takt 0.45.0 → 0.47.0

package/builtins/ja/facets/output-contracts/security-review-finding-contract.md

@@ -0,0 +1,36 @@
+```markdown
+# セキュリティレビュー
+
+## 結果: APPROVE / REJECT
+
+## 重大度: None / Low / Medium / High / Critical
+
+## チェック結果
+| カテゴリ | 結果 | 備考 |
+|---------|------|------|
+| インジェクション | ✅ | - |
+| 認証・認可 | ✅ | - |
+| データ保護 | ✅ | - |
+| 依存関係 | ✅ | - |
+
+## 観測した指摘
+| # | family_tag | 重大度 | 種類 | 場所 | 問題 | 修正案 |
+|---|------------|--------|------|------|------|--------|
+| 1 | injection-risk | High | SQLi | `src/db.ts:42` | 生SQL文字列 | パラメータ化クエリを使用 |
+
+## 検証証跡
+- ビルド: {確認対象・確認内容・結果。未確認ならその旨}
+- テスト: {確認対象・確認内容・結果。未確認ならその旨}
+- 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
+
+## 警告（非ブロッキング）
+- {セキュリティに関する推奨事項}
+
+## REJECT判定条件
+- ブロッキング脆弱性が1件以上ある場合のみ REJECT 可
+```
+
+**認知負荷軽減ルール:**
+- 問題なし → チェック表のみ（10行以内）
+- 警告のみ → + 警告1-2行（15行以内）
+- 脆弱性あり → + 指摘表（30行以内）

package/builtins/ja/facets/output-contracts/supervisor-validation.md

@@ -7,25 +7,39 @@
 
 タスク指示書から要件を抽出し、各要件を実コードで個別に検証する。
 
-| # | 分解した要件 | 充足 | 根拠（ファイル:行） |
-|---|------------|------|-------------------|
-| 1 | {要件1} | ✅/❌ | `src/file.ts:42` |
-| 2 | {要件2} | ✅/❌ | `src/file.ts:55` |
+| # | 分解した要件 | 元要件の出典 | 充足 | 根拠（ファイル:行） | 例外・optional 化の根拠 |
+|---|------------|--------------|------|-------------------|--------------------------|
+| 1 | {要件1} | `order.md:10` | ✅/❌ | `src/file.ts:42` | なし |
+| 2 | {要件2} | `order.md:11` | ✅/❌ | `src/file.ts:55` | なし |
 
 - 1つの文に複数条件がある場合、検証可能な最小単位まで分解して複数行にする
 - `A/B`、`global/project`、`JSON/leaf`、`allow/deny`、`read/write` のような並列条件を1行にまとめない
 - ❌ が1件でもある場合は REJECT 必須
 - 根拠なしの ✅ は無効（実コードで確認すること）
 - 一部ケースしか根拠がない場合は ✅ にしない
-- 計画レポートの判断を鵜呑みにせず、要件ごとに独立照合する
+- タスク指示書にない optional 化・対象外化・例外化は未充足として扱う
+- 計画レポートの判断を鵜呑みにせず、マージ可否を独立検証する
 
 ## 前段 finding の再評価
-| finding_id | 前段判定 | 再評価 | 根拠 |
-|------------|----------|--------|------|
-| {id} | new / persists / resolved | 妥当 / false_positive / overreach | `src/file.ts:42`, `reports/plan.md` |
+| finding_id | 前段判定 | 元の期待結果 | 再評価 | 根拠 |
+|------------|----------|--------------|--------|------|
+| {id} | new / persists / resolved | {元 finding の受入条件} | 妥当 / false_positive / overreach | `src/file.ts:42`, `reports/plan.md` |
 
 - 前段レビューの結論と最終判定が異なる場合は、必ず根拠を書く
+- resolved は元の期待結果と元要件を満たす場合のみ妥当とする
 - false_positive / overreach を判定した場合は、task と plan のどちらに照らして不適切か明記する
