takt 0.48.0 → 0.49.0

package/README.md

@@ -234,6 +234,7 @@ See the [Builtin Catalog](./docs/builtin-catalog.md) for all workflows and perso
 | Command | Description |
 |---------|-------------|
 | `takt` | Talk to AI, refine requirements, execute or queue tasks |
+| `takt exec` | Start instant Assistant/Worker/Review agent mode without writing workflow YAML |
 | `takt run` | Execute all pending tasks |
 | `takt list` | Manage task branches (merge, retry, requeue, force-fail, instruct, delete) |
 | `takt #N` | Execute GitHub Issue as task |
@@ -244,6 +245,18 @@ See the [Builtin Catalog](./docs/builtin-catalog.md) for all workflows and perso
 
 See the [CLI Reference](./docs/cli-reference.md) for all commands and options.
 
+### Instant exec mode
+
+`takt exec` starts TAKT's interactive task-entry mode. The Assistant agent clarifies the request, `/go` turns the conversation into a generated workflow, Worker agent(s) implement the task, Review agent(s) review the result, the Replanning agent asks the user for direction when needed, and loop detection prevents repeated unproductive cycles.
+
+Exec starts from the previous exec configuration, or the default configuration on first run. Pass a preset name to start from that preset. Use `/setup` during the conversation to edit agents, loop detection thresholds, presets, and referenced instruction/knowledge/policy facets. Builtin/default presets define the agent roles, facets, and loop thresholds only. Provider and model are resolved from normal TAKT configuration when exec mode starts, and the same resolved values are used for the Assistant dialogue, `/setup` display, and workflow generation. An exec config overrides provider/model only when it sets them explicitly. `effort` is emitted only when it is explicitly configured.
+
+Exec presets resolve in this order: project `.takt/exec/presets/` → global `$TAKT_CONFIG_DIR/exec/presets/` (default `~/.takt/exec/presets/`) → builtin `builtins/exec/presets/`. Changes made in `/setup` are saved to `$TAKT_CONFIG_DIR/exec.yaml` (default `~/.takt/exec.yaml`) for the next exec session. `/setup` can also save or delete project/global presets, and created facets are stored under `.takt/facets/` or `$TAKT_CONFIG_DIR/facets/` (default `~/.takt/facets/`).
+
+When `/go` runs, TAKT generates `.takt/exec/workflow.yaml` and executes it through the normal workflow engine. Inline text after `/go` is treated as an additional note. `/go` without prior conversation or inline task text does not generate the workflow. Use `/cancel` to exit without running.
+
+Normal agent steps, parallel sub-steps, and loop detection judges may set `session_key` to share or isolate persona sessions. System steps, workflow_call steps, and parallel parent steps cannot set `session_key`. TAKT builds the runtime key as `session_key` plus the resolved provider, so values must be non-empty strings that do not collide with other generated session routes.
+
 ## Configuration
 
 Minimal `~/.takt/config.yaml`:

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

@@ -0,0 +1,15 @@
+# Exec Loop Monitor Instruction
+
+Review whether the repeated exec loop is productive.
+
+This loop has repeated {cycle_count} times.
+
+Review recent reports in chronological order and choose one of the following conditions.
+
+Small loop (execute ↔ review):
+- `Healthy (progress being made)` — findings are decreasing or meaningful progress is visible.
+- `Unproductive (same rework repeating)` — the same fixes repeat with no improvement.
+
+Large loop (replan → execute → review):
+- `Healthy (progress being made)` — findings are decreasing or meaningful progress is visible.
+- `Unproductive (no convergence)` — workers stay blocked or no convergence is visible.

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

@@ -0,0 +1,5 @@
+# Exec Replan Instruction
+
+Discuss replanning with the user after a review requests needs_replan.
+
+Summarize the blocking issue from the review report, ask for the minimum needed clarification, and produce a revised plan when ready.

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

@@ -0,0 +1,10 @@
+# Exec Review Instruction
+
+Review the worker result in an independent session.
+
+Check the task requirement, worker reports, and actual code changes. Return one of these statuses:
+- approved: the task is complete.
+- needs_fix: small implementation fixes are required.
+- needs_replan: the approach needs user-level replanning.
+
+Include concise evidence and concrete next steps.

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

@@ -0,0 +1,5 @@
+# Exec Worker Instruction
+
+Implement the requested task.
+
+Use the task instruction and reports in the Report Directory as primary context. If this is a fix pass, address review findings first. Keep changes inside the assigned scope, run the relevant checks, and report changed files and verification results.

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

