Test Recommendation Skill - 追加テストの判定と実施

役割

本スキルは追加テスト（ミューテーションテストと E2E テストの総称。常に実行される quality-check Step 2〜4 に対し、推奨度と範囲で実施を決める）を担う。役割は次の 4 つ。

1. 提案ヒューリスティクスの判定 — 変更差分から推奨度（strong / recommended / none）を判定する
2. 区分: 自動実施（確認なし）/ 確認（最後の 1 通で聞く）/ 記録のみ
3. 自動実施分と、確認で実施と決まった追加テストの実行（E2E 実行時のサーバー起動・停止を内包する）
4. 永続台帳の管理（documents/development/test-recommendation-ledger.md）

quality-check の Step 5 は本スキルを参照実行する。それとは別に、開発中の任意タイミングで単体実行もできる（判定・区分・実行・台帳更新は同一。記録先のみ異なる — 「記録」節参照）。判定・区分・実行・記録の手順は本スキルを単一ソースとし、quality-check 側には転記しない。区分の数値（範囲の上限）は quality-policy §2「自動実施の範囲の上限」を正とする。

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

実行フロー

Step 1: 判定対象の差分取得 + 永続台帳の参照 + ヒューリスティクス判定
  ↓
Step 2: 区分（自動実施 / 確認 / 記録のみ）→ 自動実施分は確認なしで Step 3・4 へ。確認の対象は最後の 1 通で聞く
  ↓
Step 3: ミューテーション実行（自動実施分・確認で実施と決まった分。通過判定なし — 生存の対処は既定の規則で AI が決める）
  ↓
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エンジニア（ファルシフィケーション型）で担保）/ 型・設定・文言のみ / テスト緑のままの純リファクタ

提案ヒューリスティクス: E2E

E2E はフロントメイン・シナリオベースとする。バックエンドの API 検証は quality-check Step 3 の統合テストで担保するため、「フロントとバックにまたがる」ことは E2E の提案理由にしない。

推奨度	条件
強推奨（strong）	既存 E2E シナリオの通過経路（画面・ルート・導線）に触れるフロント変更 / High リスク領域を通る新規導線の追加（シナリオ起草 + 実行を提案）
推奨（recommended）	新規導線の追加でシナリオ未整備（シナリオ起草 + 実行を提案）
提案しない（none）	バックエンドのみの変更 / シナリオ経路外のフロント変更 / docs・infra のみ

付帯規則

• 「既存 E2E シナリオの通過経路」は、プロダクトの E2E テストスイート（Playwright 等の spec）が参照する画面・ルートと変更ファイルの突き合わせで判定する。E2E スイートが存在しないプロダクトでは既存経路判定をスキップし、新規導線の検出のみ行う
• 突き合わせは変更ファイル側を起点とする: 変更したフロント画面・ルートのパス識別子を抽出し、それを検索語として E2E spec を grep する（spec 全体の読み込みはしない）。grep でも判定が確定しない場合はその事実を recommendation_basis に記録して recommended に倒す（走査を続けない）
• 複数条件に該当する場合は最も高い推奨度を採用する
• ミューテーションはツール（Stryker / PIT）未導入なら提案しない。not_configured を記録し、必要なら lint-scaffolding を案内する（ミューテーション設定の配線は同スキル Step 3-3。現行の quality-check と同じ扱い）
• 判定不能の対象は recommended に倒して提示する（E2E spec の経路突き合わせ不能等。提案しない側に倒すと黙って穴になる）。判定不能であった事実を根拠欄（recommendation_basis）に記録する
• 推奨度の記録値は strong / recommended / none の 3 値

未実行理由の優先順位

追加テストを実行しない場合の記録は、次の優先順位表で決める（上から先に一致した行を記録する）。

条件	記録
quality-check の領域テーブルで Step 3 欄が -（docs のみ / infra のみ）	ミューテーションのヒューリスティクス判定を行わない。mutation: { executed: false, reason: "out_of_scope" } を記録し recommendation 以下は省略する（quality-policy §2「マトリクス優先順位原則」 — 領域による対象外を最優先）。E2E は領域による対象外を設けず、ヒューリスティクスで none と判定して記録する
ツール（Stryker / PIT）未導入	提案しない。reason: "not_configured" を記録し recommendation 以下は省略する（lint-scaffolding を案内する）
上記以外で推奨度 none	reason: null / recommendation: "none" / user_decision: "not_proposed" を記録する
実施が決まった後に空スコープ / 導出失敗 / ツール起動失敗	reason: "empty_scope" / "scope_error" / "tool_error" を記録する（「実行の失敗」節参照）

