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، description أو 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. أرفقها بإصدار

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

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

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