regression-suite

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow,qa.level,system_overrides

上記で解決済みです。そのまま使用してください。ブロックがない場合は、 .claude/docs/config-resolution.md のデフォルトを使用します。

回帰テストスイート

このスキルは、すべてのバグ修正に、元のバグを検出できたはずのテストが伴うこと、そしてゲームの進化に合わせて回帰テストスイートが最新の状態に保たれることを保証します。また、対応する回帰テストのカバレッジがないまま新機能が追加された場合も検出します。

回帰テストスイートは新しいテストカテゴリではありません。ゲームの重要な経路と既知の障害箇所を総合的にカバーする、tests/ 内にすでにあるテストを厳選してまとめたリストです。このスキルは、そのリストを維持します。

出力: tests/regression-suite.md

実行するタイミング:

• バグ修正後（回帰テストが作成されたことを確認するか、カバレッジの不足を特定します）
• フェーズゲートの前 — qa.level: full の場合、/gate-check で回帰テストスイートが必須です
• カバレッジのずれを検出するため、スプリントの締めくくりの一環として

---

すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います （collaborative では常に質問 · guided では主要な場合のみ · autonomous では記録して続行； automation_always_ask のカテゴリでは常に質問します）。

ワークフローのティア: 上記で解決された modes.workflow — 明示的に設定されていない場合は modes.rigor によって指定されます — .claude/docs/workflow-modes.md に従います。audit モードでは、各 GDD を読み込む際にシステムごとの workflow_overrides.system_overrides.<system> を考慮します。ワークフローのティアによって、GDD の重要な経路をマッピングするか、カバレッジをスモークテストのみにするかが決まります — Step 2c を参照してください。

qa.level: 回帰テストスイートを生成するかどうかを制御します。minimal では回帰テストスイートは生成されません（その旨を報告して終了します）。standard では Polish ステージ開始時に生成し、full では Production ステージ開始時に生成します。workflow とは別の軸です。

1. 引数の解析

早期の qa.level ガード（上記で解決済み）: qa.level: minimal の場合、回帰テストスイートは生成されません。すべてのモード（update / audit / report）で「Regression suite not generated at qa.level minimal」と報告し、スキャンを始める前に、ここで直ちに終了してください。これは qa.level の軸であり、Step 2c の workflow ティアにおける minimal 分岐（変更するのは重要な経路の情報源のみであり、スイートを実行するかどうかではありません）とは別です。qa.level を理由に Step 2c の minimal 分岐に入らないでください。この終了時の判定は NOT ASSESSED（Section 7）です。このレベルではテストは必須ではなく、何もスキャンされていません。

モード:

• /regression-suite update — 今回のスプリントで新たに修正されたバグをスキャンし、回帰テストの有無を確認します。新しいテストをスイートのマニフェストに追加します
• /regression-suite audit — すべての GDD の重要な経路と既存のテストカバレッジを全面的に監査し、回帰テストがない経路を明示します
• /regression-suite report — 読み取り専用の状況レポート（書き込みなし）です。スプリントレビューに適しています
• 引数なし — スプリントが明らかに進行中の場合（スプリント計画があり、進行中のストーリーがある場合）は update を実行します。状況が不明確な場合、または進行中のスプリントが検出されない場合は、AskUserQuestion を使用します。
  • プロンプト: 「サブコマンドが指定されていません。どのモードを実行しますか？」
  • 選択肢:
    • [A] update — 今回のスプリントで新たに修正されたバグをスキャンし、不足している回帰テストを追加する
    • [B] audit — すべての GDD の重要な経路と既存のテストカバレッジを全面的に監査する
    • [C] report — 読み取り専用の状況レポート（書き込みなし）

---

2. コンテキストの読み込み

Step 2a — 既存の回帰テストスイートを読み込む

tests/regression-suite.md が存在する場合は読み込みます。以下を抽出します。

