जब असिस्टेंट कहता है, “एलिस को इनवॉइस भेजें,” तो यूज़र Send पर क्लिक करता है, क्योंकि UI उस समरी को ऐसा दिखाता है जैसे वही काम होने वाला हो।
इसके बाद UI एक ऐसा अनुरोध पूरा करता है जिसका असली पाने वाला bob@vendor.com होता है, और यूज़र को इसका पता तब चलता है जब इनवॉइस गलत इनबॉक्स में पहुँच जाता है।
इस खराबी में मॉडल को प्रोडक्ट को “हैक” करने की ज़रूरत नहीं पड़ती।
यह खराबी इंटरफ़ेस की उस सीमा पर होती है जहाँ जेनरेट किया गया टेक्स्ट ऐसी चीज़ बन जाता है जिसे कोई इंसान मंज़ूरी देता है, और UI असिस्टेंट के आसान और साफ़ विवरण को उन पैरामीटर की जगह लेने देता है जो असल में लागू होंगे।
अगला उदाहरण एक छोटे असिस्टेंट UI का है जो बटन पर क्लिक करने पर सीधे तौर पर मिसमैच (मेल न खाने की स्थिति) को दिखाता है।
यह कोड समस्या को स्पष्ट करता है; यह UI जो दिखाता है और एक्शन जो असल में भेजता है, उन्हें अलग-अलग करता है। क्लिक करने पर पता चलता है कि प्रोडक्ट असल में क्या डेटा (पेलोड) भेजेगा।
हमने अभी जो अंतर देखा, वह इसलिए होता है क्योंकि फ्रंटएंड असिस्टेंट फ़्लो में कई अलग-अलग चरण होते हैं, और हर चरण गलत या असुरक्षित धारणा बना सकता है।
हम फ्रंटएंड द्वारा नियंत्रित चार चरणों के नाम रख सकते हैं और हर एक को “इनवॉइस भेजने” वाले एक ही उदाहरण से जोड़ सकते हैं, ताकि बाद में किए जाने वाले सुधार फ़्लो के सही बिंदु पर लागू हों।
इन चरणों को अलग-अलग करने का फ़ायदा यह है कि हर चरण के लिए अलग इंटरफ़ेस कंट्रोल की ज़रूरत होती है, और गलत चरण पर चेतावनी वाला बैनर लगाने से समस्या नहीं रुकती।
अगला डायग्राम उन दो सीमाओं को दिखाता है जो इस कोर्स में सबसे महत्वपूर्ण हैं: जहाँ टेक्स्ट DOM बनता है और जहाँ मंज़ूरी एक रिक्वेस्ट (अनुरोध) में बदलती है।