リリースする¶
このページでは、実装と検証まで終えた Milestone を、1 つのリリースとして締めるまでを説明します。SpecBind でのリリースは「Milestone 全体を出すか、出さないか」で、一部の Spec だけを切り出す方法はありません。
用語について
用語（ Milestone、Spec、Gate、完了を裏付ける記録など）は基本概念 にまとめています。
いつリリースするか¶
次がそろっていることが前提です。
- 参加する全 Spec が Implement と
sb-validate-implementationを終え、CLI が 完了を裏付ける記録（ completion evidence ）を受理している （specbind milestone statusで確認できます） - この Milestone を実際に出すと決めている
まだ試用の段階なら、無理にリリースまで進める必要はありません。実装の検証までを完了地点にして、次の Milestone の Discovery へ進んでもかまいません。
1. リリース方針を用意する¶
準備・公開・検証・後片付けをどう行うかは、プロジェクト固有の
.specbind/settings/adapters/release.md（リリースアダプター）に自然言語で書きます。
CLI も SpecBind も、この手順を代行しません。
- 未設定のまま
sb-releaseを実行した場合 — スキルがリポジトリ内の リリース用ワークフロー、バージョンマニフェスト、ビルドスクリプト、既存のRELEASE/CHANGELOGなどを調べ、Prepare （準備）・ Publish （公開）・ Verify （検証）・ After-finalize （確定後処理）の 具体案を提示します。承認するとその案をrelease.mdへ保存してローカルコミットし、 その回はそこで停止します（バージョンの紐付けも公開もしません）。 - 設定を変更したあと —
release.mdの保存は通常のプロジェクト変更なので、 完了を裏付ける記録を受理済みの Spec は、それぞれ完了処理のやり直しが必要に なります。やり直してから、改めてsb-releaseを実行します。 - プロジェクト固有の作業が本当に不要なら — Front Matter を残して本文を空に すると、「リリースに固有の手順は不要」という明示になります。
書き方の詳細はカスタマイズのアダプターの節にあります。
2. sb-release を実行する¶
リリースの操作は、基本的にこのスキル 1 つで進みます。バージョンの紐付けから確定処理までスキルがオーケストレーションし、状態の変更はすべてスキル経由で CLI が行います。あなたは要所の確認に答えます。以下は、スキルが内部で進める流れです。
バージョンの紐付け¶
リリースのラベルは不透明で、大文字小文字も区別します（v1.4.0と1.4.0は別のリリース）。スキルはこの値を自動で決めず、必ず尋ねます。指定すると Milestone へ
target_releaseが書き込まれます。
target_releaseだけの紐付けまたは明示的な再紐付けは、完了記録の鮮度を保つライフサイクルのメタデータ変更です。ある Spec がすでにrelease_readyでも、その完了を裏付ける記録は古くならず、完了処理をやり直す必要はありません。Roadmap のスコープや本文、プロジェクト内のバージョンファイルなどを同時に変えた場合は、この例外にはなりません。
紐付け後の Roadmap は通常の Git 変更なので、スキルは Git アダプターに従ってこの 1 ファイルだけをチェックポイントとしてコミットしてから事前検査へ進みます。Git アダプターがコミットを許可していない場合は、完了を裏付ける記録を保ったままそこで停止し、未コミットの変更がないチェックポイントが必要だと報告します。
事前検査 / Prepare / Publish / Verify¶
スキルはまず前提を確認し（この検査が失敗した回は、そこで止まります）、通ったらアダプターに書いた手順を順に実行します。
- Prepare — 繰り返し可能でローカルに閉じた準備。失敗したらそこで報告し、 リポジトリの外には何も出ていません。
- Publish — リリースの識別子を確定させる、または外部に出る境界です。ローカル タグでも、デプロイやアップロードでも、スキルは「何をどのバージョンに対して 行うか」を述べて確認を取ってから実行します。広い指示で始めた場合でも、公開は 別に確認します。
- Verify — 「意図したバージョンが実際に公開され、使える」ことを、公開コマンドの 出力の読み直しではなく、新しい証拠で確かめます。確かめる手段がない場合は 「検証できない」であって、成功ではありません。この場合は確定処理を行いません。
Publish は成功したが Verify が通らなかったときは、Milestone は進行中のまま、SpecBind の成果物もそのままです。公開のロールバックや盲目的な再試行はせず、現状を報告してどう扱うかを相談します。
確定処理¶
Verify まで通ったら、参加する各 Spec の成果（要求ではなく、実際に届けたもの）を 1 行で要約し、スキルが Milestone 全体の確定処理を CLI に指示します。log.mdは CLI が構造ごと更新するので、手で先に編集しないでください。失敗しても再実行でき、履歴は重複しません。
3. 確定処理の後¶
- Roadmap は CLI によってリリースアーカイブへ移ります。各 Spec はリリース後も残り、次の
変更の出発点として待機状態（
idle）に戻ります log.mdにこの Milestone の記録が追加されます- Milestone はクローズされ、次の
sb-discoveryが新しい Milestone を開始できます git.mdに方針があれば、確定処理が生成したログ・アーカイブ・後片付けは、公開対象とは 別のローカルコミットになります
この Milestone で新規 Spec を追加した、Contract が動いた、あるいはまだ Steering が 1 つもない状態でリリースした場合は、sb-steeringを一度回しておくとよいです。
確定処理の後は Steering の編集がふたたび自由になります。
現在の状態を確認する¶
スキルを呼ぶ前に、自分でリリースの準備状況を見ておけます。どちらも読み取り専用です。
specbind milestone status # 対象リリース、リリースを妨げる問題を表示
specbind release preflight # 未紐付けや未受理の完了記録など、残っている障害を表示