עבודה בטוחה עם סוכן על מערכת חיה

שלושת הסיכונים: כלי שמחליף את כל הקיים (“דורס”) במקום למזג, פעולה שאין לה כלי ביטול, ופרטי גישה שעוקפים כל הרשאה. ארבעה מעקות: סביבת ניסיון, אישור תוכנית לפני כתיבה, ידיעה מראש שאין כלי מחיקה, ובחירה מודעת של מודל האימות.

---

סביבת ניסיון קודם

הריצו ניסויים ראשונים על סביבת ניסיון. מערכת ניסיון ל‑14 יום נפתחת בדקות, מקבלת Application Id ו‑API Key משלה, ומריצה את אותו שרת MCP.

זה נכון במיוחד לסקילים שנוגעים בדברים שקשה להחזיר: myb-p-mybooks-setup (מספרי מסמכים), myb-p-users-roles-permissions (CLP), ו‑myb-p-rename-terms (HTML של עשרות דפים).

חיבור אחד = מערכת אחת. אין כלי חוצה‑מערכות; ניתוב פרטי הגישה נעשה בהגדרת החיבור, לא בקריאה. אחרי כל החלפת סביבה אמתו עם Get-Current-User (במצב מפתח מוחזרת זהות סינתטית username: "Master" עם name: "User name not found") ו‑Get-Schema. שום דבר אחר לא יגיד לכם שאתם על המערכת הלא נכונה.

---

תוכנית לפני כתיבה

הפריט	למה
הטבלאות והדפים שייגעו	הרשימה מגלה עודף היקף לפני שהוא נכתב
מה מהפעולות בלתי הפיך	ראו אין כלי מחיקה ושני מודלים של אימות
מה נדרס לעומת מה מתווסף	ראו הכלים שדורסים
איך חוזרים לאחור	ל‑add יש delete; ל‑Set-* יש רק גיבוי שנקרא מראש

אחרי הכתיבה — קריאה חוזרת מהמערכת, לא “OK” מקריאת הכתיבה: Get-Table-Permissions אחרי Set-Table-Permissions, Get-Form-Rules אחרי Edit-Form-Rules, Get-Page-Settings אחרי Set-Page-Settings.

---

אין כלי מחיקה

מגבלה ידועה

אין ב‑MCP כלי מחיקה — לשום דבר. לא לרשומה, לא לטבלה, לא לדף, ולא לטריגר; אף אחד מ‑67 הכלים אינו מוחק.

מה נוצר בטעות	איך מסירים
רשומה	ממשק ה‑CRM, או REST עם Master Key
טבלה	ידנית בממשק הבנייה
דף	ידנית בממשק — ולכן pageName חייב להיות נכון בפעם הראשונה
טריגר	MCP יכול רק לכבות (active: false). מחיקה: Admin ← Databases ← Tables ← [הטבלה] ← Triggers
משתמש	אין כלי — ולא צריך אחד. active: false שומר את ההיסטוריה ואת כל הפניות ה‑Pointer שהיו נשברות
פעולת טריגר	deleteAction: true — וגם אז חייבים להעביר actionData תקף לסוג הפעולה, אחרת Cannot read properties of undefined

שם שגוי הוא נזק קבוע: דף בשם apps/mybusiness/Suppleirs יישאר עד שמישהו ימחק אותו ידנית בממשק.

---

שני מודלים של אימות — וההבדל אינו ניואנס

	Application Id + API Key	התחברות משתמש (OAuth 2.1)
הזהות בשרת	משתמש‑על בשם Master	משתמש ה‑CRM שהתחבר
מודל ההרשאות	אין — עוקף כל הרשאת טבלה	התפקיד שלו בתוספת הרשאות ה‑MCP האישיות
הגישה בפועל	כל טבלה, כל רשומה — כולל _User	רק מה שהמשתמש רשאי
הפעולות נרשמות בשם	Master	המשתמש
ביטול	Revoke לכל מפתח	ניקוי הרשאות ה‑MCP
זמין ב	כל לקוח	דפדפן בלבד

ה‑API Key איננו מפתח מוגבל

הוא מגיע לכל טבלה ולכל רשומה, והכתיבות שלו נרשמות כ‑Master. היתרון היחיד על Master Key הוא ביטול נקודתי (Revoke), וזה יתרון רק אם המפתחות אינם משותפים.

לגבול הרשאות אמיתי משתמשים בהתחברות משתמש. לפני שמבטיחים אותה ללקוח, קראו את מגבלת ה‑OAuth ללקוחות שולחן עבודה: לקוחות שכתובת ה‑callback שלהם מקומית (Claude Code, Cursor, Claude Desktop) אינם יכולים להשלים את הזרימה כרגע.

שכבת ההרשאות היחידה שנאכפת בשרת