---

Step 2: 区分（自動実施 / 確認 / 記録のみ）

推奨度が strong / recommended の対象を、次の区分に分ける（none は従来どおり記録のみ）。

区分	条件	動き
自動実施	次のすべてを満たす: 推奨度が strong ／ 範囲が小さい（quality-policy §2「自動実施の範囲の上限」以内）／ 副作用が無い（下記）／ 同じ対象をユーザーが見送った記録が無い（下記「ユーザーの見送りと AI の持ち越し」）	確認せずに Step 3・4 で実施する。decided_by: "auto" を記録し、結果は PR 本文に書く
確認	上のどれかを満たさない（recommended、判定不能で recommended に倒したもの、範囲が大きい、副作用がある、過去にユーザーが見送った）	途中では止まらず、最後の 1 通（documents/development/development-policy.md §1.0「承認後の進め方」）の「判断が必要なこと」で、推奨度・根拠・範囲の大きさ・見込みの時間を添えてまとめて聞く。decided_by: "user"
記録のみ	none	提示しない。判定結果だけを記録する

副作用が無いこと（E2E）: プロジェクトの固定ポートで、他プロジェクトのプロセスを止めずにサーバーを起動できる（quality-check Step 1 のポート確認の結果を使う）／ 個人の認証情報・手作業のログイン・有料の外部 API など、AI が自分で用意できないものを必要としない ／ E2E スイート・実行手段が導入済み ／ 接続先が server-startup で起動したサーバーとローカル（使い捨て）の DB・モックに閉じ、共有環境（共有の開発 DB・staging 等）や外部サービスへの書き込み・送信をしない（判断できなければ確認の区分）。server-startup の停止規則は変えない（自動実施だけ一段厳しい条件にする）。

確認の対象があるときの順序（quality-check から実行された場合）: 自動実施分の実行 → Step 5 の差分のコミット → --check-untracked で未追跡の確認（最初の push の前。quality-check Step 6 の手順）→ push → PR 作成 → 最後の 1 通 → 返答 → 実施と決まったものを実行・記録し、同じ PR にコミット → PR 本文の更新 → quality-check Step 6（フラグ作成。設計との差異の項目がある場合は、その項目への OK を受けてから）→ PR 本文の Flag commit を更新 → push（その後にマージ）。PR は通常の PR で作り（draft にはしない）、本文に「確認待ち」と書く。リモートや PR を使わないプロジェクトでは push・PR を省き、仕上げた feature ブランチで最後の 1 通を送る（documents/development/development-policy.md §1.0「承認後の進め方」7）。確認待ちの PR は、その PR の作業ツリーで、返答 → フラグ作成の後にだけマージする（別の作業ツリーから PR 番号を指定してマージしない）。返答までフラグは作らない。返答を受けたら Step 0 からやり直さず、ここから再開する（.quality-check-report.json を残す）。

確認で示す選択肢:

対象	選択肢
ミューテーション	① 実施 ② 見送り（2 択）
E2E（既存シナリオ経路）	① 実施 ② 見送り（2 択）
E2E（新規導線・シナリオ未整備）	シナリオのドラフトを提示した上で ① シナリオ追加 + 実行 ② シナリオ追加のみ（実行見送り） ③ 見送り（3 択）

• 確認は最後の 1 通に纏める: 確認の区分のミューテーションと E2E（既存シナリオ経路・新規導線。新規導線のシナリオドラフトを含む）を、設計との差異の報告と同じメッセージで示し、判断も 1 往復で取る。対象ごとに順に聞かない。見送りの理由も同じ回答で受け取れるよう求めておく（理由が無ければ「理由の記載なし」と記録し、聞き直さない）
• E2E スイート・実行手段が未導入のプロダクトでは、新規導線の 3 択から「実行」を除いた 2 択（① シナリオ追加のみ ② 見送り）で提示する（recommendation_basis に未導入の事実を記録する）
• シナリオドラフトの根拠は機能ドキュメント・要件（documents/features/ 等）から導出し、実装コードから逆算しない（quality-policy §4 のテストオラクル原則と同じ規律）
• 推奨度 none の対象は提示せず、判定結果のみを記録する（「記録」節参照）
• 見送りが選ばれた場合は理由（上記の回答で受領）を decline_reason と永続台帳に記録する
• 確認の区分にした理由（範囲が大きい・副作用・recommended・過去の見送り）を recommendation_basis に書く
• 単体実行時も同じ区分・実行・記録を行う（確認の対象は、その作業の最後の報告で聞く）