@@ -88,6 +88,22 @@ In TAKT, workflow runtime is not the only user-visible contract entry. Preview,
 | Doctor or validation accepts config that fails at runtime due to different conditions | Warning |
 | Runtime and auxiliary entries share the same normalized input or resolver | OK |
 
+## Runtime Asset Consumption Boundaries
+
+TAKT runtime assets get their meaning from the entry point that consumes them, not only from their location or name. The same string can be an asset reference, session identifier, display name, or directly supplied body, and each is a separate contract.
+
+| Criteria | Judgment |
+|----------|----------|
+| Treating an entry that resolves asset references and an entry that only uses identifiers as equivalent | REJECT |
+| Adding a same-named facet and assuming it affects an entry that receives body content directly | REJECT |
+| Workflow-derived runtime assets and feature-local runtime assets share the same responsibility name | Warning |
+| Each entry point confirms which resolver or loader consumes which asset type before placing the asset | OK |
+| Shared body content is centralized behind the existing runtime asset loader | OK |
+
+### Reference Names and Identity Names
+
+Strings such as `persona`, `session_key`, and `name` mean different things depending on whether they are reference names or identity names. A reference name causes the corresponding resolver to load an asset. An identity name is a key for sessions, logs, state, or display, and a same-named file is not used unless that entry reads it. When adding a new asset, trace the loader that reads it and the call site that consumes it.
+
 ## Facet Assembly
 
 The faceted-prompting module is independent from TAKT core.

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

@@ -0,0 +1,13 @@
+# Exec Review Result
+
+## Status
+
+approved | needs_fix | needs_replan
+
+## Evidence
+
+Concise evidence for the status.
+
+## Required Next Step
+
+Concrete next action, if any.

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

@@ -0,0 +1,3 @@
+# Assistant Persona
+
+You are a TAKT assistant. Stay helpful, concise, and action-oriented.

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

@@ -0,0 +1,3 @@
+# Worker Persona
+
+You are a TAKT worker. Stay focused, precise, and self-contained.

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

@@ -12,6 +12,7 @@ For released or operational systems, make changes that are causally related to t
 | Respect existing structure | Do not change file placement, type names, public APIs, or responsibility boundaries without causal relationship to the request |
 | Preserve comments | Do not delete comments that explain intent, constraints, or calculation rationale |
 | Tests are contracts | Do not treat behavior asserted by existing tests as incidental |
+| Verify external contracts from primary evidence | Confirm behavior of external services, SDKs, and generated artifacts from official specs or actual types/schemas |
 | Causal improvement judgment | Perform style improvements and refactoring when causally related to the request. Do not mix improvements without causal relationship |
 | Protect unrelated code | Prioritize preserving existing behavior and structure that is not causally related to the request |
 
@@ -51,6 +52,18 @@ UI, accessibility, tests, logs, APIs, types, file placement, and comments can be
 | Comments | Change only when correcting inaccurate comments or when code makes them truly obsolete |
 | File placement | Change only when causally related to the request |
 
+## External Dependency Contracts
+
+Treat behavior of external services, SDKs, generated code, schemas, and CLIs as boundary contracts of the existing system. Do not infer one operation's error types, statuses, return values, idempotency, limits, or optionality from another operation without verification.
+
+| Criteria | Verdict |
+|----------|---------|
+| The concrete contract is verified from official specs, actual type definitions, generated schemas, or existing equivalent implementation | OK |
+| Error types, statuses, or return values from a different operation in the same service are generalized as "equivalent" and reused for an unverified operation | REJECT |
+| Compile success, mock success, or stub expectations alone are treated as proof of the external contract | REJECT |
+| Plans or implementation guidelines keep vague external-contract wording such as "equivalent" or "same as" | REJECT |
+| When the external contract cannot be verified, the unverified scope, risk, and verification method are recorded | OK |
+
 ## Test Changes
 
 Tests should distinguish existing contracts from new requirements, not merely follow the implementation.

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

@@ -13,6 +13,7 @@ Define the shared judgment criteria and behavioral principles for all reviewers.
 | State consistency | For side effects and state changes, verify that success, failure, and interruption paths have no missing, duplicated, or inconsistent effects |
 | Contract coverage | Verify new contracts across normal entries, derived conditions, validation, evaluation, output, and re-injection paths |
 | Contract consistency | Verify that contracts carried by consolidation or abstraction are applied to existing equivalent branches by the same standard |
