ينقر المستخدم على زر إرسال (Send) بعد أن يقول المساعد: “أرسل الفاتورة إلى أليس” (Alice)، وذلك لأن واجهة المستخدم تُظهر ذلك الملخص وكأنه الإجراء الفعلي الذي سيتم تنفيذه.
بعد ذلك، تُنفِّذ الواجهة طلباً يكون فيه المستلم الحقيقي هو bob@vendor.com، ولا يكتشف المستخدم ذلك إلا بعد فوات الأوان، حين تصل الفاتورة إلى صندوق الوارد الخطأ.
لا يتطلب هذا النوع من الفشل قيام النموذج “باختراق” المنتج.
يحدث الفشل عند نقطة التماس في الواجهة، حيث يتحول النص المُولَّد إلى إجراء يوافق عليه المستخدم البشري، وتسمح الواجهة لوصف المساعد السلس والمقنع بأن يحل محل المعاملات (parameters) التي سيتم تنفيذها فعلياً.
المثال التالي يوضح واجهة مصغرة لمساعد تظهر فيها حالة عدم التطابق هذه بوضوح عند النقر على الزر.
يجعل هذا الكود المشكلة ملموسة من خلال الفصل بين ما تعرضه واجهة المستخدم (UI) وبين ما سيرسله الإجراء الفعلي؛ إذ يكشف النقر عن “الحمولة” (البيانات) الحقيقية التي سينقلها المنتج.
ينشأ عدم التطابق الذي رأيناه للتو لأن مسار عمل المساعد في الواجهة الأمامية يتكون من مراحل متعددة ومتميزة، ويمكن لكل مرحلة أن تولد نوعاً مختلفاً من الاعتقادات غير الآمنة.
يمكننا تحديد أربع مراحل تتحكم فيها الواجهة الأمامية وربط كل منها بسيناريو “إرسال الفاتورة” ذاته، وذلك لضمان تطبيق الإصلاحات اللاحقة في النقطة الصحيحة من المسار.
تكمن قيمة الفصل بين هذه المراحل في أن كل مرحلة تتطلب عنصر تحكم مختلفاً في الواجهة، كما أن عرض شريط تحذيري في مرحلة خاطئة لن يمنع حدوث النتيجة غير المرغوبة.
يوضح الرسم البياني التالي الحدين الفاصلين الأكثر أهمية في هذا السياق: النقطة التي يتحول فيها النص إلى DOM، والنقطة التي تتحول فيها الموافقة إلى طلب تنفيذ.