cut-release

リリースの作成

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

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

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

docs/agents/project.md からリポジトリのコマンドを読み取ってください（検証コマンド、リリース手順、スモークコマンド）。ファイルがない場合は、その旨を伝えて configure-repo を提案し、続行する前にユーザーにコマンドを尋ねてください。

a. 主張の証明ゲート

すべての検証コマンドを順番に実行してください。typecheck、lint、unit、e2e に加え、ドキュメント専用の audit-trace チェックも行います（必須サブスキル：audit-trace を使用）。すべてのチェックは、今回新たに実行して成功する必要があります。過去の成功結果は認められません。audit-trace チェックでは、ドキュメントの整合性（不明なタスクの引用、定義の重複など）がクリーンでなければなりません。要件 ID についてテストを grep するチェックではありません。

完了条件： すべてのコマンドを今回実行して成功し、その出力を確認していること。

b. リリース対象セット、その後に変更履歴

リリースノートの草案を作成したり、バージョンを提案したりする前に分類してください。HEAD にタグを付けると、その範囲内でマージされたすべての機能のコードがリリースされます。Status: がまだ Approved または In-progress のままなら、それは実態に即していません。このステップで停止し、ステップ i には進みません。

手順 — 実行して結果を確認してください：

1. last=$(git describe --tags --abbrev=0 2>/dev/null) — タグがない場合は、履歴全体が対象範囲です。その旨を伝えてください。
2. git diff --name-only ${last:+$last..}HEAD と git log ${last:+$last..}HEAD --oneline。
3. 変更されたパスを docs/specs/INDEX.md の機能に対応付けます（仕様ディレクトリのプレフィックスまたは **Files:** の所有関係を使用）。このリストが対象範囲の機能セットです。
4. 各機能について、その requirements.md の Status: を読み取ります（ファイルに該当行がない場合は INDEX の行を使用）。次のように分類します。
   • Implemented → 今回の対象（このリリースで対象に含め、後でステータスを更新します）
   • Shipped → リリース済み（対象範囲に変更が含まれる場合は変更履歴を追記し、ステータスは変更しません）
   • Approved、In-progress、Draft、またはステータスなし → ブロッカー

ブロッカーがある場合： このステップは失敗です。停止してください。各ブロッカーとその Status: を列挙します。バージョンを提案しないでください。タグを付けないでください。realign-spec を実行しないでください。各ブロッカーは、まず Implemented にする必要があると伝えてください（その機能に対して realign-spec を実行します。引き続きブランチで作業中の場合は、land-branch の forget-net を使用します）。その後 /cut-release を再実行します。SHELL／BILLING も、残りの対象機能と同様に待機します。

ブロッカーがない場合： 今回の対象（および追記対象のリリース済み機能）から変更履歴の草案を作成します。requirements.md の現在の要件文を引用し、必要に応じて括弧内に CODE を記載します。残りのコミット件名は Misc にまとめます。Implements:／Guards: のトレーラーを必須にしたり、解析したりしないでください。

完了条件： 停止対象の一覧がユーザーに提示されているか、今回の対象機能に基づく変更履歴の草案が作成され、提示されていること。

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

変更履歴に基づき、セマンティックバージョニングの観点から判断します。公開動作の削除または変更 → major、新しい要件のリリース → minor、修正とガードのみ → patch。理由と提案するバージョンを伝えてください。バージョン番号の承認はユーザーが行います。返答がないまま先に進んではいけません。

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

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

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

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

e. ビルド

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

任意のデプロイに関する説明： docs/ops/deployment.md については、 skills/project/define-system-doc/consult-recipe.md に 説明文のみ従ってください。docs/agents/project.md の実行可能なリリースコマンドを置き換えたり、上書きしたりしてはなりません。重要な場合は一度だけ提案し、自動的に呼び出してはなりません。

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

f. 成果物のスモークテスト

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

完了条件： スモークテスト用コマンドが成功するか、ユーザーがチェックリストを確認済みであること。

g. タグ付けとプッシュ

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

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

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

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

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

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

i. 仕様のステータスを切り替える

コホートとは、手順 b で記録した「実装済み」リストです。同じ対象を使用し、再調査は行いません。コホート内の各機能について、該当する requirements.md と、対応する docs/specs/INDEX.md の行に Status: Shipped と記入します。コミットは1つです。

realign-spec を呼び出してはなりません。このスキルは、コホートの Implemented → Shipped を担当します。realign-spec はずれた3項組を1つ整合させるものであり、リリースの確定には使いません。

「忘れないように常に realign-spec を実行する」「仕様の事務作業は省略する」「INDEX を読む人はいない」「タグ付けが本番の作業だ」という理由は、この手順を省略する理由にはならず、ステータスの切り替えを realign-spec に任せる理由にもなりません。

続いて、docs/agents/issue-tracker.md にトラッカーの記載がある場合は、コホートのチケットを更新します。範囲内でマージされた PR がチケットをクローズした場合、そのチケットはこのリリースカットに属します。範囲内のマージコミットと PR 本文で、クローズキーワード（Closes #N）を使ってチケットが指定されています。該当する各チケットについて、状態の役割を shipped に切り替え（docs/agents/triage-labels.md）、トラッカーの運用手順に従って Shipped in v<version> とコメントします。3回のベースラインリリースではタグ v0.5.0 が付けられた一方、クローズ済みの #23 は status:in-review のままでした。そのため、ボードではマージ済みとリリース済みを区別できませんでした。

完了条件： コホート内のすべての機能について、ファイルと INDEX の両方で Shipped になっており、範囲内でクローズされたすべてのチケットが shipped になっていること（または、手順 b ですでにリリースカットが停止されていること）。

危険信号 — 絶対にしない

• range-set 機能のいずれかが Approved、In-progress、Draft、または Status: がない状態のままタグを付ける
• このスキルから realign-spec を実行する
• ブロッカー（Approved／In-progress／Draft）を Shipped に変更する
• タグが存在する、またはリードからステータスは後回しでよいと言われたという理由で、ステップ i を省略する
• Approved または In-progress の作業を、出荷済みの動作として変更履歴に記載する

考え	実際
「AUTH は Approved だけです。タグ付けの後にステップ i として realign します」	手遅れです。コードはタグに含まれています。ステップ b はバージョン／タグの前に止めます。
「コードはすでに main にあるので、すべて出荷済みです」	main にあることは、取り込み済みということです。このスキルは Implemented の仕様をひとまとまりにしてタグ付けします。
「必須サブスキルの realign-spec を使えば Shipped に変更できます」	もう違います。ステップ i は Status／INDEX の編集です。realign-spec は機能ごとの劣化防止に使います。
「忘れないよう、常に realign-spec を実行します」	常に磨き上げるのと同じです。Implemented のまとまった一群を、機械的に変更します。
「仕様書の手続きを省略しましょう／INDEX は誰も読みません／これで終わりです」	ステップ i はゲートです。タグ付けは手順の終わりではありません。
「5 分後にスタンドアップがあります。とにかく切って、すべて変更しましょう」	時間やリードの指示があっても、ステップ b のブロッカー一覧は省略できません。
「AUTH を Approved から Shipped に変更しましょう。リリースが証拠です」	Shipped にするには、まず Implemented が必要です。ブロッカーはブロッカーのままです。