Detector Detection Power

---
id: 'detector-detection-power'
name: 'Detector Detection Power 検査器の検出力の検証'
description: '検査器（linter / ガード / CI ゲート / バリデータ / フィルタ）そのものの検出力が差分で静かに落ちていないか、また新設した検査が実際に検出できることが実証されているかを diff-time で検出する。Check 1 unverified detection reduction（検査器の検出ロジック（正規表現・除外パターン・解決集合・allowlist・baseline）を変更して検出件数が減ったのに、減った 1 件ずつが誤検出であった根拠が示されないまま「誤検出を潰した」「N → M 件に減少」と改善として主張している）、Check 2 unproven guard detection power（新しい検査ロジック・CI ゲート・バリデーションを追加・変更したのに、検出すべき入力を注入して検出されること／検出すべきでない入力で黙ることを示す変異注入の証跡が無く、「追加した」「CI が緑」を検出力の証拠として扱っている）、の 2 Check を対象とする report-only。テスト自身のアサーションが実質何も検証していない構造は test-assertion-effectiveness、レビュー基準・品質ゲートの明示的な弱体化（ルールの削除・閾値の引き下げ・suppression entry 追加・lint ルールの無効化）は review-criteria-integrity、リファクタ完了主張一般の検証は refactor-claim-audit、workflow の permissions と action pin は gha-workflow-security、設定ファイルの構文・型の妥当性は config-json へ委譲する'
version: 0.1.0
category: midstream
phase: midstream
applyTo:
  - 'scripts/**/*.{mjs,cjs,js,ts,sh,py,rb}'
  - 'tools/**/*.{mjs,cjs,js,ts,sh,py,rb}'
  - '.github/scripts/**/*.{mjs,cjs,js,ts,sh,py,rb}'
  - '.github/workflows/**/*.{yml,yaml}'
  - '**/*lint*.{mjs,cjs,js,ts,py,rb,sh}'
  - '**/*guard*.{mjs,cjs,js,ts,py,rb,sh}'
  - '**/*validat*.{mjs,cjs,js,ts,py,rb,sh}'
  - '**/*check*.{mjs,cjs,js,ts,py,rb,sh}'
  - '**/*detect*.{mjs,cjs,js,ts,py,rb,sh}'
  - '**/*scan*.{mjs,cjs,js,ts,py,rb,sh}'
  - '**/*audit*.{mjs,cjs,js,ts,py,rb,sh}'
  - '**/*baseline*.{json,yaml,yml,txt}'
  - '**/*allowlist*.{json,yaml,yml,txt}'
  - '**/*ignorelist*.{json,yaml,yml,txt}'
tags:
  [
    detector-quality,
    detection-power,
    guard,
    linter,
    ci-gate,
    validator,
    mutation-evidence,
    false-negative,
    midstream,
  ]
severity: major
inputContext: [diff, prDescription, fullFile]
outputKind: [findings, questions]
modelHint: high-accuracy
dependencies: [code_search]
exclude:
  - '**/*.{test,spec}.{ts,tsx,js,jsx,mjs,cjs}'
  - 'tests/**/*'
  - 'test/**/*'
  - '__tests__/**/*'
  - '**/*Test.php'
  - '**/test_*.py'
  - '**/*_test.{py,go,rb}'
---

## Naming / 命名

`skills/README.md` の Naming Q0–Q5 に従って決定した。本 skill は外部プロジェクトの成果物・技術の取り込みではなく、リポジトリ内の運用振り返りから起こした観点であるため Q0 の入力分類（artifact / concept reimplementation）は適用外であり、Q1–Q4 の「原語」も存在しない。したがって Q5 に落ち、**役割を名指す新規命名**として `detector-detection-power` を採用した。機構名（件数比較・変異注入）ではなく「検査器が持つべき価値＝検出力」を名指す点が Q5 の要件である。既存の `test-assertion-effectiveness`（テストの有効性）と語形をそろえ、対象が **テスト** ではなく **検査器** であることを `detector-` の接頭で区別している。

## Pattern declaration

Primary pattern: Reviewer
Secondary patterns: Inversion
Why: 検出ロジックの変更はパターンとして拾えるが、「その変更が誤検出の除去か検出力の低下か」は件数からは決定できず、比較の根拠（減った項目の内訳・変異注入の証跡）が discover できない差分では実行を止めるゲートが必要である。

## Goal / 目的

