failproofai publish は、指定されたポリシーファイルからこれら3つのファイルをすべて生成し、リリースを作成してアップロードします。
1. ポリシーを作成する
空白のテンプレートではなく、すでに機能しているものから始めましょう：<name>.mjs を作成して終了します — ネットワーク接続も、gitも、公開も一切行いません。作成されるファイルには git push --force をブロックするポリシーが1つ含まれています。既存のファイルは上書きしません。
ポリシーは、カスタムポリシーと同じAPIを使用します。パック向けに重要な追加フィールドが2つあります：
defaultEnabled を省略すると、デフォルトで false になります。単純な failproofai policies add は、マークしたポリシーのみを有効化します — 見知らぬ人のすべてのポリシーを無人でインストールするかどうかは、インストーラーがユーザーの代わりに決めるべき判断ではありません。
ファイルはいくつでも作成できます。カテゴリごとに1ファイルにすると読みやすくなります。ポリシーを登録するディレクトリ内のすべてのファイルは、パックが持つべき単一のアーティファクトにバンドルされます。
2. まずここで試す
他の人が確認できるようになる前に、このマシンでファイルを強制適用します：3. 公開する
- ファイル名ではなく コンテンツ でポリシーファイルを検索します —
failproofaiをインポートしてcustomPolicies.addを呼び出しているものを対象にするため、guards.mjsは検出されますが、無関係なpolicies.mjsは無視されます。サブディレクトリには降りないため、テストフィクスチャが誤って含まれることはありません。 - ファイルの ディレクトリ（作業ディレクトリではなく）で
git remote get-url originからリポジトリを読み取り、バージョンを決定します。 - 認証情報を検索します：
GITHUB_TOKEN、GH_TOKEN、またはgh auth login。release-write 権限のみ必要で、表示されることはありません。 - リポジトリが存在しない場合は作成します。これはビルド前に行われるため、次のステップで拒否されたパックは、リリースのない新しいリポジトリを残す可能性があります。
- 3つのアセットをビルドし、ローダー自身のルール — 見知らぬマシンにインストールできるものを決定するのと同じコード — で検証します。そのため、インストールできないパックはここで失敗し、まだ修正できます。
- リリースを作成または再利用してアップロードし、同名のアセットは置き換えます。
アセット名は固定です — これはコンシューマーのCLIがAPIコールや探索なしにURLを構築するために使用するものだからです。
ビルド時に拒否されるもの：
publisher/name 形式でないid、/ を含むポリシー名、alwaysOn を宣言するポリシー、description・category・match のいずれかが欠けているポリシー、何も登録しないエントリ、ローカルファイルをインポートするエントリ。
自動判断した内容を上書きするには：
--id はリポジトリと異なる場合にパックidを設定し、--tag はリリースのタグを設定します。--notes は自動生成されたリリースノートを置き換えます（policies show --releases が各リリースのカウントとコミットを読み取る場所）。--out はアセットの出力先を指定し（デフォルトは dist-pack）、--dry-run は公開せずにビルドのみ行い、認証情報は不要です。
これで failproofai policies add acme/support-agent を使って誰でもインストールできるようになります。バージョンのピン留めや一部のみのインストールについては、ポリシーパックを参照してください。
ポリシーハブに登録する
GitHubのリポジトリにfailproofai-policies トピックを追加してください。申請フォームも承認キューもありません：ポリシーハブのクローラーが次回のパスでリポジトリを検出します。トピックは掲載の候補に挙げるだけです — 実際に掲載されるのは、マニフェストが自身の SHA256SUMS に対して検証され、CLIが使用するのと同じルールでパースされるリリースが存在する場合で、それはまさに failproofai publish が生成するものです。
バージョンの決定方法
バージョンは 公開元のコミット — 12文字の短縮sha：a1b2c3d4e5f6 です。選択するものも、インクリメントするものも何もありません。バージョンはバイトがどこから来たかを正確に示すため、同じソースを2回公開すると同じバージョンになります。
バージョンはリポジトリのリリースからではなく、目の前のツリーから読み取られるため、フレッシュなクローンとエアギャップ環境のマシンは、GitHubに何があったかを尋ねることなく同じ答えを計算します。
バージョンはコミットを指しているため、そのコミットが存在する必要があります。ターミナルでは、publish が代わりにコミットを作成します：リポジトリがない場合は初期化し、変更されたポリシーファイルをビルド前にコミットします。ターミナルなしで実行された場合（CIランナーで作成されたコミットは他の場所には存在しない）、ポリシー以外のファイルがコミットされていない場合、またはまだコミットがないチェックアウトでは、拒否 します — --version が回避策として案内されます。HEAD にタグがある場合はshaよりタグが優先されます — v1.2.0 とタグを付けた人はこのリリースが何であるかを宣言しています。
shaにはそれ自体の順序付けがないため、failproofai policies show <owner>/<repo> --releases を使用して、どのリリースが先かを確認してください — 最新が上に表示されます。
新しいバージョンを配布する
変更をコミットしてfailproofai publish を再実行してください — 新しいコミットが新しいバージョンになります。コンシューマーは同じ failproofai policies add を実行します。ターミナルなし、または選択フラグがある場合、選択したサブセットが保持され、無効にしたポリシーはオフのままです。ターミナルありでフラグなしの場合、ピッカーがデフォルト設定でチェック済みの状態で開き、選択した内容が以前の選択を置き換えます。
ポリシーの 名前 を変更することは破壊的変更です：無効にしていたマシンは存在しない名前をオフにしていることになり、新しい名前は defaultEnabled の設定で有効化されます。
ユーザーが信頼しているもの
SHA256SUMS はアーティファクトと同じリリースに存在するため、バイトが公開したものであることを証明しますが、あなたが誰であるかは証明しません。リポジトリへの書き込み権限を持つ人は誰でも両方のファイルを書き換えられます。ユーザーの保護は、インストール時にダイジェストがピン留めされることで、配布後に内容を変更できなくなることです。
書き込みアクセスを管理しているリポジトリから公開し、パックのリリースはパッケージの公開と同様に扱ってください。
リポジトリは 公開 されている必要があります。インストールは認証情報のない匿名HTTPSで行われるため、既存のプライベートリポジトリはビルドやアップロード前に拒否され、publish が作成するリポジトリも同じ理由で公開されます。--allow-private は、3つのアセットを別の方法で渡す場合に上書きできますが、policies add ではアクセスできないことを明示します。重要なのはリリースのみです：インストールは releases/download/<tag>/<asset> を読み取り、gitツリーには一切アクセスしません。
強制適用前にオブザーブする
マニフェストは"effect": "observe" を宣言できます — failproofai publish --effect observe で設定します。これらのポリシーは実行され、その判定は 記録されますが破棄されます — 何もブロックされません。誰かの作業を妨げる前に、実際のトラフィックに対して新しいルールを測定する方法です。