sherlock-review

Sherlock Review

<default_to_action> コードに関する主張を調査する際は、次の手順に従います。

1. 観察：すべての証拠（コード、テスト、履歴、動作）を集めます
2. 推論：証拠が実際に示すことと、主張されたことを比較します
3. 排除：真実ではあり得ないことを除外します
4. 結論：証拠が主張を裏付けているか判断します
5. 記録：推測ではなく、証拠とともに調査結果を記録します

3 ステップの調査：

# 1. OBSERVE: Gather evidence
git diff <commit>
npm test -- --coverage

# 2. DEDUCE: Compare claim vs reality
# Does code match description?
# Do tests prove the fix/feature?

# 3. CONCLUDE: Verdict with evidence
# SUPPORTED / PARTIALLY SUPPORTED / NOT SUPPORTED

ホームズ流の原則：

• 「データだ！ データだ！ データだ！」 - 結論を出す前に集めます
• 「不可能なものを排除する」 - 真実ではあり得ないことは何でしょうか？
• 「あなたは見ているが、観察していない」 - 読むだけでなく、コードを実行します
• 再現可能な証拠だけを信頼します </default_to_action>

クイックリファレンスカード

証拠収集チェックリスト

カテゴリ	確認事項	方法
主張	PR の説明、コミットメッセージ	しっかり読みます
コード	実際のファイル変更	git diff
テスト	カバレッジ、アサーション	個別に実行します
動作	実行時の出力	ローカルで実行します
時系列	事象の発生時期	git log、git blame

判定レベル

判定	意味
✓ TRUE	証拠が主張を完全に裏付けています
⚠ PARTIALLY TRUE	主張は正確ですが、不完全です
✗ FALSE	証拠が主張と矛盾しています
? NONSENSICAL	主張が文脈に当てはまりません

---

調査テンプレート

## Sherlock Investigation: [Claim]

### The Claim
"[What PR/commit claims to do]"

### Evidence Examined
- Code changes: [files, lines]
- Tests added: [count, coverage]
- Behavior observed: [what actually happens]

### Deductive Analysis

**Claim**: [specific assertion]
**Evidence**: [what you found]
**Deduction**: [logical conclusion]
**Verdict**: ✓/⚠/✗

### Findings
- What works: [with evidence]
- What doesn't: [with evidence]
- What's missing: [gaps in implementation/testing]

### Recommendations
1. [Action based on findings]

調査結果の最低数の徹底

すべての調査で、少なくとも重み付けされた観察事項を 3 件提示する必要があります（CRITICAL=3、HIGH=2、MEDIUM=1、LOW=0.5）。基本的な観察事項は INFORMATIONAL=0.25 の重みで数えます。何も見つからない Sherlock 調査は失敗です。ホームズなら必ず手掛かりを見つけます。

---

調査シナリオ

シナリオ 1：「これでバグを修正しました」

手順：

1. 修正前のコミットでバグを再現します
2. 修正を含むコミットでバグが解消されたことを確認します
3. 修正が根本原因と症状のどちらに対処しているか確認します
4. 元の報告にないエッジケースをテストします

注意すべき点：

• エラーロギングを削除しただけの修正
• 特定のテストケースでしか動作しない
• 根本原因の修正ではなく、回避策を使用している
• 回帰テストが追加されていない

シナリオ 2：「パフォーマンスが 50% 向上しました」

手順：

1. ベースラインのコミットでベンチマークを実行します
2. 最適化したコミットで同じベンチマークを実行します
3. 同一条件で比較します
4. 測定方法を確認します

注意すべき点：

• おもちゃのようなデータだけでテストしている
• 比較条件が異なる
• トレードオフに触れていない

シナリオ 3：「すべてのエッジケースに対応しています」

手順：

1. コードパス内のすべてのエッジケースを列挙します
2. それぞれにテストカバレッジがあるか確認します
3. 境界条件をテストします
4. エラー処理の経路を確認します

注意すべき点：

• catch {} でエラーを握りつぶしている
• 汎用的なエラーメッセージ
• 重大なエラーをログに記録していない

---

調査例

## Case: PR #123 "Fix race condition in async handler"

### Claims Examined:
1. "Eliminates race condition"
2. "Adds mutex locking"
3. "100% thread safe"

### Evidence:
- File: src/handlers/async-handler.js
- Changes: Added `async/await`, removed callbacks
- Tests: 2 new tests for async flow
- Coverage: 85% (was 75%)

### Analysis:

**Claim 1: "Eliminates race condition"**
Evidence: Added `await` to sequential operations. No actual mutex.
Deduction: Race avoided by removing concurrency, not synchronization.
Verdict: ⚠ PARTIALLY TRUE (solved differently than claimed)

**Claim 2: "Adds mutex locking"**
Evidence: No mutex library, no lock variables, no sync primitives.
Verdict: ✗ FALSE

**Claim 3: "100% thread safe"**
Evidence: JavaScript is single-threaded. No worker threads used.
Verdict: ? NONSENSICAL (meaningless in this context)

### Conclusion:
Fix works but not for reasons claimed. Race condition avoided by
making operations sequential, not by adding synchronization.

### Recommendations:
1. Update PR description to accurately reflect solution
2. Add test for concurrent request handling
3. Remove incorrect technical claims

---

エージェントとの統合

// Evidence-based code review
await Task("Sherlock Review", {
  prNumber: 123,
  claims: [
    "Fixes memory leak",
    "Improves performance 30%"
  ],
  verifyReproduction: true,
  testEdgeCases: true
}, "qe-code-reviewer");

// Bug fix verification
await Task("Verify Fix", {
  bugCommit: 'abc123',
  fixCommit: 'def456',
  reproductionSteps: steps,
  testBoundaryConditions: true
}, "qe-code-reviewer");

---

エージェント連携のヒント

メモリの名前空間

aqe/sherlock/
├── investigations/*   - Investigation reports
├── evidence/*         - Collected evidence
├── verdicts/*         - Claim verdicts
└── patterns/*         - Common deception patterns

フリートの連携

const investigationFleet = await FleetManager.coordinate({
  strategy: 'evidence-investigation',
  agents: [
    'qe-code-reviewer',        // Code analysis
    'qe-security-auditor',     // Security claim verification
    'qe-performance-validator' // Performance claim verification
  ],
  topology: 'parallel'
});

---

関連スキル

• brutal-honesty-review - 技術的な問題を率直に指摘します
• context-driven-testing - 文脈に合わせて対応します
• bug-reporting-excellence - 調査結果を記録します

---

忘れずに

「データを得る前に理論を立てるのは、大きな誤りです。」 再現可能な証拠だけを信頼します。コミットメッセージ、ドキュメント、「自分の環境では動く」という言葉を鵜呑みにしてはいけません。

Sherlock の基準： すべての主張を実証的に検証する必要があります。証拠は実際に何を示しているでしょうか？