takt 0.46.0 → 0.48.0

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/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/policies/ai-antipattern.md

@@ -1,5 +1,20 @@
 # AI Antipattern 検出基準
 
+AI が生成しがちな仮定、過剰実装、見かけ上の修正をレビューで検出する。
+
+## 原則
+
+| 原則 | 基準 |
+|------|------|
+| 要求一致 | 実装が実際の要求に対応しているか確認する |
+| 実在性確認 | API、設定、フィールド、呼び出し経路を推測で扱わない |
+| コンテキスト適合 | 既存の命名、構造、エラー処理、ログ、テストに合わせる |
+| 最小差分 | 要求達成に不要な機能、抽象化、設定、互換処理を混ぜない |
+| 契約維持 | UI文言、公開API、戻り値、エラー文言、テスト期待値を要求外で変えない |
+| 直接修正 | 指摘をテストやドキュメントで説明するだけにしない |
+| 到達性確認 | 追加・残存コードが現在の呼び出し経路から使われるか確認する |
+| 検証可能性 | 説明ではなく、コード経路、使用箇所、実行結果で確認する |
+
 ## 仮定の検証
 
 AIはしばしば仮定を行う。それを検証する。

package/builtins/ja/facets/policies/existing-system-respect.md

@@ -1,19 +1,19 @@
 # 既存システム尊重ポリシー
 
-リリース済みまたは運用中の既存システムでは、要求達成に必要な最小差分だけを行い、既存契約を不用意に変えない。
+リリース済みまたは運用中の既存システムでは、要求と因果関係のある変更を行い、因果関係のない既存契約を変えない。
 
 ## 原則
 
 | 原則 | 基準 |
 |------|------|
 | 既存契約優先 | 既存利用者、テスト、運用が依存する契約を保持する |
-| 最小差分 | 要求達成に必要な変更だけを残す |
+| 因果差分 | 要求と因果関係のある変更を行い、因果関係のない変更を排除する |
 | 近接性より必要性 | 変更箇所に近いことを変更理由にしない |
-| 既存構造尊重 | ファイル配置、型名、公開API、責務境界を明示要求なしに変えない |
+| 既存構造尊重 | ファイル配置、型名、公開API、責務境界を要求と因果関係なく変えない |
 | コメント保全 | 意図、制約、算出根拠を示すコメントを削除しない |
 | テストの契約性 | 既存テストが検証する挙動を軽微扱いしない |
-| 改善の分離 | 作法改善や整理は要求と直接関係する場合に限定する |
-| 保守制約優先 | 一般的な品質改善より、既存挙動と既存構造の保持を優先する |
+| 改善の因果判定 | 作法改善・リファクタは要求と因果関係がある場合に実施する。因果関係のない改善は混ぜない |
+| 無関係保護優先 | 要求と因果関係のない既存挙動・構造の保持を優先する |
 
 ## 変更境界
 
@@ -22,21 +22,22 @@
 | 要求を満たすために不可欠な変更 | OK |
 | 不可欠な変更を接続するための呼び出し元更新 | OK |
 | 不可欠な変更の副作用を止めるための局所修正 | OK |
+| 要求と因果関係のある構造変更・リファクタ | OK |
 | 変更ファイル内という理由だけの整理 | REJECT |
-| 明示要求のないファイル移動、型名変更、公開API変更 | REJECT |
-| フレームワーク作法の改善を混ぜる | REJECT |
-| 別PRで扱える改善を同時に入れる | REJECT |
+| 要求と因果関係のないファイル移動、型名変更、公開API変更 | REJECT |
+| フレームワーク作法の改善を混ぜる（要求と因果関係がない場合） | REJECT |
+| 要求と因果関係のない改善を同時に入れる | REJECT |
 
 ## 他ポリシーとの優先順位
 
-既存システムの保守では、coding、frontend、design-fidelity、testing などの一般的な品質基準を、要求達成に必要な範囲へ制限して適用する。
+既存システムの保守では、coding、frontend、design-fidelity、testing などの一般的な品質基準を、要求と因果関係のある範囲で適用する。
 
 | 衝突 | 判定 |
 |------|------|
