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

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

ארבעת המעקות

#	המעקה	מה זה מונע
1	מתחילים בסביבת ניסיון	שינוי ראשון על מערכת ייצור
2	מאשרים את תוכנית העבודה לפני כתיבה	כתיבה שדורסת קונפיגורציה שאיש לא הזכיר
3	יודעים מראש שאין כלי מחיקה	דף או טבלה שנוצרו בטעות ואי אפשר להסיר
4	בוחרים את מודל האימות במודע	סוכן שמגיע לכל טבלה, כולל _User

---

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

את הניסויים הראשונים עושים על סביבת ניסיון. מערכת ניסיון ל‑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", ובגרסאות שרת ישנות Error: 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 — תוכן רגיש. בגרסאות שרת ישנות הטבלה חסומה (Error: Table is restricted) ונדרש REST עם Master Key. ראו דגלי 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 — הפרוטוקול, המלכודות והמגבלות
• סוכן במצב קריאה בלבד — רשימת ההיתר המדויקת
• אימות והרשאות
• התקנה בכל סוכן — היגיינת מפתחות