Logic Torturing

---
id: 'logic-torturing'
name: 'Logic Torturing 論理検証'
description: '変更に含まれる設計判断・実装選択の論理的整合性を徹底的に検証し、確証バイアスを排除して判断精度を高める'
version: 0.1.0
category: midstream
phase: [upstream, midstream]
applyTo:
  - 'src/**/*.{ts,tsx,js,jsx,mjs}'
  - 'docs/**/*design*.md'
  - 'docs/adr/**/*'
  - 'pages/**/*design*.md'
  - 'pages/**/*architecture*.md'
tags: [adversarial, logic-torturing, decision-quality, critical-thinking, midstream, cognitive-bias]
severity: major
inputContext: [diff, fullFile, commitMessage, adr]
outputKind: [findings, questions]
modelHint: high-accuracy
dependencies: [code_search, repo_metadata]
---

## 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 / 出力フォーマット

すべて日本語。

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

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

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

## Good / Bad Examples

### Good

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

### Bad

```text
src/core/skill-dispatcher.mjs:112: 他のやり方もあると思う
```

（問いが曖昧、リスクの説明なし、強化方法なし）

## 評価指標（Evaluation）

- 合格基準: 指摘が差分内の具体的な判断に紐づき、「問い」「なぜ問題か」「強化方法」の3要素が揃っている。
- 不合格基準: 差分と無関係な一般論、反論のための反論、建設的でない批判。

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

- 判断の背景にビジネス要件や組織的制約がある場合（コードからは見えない理由）。
- トレードオフの優先順位付けが必要な場合。
- 複数の判断が相互に依存し、1つの判断だけでは評価できない場合。