release

release - バージョニング段階

不変条件

• マージ済みの Ready To Ship タスクのみリリースします。
• 最後まで確認します： タスクを Shipped に移動するのは、PR／テストレポートに記載されたデプロイ後のチェックを本番システムに対して実行し、その結果をテストレポートに記録した場合、またはユーザーがそのタスクについて明示的に免除した場合に限ります。マージ済みであることと、動作していることは同じではありません。
• 変更履歴の項目はユーザー向けに記述します。
• 未マージのプルリクエストは含めません。
• ユーザーの明示的な承認なしに、既存のタグを書き換えないでください。
• リリース項目を Shipped に移動した後、TASKS.md を読み直し、各行が Ready To Ship から移動済みであることを確認します。トラッカーが古いままだと、後続の作業やヘッドレスセッションがブロックされます。

ランタイムアダプターでは、この段階をスラッシュコマンド、メニューアクション、または自然言語によるスキル呼び出しとして公開できます。移植可能な段階名は release です。

呼び出し方法

サポートされているバージョン入力：

• auto または引数なし：タスクの Version Impact から導出します
• patch
• minor
• major
• v1.2.3 のような明示的なバージョン

ワークフロー

1. AGENTS.md を読みます。
2. TASKS.md を読み、マージ済みの Ready To Ship 項目を探します。
3. 各タスクのドキュメントを読み、種類、バージョンへの影響、概要を確認します。
4. 各タスクについて、デプロイ後のチェックが実行され、記録されていること（またはユーザーによって免除されていること）を確認します。チェックが未完了のタスクは Ready To Ship に残し、未完了のチェックとともに引き継ぎに記載します。
5. 次のバージョンを決定します。
6. docs/changelogs/CHANGELOG.md を生成または更新します。
7. リポジトリのワークフローでリリースコミットが必要な場合は、変更履歴の変更をコミットします。
8. 適切な場合は Git タグを作成します。
9. 適切な場合は、利用可能なリポジトリホスティングツールを使ってリリースノートを作成します。
10. リリース項目を TASKS.md の Shipped に移動し、各行を Ready To Ship から削除します。
11. TASKS.md を読み直し、リリースしたタスクの行が Shipped にあり、Ready To Ship にはないことを確認します。行が期待されるセクションにない場合は、移動漏れです。引き継ぎの前に編集を行ってください。

バージョンの計算

シグナル	バージョンへの影響
破壊的変更または必須のユーザー移行	major
新機能	minor
バグ修正、ドキュメント、雑務、小規模な機能強化	patch

複数のタスクをまとめてリリースする場合は、最も高い影響度を適用します。

変更履歴テンプレート

## [v{version}] - {Date}

### New Features
- {User-facing feature}

### Fixes
- {Bug fix}

### Improvements
- {Enhancement}

### Documentation
- {Documentation update}

### Breaking Changes
- {Required migration, if any}

引き継ぎ

Release prepared: v{version}
Tasks shipped: {IDs}
Held (post-deploy checks pending): {IDs or "None"}
Changelog: docs/changelogs/CHANGELOG.md