סקילים — חיבור, ידע ומתודולוגיה

שלושה סקילים שאינם בונים ישות ולא מציבים אלמנט: אחד פותח את הדלת, אחד מחזיק את העובדות, ואחד מחליט מה בהיקף. בסוף העמוד — מתכון סקר שביעות הרצון, שעבר ב‑1.5.0 לתוך myb-p-public-forms.

מאפס עד חיבור מוכח: פתיחת חשבון ← התחברות ראשונה ← חיבור התוסף ← הוכחה ← המשימה הראשונה. שני קהלים קוראים אותו — אדם שעוקב אחרי התמונות, וסוכן שמבצע את הצעדים; קובצי הייחוס נושאים את צילומי המסך.

הצעדים המפורטים מכוסים בהתקנה בכל סוכן. מה שהסקיל מוסיף הוא המשמעת.

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

initialize ורשימת הכלים מצליחות גם בלי אימות; רק קריאת כלי אמיתית מוכיחה.

ואז הקריאו למשתמש 3–4 שמות טבלה או שדה שהוא מזהה, ובקשו אישור שזה בסיס הנתונים הנכון, לפני שאתם כותבים.

מחובר לבסיס הנתונים <שם/סאב‑דומיין> בזהות <משתמש או Master>. יש בו <n> טבלאות, כולל <3–4 שמות מזוהים>. זו המערכת הנכונה?

אחרי ההוכחה, הסקיל אומר מה יש במערכת (ספירת מודולים וטבלאות מ‑Get-Schema/Count-Data) ומנתב:

1. API Key לעולם לא בקובץ משותף או מנוהל‑גיט — לא ב‑repository, לא ב‑.mcp.json של פרויקט, לא בצ’אט. קונפיגורציית התוסף שומרת אותו בכספת של מערכת ההפעלה.
2. לעולם לא לבקש מהמשתמש את סיסמת החשבון שלו. מצב ההתחברות לוקח אותו לדף הרשמי; מצב המפתח לא צריך סיסמה.
3. חיבור אחד = בסיס נתונים אחד. אין כלי חוצה‑מערכות; אחרי כל החלפת חיבור, Get-Current-User + Get-Schema.
4. מוכיחים לפני שכותבים.

• התחברות משתמש חסומה בלקוחות שולחן עבודה/CLI — ה‑callback המקומי נדחה לפני שהוא מגיע לשרת.
• הרשאות MCP ניתנות לכל משתמש בנפרד, לא לתפקיד — עשרה משתמשים = עשר הענקות. ארבע תיבות בלשונית (Read / Create / Update / Edit pages and schema), זמינות רק במערכת עם חבילת מנוי.
• הסקיל מקים ומוכיח את החיבור, לא מאבחן את ה‑CRM. Permission denied on get היא שאלת הרשאות.

בסיס הידע של המוצר. הסקיל הוא ספרן: מנתב לקובץ הייחוס הנכון מתוך יותר מ‑40 מסמכי מוצר, ואומר לסוכן לקרוא רק את מה שצריך.

myb-p-kb/references/
├── 00-overview/             סקירת מוצר · ארכיטקטורה · מילון מונחים · סביבות וגישה
├── 10-modules/              CRM Core · MyBooks · MyCampaigns · MyChat · MyCollege · TimeSheet · MyInbox
├── 20-data-model/           סקירה · טבלאות ליבה · טבלאות מודולים · טבלאות מערכת ולוגים · טיפוסים ומוסכמות
├── 30-customization/        דפים · טבלאות תצוגה · דשבורדים ודוחות · טריגרים · חוקי טופס ·
│                            הרשאות · מינוח · מסמכים · דפוסי שדות · Blueprints · פורטלים
├── 40-integrations-api/     Parse REST · קטלוג כלי MCP · getlead/web2table · פונקציות ענן ·
│                            ערוצי הודעות · קבצים ואחסון
├── 50-ui-walkthrough/       סיור בממשק הריצה ובממשק הבנייה — עם צילומי מסך
├── 60-implementation-methodology/  מחזור יישום · אפיון · fit-gap · אפיון טכני · תוכנית · אומדנים
├── 80-capability-matrix/    מטריצת יכולות + מגבלות ידועות
└── 90-appendices/           קטלוג מדריכי התמיכה · שאלות נפוצות

כל קובץ נפתח בשורת Purpose ומסתיים ב‑Limitations & gotchas.

1. מערכת חיה גוברת על מסמכים. לפני שמבטיחים התנהגות על מערכת ספציפית, אמתו בקריאות MCP לקריאה בלבד (Get-Schema, Get-Triggers, Get-Site-Pages). סכימות מתפצלות בין לקוחות.
2. כל דבר שמסומן ⚠️ UNVERIFIED חייב אימות.
3. תשובות יכולת משתמשות בסולם: Native / Config / Custom-JS / Custom-Server / External / Gap.
4. טענות שמצטטות מספרי קריאות שירות או “ב‑QA” פגות תוקף. אמתו מחדש בזמן השימוש.
5. תיעוד שגוי — אומרים במפורש בתשובה ומסמנים למתחזקים. לא עוקפים בשקט.