---

Step 3: ミューテーション実行手順（自動実施分・確認で実施と決まった分）

前提: テストが緑であること

ミューテーションはテストスイートが全て成功している状態でのみ実行する。quality-check から実行される場合はサイクル完了後（テスト緑確認後）に到達するためこの前提は満たされている。単体実行時はテストを実行して緑を確認してから起動する。今回の作業による失敗なら直してから実行する（通常の作業）。今回の作業と無関係な失敗なら実行せず、その事実を記録して最後の報告に 1 行書く（ユーザーに途中で確認しない）。

差分スコープとベース ref

差分スコープ・ベース ref の規律は従来どおりとする。

• 差分スコープ = 変更行（Stryker: mutation:diff が、ベース ref との merge-base に対する作業ツリーの差分の hunk を行範囲として mutate に渡す。glob 特殊文字を含むパスはファイル単位に縮退）または変更クラス（PIT: mutationDiff -PmutationDiffBase=origin/main）。定義は quality-policy §2「差分スコープの定義」を正とする。変更ファイル全体・プロジェクト全体のフル実行は行わない
• ベース ref は Step 1 の判定対象と同じ基幹でなければならない（基幹が異なるプロダクトは MUTATION_BASE_REF で Step 1 と同じ ref を指定する）。HEAD は Step 1 の基幹になり得ないため無効: MUTATION_BASE_REF=HEAD の計測、および stderr に [mutation:diff] warning: ... resolves to HEAD itself が出た計測（作業ツリーの未コミット行のみのスコープ）は、ゲートの計測（executed）として記録しない。その場合は Step 1 の基幹を MUTATION_BASE_REF に指定して再実行し（runs に数えない）、基幹を解決できないときは scope_error として記録する。基幹を指定しても同じ警告が出るのは Step 1 の差分（origin/main...HEAD）が空、すなわち変更がまだコミットされていない状態なので、コミットしてから quality-check を実行する（exit 0 の実行を scope_error として記録しない）。使用した ref を mutation.base_ref に、粒度を mutation.scope（changed_lines / changed_classes。旧配線のままファイル単位で実行された場合は changed_files — lint-scaffolding の再配線を案内する）に記録する

実行手順

1. mutation:diff（JS）/ mutationDiff（Java）を実行し、レポート（Stryker: reports/mutation/mutation.json / PIT: build/reports/pitest/mutations.xml）からミュータント総数・生スコア・生存ミュータントを読み取る（killed / 生存 / 集計外の status 対応は quality-policy §2「ツール status との対応」— NoCoverage は生存として台帳に載せる）
   • 実行単位が複数に分かれる構成（PIT をモジュールごとに適用したマルチモジュール等）では各単位のレポートを全て読み、ミュータント総数（quality-policy §2「ツール status との対応」の集計外を除いた値）・生存を合算する。生スコアは合算後の killed と合算後のミュータント総数から算出し、1 単位のスコアを全体の値として記録しない（合算は各単位のツール生値を足し合わせるだけで、トリアージによる調整は行わない）
2. 生存ミュータントを mutation.survivors に一覧化する（テスト設計メモの不変条件・ファルシフィケーション項目に対応する変更行のものは memo_linked: true とする）
3. 各生存ミュータントをトリアージする（下記「トリアージ規律」。決定値・カテゴリの一覧は quality-policy §2 を正とする）
4. スコア・生存台帳・トリアージ結果を記録し、生存の対処を既定の規則で AI が決める（下記「通過判定なし」）。結果は PR 本文に書き、持ち越しがあれば最後の報告に 1 行書く

通過判定なし — 生存の対処は既定の規則で決める

