Logic Torturing 論理検証

Pattern declaration

Primary pattern: Reviewer Secondary patterns: Inversion Why: 論理検証はチェックリスト型評価が主だが、判断を含まない変更では実行を止めるゲートが必要

Goal / 目的

• 変更に含まれる設計判断・技術選択・実装方針の論理的な穴を徹底的に突き、確証バイアスを排除する。
• 「なぜその選択なのか」「他の選択肢はなぜ棄却されたのか」「前提が変わっても成立するか」を問い続け、判断の耐久性を検証する。
• 既定 CI レビューでは自動発火しない（/challenge 等の明示呼び出し向け）。

Non-goals / 扱わないこと

• コードスタイルや命名規則の指摘。
• 既知のバグパターンの検出（それは他のスキルの役割）。
• 著者の判断を否定すること自体が目的ではない（より強固な判断にすることが目的）。

Pre-execution Gate / 実行前ゲート

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

• 差分に設計判断・技術選択・実装方針の判断を含む変更がある
• 変更が機械的なもの（リネーム、フォーマット、依存更新のみ）ではない
• inputContextにdiffが含まれている

ゲート不成立時の出力: NO_REVIEW: logic-torturing — 論理検証の対象となる判断が検出されない

False-positive guards / 抑制条件

• ADRや設計ドキュメントですでに代替案とトレードオフが十分に記述されている場合は重複指摘しない。
• 些末な判断（変数名の選択、import順序など）には適用しない。

Rule / ルール

検証フレームワーク

変更内の判断を発見したら、以下の5つの問いを順に適用する：

1. 前提の検証: 「この判断が依存している前提は何か？その前提は常に成立するか？」
2. 代替案の検証: 「他にどんな選択肢があったか？なぜそれらは劣るのか？」
3. 境界条件の検証: 「この判断が破綻する条件は何か？入力の極端値、負荷の増大、依存の変化」
4. 整合性の検証: 「この判断は既存のアーキテクチャ/設計原則と矛盾しないか？」
5. 可逆性の検証: 「この判断が間違いだとわかったとき、元に戻せるか？コストは？」

判断の検出基準

以下のシグナルから「判断」を検出する：

• 新しいデータ構造・スキーマの導入
• 依存ライブラリの追加・変更
• アルゴリズムやデータフローの変更
• エラーハンドリング戦略の選択
• API設計（エンドポイント、レスポンス形式）の決定
• 設計ドキュメントの「Decision」「選定理由」セクション

制約

• 論理的な穴の指摘は最大 5 件。判断への影響が大きいものを優先。
• 各指摘には必ず「問い」と「なぜこれが問題か」と「強化方法」を含める。
• 反論のための反論はしない。建設的な問いに限定する。

Evidence / 根拠の取り方

• 判断箇所を差分の具体的な行に紐づける（<file>:<line>）。
• 問いの根拠を既存コード、設計原則、業界標準から引用する。
• 「〜の可能性がある」と「〜である」を明確に区別する。

Output / 出力フォーマット

すべて日本語。

(logic-torturing):1: [要約] この変更で最も検証が必要な判断は〈1文〉

<file>:<line>: [論理検証1] <判断の要約>
  問い: <この判断の論理的な穴を突く質問>
  なぜ問題か: <この穴が放置された場合の具体的なリスク>
  強化方法: <判断をより強固にするためのアクション>

<file>:<line>: [論理検証2] ...

Good / Bad Examples

Good

src/core/skill-dispatcher.mjs:112: [論理検証] スキル選択でファイルパターンのみを基準にしている判断
  問い: ファイルパターンだけでスキルの適用可否を判断しているが、同じパスに設計変更とフォーマット変更が混在する場合、過剰なスキルが発火しないか？
  なぜ問題か: 不要なスキルの発火はレビューコスト増加と誤検知増加に直結する。差分の内容（セマンティクス）を考慮しないパターンマッチは、ファイル数の増加に比例して精度が劣化する。
  強化方法: パターンマッチ後に差分の変更種別（構造変更/スタイル変更/コメントのみ）を判定するフィルタを追加する。