takt 0.32.0 → 0.32.2

package/builtins/ja/facets/instructions/security-audit-team-leader.md

@@ -0,0 +1,27 @@
+セキュリティ監査タスクを分解し、担当ファイルを割り当てて並列実行してください。
+
+**重要:** 計画レポートを参照してください: {report:01-plan.md}
+
+**やること:**
+
+1. 計画レポートのファイル一覧を確認し、監査対象の全ファイルを把握する
+2. ファイルをモジュール/レイヤー単位で3グループに分割する
+   - セキュリティリスクの高いファイル（認証、入力処理、外部通信等）を各グループに均等に分散する
+   - 関連するファイル（同一モジュール内）はなるべく同じグループにまとめる
+3. 各パートに排他的なファイル担当を割り当てる
+
+**各パートの instruction に以下を必ず明記する:**
+- **担当ファイル一覧**（Read で確認する全ファイルのパス）
+- **監査手順:**
+  1. 担当ファイルを**1つずつ Read tool で全文を読む**（Grep や部分読みで省略しない）
+  2. 各ファイルについてセキュリティ観点でレビューする
+  3. 発見した問題を重大度付きで報告する
+- **絶対禁止事項:**
+  - Grep でキーワード検索してヒットしたファイルだけ見る → 禁止。全ファイルを Read する
+  - ファイルの一部だけ読んで判断する → 禁止。全文を読む
+  - 「問題なさそう」で読み飛ばす → 禁止。全ファイルを確認する
+- **完了基準:** 担当ファイル全件の Read が完了し、各ファイルの監査結果を報告していること
+
+**制約:**
+- 各パートは読み取り専用。コードを変更しない
+- 担当外のファイルを監査しない（重複を防ぐ）

package/builtins/ja/facets/knowledge/e2e-testing.md

@@ -0,0 +1,89 @@
+# E2Eテスト知識
+
+## E2Eテストのスコープ
+
+E2Eテストはユーザーの操作フロー全体を検証する。ユニットテストやインテグレーションテストとはスコープが異なる。
+
+| テスト種別 | スコープ | 検証対象 |
+|-----------|---------|---------|
+| ユニット | 関数/クラス | ロジックの正しさ |
+| インテグレーション | モジュール間結合 | データフローの正しさ |
+| E2E | ユーザー操作フロー全体 | ユーザーから見た振る舞い |
+
+| 基準 | 判定 |
+|------|------|
+| ユニットテストでカバーできるロジック検証をE2Eで書く | 警告。ユニットテストに移動を検討 |
+| ユーザーが実行する操作フローの検証 | E2Eテストが適切 |
+| 複数コマンド/ページにまたがるシナリオ | E2Eテストが適切 |
+| エラーメッセージの表示確認 | E2Eテストが適切 |
+
+## UXルートの洗い出し
+
+E2Eテストの網羅性はユーザー操作ルートの洗い出しに依存する。ドキュメントではなくコードから起点を特定する。
+
+### 起点の特定方法
+
+| アプリケーション種別 | 起点の探し方 |
+|-------------------|------------|
+| CLI | コマンド定義、サブコマンド登録、オプション/フラグ定義をコードから抽出 |
+| Web | ルーティング定義、ページコンポーネント一覧をコードから抽出 |
+| API | エンドポイント定義、ルーター登録をコードから抽出 |
+
+### 分岐パターン
+
+各起点から分岐するルートを網羅的に列挙する。
+
+| 分岐パターン | 例 |
+|------------|-----|
+| オプション/フラグの組み合わせ | `--verbose` あり/なし、`--format json` vs `--format table` |
+| 状態による分岐 | 初回実行 vs 既存データあり、設定ファイルあり vs なし |
+| 権限/ロール | 管理者 vs 一般ユーザー、認証済み vs 未認証 |
+| 外部依存の状態 | 接続成功 vs タイムアウト、正常レスポンス vs エラーレスポンス |
+| エラーリカバリー | 途中で失敗した場合の再試行、ロールバック |
+| 入力バリエーション | 有効な入力、無効な入力、空入力、境界値 |
+
+
+## モック境界の設計
+
+E2Eテストでは「どこまで実物で動かし、どこからモックするか」の判断が重要。
+
+### モック設計の原則
+
+- テスト対象のアプリケーションコードはそのまま動かす
+- 外部サービスとの境界でモックを挿入する
+- モックは既存のフィクスチャ・ヘルパーのパターンに合わせる
+- 新しいモック機構を導入する前に既存のものを確認する
+
+## フレイキーテスト対策
+
+E2Eテストは非決定的な要因で失敗しやすい。
+
+| 原因 | 対策 |
+|------|------|
+| タイミング依存 | 明示的な待機条件を使う（固定 sleep ではなく状態ベースの待機） |
+| ポート競合 | テストごとにランダムポートを割り当てる |
+| ファイルシステムの残留 | テストごとに一時ディレクトリを作成し、終了時にクリーンアップ |
+| プロセスリーク | タイムアウトと強制終了を設定する |
+| 環境依存 | テスト実行に必要な前提条件を明示的にセットアップする |
+| 実行順序依存 | 各テストが独立して実行できるよう、状態を初期化する |
+
+```typescript
+// NG - 固定 sleep でタイミングを合わせる
+await sleep(3000)
+expect(result).toBeDefined()
+
+// OK - 条件ベースで待機する
+await waitFor(() => expect(result).toBeDefined(), { timeout: 5000 })
+```
+
+## テストケース管理
+
+E2Eテストの網羅性を保証するため、テストケースをリストで管理する。
+
+| 原則 | 内容 |
+|------|------|
+| 番号付きリスト | 各テストケースに一意の番号を付与し、実装状況を追跡する |
+| 起点ごとに分類 | コマンド/ページ/エンドポイント単位でグループ化する |
+| 優先度付け | ユーザー影響度 × 未テストのリスクで優先度を決定する |
+| 既存テストとの突き合わせ | 新規追加前に既存テストのカバー範囲を確認する |
+

