hotfix

ホットフィックス

明示的な呼び出しのみ：このスキルは、ユーザーが /hotfix を明示的に要求した場合にのみ実行してください。コンテキストが一致するという理由で自動的に呼び出してはいけません。

フェーズ 1：重大度の評価

バグの説明または ID を読みます。/bug-triage の尺度に基づいて重大度を評価します。

• S1（クリティカル）：クラッシュ、データ損失、または機能の完全な停止 — ゲームを進行できません（セキュリティ問題も、その影響に基づいて評価します）
• S2（高）：主要機能が壊れていますが、ゲームは引き続きプレイできます
• S3 以下：回避策のある機能劣化、または見た目上の問題 — 通常のバグ修正ワークフローを適用します

AskUserQuestion で確認します。

• Prompt: "重大度を [評価した重大度] と評価しました — [簡潔な理由]。続行するため、重大度を確認してください："
• Options:
  • [A] S1（クリティカル） — クラッシュ、データ損失、または機能の完全な停止
  • [B] S2（高） — 主要機能が壊れていますが、ゲームは引き続きプレイ可能
  • [C] S3 以下 — 通常のバグ修正ワークフローに切り替える

[C] の場合：停止します。判定：リダイレクト — S3 以下には通常のバグ修正ワークフローを使用してください。

---

フェーズ 2：ホットフィックス記録の作成

ホットフィックス記録の草案を作成します。

## Hotfix: [Short Description]
Date: [Date]
Severity: [S1/S2]
Reporter: [Who found it]
Status: IN PROGRESS

### Problem
[Clear description of what is broken and the player impact]

### Root Cause
[To be filled during investigation]

### Fix
[To be filled during implementation]

### Testing
[What was tested and how]

### Approvals
- [ ] Fix reviewed by lead-programmer
- [ ] Regression test passed (qa-tester)
- [ ] Release approved (producer)

### Rollback Plan
[How to revert if the fix causes new issues]

質問します："これを production/hotfixes/hotfix-[date]-[short-name].md に書き込んでもよいですか？"

はいの場合、必要に応じてディレクトリを作成し、ファイルを書き込みます。

---

フェーズ 3：ホットフィックスブランチの作成

Git リポジトリかどうかを確認します。

Bash: git rev-parse --is-inside-work-tree 2>/dev/null

このコマンドが失敗するか、空の結果を返す場合："Git リポジトリではありません — ブランチは手動で作成してください。" と記録し、ブランチの作成をスキップします。

