release

release — 段階的な互換性とリリースワークフロー

Cull リポジトリでは $cull-release を使用してください。Cull のリポジトリで適用される状態、アーティファクト、アップデーター、Homebrew のゲートは、この汎用ワークフローよりも厳格です。

設定駆動型のリリースオーケストレーターです。処理の実装は scripts/release.py （単体テスト済み、標準ライブラリのみ）にあります。このファイルは、あなた（またはエージェント）が従うワークフローです。 release.config.json については reference/config-schema.md を、 各ステップの 理由 については reference/standards.md を読んでください。

適用範囲について: Tauri + Rust + SvelteKit のリポジトリ（Cull）で参照テスト済みです。 その他のスタックは 設定によって サポートされていますが、まだ検証されていません。信頼できるようになるまでは、新しいスタックでの初回実行はドライランとして扱ってください（下記「ドライラン」を参照）。

使用するタイミング

ユーザーが「リリース」「公開して」「バージョンを切って」「バージョンを上げて」「リリースにタグを付けて」「変更履歴／COMPATIBILITYを更新して」と言った場合です。リポジトリのルートに release.config.json が必要です（templates/release.config.json.tmpl を使ってひな形を作成してください）。

考え方 — 公開 API とは、宣言したサーフェスのことです

バージョンに意味が生まれるのは、何を引き続き動作させると約束するか を宣言してからです。release.config.json → surfaces[] がその宣言です。各サーフェスには ティア（experimental → preview → stable）と互換性の モード があります。約束を伴うのは stable サーフェスのみです。stable サーフェスを破壊的に変更すると、メジャー バージョンアップが必須になります。これはエンジンによって強制されます（規定については reference/standards.md を参照してください）。

コマンド

/release <patch|minor|major> — 以下の手順を実行します。慣れていないリポジトリでは、まず ドライラン を行ってください（下記を参照）。ユーザーが「説明して」と求めた場合は、各ステップの 理由 を reference/standards.md に基づく短い解説に広げてください。

手順

1. 前提条件。 設定された releaseBranch（デフォルトは main。worktree が設定されている場合はその中）がチェックアウトされ、クリーンで、origin と同期されていることを確認します。そうでない場合は、理由を明示して中止します。 — 理由：リリースタグは、正常でプッシュ済みのツリーを指している必要があります。

2. バージョン。 python3 scripts/release.py --config <cfg> plan <kind> を実行すると、新しいバージョンとタグが表示されます。バージョンファイルの現在の値が一致していることも検証されます。old → new を表示します。 — 理由：SemVer に基づく計算です。0.x ではマイナーバージョンで破壊的変更が可能です（1.0 未満）。 [[Semantic Versioning (SemVer)]]

3. リリース準備ゲート。 cfg.gate を実行し、続けて各 cfg.extraGate[] を実行します。すべて終了コード 0 でなければなりません（fmt、clippy、テスト、ライセンス監査、本番ビルド、ゴールデンコントラクトテスト）。失敗した場合は先に進みません。 — 理由：これは本番運用準備レビューです。 [[Production Readiness Review]]

   • TODO（延期）：cargo-deny / cargo-audit / SBOM。現時点では一覧に記載するだけで、必須にはしません。

4. 変更履歴。 最後のタグ以降のコミットの件名（git log <lastTag>..HEAD --format=%s）を収集して、セクションの草案を作成します — エンジンの draft_changelog がコミットを Added／Changed／Fixed に分類します（Keep a Changelog）。CHANGELOG.md の先頭に挿入し、ユーザー向けの記述は手作業で精査します。 — 理由：変更履歴を読むのは人間であり、Conventional Commits はその下地になります。 [[Keep a Changelog]]

5. 互換性レビュー。 cfg.compatibility.path（COMPATIBILITY.md）を開いて、以下を確認します。

   • サーフェスのティアに変更がありましたか？（Surfaces テーブルを更新します）
   • 新たな非推奨項目はありますか？（項目／非推奨となるバージョン／削除可能となるバージョン／代替手段の行を追加します）
   • この変更は stable サーフェスを破壊しますか？ その場合、必要なバージョン更新は major です — major で再実行するか、リリースは無効になります。（enforce_bump で強制されます。）「Last updated: ()」を記載します。 — 理由：ティアと非推奨期間があれば、誤解を招かずに進化させることができます。 [[Kubernetes API Deprecation Policy]]

6. バージョン更新とコミット。 python3 scripts/release.py --config <cfg> bump <kind> を実行して、すべてのバージョンファイルを書き換えます。cfg.lockfiles を更新します（例：cargo update -p <crate> を実行するか、ビルドします）。CHANGELOG と COMPATIBILITY を含めて chore(release): v<new> としてコミットします。

7. タグ付けとプッシュ。 git tag v<new> を実行してタグ（→リポジトリのリリースワークフロー）とブランチをプッシュします。最初のリリース前に、タグのトリガーが存在することを確認します（grep -A3 '^on:' .github/workflows/*.yml）。

8. 報告。 タグ、リリースワークフローの URL、最後のタグ以降にクローズされたイシュー（cfg.issueTracker が設定されている場合。例：bd）を出力します — これらがリリースノートになります。

ドライラン

--dry-run フラグはありません — ドライランでは、何も変更せずに手順 1～5 を行います。 python3 scripts/release.py --config <cfg> plan <kind> を実行します（副作用なし：バージョンとタグを表示し、何も書き込みません）。準備状況を確認するために、必要に応じて cfg.gate も実行します。 bump、コミット、タグ付けは実行しないでください。書き込みを行うエンジンのコマンドは bump サブコマンドだけです（バージョンファイルのみ）。コミット、タグ付け、プッシュは手順 6～7 で行う Git の操作であり、エンジンの操作ではありません。

コントラクトとモードへの拡張

リリース準備ゲートでは、ゴールデン／コントラクトテスト（cfg.extraGate）を実行します。まずは 1 つ（DB のラウンドトリップ）から始め、その後エクスポートと API のコントラクトテストを追加します。利用側のリポジトリにある docs/CONTRACTS.md と reference/standards.md を参照してください。 [[Pact — Consumer-Driven Contract Testing]]