+| External contract verification | Verify semantic contracts of external services, SDKs, and generated artifacts from primary evidence or actual types |
 | Specification completeness | When changing a user-facing contract, verify that implementation, tests, and documentation describe the same lookup order, override rules, special syntax, and failure conditions |
 | Requirement anchoring | Do not reinterpret required task items as optional, out of scope, or different requirements for implementation convenience |
 | Resolution judgment | Judge `resolved` against the original finding acceptance criteria and original task requirements, not merely against the presence of a fix |
@@ -57,6 +58,7 @@ REJECT without exception if any of the following apply.
 - User-facing contract changes for configuration, CLI, or file formats where documentation or examples omit priority, first-match/merge behavior, inline overrides, scoped/special references, or failure conditions
 - Existing branches with the same contract remain on the old implementation after adding or changing a shared helper, normalizer, builder, or adapter
 - Fields, attributes, outputs, settings, or identifiers requested by the task are treated as optional, unset, out of scope, or missing for some entry point or execution mode without explicit evidence
+- Operation-specific error types, statuses, return values, or idempotency of an external service, SDK, or generated artifact are not verified, and another operation's contract or mock success is used instead
 - Missing, duplicated, or incorrectly ordered effects in side-effect or state-change paths
 - Sensitive data exposed in logs, error responses, or test output
 

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

@@ -14,6 +14,7 @@ Every behavior change requires a corresponding test, and every bug fix requires
 | Reproducibility | Do not depend on time or randomness. Same result every run |
 | Do not freeze non-executable assets | Do not make prose or section structure that does not define runtime behavior a CI failure condition |
 | Verify negative contracts at observable units | Do not pass prohibition, rejection, non-inheritance, or unsupported cases by exact-string absence alone |
+| Mock contract fidelity | Keep external SDK/API mocks aligned with real contracts and do not freeze wrong assumptions in tests |
 
 ## Coverage Criteria
 
@@ -164,6 +165,18 @@ Test data should explicitly generate the minimum facts needed by each test. Muta
 | Factories provide defaults and each test overrides only relevant fields | OK |
 | Contract changes update fixtures, mocks, and snapshots in the same change | OK |
 
+## External Contract Mocks
+
+When mocking an external SDK, external API, generated client, or CLI, align mocked exception types, statuses, return values, missing values, partial successes, and idempotency with the real contract. Type compatibility alone does not verify the semantic contract.
+
+| Criteria | Verdict |
+|----------|---------|
+| Mock values are chosen by checking official specs, SDK types, generated schemas, or existing equivalent tests | OK |
+| The mock throws the exception or return value expected by the implementation, and test success is used as proof of the external contract | REJECT |
+| Error types or response shapes from a different operation in the same service are reused | REJECT |
+| The mock is type-safe but operation-specific semantic contracts, such as existing-resource behavior, partial success, or missing detection, are not verified | REJECT |
+| When real integration is stubbed, the report separates what the mock verifies from the unverified real-integration scope | OK |
+
 ### Naming
 
 Test names describe expected behavior. Use the `should {expected behavior} when {condition}` pattern.

package/builtins/en/workflows/draft.yaml

@@ -98,7 +98,7 @@ steps:
       - review
       - ai-antipattern
     provider_options:
-      extends: review-web
+      extends: review-readonly
     rules:
       - condition: No AI-specific issues
         next: COMPLETE

package/builtins/en/workflows/peer-review-with-fc.yaml

@@ -163,7 +163,7 @@ steps:
           - review
           - ai-antipattern
         provider_options:
-          extends: review-web
+          extends: review-readonly
         instruction: ai-antipattern-review
         rules:
           - condition: approved

package/builtins/en/workflows/peer-review.yaml

@@ -156,7 +156,7 @@ steps:
           - review
           - ai-antipattern
         provider_options:
-          extends: review-web
+          extends: review-readonly
         instruction: ai-antipattern-review
         rules:
           - condition: approved

package/builtins/exec/presets/backend.yaml

@@ -0,0 +1,31 @@
+name: backend
+description: Backend development team
+session: {}
+replan:
+  instruction: exec-replan
+  knowledge:
+    - architecture
+    - backend
+  policy: []
+workers:
+  - name: worker-1
+    instruction: exec-worker
+    knowledge:
+      - architecture
+      - backend
+      - security
+    policy:
+      - coding
+      - testing
+reviews:
+  - name: review-1
+    instruction: exec-review
+    knowledge:
+      - architecture
+      - security
+    policy:
+      - review
+loop:
+  threshold: 3
+  large_threshold: 2
+  max_steps: 20

