takt 0.47.0 → 0.49.0

package/builtins/exec/presets/research.yaml

@@ -0,0 +1,45 @@
+name: research
+description: Research and implementation team
+session: {}
+replan:
+  instruction: exec-replan
+  knowledge:
+    - research
+  policy: []
+workers:
+  - name: worker-1
+    instruction: exec-worker
+    knowledge:
+      - research
+      - architecture
+    policy:
+      - coding
+      - testing
+  - name: worker-2
+    instruction: exec-worker
+    knowledge:
+      - research
+      - unit-testing
+    policy:
+      - coding
+      - testing
+  - name: worker-3
+    instruction: exec-worker
+    knowledge:
+      - research
+      - architecture
+    policy:
+      - coding
+      - testing
+reviews:
+  - name: review-1
+    instruction: exec-review
+    knowledge:
+      - research
+      - architecture
+    policy:
+      - review
+loop:
+  threshold: 3
+  large_threshold: 2
+  max_steps: 20

package/builtins/ja/facets/instructions/exec-loop-monitor.md

@@ -0,0 +1,15 @@
+# Exec ループモニター指示
+
+繰り返されている exec ループが生産的か判定する。
+
+このループは {cycle_count} 回繰り返されています。
+
+直近のレポートを時系列で確認し、次のいずれかの条件を選ぶ。
+
+小ループ（execute ↔ review）:
+- `Healthy (progress being made)` — 指摘が減っている、または意味のある進捗がある。
+- `Unproductive (same rework repeating)` — 同じ修正が改善なく繰り返されている。
+
+大ループ（replan → execute → review）:
+- `Healthy (progress being made)` — 指摘が減っている、または意味のある進捗がある。
+- `Unproductive (no convergence)` — Worker が blocked を続ける、または収束が見えない。

package/builtins/ja/facets/instructions/exec-replan.md

@@ -0,0 +1,5 @@
+# Exec Replan 指示
+
+review が needs_replan を求めた場合に、ユーザーと再計画を相談する。
+
+review レポートの問題点を要約し、必要最小限の確認を行い、合意できたら改訂計画を作成する。

package/builtins/ja/facets/instructions/exec-review.md

@@ -0,0 +1,10 @@
+# Exec Review 指示
+
+Worker の結果を独立セッションでレビューする。
+
+タスク要件、Worker レポート、実際のコード変更を確認する。次のいずれかのステータスを返す:
+- approved: タスクは完了している。
+- needs_fix: 軽微な実装修正が必要。
+- needs_replan: ユーザーと方針を再計画する必要がある。
+
+根拠と次の具体的な手順を簡潔に含める。

package/builtins/ja/facets/instructions/exec-worker.md

@@ -0,0 +1,5 @@
+# Exec Worker 指示
+
+依頼されたタスクを実装する。
+
+タスク指示と Report Directory 内のレポートを主要な文脈として扱う。差し戻しの場合は review の指摘を最優先で修正する。担当範囲内に変更を限定し、必要な検証を実行し、変更ファイルと検証結果を報告する。

package/builtins/ja/facets/instructions/fix-maintenance.md

@@ -1,4 +1,4 @@
-Report Directory内のレビューレポートを確認し、指摘事項を既存契約を保つ最小差分で修正してください。
+Report Directory内のレビューレポートを確認し、指摘事項を既存契約を保ちつつ、要求と因果関係のある範囲で修正してください。
 
 **修正の原則:**
 - 指摘の「修正案」が示されている場合はそれに沿った対応を優先し、独自の迂回策を取らない

package/builtins/ja/facets/instructions/implement-maintenance.md

@@ -1,4 +1,4 @@
-計画に従い、既存契約を保った最小差分で実装してください。
+計画に従い、既存契約を保ちつつ、要求と因果関係のある範囲で実装してください。
 Workflow Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
 Report Directory内のレポートを一次情報として参照してください。不足情報の補完が必要な場合に限り、Previous Responseや会話履歴を補助的に参照して構いません（Previous Responseは提供されない場合があります）。情報が競合する場合は、Report Directory内のレポートと実際のファイル内容を優先してください。
 
@@ -14,7 +14,7 @@ Report Directory内のレポートを一次情報として参照してくださ
 - 実装前に差分予定を「必須変更」「関連変更」「不要変更」に分類する
 - 必須変更と関連変更だけを実装する
 - 変更ファイル内という理由だけで、作法改善、改名、ファイル移動、hook戻り値変更、コメント削除、テスト期待値変更を行わない
