Publish a pack - Failproof AI

title: “نشر حزمة” description: “شحن سياساتك الخاصة كإصدار GitHub يمكن لأي شخص تثبيته.” icon: “upload”

الحزمة عبارة عن ثلاثة ملفات مرفقة بإصدار GitHub. يكتب failproofai pack build جميع الثلاثة من ملف سياسة لديك بالفعل.

1. اكتب السياسات

ملف واحد، يستخدم نفس الواجهة البرمجية لأي سياسة مخصصة. يهمان حقلان إضافيان للحزمة:

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

customPolicies.add({
  name: "block-refunds",
  description: "Refunds above the approved limit need a human",
  category: "Billing",        // groups it, and is what --category selects on
  defaultEnabled: true,       // switched on by a plain `pack add`
  match: { events: ["PreToolUse"], tools: ["Bash"] },
  fn: async (ctx) =>
    String(ctx.toolInput?.command ?? "").includes("refund")
      ? deny("Refunds need a human. Ask before running this.")
      : allow(),
});

يتم تعيين defaultEnabled افتراضيًا إلى false عند حذفه. failproofai pack add البسيط يقوم بتشغيل فقط ما حددته — تثبيت كل سياسة من سياسات الغريب دون مراقبة ليست قرارًا يجب على المثبت أن يتخذه للمستخدم.

يجب أن يكون الإدخال ملف واحد مكتفٍ بذاته. فقط الإدخال هو ما يتم تثبيت الخلاصة عليه، لذا فإن حزمة تستورد ملفات محلية لا يمكنها بصراحة المطالبة بأن الخلاصة تغطي ما يعمل. قم بالدمج أولاً (esbuild أو bun build أو rollup) وأنشئ الحزمة من الحزمة المدمجة — يرفض pack build الاستيراد المحلي بدلاً من شحن وعد لا يمكنه الوفاء به.

2. بناء أصول الإصدار

failproofai pack build ./policies.mjs \
  --id acme/support-agent \
  --version 1.0.0 \
  --out ./dist-pack

يكتب ثلاثة ملفات ويتحقق من صحة كل سياسة باستخدام قواعد المُحمِّل الخاصة أولاً — لذا فإن الحزمة التي لن تتمكن من التثبيت تفشل هنا، حيث يمكنك إصلاحها:

الملف	ما هو
`failproofai-pack.json`	البيان: المعرّف والإصدار والتأثير وإدخال واحد لكل سياسة
`failproofai-pack.mjs`	إدخالك، كما هو حرفيًا
`SHA256SUMS`	`<sha256> <filename>` للملفين الآخرين

تم الرفض عند وقت البناء: معرف ليس publisher/name، اسم سياسة يحتوي على /، سياسة تعلن alwaysOn، وصف مفقود أو category أو match، إدخال لا يسجل أي شيء، وإدخال يستورد ملفات محلية.

3. أرفقها بإصدار

ضع علامة على الإصدار بنفس الإصدار الذي أنشأته، وأرفق جميع الملفات الثلاثة كأصول الإصدار:

gh release create 1.0.0 \
  ./dist-pack/failproofai-pack.json \
  ./dist-pack/failproofai-pack.mjs \
  ./dist-pack/SHA256SUMS

يمكن لأي شخص الآن تثبيته:

failproofai pack add acme/support-agent

أسماء الأصول ثابتة — وهي ما ينشئها CLI الخاص بالمستهلك من عناوين URL الخاصة به، بدون استدعاء API وبدون اكتشاف.

شحن إصدار جديد

قم بالبناء باستخدام --version الجديد، وضع علامة على إصدار جديد، وأرفق الأصول الثلاثة مرة أخرى. يقوم المستهلكون بتشغيل نفس pack add والاحتفاظ بأي مجموعة اختاروها؛ تبقى السياسة التي أطفأوها مطفأة عبر الترقية. تغيير اسم السياسة هو تغيير كسر: جهاز قام بإيقاف تشغيله يقوم بإيقاف تشغيل اسم لم يعد موجودًا، والاسم الجديد يصل إلى أيًا كان defaultEnabled يقول.

ما يثق به المستخدمون

SHA256SUMS يعيش في نفس الإصدار مثل الأصل، لذا فإنه يثبت أن البايتات هي تلك التي نشرتها — وليس من أنت. أي شخص يمكنه الكتابة إلى المستودع يمكنه كتابة كلا الملفين. حماية المستخدمين هي أن الخلاصة يتم تثبيتها عند التثبيت، بحيث لا يمكن لما شحنته أن يتغير تحتهم بعد ذلك. قم بالنشر من مستودع يمكنك التحكم في الوصول الكتابي إليه، وتعامل مع إصدار حزمة مثل نشر حزمة.

راقب قبل أن تفرض

قد يعلن البيان عن "effect": "observe". تعمل تلك السياسات وتُسجل أحكامها وتُرفض — لا شيء محجوب. إنها الطريقة لقياس قاعدة جديدة مقابل حركة المرور الحقيقية قبل أن تتمكن من مقاطعة عمل أي شخص.

{ "id": "acme/support-agent", "version": "1.1.0", "effect": "observe", "policies": [ ... ] }

​title: “نشر حزمة” description: “شحن سياساتك الخاصة كإصدار GitHub يمكن لأي شخص تثبيته.” icon: “upload”

​1. اكتب السياسات

​2. بناء أصول الإصدار

​3. أرفقها بإصدار

​شحن إصدار جديد

​ما يثق به المستخدمون

​راقب قبل أن تفرض