本スキルのミューテーションに通過判定はない。 スコアは参考情報として記録するのみで、いかなる基準との比較もブロックには用いない。生存ミュータントへの対処は、ユーザーと合意せずに次の既定の規則で AI が決める（自動実施・確認で実施のどちらでも同じ）— いずれもブロックしない。① memo_linked: true を先に、撃殺できるものは撃殺テストを追加する（red-green 検証、1 実行あたり最大 5 件 — 「トリアージ規律」）② equivalent は 1 件ずつ論証できたものだけ ③ 残りは unresolved として台帳に持ち越す（「台帳更新」の書き方に従う）。

対処	内容
その場でテスト追加	撃殺テストを追加する（red-green 検証必須 — 下記）。再計測は対処予定の生存を全て処理してから 1 回だけ行い（1 件ごとに再計測しない）、台帳を更新する。撃殺テスト・台帳更新の差分は quality-check Step 6 のフラグ作成より前にコミットする（「台帳更新」節のコミット順序参照）
台帳に持ち越し	生存への対処を持ち越す。永続台帳のミューテーション見送り履歴に対象領域・理由を記録する
対処不要と判断	理由を記録して確定する（equivalent / accepted の論証がある場合）

• memo-linked の生存を優先して対処する（テスト設計メモの不変条件・ファルシフィケーション項目に対応する生存を先に撃殺テストの対象にする）

incremental と再実行

同一ブランチ内での再実行（撃殺テスト追加後の再計測）では Stryker の incremental を許可する。

初回計測は MUTATION_INCREMENTAL を明示的に外して（キャッシュなしで）行い、撃殺テスト追加後の再計測を MUTATION_INCREMENTAL=1（Windows は cross-env / $env:。受理値・キャッシュの仕組み・その限界は stack README「Re-measurement」を正とする）で実行する。実行時に stderr へ出る [mutation:diff] incremental: 行（reusing / starting / disabled for this run — 最後は前回キャッシュを削除できずキャッシュ無しで実行した意味）を確認し、キャッシュを再利用した計測かどうかを mutation.incremental に記録する（reusing のみ true。スキーマ参照）。キャッシュの再利用判定は行番号ベースであり、同一ファイルの大きな編集ではキャッシュ由来のミュータントが変更行の外に現れうる（README が明記する残存制限）。変更行以外の行に生存が報告された場合は、フラグを外して 1 回だけ再実行して確認する — この確認実行は mutation.runs に数え、上限（「実行回数の上限」）を超える場合は実行せず、該当する生存を unresolved として持ち越す（承認は求めない）。

実行回数の上限

1 回の quality-check（単体実行時は 1 セッション）でのミューテーション実行は、初回計測 1 回＋縮退再試行 1 回＋撃殺テスト追加後の再計測 1 回の最大 3 回とする。上限に達したら追加の実行はせず、残りの生存を unresolved として持ち越して記録する（承認は求めない）。実行回数は mutation.runs に記録する（バジェットの数値・キーは従来どおり quality-policy §2 を参照する。縮退再試行が 1 回である旨も同 §2 を正とする）。計測が一切得られなかった試行（tool_error / scope_error で終了し、解消手順を試して再試行した場合）は runs に数えない。

バジェット

実行時間バジェットの既定値と上書きキーは quality-policy §2「上書きの契約」を参照する（数値・キー名は本スキルに置かない）。超過時は縮退再試行（スコープ絞り込み。絞った場合は mutation.scope_reduced に記録）を行い、それでも完走できない場合は正規 outcome として aborted_reason: "unmeasurable_within_budget" を記録して先へ進む（非ブロック）。

トリアージ規律