הרשאות ה‑MCP האישיות הן השכבה היחידה שבה גבול הרשאות נאכף ברמת ה‑MCP. מעניקים ב‑הגדרות ← הכרטיס “משתמשים” ← עיפרון על כרטיס המשתמש ← לשונית MCP Permissions ← Apply, ארבע תיבות: Read / Create / Update / Edit pages and schema (דורשת Admin). מגבלה ידועה: כפוף לחבילת המנוי; במערכת ללא חבילה התיבות מנוטרלות.

הרשאות MCP לעולם לא מרחיבות את מה שלמשתמש מותר — הן יושבות מעל התפקיד. משתמש שלא רואה חשבוניות ב‑CRM לא יראה אותן דרך AI.

חיבור עם API Key עוקף את השכבה הזו לגמרי. סוכן במצב קריאה בלבד נבנה מרשימת היתר של כלים בצד הלקוח: סוכן במצב קריאה בלבד.

---

הכלים שדורסים ולא ממזגים

כל אחד מהם מקבל מצב מלא ומחליף את מה שהיה. מה שלא כללתם — בוטל בשקט.

הכלי	מה נדרס	הזרימה הבטוחה
Set-Form-Rules	כל חוקי הטופס בדף	Get-Form-Rules ← מיזוג ← כתיבה ← Get-Form-Rules לאימות. או, עדיף: Edit-Form-Rules לכלל אחד
Set-Table-Permissions	ה‑CLP המלא — כל שש הפעולות	Get-Table-Permissions ← העתק עמוק ← שינוי ← כתיבה ← קריאה חוזרת
Edit-Page-CSS-JS	כל בלוק ה‑CSS או ה‑JS	קריאה דרך Get-Page-Content ← מיזוג ← כתיבה
Edit-Table-View	columns · optionalFields · classPointers · criteria · conditionalFormattingRules	להעביר את המצב הרצוי המלא בכל קריאה
Set-Menu-Items	פריט שנשלח בלי כל שדותיו	להעתיק את הפריט המלא מ‑Get-Menu-Items — _id, title, type, page, order, icon
Set-Terminology-Dictionary	המילון	Get-Terminology-Dictionary ← עדכון המונחים שמשתנים ← שימור כל השאר
Set-Page-Version	תוכן הדף הנוכחי	בלתי הפיך. רק עם overrideHTML/overrideCSS/overrideJS שהוגדרו במפורש

הכשל האופייני של Set-Table-Permissions

אובייקט הרשאות “מתוקן” שבו find כולל רק role:Admin = צוות המכירות לא רואה לקוחות, כי role:Sales לא נכלל. הסכימה דורשת את כל שש הפעולות (find, get, create, update, delete, addField); השמטת פעולה נדחית בוולידציה, אבל השמטת תפקיד בתוך פעולה היא ביטול שקט.

כלים שמוסיפים במקום להחליף — בטעות

• Add-Edit-Counter-Element / Add-Edit-Chart-Element / Add-Edit-Text-Element עם rowId + columnNumber מוסיפים; עם elemId — מעדכנים. על תא שכבר מכיל מונה מורש, הראשון יוצר מונה שני שיושב מעליו.
• Add-Table-View-to-Form-Page מכניס ווידג’ט חדש בכל קריאה. אין “עדכן אם קיים”.

---

מלכודות שקטות בכתיבה

המלכודת	מה קורה
classPointers חסר ב‑Edit-Table-View	מיון לפי תאריך יצירה/עדכון מפסיק לעבוד. אין שגיאה. תמיד לכלול createdBy: "_User" ו‑updatedBy: "_User"
shcedulerHours מאויית נכון	השם המשובש הוא הנכון. schedulerHours המאויית נכון אינו שקט — מחזיר Error: Scheduler hours is required for scheduled trigger והטריגר לא נוצר
שני סוגי מזהים	תפריטים ודפים משתמשים ב‑_id של MongoDB (24 תווים הקסדצימליים); רשומות נתונים ב‑objectId של Parse (10 תווים). הזנת שם היכן שמצופה מזהה — כישלון
Get-Data מחזיר 5 שורות	תשובה קטומה נראית כמו טבלה קטנה, ו“אימות” מול רשימה חלקית עובר בהצלחה

ושתי מגבלות ארכיטקטורה לתכנן סביבן:

• מגבלה ידועה — שרשרת טריגרים מוגבלת ל‑3 רמות. שלושה טריגרים שלובים רצים; הרביעי נחסם ונרשם ב‑_syslogTriggers עם blocked! trigger step is to deep -3.
• טבלת Config פתוחה ל‑MCP — דגלי הטפסים (AcceptWebLeads / AcceptWebToTable) ניתנים לאבחון ולהפעלה מכלי הנתונים בחיבור Master Key. דף Config בממשק אינו קיים, והשורות כוללות את הגדרות Payment — תוכן רגיש. ראו דגלי Config.

---

ייבוא המוני מעיר את האוטומציות

רשומות שנוצרות דרך API מפעילות טריגרים כברירת מחדל