検査器（linter / ガード / CI ゲート / バリデータ / フィルタ）は、それ自身がレビューされないまま「安全網がある」という前提を支えてしまう。検査器の**検出力が落ちたことは、失敗として現れない**。件数は減り、CI は緑になり、指標はむしろ改善したように見える。この非対称性が本 skill の対象である。

具体的には次の 2 つの盲点を diff-time の静的観点として埋める。

- **減少の解釈**: 検出件数が減ったとき、それが誤検出の除去なのか検出力の低下なのかは**件数だけでは区別できない**。にもかかわらず、件数の減少がそのまま「改善」として報告される。
- **新設の実証**: 検査を追加したとき、「追加した」ことと「CI が緑になった」ことは、いずれも**その検査が何かを検出できる証拠にならない**。検出すべきものを入れたら赤くなり、入れなければ緑のままであることを示して初めて検出力が実証される。

report-only（ADR-005）であり、finding / question のみを出力して自動修正はしない。

## Non-goals / 扱わないこと（委譲表）

| 隣接領域                                                                                                                 | 委譲先                                        | 分界                                                                                                                                                                                                                                                                                                                                                                                                        |
| ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **テスト**のアサーションが実質何も検証しておらず常に PASS する                                                           | `test-assertion-effectiveness`                | 委譲先の対象は**テストコード**であり、その中のアサーションが失敗しうるかを見る。本 skill の対象は**検査器そのもの**（linter / ガード / CI ゲート / バリデータ / フィルタ）であり、その検出ロジックが検出すべきものを検出できるかを見る。検査器に付随するテストの書きぶりは委譲先、検査器本体の検出力は本 skill。この分界は frontmatter の `exclude`（テストのパス・命名規約を除外）で機構的にも担保している |
| レビュー基準・品質ゲートの**明示的な弱体化**（ルール削除・閾値引き下げ・suppression entry 追加・lint ルールの `off` 化） | `review-criteria-integrity`                   | 委譲先は「基準そのものを外した・緩めた」差分を見る。本 skill は**基準・検査器が残ったまま、その内部ロジックの検出力だけが変わった／未実証である**ケースを見る。設定値の無効化は委譲先、検出ロジック（正規表現・解決集合・除外パターン・baseline）の変更は本 skill                                                                                                                                           |
| リファクタ完了主張一般（「全部置換した」「-N% 削減」）の反証                                                             | `refactor-claim-audit`                        | 委譲先は主張と実装の一致を grep で反証する汎用監査。本 skill は**検査器の検出件数に関する主張**に限定し、かつ「一致しているか」ではなく「減少が誤検出由来か見逃し由来か」を見る                                                                                                                                                                                                                             |
| workflow の `permissions` 拡大・third-party action の未 pin・トリガーの危険な組合せ                                      | `gha-workflow-security`                       | 委譲先は供給網と権限。本 skill が workflow を見るのは**検査 job / step の検出力**という文脈のみ                                                                                                                                                                                                                                                                                                             |
| 設定ファイル（JSON / YAML）の構文・型・一般的ベストプラクティス                                                          | `config-json`                                 | 委譲先は設定の妥当性一般。本 skill は allowlist / baseline を**検出力を左右するデータ**としてのみ見る                                                                                                                                                                                                                                                                                                       |
| `.only` / `.skip` / `xit` / `@ts-ignore` / `@ts-nocheck` / 空の `catch {}`                                               | `src/lib/heuristic-review.mjs` の決定論検出器 | 決定論で判定済みのため**重複指摘しない**（`.claude/rules/review-core.md` §「カスタム静的解析の False-positive 責務分界（#1070）」）                                                                                                                                                                                                                                                                         |
| 影響・失敗系を調査した証拠の有無一般                                                                                     | `impact-evidence-coverage`                    | 委譲先は証拠の充足性一般。本 skill が求める証拠は**変異注入（検出されること／黙ること）の 1 種類**に限定する                                                                                                                                                                                                                                                                                                |

さらに次はスコープ外とする。

- **ミューテーションテスト基盤の導入**: 変異注入を自動化する仕組みの導入・選定は静的レビュー観点の責務ではない。本 skill は「変異注入の証跡が示されているか」だけを見る。
- **検査器の実装品質一般**: 可読性・性能・エラーハンドリングは対象外（検出力に影響する場合のみ扱う）。
- **検出件数そのものの多寡**: 「検出が多すぎる／少なすぎる」という規模の議論はしない。扱うのは**変化と、その変化に付けられた説明の妥当性**である。
- **検査器を新設すべきかどうか**: ガードの要否・費用対効果の判断は人間に返す。