• 登録済みの回帰テストの合計数
• 最終更新日
• STALE または QUARANTINED としてフラグが付けられたテスト

存在しない場合は、「回帰テストスイートが見つかりません — 作成します」と記録します。

Step 2b — テスト一覧を読み込む

すべてのテストファイルを Glob で検索します。

tests/unit/**/*_test.*
tests/integration/**/*_test.*
tests/regression/**/*

各ファイルについて、システム（ディレクトリパスから取得）とファイル名を記録します。 名前とテストの対応付けに必要な場合を除き、テストファイルの内容は読み込まないでください。

ステップ 2c — GDD のクリティカルパスを読み込む

audit モードの場合：design/gdd/systems-index.md を読み込んですべてのシステムを確認し、各システムのワークフロー階層（上記で解決済み）に応じてスキャン範囲を設定します。

• full — GDD を読み込み、すべてのセクションからクリティカルパスを特定します。
• standard — 必須セクション（Acceptance Criteria、Edge Cases、およびシステムで数値ルールが定義されている場合は Formulas）から、同様に特定します。 system_overrides によって上位の階層に固定されたシステムは、その上位階層でマッピングします。
• minimal — GDD のクリティカルパススキャンをスキップします。代わりに、production/qa/smoke-*.md にある最新のスモークチェックレポートを読み込み、そこで実施されているクリティカルパスを回帰テストの対象範囲として使用します（ステップ 3 では GDD の受け入れ基準ではなく、それらに対するカバレッジをマッピングします）。スモークレポートがない場合は、Verdict: 評価不能 — クリティカルパスの参照元となるスモークレポートがありません — で停止します。スモークレポートがない場合、minimal にはクリティカルパスの参照元がありません。先に /smoke-check を実行してください。

（階層が影響するのは audit モードのみです。update モードと report モードは階層に依存しません。）

GDD はセクションごとに読み込みます。必要な見出しは Grep ツール（パターン ^#、content モード）で探し、該当範囲を offset と limit を指定して Read します。full では、40 KB を超えるファイル全体の Read は拒否されるため、範囲を指定してすべてのセクションを読み込みます。

対象範囲に含まれる MVP 階層の各システムの GDD から、以下を抽出します。

• Acceptance Criteria（クリティカルパスを定義します）
• Formulas セクション（数式には回帰テストが必要です）
• Edge Cases セクション（既知のエッジケースには回帰テストが必要です）

update モードの場合：GDD 全体のスキャンをスキップします。代わりに、現在のスプリント計画とストーリーファイルを読み込み、今スプリントで Status: Complete となっているストーリーを探します。

ステップ 2d — クローズ済みのバグを読み込む

