day-one-patch

Day-One Patch

リリースされるゲームにはすべて、Day-One Patch があります。リリース日に先立って計画しておけば、混乱を防げます。このスキルでは、安全かつ必要な範囲だけにパッチを限定し、簡易 QA を通し、リリース前にロールバック計画があることを確認します。これはミニスプリントであり、ホットフィックスでもフルスプリントでもありません。

実行するタイミング：

• ゴールドマスタービルドが確定した後（認証承認済み、またはローンチ候補としてタグ付け済み）
• ゴールドマスターで修正するにはリスクが高すぎる既知のバグがある場合
• 認証のフィードバックにより、提出後に軽微な修正が必要な場合
• リリースゲート通過後のリリース前プレイテストで、必須修正項目が見つかった場合

Day-One Patch のスコープルール：

• 迅速かつ安全に修正できる P1/P2 のバグのみ
• 新機能は禁止 — 修正のみ
• リファクタリングは禁止 — 最小限の変更にとどめる
• 開発に 4 時間を超える修正は、Day-One ではなくパッチ 1.1 に含める

出力： production/releases/day-one-patch-[version].md

---

Phase 1: リリースコンテキストの読み込み

以下を読み込みます：

• project.yaml 内の project.stage（なければ production/stage.txt） — プロジェクトが Release ステージであることを確認します
• production/gate-checks/ 内の最新ファイル — リリースゲートの判定を読み込みます
• production/qa/bugs/*.md — Status: Open または Fixed — Pending Verification のすべてのバグを読み込みます
• production/sprints/ 内の最新ファイル — リリース済みの内容を把握します
• production/security/security-audit-*.md 内の最新ファイル — 未解決のセキュリティ項目がないか確認します

解決されたステージ（project.yaml → stage.txt）が Release または Polish でない場合：

"Day-One Patch の準備は Release ステージのプロジェクト向けです。現在のステージ：[stage]。ローンチが近づくまで、このスキルは適切ではありません。"

前提を確認し、決めつけないでください。 このスキルは、リリースゲートをすでに通過したゴールドマスターがあることを前提としています。この前提があるからこそ、フル QA ではなく簡易 QA を実施できます。したがって、ステージの値から推測するのではなく、必ず確認してください。

• production/gate-checks/ にファイルがない場合、またはリリースゲートの判定が記録されたファイルがない場合：Release gate: NOT ASSESSED — no gate-check record found と報告します。何も言わずに先へ進んではいけません。以下の QA スコープを縮小できる根拠となるゲート記録が見つからないことを明言し、まず /gate-check を実行するか、代わりにフル QA を実施するかを尋ねてください。
• 最新の記録が FAIL、CONCERNS、または NOT ASSESSED の場合：その記録を明示して停止します。ゲートを一度も通過していないビルドに対する Day-One Patch は、Day-One Patch ではありません。遅れて実施するリリースゲートであり、対象とする変更を誤っています。
• project.stage: Release だけでは、この前提を満たしません。ステージはプロジェクトの現在地を示すものであり、ゲート記録はその位置に到達した根拠です。

---

Phase 2: パッチのスコープを決める

Step 2a — オープンバグを分類し、パッチへの含否を決める

各オープンバグについて、以下を評価します。

基準	Day-One に含めるか？
S1 または S2 の深刻度	はい — 安全に修正できる場合は含める必要があります
P1 優先度	はい
修正の見積もりが 4 時間未満	はい
修正にアーキテクチャの変更が必要	いいえ — 1.1 まで延期します
修正によって新たなコードパスが生じる	いいえ — リスクが高すぎます
修正がデータ／設定のみ（コード変更なし）	はい — リスクが非常に低いため
認証フィードバックによる要件	はい — プラットフォーム承認に必須です
S3/S4 の深刻度	設定の軽微な修正のみ対象。それ以外は延期します

Step 2b — パッチのスコープをユーザーに提示する

AskUserQuestion を使用します：

• プロンプト：「オープンバグと認証フィードバックに基づく、Day-One Patch のスコープ案はこちらです。この内容でよいですか？」
• 表示：含めるバグの表（ID、深刻度、説明、作業の見積もり）
• 表示：延期するバグの表（ID、深刻度、延期する理由）
• 選択肢：[A] このスコープを承認する / [B] 調整する — 項目を追加または削除したい / [C] Day-One Patch は不要

[C] の場合：「Day-One Patch は不要です。/launch-checklist に進んでください。」と出力して停止します。

ステップ 2c — スコープ全体を確認する

見積もった作業量を合計します。合計が 1 日分の作業を超える場合は、次のように伝えます。

「⚠️ パッチの作業量は［N 時間］です。安全な初日の作業時間を超えています。優先度の低い項目はパッチ 1.1 に延期することを検討してください。初日のパッチが肥大化すると、取り除くリスクよりも多くのリスクを招きます。」

AskUserQuestion を使用して、続行するかスコープを縮小するか確認します。

---

フェーズ 3：ロールバック計画

コードを書く前に、ロールバック手順を定義します。これは必須です。

Agent 経由で release-manager を起動します。次の内容を含むロールバック計画を作成するよう依頼します。

• 各対象プラットフォームでゴールドマスタービルドに戻す方法
• プラットフォーム固有のロールバック制約（一部のプラットフォームでは、証明書付きビルドをロールバックできません）
• ロールバックを実行する責任者
• ロールバックが発生した場合に必要となるプレイヤーへの連絡

ロールバック計画を提示します。「このロールバック計画を production/releases/rollback-plan-[version].md に書き込んでもよいですか？」と尋ねます。

ロールバック計画を書き込むまで、フェーズ 4 に進んではいけません。

---

フェーズ 4：修正を実装する

承認されたスコープ内のコード修正ごとに、対象を絞った実装ループを実行します。

1. Agent 経由で lead-programmer を起動し、次の情報を渡します。

   • バグ報告（正確な再現手順と、判明している場合は根本原因）
   • 制約：実用最小限の修正のみ。クリーンアップは行わない
   • 影響を受けるファイル（バグ報告の Technical Context セクションから）

   バグごとに、最小限の修正内容と変更対象ファイルを返します。 何も書き込みません。

2. 修正一式について一度だけ、「これらの修正を適用してもよいですか？［BUG-ID → ファイル、1 行ずつ］」と尋ねます。この承認前にコードを変更してはいけません。

3. 承認された場合は、各修正の計画を添えて、新しい Agent 呼び出しで lead-programmer に差し戻し、実装と対象テストの実行を依頼します。テストには project.yaml の commands.test を使用し、テストランナーで可能な場合は影響を受けるスイートに範囲を絞ります。記憶を頼りにテストランナーのコマンドを記述してはいけません。commands.test が未設定の場合はその旨を伝え、そのバグについて Tests: NOT RUN — commands.test unset と記録します。

4. Agent 経由で qa-tester を起動し、修正後にバグが再現するか検証します。

設定／データのみの修正は直接変更します（プログラマーエージェントは不要です）。まず、ファイルと変更内容を明記して、「[config file] の [key] を編集してもよいですか？［old value］→［new value］」と尋ねます。値が変更されたことを確認し、関連するスモークテストを再実行します。

---

フェーズ 5：パッチ QA ゲート

これは簡易的な QA パスであり、完全な /team-qa ではありません。パッチはリリースゲートで QA 承認済みのため、変更箇所のみを再確認します。

Agent を使って qa-lead を起動し、次の情報を渡します。

• 変更したファイルの一覧
• 修正したバグの一覧（フェーズ 4 の検証状況を含む）
• 影響を受けるシステムのスモークチェック範囲

qa-lead に次の点を判断するよう依頼します。対象を絞ったスモークチェックで十分か、より広範な回帰テストが必要なシステムに触れる修正があるか？

必要な QA 範囲を実行します。

• 対象を絞ったスモークチェック — /smoke-check を実行します（システム引数は不要です）
• より広範な回帰テスト — エンジンのテストルート（Godot は tests/unit/ と tests/integration/、Unity は Assets/Tests/、Unreal は Source/<Module>/Private/Tests/ — .claude/docs/directory-structure.md）で、影響を受けるシステムのテストを project.yaml の commands.test を使って実行します。ランナーが対応している場合は、影響を受けるテストスイートに絞ります。記憶を頼りにランナーのコマンドを決して書いてはいけません。commands.test が未設定の場合、より広範な回帰テストは「未評価」です。その旨を明記してください。

先に進むには、QA 判定が PASS または PASS WITH WARNINGS である必要があります。FAIL の場合、失敗した修正を初日パッチの対象から外し、1.1 に延期します。

QA 判定が NOT ASSESSED の場合、それは合格ではありません。 /smoke-check はスイートが一度も実行されなかった場合（ビルドがない、ランナーがない、または結果を誰も確認していない場合）にこの判定を返します。この判定のまま先に進んではいけません。また、PASS WITH WARNINGS と読み替えてはいけません。warnings は誰かが確認し、軽微な問題を見つけたという意味ですが、この判定は誰も確認していないという意味です。結果を取得するか（判定には実行可能にする方法が示されます）、修正を 1.1 に延期してください。初日パッチは発売初日にゲームを購入したプレイヤー全員に配信されるため、未検証の変更を届ける相手としては最悪です。

---

フェーズ 6：パッチ記録を生成する

# Day-One Patch: [Game Name] v[version]

**Date prepared**: [date]
**Target release**: [launch date or "day of launch"]
**Base build**: [gold master tag or commit]
**Patch build**: [patch tag or commit]

---

## Patch Notes (Internal)

### Bugs Fixed
| BUG-ID | Severity | Description | Fix summary |
|--------|----------|-------------|-------------|
| BUG-NNNN | S[1-4] | [description] | [one-line fix] |

### Deferred to 1.1
| BUG-ID | Severity | Description | Reason deferred |
|--------|----------|-------------|-----------------|
| BUG-NNNN | S[1-4] | [description] | [reason] |

---

## QA Sign-Off

**QA scope**: [Targeted smoke / Broader regression]
**Verdict**: [PASS / PASS WITH WARNINGS / NOT ASSESSED]
**QA lead**: qa-lead agent
**Date**: [date]
**Warnings (if any)**: [list or "None"]
**Not assessed (if any)**: [what could not be checked, and why — or "None"]

---

## Rollback Plan

See: `production/releases/rollback-plan-[version].md`

**Trigger condition**: If [N] or more S1 bugs are reported within [X] hours of launch, execute rollback.
**Rollback owner**: [user / producer]

---

## Approvals Required Before Deploy

- [ ] lead-programmer: all fixes reviewed
- [ ] qa-lead: QA gate PASS confirmed
- [ ] producer: deployment timing approved
- [ ] release-manager: platform submission confirmed

---

## Player-Facing Patch Notes

[Draft for community-manager to review before publishing]

[list player-facing changes in plain language]

次のように尋ねます。「このパッチ記録を production/releases/day-one-patch-[version].md に書き込んでもよろしいですか？」

---

フェーズ 7：次のステップ

パッチ記録を書き込んだ後：

1. /patch-notes を実行して、プレイヤー向けのパッチノートを生成します
2. パッチ公開後、修正したバグごとに /bug-report verify [BUG-ID] を実行します
3. 検証済みの修正ごとに /bug-report close [BUG-ID] を実行します
4. production/milestones/ にあるローンチのマイルストーンに対して、/retrospective [milestone-name] を使い、ローンチから 48～72 時間後にローンチ後レビューを予定します

パッチ適用後も S1 バグが未解決の場合：

"⚠️ S1 バグが未解決のまま残っており、パッチも適用されていません。これらは許容するリスクです。ロールバック計画の発動条件に記録してください。大規模に発生した場合は、追加パッチよりロールバックが望ましい可能性があります。"

AskUserQuestion を使います。

• プロンプト：「初日パッチが完了しました。次は何をしますか？」
• 選択肢：
  • [A] /patch-notes を実行 — プレイヤー向けパッチノートを生成
  • [B] /bug-report を実行 — デプロイ後に見つかった問題を記録
  • [C] ここで終了

---

コラボレーションプロトコル

• 範囲の管理がすべてです — スコープクリープを避けてください。追加するたびにリスクが高まります
• 常にロールバック計画を最初に作成します — ロールバック計画のないパッチは無責任です
• 延期しても忘れてはいけません — 延期したバグはすべて、記録の「1.1 に延期」テーブルに記載します。その後 /bug-triage を実行し、1.1 のスプリントに組み込むよう予定します（デフォルトの最小ワークフローのようにプロジェクトにスプリント計画がない場合は、ブリーフのビルド順に組み込みます）
• プレイヤーへの告知もパッチの一部です — /patch-notes は任意ではなく、必須の成果物です