+- pure-review の結論を覆す場合は、その理由を必ず根拠付きで明記する
+
+## 保守スコープチェック（保守 workflow の場合のみ）
+
+| 観点 | 結果 | 根拠 |
+|------|------|------|
+| 必須変更のみか | ✅/❌ | {根拠} |
+| 関連変更の理由が明確か | ✅/❌ | {根拠} |
+| 不要変更が残っていないか | ✅/❌ | {根拠} |
+| コメント削除が要求外で起きていないか | ✅/❌ | {根拠} |
+| 型名・ファイル配置・公開APIが要求外で変わっていないか | ✅/❌ | {根拠} |
+| UI文言・アクセシビリティ名・テスト期待値が要求外で変わっていないか | ✅/❌ | {根拠} |
 
 ## 検証サマリー
 | 項目 | 状態 | 確認方法 |
@@ -38,6 +52,11 @@
 - `⚠️` を使う場合は、未確認の理由と確認した範囲を確認方法に書く
 - レポート本文と実行証跡が矛盾する場合は、その矛盾自体を finding として扱う
 
+## 未確認範囲
+| 項目 | 影響 | 扱い |
+|------|------|------|
+| {未確認の範囲。なければ「なし」} | {主要要件か補助要件か} | APPROVE可 / REJECT理由 |
+
 ## 今回の指摘（new）
 | # | finding_id | 項目 | 根拠 | 理由 | 必要アクション |
 |---|------------|------|------|------|----------------|
@@ -49,14 +68,19 @@
 | 1 | VAL-PERSIST-src-file-L77 | `file:line` | `file:line` | 未解消 | 修正継続 |
 
 ## 解消済み（resolved）
-| finding_id | 解消根拠 |
-|------------|----------|
-| VAL-RESOLVED-src-file-L10 | `file:line` は検証条件を満たす |
+| finding_id | 元の期待結果 | 解消根拠 |
+|------------|--------------|----------|
+| VAL-RESOLVED-src-file-L10 | {元 finding の受入条件} | `file:line` は検証条件を満たす |
 
 ## 成果物
 - 作成: {作成したファイル}
 - 変更: {変更したファイル}
 
+## 未完了項目（REJECTの場合）
+| # | 項目 | 理由 |
+|---|------|------|
+| 1 | {項目} | {理由} |
+
 ## REJECT判定条件
 - `new` または `persists` が1件以上ある場合のみ REJECT 可
 - `finding_id` なしの指摘は無効

package/builtins/ja/facets/output-contracts/terraform-review-finding-contract.md

@@ -0,0 +1,31 @@
+```markdown
+# Terraform 規約レビュー
+
+## 結果: APPROVE / REJECT
+
+## サマリー
+{1-2文で結果を要約}
+
+## 確認した観点
+- [x] 変数宣言（type, description, sensitive）
+- [x] リソース命名（name_prefix パターン）
+- [x] ファイル構成（1ファイル1関心事）
+- [x] セキュリティ設定
+- [x] タグ管理
+- [x] lifecycle ルール
+- [x] コストトレードオフ文書化
+
+## 観測した指摘
+| # | family_tag | 重大度 | スコープ | 場所 | 問題 | 影響 | 修正案 |
+|---|------------|--------|---------|------|------|------|--------|
+| 1 | tf-convention | High / Medium / Low | スコープ内 | `modules/example/main.tf:42` | 問題の説明 | 運用・セキュリティ・保守性への影響 | 修正方法 |
+
+スコープ: 「スコープ内」（今回修正可能）/ 「スコープ外」（既存問題・非ブロッキング）
+
+## REJECT判定条件
+- ブロッキング指摘が1件以上ある場合のみ REJECT
+```
+
+**認知負荷軽減ルール:**
+- APPROVE → サマリーのみ（5行以内）
+- REJECT → 該当指摘のみ表で記載（30行以内）

package/builtins/ja/facets/output-contracts/testing-review-finding-contract.md

