خطأ صغير في فريقنا الوكيلي وبوابتا أمان أوقفتاه

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

كانت واجهة إدارة TekeraLab تعرض أحياناً إصداراً سابقاً بعد بعض التحديثات. ولم يكن تكرار النشر يغير دائماً ما تعرضه بعض المتصفحات.

كان التغيير موجوداً لكن الواجهة بقيت في الخلف

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

لهذا لا يمكن أن ينتهي فحص الاكتمال الحقيقي عند رسالة Build أو Deploy خضراء. يجب فحص السطح النهائي الذي يراه المستخدم.

من أنشأ الإعداد الخاطئ؟ الجواب الصادق: لا نعرف

كان السلوك موجوداً في البنية من قبل، لكن التاريخ المتاح لا يبين أي إنسان أو وكيل كتبه أولاً. اختراع متهم يجعل القصة أسهل، لكنه يجعلها أقل صدقاً.

ما يثبته الدليل هو أن سير العمل الوكيلي لدينا لم يكتشف الفجوة في وقت أبكر. تبدأ مسؤولية الفريق بالاعتراف بهذه الفجوة حتى عندما لا نعرف الكاتب الأول.

تتبع Merlin العَرَض الظاهر إلى سياسة Cache

بعد تقرير المؤسس المتكرر، قارن Merlin—المراجع التحليلي في الفريق—ما ينفذه المتصفح بما يوجد على الخادم. وأشار التحقيق إلى طريقة تخزين مستند الدخول مؤقتاً.

يمكن لملفات JavaScript وCSS ذات أسماء الإصدارات الاستفادة من التخزين الطويل لأن أسماءها تتغير مع Build. أما مستند الدخول فيجب التحقق منه مجدداً كي يكتشف المتصفح أسماء الملفات الجديدة. معاملة الاثنين بالطريقة نفسها قد تبقي الواجهة خلف الإصدار المنشور.

رفضت بوابتان إصلاحاً متسرعاً

توقفت المحاولة الأولى لأن التغيير لم يدخل بعد المسار المتحكم به. وأطلقت المحاولة الثانية نمط أمان لا يمكن الموافقة عليه كما كُتب. لم يعتبر النظام حسن النية كافياً ورفض المحاولتين.

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

ماذا تقول التجربة عن الفريق الوكيلي؟

قيمة الوكلاء ليست أنهم لا يخطئون. القيمة في فصل المسؤوليات: يبلغ الإنسان عما يراه، ويجد الوكيل التحليلي السبب، وتوقف البوابات المستقلة التغيير الناقص، وتظل السلطة النهائية واضحة.

عزز الحادث ثلاث قواعد: لا نخترع مسؤولاً عندما يغيب الدليل؛ لا نحرك إصلاحاً من دون إثبات قابل للتتبع؛ ونقيس النجاح من شاشة المستخدم لا من حالة البنية فقط. وينظم النهج نفسه تحويل Logbook إلى رادار محتوى آمن.

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