test-recommendation

Test Recommendation Skill - 追加テスト提案フロー

役割

本スキルは追加テスト（ミューテーションテストと E2E テストの総称。自動実行される quality-check Step 2〜4 に対し、提案 → ユーザー判断を経て実行される）を担う。役割は次の 4 つ。

1. 提案ヒューリスティクスの判定 — 変更差分から推奨度（strong / recommended / none）を判定する
2. 推奨度 + 根拠の提示とユーザー判断の取得
3. 承認された追加テストの実行（E2E 実行時のサーバー起動・停止を内包する）
4. 永続台帳の管理（documents/development/test-recommendation-ledger.md）

quality-check の Step 5 は本スキルを参照実行する。それとは別に、開発中の任意タイミングで単体実行もできる（判定・提示・判断・実行・台帳更新は同一。記録先のみ異なる — 「記録」節参照）。判定・提示・実行・記録の手順は本スキルを単一ソースとし、quality-check 側には転記しない。

追加テストの見送り・実施後の生存ミュータントは記録のみ・非ブロックである（quality-check から実行された場合もフラグ作成をブロックしない）。唯一の例外は E2E を実施して失敗した場合で、実バグとして修正が必要になる（Step 4 参照）。

実行フロー

Step 1: 判定対象の差分取得 + 永続台帳の参照 + ヒューリスティクス判定
  ↓
Step 2: 推奨度 + 根拠の提示 → ユーザー判断の取得（none は提示せず記録のみ）
  ↓
Step 3: ミューテーション実行（承認時のみ。通過判定なし — 対処範囲をユーザーと合意）
  ↓
Step 4: E2E 実行（承認時のみ。サーバー起動 → シナリオ実行 → 必ず停止）
  ↓
Step 5: 永続台帳の更新 + 記録

---

Step 1: 判定対象とヒューリスティクス判定

判定対象

git diff origin/main...HEAD

ベース ref の解決は quality-check Step 1 と同一とする（既定は origin/main、無ければ origin/master、いずれも無ければローカルの main / master。探索順の正は quality-policy §2「差分スコープの定義」。基幹が異なるプロダクトは quality-check Step 1 と同じ ref を用いる）。単体実行時も同じ差分を判定対象とする。

判定の前に永続台帳（Step 5 参照）を読み取り、導線の状態（pending / scenario_added / dismissed）を判定に反映する。台帳が読み取れない場合の扱いは Step 5「生成と保全」に従う（黙って上書きしない）。

リスクレベルは、quality-check から実行された場合は Step 1 の判定結果（risk_level）を用いる。単体実行時は quality-policy §1 の定義に照らして判定する（判定基準の表は同 §1 を正とし、ここには転記しない）。

提案ヒューリスティクス: ミューテーション

トリガーは「テストスイートの判別力を疑うべきシグナル」と「メタ検証を掛ける価値のある重要なまとまり」に限る。個々のロジック変更では提案しない（ユニットテストの守備範囲にミューテーションを重ねない）。

推奨度	条件
強推奨（strong）	High リスク領域の中核ロジックのまとまった実装差分（決済・金額計算 / 認証・認可 / データ整合性を伴う状態遷移）
推奨（recommended）	テストの信頼性に疑義があるシグナル: ① 既存テストの期待値を実装に合わせて変更した ② まとまった新規ロジックに対しテストも同時に新規作成された（オラクルが実装と同時生成 = 相関故障リスク） ③ 追加ロジック量に対して追加テストが明らかに薄い
提案しない（none）	個別の条件分岐・境界値の変更（ユニットテストの守備範囲 — quality-check Step 3 と QAエンジニア（ファルシフィケーション型）で担保）/ 型・設定・文言のみ / テスト緑のままの純リファクタ