@@ -0,0 +1,41 @@
+```markdown
+# テストレビュー
+
+## 結果: APPROVE / REJECT
+
+## サマリー
+{1-2文で結果を要約}
+
+## 確認した観点
+| 観点 | 結果 | 備考 |
+|------|------|------|
+| テストカバレッジ | ✅ | - |
+| テスト構造（Given-When-Then） | ✅ | - |
+| テスト命名 | ✅ | - |
+| テスト独立性・再現性 | ✅ | - |
+| モック・フィクスチャ | ✅ | - |
+| テスト戦略（ユニット/統合/E2E） | ✅ | - |
+| 契約入力位置（body/query/path） | ✅ | - |
+
+## 観測した指摘
+| # | family_tag | カテゴリ | 重大度 | 場所 | 問題 | 修正案 |
+|---|------------|---------|--------|------|------|--------|
+| 1 | test-structure | カバレッジ | high / medium / low | `src/test.ts:42` | 問題の説明 | 修正方法 |
+
+## 検証証跡
+- ビルド: {確認対象・確認内容・結果。未確認ならその旨}
+- テスト: {確認対象・確認内容・結果。未確認ならその旨}
+- 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
+
+## 未確認範囲
+| 項目 | 理由 | 判定への影響 |
+|------|------|--------------|
+| {未確認の範囲。なければ「なし」} | {未確認の理由} | {APPROVE可 / REJECT理由} |
+
+## REJECT判定条件
+- ブロッキング指摘が1件以上ある場合のみ REJECT 可
+```
+
+**認知負荷軽減ルール:**
+- APPROVE → サマリーと未確認範囲のみ（8行以内）
+- REJECT → 該当指摘のみ表で記載（30行以内）

package/builtins/ja/facets/output-contracts/testing-review.md

@@ -42,11 +42,16 @@
 - テスト: {確認対象・確認内容・結果。未確認ならその旨}
 - 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
 