## applyTo を選んだ理由

検査器はコード上の型や継承関係では識別できず、**置かれる場所**と**名前が担う役割**で識別するのが最も精度が高い。テンプレートの「できるだけ絞り込む」要求に対し、次の 3 群だけに限定した。

1. **リポジトリ自動化ディレクトリ**（`scripts/**` / `tools/**` / `.github/scripts/**` / `.github/workflows/**`）: 検査器・CI ゲートの一次的な置き場。`src/**` を**ディレクトリとして丸ごと**含めないのは、本番コードのバリデーション（入力検証・ドメイン制約）まで拾うと対象が製品コード全体に広がり、`security-basic` や `nullability-contract` の領分と重複するため。
2. **役割を名乗るファイル名**（`*lint*` / `*guard*` / `*validat*` / `*check*` / `*detect*` / `*scan*` / `*audit*`）: 上記ディレクトリ外に置かれた検査器を拾う。この群は**ディレクトリを問わない**ため、`src/lib/plan-review/approval-scan.mjs` のように `src/**` 配下でも役割を名乗るファイルは対象に入る。第 1 群で `src/**` を外したのは「製品コード全体を対象化しない」という意味であり、**役割名を持つ個別の検査器まで対象外にする意図ではない**。拡張子を実行可能なスクリプト言語に限定し、同名の Markdown ドキュメントやテストデータを除外している。
3. **検出力を左右するデータファイル**（`*baseline*` / `*allowlist*` / `*ignorelist*`）: 検出ロジックを 1 行も変えずに検出力を落とせる経路であり、ロジック本体と同じ観点で見る必要がある。

`**/*check*` は語として一般的だが、拡張子制約と Pre-execution Gate（検出ロジックの変更を含むこと）の二段で絞られるため、ドキュメントや無関係なユーティリティで発火しない。

### exclude を置いた理由

第 2 群のファイル名パターンは、`tests/check-doc-links.test.mjs` のような**検査器のテスト**にも一致してしまう。テストコードは委譲表のとおり `test-assertion-effectiveness` の領分であり（同 skill の applyTo は `tests/**/*` を含む）、applyTo をそのままにすると**同一ファイルに対して 2 つの skill が発火する**。そこで frontmatter の `exclude` でテストのパス・命名規約を除外し、本 skill の対象を**検査器本体とそのデータファイル**に限定した。

除外は applyTo の否定パターン（`!tests/**`）ではなく `exclude` フィールドで表現する。dispatcher の一致判定は applyTo の各パターンの OR（`Array.prototype.some`）であり、否定パターンを混ぜると「`tests/` 以外の全ファイルに一致する 1 パターン」として働き、絞り込みが逆に消えるためである。

## Pre-execution Gate / 実行前ゲート

このスキルは以下の条件が**すべて**満たされない限り `NO_REVIEW` を返す。

- [ ] inputContext に `diff` が含まれている。
- [ ] 差分に**検査器（linter / ガード / CI ゲート / バリデータ / フィルタ / 静的解析スクリプト）の追加または変更**が含まれている。対象ファイルが applyTo に一致するだけでは足りず、変更箇所が**何かを検出して報告・失敗させるロジック、またはその検出範囲を決めるデータ**であること。
- [ ] Check 1 を判定する場合、変更が**検出ロジック**（判定に使う正規表現・除外パターン・解決集合 / キー集合・allowlist / denylist・baseline・閾値・走査対象の列挙）に及んでいる。出力整形・ログ文言・リファクタのみの変更では Check 1 を実行しない。
- [ ] Check 2 を判定する場合、差分に**新規の検査ロジック・CI ゲート・バリデーションの追加、または既存検査の検出条件の拡張**が含まれている。

ゲート不成立時の出力: `NO_REVIEW: detector-detection-power — 検査器の検出ロジックの追加・変更を含む差分が無い`

## False-positive guards / 抑制条件

Gate を通過したうえで、次に該当する個別の指摘は抑制する（黙る）。

