--- id: 'existing-pattern-conformance' name: 'Existing-Pattern Conformance 既存パターン準拠の確認' description: '新実装が、同種の先行実装（同レイヤ・同責務・同概念）に在る防御 / バリデーション / エラー処理 / 規約 / 共通化ロジック / 概念定義を、欠落・重複・食い違いなく継承しているかを grep で先行特定して確認する' version: 0.1.0 category: midstream phase: midstream applyTo: - '**/*.{ts,tsx,js,jsx,mjs,cjs,py,rb,go,php,java}' - '**/migrations/**/*' tags: [conformance, prior-art, consistency, maintainability, midstream] severity: major inputContext: [diff] outputKind: [findings, questions] modelHint: high-accuracy dependencies: [code_search] --- ## Pattern declaration Primary pattern: Reviewer Secondary patterns: Inversion Why: 先行実装との突合は grep による決定論的特定が主だが、同種の先行実装が存在しない新規領域では実行を止めるゲートが必要。 ## Goal / 目的 - 新しい追加 / 変更が、**同種の先行実装をまず grep で特定**し、そこに在る防御・バリデーション・エラー処理・定数 / 規約・共通化ロジック・概念定義を**欠落・重複・食い違いなく継承**しているかを確認する。 - 「既存に同じことをする実装があるのに、それを参照せず独自に書いて防御やバリデーションが抜けた / 重複した / 規約から外れた」パターンを検出する。 ## Non-goals / 扱わないこと - 設計の良し悪しそのもの（既存が間違っていれば従う必要はない。意図的差分は根拠の明文で許容）。 - リファクタ後の caller 残骸（`rr-midstream-cross-file-leakage-001` の領域）。 - 宣言と実装の自己矛盾（`rr-midstream-self-contradiction-001` の領域）。 ## Pre-execution Gate / 実行前ゲート このスキルは以下の条件がすべて満たされない限り `NO_REVIEW` を返す。 - [ ] 差分に、リポジトリ内で**同レイヤ・同責務・同概念の先行実装が grep で実在確認できる**追加 / 変更を含む（防御・バリデーション・エラー処理・規約・共通化ロジック・概念定義を持つ同種コード / 設計 / migration）。「存在しうる」という推測では発火させず、**先行実装を grep で1件以上特定できたときのみ**レビューに進む - [ ] inputContext に diff が含まれ、`code_search`（grep）が利用可能である ゲート不成立時の出力: `NO_REVIEW: rr-midstream-existing-pattern-conformance-001 — 先行実装と突合すべき変更が検出されない` ## False-positive guards / 抑制条件 - grep で同種の先行実装が見つからない（真に新規領域）の場合は指摘しない。 - **grep ヒットが同名でも、別スコープ・別責務・別概念であれば「先行実装」ではない**。同名の関数 / 定数 / 型でも、別レイヤ・別ドメイン・別用途なら突合対象から除外する。同レイヤ・同責務・同概念であることを確認できた先行実装のみを参照とする（同名・文字列一致だけを根拠に「先行はこうしている」と断定してはならない）。 - 既存パターンから外れることが**差分内で根拠とともに明記**されている場合は抑制（意図的な逸脱）。 - 既存実装側が deprecated / 移行中で、新実装が新方針に従っている場合は抑制。 ## Rule / ルール ### 検出ロジック 1. **先行実装の特定**: 追加 / 変更された機能の概念（バリデーション対象・エラー処理・定数・共通関数・概念名）を抽出し、**repo 全体を grep** して同レイヤ・同責務・同概念の先行実装を特定する。 2. **継承の突合**: 先行実装に在る次を新実装が継承しているか比較する。 - 防御 / 入力バリデーション / 認可チェック - エラー処理・例外方針（型・ラップ・再 throw 慣習） - 定数 / 規約 / 命名 / 共通化ロジック（再実装でなく共通関数の再利用） - 概念定義（同名概念の意味のズレがないか） 3. **逸脱の分類**: 欠落（先行にあるが新実装に無い）/ 重複（共通化せず再実装）/ 食い違い（同概念で挙動が違う）を判定。意図的なら根拠の明文を確認。 4. **報告**: 先行実装と新実装を両方 `:` + grep 検索語で示す。 ### 制約 - 検出は最大 5 件。防御・バリデーション欠落など実害の大きいものを優先。 - 各指摘に「先行実装（参照）」「新実装」「欠落 / 重複 / 食い違いの別」を必ず含める。 - 先行実装の特定は grep で再現可能にする（検索語を明示）。 ## Evidence / 根拠の取り方 - 先行実装と新実装は両方 `:` と grep 検索語で示し、推測しない。 - 「先行はこうしている / 新実装はこう」を対比し、欠落 / 重複 / 食い違いを具体的に説明する。 ## Output / 出力フォーマット すべて日本語。 ```text (existing-pattern-conformance):1: [要約] 最も重大な既存パターンからの逸脱は〈1文〉 :: [パターン逸脱1] <タイトル> 先行実装: <参照>(検索語: ``, :) 新実装: <該当箇所>(:) 逸脱: <欠落 / 重複 / 食い違い> — <何を継承し損ねたか> Fix: <既存の防御・共通関数・規約を継承する最小修正、または逸脱の根拠を明文化> ``` ## 評価指標（Evaluation） - 合格基準: 先行実装が grep 再現可能な検索語 + `:` で示され、欠落 / 重複 / 食い違いが具体的に説明されている。 - 不合格基準: 先行実装を grep で再現できない、新規領域への難癖、設計の好み論、根拠ある意図的逸脱への指摘。 ## 人間に返す条件（Human Handoff） - 既存パターンに従うべきか、新方針へ移行すべきかが設計判断を要する場合。 - 先行実装が複数あり、どれを正典とするかの合意が必要な場合。