-| 一般品質基準は改善を推奨するが、要求には不要 | 変更しない |
-| 既存構造は理想的でないが、今回の要求を満たせる | 既存構造を維持する |
+| 一般品質基準は改善を推奨するが、要求と因果関係がない | 変更しない |
+| 既存構造は理想的でないが、要求と因果関係がない | 既存構造を維持する |
 | 品質基準を満たすには既存契約変更が必要 | ユーザーの明示要求または計画上の根拠が必要 |
-| 不具合修正に必要な最小の構造変更 | 理由と影響範囲を明記して実施する |
+| 要求と因果関係のある構造変更 | 理由と影響範囲を明記して実施する |
 
 ## 観測可能契約
 
@@ -44,11 +45,11 @@ UI、アクセシビリティ、テスト、ログ、API、型、ファイル配
 
 | 契約 | 変更条件 |
 |------|----------|
-| UI文言、アクセシビリティ名、role/state | 要求に直接含まれる場合のみ変更する |
-| hook の戻り値、Props 型名、公開関数名 | 呼び出し元更新が要求達成に不可欠な場合のみ変更する |
+| UI文言、アクセシビリティ名、role/state | 要求と因果関係がある場合のみ変更する |
+| hook の戻り値、Props 型名、公開関数名 | 要求と因果関係のある呼び出し元更新に不可欠な場合のみ変更する |
 | テスト期待値 | 仕様変更が要求されている場合のみ変更する |
 | コメント | 誤りを直す場合、またはコードで完全に不要になった場合のみ変更する |
-| ファイル配置 | 既存構造では要求を満たせない場合のみ変更する |
+| ファイル配置 | 要求と因果関係がある場合のみ変更する |
 
 ## テスト変更
 
@@ -70,4 +71,4 @@ UI、アクセシビリティ、テスト、ログ、API、型、ファイル配
 |------|------|
 | 必須変更 | これがないと要求を満たせない |
 | 関連変更 | 必須変更を接続、検証、整合させるために必要 |
-| 不要変更 | 読みやすさ、作法、ついで整理、将来拡張だけが理由 |
+| 不要変更 | 要求との因果関係がなく、読みやすさ、作法、ついで整理、将来拡張だけが理由 |

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

@@ -11,6 +11,11 @@
 | ファクトチェック | 推測ではなく実コードを確認してから指摘する |
 | 実践的修正案 | 理想論ではなく実装可能な対策を提示する |
 | 状態整合性 | 副作用や状態変更は、正常・失敗・中断の各経路で漏れ・重複・不整合がないことを確認する |
+| 契約全入口 | 新しい契約は通常入口だけでなく、派生条件・検証・評価・出力・再注入経路まで同じ基準で確認する |
+| 契約一貫性 | 共通化・抽象化で担う契約は、既存の同種分岐にも同じ基準で適用されていることを確認する |
+| 仕様完全性 | 利用者向け契約を変える場合、実装・テスト・ドキュメントが同じ探索順、上書き規則、特殊記法、失敗条件を説明していることを確認する |
+| 元要件固定 | タスク指示書の必須項目を、実装都合で optional・対象外・別要件に読み替えない |
+| 解消判定 | resolved 判定は修正内容ではなく、元 finding の受入条件と元要件に戻って確認する |
 | 振る舞い保証 | テストやログの有無ではなく、期待する振る舞いが検証されているかを確認する |
 | ボーイスカウト | 変更箇所と、その正しさ・契約・配線に直接関係する箇所の問題をタスクスコープ内で改善させる |
 
@@ -48,7 +53,10 @@
 - 内部実装のパブリック API エクスポート（インフラ層の関数・内部クラスが公開されている）
 - リファクタリングで置き換えられた旧コード・旧エクスポートの残存
 - 関連フィールドのクロスバリデーション欠如（意味的に結合した設定値の不変条件が未検証）
-- 契約変更後の呼び出し元・生成元・テストデータの更新漏れ
+- 契約変更後の呼び出し元・生成元・利用元・検証元・テストデータ・派生入口の更新漏れ
+- 設定・CLI・ファイル形式などの利用者向け契約変更に対して、ドキュメントや例が優先順位、first-match/merge、inline上書き、scope/特殊参照、失敗条件のいずれかを欠落している
+- 共通ヘルパー、正規化関数、builder、adapter の追加・変更後に、同じ契約を持つ既存分岐が旧実装のまま残っている
+- タスクで要求されたフィールド、属性、出力、設定、識別子を、明示根拠なく optional・未設定・対象外として扱う、または入口や実行モードによって欠落させている
 - 副作用や状態変更の実行経路に、漏れ・重複・順序不整合がある
 - ログ、エラーレスポンス、テスト出力への機密情報露出
 
