מאושר לפני שהוא רץ: איך קו מטפל בפעולת כתיבה

לשאול שאלה ולבקש שמשהו יקרה הן בעיות שונות. אם התשובה לשאלה שגויה, התושב פשוט שואל שוב. אם פעולת כתיבה שגויה — פגישה שהועברה, טופס שנשלח, שירות שבוטל — משהו אמיתי השתנה על סמך ניחוש.

מה התושב רואה

העוזר של משרד שירות מתבקש להעביר פגישת ייעוץ. במקום פשוט לבצע זאת, הוא מציג כרטיס: השעה הישנה, השעה החדשה, ושורה אחת — ממתין לאישורך. שום דבר לא קורה עד שהתושב לוחץ על אישור.

למה זה לא רק דפוס עיצוב

בקו, יכולת שמשנה משהו מוגדרת כתיבה, וההגדרה הזו נושאת השלכות אמיתיות, לא רק תווית. היא דורשת תור אישור מפורש לפני שהיא רצה. היא נושאת מפתח אידמפוטנטיות עם חלון מניעת כפילות, כך שלחיצה כפולה — או בקשה כפולה מחיבור לא יציב — לא מכפילה את הפעולה. ואם בקשה נראית כאילו היא כבר בביצוע, הפלטפורמה לא מנחשת; היא מנתבת לתוצאת possibly-duplicated שאדם פותר, במקום להריץ בשקט שוב משהו שאולי כבר קרה.

מה המודל רשאי ואינו רשאי לעשות

המודל יכול להציע פעולת כתיבה ולתאר אותה במילותיו של התושב. הוא לא יכול להחליט, ביוזמתו, שהפעולה תתבצע. כרטיס האישור מוזן מאותו פלט יכולת מוקלד כמו כל קריאה — שעת הפגישה, העלות, מספר האסמכתא — כולם מגיעים מהמערכת עצמה, לעולם לא נכתבים על ידי המודל — כך שמה שהתושב מאשר הוא בדיוק מה שירוץ, לא ניסוח מחדש שלו.

למה זה חשוב

שיחת שירות שיכולה רק לספר לתושב משהו בטוחה מעצם מבנהּ. שיחה שיכולה גם לעשות משהו היא המקום שבו הזיה מפסיקה להיות מביכה והופכת לתקרית. אישור לפני ביצוע, עם מפתח אידמפוטנטיות מאחורי האישור, הוא מה שמאפשר לקו לעשות את שניהם — לענות, ולפעול — בלי לבקש מארגון לסמוך על ניחוש.