Publish a pack - Failproof AI

title: “एक पैक प्रकाशित करें” description: “GitHub रिलीज़ के रूप में अपनी नीतियों को शिप करें जिन्हें कोई भी इंस्टॉल कर सके।” icon: “upload”

एक पैक GitHub रिलीज़ से जुड़ी तीन फाइलें हैं। failproofai pack build एक नीति फाइल से सभी तीन को लिखता है जो आपके पास पहले से है।

1. नीतियां लिखें

एक फाइल, किसी भी कस्टम नीति के समान API का उपयोग करते हुए। एक पैक के लिए दो अतिरिक्त फील्ड महत्वपूर्ण हैं:

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`	मेनिफेस्ट: id, version, effect, और प्रति नीति एक प्रविष्टि
`failproofai-pack.mjs`	आपकी प्रविष्टि, ज्यों की त्यों
`SHA256SUMS`	`<sha256> <filename>` अन्य दोनों के लिए

बिल्ड समय पर अस्वीकृत: एक id जो 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 अपने URLs से बनाती है, कोई API कॉल नहीं और कोई खोज नहीं।

एक नया संस्करण शिप करना

नए --version के साथ बनाएं, एक नई रिलीज़ टैग करें, तीनों संपत्ति को फिर से जोड़ें। उपभोक्ता एक ही pack add चलाते हैं और जो भी सबसेट उन्होंने चुना था उसे रखते हैं; एक नीति जिसे वे बंद कर गए थे वह अपग्रेड में बंद रहती है। एक नीति के name को बदलना एक विघ्नकारी परिवर्तन है: एक मशीन जिसने इसे बंद कर दिया था वह एक नाम बंद कर रही है जो अब मौजूद नहीं है, और नया नाम जो कुछ भी defaultEnabled कहता है उस पर आता है।

आपके उपयोगकर्ता क्या विश्वास कर रहे हैं

SHA256SUMS उसी रिलीज़ में है जो कलाकृति है, इसलिए यह साबित करता है कि बाइट्स वे हैं जो आपने प्रकाशित किए — न कि आप कौन हैं। जो कोई भी रिपॉजिटरी में लिख सकता है वह दोनों फाइलें लिख सकता है। आपके उपयोगकर्ताओं की सुरक्षा यह है कि डाइजेस्ट तब पिन किया जाता है जब वे इंस्टॉल करते हैं, इसलिए जो आपने शिप किया वह उनके बाद नहीं बदल सकता। एक रिपॉजिटरी से प्रकाशित करें जिसके लिखने की पहुंच आप नियंत्रित करते हैं, और एक पैक रिलीज़ को एक पैकेज प्रकाशित करने जैसे मानें।

लागू करने से पहले अवलोकन करें

एक मेनिफेस्ट "effect": "observe" घोषित कर सकता है। वे नीतियां चलती हैं और उनके निर्णय रिकॉर्ड किए जाते हैं और त्याग दिए जाते हैं — कुछ भी ब्लॉक नहीं है। यह एक नए नियम को वास्तविक ट्रैफिक के खिलाफ मापने का तरीका है इससे पहले कि यह किसी के काम को बाधित कर सके।

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

​1. नीतियां लिखें

​2. रिलीज़ संपत्ति बनाएं

​3. उन्हें एक रिलीज़ से जोड़ें

​एक नया संस्करण शिप करना

​आपके उपयोगकर्ता क्या विश्वास कर रहे हैं

​लागू करने से पहले अवलोकन करें