package/builtins/ja/facets/knowledge/frontend.md

@@ -37,6 +37,40 @@ View コンポーネント（`features/*/components/*-view.tsx`）がデータ
 ルート（route） → View（データ取得・状態管理） → 子コンポーネント（表示）
 ```
 
+### 画面追加時のルーティング配線
+
+新しい画面を追加したら、画面コンポーネントを作るだけで終わらせず、到達経路まで配線する。Router、メニュー、導線のどこから到達するかを計画時点で固定する。
+
+| 基準 | 判定 |
+|------|------|
+| 新規ページを作成したのに Router に route がない | REJECT |
+| basename 配下の URL と route path の対応を確認していない | REJECT |
+| 画面実装と同時に Router / 導線 / 一時導線の要否を判断している | OK |
+| 開発用の一時導線を使う場合、その理由と後で除去する前提を記録している | OK |
+| route を更新したが、メニュー・ボタン・リンク・外部呼び出しなど実際の入口を未確認 | 警告 |
+
+```tsx
+// OK - 画面実装と route 配線を同時に追加
+<Route path="/contreg" element={<ContainerRegisterPage />} />
+
+// REJECT - 画面実装はあるが到達経路がない
+// src/pages/ContainerRegisterPage.tsx は存在する
+// Router には route がない
+```
+
+到達経路は Router だけではない。メニュー、一覧からの遷移ボタン、ダイアログ内の確定導線、外部画面からのリンクなど、利用者が実際にたどる入口を基準に確認する。
+
+### 外部UIライブラリとの統合
+
+DataGrid、日付ピッカー、チャート、仮想リストのような外部 UI ライブラリは、型が通っても実行時に落ちることがある。特にメジャーバージョン差分では、props 名や state model の互換性を shallow なモックだけでは検出できない。
+
+| 基準 | 判定 |
+|------|------|
+| 主要 UI ライブラリの props を、既存プロジェクトのバージョン確認なしに推測で渡す | REJECT |
+| テストでライブラリ本体を完全にモックし、実マウント時の破綻を見逃す | 警告 |
+| 代表的な props で実コンポーネントを描画し、画面レベルでクラッシュしないことを確認する | OK |
+| 既存画面の利用パターンやプロジェクト依存バージョンを参照して props 形を決める | OK |
+
 ## コンポーネント設計
 
 1ファイルにベタ書きしない。必ずコンポーネント分割する。
@@ -146,6 +180,7 @@ const Parent = () => {
 | 子から親への状態変更（逆方向データフロー） | REJECT |
 | APIレスポンスをそのまま状態に | 正規化を検討 |
 | useEffectの依存配列が不適切 | REJECT |
+| 初期取得が不安定な Context/Provider 関数参照に結び付いている | REJECT |
 
 状態配置の判断基準:
 
@@ -171,6 +206,17 @@ const Parent = () => {
 2. 既存の生成済みクライアントの使用パターンを確認
 3. 新規エンドポイントは生成パイプラインに追加し、生成されたフックを使う
 
+## 初期表示ロードと再取得境界
+
+初期表示ロードはリアクティブな再取得と分けて扱う。URL、フィルタ、ページング、明示的な更新操作がない限り、初回ロードは mount-only に保ち、不安定なコールバック参照に結び付けない。
+
+| 基準 | 判定 |
+|------|------|
+| Provider/Context の関数参照変化で初期取得が再実行される | REJECT |
+| 再取得条件が URL・フィルタ・ページング・更新操作として明示されている | OK |
+| メッセージ表示、loading 切替、dialog 開閉で再取得される | REJECT |
+| 初期取得は mount-only、以後の再取得は明示トリガーで行う | OK |
+
 ## データ取得
 
 API呼び出しはルート（View）コンポーネントで行い、子コンポーネントにはpropsで渡す。

package/builtins/ja/facets/knowledge/react.md

@@ -0,0 +1,90 @@
+# React知識
+
+## effect と再実行
+
+`useEffect` は「いつ再実行してよいか」を明示する仕組みであり、初期化処理の置き場ではない。初期表示で1回だけ行う処理か、依存変化で再実行すべき処理かを先に決める。
+
+| 基準 | 判定 |
+|------|------|
+| 初期表示の一度きりのロードなのに、再生成される関数参照を依存に置く | REJECT |
+| 再取得条件が明確でないのに、Context/Provider 由来関数を依存に置く | REJECT |
+| mount-only 初期化を `useEffect(..., [])` で表現し、意図をコメントで残す | OK |
+| 依存変化時の再取得が仕様として必要で、その依存を明示している | OK |
+
+```tsx
+// REJECT - 初期取得なのに不安定な関数依存を経由して再実行されうる
+const fetchList = useCallback(async () => {
+  await loadItems()
+}, [setIsLoading, errorPage])
+
+useEffect(() => {
+  fetchList()
+}, [fetchList])
+
+// OK - 初期表示の一度きりロードとして固定
+useEffect(() => {
+  void loadItemsOnMount()
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## Context と Provider value
+
+Context の `value={{ ... }}` は Provider の再描画ごとに新しい参照になる。Context から受け取った関数を `useEffect` の依存に置くと、利用側が意図せず再実行ループに入ることがある。
+
+| 基準 | 判定 |
+|------|------|
+| Context 由来関数の参照安定性を確認せず、effect 依存に入れる | REJECT |
+| Provider 側で value の安定性が保証されていないのに mount effect の依存に使う | REJECT |
+| Context 関数はイベントハンドラから使い、初期取得は mount-only に閉じる | OK |
+| Provider 側で value 安定化を行い、再取得条件も仕様で定義する | OK |
+
+```tsx
+// REJECT - Context 関数をそのまま初期取得 effect の依存に使う
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData(setIsLoading, errorPage)
+}, [setIsLoading, errorPage])
+
+// OK - 初期取得は mount-only、Context 関数は内部で使う
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData({ setIsLoading, errorPage })
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## 初期表示ロード
+
+初期表示ロードは「画面を開いたときに1回だけ必要な処理」か、「状態変化に応じて再実行する処理」かを区別する。後者でない限り、再取得のトリガーは明示的なユーザー操作や URL/検索条件の変化に限定する。
+
+| 条件 | 推奨 |
+|------|------|
+| 初期表示で一覧を1回読むだけ | mount-only effect |
+| フィルタ、ページング、URL パラメータ変更で再取得 | その状態を依存に明示 |
+| loading state 更新で再取得が走る | REJECT |
+| message 表示や dialog 開閉で再取得が走る | REJECT |
+
+## custom hook の責務
+
+React custom hook は「React の state/effect/ref を使う状態遷移」に限定する。純粋計算だけなら custom hook ではなく関数モジュールでよい。
+
+| 基準 | 判定 |
+|------|------|
+| React の state/effect を使わないのに `use*` と命名する | 警告 |
+| 純関数群を custom hook として扱う | 警告 |
+| stateful な UI 制御は custom hook に、純粋計算は function module に分ける | OK |
+| hook が JSX を返す | REJECT |
+
+## exhaustive-deps の扱い
+
+`react-hooks/exhaustive-deps` は無条件で従うものではなく、effect の意味を壊さない範囲で従う。mount-only 初期化で依存を増やすと挙動が壊れる場合は、理由を残して抑制する。
+
+| 基準 | 判定 |
+|------|------|
+| ルールに従うためだけに不要な再実行依存を追加する | REJECT |
+| lint 抑制を無言で入れる | 警告 |
+| mount-only の理由をコメントで説明して抑制する | OK |
+| 再実行が必要な effect なのに `[]` にする | REJECT |

package/builtins/ja/facets/knowledge/unit-testing.md

@@ -0,0 +1,108 @@
+# ユニットテスト知識
+
+## テストダブルの使い分け
+
+テストダブルは目的に応じて使い分ける。過剰なモックはテストの信頼性を下げる。
+
+| 種類 | 目的 | 使用場面 |
+|------|------|---------|
+| Stub | 固定値を返す | 外部依存の出力を制御したい |
+| Mock | 呼び出しを検証する | メソッド呼び出しの有無・引数を確認したい |
+| Spy | 実装を残しつつ呼び出しを記録 | 副作用の検証をしたい |
+| Fake | 簡易的な実装 | インメモリDBなど軽量な代替が必要 |
+
+### モック粒度の判断
+
+- テスト対象の直接の依存のみモックする（間接依存はモックしない）
+- 「モックが多すぎる」はテスト対象の設計の問題を示唆する
+- 純粋関数は依存がないのでモック不要
+
+```typescript
+// NG - 内部実装をモック（振る舞いではなく実装を検証している）
+vi.spyOn(service, 'privateMethod')
+service.execute()
+expect(service.privateMethod).toHaveBeenCalled()
+
+// OK - 外部依存をモックし、振る舞いを検証
+const repository = { findById: vi.fn().mockResolvedValue(user) }
+const service = new UserService(repository)
+const result = await service.getUser('id')
+expect(result).toEqual(user)
+```
+
+## 境界値分析
+
+境界値と同値分割はユニットテストの基本手法。
+
+| 手法 | 内容 |
+|------|------|
+| 同値分割 | 入力を等価なグループに分け、各グループから1つずつテスト |
+| 境界値分析 | 同値クラスの境界でテスト（境界、境界±1） |
+
+```typescript
+// NG - 正常系のみ
+test('validates age', () => {
+  expect(validateAge(25)).toBe(true)
+})
+
+// OK - 境界値を含む
+test('validates age at boundaries', () => {
+  expect(validateAge(0)).toBe(true)    // 下限
+  expect(validateAge(-1)).toBe(false)  // 下限-1
+  expect(validateAge(150)).toBe(true)  // 上限
+  expect(validateAge(151)).toBe(false) // 上限+1
+})
+```
+
+## テストフィクスチャ設計
+
+テストデータはファクトリ関数で管理する。
+
+- ファクトリ関数で必要最小限のフィクスチャを生成する
+- テストに無関係なフィールドはデフォルト値で埋める
+- 共有フィクスチャを変更して使い回さない（テスト間の独立性を保つ）
+
+```typescript
+// NG - 全フィールドを毎回定義
+const user = { id: '1', name: 'test', email: 'test@example.com', role: 'admin', createdAt: new Date() }
+
+// OK - ファクトリ関数で必要最小限
+const createUser = (overrides: Partial<User> = {}): User => ({
+  id: 'test-id',
+  name: 'test-user',
+  email: 'test@example.com',
+  role: 'user',
+  ...overrides,
+})
+
+test('admin can delete', () => {
+  const admin = createUser({ role: 'admin' })
+  // テストに関係するフィールドだけ明示
+})
+```
+
+## テスト対象の分離
+
+テスト容易性は設計品質の指標。テストしにくいコードは依存が密結合している。
+
+### 依存注入パターン
+
+| パターン | 使用場面 |
+|---------|---------|
+| コンストラクタ注入 | クラスベースの依存分離 |
+| 関数引数 | 関数の依存を引数で受け取る |
+| モジュール差し替え | テスト時にモジュール全体を差し替える |
+
+```typescript
+// NG - 直接依存を生成（テストでモック不可）
+class OrderService {
+  private repo = new OrderRepository()
+  async create(order: Order) { return this.repo.save(order) }
+}
+
+// OK - コンストラクタ注入（テストでモック可能）
+class OrderService {
+  constructor(private readonly repo: OrderRepository) {}
+  async create(order: Order) { return this.repo.save(order) }
+}
+```

package/builtins/ja/facets/output-contracts/e2e-coverage-plan.md

@@ -0,0 +1,33 @@
+```markdown
+# E2Eカバレッジ計画
+
+## プロジェクト概要
+{技術スタック、E2Eテストフレームワーク、テスト実行コマンド}
+
+## ユーザー操作の起点
+| # | 起点 | 種別 | ハンドラ |
+|---|------|------|---------|
+| 1 | {コマンド名/ルート/エンドポイント} | CLI/Web/API | `src/file.ts:42` |
+
+## UXルート分析
+### {起点名}
+| # | ルート | 分岐条件 | 既存テスト |
+|---|--------|---------|-----------|
+| 1 | {正常フロー} | - | ✅ `e2e/file.test.ts` / ❌ なし |
+| 2 | {オプションX有効時} | `--flag` | ❌ なし |
+| 3 | {エラー時} | {条件} | ❌ なし |
+
+## 不足テストケースリスト
+| # | 起点 | テストケース | 優先度 | 検証すべき期待結果 |
+|---|------|------------|--------|-----------------|
+| 1 | {起点} | {ケース概要} | 高/中/低 | {期待結果} |
+| 2 | {起点} | {ケース概要} | 高/中/低 | {期待結果} |
+
+## テスト方針
+- {モック戦略}
+- {フィクスチャ設計}
+- {既存ヘルパーの活用}
+
+## 実装ガイドライン
+- {テスト実装者向けの指示}
+```

package/builtins/ja/facets/output-contracts/plan-frontend.md

@@ -0,0 +1,41 @@
+```markdown
+# タスク計画
+
+## 元の要求
+{ユーザーの要求をそのまま記載}
+
+## 分析結果
+
+### 目的
+{達成すべきこと}
+
+### 参照資料の調査結果（参照資料がある場合）
+{参照資料の実装アプローチの概要と、現在の実装との主要な差異}
+
+### デザイン要素の判定（デザイン参照がある場合）
+| 要素 | 変更要/不要 | 根拠 |
+|------|-------------|------|
+
+### スコープ
+{影響範囲}
+
+### 検討したアプローチ（設計判断がある場合）
+| アプローチ | 採否 | 理由 |
+|-----------|------|------|
+
+### 実装アプローチ
+{どう進めるか}
+
+## 実装ガイドライン（設計が必要な場合のみ）
+- {Coderが実装時に従うべき指針}
+
+## スコープ外（項目がある場合のみ）
+| 項目 | 除外理由 |
+|------|---------|
+
+デザイン参照がある場合:
+- {除外した要素名と、除外理由・代替しない理由}
+
+## 確認事項（あれば）
+- {不明点や確認が必要な点}
+```

package/builtins/ja/facets/output-contracts/plan.md

@@ -22,6 +22,14 @@
 ### 実装アプローチ
 {どう進めるか}
 
+### 到達経路・起動条件（利用者向け機能の追加/変更がある場合）
+| 項目 | 内容 |
+|------|------|
+| 利用者が到達する入口 | {メニュー/route/ボタン/リンク/外部呼び出し など。なければ「入口なし」と明記} |
+| 更新が必要な呼び出し元・配線 | {更新対象のファイルや層} |
+| 起動条件 | {認証、権限、URL条件、フラグなど} |
+| 未対応項目 | {残っている配線があれば明記。なければ「なし」} |
+
 ## 実装ガイドライン（設計が必要な場合のみ）
 - {Coderが実装時に従うべき指針}
 

package/builtins/ja/facets/output-contracts/security-audit.md

@@ -0,0 +1,31 @@
+```markdown
+# セキュリティ監査レポート
+
+## 結果: APPROVE / REJECT
+
+## 重大度: None / Low / Medium / High / Critical
+
+## 監査対象
+| # | ファイル | 監査済み | リスク分類 |
+|---|---------|---------|-----------|
+| 1 | `src/file.ts` | ✅ | 高 / 中 / 低 |
+
+## 検出された問題
+| # | 重大度 | カテゴリ | 場所 | 問題 | 修正案 |
+|---|--------|---------|------|------|--------|
+| 1 | Critical | injection | `src/file.ts:42` | {問題の説明} | {修正方法} |
+
+## 問題なしのファイル
+- {問題が検出されなかったファイルの一覧}
+
+## 推奨事項（非ブロッキング）
+- {セキュリティ改善の提案}
+
+## REJECT判定条件
+- High または Critical の問題が1件以上ある場合は REJECT
+```
+
+**認知負荷軽減ルール:**
+- 問題なし → 監査対象テーブルのみ（15行以内）
+- Low/Medium のみ → + 問題テーブル（30行以内）
+- High/Critical あり → 全セクション出力

package/builtins/ja/facets/personas/coder.md

@@ -19,6 +19,7 @@
 - 速さより丁寧さ。実装の楽さよりコードの正確さ
 - 「とりあえず動く」より「正しく動く」を優先
 - 推測で実装せず、不明点は報告する
+- デザイン参照が指定されている場合、UIの見た目・構造・文言をデザインに一致させる。独自判断で追加・省略・変更しない
 - 作業は必ず指定されたプロジェクトディレクトリ内で行う（参照読みのみ外部可）
 
 **レビュワーの指摘は絶対。あなたの認識が間違っている。**

package/builtins/ja/facets/personas/frontend-reviewer.md

@@ -13,6 +13,7 @@
 - TypeScript型安全性の検証
 - フロントエンドセキュリティの確認
 - フロントエンド/バックエンド責務分離の検証
+- デザイン参照が指定されている場合、実装とデザインの一致度検証
 
 **やらないこと:**
 - バックエンドのアーキテクチャレビュー（Architecture Reviewerが担当）
@@ -27,3 +28,4 @@
 - アクセシビリティは後付け困難。最初から組み込む
 - 過度な抽象化を警戒。シンプルに保つ
 - フレームワークの作法に従う。独自パターンより標準的なアプローチ
+- デザイン参照があれば、UXの良し悪しより先にデザインとの一致を確認する

package/builtins/ja/facets/policies/ai-antipattern.md

@@ -75,6 +75,49 @@ await processFile(input, output, formatOpt);
 2. 差異がオプション引数の有無のみなら、三項演算子やスプレッド構文で統一
 3. 分岐ごとに異なる前処理がある場合は、変数に結果を格納してから単一呼び出しに統一
 
+## コールバック + 外部変数キャプチャの濫用
+
+AIは戻り値で返せるデータを、コールバック関数と外部変数のキャプチャで実装しがちである。
+
+| パターン | 例 | 判定 |
+|---------|-----|------|
+| コールバックで外部変数に代入 | `let result; await f(x => { result = x })` | REJECT |
+| イベントハンドラ経由で値を取得 | `emitter.on('data', d => { captured = d })` で同期的に値を取得 | REJECT |
+| 複数のコールバックで外部状態を組み立て | `forEach(item => {外部Map.set(...) })` で結果を構築 | REJECT |
+
+```typescript
+// REJECT - コールバックで外部変数をキャプチャ
+let selectedMode: string | undefined;
+await promptUser(choices, (choice) => {
+  selectedMode = choice;
+});
+return selectedMode;
+
+// OK - 戻り値で受け取る
+const selectedMode = await promptUser(choices);
+return selectedMode;
+```
+
+検証アプローチ:
+1. コールバック関数内で外部スコープの変数に代入している箇所を探す
+2. その値が関数の戻り値で返せるか確認
+3. 返せる場合は戻り値パターンに書き換えを指摘する
+
+## レビュー指摘への不適切な対応検出
+
+AIはレビュー指摘を「修正」する代わりに、テストやドキュメントで「指摘内容を検証する」コードを追加して対応したつもりになることがある。
+
+| パターン | 例 | 判定 |
+|---------|-----|------|
+| 指摘の修正ではなくテストの追加 | 「コメント不要」→ コメントの有無を検証するテストを追加 | REJECT |
+| 指摘の修正ではなくドキュメントの追加 | 「DRY違反」→ 重複が意図的である旨のドキュメントを追加 | REJECT |
+| 指摘と無関係なファイルの変更 | セキュリティ指摘 → 全く別のリファクタリングを実施 | REJECT |
+
+検証アプローチ:
+1. 修正差分が指摘の対象ファイル・対象行に対する変更を含んでいるか確認
+2. 新規ファイル追加のみで対応している場合、そのファイルが指摘の「修正」ではなく「検証」になっていないか確認
+3. テスト追加が指摘への対応の場合、テストが「修正後の正しい動作」を検証しているか（「指摘内容そのもの」を検証していないか）確認
+
 ## コンテキスト適合性評価
 
 コードはこの特定のプロジェクトに合っているか?