> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# בדיקת מדיניות

> בצע בדיקת אחורה של טיוטה מול תנועה שכבר יש לך, והוכח שהיא עוצרת את מה שצריך ומאפשרת את מה שחייב, לפני שכל מכונה אוכפת אותה.

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

## בדיקת אחורה של הטיוטה

<Tabs>
  <Tab title="Dashboard">
    עורך המדיניות משחק מחדש טיוטה מול קריאות שהצי שלך כבר ביצע, לפני שאתה מפרסם אותה.

    1. פתח את הטיוטה ב-**Admin → policy editor**. העורך מאשר שהיא מתאימה כ-JavaScript.
    2. ב-**backtest**, בחר את הסוכנים ואת חלון הזמן להשחקה מחדש — **כל סוכן** ו-**30d** כברירת מחדל — והשאר את המסנן האחרון ב-**everything** אלא אם אתה רוצה לצמצם.
    3. בחר **run backtest**.

           <img src="https://mintcdn.com/exosphere/k_s8fY_jSxA_m1d_/images/dashboard/policy-backtest.png?fit=max&auto=format&n=k_s8fY_jSxA_m1d_&q=85&s=4231c5aa520d82131f70d1b9226e0114" alt="לוח ה-backtest תחת טיוטה שמתאימה כ-JavaScript, עם שלושת המסננים שלה וה-run backtest action, מעל publish version." width="2284" height="522" data-path="images/dashboard/policy-backtest.png" />

    התוצאה היא מה שהטיוטה הייתה עושה לקריאות אלה — כולל כמה קריאות **עובדות** היה היא עוצרת. אלה חיובים כוזבים שנמצאו לפני שכל סוכן פוגש בהם: התחזק את הטיוטה והשחק אותה שוב עד שהמספר הזה הוא מספר שאתה יכול לקבל.
  </Tab>

  <Tab title="CLI">
    בדיקת אחורה היא תכונת dashboard. מטרמינל, הרץ את המדיניות מול אירועים שאתה מתאר במקום, למטה.
  </Tab>
</Tabs>

## הרץ אותה מול אירוע שאתה מתאר

`fp policies test` מריץ קובץ מדיניות על המכונה שלך מול אירוע סינתטי ובודק את ההחלטה. שום דבר לא מפורסם ותום דבר לא מגיע ל-Cloud:

```bash theme={null}
fp policies test ./checkout.policy.mjs --command "git push --force" --expect deny
fp policies test ./checkout.policy.mjs --command "git push" --expect allow
```

עצב את האירוע עם `--event`, `--tool`, `--command` ו-`--file`. מסנן ה-`match` של המדיניות עצמה עדיין תקף, ולכן מדיניות שלא מכסה את האירוע שתיארת מדווחת `skipped` ולא החלטה — בדרך כלל סימן שה-`match` שלה צר יותר ממה שהתכוונת.

## הרץ אותה על מכונה אחת

לאחר מכן, אכוף אותה באמת על המכונה שלך, מול הסוכן שלך:

```bash theme={null}
failproofai policies --install --custom ./checkout.policy.mjs --scope project
failproofai policies
```

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

על מכונה המחוברת ל-Cloud, בדוק את שתי ההחלטות תחת **Observe → policy**: סנן לפי שם המדיניות, ואז פתח כל הפעלה מקושרת כדי לאשר את קלט הכלי שהיא התאימה ואת הסיבה שהחזירה.

## בדוק מה שמתקלקל

ההתקנה דוחה קובץ חסר, שגיאת תחביר, ייבוא לא פתור, חריגה ברמה העליונה, או מודול שקופא בעת טעינה — אז הרץ שוב אחרי כל שינוי לקובץ או לכל דבר שהוא מייבא. בזמן אכיפה אותו קובץ שבור מתועד וביצוע מושעה כך שכל מדיניות אחרת ממשיכה לרוץ: התייחס לאזהרת טעינה ביומנים בייצור כאל אכיפה אבודה. קובצי קונבנציה נטענים ללא פקודת ההתקנה, אז שמור על שלב `failproofai policies --install --custom <file>` מפורש ב-CI — זה מה שגורם לבנייה להיכשל על מדיניות שבורה.

לאחר מכן הזן לה מה שסוכנים בעצם שולחים, לא רק את הקלט שאתה צופה: שדות חסרים, שמות כלים חלופיים כגון `Write` ו-`Edit`, נתיבים של Windows, קלט שגוי. החזר בכוונה `allow`, `instruct` או `deny` בכל נתיב, שמור על הפונקציה דטרמיניסטית, וקשור כל קריאה חיצונית עם timeout קצר.

## ואז פרסם אותה ותבחין בה

בדיקת אחורה מראה מה המדיניות הייתה עושה לתנועה שהייתה לך; היא לא יכולה להראות מה תנועה שלא ראית עדיין תעשה. בחר **publish version** בעורך (או הרץ `fp policies publish`), ואז [פרוס אותה](/he/policies/deploy) ב-**observe** mode קודם — הפסקיות שלה מתועדות ותום דבר לא חסום — ואכוף ברגע שהתאימות שלה מפרידות בין פעולות לא בטוחות ליעילות בעל כורחך.