• מטריצת יכולות שכל שורה בה מצביעה למנגנון ספציפי.
• חובה לבדוק את 02-known-limitations.md לפני “כן”.
• שורה חסרה מפעילה סדר חיפוש: Blueprints של פתרונות ← מסמך התחום ← אימות חי בסביבת ניסיון.
• סיווג לסולם, כלומר גם מי משלם: Native בחינם, Custom-Server כרטיס פיתוח.
• מקור לכל טענה: שורה במטריצה, blueprint, או אימות חי.

מסווג כל דרישה לשלב הזול ביותר בסולם שבאמת עובד, עם ראיות, ומייצר החלטת היקף שהלקוח יכול לחתום עליה. השיטה: סולם היכולות + fit-to-standard first (adopt > adapt > build), עם הכרעות מנוסחות לפערים ו‑workbook שמסמך האפיון הטכני צורך.

לעולם לא מסווגים מהזיכרון.

1. מטריצת היכולות ← ואז תמיד מגבלות ידועות, לפני כל “כן”. שורה חסרה? ← Blueprints של פתרונות ← מסמך התחום ← אימות חי בסביבת ניסיון.
2. עוגני אומדן ממדריך ההערכות.
3. מסמך השיטה + ה‑playbook של הסיווג בסקיל.

ולצדן שתי הכרעות שיכולות לפתור שורה במקום מחלקה:

• Process-change — השינוי בתהליך, לא במערכת. דורש הסכמה מתועדת של הלקוח.
• Defer — חדר המתנה, עם תאריך חזרה.

כל צעד למטה בסולם דורש שורת נימוק כתובה.

לכל Gap אחת משלוש הכרעות כתובות: עוקף (כולל עלות החיכוך) / דחייה / הסרה מההיקף (עם יידוע הלקוח). מהשורות נגזרת רמת המורכבות (Low/Medium/High/Enterprise = השלב העמוק ביותר שנעשה בו שימוש), שמכתיבה את שאר ההתקשרות.

עבודת פיתוח בתשלום דורשת אישור מפורש של הגורם המאשר אצל הלקוח, פריט‑פריט.

דוח HTML ממותג בעברית + fit-gap.csv, ההעברה המכונתית לסקיל האפיון הטכני.

1. מחפשים, לא מנחשים. כל סיווג מצטט שורת מטריצה, blueprint, או אימות חי. תשובה “מהניסיון” היא באג.
2. טענות שמצטטות כרטיסים פתוחים או “ב‑QA” פגות; לאמת מחדש.
3. יכולת או מגבלה שהמטריצה לא מכירה — לציין בדוח וגם לסמן למתחזקים.
4. “Config בתיאוריה, Custom בפועל”: 14 טריגרים שלובים גרועים מפונקציית שרת אחת. שופטים לפי תחזוקתיות.
5. הדוח בעברית; סקיצות הפתרון יכולות לשאת שמות מנגנון באנגלית.

עד 1.5.0 סקיל נפרד, myb-p-csat-survey; מאז התיקייה csat/ בתוך myb-p-public-forms. המתכון זהה, ונוסף לו וריאנט נייטיבי שהקישור שלו לא נושא נתון אישי.

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

עובד על כל אובייקט עסקי עם אירוע סגירה ואיש קשר נגיש: Cases הוא הנפוץ, ו‑Sales, Tasks או ישות מותאמת עובדים זהה.

המשיב אנונימי, ואנונימי אף פעם לא כותב לפנייה עצמה — רק לשורת קליטה. לכן לשני הווריאנטים אותן ארבע שכבות:

הודעה · קישור לכל דירוג  →  מזהה הפנייה + הדירוג
דף ציבורי                →  רושם את הדירוג בטעינה  →  שורה בטבלת הקליטה
טריגר היטל               →  מעתיק דירוג / הערה / תאריך אל הפנייה
טריגר תגובה              →  דירוג שלילי  →  משימה או התראה לאחראי

בחרו בנייטיבי, אלא אם הלקוח כבר מריץ את גרסת web2table — שומרים אותה, לא בונים מחדש סקר שעובד — או חייב אפס תלות בצד הגולש. בשני הווריאנטים ההערה נרשמת כשורת קליטה שנייה, כי הקליטה נשארת create-only.

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

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

Get-Schema(<הטבלה העסקית>)        ← Pointer לאיש הקשר, שדה האחראי, שדה הסטטוס
Get-Data(<טבלת הסטטוסים>)         ← סטטוסי הסגירה וה-objectIds, לשאול בשמות אמיתיים
Get-Schema("SatisfactionSurveys") ← ייתכן שכבר קיימת במערכת ותיקה (במערכת חדשה אינה קיימת)
Get-Triggers(<הטבלה העסקית>)      ← לרוב כבר יש טריגר מייל סגירה: כבוי, או על הסטטוסים הלא נכונים
Get-Site-Pages                     ← דף ציבורי קיים מוכיח שהמסלול עובד כאן — וזה הדבר הכי טוב לשכפל

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