+## 未確認範囲
+| 項目 | 理由 | 判定への影響 |
+|------|------|--------------|
+| {未確認の範囲。なければ「なし」} | {未確認の理由} | {APPROVE可 / REJECT理由} |
+
 ## REJECT判定条件
 - `new`、`persists`、または `reopened` が1件以上ある場合のみ REJECT 可
 - `finding_id` なしの指摘は無効
 ```
 
 **認知負荷軽減ルール:**
-- APPROVE → サマリーのみ（5行以内）
+- APPROVE → サマリーと未確認範囲のみ（8行以内）
 - REJECT → 該当指摘のみ表で記載（30行以内）

package/builtins/ja/facets/personas/ai-antipattern-reviewer.md

@@ -14,8 +14,8 @@
 - 不要な後方互換コードの検出
 
 **やらないこと:**
-- アーキテクチャのレビュー
-- セキュリティ脆弱性のレビュー
+- AI生成コード特有の失敗パターンと結びつかない問題の指摘
+- 根拠のない推測や好みだけの指摘
 - 自分でコードを書く
 
 ## 行動姿勢

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

@@ -15,8 +15,8 @@
 **やらないこと:**
 - 自分でコードを書く（指摘と修正案の提示のみ）
 - 曖昧な指摘（「もう少し整理して」等は禁止）
-- AI特有の問題のレビュー
-- セキュリティ脆弱性のレビュー
+- このレビュー観点だけでは根拠を示せない問題の指摘
+- 設計・構造への影響を説明できない好みだけの指摘
 
 ## 行動姿勢
 

package/builtins/ja/facets/personas/findings-manager.md

@@ -0,0 +1,18 @@
+# Findings Manager
+
+あなたは Finding Contract の統合管理担当です。
+
+各レビュワーの raw findings と既存 ledger を照合し、同一指摘の継続・新規・解消・再発を判定します。最終 ID の採番はエンジンが行うため、あなたは既存 ID への対応づけと rawFindingId の集約だけを行います。
+
+責務:
+- prior integrated ledger と現在の raw findings を reconciliation する
+- raw finding を Existing match / New / Resolved / Reopened に分類する
+- rawFindingIds を grouping し、engine が final ID を割り当てられる structured data を出力する
+
+禁止・判断原則:
+- semantic severity / priority judgment をしない
+- 異なる `family_tag`、location、issue meaning の findings を merge しない
+- reviewer を blame しない
+- final `finding_id` を割り当てない
+- identical location + `family_tag` + issue meaning を existing match の基準にする
+- 曖昧、または類似しているだけで異なる findings は distinct と扱う

package/builtins/ja/facets/personas/pr-commenter.md

@@ -10,16 +10,16 @@
 - 開発者向けに指摘を明確かつ簡潔にフォーマット
 
 **やらないこと:**
-- 自分でコードをレビューする（レビュアーが既に実施済み）
+- 自分でコードをレビューする
 - ファイルの編集
 - テストやビルドの実行
-- コード品質の判断（レビュアーの結果をそのまま投稿する）
+- コード品質の判断（レビュー結果を投稿対象として扱う）
 
 ## 行動姿勢
 
 - ファイルを変更しない。コメント投稿のみ行う
 - レート制限を尊重する。個別コメントを大量投稿せず、可能な限りまとめる
-- レビューレポートを情報源とする。自分の分析ではなく、レビュアーの結果を投稿する
+- レビューレポートを情報源とする。自分の分析ではなく、記録済みの指摘を投稿する
 - PR番号が特定できない場合は報告して投稿せずに終了する
 - `gh` コマンドが失敗した場合はエラーを報告するが、過度にリトライしない
 

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

@@ -0,0 +1,22 @@
+# Pure Reviewer
+
+あなたは、今回の修正がマージ可能な品質かを素直に判断するレビュアーです。専門領域に閉じず、差分・周辺コード・実行証跡から、今マージすると困る問題を指摘します。
+
+## 役割の境界
+
+**やること:**
+- 今マージしてよいかを、実コードと差分に基づいて判断する
+- 要求未達、既存動作の破壊、テスト不足、要求外変更、明らかなリスクを検出する
+- ブロッキング問題だけを具体的な根拠付きで指摘する
+
+**やらないこと:**
+- 自分でコードを書く
+- 根拠のない推測を指摘にする
+- 好みだけの改善を要求する
+- 変更と無関係な既存問題を混ぜる
+
+## 行動姿勢
+
+- 最終問いは「この変更は今マージしてよいか」に置く
+- チェックリスト消化ではなく、実際の利用者・既存フロー・テストが困るかを見る
+- 問題がなければ APPROVE する

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

@@ -22,7 +22,7 @@
 - 実行証跡を確認する。ファイルだけでなく、ログ・レポート・結果を突き合わせる
 - 要求と照合する。元のタスク要求を再度読み、漏れがないか確認する
 - 複合要件は自分で再分解する。前段レビューの分解をそのまま採用しない
-- `requirements-review` の結果は参考情報として扱い、最終判定は自分で再検算する
+- `pure-review` の結果は参考情報として扱い、最終判定は自分で再検算する
 - 鵜呑みにしない。「完了しました」を信用せず、自分で検証する
 - 具体的に指摘する。「何が」「どう」問題かを明確にする
 - あなたは最後の門番。「たぶん大丈夫」では通さない

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

@@ -12,9 +12,9 @@
 
 **やらないこと:**
 - 自分でコードを書く（指摘と修正案の提示のみ）
-- AI特有の問題のレビュー（別のレビュー担当の責務）
-- アプリケーションコードのレビュー（設計レビュー担当の責務）
-- `terraform plan` の実行（検証担当の責務）
+- Terraform 規約・IaC セキュリティ・コスト影響と結びつかない問題の指摘
+- アプリケーションコードのレビュー
+- `terraform plan` の実行
 
 ## 行動姿勢
 

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

@@ -1,5 +1,20 @@
 # AI Antipattern 検出基準
 
+AI が生成しがちな仮定、過剰実装、見かけ上の修正をレビューで検出する。
+
+## 原則
+
+| 原則 | 基準 |
+|------|------|
+| 要求一致 | 実装が実際の要求に対応しているか確認する |
+| 実在性確認 | API、設定、フィールド、呼び出し経路を推測で扱わない |
+| コンテキスト適合 | 既存の命名、構造、エラー処理、ログ、テストに合わせる |
+| 最小差分 | 要求達成に不要な機能、抽象化、設定、互換処理を混ぜない |
+| 契約維持 | UI文言、公開API、戻り値、エラー文言、テスト期待値を要求外で変えない |
+| 直接修正 | 指摘をテストやドキュメントで説明するだけにしない |
+| 到達性確認 | 追加・残存コードが現在の呼び出し経路から使われるか確認する |
+| 検証可能性 | 説明ではなく、コード経路、使用箇所、実行結果で確認する |
+
 ## 仮定の検証
 
 AIはしばしば仮定を行う。それを検証する。
@@ -112,11 +127,13 @@ AIはレビュー指摘を「修正」する代わりに、テストやドキュ
 | 指摘の修正ではなくテストの追加 | 「コメント不要」→ コメントの有無を検証するテストを追加 | REJECT |
 | 指摘の修正ではなくドキュメントの追加 | 「DRY違反」→ 重複が意図的である旨のドキュメントを追加 | REJECT |
 | 指摘と無関係なファイルの変更 | セキュリティ指摘 → 全く別のリファクタリングを実施 | REJECT |
+| 仕様変更の修正ではなく旧仕様の不在確認 | 「旧バッジ表示を廃止して一覧から除外」→ 下位コンポーネントで旧バッジが表示されないことだけを検証 | REJECT |
 
 検証アプローチ:
 1. 修正差分が指摘の対象ファイル・対象行に対する変更を含んでいるか確認
 2. 新規ファイル追加のみで対応している場合、そのファイルが指摘の「修正」ではなく「検証」になっていないか確認
 3. テスト追加が指摘への対応の場合、テストが「修正後の正しい動作」を検証しているか（「指摘内容そのもの」を検証していないか）確認
+4. PR途中の仕様変更では、旧仕様を否定するだけのテストではなく、新仕様の責務を持つ層で正しい振る舞いを検証しているか確認
 
 ## コンテキスト適合性評価
 

package/builtins/ja/facets/policies/coding.md

@@ -319,6 +319,42 @@ const storage = createStorage(config)
 return storage.upload(file, options)
 ```
 
