ל-LVLZ יש שתי דרכי כניסה. אפשר לכתוב לסוכן, ואפשר לפתוח את סביבת העבודה באפליקציית הווב. מוקדם מאוד קבענו כלל: כל מה שאפשר לעשות באחת, אפשר לעשות גם בשנייה. הפוסט הזה מסביר איך אנחנו עומדים בהבטחה הזאת בלי להסתמך על זיכרון ועל כוונות טובות.
למה השוויון חשוב
אם האפליקציה יכולה להעביר פרויקט לארכיון אבל הסוכן לא, לומדים לא לבקש מהסוכן. אם הסוכן יכול להגדיר שגרה אבל האפליקציה לא יכולה להציג אותה, מפסיקים לסמוך על האפליקציה. כל פער כזה מלמד אתכם לעקוף את המוצר. שוויון אומר שאף פעם לא צריך לתהות איזה צד יכול לעשות מה.
הגדרה אחת לכל יכולת
כל פעולה, כמו יצירת משימה, שליחת מייל או התחלת משימת דפדפן, מוגדרת פעם אחת במרשם משותף. הגדרה כוללת:
- מפתח קבוע, כמו
task.create, - סכמה עם טיפוסים לקלט שלה,
- איך היא מוגנת (האם היא צריכה את האישור שלכם),
- אילו ממשקים מציעים אותה,
- דוגמה לאיך הייתם מבקשים אותה במילים פשוטות.
מההגדרה האחת הזאת אנחנו מייצרים את הכלי שהסוכן קורא לו, את נקודת הקצה ב-HTTP שהאפליקציה קוראת לה ואת הרשומה במניפסט. אותו handler משרת את הסוכן ואת האפליקציה, כך שההתנהגות זהה מעצם המבנה.
בדיקה שמכשילה את ה-build
הגדרות לבדן לא מבטיחות שוויון, כי עדיין מישהו צריך לממש כל צד. לכן ה-build שלנו מריץ בדיקת שוויון. אם יכולת מסומנת כפעילה אבל צד אחד לא מימש אחת מהפעולות שלה, ה-build נכשל. אם פעולה ממומשת בכל הצדדים אבל עדיין מסומנת כ"בקרוב", ה-build נכשל גם כן, כך שהסטטוס הציבורי לא יכול לפגר אחרי המציאות.
האתר קורא את אותה רשימה
המניפסט מזין גם את האתר הזה. עמוד היכולות וכל עמוד שמתחתיו מציגים כל יכולת עם הסטטוס שלה, פעיל, בקרוב או בהמשך, ואיפה היא רצה: באפליקציה או בוואטסאפ. כשאנחנו משחררים משהו, העמוד מתעדכן בפריסה הבאה. כשאנחנו כותבים שמשהו בדרך, זה כי המרשם אומר את זה.
מה זה אומר בשבילכם
לומדים את LVLZ פעם אחת. כל מה שתמצאו באפליקציה, אפשר לבקש בהודעה, וכל מה שהסוכן עושה, תמצאו באפליקציה. וכשאתם קוראים את רשימת היכולות שלנו, אתם קוראים את הקוד.