- **減った分が 1 件ずつ根拠づけられている場合は指摘しない**: 検出が減ったことに対し、PR 本文・コード内コメント・追加された fixture のいずれかで、**減った項目の内訳と、それぞれが誤検出であった理由**が示されている場合、Check 1 に該当しない。件数の内訳が全件でなくとも、代表例ではなく**網羅**であることが読み取れれば足りる。
- **検査対象範囲の意図的な縮小は指摘しない**: 検査のスコープ縮小（対象ディレクトリの除外・対象外と決めた種別の除去・別の検査器への移管）が PR で**明示的に宣言されている**場合、件数の減少はその宣言の帰結であり Check 1 に該当しない。移管先が示されている場合は特に指摘しない。
- **件数が変わらないリファクタは指摘しない**: 検出ロジックの構造だけを変え、変更前後で検出結果が同一であることが示されている（同一件数・同一項目の提示、スナップショット比較、既存 fixture の無変更通過）場合は指摘しない。
- **変異注入の証跡がある新設ガードは指摘しない**: 検出すべき入力で失敗し、検出すべきでない入力で成功することが、**テスト・fixture・PR 本文の実行ログ**のいずれかで示されている場合、Check 2 に該当しない。証跡の形式（自動テストか手動実行ログか）は問わない。
- **テストの中身は判定しない**: 証跡がテストとして示されている場合、本 skill は**両方向の入力を扱うテストが存在すること自体を証跡とみなし**、そのテストのアサーションが実質何かを検証しているか（`expect(true).toBe(true)` のような空虚な検証でないか）は**判定しない**。テスト内容の有効性は `test-assertion-effectiveness` の領分であり、「テストが空虚だから証跡として不十分」という理由で Check 2 を出すことは禁じる。テストの中身を理由に発火してよいのは委譲先だけである。
- **決定論的で自明な検査は Check 2 の対象としない**: 外部ツール（既存 linter / formatter / 型チェッカ）をそのまま呼び出すだけで、リポジトリ独自の判定ロジックを持たない step の追加は、検出力が呼び出し先に担保されるため指摘しない。
- **検出ロジックに触れない変更は指摘しない**: 出力の整形、メッセージの文言、進捗表示、終了コードを変えないログ追加は対象外。
- **委譲先の領分は指摘しない**: 上記委譲表の各行、特にルールの削除・閾値の引き下げ・**river の suppression store（`river suppression add` 相当）への entry 追加**・lint ルールの無効化は本 skill から出力しない。なお検査器自身が持つ **allowlist / ignorelist / baseline データの拡大**は委譲先ではなく本 skill の Check 1 の対象である（検出ロジックの一部として扱う）。
- **根拠に到達できなければ question**: PR 本文が供給されず、主張の有無自体を確認できない場合は finding ではなく question とする（false-positive-first）。実行時に供給される文脈は `diff` / `prDescription` / `fullFile` であり、**コミットメッセージは供給されない**。根拠の主たる出所は PR 本文と差分内（コメント・テスト・fixture）である。
- **指摘上限**: Check ごとに finding と question の合算で最大 2 件、全体で最大 4 件とする。保持の優先順は findings（severity 降順）→ questions とし、上限超過分は優先度の低い側から切り捨てる。

抑制時の出力: 該当する指摘を出力しない（黙る）。

## Rule / ルール

### Check 1 — Unverified detection reduction / 検出件数の減少が改善として未検証のまま主張されている

差分が検査器の**検出ロジック**（正規表現・除外パターン・解決集合 / キー集合・allowlist・baseline・閾値・走査対象）を変更しており、かつ PR 本文が「誤検出を減らした」「誤検出を潰した」「N → M 件に減少」といった**改善としての主張**を行っているのに、**減った 1 件ずつが誤検出であった根拠が示されていない**場合に指摘する。

判定の中核は次の一点である。**検出件数の減少は、誤検出の除去と検出力の低下のどちらでも起こる。**したがって件数の変化それ自体は、どちらであるかの証拠にならない。特に注意すべき変更の型を挙げる。

- **解決集合・キー集合の拡張**: 参照先の解決に使うキーを増やすと、実際のツールや実行環境が解決しないキーで解決してしまい、**本来検出すべき壊れた参照が「解決済み」として黙る**。拡張したキーが実行時の解決規則と一致しているかが論点になる。
- **除外パターン・allowlist の拡大**: 誤検出を消す目的の除外が、同じパターンに一致する真の検出も一緒に消す。除外の粒度が「その 1 件」ではなく「その種別全体」になっていないかが論点になる。
- **baseline の再生成**: 既存の未修正項目を baseline に取り込む操作は、**未修正のまま検出を止める**。再生成が意図的か、差分に紛れた副作用かが論点になる。
- **正規表現の厳格化**: マッチ条件を厳しくすると誤検出は減るが、書き方の揺れを持つ真の検出も落ちる。
- **走査対象の縮小**: glob や対象ディレクトリ列挙の変更で、走査自体が届かなくなる。