• equivalent 判定の基準: 結果が同一でも、副作用・発行文数・実行経路の観測可能な差を生む変異は equivalent としない。複数変異の一括判定をしない。 判断根拠を 1 件ずつ記録する。「観測可能な挙動がその関数に到達しうる入力全体で不変」を論証できたときにのみ equivalent と判定する（「現行テストで落ちない」は根拠にならない）。その論証は呼び出し元の現在の構成（「今の呼び出し元は空配列を渡さない」等）に依存させず、関数契約（不変条件）と直接入力テストで関数境界に閉じて行う — 呼び出し元に依存した論証は呼び出し元が増えた時点で無効になる
• red-green 検証: 撃殺テストは、変異を一時適用 → テストが赤になることを確認 → 変異を復元 → 緑に戻ることを確認 — を経てから killed を主張する。この検証なしに killed を主張してはならない。検証時に実行するのは当該テストファイル（対象テストのみ）とし、スイート全体は回さない。検証を要するのは killed を主張する生存に限り、1 実行あたり最大 5 件（memo_linked: true を優先）。上限超過分は unresolved として台帳に持ち越す（非ブロック）
• tool_false_negative（ツール偽陰性）: トリアージ決定値に含まれる。Stryker の static: true かつ Survived のミュータントは機械判定でこれに分類する。 score_raw はツール算出の生値であり tool_false_negative を含む。台帳に件数を明示し、スコアの解釈時に差し引いて読む
• 再計測（撃殺テスト追加後）や同一ブランチでの quality-check 再実行で、前回計測の生存台帳（mutation.survivors — 永続台帳は生存を行単位で持たない）にない生存が出た場合: 前回の生存台帳と突き合わせる前に、その行が今回の差分で初めてスコープ入りしたかを確認する（前回計測の生存台帳が参照できない場合は、この確認のみを行う）。変更行スコープは行単位のため、非挙動差分（className・整形・同一行にある別の式の編集）でも同じ行の既存の分岐が対象に入る（変更行の上位集合 — 設計どおりの挙動であり、今回の修正が欠陥を持ち込んだことを意味しない）。非挙動差分でスコープ入りした既存分岐の生存は「既存コードのテスト欠落の発見」として扱い、第一選択として撃殺テストを追加する。再計測で出た生存に追加した撃殺テストは red-green 検証で担保し、そのための再計測は行わない（実行回数の上限 — 超過する再計測はしない）。red-green の上限（1 実行あたり 5 件）を超える分と対処しない分は unresolved として台帳に持ち越す（非ブロック）

運用上の教訓

• ミュータントの id は実行のたびに変わる。生存の台帳は file:line:mutator:replacement を鍵にする
• related テストが 0 件のときは ConfigError になる。その場合は、そのファイルのテストを明示して実行する
• 台帳は追記だけにし、判断 1 件につき 1 エントリ（1 行）にする

実施結果の検証（QAエンジニア（ファルシフィケーション型））

ミューテーションを実施し、memo_linked: true の生存または equivalent / accepted 判定が残った場合は、QAエンジニア（ファルシフィケーション型）1 体を（起動前に review-budget begin --phase mutation --roles falsification-qa で予約し、）サブエージェントとして起動し、台帳の分類妥当性を検証する（指摘が出ても非ブロック。指摘に従って分類を直し、直さない指摘は理由を記録する。ユーザーと合意しない）。mutation フェーズの予約は 1 回で延長できない。上限なら検証を追加せず、残りを記録して進む。実装者の自己トリアージだけで分類を確定しない。 使用モデルは quality-check SKILL.md Step 4「使用モデル（必須）」の規定に従う。

担保範囲注記

ミューテーションの実施・生存ゼロは、行網羅・配線検証の証明ではない。 既知の穴として、Stryker は ObjectLiteral を既定で除外しており、また呼び出し引数の識別子置換（引数に別の変数を渡す誤り等）には変異が生成されない。ミューテーション結果を「この行がテストされている」「この配線が正しい」の証明として扱ってはならない。

実行の失敗（empty_scope / scope_error / ツール起動失敗）

状況	挙動
差分スコープが空（mutation:diff / mutationDiff が終了コード 0 + empty scope メッセージで終了。実行して初めてミュータント数 0（全て除外種別等）と判明した場合も同様。実行単位が複数に分かれる構成（PIT をモジュールごとに適用したマルチモジュール等）では各単位が自分の行を出すため、どの単位もミュータントを 1 つも生成しなかった（empty scope 行、またはスコープはあるがミュータント数 0 で完走）ときだけ空スコープとする — 1 単位の行で全体を判定しない。本行が空スコープ判定の正であり、スタック README は観測される出力の説明として参照する）	実行しない（または実行結果を破棄する）。reason: "empty_scope" を記録する（提示・確認はしない）
差分スコープの導出に失敗（ベース ref 未取得・ローカル基幹が HEAD と同一・スコープとして表現できないパス（Stryker の否定パターンと衝突する ! 始まりのルート直下パス）・前回のレポートを削除できない（ディレクトリや実行ディレクトリ外を指す jsonReporter.fileName は削除しない）、等で非 0 終了。cannot resolve the merge base / no base ref found / cannot scope 等）	empty_scope として記録してはならない。 reason: "scope_error" を記録し、エラーメッセージが示す解消手順（git fetch origin main、MUTATION_BASE_REF の設定、ファイルの改名または mutate グロブからの除外、レポートの手動削除または jsonReporter.fileName の修正 等）を AI が 1 回試して再実行する。解消しなければ記録して最後の報告に 1 行書く。非ブロック
ツールの起動失敗	解消手順を AI が 1 回試して再実行する。解消しなければ reason: "tool_error" を記録し（非ブロック）、最後の報告に 1 行書く