package/builtins/exec/presets/dual.yaml

@@ -0,0 +1,34 @@
+name: dual
+description: Two-worker development team
+session: {}
+replan:
+  instruction: exec-replan
+  knowledge:
+    - architecture
+  policy: []
+workers:
+  - name: worker-1
+    instruction: exec-worker
+    knowledge:
+      - architecture
+    policy:
+      - coding
+      - testing
+  - name: worker-2
+    instruction: exec-worker
+    knowledge:
+      - unit-testing
+    policy:
+      - coding
+      - testing
+reviews:
+  - name: review-1
+    instruction: exec-review
+    knowledge:
+      - architecture
+    policy:
+      - review
+loop:
+  threshold: 3
+  large_threshold: 2
+  max_steps: 20

package/builtins/exec/presets/frontend.yaml

@@ -0,0 +1,31 @@
+name: frontend
+description: Frontend development team
+session: {}
+replan:
+  instruction: exec-replan
+  knowledge:
+    - architecture
+    - frontend
+    - react
+  policy: []
+workers:
+  - name: worker-1
+    instruction: exec-worker
+    knowledge:
+      - frontend
+      - react
+    policy:
+      - coding
+      - testing
+reviews:
+  - name: review-1
+    instruction: exec-review
+    knowledge:
+      - frontend
+      - react
+    policy:
+      - review
+loop:
+  threshold: 3
+  large_threshold: 2
+  max_steps: 20

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/knowledge/takt.md

@@ -88,6 +88,22 @@ TAKT では workflow 実行経路だけでなく、preview、doctor、workflow s
 | 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

@@ -12,6 +12,7 @@
 | 既存構造尊重 | ファイル配置、型名、公開API、責務境界を要求と因果関係なく変えない |
 | コメント保全 | 意図、制約、算出根拠を示すコメントを削除しない |
 | テストの契約性 | 既存テストが検証する挙動を軽微扱いしない |
+| 外部契約一次確認 | 外部サービス・SDK・生成物の挙動は、公式仕様または実際の型・スキーマで確認する |
 | 改善の因果判定 | 作法改善・リファクタは要求と因果関係がある場合に実施する。因果関係のない改善は混ぜない |
 | 無関係保護優先 | 要求と因果関係のない既存挙動・構造の保持を優先する |
 
@@ -51,6 +52,18 @@ UI、アクセシビリティ、テスト、ログ、API、型、ファイル配
 | コメント | 誤りを直す場合、またはコードで完全に不要になった場合のみ変更する |
 | ファイル配置 | 要求と因果関係がある場合のみ変更する |
 
+## 外部依存契約
+
+外部サービス、SDK、生成コード、スキーマ、CLI の挙動は既存システムの境界契約として扱う。操作ごとのエラー型、ステータス、戻り値、冪等性、上限、optional 条件を推測で共通化しない。
+
+| 基準 | 判定 |
+|------|------|
+| 公式仕様、実際の型定義、生成スキーマ、または既存の同種実装で具体契約を確認している | OK |
+| 同じサービス内の別操作の例外型・ステータス・戻り値を「相当」とみなし、未確認の操作へ流用する | REJECT |
+| コンパイル成功、モック成功、スタブの期待値だけで外部契約を確認済みと扱う | REJECT |
+| 計画や実装ガイドラインに外部契約の曖昧語が残る（例: 「相当」「同様」） | REJECT |
+| 外部契約を確認できない場合に、未確認範囲・リスク・確認方法を記録している | OK |
+
 ## テスト変更
 
 テストは実装へ追随させるものではなく、既存契約と新要求を区別するために使う。

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

@@ -13,6 +13,7 @@
 | 再現性 | 時間やランダム性に依存せず、毎回同じ結果 |
 | 非実行資産を固定しない | 実行時の振る舞いを定義しない本文や章構成を CI の失敗条件にしない |
 | 否定契約を観測単位で検証 | 禁止・拒否・非継承・非対応は、完全一致文字列の不在だけで合格にしない |
+| モック契約一致 | 外部SDK・APIのモックは実契約と一致させ、誤った前提をテストで固定しない |
 
 ## カバレッジ基準
 
@@ -164,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/workflows/draft.yaml

@@ -98,7 +98,7 @@ steps:
       - review
       - ai-antipattern
     provider_options:
-      extends: review-web
+      extends: review-readonly
     rules:
       - condition: AI特有の問題なし
         next: COMPLETE

package/builtins/ja/workflows/peer-review-with-fc.yaml

