release

リリース

リリースの準備と実施は、厳密なゲートの順序に従って行います。以下の各ステップについて TODO を 1 つずつ作成し、順番に進めてください。

停止ルール： いずれかのステップが失敗した場合は STOP してください。失敗した内容と残っている作業を正確に報告し、リポジトリは未リリースのままにします。部分的なリリースはありません。ビルドに合格する前にタグを付けない、存在しない成果物についてリリースノートを作らない、「タグ付け後に修正する」としないでください。

最終拒否と停止ルールの違い： 停止ルールに該当する失敗が発生した後、ユーザーに明示的な最終拒否を行うかどうかを一度だけ尋ねてください。はい → 必須サブスキル：record-decision を判定 release-reject、Boundary-Type: release、インラインの永続的な証拠とともに使用し、リポジトリは未リリースのままにします。いいえ／無回答／「後で修正する」→ 判定記録は作成しない（機械的な停止だけでは最終判定になりません）。ユーザーがバージョンまたはタグの承認時に拒否した場合も、同じ release-reject の引き継ぎを適用します。停止ルールの徹底に変更はありません。部分的なリリースはしないでください。

docs/agents/project.md からリポジトリのコマンドを確認してください（検証コマンド、リリース手順、スモークコマンド）。このファイルがない場合は、その旨を伝え、setup-repo を提案したうえで、作業を進める前にユーザーにコマンドを尋ねてください。

a. 検証ゲート

すべての検証コマンドを順番に実行してください。typecheck、lint、unit、e2e に加え、トレースチェックも実行します（必須サブスキル：trace を使用）。すべて、今回あらためて実行して合格する必要があります。以前の合格結果は認められません。トレースチェックはクリーンでなければなりません。実装済みの要件に対応するテストがない場合、その要件にはトレースがなく、トレースされていない要件がある場合はリリースできません。

完了条件： すべてのコマンドについて、今回実行した結果に合格し、その出力を確認していること。

b. 変更履歴の作成

最後のリリースタグ（git describe --tags --abbrev=0）を特定し、git log <last-tag>..HEAD の結果を収集します。コミットを要件 ID のトレーラー（Implements: CODE-N.M、Guards: CODE-N.M）ごとに分類します。記載された ID ごとに docs/specs/ から要件の文面を調べ、変更履歴の項目をコミットの説明ではなく、リリース済みの動作として記載してください（「モジュールの選択が起動後も保持される — SHELL-1.2」など）。Guards は「保護された動作」のグループにまとめます。トレーラーのないコミットは、そのまま Misc セクションに記載します。

以前のタグがない場合は、対象範囲が全履歴であることを伝えてください。

完了条件： 要件ごとに整理した変更履歴の草案を作成し、ユーザーに提示していること。

c. バージョン更新案の提示

変更履歴に基づき、セマンティックバージョニングの観点から判断します。公開されている動作の削除または変更 → メジャー、新しい要件のリリース → マイナー、修正とガードのみ → パッチ。判断理由と提案するバージョンを示してください。バージョン番号の承認者はユーザーです。 無回答のまま先に進まないでください。

完了条件： ユーザーが正確なバージョン文字列を承認していること。

d. バージョンファイルと変更履歴の更新

承認されたバージョンを、プロジェクトのバージョンファイル（マニフェスト、エコシステムで必要な場合はロックファイル、ハードコードされたバージョン定数など）に書き込み、変更履歴ファイルの先頭に項目を追加します。リポジトリに変更履歴ファイルがない場合は CHANGELOG.md を作成します。これらをまとめてコミットしてください。

完了条件： リリース用コミットが存在し、git status がクリーンであること。

e. ビルド

docs/agents/project.md に記載された順序どおりのリリース手順を、正確に実行してください。フラグを独自に追加したり、コマンドを別のものに置き換えたりしないでください。手順が不明瞭な場合は、停止ルールに基づき失敗とします。

完了条件： すべてのリリース手順を正常に実行し、成果物が存在していること。

f. 成果物のスモークチェック

ソースツリーではなく、ビルド済みの成果物を検証してください。プロジェクトでスモークコマンドが設定されている場合は実行します。設定されていない場合は、ユーザーと短い手動チェックリストを実施してください（成果物のインストールと起動、主要なフローの確認）。そのうえで、ユーザーから明示的な確認を得てください。

完了条件： スモークコマンドに合格しているか、ユーザーがチェックリストを確認済みであること。

g. タグ付けとプッシュ

ユーザーの明示的な承認を得た後に限り実行します（この承認がリリースに対する最終判定の成功となります）。

1. 必須サブスキル：判定 release-approve、Boundary-Type: release、Accountable depth の入力、およびバージョン／ビルド／スモークテスト／タグの承認をまとめたエビデンス行を指定して、record-decision を使用します（リリース全体で記録は1件のみとし、中間承認ごとに個別の記録を作成しないでください）。タグを作成する前に公開します。
2. 公開に失敗した場合：タグを作成またはプッシュせず、判定が実行されなかったことを報告します。
3. 成功した場合：タグを作成し（git tag <version>）、リリースコミットとタグをプッシュしてから、記録エンベロープに以下を追記します。 Execution-Outcome: tag <ref-name>@<object-id> pushed <UTC>.

**完了条件：**タグがリモートに存在し、リリース判定記録にそのタグが記載されていること（または、リリースがタグなしで明示的に却下／停止されていること）。

h. リリースノートの下書きを作成

変更履歴のエントリーを、トラッカーの形式に合わせてリリースノートにします（例：gh release create --draft、または手動公開用のノートファイル）。要件グループごとの構成を維持します。ユーザーから公開を依頼されない限り、リリースは下書きのままにします。

**完了条件：**下書きのノートが存在し、その URL またはパスをユーザーに伝えていること。

i. 仕様のステータスを更新

必須サブスキル：sync-spec を使用して、出荷済み機能の要件を Status: Shipped に変更し、docs/specs/INDEX.md を更新します。

**完了条件：**sync-spec の終了時のトレースレポートに問題がないこと。