Refactor-Claim Audit リファクタ完了主張の検証

Pattern declaration

Primary pattern: Reviewer Secondary patterns: Inversion Why: 完了主張の反証は grep 検索による決定論的突合が主だが、主張がない変更では実行を止めるゲートが必要

Goal / 目的

• 「全部置換した」「すべて移行済み」「-83% 削減」のような 完了主張（commit message / PR description / コメント）に対し、grep で簡単に反証できる残骸や、過大な数値主張を検証する。
• 抽出（extract function/module）・集約リファクタが伴う 暗黙の挙動不変主張（「動作は変えていない」「テストは通る」）に対し、戻り値の byte 不変では守られない性能特性の退行やキー集約の衝突を検証する。
• 「やったと書いてあること」と「実際にやれていること」のギャップを可視化する。

Non-goals / 扱わないこと

• リファクタの設計妥当性の判断（それ自体が良い変更かは問わない）。
• 残骸が1件もない正当な完了主張への難癖（反証できなければ指摘しない）。
• パフォーマンス計測の代替（数値は主張の論理的整合性のみ検証し、実測はしない）。

Pre-execution Gate / 実行前ゲート

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

• 差分・commit message・PR description に完了主張（「全」「すべて」「all」「完了」「移行済」「置換」「-N%」「削減」等）、または抽出・集約リファクタの挙動不変主張（「抽出」「切り出し」「集約」「リファクタ」「挙動不変」「動作は変えていない」「テストは通る」「extract」「refactor」「aggregate」「consolidate」「no behavioral change(s)」「behavior unchanged」「tests pass」等）が含まれている
• inputContext に diff が含まれている

ゲート不成立時の出力: NO_REVIEW: refactor-claim-audit — 完了主張・リファクタ挙動不変主張が検出されない

False-positive guards / 抑制条件

• 主張の対象を grep しても残骸が見つからない場合は指摘しない（反証できない主張は正しいとみなす）。
• 残骸が意図的に残されたもの（後方互換のための alias、deprecation 期間中の旧 API 等）で、差分内にその旨が明記されている場合は抑制。
• 数値主張が範囲表記（「-47%〜-55%」）で既に幅を持っている場合は抑制。
• 性能特性の退行は、抽出前に並列（Promise.all）・fast-path・遅延評価が存在したことを差分または元コードで確認できる場合のみ指摘する。元から直列・同一評価順のコードを「直列だ」と指摘しない（新規の非効率提案は本スキルの対象外）。
• キー集約の衝突は、集約対象が単一 kind のみ、または集約キーが元から複合キーで衝突し得ない場合は指摘しない（衝突の現実的な可能性を示せないなら抑制）。

Rule / ルール

検出ロジック

1. 主張の抽出: 完了主張を抽出し、検証可能な命題に変換する。
   • 置換主張: 「A を B に全置換」→ 「repo 全体に A が残っていないはず」
   • 完了主張: 「移行完了」→ 「旧構造への参照が残っていないはず」
   • 数値主張: 「-N%」→ 「best/typical/worst のどのケースの値か」
2. 反証検索: 主張の対象パターン（旧 API 名・旧参照形式・旧記法）を repo 全体に grep し、残骸を探す。
3. 数値の独立試算: -N% 等の定量主張は、best-case / typical-case / worst-case を独立に算出し、主張値がどのケースか・過大表示でないかを併記要求する。
4. ギャップの報告: 主張と、それを反証する残骸 or 試算を <file>:<line> で示す。

抽出・集約リファクタの退行観点

抽出・集約リファクタは「動作は変えていない」「テストは通る」という暗黙の挙動不変主張を伴う。だがこの主張が守るのは戻り値・出力（byte 不変）までで、次の非機能的な特性は検証範囲外に落ちやすい。主張に挙動不変が含まれるとき、抽出前後のコードを対比して以下を追加監査する（grep 単独では判定できない意味論的観点）。

1. 性能特性の退行（parallelism / fast-path / 遅延評価）: 元コードの並列性・fast path・遅延評価が、抽出後に直列化・全 async 化・先行評価へ劣化していないか。
   • 並列 → 直列: 元が Promise.all([...]) で並行実行していた処理が、抽出後にループ内 await（直列）へ落ちていないか。
   • fast path の消滅: 同期で早期判定していた分岐（例: Dirent.isDirectory() の同期チェック）が、抽出後に一律 async 化・追加 I/O 経由へ変わっていないか。
   • 遅延 → 先行評価: 必要時のみ評価していた値が、抽出後に無条件で先行評価（余分な Promise 生成を含む）されていないか。
   • 実例: #1481/#1482 — 抽出で Promise.all の並列度が直列 await に落ち、Dirent の同期 fast-path が失われた（gemini 指摘、adopted）。「テストは通る」ため byte 不変検証を素通りした。
2. キー集約の衝突退行（cross-kind collision）: 複数ソースを単一の Map / Set / Object に集約するリファクタで、集約キーが識別子の一部（label のみ等）に落ち、異種（kind 違い）の同名エントリが上書き・dedup されて検出漏れしないか。
   • 集約キーが label 単体になっていないか（本来は kind:label 等の複合キーが必要）。
   • 同名・別 kind のエントリが後勝ちで消えないか、Set 化で異種の重複が黙って畳まれないか。
   • 実例: #1468 — Map キーが label のみになり、kind の異なる同名エントリが衝突して片方が上書き消失し、検出漏れになった（gemini 指摘、adopted）。

制約

• 検出は最大 5 件。反証が明確で影響が大きいものを優先。
• 各指摘には「主張」「主張の出典」「反証（残骸位置 or 試算 or 抽出前後の対比）」を必ず含める。
• 残骸を挙げるときは grep で再現可能な検索語を明示する。
• 性能特性・キー集約の退行は、抽出前（base）と抽出後（diff）の該当箇所を <file>:<line> で併記し、どの特性がどう変わったかを対比で示す。

Evidence / 根拠の取り方

• 反証する残骸は必ず <file>:<line> と検索語を示し、推測しない。
• 数値主張は算出根拠（分母・分子・ケース定義）を明示し、best/typical/worst を区別する。
• 性能特性の退行は、抽出前に並列（Promise.all）・fast-path・遅延評価が実在したことを差分または base コードで確認してから指摘する（元から直列なら退行ではない）。

Output / 出力フォーマット

すべて日本語。

(refactor-claim-audit):1: [要約] 最も過大な完了主張は〈1文〉

<file>:<line>: [完了主張の反証1] <タイトル>
  主張: 「<完了主張の引用>」(<出典: commit message | PR | file:line>)
  反証: <残骸の説明 or 試算>(検索語: `<grep pattern>`, <file>:<line>)
  実態: <主張と実態のギャップ>
  Fix: <残骸を処理するか、主張を実態に合わせて訂正する>

<file>:<line>: [完了主張の反証2] ...

Good / Bad Examples

Good

sub-supervisor.md:1: [完了主張の反証] 「章番号参照を全置換」主張に対し本文7箇所が未置換
  主張: 「sub-supervisor の章番号参照 → ファイル参照に置換」(commit message)
  反証: 冒頭の参照表のみ置換、本文は §refs のまま (検索語: `§[0-9]`, sub-supervisor.md:38,68,85,87,111,123)
  実態: 7 箇所が未置換で「全置換」は不成立
  Fix: 本文 7 箇所を置換するか、commit message を「参照表のみ置換」に訂正

scan.mjs:42: [挙動不変主張の反証] 「ヘルパーへ抽出（動作は変えない）」だが並列度が直列に退行
  主張: 「エントリ収集を collectEntries() に抽出、動作は変えていない」(PR description)
  反証: 抽出前は `await Promise.all(dirs.map(readOne))`（並列）だったが、抽出後は for-of 内 `await readOne(d)`（直列）(scan.mjs:42-48、抽出元 scan.mjs@base:31)
  実態: 戻り値は byte 不変でテストは通るが、I/O 並列度が失われスループットが退行
  Fix: 抽出後も `Promise.all` で並列実行を維持するか、直列化する旨を主張に明記

registry.mjs:88: [挙動不変主張の反証] Map 集約でキーが label のみになり cross-kind 衝突が発生
  主張: 「skill と agent-skill を単一 Map に集約（リファクタのみ）」(commit message)
  反証: キーが `entry.label` 単体（registry.mjs:88）。kind の異なる同名 label が後勝ちで上書き消失する（検索語: `new Map`, registry.mjs:88）
  実態: 同名・別 kind のエントリが dedup され、片方が検出対象から漏れる
  Fix: 集約キーを `${entry.kind}:${entry.label}` 等の複合キーにするか、kind 別に Map を分ける

Bad

リファクタが不完全そうです

（主張の引用なし、残骸位置・検索語なし、具体性なし）

評価指標（Evaluation）

• 合格基準: 完了主張（または挙動不変主張）が引用され、反証が grep 再現可能な検索語 + <file>:<line>、明示された試算、または抽出前後の対比で示されている。
• 不合格基準: 主張の引用がない、残骸を grep で再現できない、数値試算の根拠がない、性能特性の退行を base コードでの並列/fast-path/遅延の実在確認なしに指摘している、反証できないのに指摘している。

人間に返す条件（Human Handoff）

• 残骸を処理するか主張を訂正するかが、後方互換や移行戦略の判断を要する場合。
• 数値主張の正しいケース定義（何を分母にするか）がチーム合意を要する場合。