@@ -163,7 +163,7 @@ steps:
           - review
           - ai-antipattern
         provider_options:
-          extends: review-web
+          extends: review-readonly
         instruction: ai-antipattern-review
         rules:
           - condition: approved

package/builtins/ja/workflows/peer-review.yaml

@@ -156,7 +156,7 @@ steps:
           - review
           - ai-antipattern
         provider_options:
-          extends: review-web
+          extends: review-readonly
         instruction: ai-antipattern-review
         rules:
           - condition: approved

package/builtins/skill/SKILL.md

@@ -137,7 +137,7 @@ current_step のプロンプトを構築する（→ references/engine.md のプ
 
 プロンプト構築の要素:
 1. **ペルソナ**: `persona:` キー → `personas:` セクション → .md ファイル内容
-2. **ポリシー**: `policy:` キー → `policies:` セクション → .md ファイル内容（複数可、末尾にリマインダー再掲）
+2. **ポリシー**: `policy:` キー → `policies:` セクション → .md ファイル内容（複数可）
 3. **実行コンテキスト**: cwd, ワークフロー名, step 名, イテレーション情報
 4. **ナレッジ**: `knowledge:` キー → `knowledge:` セクション → .md ファイル内容
 5. **インストラクション**: `instruction:` キー → `instructions:` セクション → .md ファイル内容（テンプレート変数展開済み）

package/builtins/skill/references/engine.md

@@ -89,7 +89,6 @@ Task tool:
 9. 前の step の出力（pass_previous_response: true の場合、自動追加）
 10. レポート出力指示（report フィールドがある場合、自動追加）
 11. ステータスタグ出力指示（rules がある場合、自動追加）
-12. ポリシーリマインダー（ポリシーがある場合、末尾に再掲）
 ```
 
 ### ペルソナプロンプト
@@ -100,19 +99,6 @@ step の `persona:` キーからセクションマップを経由して .md フ
 
 step の `policy:` キー（単一または配列）からポリシーファイルを解決し、内容を結合する。ポリシーは行動ルール（コーディング規約、レビュー基準等）を定義する。
 
-**Lost in the Middle 対策**: ポリシーはプロンプトの前半に配置し、末尾にリマインダーとして再掲する。
-
-```
-（プロンプト冒頭付近）
-## ポリシー（行動ルール）
-{ポリシーの内容}
-
-（プロンプト末尾）
----
-**リマインダー**: 以下のポリシーに従ってください。
-{ポリシーの内容（再掲）}
-```
-
 ### ナレッジ注入
 
 step の `knowledge:` キーからナレッジファイルを解決し、ドメイン固有の参考情報としてプロンプトに含める。
@@ -410,7 +396,7 @@ initial_step を取得
 │     ├── 通常: 1つの Task tool 呼び出し
 │     │     prompt = persona + policy + context + knowledge
 │     │           + instruction + task + previous_response
-│     │           + レポート指示 + タグ指示 + ポリシーリマインダー
+│     │           + レポート指示 + タグ指示
 │     └── parallel: 複数の Task tool を1メッセージで並列呼び出し
 │           各サブステップを別々のチームメイトとして起動
 │   ↓

package/builtins/skill-codex/SKILL.md

@@ -124,7 +124,7 @@ current_step のプロンプトを構築する（→ references/engine.md のプ
 
 プロンプト構築の要素:
 1. **ペルソナ**: `persona:` キー → `personas:` セクション → .md ファイル内容
-2. **ポリシー**: `policy:` キー → `policies:` セクション → .md ファイル内容（複数可、末尾にリマインダー再掲）
+2. **ポリシー**: `policy:` キー → `policies:` セクション → .md ファイル内容（複数可）
 3. **実行コンテキスト**: cwd, ワークフロー名, step 名, イテレーション情報
 4. **ナレッジ**: `knowledge:` キー → `knowledge:` セクション → .md ファイル内容
 5. **インストラクション**: `instruction:` キー → `instructions:` セクション → .md ファイル内容（テンプレート変数展開済み）

package/builtins/skill-codex/references/engine.md

@@ -91,8 +91,6 @@ codex exec --full-auto - < "$tmp_prompt_file"
 9. 前回出力（`pass_previous_response: true` のとき）
 10. レポート出力指示（`report` または `output_contracts.report` があるとき）
 11. ステータスタグ出力指示（`rules` があるとき）
-12. ポリシーリマインダー（ポリシーを末尾再掲）
-
 ### テンプレート変数展開
 
 インストラクション内のプレースホルダーを置換する。