כתיבת מדיניות

ישנן שתי דרכים לכתוב מדיניות: לתת ל-Failproof AI לנסח אותה מממצא ביקורת, או לכתוב את המקור בעצמך. שום דבר לא מפורסם או נפרס עד שתבחר לעשות זאת.

כתיבת מדיניות מביקורת

ביקורת מגלה כשל; מדיניות עוצרת אותו מהתרחשות שוב. Failproof AI משרטטת את המדיניות מהראיות של הממצא עצמו.

1. הרץ ביקורת

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

2. צור את הטיוטה

לוח בקרה
CLI

פתח את בעיית הממצא תחת Analyze → issues ובדוק את התקופות המצוטטות שלה, הסיבה השורש, וההמלצה.
בחר generate policy. Failproof AI תגיד תחילה אם מדיניות יכולה בכלל להביע את הבעיה. תוצאה של no policy אומרת שהתיקון הוא התראה, שינוי זרימת עבודה, או אדם — לא מדיניות.
בחר write this policy. כותרת הבעיה, הממצא, הסיבה השורש, ההמלצה, וכוונת האכיפה המוצעת הופכות לטיוטה ב-Admin → policy editor. השתמש ב-open the editor anyway כשאתה לא מסכים עם בדיקת המועמדות.

קרא את הראיות, ואז שרטט עם העוזר. compose מדפיס מקור לך לבדיקה ולא מפרסם כלום:

fp issues show <issue-id>
fp audits finding <finding-id>
fp policies compose "Block git push --force on release branches"

compose דורש session מחובר (fp login) שלתפקיד שלו יש הרשאת policies:write; מפתחות API נדחים.

3. בדוק את הטיוטה

טיוטה היא נקודת התחלה, לא פסק דין. לפני פרסום, בדוק כי היא:

קוראת למצב הכשל בשפה תפעולית.
מתאימה רק להתרחשויות ווקט וכלים שנושאים מספיק ראיות להחלטה.
משתמשת בתנאי הצר ביותר שתופס את הפעולה הלא בטוחה.
מחזירה סיבה שאומרת לסוכן מה לעשות במקום זאת.
משתמשת ב-instruct כאשר הסוכן יכול בבטחה לתקן את הקורס, ו-deny רק היכן שאפשר את הפעולה היא בלתי קבילה או בלתי הפיכה.

אמת את המקור בעורך ותקן כל שגיאה שדווחה.

4. תקדד וערך פרסום

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

fp policies publish checkout-guard ./checkout.policy.mjs --description "Block force-push"

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

כתוב זאת בעצמך

מדיניות היא JavaScript או TypeScript בעומת ה-API של failproofai:

import { customPolicies, allow, deny } from "failproofai";

customPolicies.add({
  name: "protect-production-paths",
  description: "Block writes to production configuration",
  match: { events: ["PreToolUse"] },
  fn: async (ctx) => {
    if (ctx.toolName !== "Write" && ctx.toolName !== "Edit") return allow();
    const path = String(ctx.toolInput?.file_path ?? "").replaceAll("\\", "/");
    if (path.split("/").includes("production")) {
      return deny("Writes to production configuration require approval.");
    }
    return allow();
  },
});

זה תואם production/config.yml, /srv/production/config.yml, /srv/production, ו-C:\\production\\config.yml עבור both Write ו-Edit, אך לא production-backup: production צריך להיות קטע נתיב שלם. הקשר גם נושא את סוג ההתרחשות, העומס הנורמלי, מטא נתוני תקופה, פרמטרים, וCLI מקור כשזמין — ראה את SDK מדיניות. כדי לפרסם זאת כגרסה, הדבק את המקור לתוך compose ב-Admin → policy editor ובצע שלבים 3 ו-4 לעיל, או פרסם את הקובץ מסוף עם fp policies publish. כדי להריץ אותו על מכונה ללא Cloud, שמור אותו תחת .failproofai/policies/ עם שם המסתיים ב-policies.js, policies.mjs או policies.ts — אלה טוענים באופן אוטומטי בתחום פרויקט ומשתמש — או התקן אותו לפי נתיב:

failproofai policies --install --custom ./security.policies.ts --scope project

תן לכל מדיניות שם שהוא ייחודי על פני כנס, מותאם אישית, חבילה, ומדיניות מנוהלת בענן.

Prevent repeat failures

Get a policy

Ship a policy

כתיבת מדיניות