-- 既存構造で要求を満たせる場合は、より一般的な作法へ寄せるためだけの構造変更をしない
+- 要求と因果関係のない構造変更をしない
 - 仕様変更で廃止された旧設計について、旧仕様の不在確認だけのコード・テストを残さない
 - 実装後に全差分を確認し、不要変更を戻す
 

package/builtins/ja/facets/instructions/plan-maintenance.md

@@ -1,4 +1,4 @@
-既存フロントエンド機能の保守変更としてタスクを分析し、設計を含めた最小差分の実装方針を立ててください。
+既存機能の保守変更としてタスクを分析し、設計を含めた因果差分の実装方針を立ててください。
 
 **注意:** Previous Responseがある場合は差し戻しのため、その内容と現在のファイル内容を照合して計画を見直してください（replan）。
 
@@ -29,7 +29,7 @@
    - 変更ファイル内、近い責務、一般作法という理由だけでは関連変更にしない
    - 不要変更は Coder に実装させない
 6. ファイル構成・設計パターンを決定する（必要な場合）
-   - 既存構造で要求を満たせる場合は、理想的でなくても既存構造を優先する
+   - 要求と因果関係のない範囲では、理想的でなくても既存構造を優先する
 7. 実装アプローチを決める
    - 実装アプローチがナレッジ・ポリシーの制約に違反しないか照合する
    - 利用者向け機能の追加や変更がある場合、利用者がその機能へ到達する条件・入口・起動経路を固定する
@@ -48,4 +48,4 @@
 ## 既存契約
 - {守るべき既存契約}
 ## 実装方針
-- {最小差分の方針}
+- {因果差分の方針}

package/builtins/ja/facets/instructions/review-coding.md

@@ -8,7 +8,9 @@
 5. 共通ヘルパー、正規化関数、builder、adapter の追加・変更がある場合、既存の同種分岐にも同じ契約が適用されているか確認する
 6. 型、スキーマ、validator、resolver のいずれかが変わった場合、対応する契約も同じ変更で整合しているか確認する
 7. 複数レイヤーで解決・合成される値は、単体の正規化処理だけでなく、実際の入口から検証処理までの経路を追う
-8. 副作用や状態変更を伴う差分は、入口・正常終了・早期終了・例外・後片付けの経路を追う
-9. 指摘は現在の差分に起因し、ユーザーが修正すべきものだけにする
-10. 各指摘には場所、影響、修正方針を含める
-11. 根拠のない推測、好みだけの変更、今回の差分と無関係な既存問題は指摘しない
+8. 実行とは別に同じ値を表示・検証・説明する入口がある場合、主実行経路と同じ正規化済み入力・override 順・resolver で解決されているか比較する
+9. テストがある場合、値の存在だけでなく、未設定・設定・不正値・override・継承・非継承・非対応対象など元要件の分岐条件を踏んでいるか確認する
+10. 副作用や状態変更を伴う差分は、入口・正常終了・早期終了・例外・後片付けの経路を追う
+11. 指摘は現在の差分に起因し、ユーザーが修正すべきものだけにする
+12. 各指摘には場所、影響、修正方針を含める
+13. 根拠のない推測、好みだけの変更、今回の差分と無関係な既存問題は指摘しない

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

@@ -11,4 +11,9 @@
 2. 外部契約があるのに入力位置（root body / query / path）の検証が欠けている場合、カバレッジ不足として扱う
 3. 副作用や状態遷移を伴う変更では、正常系だけでなく代表的な失敗経路のテスト有無を確認する
 4. 共通化・抽象化で契約を統一した変更では、新しい共通経路だけでなく既存の同種分岐にも契約テストがあるか確認する
-5. モックで代替した検証は、実連携まで確認したものとして扱わない
+5. 設定値、実行時に選択される能力・バックエンド・オプション、権限の変更では、値の存在ではなく、未設定・設定・override・継承・非継承など元要件の分岐条件を踏むテストか確認する
+6. 実行とは別に同じ値を表示・検証・説明する入口がある変更では、表示値だけでなく実行時の解決入力と一致することを検証しているか確認する
+7. モックで代替した検証は、実連携まで確認したものとして扱わない
+8. 禁止・拒否・非継承・非対応・隔離の検証が、完全一致文字列の不在だけでなく、観測単位を抽出して禁止値ごとに確認しているか確認する
+9. 新しい設定境界では、空文字列、空白だけの文字列、空配列、大小文字違いなどの正規化対象を必要に応じて確認する
+10. E2E の timeout、cleanup、強制終了の扱いが既存の同種テスト規約と一致しているか確認する

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

