--- name: vava description: $vava、次versionの更新・公開、リリースブランチ作成・再開を頼まれたとき、version決定から既存の署名・配信経路まで完走する。 --- # $vava — 次versionをリリースする 💖 ## 権限と不変条件 明示的な `$vava` は対象releaseを進める依頼として扱う。以下は現在の依頼に含まれる操作だけを行い、既存の許可を引き継ぐ。公開版は利用者のGit・外部サービスの権限境界を広げない。 - version同期、利用者向けREADME・CHANGELOG、検証。 - **今回のreleaseに含めると確認したsource repositoryの変更**の主題別日本語commit、default branchへの通常push。秘密・証明書・一時成果物と `.gitignore` 済みfileだけを除外する。 - `release/..` branchの作成・通常push、既存の署名・CI・store release経路の完走。 - 今回の変更を利用者が使える状態にするため不可欠で、source releaseに一意に結び付く既存production deployと、配信実物の確認。 - `vava.config.json.consumerUpdates.targets` に明示された参照元で、今回の公開物への参照・lock・同梱copyを更新・検証すること。cleanな参照元は日本語commitをdefault branchへ通常pushし、既存の未コミット差分がある参照元はその差分を保持したまま参照更新を上乗せして `updated-in-worktree` とし、stage・commit・pushせず後続工程へ進む。 - 告知が現在の依頼で許可され、既存の投稿経路とaccountが設定されている場合、公開成功または一般公開向けstore申請受理後に、検証済みの紹介画像を添えて1release 1件を告知すること。 - 公開成功後、source repositoryのdefault branchへmerge済みの古いrelease branchを候補として示し、対象の削除が明示的に許可されている場合だけ整理すること。 force push、履歴改変、未merge branch削除、別versionの発行、参照元製品自体のversion bump / release / deployは含まない。依存更新、bot PR merge、製品仕様変更、新しい配信基盤も別依頼とする。 versionは1回だけ決め、`OLD_VERSION`、`NEW_VERSION`、PRIMARY、同期対象を固定する。失敗や再開を理由に再計算せず、別versionへ切り替えない。release branchへcheckoutせず、作業はsourceのdefault branchで続ける。 ローカルのbuild、test、lint、typecheck、package、署名、publish precheckは常に直列実行する。同じ作業treeや出力先を使うcommandを並列tool call、background job、複数shellで同時起動しない。長時間処理は現在sessionの継続機構で1processだけ追跡し、cell IDが返る場合は同じcellを `wait` で再開する。CIは対象runごとに `gh run watch --compact --exit-status` を使う。Windowsのcommand例はPowerShellを正本とする。自然言語のwakeupで新しいreleaseを起動せず、既存状態を再取得して未完了checkpointから続ける。 ## モードを決める ### Dry-run `--dry-run`、「計画だけ」、「プランだけ見せて」は [dry-run経路](references/dry-run.md) で `new / resume / 未確定` を読み取り判定し、計画を示して終了する。live release、CI復旧、consumer mutation、X投稿のreferenceは読まず、Git ref、file、外部状態を変更しない。`offline` 併用時はremote、CI、store、公開物も照会しない。 ### Live [live preflight](references/release-preflight.md)を読み、外部書き込み前に `RELEASE_MODE=new|resume` と必要なら `RESUME_SCOPE=announcement-only` を固定する。 - working treeのPRIMARYが`HEAD`より新しい、現在versionのrelease branch・外部release・設定済みconsumer targetに未完了checkpointがある: `resume`。現在versionを `NEW_VERSION` として保持する。 - release本体、必要なdeploy、全consumer targetが完了し、告知も完了または非該当: `new`。通常はpatchを1つ上げる。 - release本体が完了、またはstore申請受理後の公開待ちで、実行可能な残作業が告知だけ: `resume` + `announcement-only`。source作業treeとbranchを変更せず、[X告知 §1](references/x-announcement.md#1-公開再開状態を読み取り分類する)で確認した既存draft・投稿状態、または草稿作成前の告知保留と未送信の根拠から再開する。 - 外部状態が一意に照合できない: mutation前に停止し、未確定のbranch、SHA、run、artifact、store/deploy状態を示す。利用者の選択で結果が変わる場合だけ具体的な質問を1つ行う。 `resume` は同じ `NEW_VERSION` の完了済みcheckpointを飛ばし、最初の未完了地点から続ける。version commit、CHANGELOG節、package、署名、store submit、deploy、consumer commit、X投稿を状態確認なしに重複実行しない。詳しい再実行条件は、対象CIが存在する場合だけ [CI recovery](references/ci-recovery.md) を読む。 ## Live経路を進める 1. [live preflight](references/release-preflight.md)でsource root・remote・全差分、release mode、version、利用者向け文書、検証、store提出前の入力凍結を完了する。 2. projectに存在するintegrationだけ [release integration](references/release-integrations.md) の該当節を読む。署名、Apple、AMO、CWS、hosted runtime、Cloudflare/R2のうち存在しない経路は読まない。 3. [source release](references/source-release.md)に従って今回のrelease対象に固定した変更をcommitし、default branchとrelease branchをpushし、既存release・必要deploy・配信確認を完走する。 4. `consumerUpdates.targets` がある場合だけ [参照元更新](references/consumer-updates.md) を読み、設定順に処理する。設定が無い場合は候補を読み取り報告してよいが、参照元を変更しない。 5. 告知が許可され、既存の投稿経路が設定済みの一般公開releaseと一般公開向けstore申請を対象に、[告知文面](references/announcement-draft.md)、[アプリ紹介画像](references/announcement-image.md)、[X告知](references/x-announcement.md)を読み、公開確認または申請受理確認後に画像付きで1件投稿する。申請から公開まで待ち時間のあるstoreは公開確認を待たず、「申請中」と当該アプリのstore URLで告知する。TestFlight、内部・限定配布、利用者向け製品がない対象は非該当として正常終了する。今回の告知不要・文面のみ・画像不要という指定を優先する。画像生成・検証・添付または投稿の失敗はrelease本体を妨げず、告知だけを保留する。 6. sourceのbranch・clean状態、配信、consumer、cleanup、告知を確認して報告する。 ## 完了条件 - `OLD_VERSION → NEW_VERSION` を1回だけ決め、PRIMARYと同期対象、README・CHANGELOG、既存検証を整えた。 - release本体を実行した場合、sourceの全差分を把握し、今回のrelease対象だけを検証して、その変更を主題別commitにしてdefault branchへpushした。sourceは対象外の既存差分と許可された保持物を除きcleanで、報告時のbranchはdefault branchである。`announcement-only` は既存作業treeとbranchを保持する。 - `RELEASE_HEAD_SHA` からrelease branchを作成・pushし、既存署名/CI/store経路と `DEPLOY_REQUIREMENT=required` の既存production deployを完走した。公開成果物と実環境を確認した。storeの審査・公開待ちは申請受理を今回の到達点とし、公開済みとせず「申請中」とstore URLを報告する。公開確認に依存するcheckpointは保留として残し、待機せず告知へ進む。 - 設定済みconsumer targetを `complete / already-current / updated-in-worktree / pending / blocked` に分類した。clean targetは参照・検証・commit・pushを、dirty targetは既存差分の保持・参照更新・検証を確認し、dirtyであることだけを停止理由にしていない。失敗targetのためsource releaseを巻き戻していない。 - merge済みの旧release branchと今回生成した不要物を安全に整理した。`bin`・`obj` は通常保持する。 - 告知対象の一般公開release・一般公開向けstore申請は、検証済みアプリ紹介画像を添付したXの投稿URL、画像付き既投稿、保留理由のいずれかを、非公開配信・告知許可または既存経路のない対象は告知非該当を記録した。画像不要の明示指定がある場合だけ本文のみを正常とする。申請中の投稿も同versionの1件として扱い、公開後に重複投稿しない。告知失敗だけを理由にreleaseを再実行していない。 報告は利用者の言語と指定した文体で、起点branch、報告時branch、version、更新file、検証、commit SHA、push、release branch、署名/CI/store、deploy判定と実環境確認、consumerごとの状態、削除・保持branch、告知文・紹介画像・添付確認、未完了checkpointと安全な再開手順を示す。project typeに応じた動作確認checklist（extension読込、配信URLのHTTP 200、TestFlight反映等）も添える。deployは `required・実行済み` / `not-applicable` / `required・未整備` / `ambiguous` のどれかを根拠付きで必ず1行入れる。