[base-ref] は、バグが発生しているリリースです。リリースは main（トランク）上のタグなので、そのリリースのタグ（git tag --list。通常は最新のタグが稼働中のビルドです）、またはそのリリースを安定化するために作成された release/* ブランチ（git branch --list 'release/*'）を指定します。main の先端は指定しないでください。未リリースの作業が含まれている可能性があります。

確認に成功した場合は、ブランチを作成する前に AskUserQuestion を使用します。

• Prompt: "ブランチ 'hotfix/[short-name]' を [base-ref] から作成する準備ができました。よろしいですか？"
• Options:
  • [A] はい — ブランチを作成する
  • [B] 別のベース参照を使う — 指定します
  • [C] スキップ — 自分でブランチを作成します

ユーザーが [A] を選択した場合にのみ、git checkout -b hotfix/[short-name] [base-ref] を実行します。[B] の場合：ユーザーにベース参照を尋ね、その参照を使ってコマンドを実行します。[C] の場合：ブランチの作成をスキップし、フェーズ 4 に進みます。

---

フェーズ 4：調査と提案

根本原因を特定します。最小限の修正案を作成します。変更するファイル、変更内容、意図的に変更しない点を明記してください。ホットフィックスに合わせてリファクタリング、クリーンアップ、機能追加をしてはいけません。

根本原因と修正案を提示してから、"この修正を実装してもよいですか？" と尋ねます。この承認を得る前にコードを変更してはいけません。緊急対応フローの監査証跡は、変更後ではなく、変更が存在する前に承認を得ることで確保されます。

---

フェーズ 4b：実装（承認後のみ）

承認された最小限の変更を実装します。project.yaml の commands.test を使って、影響を受けるシステムの対象テストを実行し、修正を検証します（テストランナーで可能な場合は、影響を受けるテストスイートに絞り込みます）。記憶を頼りにテストランナーのコマンドを記述してはいけません。エンジンが必要とするフラグが抜けてしまうためです（gdUnit4 は --remote-debug tcp://127.0.0.1:0 がないとハングします）。隣接するシステムにリグレッションがないか確認します。commands.test が未設定、または影響を受けるシステムを対象とするテストがない場合は、その旨を伝え、ホットフィックス記録の Testing セクションに Tests: NOT RUN — [reason] と記録します。その場合は、フェーズ 5b の QA ゲートで検証を行います。

根本原因、修正の詳細、テスト結果をホットフィックス記録に追記します。

---

フェーズ 5：承認の取得

Agent ツールを使って、並行して承認を依頼します。

• subagent_type: lead-programmer — 修正の正確性と副作用をレビューします
• subagent_type: qa-tester — 影響を受けるシステムの対象リグレッションテストを実行します
• subagent_type: producer — デプロイのタイミングと告知計画を承認します

続行するには、3 者すべてから APPROVE を得る必要があります。いずれかが CONCERNS または REJECT を返した場合は、デプロイせず、問題を提示して先に解決します。

フェーズ 5b：QA 再エントリーゲート

承認後、ホットフィックスをデプロイする前に必要な QA の範囲を判断します。Agent 経由で qa-lead を起動し、以下を伝えます。

• ホットフィックスの説明と影響を受けるシステム
• フェーズ 5 の回帰テスト結果
• 変更されたファイルに関連するすべてのシステムのリスト（呼び出し元を見つけるには Grep を使用します）

qa-lead に次のように尋ねます：フルスモークチェックで十分ですか。それとも、この修正には対象を絞った team-qa の実施が必要ですか？

判定結果に従って対応します。

• スモークチェックで十分 — ホットフィックスのビルドに対して /smoke-check を実行します。PASS または PASS WITH WARNINGS の場合は、フェーズ 6 に進みます（警告をホットフィックス記録に引き継ぎます）。 FAIL の場合はデプロイしないでください。失敗したチェックとともにフェーズ 4 に戻り、そこで修正案の承認を得て、実装し（フェーズ 4b）、フェーズ 5 の承認（qa-tester による回帰テストを含む）とこの QA 手順を再度実施します。 スモークスイートを壊すホットフィックスは、修正ではなく二度目のインシデントです。
• 対象を絞った QA の実施が必要 — 変更されたシステムのみを対象に、/team-qa feature: [affected-system] を実行します。QA の結果が APPROVED または APPROVED WITH CONDITIONS の場合はフェーズ 6 に進みます。NOT APPROVED または BLOCKED の場合は、上記のスモークチェック FAIL と同様に対応します。
• フル QA が必要 — コアシステムに影響する S1 の修正では、フルの /team-qa sprint が必要になる場合があります。デプロイは遅れますが、不適切なパッチを防げます。

QA 手順の結果が NOT ASSESSED の場合、ゲートは実行されていません。未達として扱い、達成済みとはみなさないでください。 /smoke-check はスイートが一度も実行されなかった場合に、/team-qa は実行済みの証拠がないままサイクルが終了した場合に、この結果を返します。どちらのスキルでも、NOT ASSESSED は合格ではありません。時間に追われていると、許容的な解釈が妥当に思えてしまうからこそ、この点をここに明記しています。不足している結果を取得するか（判定結果には実行可能にするために必要なものが示されています）、あるいは、ゲートがひそかに通過したかのように扱うのではなく、未検証のホットフィックスをデプロイする決定として、明示的に責任者に判断を仰いでください。その決定について、誰が、なぜ行ったのかをホットフィックス記録の Testing セクションに記録します。

このゲートを省略しないでください。ほかの何かを壊すホットフィックスは、元のバグよりも悪いものです。

---

フェーズ 6：バグのステータスを更新してデプロイする

停止 — デプロイには、例外なく明示的な承認が必要です。 ホットフィックスのマージとパッチリリースのタグ付けは、このスキルにおける唯一の取り消せない操作です。そのため、取り消し可能なブランチ作成がすでに行われていても、承認が必要です。マージ、タグ付け、デプロイの前に、AskUserQuestion を使用します。

• プロンプト：「ホットフィックスの検証と承認が完了しました。[targets] にマージし、[patch tag] をタグ付けしてデプロイしますか？」— [targets] は main と、そのリリースに release/* ブランチがある場合に限りそのブランチです
• 選択肢：[A] はい — マージしてデプロイ ／ [B] main のみにマージ — リリースは保留 ／ [C] ここで停止

これは modes.automation の設定にかかわらず適用されます。autonomous の場合も同様です。緊急時のプロセスこそ、未確認の取り消せない操作が最も起こりやすく、最も復旧が難しい場面です。

[A] の場合：ホットフィックスブランチを main にマージし、そのリリースに release/* ブランチがある場合はそこにもマージします。パッチリリース（次のパッチバージョン。例：v1.2.0 → v1.2.1）を修正済みビルドにタグ付けします。タグ付け先は release/* ブランチがある場合はその先端、ない場合はホットフィックスブランチの先端です。main の先端ではなく、そのタグをデプロイします。[B] の場合：main のみにマージします。リリースブランチへのマージ、タグ付け、デプロイは行いません。[C] の場合：停止します。マージ、タグ付け、デプロイ、バグファイルの更新は行いません。ホットフィックス記録の Status は IN PROGRESS のままにし、その旨を伝えます。

確認しない限り、バックポートが検証済みとは見なされません。 フロントマターには「バックポート確認済み」と記載されています。マージ後、修正が main（トランク）に反映されていることを確認し、その結果を報告します。そのリリースに release/* ブランチがある場合は、そこにも反映されていることを確認します。バックポートされていないホットフィックスは、main からタグ付けされる次のリリースでバグを再発させます。これはホットフィックスで最もよくあるリグレッションです。

元のバグファイルがある場合は更新します。/bug-report verify と同様に、production/qa/bugs/ から番号で該当ファイルを探します。まず、「production/qa/bugs/[bug file] に以下の修正記録を追加し、Status を Fixed — Pending Verification に更新してもよろしいですか？」と尋ねます。

## Fix Record
**Fixed in**: hotfix/[branch-name] — [commit hash or description]
**Fixed date**: [date]
**Status**: Fixed — Pending Verification

バグファイルのヘッダーに **Status**: Fixed — Pending Verification を設定します。

デプロイの概要を出力します。タイトルはフェーズ 6 の回答に従います。[A] の場合は Hotfix Deployed: [short-name]、[B] の場合は Hotfix Merged to main — release held: [short-name] とします。また、タグを作成していないため、[B] の場合は末尾の行から Tag を省略します。

## Hotfix Deployed: [short-name]

**Severity**: [S1/S2]
**Root cause**: [one line]
**Fix**: [one line]
**QA gate**: [Smoke check PASS / Team-QA APPROVED / NOT ASSESSED — [why, and whose
             explicit decision it was to deploy anyway]]
**Approvals**: lead-programmer ✓ / qa-tester ✓ / producer ✓
**Backport**: [verified present on `main` (and the `release/*` branch, if the
              release has one) — or NOT VERIFIED, with what was not checked]
**Rollback plan**: [from Phase 2 record]

Merge to: [targets] · Tag: [patch tag]
Next: /bug-report verify [BUG-ID] after deploy to confirm resolution

ルール

• ホットフィックスの変更は、問題を修正するために必要な最小限にとどめます。クリーンアップやリファクタリングは行いません。
• すべてのホットフィックスについて、デプロイ前にロールバック計画を文書化する必要があります。
• ホットフィックスブランチは、修正対象のリリース（そのタグ、または存在する場合はその release/* ブランチ）から作成し、main（トランク）にマージします。また、release/* ブランチが存在する場合に限り、そこにもマージしてパッチリリースにタグを付けます。
• すべてのホットフィックスについて、48 時間以内にインシデント後レビューを実施する必要があります。
• 修正に 4 時間を超える見込みがある場合は、technical-director にエスカレーションします。

---

フェーズ 7：デプロイ後の検証

デプロイ後に /bug-report verify [BUG-ID] を実行し、デプロイ済みビルドで問題が解決したことを確認します。

VERIFIED FIXED の場合：/bug-report close [BUG-ID] を実行して正式にクローズします。 STILL PRESENT の場合：ホットフィックスは失敗です。直ちにバグを再オープンし、ロールバックを評価してエスカレーションします。 CANNOT VERIFY の場合：修正は未確認です。バグをクローズしないでください。デプロイ済みビルドで再現手順を実行してから、/bug-report verify [BUG-ID] を再度実行し、手動での実行に関する質問に回答して確認を確定します。

48 時間以内にインシデント後レビューを予定します。/retrospective はスプリントやマイルストーンを振り返るもので、インシデントを対象とするものではありません。.claude/docs/templates/incident-response.md を使用してレビューを記録し、そこで得られた教訓を次回の /retrospective で共有します。

AskUserQuestion を使用します。

• プロンプト：「ホットフィックスが完了しました。次のステップは何ですか？」
• 選択肢：
  • [A] /smoke-check を実行して修正を検証する
  • [B] /patch-notes を実行してこのホットフィックスを文書化する
  • [C] ここで停止