كتابة سياسة

هناك طريقتان لكتابة سياسة: السماح لـ 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 جلسة موقعة (fp login) دورها لديه policies:write؛ يرفض مفاتيح API.

3. مراجعة المسودة

المسودة نقطة انطلاق وليست حكماً. قبل النشر، تحقق من أنها:

تسمي وضع الفشل باللغة التشغيلية.
تطابق فقط أحداث الخطاف والأدوات التي تحمل أدلة كافية للقرار.
تستخدم أضيق شرط يمسك الإجراء غير الآمن.
تعيد سبباً يخبر الوكيل ما يجب فعله بدلاً من ذلك.
تستخدم instruct حيث يمكن للوكيل تصحيح المسار بأمان، و deny فقط حيث السماح بالإجراء غير مقبول أو لا رجعة فيه.

تحقق من المصدر في المحرر وأصلح كل خطأ تم الإبلاغ عنه.

4. اختبره، ثم انشره

شغّل backtest تحت المصدر قبل النشر: يعيد تشغيل المسودة مقابل الاستدعاءات التي قامت بها أسطولك بالفعل ويحسب الاستدعاءات الفعالة التي كانت ستقاطعها. Test a policy يغطي ذلك والفحوصات الأخرى. عندما تتصرف بشكل صحيح، أدخل هوية السياسة واختر 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 لكل من Write و Edit، لكن ليس production-backup: يجب أن تكون production جزءاً كاملاً من المسار. السياق يحمل أيضاً نوع الحدث والحمول المُعاد تنسيقه وبيانات وصفية الجلسة والمعاملات والمصدر CLI عند توفره — انظر policy 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

أعط كل سياسة اسماً فريداً عبر الاتفاقية والسياسات المخصصة والحزمة والسياسات المدارة من قبل Cloud.

Prevent repeat failures

Get a policy

Ship a policy