השתמשו ב‑SatisfactionSurveys אם קיימת; אחרת בנו במינימום:

הרשאות. בנייטיבי: create לתפקידי הצוות ול‑"*"; find/get/update לצוות; delete ל‑Admin; addField: {} — ושום דבר ציבורי מעבר ל‑create. ב‑web2table: השאירו את ה‑CLP סגור — טבלה שנוצרת ב‑Create-Table נולדת עם find/get ל‑requiresAuthentication ו‑create/update/delete ל‑role:Admin בלבד, ו‑web2table כותב בכל מקרה. בשני המקרים קראו חזרה ב‑Get-Table-Permissions ובדקו שלא פתחתם משהו בטעות בזמן דיבוג.

CsatRating (Number) · CsatComment (String) · CsatAt (Date) — מה שטריגר ההיטל כותב וכל דוח קורא. בנוסף, סקשן לקריאה בלבד על הכרטיס.

Set-Trigger על הטבלה העסקית: events: ["update"], onSetFields: ["<שדה הסטטוס>"], קריטריונים רק לסטטוסים שסוכמו, oneachupdate: false, ופעולת email שמפנה לתבנית.

oneachupdate: false פירושו גם שפנייה שנפתחה מחדש ונסגרה שוב לא מייצרת סקר שני.

על טבלת הקליטה, events: ["create"], פעולת update-object:

{ "targetClass": "Cases",
  "connection": "source.CaseId",
  "fieldsValue": [
    { "field": "CsatRating",  "type": "dynamic", "value": "OverallRating" },
    { "field": "CsatComment", "type": "dynamic", "value": "AdditionalComments" },
    { "field": "CsatAt",      "type": "dynamic", "value": "updatedAt" }
  ]}

source.<Pointer> = “הרשומה שהשורה הזו מצביעה אליה”. הדקדוק המלא: אוטומציה.

על טבלת הקליטה, קריטריון OverallRating <= <סף שלילי> ← create-object (משימה לבעלים של התהליך, מקושרת לפנייה וללקוח) או notification.

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

11 בדיקות, חמש מהן שליליות:

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

דווחו את הספירה בכנות (n/11), כולל אילו בדיקות לא הצלחתם להריץ.

• שתי שורות לכל מענה זה נכון, לא באג — האובייקט העסקי מחזיק את התשובה, טבלת הקליטה היא היומן. כתבו את זה, אחרת מישהו “יתקן”.
• אי אפשר לשנות סוג של פעולה במקום. Set-Trigger-Action מדווח הצלחה ומשאיר את הישנה; deleteAction אינו אמין דרך הפרוקסי. להחלפת משימה בהתראה: טריגר חדש נקי, והישן כבוי.
• דירוג שנשמר כ‑String הורג את חישוב הממוצע, ואף אחד לא מבחין עד שהדוח נדרש.
• קריטריון Number בטריגר צריך T: "Number"; ערך כמחרוזת לעולם לא יתאים.
• שמירת ה‑JS של הדף מחזירה 403? ה‑WAF של הפלטפורמה דחה את התוכן, לא את הקוד שלכם: חלק מדפוסי ה‑URL וה‑regex ב‑JS של דף חסומים (גופי data‑URI עוברים בנקודת ה‑MCP ונחסמים ב‑REST). העלו את הסקריפט ב‑Upload-Public-File וטענו אותו מ‑loader בן שתי שורות. אל תנסו לנצח את המסנן בשכתוב הקוד.
• וריאנט נייטיבי: שליחה לפני שה‑reCAPTCHA נטען יוצאת בלי טוקן, והשמירה נדחית. הסקריפט המצורף לסקיל מחכה; קוד שנכתב ידנית חייב לחכות גם.
• וריאנט נייטיבי: סולם רדיו בדף. הקישור ממלא שדה מוסתר — אין מה ללחוץ ואין מה שחוק טופס יקרא. השאירו אותו מוסתר.

• שאלה אחת בהודעה. שאלות נוספות שייכות לדף, אחרי הלחיצה — טופס ההערה יכול לגדול לטופס נייטיבי מלא — אף פעם לא לפניה.
• שיעור מענה הוא opt-in ולא ניתן להשלמה לאחור.
• אין דה‑דופליקציה בין מכשירים. בנייטיבי הדף מסרב לשלוח שוב בטעינה חוזרת באותה לשונית; נמען שלוחץ משני מכשירים יוצר שתי שורות, וההיטל המאוחר מנצח. מקובל ל‑CSAT; לא מקובל אם לציון יש השלכה מסחרית.
• וריאנט נייטיבי: גולש מסומן מקבל אתגר. גולש שגוגל מסמן רואה אתגר CAPTCHA לפני שהתשובה נשמרת. נדיר; התשובה נרשמת אחרי הפתרון.

• התקנה בכל סוכן — הצד המעשי של myb-p-getting-started
• עבודה בטוחה עם סוכן על מערכת חיה
• אינדקס 24 הסקילים