### Check 2 — Unproven guard detection power / 新設・変更した検査の検出力が実証されていない

差分が**新しい検査ロジック・CI ゲート・バリデーション**を追加している、または既存検査の検出条件を拡張しているのに、**変異注入の証跡**が示されていない場合に指摘する。

変異注入の証跡とは、次の**両方向**を示すものをいう。

1. **検出されること（陽性方向）**: 検出すべき入力を意図的に注入したとき、その検査が失敗する（非ゼロ終了・finding 出力）ことの提示。
2. **黙ること（陰性方向）**: 検出すべきでない入力に対して、その検査が成功する（ゼロ終了・無出力）ことの提示。

「追加した」「CI が緑になった」は、いずれも**陽性方向の証拠にならない**。検査が何も見ていなくても、対象が 0 件でも、条件式が常に真でも、CI は緑になる。特に次の形が典型的な未実証パターンである。

- **自己適用の欠落**: 新設した検査が、**自分自身を導入したその差分に対して実行されていない**、または実行されたが対象 0 件で緑になっている。
- **空集合での vacuous pass**: 走査結果が空のときに成功で抜ける実装で、**対象ディレクトリやファイル群が丸ごと消失しても検出できない**。「0 件だから問題なし」と「0 件しか見ていない」が区別されていない。
- **カバレッジ数値の非提示**: 検査が「何件を見たか」を出力しないため、走査範囲が黙って縮んでも緑のままになる。
- **陰性方向の欠落**: 陽性側だけを示し、正当な入力で黙ることを示していない。この場合、常に失敗する検査（過検出で運用が回らずすぐ無効化される）を排除できない。

### 検出ロジック

1. **Check の特定**: 差分が検出ロジックの変更（Check 1）か、検査の新設・拡張（Check 2）か、その両方かを判定する。どちらにも該当しない差分は調査しない。
2. **主張の抽出**: PR 本文（`prDescription`）から、検出件数・改善・修正完了に関する主張を抜き出す。コミットメッセージは実行時に供給されないため根拠源にしない。Check 1 は主張が存在する場合にのみ成立する（主張が無ければ指摘しない）。
3. **根拠の探索**: 減少の内訳、除外した項目の一覧、変異注入の実行結果、追加された fixture を、差分・`fullFile`・`code_search` で探す。到達できない場合は question に落とす。
4. **反例の提示**: 指摘する場合、「この変更の後でも検出されなくなる**具体的な入力**」を 1 つ述べる。述べられない場合は finding にせず question とする。これが本 skill の断定基準であり、一般論での指摘を禁じる。
5. **抑制条件の棄却**: スコープ縮小の宣言・件数不変の提示・変異注入の証跡・委譲先の領分に該当しないことを確認する。
6. **resolution の付与**: 各 finding に最小の次アクションを添える。「減った項目を列挙し 1 件ずつ誤検出である理由を示す」「除外を対象 1 件に絞る」「検出すべき入力を注入した実行結果を貼る」「検査が走査した件数を出力させる」「対象 0 件のときに失敗させる」のいずれかを明示する。

### severity 較正

- 失われた／実証されていない検出力が、機密情報・認可・データ破壊・公開物の破損といった**クリティカルな失敗を止めるための最後の砦**である場合は `blocker`。
- 検出力の低下・未実証が疑われるが、影響範囲が限定的で merge 前に根拠を足せば足りるものは `warning`。
- 検出力への影響が軽微で、将来の見逃しの温床になる程度（カバレッジ件数の非出力など）は `nit`。
- PR 本文・実行ログに到達できず、根拠の有無を確認できないものは question（`info` 相当）。

## Evidence / 根拠の取り方

- finding の `file:line` は差分内の**検出ロジックの変更行**（正規表現・除外パターン・キー追加・baseline 行・走査対象の宣言）にアンカーする。PR 本文の主張だけを根拠に、差分外へ指摘しない。
- 「検出力が落ちている可能性がある」と述べる場合、**変更後に検出されなくなる具体的な入力**を 1 つ示す。示せない場合は question とする。
- 件数の主張を扱うときは、**分子・分母・測定コマンド**の有無を事実として述べる。自分でも件数を推定して断定しない。
- 作者の意図（ごまかし・手抜き）を断定しない。ロジックの変更内容と、根拠が示されていないという事実のみを述べる（`.claude/rules/review-core.md`）。