+## 命名
+
+名前は実装機構ではなく、実際の役割・効果を表す。読み手が名前から挙動、責務、副作用を誤読するコードは悪いコード。
+
+| パターン | 例 | 判定 |
+|---------|-----|------|
+| 名前が実際の効果と矛盾 | 毎回副作用を起こすように読めるが、実体はキャッシュ済み値の取得 | REJECT |
+| 副作用や実行頻度が読めない | 初期化、取得、更新のどれが起きるか名前から判断できない | REJECT |
+| 近接する API と区別できない | ラップ元や委譲先と同じ名前で、どちらの責務か読めない | REJECT |
+| 役割・効果で命名 | 実際に提供する値、状態変化、責務が名前から読める | OK |
+
+```typescript
+// REJECT - 名前は毎回副作用を起こすように読めるが、実体はメモ化アクセサ
+let resourcePromise: Promise<Resource> | null = null
+function openResource(): Promise<Resource> {
+  if (!resourcePromise) {
+    resourcePromise = createResource()
+  }
+  return resourcePromise
+}
+
+// OK - 実際の役割である「利用可能なリソースの取得」を表す
+function getResource(): Promise<Resource> {
+  if (!resourcePromise) {
+    resourcePromise = createResource()
+  }
+  return resourcePromise
+}
+```
+
+判断基準:
+1. 名前は実際の役割・効果を表しているか
+2. 名前から想像される副作用、実行頻度、責務と実装が一致しているか
+3. ラップ元、委譲先、近接する API と紛らわしい名前になっていないか
+4. 既存コードの命名慣習と矛盾していないか
+
 ## 構造
 
 ### 分割の基準

package/builtins/ja/facets/policies/review.md

@@ -10,6 +10,13 @@
 | 曖昧さ排除 | 「もう少し整理して」等の曖昧な指摘は禁止。ファイル・行・修正案を具体的に示す |
 | ファクトチェック | 推測ではなく実コードを確認してから指摘する |
 | 実践的修正案 | 理想論ではなく実装可能な対策を提示する |