@@ -218,6 +218,8 @@ fun confirm(confirmedBy: String): OrderConfirmedEvent {
 | 読み取り用のクラス名やメソッド名なのに副作用を持つ | REJECT |
 | 単純な参照APIが問い合わせ層を呼び、レスポンスDTOに変換するだけ | OK |
 | 単純な状態変更APIが構造検証と認可境界の解決後にコマンドを1つ送るだけ | OK |
+| Controller向けの読み取り調整役が認可境界、複数Read Model、ページング等を扱う | ApplicationService または ReadService として表現 |
+| QueryHandler と同じ領域に QueryService という名前の送信側・調整側コンポーネントを置く | 警告。クエリ受信側と混同しやすい |
 | 複数のRead Model参照、外部連携、複数コマンド、結果待機をControllerに置く | REJECT。UseCase層に分離 |
 | UseCaseが別サービスへの薄い委譲だけでドメイン上の判断や調整を持たない | 削除を検討 |
 

package/builtins/ja/facets/knowledge/cqrs-es.md

@@ -471,6 +471,18 @@ Query側はイベント駆動のPubSubモデルで動作する。Projection が
 | Command と Query を同じサービスに混在させる | REJECT。責務と命名を分離 |
 | Query側で存在確認やスコープ確認を行い、呼び出し元がコマンドを送る | OK |
 
+### QueryHandler と ApplicationService の命名
+
+CQRSではクエリを受けるコンポーネントを QueryHandler と呼び、クエリを送る入口は QueryGateway / QueryBus として扱う。Controller から読み取りユースケースを呼ぶ facade は、QueryHandler と混同しないよう ApplicationService または ReadService と名付ける。
+
+| 基準 | 判定 |
+|------|------|
+| Query を受けて Read Model を参照し、Query結果の型を返す | QueryHandler |
+| Controller から複数Query、認可境界、ページング、DTO組み立てを調整する | ApplicationService または ReadService |
+| Query送信や読み取り調整だけのクラスを QueryService と呼ぶ | 警告。QueryHandler と混同しやすい |
+| QueryHandler がHTTPリクエスト/レスポンスやController都合のエラー変換を知る | REJECT |
+| 追加判断のない単純な読み取り wrapper を作る | 削除を検討。Controller から QueryGateway 直でもよい |
+
 レイヤー間の型:
 - `application/query/` - Query結果の型（例: `OrderDetail`）
 - `adapter/protocol/` - RESTレスポンスの型（例: `OrderDetailResponse`）

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

@@ -28,6 +28,18 @@ E2Eテストはユーザーから見える振る舞いを観測する。設定
 | 設定や内部状態だけを確認してユーザー-visible な結果を見ていない | REJECT |
 | 実外部環境に依存する確認しかなく、主要境界の deterministic test がない | 警告またはREJECT |
 
+## 否定契約の観測
+
+E2E で権限、実行時に選択される能力・バックエンド・オプション、設定、拒否、隔離を確認する場合、出力全体への文字列否定は証拠として弱い。
+対象の行、イベント、レコード、フィールド、呼び出し引数などを取り出し、禁止値ごとに検査することで、順序、大小文字、空白、区切り、部分漏れによる見逃しを防ぐ。
+
+| 基準 | 判定 |
+|------|------|
+| 「特定の一文が出ていない」だけで拒否・非継承・隔離を検証した扱いにする | REJECT |
+| 許可された値の表示だけを確認し、禁止値が末端処理へ渡っていないことを見ていない | REJECT |
+| 観測単位を抽出して、禁止値・拒否値・非継承値が含まれないことを値単位で確認する | OK |
+| 同じシナリオで許可側と拒否側、継承側と非継承側を比較できる | OK |
+
 ## UXルートの洗い出し
 
 E2Eテストの網羅性はユーザー操作ルートの洗い出しに依存する。ドキュメントではなくコードから起点を特定する。
@@ -77,6 +89,7 @@ E2Eテストは非決定的な要因で失敗しやすい。
 | プロセスリーク | タイムアウトと強制終了を設定する |
 | 環境依存 | テスト実行に必要な前提条件を明示的にセットアップする |
 | 実行順序依存 | 各テストが独立して実行できるよう、状態を初期化する |
+| 既存規約から外れた timeout/cleanup | 同種 E2E の既存規約に合わせる |
 
 ```typescript
 // NG - 固定 sleep でタイミングを合わせる

package/builtins/ja/facets/knowledge/existing-system.md

@@ -40,9 +40,9 @@
 
 | 状況 | 判断 |
 |------|------|
-| コンポーネント分割した方がきれいだが、今回の修正に不要 | 変更しない |
+| コンポーネント分割した方がきれいだが、要求と因果関係がない | 変更しない |
 | Props 型名や配置を一般作法へ寄せたいだけ | 変更しない |
-| 既存構造のままだと要求を満たせない | 最小範囲で変更する |
+| 既存構造のままだと要求を満たせない | 因果関係のある範囲で変更する |
 | 既存構造が不具合原因そのもの | 理由と影響範囲を明記して変更する |
 
 ## コメントとテストの意味

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

@@ -77,6 +77,33 @@ ProviderAgent.call(prompt, options) → AgentResponse
 4. config.yaml（プロバイダー一致時）
 5. プロバイダーデフォルト
 
+## 補助入口の契約
+
+TAKT では workflow 実行経路だけでなく、preview、doctor、workflow summary、validation、report も利用者に見える契約入口である。設定値、provider、model、tool、権限、出力契約を表示・検証する補助入口は、runtime と同じ正規化済み入力、resolver、override 順を使う。
+
+| 基準 | 判定 |
+|------|------|
+| runtime と preview が別々の入力で provider、model、tool、権限を解決している | REJECT |
+| preview に値が表示されるだけで、runtime と同じ override 条件を検証していない | REJECT |
+| doctor や validation が正常とする設定が runtime では別条件により失敗する | 警告 |
+| runtime と補助入口が同じ正規化済み入力または同じ resolver を共有している | OK |
+
+## 実行資産の消費境界
+
+TAKT の実行資産は、配置場所や名前だけではなく、それを消費する入口で意味が決まる。同じ文字列でも、資産参照、セッション識別子、表示名、直接渡される本文は別契約として扱う。
+
+| 基準 | 判定 |
+|------|------|
+| 資産参照を解決する入口と、識別子だけを使う入口を同一視している | REJECT |
+| 同名の facet を追加しただけで、直接本文を渡す入口にも反映されると扱っている | REJECT |
+| workflow 由来の実行資産と機能固有の実行資産が同じ責務名で混在している | 警告 |
+| 入口ごとに、どの resolver / loader がどの資産種別を消費するかを確認して配置している | OK |
+| 共有すべき本文を、既存の実行資産 loader から読む形に集約している | OK |
+
+### 参照名と識別名
+
+`persona`、`session_key`、`name` のような文字列は、参照名か識別名かで意味が異なる。参照名なら対応する resolver が資産を読み込む。識別名ならセッション、ログ、状態、表示のキーであり、同名ファイルの存在だけでは内容は使われない。新しい資産を追加した場合は、その資産を読む loader と呼び出し元まで追う。
+
 ## ファセット組み立て
 
 faceted-prompting モジュールは TAKT 本体に依存しない独立モジュール。

package/builtins/ja/facets/output-contracts/exec-review-result.md

@@ -0,0 +1,13 @@
+# Exec Review Result
+
+## Status
+
+approved | needs_fix | needs_replan
+
+## Evidence
+
+レビューの根拠を簡潔に書く。
+
+## Required Next Step
+
+必要な次の行動を具体的に書く。

package/builtins/ja/facets/personas/exec-assistant.md

@@ -0,0 +1,3 @@
+# アシスタント ペルソナ
+
+あなたは TAKT アシスタントです。簡潔で、的確で、行動指向を保ちます。

package/builtins/ja/facets/personas/exec-worker.md

@@ -0,0 +1,3 @@
+# ワーカー ペルソナ
+
+あなたは TAKT ワーカーです。集中し、正確で、自己完結的に行動します。

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

@@ -1,19 +1,20 @@
 # 既存システム尊重ポリシー
 
-リリース済みまたは運用中の既存システムでは、要求達成に必要な最小差分だけを行い、既存契約を不用意に変えない。
+リリース済みまたは運用中の既存システムでは、要求と因果関係のある変更を行い、因果関係のない既存契約を変えない。
 
 ## 原則
 
 | 原則 | 基準 |
 |------|------|
 | 既存契約優先 | 既存利用者、テスト、運用が依存する契約を保持する |
-| 最小差分 | 要求達成に必要な変更だけを残す |
+| 因果差分 | 要求と因果関係のある変更を行い、因果関係のない変更を排除する |
 | 近接性より必要性 | 変更箇所に近いことを変更理由にしない |
-| 既存構造尊重 | ファイル配置、型名、公開API、責務境界を明示要求なしに変えない |
+| 既存構造尊重 | ファイル配置、型名、公開API、責務境界を要求と因果関係なく変えない |
 | コメント保全 | 意図、制約、算出根拠を示すコメントを削除しない |
 | テストの契約性 | 既存テストが検証する挙動を軽微扱いしない |
-| 改善の分離 | 作法改善や整理は要求と直接関係する場合に限定する |
-| 保守制約優先 | 一般的な品質改善より、既存挙動と既存構造の保持を優先する |
+| 外部契約一次確認 | 外部サービス・SDK・生成物の挙動は、公式仕様または実際の型・スキーマで確認する |
+| 改善の因果判定 | 作法改善・リファクタは要求と因果関係がある場合に実施する。因果関係のない改善は混ぜない |
+| 無関係保護優先 | 要求と因果関係のない既存挙動・構造の保持を優先する |
 
 ## 変更境界
 
@@ -22,21 +23,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 +46,23 @@ UI、アクセシビリティ、テスト、ログ、API、型、ファイル配
 
 | 契約 | 変更条件 |
 |------|----------|
-| UI文言、アクセシビリティ名、role/state | 要求に直接含まれる場合のみ変更する |
-| hook の戻り値、Props 型名、公開関数名 | 呼び出し元更新が要求達成に不可欠な場合のみ変更する |
+| UI文言、アクセシビリティ名、role/state | 要求と因果関係がある場合のみ変更する |
+| hook の戻り値、Props 型名、公開関数名 | 要求と因果関係のある呼び出し元更新に不可欠な場合のみ変更する |
 | テスト期待値 | 仕様変更が要求されている場合のみ変更する |
 | コメント | 誤りを直す場合、またはコードで完全に不要になった場合のみ変更する |
-| ファイル配置 | 既存構造では要求を満たせない場合のみ変更する |
+| ファイル配置 | 要求と因果関係がある場合のみ変更する |
+
+## 外部依存契約
+
+外部サービス、SDK、生成コード、スキーマ、CLI の挙動は既存システムの境界契約として扱う。操作ごとのエラー型、ステータス、戻り値、冪等性、上限、optional 条件を推測で共通化しない。
+
+| 基準 | 判定 |
+|------|------|
+| 公式仕様、実際の型定義、生成スキーマ、または既存の同種実装で具体契約を確認している | OK |
+| 同じサービス内の別操作の例外型・ステータス・戻り値を「相当」とみなし、未確認の操作へ流用する | REJECT |
+| コンパイル成功、モック成功、スタブの期待値だけで外部契約を確認済みと扱う | REJECT |
+| 計画や実装ガイドラインに外部契約の曖昧語が残る（例: 「相当」「同様」） | REJECT |
+| 外部契約を確認できない場合に、未確認範囲・リスク・確認方法を記録している | OK |
 
 ## テスト変更
 
@@ -70,4 +84,4 @@ UI、アクセシビリティ、テスト、ログ、API、型、ファイル配
 |------|------|
 | 必須変更 | これがないと要求を満たせない |
 | 関連変更 | 必須変更を接続、検証、整合させるために必要 |
-| 不要変更 | 読みやすさ、作法、ついで整理、将来拡張だけが理由 |
+| 不要変更 | 要求との因果関係がなく、読みやすさ、作法、ついで整理、将来拡張だけが理由 |

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

@@ -13,6 +13,7 @@
 | 状態整合性 | 副作用や状態変更は、正常・失敗・中断の各経路で漏れ・重複・不整合がないことを確認する |
 | 契約全入口 | 新しい契約は通常入口だけでなく、派生条件・検証・評価・出力・再注入経路まで同じ基準で確認する |
 | 契約一貫性 | 共通化・抽象化で担う契約は、既存の同種分岐にも同じ基準で適用されていることを確認する |
+| 外部契約検証 | 外部サービス・SDK・生成物の意味契約を、一次情報または実型で確認する |
 | 仕様完全性 | 利用者向け契約を変える場合、実装・テスト・ドキュメントが同じ探索順、上書き規則、特殊記法、失敗条件を説明していることを確認する |
 | 元要件固定 | タスク指示書の必須項目を、実装都合で optional・対象外・別要件に読み替えない |
 | 解消判定 | resolved 判定は修正内容ではなく、元 finding の受入条件と元要件に戻って確認する |
@@ -57,6 +58,7 @@
 - 設定・CLI・ファイル形式などの利用者向け契約変更に対して、ドキュメントや例が優先順位、first-match/merge、inline上書き、scope/特殊参照、失敗条件のいずれかを欠落している
 - 共通ヘルパー、正規化関数、builder、adapter の追加・変更後に、同じ契約を持つ既存分岐が旧実装のまま残っている
 - タスクで要求されたフィールド、属性、出力、設定、識別子を、明示根拠なく optional・未設定・対象外として扱う、または入口や実行モードによって欠落させている
+- 外部サービス・SDK・生成物の操作ごとのエラー型、ステータス、戻り値、冪等性を確認せず、別操作の契約やモックの成功で代用している
 - 副作用や状態変更の実行経路に、漏れ・重複・順序不整合がある
 - ログ、エラーレスポンス、テスト出力への機密情報露出
 
@@ -101,6 +103,7 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 | ファイルを開いて実コードを確認 | 「修正済みのはず」と思い込む |
 | 呼び出し元・使用箇所を検索 | 記憶に基づいて指摘する |
 | 型定義・スキーマを突合 | 推測でデッドコードと判断する |
+| 外部SDK・APIの操作別契約を公式仕様または実型で確認 | コンパイル成功やモック成功だけで意味契約を確認済みとする |
 | 生成ファイル（レポート等）とソースを区別 | 生成ファイルをソースコードとしてレビュー |
 | ツール出力が正常に読めることを確認 | 文字化け・異常文字を含む出力に基づいて指摘する |
 | 「存在しない」主張は対象行を直接読んで検証 | 検索結果だけで「コードにない」と断定する |

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

@@ -12,6 +12,8 @@
 | 独立性 | 他のテストや実行順序に依存しない |
 | 再現性 | 時間やランダム性に依存せず、毎回同じ結果 |
 | 非実行資産を固定しない | 実行時の振る舞いを定義しない本文や章構成を CI の失敗条件にしない |
+| 否定契約を観測単位で検証 | 禁止・拒否・非継承・非対応は、完全一致文字列の不在だけで合格にしない |
+| モック契約一致 | 外部SDK・APIのモックは実契約と一致させ、誤った前提をテストで固定しない |
 
 ## カバレッジ基準
 
@@ -113,6 +115,33 @@ test('ユーザーが存在しない場合、NotFoundエラーを返す', async
 | 変更対象関数の 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入力などを読む境界では、型定義どおりの入力だけを検証しても十分ではない。
@@ -136,6 +165,18 @@ test('ユーザーが存在しない場合、NotFoundエラーを返す', async
 | factory でデフォルトを用意し、テストに関係するフィールドだけ上書きしている | OK |
 | 契約変更時に fixture、mock、snapshot を同じ変更で更新している | OK |
 
+## 外部契約モック
+
+外部SDK、外部API、生成クライアント、CLI をモックする場合、モックの例外型、ステータス、戻り値、欠落値、部分成功、冪等性は実契約に合わせる。型が合うだけでは、意味契約を検証したことにならない。
+
+| 基準 | 判定 |
+|------|------|
+| 公式仕様、SDK型、生成スキーマ、既存同種テストのいずれかと突合してモック値を決めている | OK |
+| 実装が期待する例外や戻り値をモックに投げさせ、そのテスト成功を外部契約の根拠にしている | REJECT |
+| 同じサービス内の別操作のエラー型やレスポンス shape を流用している | REJECT |
+| 型安全なモックだが、操作ごとの意味契約（既存リソース時、部分成功時、未検出時など）を確認していない | REJECT |
+| 実連携をスタブ化する場合、モックで確認した範囲と未確認の実連携範囲をレポートに分けて記録している | OK |
+
 ### 命名
 
 テスト名は期待される振る舞いを記述する。`should {期待する振る舞い} when {条件}` パターンを使う。

package/builtins/ja/workflow-categories.yaml

@@ -24,6 +24,7 @@ workflow_categories:
     workflows:
       - backend
       - backend-mini
+      - backend-maintenance
       - backend-cqrs
       - backend-cqrs-mini
   🔧 デュアル: