tegnike Break Duel リリースワークフロー
バージョンタグ付けと GitHub リリースノート作成を、事前検証つきで一貫して行う。
リリースノートの正本は docs/releases/vX.Y.Z.md に置く（docs 正本ルール）。
GitHub Release は同じ内容の配信面として作成する。
1. バージョン番号を決める
セマンティックバージョニング（v プレフィックス付き）を使う。
- major: ルールやセーブデータの互換性が壊れる変更
- minor: カード追加・新メカニクス・UI 機能追加など後方互換の機能追加
- patch: バグ修正・バランス数値調整・文言修正のみ
ユーザーがバージョンを指定していればそれに従う。指定がなければ前回タグからの 変更内容（feat があれば minor、fix のみなら patch）を根拠に提案し、確認を取る。
2. 事前チェック
すべて満たしてから先へ進む。満たせない場合は理由を報告して停止する。
git status --short # 未コミットの変更がないこと
git branch --show-current # main であること
git fetch && git status -sb # origin/main と同期していること（ahead/behind なし）
git tag # 予定バージョンが既存タグと重複しないこと
npm run check # typecheck + vitest + build 全合格
gh run list --branch main -L 3 # 直近の CI が成功していること（実行中なら完了を待つ）
注意: このリポジトリは npm 標準。pnpm は使わない（vitest が壊れる）。
3. 変更内容を収集する
git describe --tags --abbrev=0 # 前回タグ（初リリース時は存在しない）
git log <前回タグ>..HEAD --oneline # 初リリース時は git log --oneline で全履歴
コミットプレフィックス（feat / fix / chore / docs / refactor / test）で分類する。
コミットメッセージの本文（git log --format='%h %s%n%b'）や
docs/balance-history.md も参照して、プレイヤー目線の変化を拾う。
4. リリースノートを書く
docs/releases/vX.Y.Z.md を以下のテンプレートで作成する。
読者は「このゲームを遊ぶ人」。内部実装の詳細より、遊んで分かる変化を優先して書く。
# vX.Y.Z (YYYY-MM-DD)
ひとこと要約（このリリースで何が変わるかを1〜2文で）。
## ハイライト
- プレイヤーに一番影響が大きい変更を2〜4個
## 変更点
### 新機能・カード
- feat 系の変更（なければセクションごと省く）
### バランス調整
- 数値・ルール調整（docs/balance-history.md と整合させる）
### 修正
- fix 系の変更
### その他
- chore / docs / 開発基盤
## 検証
- npm run check の結果（テスト件数）と CI の状態
日付はコミット日ベースの実際の日付を使う。誇張せず、コミットに裏付けのある内容だけを書く。
5. タグ付けとリリース作成
リリースノートのコミット → 注釈付きタグ → push → GitHub Release の順で実行する。 （ノートを先にコミットすることで、タグがノートを含む状態になる）
git add docs/releases/vX.Y.Z.md
git commit -m "docs: vX.Y.Z リリースノートを追加"
git tag -a vX.Y.Z -m "vX.Y.Z: ひとこと要約"
git push origin main --follow-tags
gh release create vX.Y.Z --title "vX.Y.Z" --notes-file docs/releases/vX.Y.Z.md
6. リリース後に develop を同期する
リリースコミット（リリースノート、package.json / package-lock.json のバージョン更新など）を
main だけに残すと、次回の develop => main PR で差分・競合・バージョン巻き戻しの原因になる。
GitHub Release 作成後、必ず develop を main に fast-forward 同期する。
git fetch origin --prune --tags
git merge-base --is-ancestor origin/develop origin/main
上の確認が成功した場合だけ、develop を origin/main へ fast-forward して push する。
develop が別 worktree で checkout 済みの場合は、その worktree へ移動して実行する。
git switch develop
git merge --ff-only origin/main
git push origin develop
origin/develop が origin/main の祖先でない場合は、勝手にマージ・rebase しない。
分岐しているコミットを確認し、リリースコミットの取り込み方を報告して停止する。
7. 完了報告
リリース URL（gh release view vX.Y.Z --json url -q .url）、タグ、
ノートの場所、develop 同期結果を報告する。CI がタグ push で走る場合はその状態も添える。