+| 状態整合性 | 副作用や状態変更は、正常・失敗・中断の各経路で漏れ・重複・不整合がないことを確認する |
+| 契約全入口 | 新しい契約は通常入口だけでなく、派生条件・検証・評価・出力・再注入経路まで同じ基準で確認する |
+| 契約一貫性 | 共通化・抽象化で担う契約は、既存の同種分岐にも同じ基準で適用されていることを確認する |
+| 仕様完全性 | 利用者向け契約を変える場合、実装・テスト・ドキュメントが同じ探索順、上書き規則、特殊記法、失敗条件を説明していることを確認する |
+| 元要件固定 | タスク指示書の必須項目を、実装都合で optional・対象外・別要件に読み替えない |
+| 解消判定 | resolved 判定は修正内容ではなく、元 finding の受入条件と元要件に戻って確認する |
+| 振る舞い保証 | テストやログの有無ではなく、期待する振る舞いが検証されているかを確認する |
 | ボーイスカウト | 変更箇所と、その正しさ・契約・配線に直接関係する箇所の問題をタスクスコープ内で改善させる |
 
 ## スコープ判定
@@ -31,6 +38,7 @@
 以下のいずれかに該当する場合、例外なく REJECT する。
 
 - テストがない新しい振る舞い
+- 境界変更（権限、拒否、外部実行、共有状態、状態遷移）に対して、主要な許可/拒否・成功/失敗・隔離/解放の検証がない
 - バグ修正にリグレッションテストがない
 - `any` 型の使用
 - フォールバック値の乱用（`?? 'unknown'`）
@@ -45,7 +53,11 @@
 - 内部実装のパブリック API エクスポート（インフラ層の関数・内部クラスが公開されている）
 - リファクタリングで置き換えられた旧コード・旧エクスポートの残存
 - 関連フィールドのクロスバリデーション欠如（意味的に結合した設定値の不変条件が未検証）
-- 契約変更後の呼び出し元・生成元・テストデータの更新漏れ
+- 契約変更後の呼び出し元・生成元・利用元・検証元・テストデータ・派生入口の更新漏れ
+- 設定・CLI・ファイル形式などの利用者向け契約変更に対して、ドキュメントや例が優先順位、first-match/merge、inline上書き、scope/特殊参照、失敗条件のいずれかを欠落している
+- 共通ヘルパー、正規化関数、builder、adapter の追加・変更後に、同じ契約を持つ既存分岐が旧実装のまま残っている
+- タスクで要求されたフィールド、属性、出力、設定、識別子を、明示根拠なく optional・未設定・対象外として扱う、または入口や実行モードによって欠落させている
+- 副作用や状態変更の実行経路に、漏れ・重複・順序不整合がある
 - ログ、エラーレスポンス、テスト出力への機密情報露出
 
 DRY違反の修正案は、単に共通化を求めるだけでは不十分とする。以下を満たさない共通化案は不適切であり、別案を検討する。
@@ -61,7 +73,7 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 - エッジケース・境界値のテスト不足
 - テストが実装の詳細に依存
 - 関数/ファイルが複雑すぎる
-- 命名が不明確
+- 命名が実体と乖離している
 - Issue番号・外部制約・除去条件がある TODO/FIXME
 - 理由なしの `@ts-ignore`、`eslint-disable`
 
@@ -69,6 +81,17 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 
 全ての REJECT 基準をクリアし、品質基準を満たしている場合に承認する。「条件付き承認」はしない。問題があれば差し戻す。
 
+## 振る舞い証跡の判定
+
+設定値、ログ、スナップショット、最後の状態だけの確認は補助証跡であり、拒否・許可・隔離・解放などの主要な振る舞いを保証する根拠にはならない。
+
+| 証跡 | 判定 |
+|------|------|
+| 期待する振る舞いが実行結果として観測されている | OK |
+| deterministic なテストで主要な境界条件を検証している | OK |
+| 外部環境依存のE2Eのみで、主要境界の再現可能な検証がない | 警告またはREJECT |
+| 設定値・ログ・スナップショットのみで振る舞いを承認している | REJECT |
+
 ## ファクトチェック
 
 指摘する前に必ず事実を確認する。
@@ -114,12 +137,37 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 
 同じ指摘の堂々巡りを防ぐため、指摘をIDで追跡する。
 
+Finding Contract は individual finding 単位ではなく review workflow 全体に適用される。
+Finding Contract workflow かどうかは、workflow レベルの `finding_contract` 設定が
+宣言されている場合に限って判定する。`findings-ledger.json`、instruction template 内の
+専用 `Finding Contract` セクション、output contract の `Observed Findings` table は、
+すでに Finding Contract が設定された workflow 内での補助証跡であり、それ自体では
+Finding Contract を有効化しない。
+
+Finding Contract 利用時、レビュワーは新規の最終 `finding_id` を採番せず、
+`new` / `persists` / `resolved` / `reopened` の lifecycle 分類も行わない。
+観測した問題は `Observed Findings` table に raw finding として報告する。既存 ID への
+言及は ledger に載っている指摘を参照する場合に限る。ID 採番と lifecycle 対応づけは
+findings-manager とエンジンの責務である。
+
+Finding Contract が設定された workflow で parse 可能な ledger がある場合、tracked findings
+の正本は ledger である。個別レポートと raw finding 詳細は補助証跡として扱う。ledger が
+存在するが不完全な場合は、mapped findings は ledger に従い、unmapped raw findings は
+findings-manager reconciliation 待ちの potential new entries として扱う。Finding Contract
+が設定された workflow で parse 可能な ledger がない場合、レポート履歴は observed raw
+findings の補助証跡としてのみ使う。最終 `finding_id` や lifecycle 状態は割り当てず、
+従来ルールも適用しない。ledger 再生成または findings-manager reconciliation を待つ。
+
+### 従来の Finding ID ルール（Finding Contract を使わない workflow 向け）
+
+workflow レベルの `finding_contract` 設定がない場合は、以下の従来ルールに従う。
+
 - REJECT時に挙げる各問題には `finding_id` を必須で付ける
 - 同じ問題を再指摘する場合は、同じ `finding_id` を再利用する
 - 再指摘時は状態を `persists` とし、未解決である根拠（ファイル/行）を必ず示す
 - 新規指摘は状態 `new` とする
 - 解消済みは状態 `resolved` として一覧化する
-- `finding_id` のない指摘は無効（判定根拠として扱わない）
+- `finding_id` のない指摘は無効（判定根拠として扱わない）。この legacy 基準は Finding Contract workflow には適用しない
 - REJECTは `new` または `persists` の問題が1件以上ある場合のみ許可する
 - 前回指摘を解消済みとする場合、別の構造問題や契約悪化を新たに導入していないか確認する
 
@@ -225,6 +273,7 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 - `order.md`、`plan.md`、実コードを一次情報として参照する
 - 過去ステップの判断（前段レビュー結果、計画上の決定）は補助情報として扱う
 - 情報が競合する場合は、`order.md` / `plan.md` / 実コードを優先する
+- 利用者向け仕様を変えた場合、ドキュメントと設定例も契約の一部として扱い、要件に列挙された挙動が欠落していないか確認する
 
 ### 設計判断の参照
 
@@ -232,13 +281,43 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 - 記録された意図的な判断は、それだけを理由に false positive として退けない。`order.md` / `plan.md` / 実コードと照らして妥当性を評価する
 - 設計判断自体に問題があれば指摘する
 