ミューテーションテストはローカルで実行し、CI には組み込まない（quality-policy §2「ミューテーションテストの実行ポリシー」）。ミュータント単位のタイムアウトは Stryker / PIT の組み込み機構をそのまま使う。

---

Step 4: E2E 実行手順（自動実施分・確認で実施と決まった分）

1. サーバー起動: server-startup スキルに従って起動する
2. シナリオ実行: 自動実施分と、確認で実施と決まったシナリオ（既存シナリオ / 起草・追加した新規シナリオ）を実行する。新規シナリオは機能ドキュメント・要件から起草する（実装から逆算しない）
3. サーバー停止（必須）: 実行後は必ず停止する。起動したまま放置するとプロセスが大量に残りリソースを消費する

• 失敗は実バグとして修正する（追加テストで唯一のブロック要素）。修正後は影響範囲のみ再検証する（静的チェック・該当テスト・E2E の再実行。quality-check のサイクルには含めず、Step 2 からの再実行もしない）
• 修正 → 再検証の反復は最大 2 回とする。 2 回で緑にならない場合はユーザーに判断を仰ぐ（documents/development/development-policy.md §1.0「承認後の進め方」 の例外 X5）— ① 方針を変えて修正を継続する（変更する方針を明示させる — 方針の変更がない再実行は認めない。継続後の反復にも同じ上限（最大 2 回）を再適用し、上限到達のたびに本判断へ戻る — 都度ユーザーの明示選択が必要）② 中断する（フラグは作成されない）。E2E の失敗を受容したままフラグを作成する選択肢は存在しない（quality-check SKILL.md Step 5 / スキーマの e2e.result 規約のとおり、失敗は修正を経ないとフラグに到達できない）。反復中はサーバーを起動したままにしてよい（① で継続する場合を含む）。② で中断する場合、および全反復の完了時は、サーバー停止（手順 3）が必須である（起動したまま放置しない）
• 新規シナリオを追加した場合は、テストコードをブランチにコミットする（フラグ作成前なので通常フローに収まる）

---

Step 5: 永続台帳（documents/development/test-recommendation-ledger.md）

コミット対象の markdown 台帳。E2E シナリオ未整備の導線一覧とミューテーション見送り履歴の 2 表を持つ。フォーマットの正は本節の雛形とする（init は同内容を documents/development/test-recommendation-ledger.md に copy-if-missing で配布する）。手で編集してよいのは状態の是正のみ。

台帳雛形

# Test Recommendation Ledger

test-recommendation スキル（quality-check Step 5）が管理する永続台帳。**手で編集してよいのは状態の是正のみ**。フォーマットを変えないこと（スキルが読み書きする）。

運用規則:

- 行の一意キーは「導線」（E2E 表）/「対象領域」（ミューテーション表）。同じ対象を再検出・再提示したときは**既存行を更新**する（重複行を作らない）
- 行は各表のヘッダ区切り行の直後に追記する
- `scenario_added` のまま 6 か月以上更新のない行は、末尾の「アーカイブ」節へ移してよい（以降の判定は実 E2E spec への突き合わせで行われるため）。**`dismissed` の行はアーカイブしない** — 恒久的に再提案しないというユーザー判断の記録そのものであり、台帳に残り続けることで効力を持つ

## E2E シナリオ未整備の導線

<!-- 状態: pending（再提案対象）/ scenario_added（シナリオ追加済み）/ dismissed（恒久的に不要とユーザーが判断 — 再提案しない） -->

| 導線 | 検出日 | 最終提示日 | 見送り回数 | 状態 | 状態更新日 | 見送り理由 |
|---|---|---|---|---|---|---|

## ミューテーション見送り履歴

<!-- 推奨度: strong（強推奨）/ recommended（推奨） -->

| 対象領域 | 検出日 | 最終提示日 | 見送り回数 | 推奨度 | 見送り理由 |
|---|---|---|---|---|---|

