submit-store-review

# Submit Store Review `release-app` で作成済みの候補を、ストアの公開版との差分から審査へ提出する。新しいタグ、バージョン、ビルドは作成しない。 ## 責務と安全境界 - 提出は `.github/workflows/submit-store-review.yml` を使う。iOS は `asc`、Android は Fastlane と Google Play Developer API で処理する。 - 公開状態は `.github/workflows/inspect-store-state.yml` で読む。iOS は新APIの `READY_FOR_DISTRIBUTION` または旧APIの `READY_FOR_SALE`、Android は production track の `completed` / `inProgress` を正とする。 - Computer Use は通常使わない。APIで処理できない契約・税務・銀行情報や質問項目が残る場合だけ、理由と未完了項目を報告して止める。 - 新しいリリースが必要なら `$release-app`、説明文やスクリーンショット全体の更新なら `$update-store` を使う。 - 新規IAP・サブスクリプションを同じiOS審査へ含める場合、この自動提出は止める。アプリバージョン単体だけを自動化する。 ## 「最新を審査提出して」の既定動作 プラットフォーム指定がなければ iOS と Android の両方を対象に、次を連続して行う。 1. ストアAPIから現在の公開版を取得する。 2. 各プラットフォームの最新リリースタグと成功した release workflow を確認する。 3. 公開版タグから候補タグまでの累積差分を読む。 4. 英語、日本語、韓国語、簡体字中国語のリリースノートを作る。 5. 審査専用refへメタデータだけをコミットしてpushする。 6. 公開版、候補、4言語のノート、公開方式、対象refを示し、確認を1回だけ求める。 7. 承認後、iOSメタデータ反映と審査提出をdispatchし、完了まで監視する。 候補選択や翻訳ごとに確認を挟まない。ストアを変更する処理は最後の明示承認後にまとめて行う。承認前に実施してよい外部操作は、読み取り専用workflowの起動と審査refのpushまでとする。 ## 1. 公開版と最新候補を特定する 最初にリモートとタグを更新し、ローカルの未コミット変更を上書きしない。 ```bash git status --short git fetch origin main git fetch --prune origin \ '+refs/tags/ios/*:refs/store-review/remote-tags/ios/*' \ '+refs/tags/android/*:refs/store-review/remote-tags/android/*' ``` 候補版と公開版の比較には `refs/store-review/remote-tags/` 配下の隔離refを使う。既存のローカルタグは上書きしない。 公開状態の取得は `main` 上の読み取り専用workflowを使う。dispatch前のUTC時刻を記録し、その時刻より後に作られた同じref・同じplatformのrunだけを採用する。該当runが複数あり一意に決められなければ止める。 ...