Skip to main content
一个规则包由附加在 GitHub 发布版本上的三个文件组成。failproofai pack build 会从你已有的策略文件中生成这三个文件。

​
1. 编写策略

使用与自定义策略相同的 API，只需一个文件。规则包还有两个额外的重要字段：
省略 defaultEnabled 时，默认值为 false。执行 failproofai pack add 时，只会启用你标记为开启的策略——在无人值守的情况下自动安装陌生人的所有策略，不应由工具替用户做出这个决定。
入口文件必须是一个完全自包含的文件。只有入口文件会被摘要锁定，因此如果规则包引用了本地文件，就无法真实声称摘要覆盖了实际运行的内容。请先打包（使用 esbuild、bun build 或 rollup），然后再从打包产物构建规则包——pack build 会拒绝含有本地导入的文件，而不是发布一个无法兑现的承诺。

​
2. 构建发布资产

该命令会生成三个文件，并首先用加载器自身的规则验证每条策略——这样，无法安装的规则包会在此处失败，方便你及时修复： 以下情况会在构建时被拒绝：id 格式不为 publisher/name、策略名称包含 /、策略声明了 alwaysOn、缺少 description、category 或 match、入口文件未注册任何策略，以及入口文件引用了本地文件。

​
3. 将文件附加到发布版本

使用与构建时相同的版本号打标签，并将三个文件作为发布资产附加上去：
任何人现在都可以安装它：
资产文件名是固定的——这正是消费者的 CLI 构建 URL 的依据，无需任何 API 调用或服务发现。

​
发布新版本

使用新的 --version 构建，打一个新标签，再次附加三个资产文件。用户执行相同的 pack add 命令即可升级，已选择的策略子集保持不变；被关闭的策略在升级后仍保持关闭状态。 修改策略的名称是破坏性变更：曾将某个策略关闭的用户，关闭的是一个已不存在的名称，而新名称会按照 defaultEnabled 的设定启用。

​
你的用户在信任什么

SHA256SUMS 与产物文件存放在同一个发布版本中，因此它能证明字节内容正是你所发布的——但无法证明你是谁。任何拥有仓库写入权限的人都可以同时修改这两个文件。用户的保障在于：摘要在安装时被锁定，因此你所发布的内容此后不会在用户不知情的情况下被篡改。 请从你掌控写入权限的仓库发布，并像对待发布软件包一样对待规则包的发布。

​
先观察，再执行

清单可以声明 "effect": "observe"。这些策略会正常运行，但其判决结果仅被记录，随后丢弃——不会阻止任何操作。这是在新规则真正拦截任何人的工作之前，用真实流量衡量其效果的方式。