## アーカイブ

（判定対象外の旧行をここへ移す）

生成と保全

• 配布の正は init とするが、copy-if-missing（存在しなければコピー）の例外扱いである — 台帳はプロダクトの蓄積データであり、init 再実行時の上書き refresh の経路に乗せてはならない
• init を再実行していない既存プロダクトでは、本スキルが初回実行時に本節の雛形から生成する（generate-if-missing のフォールバック）
• いずれの経路でも既存ファイルがあれば何もしない
• 台帳が読み取れない・フォーマットが逸脱している場合は、新規生成・上書きをせず、ユーザーに提示して修復を仰ぐ（黙った上書きで履歴を失わない。documents/development/development-policy.md §1.0「承認後の進め方」 の例外 X7）
• 台帳は documents/ 配下のため、quality-check「ハーネスのみ変更の免除」の対象ではない（docs 変更として統合レビュアーのレビュー対象）

再提案ロジック

状態	挙動
pending	その導線に触れる変更が来たら再提案する
dismissed	再提案しない（ユーザーが恒久的に不要と判断したもの）
scenario_added	以降の判定は既存シナリオ経路の突き合わせに移る

• ミューテーション側にも適用する: declined 済みの同一対象領域は、台帳の最終提示日以降に当該領域へ新たな実装差分が入っていない場合は再提案しない（判定は台帳の最終提示日と変更差分の突き合わせで機械的に行う。日付粒度で判定が曖昧な場合 — 最終提示日と同日の差分等 — は再提案する側に倒す。記録のみ更新する）。新たな実装差分が入った場合は再提案する。見送り回数が 3 回以上の対象領域は個別の詳細提示をせず「継続見送り: N 件」の 1 行サマリに含める。ブランチを跨いだ恒久抑止はしない — 恒久的な抑止は E2E 側の dismissed と異なり、ミューテーションには設けない。いずれの場合も台帳の最終提示日を更新し、見送り回数はユーザーが見送ったときだけ増やす（下記「ユーザーの見送りと AI の持ち越し」）。ミューテーション見送り履歴の表は履歴（最終提示日・見送り回数）の記録であり、E2E 表のような状態（pending 等）の管理はしない
• E2E で見送り回数が 3 回以上の pending 行は個別提示せず、「継続 pending: N 件」の 1 行サマリで提示する（シナリオドラフトの起草は行わない）
• 判定不能で recommended に倒した対象も台帳に記録し、同じ見送り回数規定を適用する（毎回の再提示を防ぐ）
• アーカイブ規則（6 か月）は台帳雛形（「台帳雛形」節）の運用規則を正とする

ユーザーの見送りと AI の持ち越し

台帳の書式（列・見出し）は変えず、値の書き方で区別する。自動実施の条件「同じ対象をユーザーが見送った記録が無い」はこれで判定する。

• ミューテーション: 対象領域の行が無い、または「見送り回数」が 0。見送り回数を増やすのはユーザーの見送りだけで、AI の持ち越しは見送り理由に 自動持ち越し: の部分を含める（「台帳更新」）。3.3.0 以前の行で見送り回数が 1 以上のもの（ユーザーが 3 択で持ち越しを選んだ行を含む）は、ユーザーの判断として扱う（確認に回る）
• E2E: 導線が pending かつ見送り回数 1 以上なら、ユーザーが見送ったものとして確認に回す。dismissed は従来どおり再提案しない

台帳更新

• E2E 新規導線の 3 択の結果を状態に反映する: ① シナリオ追加 + 実行 / ② 追加のみ → scenario_added、③ 見送り → pending（次回も再提案）または dismissed（ユーザーが恒久的に不要と明示した場合のみ）。見送り理由を記録する。状態（pending / scenario_added / dismissed）を変更したときは状態更新日を併せて更新する
• ミューテーションの見送り・生存持ち越しをミューテーション見送り履歴に記録する。ユーザーの見送りは見送り回数を 1 増やし理由をそのまま書く。AI の持ち越し（自動実施・確認で実施の後の unresolved）は見送り回数を増やさず、見送り理由を 自動持ち越し: 生存 N 件（unresolved） の形で書く（既存の行があれば最終提示日を更新し、見送り理由はユーザーの過去の見送り理由を残し、既にある 自動持ち越し: の部分は今回の内容で置き換え、無ければ / で足す）
• コミット順序: Step 5 で生じた差分（永続台帳の更新・撃殺テスト・新規 E2E シナリオ・E2E 失敗の修正）は、quality-check Step 6 のフラグ作成より前に、パスを指定してコミットする（git add -A / git commit -a を使わない。ユーザーの未追跡ファイルを巻き込まないため）（台帳は documents/ 配下でハーネス免除の対象外のため、フラグ発行後のコミットはフラグを無効化し hook がマージをブロックする — quality-check SKILL.md Step 6「フラグの性質」）。単体実行時は同ブランチの通常フローでコミットする