## Output / 出力フォーマット

すべて日本語。標準の finding フォーマットに従い、各指摘に `check`（1 または 2）と `resolution` を含める。

```text
(detector-detection-power):1: [要約] 検出力に関する最大の懸念は〈1文〉

<file>:<line>: [Detection power] <タイトル>
  check: 1 | 2
  Finding: 検出力がどう変わりうるか（1文）
  Evidence: 差分の該当行と、PR 本文の主張／根拠が無いという事実
  Counterexample: この変更後に検出されなくなる（または検出されたか確認できない）具体的な入力
  Impact: どの見逃しが起こるか（1文）
  Fix: <最小の次アクション>
  Confidence: high | medium | low
  Severity: blocker | warning | nit（較正基準に従う）
  resolution: <解消手順>
```

## Good / Bad Examples

### Good

```text
scripts/check-doc-links.mjs:22: [Detection power] 解決キーの拡張で、実ツールが解決しない参照まで解決済みとして黙る
  check: 1
  Finding: 参照の解決集合に小文字化・basename・slug 形式を追加したため、実際のリンク解決規則が受理しない表記でも「解決済み」と判定される
  Evidence: 同行のキー追加 3 件。PR 本文は「誤検出を除去し 79 → 42 件に減少」と述べるが、減った 37 件の内訳と各件が誤検出である理由は示されていない
  Counterexample: 実在しないページを大文字混じりの表記で参照した場合、小文字化キーが偶然一致して検出されない
  Impact: 壊れた参照が検出されないまま残り、検査器が緑を返し続ける
  Fix: 減った 37 件を列挙し、1 件ずつ誤検出である理由を示す。または追加キーを実際の解決規則と一致するものだけに絞る
  Confidence: medium
  Severity: warning
  resolution: 減少分の内訳を PR 本文に添付し、真の検出であったものは検出対象へ戻す
```

### Bad

```text
このガードは意味がないかもしれません
```

（Check の特定なし、差分へのアンカーなし、検出されなくなる具体入力の提示なし、resolution なし）

## 評価指標（Evaluation）

- 合格基準: Check が特定され、指摘が差分内の検出ロジック変更行にアンカーされ、**検出されなくなる具体的な入力**が 1 つ示され、抑制条件（減少分の内訳提示・スコープ縮小の宣言・件数不変の提示・変異注入の証跡）が棄却され、resolution が示されている。委譲表の領分を重複指摘しない。
- 不合格基準: 件数の増減だけを根拠に断定している、主張が存在しないのに Check 1 を出している、外部ツールを呼ぶだけの step を Check 2 として指摘している、**証跡として提示されたテストの中身が空虚であることを理由に Check 2 を出している**（`test-assertion-effectiveness` の領分）、`review-criteria-integrity` の領分（ルール削除・閾値引き下げ・river の suppression store への entry 追加）を重複指摘している、具体的な反例も question への降格も無い、resolution が無い。

## 人間に返す条件（Human Handoff）

- 検出力の低下と誤検出の除去のトレードオフが、チームの運用方針（どこまでのノイズを許容するか）に依存して決まる場合。
- 検査器の対象範囲を縮小すべきかどうかが、製品側の設計判断（その規則を今後も守るか）に依存する場合。
- 変異注入の証跡を作ること自体に大きなコストがかかり、導入の是非を判断する必要がある場合。

## References

- `skills/downstream/test-assertion-effectiveness/SKILL.md` — テストのアサーションの有効性（対象がテストである点で分界）
- `skills/midstream/review-criteria-integrity/SKILL.md` — レビュー基準・品質ゲートの明示的な弱体化（委譲先）
- `skills/midstream/refactor-claim-audit/SKILL.md` — 完了主張一般の反証（委譲先）
- `skills/downstream/gha-workflow-security/SKILL.md` — workflow の権限・供給網（委譲先）
- `skills/midstream/config-json/SKILL.md` — 設定ファイルの妥当性（委譲先）
- `skills/midstream/impact-evidence-coverage/SKILL.md` — 証拠の充足性一般（補完関係）
- `.claude/rules/review-core.md` §「カスタム静的解析の False-positive 責務分界（#1070）」 — 決定論と意味的判断の分界
- `docs/review/output-format.md` — 重要度ラベルと出力形式（SSoT）