feat: 全レビュアーに coder-decisions.md 参照を追加し設計判断の FP を抑制

意図的な設計判断をレビュアーが誤検知（FP）しないよう、全 review-*.md に
{report:coder-decisions.md} の参照セクションを追加。ただし設計判断自体の
妥当性も評価する指示を含め、盲目的な通過を防ぐ。

builtins/en/facets/instructions/review-arch.md

@@ -12,6 +12,12 @@ Do not review AI-specific issues (already covered by the ai_review movement).
 - Call chain verification
 - Scattered hardcoding of contract strings (file names, config key names)
 
+
+**Design decisions reference:**
+Review {report:coder-decisions.md} to understand the recorded design decisions.
+- Do not flag intentionally documented decisions as FP
+- However, also evaluate whether the design decisions themselves are sound, and flag any problems
+
 **Previous finding tracking (required):**
 - First, extract open findings from "Previous Response"
 - Assign `finding_id` to each finding and classify current status as `new / persists / resolved`

builtins/en/facets/instructions/review-cqrs-es.md

@@ -11,6 +11,12 @@ AI-specific issue review is not needed (already covered by the ai_review movemen
 **Note**: If this project does not use the CQRS+ES pattern,
 review from a general domain design perspective instead.
 
+
+**Design decisions reference:**
+Review {report:coder-decisions.md} to understand the recorded design decisions.
+- Do not flag intentionally documented decisions as FP
+- However, also evaluate whether the design decisions themselves are sound, and flag any problems
+
 ## Judgment Procedure
 
 1. Review the change diff and detect issues based on the CQRS and Event Sourcing criteria above

builtins/en/facets/instructions/review-frontend.md

@@ -11,6 +11,12 @@ Review the changes from a frontend development perspective.
 **Note**: If this project does not include a frontend,
 proceed as no issues found.
 
+
+**Design decisions reference:**
+Review {report:coder-decisions.md} to understand the recorded design decisions.
+- Do not flag intentionally documented decisions as FP
+- However, also evaluate whether the design decisions themselves are sound, and flag any problems
+
 ## Judgment Procedure
 
 1. Review the change diff and detect issues based on the frontend development criteria above

builtins/en/facets/instructions/review-qa.md

@@ -7,6 +7,12 @@ Review the changes from a quality assurance perspective.
 - Logging and monitoring
 - Maintainability
 
+
+**Design decisions reference:**
+Review {report:coder-decisions.md} to understand the recorded design decisions.
+- Do not flag intentionally documented decisions as FP
+- However, also evaluate whether the design decisions themselves are sound, and flag any problems
+
 **Previous finding tracking (required):**
 - First, extract open findings from "Previous Response"
 - Assign `finding_id` to each finding and classify current status as `new / persists / resolved`

builtins/en/facets/instructions/review-requirements.md

@@ -6,6 +6,12 @@ Review the changes from a requirements fulfillment perspective.
 - Whether changes outside the scope (scope creep) have crept in
 - Whether there are any partial or missing implementations
 
+
+**Design decisions reference:**
+Review {report:coder-decisions.md} to understand the recorded design decisions.
+- Do not flag intentionally documented decisions as FP
+- However, also evaluate whether the design decisions themselves are sound, and flag any problems
+
 **Previous finding tracking (required):**
 - First, extract open findings from "Previous Response"
 - Assign `finding_id` to each finding and classify current status as `new / persists / resolved`

builtins/en/facets/instructions/review-security.md

@@ -4,6 +4,12 @@ Review the changes from a security perspective. Check for the following vulnerab
 - Data exposure risks
 - Cryptographic weaknesses
 
+
+**Design decisions reference:**
+Review {report:coder-decisions.md} to understand the recorded design decisions.
+- Do not flag intentionally documented decisions as FP
+- However, also evaluate whether the design decisions themselves are sound, and flag any problems
+
 ## Judgment Procedure
 
 1. Review the change diff and detect issues based on the security criteria above

builtins/en/facets/instructions/review-terraform.md

@@ -11,6 +11,12 @@ Do not review AI-specific issues (already covered by the ai_review movement).
 - Cost trade-off documentation
 - Unused variables / outputs / data sources
 
+
+**Design decisions reference:**
+Review {report:coder-decisions.md} to understand the recorded design decisions.
+- Do not flag intentionally documented decisions as FP
+- However, also evaluate whether the design decisions themselves are sound, and flag any problems
+
 **Previous finding tracking (required):**
 - First, extract open findings from "Previous Response"
 - Assign `finding_id` to each finding and classify current status as `new / persists / resolved`

builtins/en/facets/instructions/review-test.md

@@ -7,6 +7,12 @@ Review the changes from a test quality perspective.
 - Completeness (unnecessary tests, missing cases)
 - Appropriateness of mocks and fixtures
 
+
+**Design decisions reference:**
+Review {report:coder-decisions.md} to understand the recorded design decisions.
+- Do not flag intentionally documented decisions as FP
+- However, also evaluate whether the design decisions themselves are sound, and flag any problems
+
 ## Judgment Procedure
 
 1. Cross-reference the test plan/test scope reports in the Report Directory with the implemented tests

builtins/ja/facets/instructions/review-arch.md

@@ -12,6 +12,12 @@ AI特有の問題はレビューしないでください（ai_reviewムーブメ
 - 呼び出しチェーン検証
 - 契約文字列（ファイル名・設定キー名）のハードコード散在
 
+
+**設計判断の参照:**
+{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
+- 記録された意図的な判断は FP として指摘しない
+- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
+
 **前回指摘の追跡（必須）:**
 - まず「Previous Response」から前回の open findings を抽出する
 - 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved` で判定する

builtins/ja/facets/instructions/review-cqrs-es.md

@@ -11,6 +11,12 @@ CQRS（コマンドクエリ責務分離）とEvent Sourcing（イベントソ
 **注意**: このプロジェクトがCQRS+ESパターンを使用していない場合は、
 一般的なドメイン設計の観点からレビューしてください。
 
+
+**設計判断の参照:**
+{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
+- 記録された意図的な判断は FP として指摘しない
+- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
+
 ## 判定手順
 
 1. 変更差分を確認し、CQRS・イベントソーシングの観点に基づいて問題を検出する

builtins/ja/facets/instructions/review-frontend.md

@@ -11,6 +11,12 @@
 **注意**: このプロジェクトがフロントエンドを含まない場合は、
 問題なしとして次に進んでください。
 
+
+**設計判断の参照:**
+{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
+- 記録された意図的な判断は FP として指摘しない
+- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
+
 ## 判定手順
 
 1. 変更差分を確認し、フロントエンド開発の観点に基づいて問題を検出する

builtins/ja/facets/instructions/review-qa.md

@@ -7,6 +7,12 @@
 - ログとモニタリング
 - 保守性
 
+
+**設計判断の参照:**
+{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
+- 記録された意図的な判断は FP として指摘しない
+- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
+
 **前回指摘の追跡（必須）:**
 - まず「Previous Response」から前回の open findings を抽出する
 - 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved` で判定する

builtins/ja/facets/instructions/review-requirements.md

@@ -6,6 +6,12 @@
 - 要求にない変更（スコープクリープ）が紛れていないか
 - 部分実装や未実装がないか
 
+
+**設計判断の参照:**
+{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
+- 記録された意図的な判断は FP として指摘しない
+- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
+
 **前回指摘の追跡（必須）:**
 - まず「Previous Response」から前回の open findings を抽出する
 - 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved` で判定する

builtins/ja/facets/instructions/review-security.md

@@ -4,6 +4,12 @@
 - データ露出リスク
 - 暗号化の弱点
 
+
+**設計判断の参照:**
+{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
+- 記録された意図的な判断は FP として指摘しない
+- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
+
 ## 判定手順
 
 1. 変更差分を確認し、セキュリティの観点に基づいて問題を検出する

builtins/ja/facets/instructions/review-terraform.md

@@ -11,6 +11,12 @@ AI特有の問題はレビューしないでください（ai_reviewムーブメ
 - コストトレードオフの文書化
 - 未使用の variable / output / data source
 
+
+**設計判断の参照:**
+{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
+- 記録された意図的な判断は FP として指摘しない
+- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
+
 **前回指摘の追跡（必須）:**
 - まず「Previous Response」から前回の open findings を抽出する
 - 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved` で判定する

builtins/ja/facets/instructions/review-test.md

@@ -7,6 +7,12 @@
 - 過不足（不要なテスト、足りないケース）
 - モック・フィクスチャの適切さ
 
+
+**設計判断の参照:**
+{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
+- 記録された意図的な判断は FP として指摘しない
+- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
+
 ## 判定手順
 
 1. Report Directory内のテスト計画・テストスコープに関するレポートと実装されたテストを突合する