---

記録

quality-check から実行された場合（Step 5）

.quality-check-report.json の mutation / e2e オブジェクトに記録する。フィールド定義は _schemas/quality-check-report.schema.md を正とする（値の閉集合・必須性はスキーマに従う）。

オブジェクト	内容
mutation	recommendation（strong / recommended / none）/ recommendation_basis（該当ヒューリスティクス項目。判定不能の事実・確認の区分にした理由を含む）/ user_decision（executed / declined / not_proposed。自動実施を含む）/ decided_by（auto / user）/ decline_reason。実行時は scope / base_ref / mutants_total / score_raw / survivors / incremental（最後の実行がキャッシュを再利用したか）等の実行時フィールドを併せて記録する（実行モード・スコア基準等の旧キーは廃止 — 記録しない）
e2e	recommendation / recommendation_basis / user_decision / decided_by / result / issues / new_scenarios（起草したシナリオと 3 択の判断）。旧トップレベルの e2e_result / e2e_issues を置き換える

• 推奨度 none の対象も判定結果を記録する（recommendation / recommendation_basis、user_decision: "not_proposed"）
• 新規導線で「シナリオ追加のみ（実行見送り）」を選んだ場合は e2e.user_decision: "added_only"・e2e.result: "skipped"・new_scenarios[].decision: "added_only" を記録する

単体実行時

.quality-check-report.json には触れない（レポートは quality-check の実行単位のため）。実行結果・判断は永続台帳とセッション出力に記録する。

---

チェックリスト

• ベース ref を解決し（quality-check Step 1 と同一）、git diff で判定対象を取得した
• 永続台帳を読み取った（存在しなければ雛形から生成。読めない・フォーマット逸脱時はユーザーに修復を仰いだ — 黙って上書きしない）
• ミューテーション / E2E のヒューリスティクスを判定した（複数該当は最高推奨度 / ツール未導入は not_configured / E2E スイート不在時は新規導線検出のみ / 判定不能は recommended に倒し根拠欄に記録）
• strong / recommended を自動実施 / 確認に区分した（自動実施は strong・範囲が上限以内・副作用なし・ユーザーの見送りなしのすべて。none は提示せず記録のみ）
• 自動実施分は確認せずに実行した。確認の区分は最後の 1 通で聞き（ミューテーション・既存シナリオ E2E は 2 択、新規導線 E2E はドラフト提示の上 3 択）、返答を記録した（quality-check 経由はレポートの mutation / e2e と decided_by、単体実行は台帳 + セッション出力。見送りは decline_reason 付き）
• 実施と決まったミューテーションを実行した（テスト緑前提 / 差分スコープ / 実行回数は最大 3 回、超過はせず持ち越し / 通過判定なし — 生存の対処は既定の規則で AI が決める / トリアージ規律と red-green 検証（1 実行あたり最大 5 件・当該テストファイルのみ）/ tool_false_negative の機械判定 / バジェット超過は縮退再試行 → unmeasurable_within_budget で先へ / 検証対象が残れば QAエンジニア（ファルシフィケーション型）で分類妥当性を検証）
• 実施と決まった E2E を実行した（server-startup で起動 → シナリオ実行 → 必ず停止 — 反復を打ち切った場合も停止は必須。失敗は実バグとして修正 + 影響範囲のみ再検証 — 反復は最大 2 回、超過は方針変更か中断の 2 択（失敗受容の選択肢はない）。新規シナリオのテストコードはコミット）
• 永続台帳を更新し、Step 5 で生じた差分をフラグ作成より前にコミットした（導線の状態遷移・見送り理由・ミューテーション見送り履歴。AI の持ち越しは見送り回数を増やさず「自動持ち越し:」で記録）