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