@@ -129,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件以上ある場合のみ許可する
 - 前回指摘を解消済みとする場合、別の構造問題や契約悪化を新たに導入していないか確認する
 
@@ -240,6 +273,7 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 - `order.md`、`plan.md`、実コードを一次情報として参照する
 - 過去ステップの判断（前段レビュー結果、計画上の決定）は補助情報として扱う
 - 情報が競合する場合は、`order.md` / `plan.md` / 実コードを優先する
+- 利用者向け仕様を変えた場合、ドキュメントと設定例も契約の一部として扱い、要件に列挙された挙動が欠落していないか確認する
 
 ### 設計判断の参照
 
@@ -247,6 +281,19 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 - 記録された意図的な判断は、それだけを理由に false positive として退けない。`order.md` / `plan.md` / 実コードと照らして妥当性を評価する
 - 設計判断自体に問題があれば指摘する
 
+### 契約追加・変更の全入口検証
+
+差分で新しい契約（設定値、状態、条件式、ファイル形式、イベント、builder、adapter、状態遷移関数）を追加・変更した場合、その契約が通る入口・出口・再注入経路を列挙して照合する。
+
+- 定義、生成、正規化、検証、評価、永続化、出力、イベント発行の各経路に同じ契約が適用されているか確認する
+- 通常入口だけでなく、派生条件、集約条件、親子ワークフロー、ループ判定、早期終了、例外経路を確認する
+- 保存済みデータや外部由来データを JSON、Markdown、ログ、イベント、次の指示へ再注入する場合、エスケープ・境界・失敗時の扱いを契約に含める
+- 同じ責務を持つ既存の return、throw、catch、early return、分岐、呼び出し元を検索する
+- 既存分岐が新しい契約を満たさない場合は、コードが以前から存在していても変更の関係箇所として扱う
+- 新しい経路だけにテストが偏り、既存の同種分岐や派生入口で契約が検証されていない場合はカバレッジ不足として扱う
+- タスクで要求された契約を optional・対象外・別要件にする場合は、タスク指示書、仕様、明示的なユーザー指示の根拠を必須とする
+- 「タスク要件に明記されていない」ことは、差分で導入した契約不整合を非ブロッキングにする理由にならない
+
 ### 副作用と状態遷移の確認
 
 変更が外部呼び出し、設定反映、セッション、キュー、ロック、購読、キャッシュ、一時資源などの副作用や状態変更を伴う場合は、正常系だけで判断しない。
@@ -259,11 +306,18 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 
 ### 前回指摘の追跡
 
-- 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 の期待結果と元要件を満たす場合のみ認める
 
 ### 判定の最終手順
 
@@ -273,12 +327,4 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 
 ## 堂々巡りの検出
 
-同じ種類の指摘が繰り返されている場合、修正指示の繰り返しではなくアプローチ自体を見直す。
-
-### 同じ問題が繰り返されたら
-
-1. 同じ種類の問題が繰り返されていないか確認
-2. 繰り返されている場合、細かい修正指示ではなくアプローチ自体の代替案を提示
-3. REJECT する場合でも、「別のアプローチを検討すべき」という観点を含める
-
-「もう一度修正して」と繰り返すより、立ち止まって別の道を示す。
+同じ種類の指摘が繰り返される場合、細かい修正指示の反復ではなくアプローチ自体を見直す。

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

@@ -12,6 +12,7 @@
 | 独立性 | 他のテストや実行順序に依存しない |
 | 再現性 | 時間やランダム性に依存せず、毎回同じ結果 |
 | 非実行資産を固定しない | 実行時の振る舞いを定義しない本文や章構成を CI の失敗条件にしない |
+| 否定契約を観測単位で検証 | 禁止・拒否・非継承・非対応は、完全一致文字列の不在だけで合格にしない |
 
 ## カバレッジ基準
 
@@ -21,6 +22,8 @@
 | バグ修正 | リグレッションテスト必須。テストがなければ REJECT |
 | 振る舞いの変更 | テストの更新必須。更新がなければ REJECT |
 | 副作用・状態遷移の変更 | 正常系と代表的な失敗経路の検証必須。失敗経路が未検証なら REJECT |
