releaselisted

# リリース手順 リリースの起点は `v<VERSION>` タグのpushのみ。タグpushで `.github/workflows/release.yml` が macOSランナーでビルド → ドラフトリリース作成（ノートはマージ済みPRから自動生成）→ `ccglance.zip` + `ccglance.zip.sha256` 添付 → 公開 → Homebrew tap更新まで自動で行う。 **GitHub Releaseを手動で公開してはいけない**。リリースはimmutableのため、公開後に成果物を 添付できず、アセット無しの壊れたリリースになる（v1.5.0〜v1.5.3で実際に起きた事故）。 公開済みタグは再利用不可。やり直す場合は新バージョンのタグを切る。 ## 手順 ### 1. 差分の確認とバージョン判断 ```bash git fetch origin main --tags # --tags必須（mainのfetchだけではタグが揃わないことがある） git tag --sort=-v:refname | head -1 # 前回リリースタグ git log v<前回>..origin/main --oneline --merges # 取り込まれたPR gh pr list --repo hatoya/ccglance --state merged --limit 30 \ --json number,title,labels --jq '.[] | "\(.number)\t\(.title)\t\([.labels[].name] | join(","))"' ``` `gh pr list` の結果は `git log --merges` のPR一覧と突合し、対象PRが揃っていることを確認する （`gh pr list` は作成日降順のため、古いPRが後からマージされたケースを取りこぼしうる）。 PRラベルからバンプ幅を決める: `feature` が1つでもあればminor、`bug`/`chore` のみならpatch。 破壊的変更（設定・セッションJSONフォーマットの非互換等）があればmajor。 前回タグ以降のPRが無い場合はリリース不要と報告して終了する。 ### 2. バージョンバンプとCHANGELOG 新しいブランチを `origin/main` から作成し（ヘッド・ベースとも`main`基準）、以下を変更: - `build.sh` の `VERSION` を新バージョンに更新 - `CHANGELOG.md` の先頭に `## v<VERSION>` エントリを追加。既存エントリと同じ英語・箇条書きで、 **前リリース以降の変更のみ**を記載する。手順1のPR一覧と突合し、漏れ・過剰記載がないこと ### 3. ビルド確認 ```bash bash build.sh ``` コンパイル → .app生成 → ad-hoc署名 → zip + sha256生成まで通ること。 `build/ccglance.app/Contents/Info.plist` の `CFBundleShortVersionString` が新バージョンであること。 ### 4. コードレビュー サブエージェント（`Agent`ツール）に `engineering:code-review