production/qa/bugs/*.md を Glob し、Status: Closed または Status: Fixed フィールドがあるバグに絞り込みます。以下を記録します。

• バグが発生したストーリーまたはシステム
• 修正の説明に回帰テストへの言及があったかどうか

---

3. カバレッジをマッピング — クリティカルパス

audit モードのみ。minimal では、クリティカルパスは GDD の受け入れ基準ではなく、ステップ 2c で特定したスモークチェックレポートから取得します。スモークパスに対するカバレッジをマッピングし、以下の GDD 基準のループはスキップしてください。

各 GDD の受け入れ基準について、テストが存在するかどうかを判断します。

1. tests/unit/[system]/ と tests/integration/[system]/ を Grep し、基準の主要な名詞や動詞に関連するファイル名と関数名を探します。
2. カバレッジを割り当てます。

状態	意味
COVERED	この基準のロジックを対象とするテストファイルが存在します
PARTIAL	テストは存在しますが、すべてのケースを網羅していません（例：正常系のパスのみ）
MISSING	このクリティカルパスのテストが見つかりません
EXEMPT	Visual/Feel または UI の基準であり、設計上、自動化できません

3. 数式または状態機械に関連する MISSING 項目は、HIGH PRIORITY のギャップに引き上げます。これらは回帰の原因となる可能性が最も高いものです。

---

4. カバレッジをマッピング — 修正済みのバグ

クローズ済みのバグごとに、以下を行います。

1. バグのメタデータからシステムのスラッグを抽出します。
2. tests/unit/[system]/ と tests/integration/[system]/ を Grep し、バグ ID または具体的な失敗シナリオを参照するテストを探します。
3. 以下を割り当てます。
   • HAS REGRESSION TEST — このバグを検出できるテストが見つかりました
   • MISSING REGRESSION TEST — バグは修正されましたが、再発を防ぐテストがありません

MISSING REGRESSION TEST 項目について：

• 回帰のギャップとしてフラグを付けます
• テストファイルのパスを提案します：tests/unit/[system]/[bug-slug]_regression_test.[ext]
• 次のように記載します：「このテストがなければ、今後のスプリントでこのバグが気付かれないまま再発する可能性があります。」

---

5. カバレッジのドリフトを検出する

ゲームが拡大しても、回帰テストスイートが更新されない場合、カバレッジのドリフトが発生します。

ドリフトの兆候を確認します：

• 今スプリントで完了したストーリーに対応するテストファイルが tests/ にない
• 前回の回帰テストスイート更新以降に、systems-index.md に新しいシステムが追加されている
• 回帰テストスイートの前回の更新以降に、GDD のセクションが追加または修正されている （利用可能な場合は Grep で GDD ファイルの変更履歴を確認するか、ユーザーに尋ねます）
• tests/regression-suite.md の最終更新日と現在の日付の差が 2 スプリントを超える場合、古くなっている可能性が高いと報告します

---

6. レポートとスイートマニフェストを生成する

レポート形式（会話内）

## Regression Suite Status

**Mode**: [update | audit | report]
**Existing registered tests**: [N]
**Test files scanned**: [N]

### Critical Path Coverage (audit mode only)
| System | Total ACs | Covered | Partial | Missing | Exempt |
|--------|-----------|---------|---------|---------|--------|
| [name] | [N] | [N] | [N] | [N] | [N] |

**Coverage rate (non-exempt)**: [N]%

### Bug Regression Coverage
| Bug ID | System | Severity | Has Regression Test? |
|--------|--------|----------|----------------------|
| BUG-NNNN | [system] | S[N] | YES / NO ⚠ |

**Bugs without regression tests**: [N]

### Coverage Drift Indicators
[List new systems or stories with no test coverage, or "None detected."]

### Recommended New Regression Tests
| Priority | System | Suggested Test File | Covers |
|----------|--------|---------------------|--------|
| HIGH | [system] | `tests/unit/[system]/[slug]_regression_test.[ext]` | BUG-NNNN / AC-[N] |
| MEDIUM | [system] | `tests/unit/[system]/[slug]_test.[ext]` | [criterion] |

スイートマニフェストの形式（tests/regression-suite.md）

カバレッジを計算する前に、分母を確認してください。 GDD の glob がクリティカルパスを 1 つも返さない場合、またはテストの glob がテスト ファイルを 1 つも返さない場合、パーセンテージを出力せず、 Coverage: NOT ASSESSED — [no GDDs found | no test files found] と報告し、どちらが空だったか、 およびそれを生成するスキル（GDD の場合は /map-systems と /design-system、テストのスキャフォールドの場合は /test-setup）を明記します。

空の分母から計算したパーセンテージは、低いスコアではありません。数値ではありません。 0% は「測定した結果、ひどい」と読み取られ、100% は「測定した結果、完璧」と読み取られますが、 どちらも比較が行われていないにもかかわらず比較について主張しています。これは /scope-check に Phase 4 のガードが同じ文言で設けられているのと同じ問題です： 「ベースライン項目がない状態から計算されたパーセンテージは、小さい数値ではありません。数値ではありません。」

マニフェストは厳選されたインデックスです。テストそのものではなく、リリース前に必ず合格すべきテストを登録したものです：

# Regression Suite Manifest

> Last Updated: [date]
> Total registered tests: [N]
> Coverage: [N]% of GDD critical paths

## How to run

[Engine-specific command to run all regression tests]

## Registered Regression Tests

### [System Name]

| Test File | Test Function (if known) | Covers | Added |
|-----------|--------------------------|--------|-------|
| `tests/unit/[system]/[file]_test.[ext]` | `test_[scenario]` | AC-N / BUG-NNNN | [date] |

## Known Gaps

Tests that should exist but don't yet:

| Priority | System | Suggested Path | Covers | Reason Not Yet Written |
|----------|--------|----------------|--------|------------------------|
| HIGH | [system] | `tests/unit/[system]/[path]` | BUG-NNNN | Bug fixed without test |

## Quarantined Tests

Tests that are flaky or disabled (do not run in CI):

| Test File | Function | Reason | Quarantined Since |
|-----------|----------|--------|-------------------|
| (none) | | | |

---

7. 出力を書き込む

update または audit モードでは、「現在の回帰テストスイートマニフェストを tests/regression-suite.md に書き込む／更新してもよいですか？」と尋ねます。

update モードの場合：新しい項目を追加し、既存の項目は削除しません （対象を絞った挿入には Edit を使用します）。 audit モードの場合：カバレッジデータを更新してマニフェスト全体を書き直します。 report モードの場合：何も書き込みません。

書き込みが承認された後：

• 優先度が HIGH のギャップごとに：「次のスプリントまでに、欠落している回帰テストを作成することを検討してください。 /test-helpers を実行すると、テストファイルをスキャフォールドできます。」
• バグの回帰ギャップが 0 より大きい場合：「回帰テストがないと、これらのバグが気づかれないまま再発する可能性があります。 次のスプリントには、欠落しているテストを作成するストーリーを含めてください。」
• カバレッジのドリフトが検出された場合：「回帰テストスイートにドリフトが生じている可能性があります。 次のスプリントの区切りで /regression-suite audit を実行することを検討してください。」

スプリントがない workflow: minimal では、上記 3 行の「次のスプリント」を「次のストーリー」とします。

判定は最初に一致したものが適用されます：

• NOT ASSESSED — Section 1 の qa.level: minimal による停止：「Regression suite not generated at qa.level minimal」。このレベルではテストは必須ではないため、スキャンも書き込みも行われていません。
• NOT ASSESSED — 上記の minimal による停止：クリティカルパスの取得元となるスモークレポートがありません。解決策として /smoke-check を明記します。
• NOT ASSESSED — カバレッジが Coverage: NOT ASSESSED — [reason]（GDD がない、または テストファイルがない）となった場合、理由を明記します。計算されていないカバレッジ数値について COMPLETE と報告してはいけません。
• BLOCKED — update または audit モードで、ユーザーが書き込みを拒否した場合。
• COMPLETE — update／audit：回帰テストスイートが更新された場合。report：カバレッジレポートが表示された場合（report モードでは何も書き込みません）。

---

協調プロトコル

collaborative モード（デフォルト）に適用されます。 guided モードと autonomous モードについては、.claude/docs/automation-modes.md を参照してください。以下のルールは、 協調モードで求められる内容を説明するものであり、すべてのモードに共通する動作ではありません。

• 明示的なユーザーの承認なしに、マニフェストから既存の回帰テストを削除しないでください — 意図的に作成されたテストを削除すること自体が、 回帰リスクになります
• ギャップは参考情報であり、作業を妨げるものではありません — ギャップを明確に示しつつ、ほかの作業を妨げないでください（qa.level: full の場合を除きます。この場合、フェーズゲートで回帰テストスイートが必須となります）
• 隔離は削除ではありません — 断続的に失敗するテストはマニフェストに記録して隔離しますが、削除しないでください。/test-flakiness で修正してください
• 書き込む前に確認してください — マニフェストを作成または更新する前に、必ず確認してください