+| 共通化・抽象化による契約変更 | 新しい共通経路だけでなく、既存の同種分岐で契約が保たれることの検証必須 |
+| パーサー・設定境界の変更 | 構文上は有効だが期待shapeと異なる入力、欠落値、個人設定からの汚染を検証必須 |
 | ビルド（型チェック） | ビルド成功必須。失敗は REJECT |
 | エッジケース・境界値 | テスト推奨（Warning） |
 
@@ -100,6 +103,55 @@ test('ユーザーが存在しない場合、NotFoundエラーを返す', async
 | モックで確認した範囲と未確認の実連携範囲を区別していない | 警告。主要要件なら REJECT |
 | 正常系、代表的な失敗経路、境界的な状態遷移をそれぞれ検証している | OK |
 
+## 契約変更と既存分岐のテスト
+
+共通ヘルパー、正規化関数、builder、adapter などで契約を統一する変更では、変更で追加した経路だけを検証しても十分ではない。既存の同種分岐が同じ契約を満たすことを検証する。
+
+| 基準 | 判定 |
+|------|------|
+| 新しい共通経路のテストだけで、既存の同種分岐に同じ戻り値・副作用・エラー契約が適用されることを検証していない | REJECT |
+| 既存分岐を「現行維持」としたが、差分で追加した契約と矛盾しないことを確認していない | REJECT |
+| 変更対象関数の return / throw / catch / early return を列挙せず、代表的な失敗経路を取りこぼしている | REJECT |
+| 同じ責務の既存分岐にも、戻り値・副作用・イベント・エラー分類の契約を検証するテストがある | OK |
+
+## 契約テストの十分性
+
+新しい設定値、実行時に選択される能力・バックエンド・オプション、権限、出力契約を追加・変更した場合、テストは値の存在ではなく、契約を変える分岐条件を踏んでいることを確認する。
+
+| 基準 | 判定 |
+|------|------|
+| 新しいオプションの正常系だけを確認している | 警告 |
+| 未設定、設定、不正値、継承、非継承、override、非対応対象のうち、要件に関係する分岐を検証していない | REJECT |
+| 利用者向けの表示・検証用入口で、主実行経路と同じ契約になることを確認していない | REJECT |
+| 値の表示だけを確認し、実行時に使われる解決入力と一致するか検証していない | REJECT |
+| 漏れ検証を完全一致文字列だけで行い、順序、大小文字、空白、部分漏れの違いを見逃す | REJECT |
+| 空文字列、空白だけの文字列、空配列、大小文字違いなど、設定境界で正規化対象になり得る値を検証していない | 警告。契約の主要分岐なら REJECT |
+| 入口から末端呼び出しまで、正常系、拒否系、非継承系を確認している | OK |
+
+## 否定・非継承・拒否のテスト
+
+禁止、拒否、非継承、非対応、隔離を検証するテストは、出力全体に特定の文字列が存在しないことだけを根拠にしない。
+観測対象の行、レコード、フィールド、呼び出し引数などを抽出し、禁止値が順序、大小文字、空白、区切り、部分一致の形でも漏れていないことを検証する。
+
+| 基準 | 判定 |
+|------|------|
+| 完全一致文字列の不在だけで、禁止値や非継承値が使われていないと判断している | REJECT |
+| 許可値の存在確認だけで、拒否値・禁止値・非継承値が末端に渡らないことを検証していない | REJECT |
+| 出力行、イベント、レコード、フィールド、呼び出し引数などの観測単位を抽出し、禁止値ごとに検証している | OK |
+| 許可側と拒否側、継承側と非継承側を対にして検証している | OK |
+| 新しい E2E の timeout、cleanup、強制終了の扱いが既存の同種テスト規約と一致していない | 警告。プロセスリークやフレークの原因になる場合は REJECT |
+
+## パーサー・設定境界のテスト
+
+外部ファイル、設定、YAML/JSON、CLI入力などを読む境界では、型定義どおりの入力だけを検証しても十分ではない。
+
+| 基準 | 判定 |
+|------|------|
+| 配列前提のフィールドに object/null/欠落が入った場合の挙動を検証していない | REJECT |
+| ファイル/ディレクトリ判定で、存在する通常ファイル・壊れたリンク・権限エラーを検証していない | REJECT |
+| ユーザーやマシンの既存設定を引き継ぐ可能性があるテストで、空の設定ディレクトリや一時HOMEに隔離していない | REJECT |
+| 構文上有効だが契約外のshapeを、無視・正規化・明示エラーのいずれかに固定している | OK |
+
 ## テストデータとフィクスチャ
 
 テストデータは、テストごとに必要最小限の事実を明示して生成する。共有フィクスチャの破壊的変更や、実契約と異なるモックはテストの信頼性を下げる。

package/builtins/ja/workflow-categories.yaml

@@ -24,6 +24,7 @@ workflow_categories:
     workflows:
       - backend
       - backend-mini
+      - backend-maintenance
       - backend-cqrs
       - backend-cqrs-mini
   🔧 デュアル:
@@ -61,6 +62,7 @@ workflow_categories:
   🎵 TAKT開発:
     workflows:
       - takt-default
+      - takt-default-with-fc
       - takt-default-refresh-all
       - takt-default-refresh-fast
       - auto-improvement-loop

package/builtins/ja/workflows/audit-architecture-backend.yaml

@@ -23,6 +23,8 @@ loop_monitors:
 
 steps:
   - name: plan
+    tags:
+      - plan
     persona: planner
     knowledge:
       - backend
@@ -40,6 +42,8 @@ steps:
         next: ABORT
 
   - name: audit
+    tags:
+      - review
     persona: architecture-reviewer
     policy: review
     knowledge:
@@ -60,6 +64,8 @@ steps:
         next: supervise
 
   - name: supervise
+    tags:
+      - review
     persona: supervisor
     policy: review
     knowledge:
@@ -75,6 +81,8 @@ steps:
         next: review
 
   - name: review
+    tags:
+      - review
     persona: architecture-reviewer
     policy: review
     knowledge:

package/builtins/ja/workflows/audit-architecture-dual.yaml

@@ -23,6 +23,8 @@ loop_monitors:
 
 steps:
   - name: plan
+    tags:
+      - plan
     persona: planner
     knowledge:
       - frontend
@@ -41,6 +43,8 @@ steps:
         next: ABORT
 
   - name: audit
+    tags:
+      - review
     persona: architecture-reviewer
     policy: review
     knowledge:
@@ -62,6 +66,8 @@ steps:
         next: supervise
 
   - name: supervise
+    tags:
+      - review
     persona: supervisor
     policy: review
     knowledge:
@@ -78,6 +84,8 @@ steps:
         next: review
 
   - name: review
+    tags:
+      - review
     persona: architecture-reviewer
     policy: review
     knowledge:

package/builtins/ja/workflows/audit-architecture-frontend.yaml

@@ -23,6 +23,8 @@ loop_monitors:
 
 steps:
   - name: plan
+    tags:
+      - plan
     persona: planner
     knowledge:
       - frontend
@@ -41,6 +43,8 @@ steps:
         next: ABORT
 
   - name: audit
+    tags:
+      - review
     persona: frontend-reviewer
     policy: review
     knowledge:
@@ -62,6 +66,8 @@ steps:
         next: supervise
 
   - name: supervise
+    tags:
+      - review
     persona: supervisor
     policy: review
     knowledge:
@@ -78,6 +84,8 @@ steps:
         next: review
 
   - name: review
+    tags:
+      - review
     persona: frontend-reviewer
     policy: review
     knowledge:

package/builtins/ja/workflows/audit-architecture.yaml

@@ -23,6 +23,8 @@ loop_monitors:
 
 steps:
   - name: plan
+    tags:
+      - plan
     persona: planner
     knowledge: architecture
     instruction: architecture-audit-plan
@@ -38,6 +40,8 @@ steps:
         next: ABORT
 
   - name: audit
+    tags:
+      - review
     persona: architecture-reviewer
     policy: review
     knowledge: architecture
@@ -56,6 +60,8 @@ steps:
         next: supervise
 
   - name: supervise
+    tags:
+      - review
     persona: supervisor
     policy: review
     knowledge: architecture
@@ -69,6 +75,8 @@ steps:
         next: review
 
   - name: review
+    tags:
+      - review
     persona: architecture-reviewer
     policy: review
     knowledge: architecture