/release-app

name: release-app
description: ccpocketアプリのバージョン更新と、指定プラットフォーム向けリリースを行う。
allowed-tools: Bash(git:*), Bash(grep:*), Bash(gh:*), Bash(bash scripts/release/run-checks.sh), Bash(node scripts/release/monitor.mjs:*), Read, Edit, AskUserQuestion

アプリ リリース

Flutter アプリのリリースを行う。 タグ push 後は GH Actions が自動でビルド・署名・配布・GitHub Release を作成する。

前提

• main ブランチで作業中であること
• 未コミットの変更がないこと

指定済みのバージョン・対象を優先する。未指定の項目は以下の既定ルールで決定し、決定内容と理由を報告してリリースを進める。リリース依頼に含まれるコミット・push・タグ作成に追加の承認を求めない。

手順

1. 現在のバージョン確認 & 変更内容の収集

grep '^version:' apps/mobile/pubspec.yaml

`version: X.Y.Z+N` の形式。`+N` は build number。

前回リリースからの差分を確認する:

# 前回のタグ（iOS/Android/macOS/Linux/Windows のいずれか新しい方）
git tag -l 'ios/v*' 'android/v*' 'macos/v*' 'linux/v*' 'windows/v*' --sort=-v:refname | head -1

# 差分コミット（bridge 以外）
git log $(git tag -l 'ios/v*' 'android/v*' 'macos/v*' 'linux/v*' 'windows/v*' --sort=-v:refname | head -1)..HEAD --oneline -- apps/mobile/ CHANGELOG.md

2. バージョンとプラットフォームを決定

差分コミットと実装内容から、次の優先順で決定する。指定済みのバージョンは再確認しない。

• 破壊的変更（`!`、`BREAKING CHANGE`、実際の互換性破壊）がある → `major`。未承認の場合だけ、具体的なバージョンと互換性への影響を示してユーザーに確認する。
• 破壊的変更がなく `feat` / 新機能がある → `minor` を自動採用する。
• その他の修正・改善・保守変更 → `patch` を自動採用する。

build number は現在の値 +1 とする。

プラットフォーム指定がなければ **iOS + Android + macOS + Linux + Windows 全部**を対象にする。「モバイルのみ」は iOS + Android、「デスクトップのみ」は macOS + Linux + Windows とし、個別指定があればその対象だけを使う。

3. CHANGELOG 更新

`CHANGELOG.md`（ルート）の先頭に新しいセクションを追加する。

## [X.Y.Z] - YYYY-MM-DD

### Added
- ...

### Changed
- ...

### Fixed
- ...

ステップ 1 で確認したコミットを元に、Added / Changed / Fixed に分類する。 空のセクション（該当なし）は省略する。

4. バージョン bump

`apps/mobile/pubspec.yaml` の `version` をステップ 2 で決定したバージョンに更新する。

5. ローカル検証

タグpush前に、CDと同じチェックをcompactラッパーで実行する。 成功時は解析・テスト・合計時間の3行だけを返す。失敗時は一時ログのパスと 最大120行の末尾だけを返す。**すべてpassしなければ次へ進まない。**

bash scripts/release/run-checks.sh

失敗した場合は原因を調査し、今回の変更に起因する問題を修正・再検証する。既存の無関係な問題や権限・認証など自力で解消できない障害が残る場合は、失敗内容と必要な対応を報告し、タグをpushしない。

6. コミット & push

git add apps/mobile/pubspec.yaml CHANGELOG.md
git commit -m "chore: bump version to X.Y.Z+N"
git push origin main

6.1. Windows preflight（Windowsを選択した場合）

Windowsタグを含むリリースでは、**いずれのプラットフォームタグも作成する前に**、 リリースコミットと同じSHAで起動した `Test` workflowの成功を確認する。 通常CIの `mobile-windows` jobが、リリースworkflowと同じFlutter全テストを `windows-2022` で実行する。

release_sha=$(git rev-parse HEAD)
node scripts/release/monitor.mjs preflight --sha "$release_sha"

監視スクリプトは起動検出を10秒間隔、実行中を30秒間隔で確認し、状態変化と 3分ごとのheartbeatだけを出す。起動しなければ2分、完了しなければ15分で失敗する。 個々の`gh`呼び出しも60秒で打ち切り、最大3回まで再試行する。 失敗時はjob・step・run URLと、完全な失敗ログを保存した一時パスを1行で返す。 タグは作成せず、必要なログ箇所だけを調査して修正コミットをpushし、新しいSHAで preflightをやり直す。タグがなければ同じversion/build numberを使用できる。

6.2. タグ

ローカル検証と、Windows選択時のpreflightがすべて成功した後で、 ステップ2で選択されたプラットフォームのタグを作成・pushする。 Windowsを含む複数プラットフォームのリリースでは、preflight成功前に他のタグも作成しない。

ステップ 2 で選択されたプラットフォームのタグを打つ:

**各タグは必ず別々の `git push` で送信すること。** GitHubは4個以上のタグを 1回のpushで送るとtag pushイベントを生成しないため、複数タグを1つの `git push origin <tag> <tag> ...` にまとめてはならない。

# iOS（選択された場合）
git tag ios/vX.Y.Z+N
git push origin ios/vX.Y.Z+N

# Android（選択された場合）
git tag android/vX.Y.Z+N
git push origin android/vX.Y.Z+N

# macOS（選択された場合）
git tag macos/vX.Y.Z+N
git push origin macos/vX.Y.Z+N

# Linux（選択された場合）
git tag linux/vX.Y.Z+N
git push origin linux/vX.Y.Z+N

# Windows（選択された場合）
git tag windows/vX.Y.Z+N
git push origin windows/vX.Y.Z+N

7. 完了確認

タグ push 後、GH Actions が自動実行される:

| タグ | ワークフロー | 内容 | |-----|------------|------| | `ios/v*` | `ios-release.yml` | Shorebird release iOS → TestFlight → GitHub Release | | `android/v*` | `android-release.yml` | Shorebird release Android → Google Play (internal draft) → GitHub Release | | `macos/v*` | `macos-release.yml` | Developer ID 署名 → 公証 → DMG → GitHub Release | | `linux/v*` | `linux-release.yml` | Linux release build → Xvfb smoke → tar.gz → GitHub Release | | `windows/v*` | `windows-release.yml` | Windows release build → smoke → zip → GitHub Release |

タグをpushしたプラットフォームだけをカンマ区切りで指定する:

node scripts/release/monitor.mjs release \
  --version "X.Y.Z+N" \
  --platforms "ios,android,macos,linux,windows"

監視スクリプトは全タグが同じcommitを指すことを検証し、exact tag/SHAのrunだけを 追跡する。起動検出は10秒間隔、開始後10分までは60秒間隔、その後は90秒間隔で確認し、 状態変化と3分heartbeatだけを出す。起動しなければ2分、完了しなければ40分で失敗する。 platformごとのworkflow名も照合し、同じtag/SHAで動く別workflowを成功扱いしない。 `gh run watch`や個別の`gh run list`を直接繰り返さない。

失敗時はcompactなjob/step要約と一時ログを調査する。全ログを会話へ貼らない。 全対象が`completed/success`になるまでリリースを完了扱いにしない。