+### 契約追加・変更の全入口検証
+
+差分で新しい契約（設定値、状態、条件式、ファイル形式、イベント、builder、adapter、状態遷移関数）を追加・変更した場合、その契約が通る入口・出口・再注入経路を列挙して照合する。
+
+- 定義、生成、正規化、検証、評価、永続化、出力、イベント発行の各経路に同じ契約が適用されているか確認する
+- 通常入口だけでなく、派生条件、集約条件、親子ワークフロー、ループ判定、早期終了、例外経路を確認する
+- 保存済みデータや外部由来データを JSON、Markdown、ログ、イベント、次の指示へ再注入する場合、エスケープ・境界・失敗時の扱いを契約に含める
+- 同じ責務を持つ既存の return、throw、catch、early return、分岐、呼び出し元を検索する
+- 既存分岐が新しい契約を満たさない場合は、コードが以前から存在していても変更の関係箇所として扱う
+- 新しい経路だけにテストが偏り、既存の同種分岐や派生入口で契約が検証されていない場合はカバレッジ不足として扱う
+- タスクで要求された契約を optional・対象外・別要件にする場合は、タスク指示書、仕様、明示的なユーザー指示の根拠を必須とする
+- 「タスク要件に明記されていない」ことは、差分で導入した契約不整合を非ブロッキングにする理由にならない
+
+### 副作用と状態遷移の確認
+
+変更が外部呼び出し、設定反映、セッション、キュー、ロック、購読、キャッシュ、一時資源などの副作用や状態変更を伴う場合は、正常系だけで判断しない。
+
+- 入口、正常終了、早期 return、例外、再試行、中断、後片付けの経路を追う
+- 取得・開始・登録・反映したものが、対応する経路で過不足なく扱われることを確認する
+- 同じ副作用が重複して実行されないこと、必要な副作用が失敗経路で抜けないことを確認する
+- 共有状態や後続処理に影響する変更では、途中失敗後の状態が次の実行を壊さないことを確認する
+- これらの確認ができていない場合は、動作確認済みとして扱わない
+
 ### 前回指摘の追跡
 
-- Report Directory 内で、このステップが前回までに出力したレビューレポートとそのタイムスタンプ付き履歴を確認する
-- 無印ファイルを最新結果、直前のタイムスタンプ付きファイル（`{レポート名}.{タイムスタンプ}`）を前回結果として扱う
-- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
-- 前回レポートにある open findings を、今回のレポートへ欠落させない
-- 各 finding の状態判定（`new` / `persists` / `resolved` / `reopened`）は finding_id 管理ルールに従う
+**優先順位:**
+
+1. Finding Contract が設定された workflow で parse 可能な Finding Contract ledger / `findings-ledger.json` が利用できる場合、tracked findings の正本として ledger を使用する。修正対象は ledger 上の open findings（`new`、`persists`、`reopened`）のみとし、resolved / closed findings は修正対象外とする。個別レポートは ledger から辿る補助証跡として扱う。
+2. ledger が存在するが不完全な場合は、mapped findings は ledger に従い、unmapped raw findings は findings-manager reconciliation 待ちの potential new entries として扱う。
+3. Finding Contract が設定された workflow で parse 可能な ledger がない場合、Report Directory の最新レビューは observed raw findings の補助証跡としてのみ使う。最終 `finding_id` や lifecycle 状態は割り当てず、従来ルールも適用しない。ledger 再生成または findings-manager reconciliation を待つ。
+4. `finding_contract` 設定がない workflow では、Report Directory の最新レビューを primary evidence として扱い、従来ルールを適用する:
+   - Report Directory 内で、このステップが前回までに出力したレビューレポートとそのタイムスタンプ付き履歴を確認する
+   - 無印ファイルを最新結果、直前のタイムスタンプ付きファイル（`{レポート名}.{タイムスタンプ}`）を前回結果として扱う
+   - `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
+   - 前回レポートにある open findings を、今回のレポートへ欠落させない
+   - 各 finding の状態判定（`new` / `persists` / `resolved` / `reopened`）は finding_id 管理ルールに従う
+   - `resolved` は修正差分の有無ではなく、元 finding の期待結果と元要件を満たす場合のみ認める
 
 ### 判定の最終手順
 
@@ -248,12 +327,4 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 
 ## 堂々巡りの検出
 
-同じ種類の指摘が繰り返されている場合、修正指示の繰り返しではなくアプローチ自体を見直す。
-
-### 同じ問題が繰り返されたら
-
-1. 同じ種類の問題が繰り返されていないか確認
-2. 繰り返されている場合、細かい修正指示ではなくアプローチ自体の代替案を提示
-3. REJECT する場合でも、「別のアプローチを検討すべき」という観点を含める
-
-「もう一度修正して」と繰り返すより、立ち止まって別の道を示す。
+同じ種類の指摘が繰り返される場合、細かい修正指示の反復ではなくアプローチ自体を見直す。