Create-Data, Update-Data ו‑Create-Many מפעילים אירועי create/update. הצד הטוב: בדיקת טריגר דרך MCP היא בדיקה תקפה. הצד המסוכן: ייבוא של 800 שורות יכול לשלוח 800 מיילים.

ההשתקה היחידה היא Create-Many(skipTriggers: true) (ו‑skipTimeline: true לציר הזמן), והיא מפתח‑מאסטר בלבד. לכלים של רשומה בודדת אין דגל דילוג.

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

---

שכבת התיעוד — כל פעולה נרשמת

הפלטפורמה כותבת שורת _Timeline לכל אירוע יצירה או עדכון על טבלאות העסק הנעקבות, בתוספת אירועי פיד (הערות, מיילים, SMS, שיחות, הצעות מחיר). זו הטבלה שמזינה את פיד הפעילות על כרטיס הרשומה, וטבלת הביקורת הראשית.

JSON

Get-Data({
  "table": "_Timeline",
  "where": { "objectClass": "Sales", "objectIdValue": "YEkT85jX3K" },
  "order": "-createdAt",
  "limit": 50
})

השדה	המשמעות
event	סוג האירוע
objectClass	מחלקת הרשומה ששונתה
objectIdValue	ה‑objectId של הרשומה
data	השדות שהשתנו, עם הערכים החדשים, לפי הפורמט ב‑JSON
user	מי ביצע — Master לכתיבות שרת/טריגר, כלומר גם לכתיבות של סוכן עם API Key
Last	מסמן את שורת ציר הזמן האחרונה של הרשומה

מה זה אומר על ביקורת

פעולה של סוכן עם API Key נרשמת בשם Master. ה‑_Timeline יגיד לכם מה השתנה ומתי, לא מי הריץ את הסוכן. דרושה שרשרת אחריות ברמת אדם? העדיפו התחברות משתמש.

ליומן הטריגרים יש טבלה משלו, _syslogTriggers, עם שדה error לכל ריצה. המקום הראשון לבדוק כשטריגר “לא ירה”:

JSON

Get-Data({ "table": "_syslogTriggers", "order": "-createdAt", "limit": 5,
           "keys": ["triggerId", "actionId", "objectIdValue", "error", "event", "createdAt"] })

שורה לכל פעולה; אין שדה triggerName — את השם מצליבים מ‑Get-Triggers.

גרסאות דף נשמרות: Get-Page-Versions מחזיר את הרשימה (החדשה ראשונה), Get-Page-Version מחזיר רק את מה שהשתנה באותה גרסה (content או jsCode או cssCode, לא תמיד שלושתם), ו‑Set-Page-Version משחזר — בלי דגלי override* הוא מחזיר Error: No update to perform. זה מסלול השחזור היחיד לדף ששובר.

---

סודות — ומה אף פעם לא נכנס לקובץ

הכלל	למה
מפתח לעולם לא ב‑repository — לא ב‑.mcp.json של פרויקט, לא בצ’אט, לא בקריאת שירות	בפורמט Agent Plugins 1.0 המפתח יושב ב‑mcp.json כטקסט. התיקייה הזו לא עולה לגיט
לעולם לא לבקש מהמשתמש את סיסמת החשבון שלו	מצב ההתחברות לוקח אותו לדף הרשמי; מצב המפתח לא צריך סיסמה
עובדים על מערכת של מישהו אחר? הוא מייצר את המפתח, והוא מבטל אותו בסיום	ביטול נקודתי שווה משהו רק אם ידוע איזה מפתח שייך למי
פרטי סליקה וסיסמאות SMTP — הלקוח מזין אותם בממשק, הסוכן לא מקבל אותם	ב‑myb-p-mybooks-setup זה כלל מנוסח. בקריאת AccountingSettings — רשימת keys מפורשת שאינה כוללת Password
מפתח אחד לכל לקוח או מטרה	מפתח משותף לא ניתן לביטול בלי לשבור את כולם. עד 5 מפתחות לבסיס נתונים

---

רשימת בדיקה לפני כתיבה ראשונה לייצור

• Get-Current-User — באיזה מצב אימות אני
• Get-Schema — הקראתי שמות טבלה, והמשתמש אישר שזו המערכת הנכונה
• אילו כלים בתוכנית דורסים, והמצב הקיים נקרא לפני כל אחד
• אילו פעולות בלתי הפיכות (שם דף, מספר מסמך, מספר רצף)
• Get-Triggers על טבלאות היעד
• גיבוי לכל מצב שעומד להידרס (Get-Form-Rules / Get-Table-Permissions / Get-Page-Content)
• התוכנית אושרה
• אחרי הכתיבה — קריאה חוזרת מהמערכת

---

המשך

• שרת ה‑MCP — הפרוטוקול, המלכודות והמגבלות
• סוכן במצב קריאה בלבד — רשימת ההיתר המדויקת
• אימות והרשאות
• התקנה בכל סוכן — היגיינת מפתחות