piaro · Aug 30, 2026 · Aug 30, 2026
diff --git a/README.md b/README.md
@@ -245,7 +245,7 @@ adf mcp --project /path/to/project
     │           ├─ Builder    implement, then record required clause evidence
     │           └─ Challenger try to falsify it, before and after the build
     │           │
-    └───────────┴─ adf_submit ──── validated, stored, reevaluated
+    └───────────┴─ adf_submit ──── validated and stored
                 │
                 ▼
           ready to merge
@@ -283,15 +283,28 @@ While impact assessment is still pending, `next` and `explain` select that
 action before deriving repository-wide Contract health. Unrelated Result and
 Evidence history is not loaded for this first step.
 
-When Contract health is required, ADF indexes Evidence and verification Results
-once, then validates and hashes only records that can affect a Contract clause.
-It does not repeatedly scan every Result for every clause.
+When Contract health is required, ADF maintains persistent Evidence and Result
+indexes under `.adf/cache/runtime/`. Unchanged tracked records are identified by
+their Git blob IDs; changed and untracked records use content hashes. ADF parses
+only records whose source identity changed, and it does not scan every Result
+again for each Contract clause. Corrupt cache entries are rebuilt from source.
+ADF writes runtime caches only when Git confirms that the cache path is ignored.
+
+Repository observation uses a separate cache tied to the current revision,
+analysis configuration, signal catalog, and source identities. Source changes
+invalidate the observation without making cache files authoritative.
 
 New Results store shared input and freshness references once at the Result
 level. An outcome carries its own references only when they differ from those
 shared values. Existing Results remain readable and are not rewritten, so their
 identities and downstream freshness checks remain stable.
 
+`adf_submit` returns after the Result is stored. Its response includes
+`result_id`, `already_completed`, `next_required`, and per-stage `timings_ms`.
+Call `adf_next` separately when `next_required` is true. This keeps a slow next
+evaluation from obscuring whether submission itself succeeded. `adf_next` also
+reports per-stage timings.
+
 Each action also carries advisory execution guidance. Impact assessment
 normally recommends an economy model, while challenge recommends a
 high-accuracy model. The listed escalation conditions tell an orchestrator when

diff --git a/docs/MCP-DESIGN.md b/docs/MCP-DESIGN.md
@@ -154,7 +154,7 @@ registered_output_refs: []
 - RegistryはMCP sessionのmemoryにだけ保持する。memoryにないActionは、正本の再評価と一致するときに再構成する。再構成後に`adf_next`を呼んだ場合も、同じChangeの正本に保存済みのEvidence、Decision、Contractは提出時の出力として参照できる。
 - Generated ContextをGit、Result、derived cacheへ保存しない。
 - Evidence、Decision、Contractの専用Toolが保存したrefだけを`registered_output_refs`へ追加する。Evidenceには、発行済みRequirementが参照した入力digestを`input_refs`として付与する。
-- 正常な`submit`後にexact keyを消費し、再評価で返した次Actionを新しいentryとして登録する。
+- 正常な`submit`後にexact keyを消費する。次Actionは後続の`adf_next`で発行し、新しいentryとして登録する。
 - submit失敗時は、修正して再試行できるようentryを残す。
 - 同じkeyへ複数提出が競合した場合、Filesystem Storeのexclusive createを最終防衛線とする。
 
@@ -186,7 +186,7 @@ Tool名は広いMCP client互換性を優先し、ASCII英数字とunderscoreだ
 | `adf_execution_log` | read | 保存済みResultと実行RecordからContextサイズと計測値を集計する |
 | `adf_begin_execution` | write | 現在のActionに対する外部実行の開始を追記する。Agentは起動しない |
 | `adf_complete_execution` | write | 外部実行の成否と確定済みの利用量を追記する |
-| `adf_submit` | write | 発行済みActionのResultを検証・保存し、再評価する |
+| `adf_submit` | write | 発行済みActionのResultを検証・保存する |
 | `adf_add_evidence` | write | 発行済みEvidence ActionへEvidenceを追記する |
 | `adf_apply_decision` | write | Human回答を解決するDecisionを保存する |
 | `adf_apply_contract` | write | Decisionを反映したContractを楽観的lock付きで更新する |
@@ -204,7 +204,7 @@ MCP Tool annotationはHost向けhintとして設定しますが、認可には
 ## 10. Tool契約
 
 全Toolは`inputSchema`と`outputSchema`を公開し、成功時は`structuredContent`を返します。
-保存Record Schemaとは別に、MCP I/O Schemaを`schemas/mcp/v1/`へ置きます。
+保存Record Schemaとは別に、MCP I/O Schemaを`schemas/mcp/`へ置きます。`adf_next`はv1、保存完了だけを返す`adf_submit`出力はv2です。
 
 ### 10.1 `adf_next`
 
@@ -227,6 +227,11 @@ Output:
     "change_id": "change.example",
     "action_id": "action.example",
     "context_digest": "sha256:..."
+  },
+  "timings_ms": {
+    "repository_load": 12,
+    "evaluation": 34,
+    "total": 46
   }
 }
 ```
@@ -261,13 +266,22 @@ Output:
 
 ```json
 {
-  "schema_version": "1",
+  "schema_version": "2",
   "result_id": "result.example",
   "already_completed": false,
-  "next_response": {}
+  "next_required": true,
+  "timings_ms": {
+    "repository_load": 12,
+    "change_snapshot": 3,
+    "validation_and_persist": 8,
+    "total": 23
+  }
 }
 ```
 
+- `adf_submit`はResultを永続化した時点で応答し、次Actionを計算しない。
+- `next_required`が`true`なら、呼出し側は`adf_next`を別に実行する。
+- `timings_ms`は処理段階ごとの実測時間をミリ秒で返す。
 - exact action keyがRegistryにない提出は、正本を再評価して同じActionが現在のものであるときだけ受理する。
 - 成功したResult追記後だけActionを消費する。
 - Contract、Decision、Evidenceの`output_refs`は、同じentryの`registered_output_refs`に存在しなければ拒否する。再起動を跨いだActionでは、そのRecordがChangeの正本に存在することで代える。
@@ -482,8 +496,11 @@ schemas/mcp/v1/
 ├── next-input.schema.json
 ├── next-output.schema.json
 ├── submit-input.schema.json
-├── submit-output.schema.json
+├── submit-output.schema.json  # 旧出力契約
 └── tool-error.schema.json
+
+schemas/mcp/v2/
+└── submit-output.schema.json
 ```
 
 RMCP、Tokio、schema生成用crateを追加する場合も、公開Schemaの正本はRepository上のJSON
@@ -507,7 +524,7 @@ Schemaとし、生成差分をtestで検査します。
 - 専用Toolを経由していないContract、Decision、Evidenceの`output_refs`を拒否
 - Decision、Contract、EvidenceのAction binding
 - submit失敗時にIssued Actionを消費しない
-- 成功時にexact Actionだけを消費し、返した次Actionを登録する
+- 成功時にexact Actionだけを消費し、次の`adf_next`で新しいActionを登録する
 
 ### 18.3 MCP protocol integration
 
@@ -517,7 +534,7 @@ Schemaとし、生成差分をtestで検査します。
 2. tools/list
 3. `adf_next`
 4. `adf_submit`
-5. 再評価後の次Action
+5. `adf_next`で次Actionを取得
 6. lifecycle全体を`ready-to-merge`まで実行
 7. stdoutへJSON-RPC以外を出さない
 8. server停止時に未提出Actionを失効

diff --git a/docs/concepts.ja.md b/docs/concepts.ja.md
@@ -31,7 +31,7 @@ Contractは変更のたびに増えます。障害から学んだことはテス
 
 ## 変更の流れ
 
-変更は`adf change init`で作ります。以降は`adf next`が「次にやること」を1件ずつ返します。エージェントはそれを実行し、MCPの`adf_submit`で結果を提出して、また次を受け取ります。作業の順番を決めるのはエージェントではなく`adf`です。
+変更は`adf change init`で作ります。以降は`adf next`が「次にやること」を1件ずつ返します。エージェントはそれを実行し、MCPの`adf_submit`で結果を保存してから、`adf_next`で次の作業を受け取ります。作業の順番を決めるのはエージェントではなく`adf`です。
 
 最初の作業は影響評価です。変更の目的から、影響がある対象とリスクを実装前に整理します。結果は次の3種類を明示します。
 
@@ -54,7 +54,7 @@ Contractは変更のたびに増えます。障害から学んだことはテス
 │       ├─ Builder    実装し、必要な条項の証拠を記録する
 │       └─ Challenger 実装の前後で反証する
 │       │
-└───────┴─ adf_submit ─── 結果を検証して保存し、状態を進める
+└───────┴─ adf_submit ─── 結果を検証して保存する
         │
         ▼
    ready-to-merge
@@ -97,10 +97,14 @@ Contractまたは条項の`evidence_mode`で、検証に掛ける費用を選べ
 
 影響評価が済んでいない間、`adf next`と`adf explain`は、リポジトリ全体のContract検証状態を計算する前に影響評価を次の作業として選びます。この最初の段階では、無関係なChangeのResultとEvidenceを読み込みません。
 
-Contract検証状態が必要な場合は、Evidenceと検証Resultを一度索引化し、Contract条項へ影響する記録だけを検証してハッシュを計算します。条項ごとに全Resultを繰り返し検索しません。
+Contract検証状態が必要な場合は、Evidenceと検証Resultの永続索引を`.adf/cache/runtime/`に作ります。変更のない記録はGitのBlob ID、変更中または未追跡の記録は内容ハッシュで識別します。元の記録が変わった場合だけJSONを読み直し、条項ごとに全Resultを繰り返し検索しません。索引が壊れている場合は正本から作り直します。Gitがキャッシュ先を無視すると確認できた場合だけ、索引をファイルへ保存します。
+
+Repository観測も、現在のrevision、解析設定、Signal Catalog、解析対象ファイルに結び付いたキャッシュを使います。解析対象が変われば無効になるため、キャッシュを正本として扱いません。
 
 新しいResultでは、すべての判定結果に共通する入力参照と鮮度参照をResult全体へ一度だけ保存します。判定結果ごとの参照が共通値と異なる場合だけ、その判定結果にも保存します。既存Resultは引き続き読み込めます。識別子と後続Resultの鮮度判定を保つため、既存ファイルは自動で書き換えません。
 
+`adf_submit`はResultの保存が完了した時点で応答します。応答にはResult ID、再送かどうか、次の`adf_next`が必要かどうか、処理段階ごとの所要時間が含まれます。次の作業の計算が遅くても、Resultが保存されたかどうかを区別できます。`adf_next`も処理段階ごとの所要時間を返します。
+
 各作業には、実行環境へ向けたモデルの推奨も含まれます。影響評価には通常、軽量なモデルを推奨します。ただし、影響なしと結論付ける場合、根拠が矛盾する場合、セキュリティ、プライバシー、決済、元に戻せないデータ変更の可能性がある場合は、精度の高いモデルへの切り替えを勧めます。ADF自体はモデルを選ばず、LLMも実行しません。
 
 実行環境がすでに把握している処理時間、モデル名、入出力Token数、ツール呼び出し数、再試行回数は、`adf_submit`で任意に記録できます。外部Runnerは`adf_begin_execution`と`adf_complete_execution`を使い、Result提出後に確定したToken数や、失敗・中断した実行も追記できます。外部実行では、キャッシュ作成Token、キャッシュ読取Token、推論Token、実行環境が報告した米ドル費用も記録できます。この実行RecordはADFの状態、Result ID、鮮度、Evidence検証には影響しません。同じResultに提出時の計測値とRunnerの完了Recordがある場合は、Runnerの値だけを集計します。

diff --git a/docs/implementation.md b/docs/implementation.md
@@ -122,7 +122,9 @@ Explainでは、確認前を`applicability-pending`、支持された後を`not-
 
 `contract-health`は、全ChangeのResult・Evidenceと現在のRepository観測から、Contract条項ごとの実装準拠状態を再生成します。
 
-計算時には、条項ごとのEvidenceと、Evidenceを参照する検証Resultを一度索引化します。Schema検証と現在値のハッシュ計算は、Contract Healthへ影響するContract、Evidence、検証Result、参照先だけに限定します。Result全件を条項ごとに走査せず、無関係なResultの内容全体も検証しません。ただし、Filesystem StoreはすべてのResultファイルを列挙してJSONとして読み込むため、壊れたJSONは引き続きエラーになります。
+計算時には、条項ごとのEvidenceと、Evidenceを参照する検証Resultを索引化します。索引は`.adf/cache/runtime/`へ保存し、追跡済みRecordはGitのBlob ID、変更中または未追跡のRecordは内容ハッシュで更新を判定します。変更のないResultとEvidenceはJSONの読込み、Schema検証、ハッシュ計算を再実行しません。Result全件を条項ごとに走査せず、壊れた索引は正本から作り直します。Gitが保存先を無視すると確認できない場合は、索引をメモリ内だけで使います。
+
+Repository観測も永続キャッシュを使います。現在のrevision、解析設定、Signal Catalog、解析対象の識別子がすべて一致する場合だけ再利用します。キャッシュは派生データであり、Actionの認証やRecordの正本には使いません。
 
 Result提出時は、判定結果の`input_refs`と`freshness_refs`がResult全体の値と同じなら省略します。判定結果だけが追加または異なる参照を持つ場合は、その値を判定結果へ保存します。Kernelは判定結果に値がなければResult全体の値を使うため、既存形式と軽量形式を同じ意味で扱えます。Schema上で両項目はもともと省略可能なので、Schema versionは変更しません。既存Resultを変換するとResult IDと、それを参照する後続Resultの鮮度が変わるため、自動移行は行いません。
 
@@ -513,14 +515,16 @@ bindings:
       authority_ref: decision.repository-bindings
 ```
 
-Agentの通常利用経路はlocal stdio MCP serverです。同じRustバイナリを`mcp` subcommandで起動すると、`next`、`submit`、`explain`、`contract-health`と、発行Actionに限定されたEvidence、Decision、Contract書込みToolを利用できます。Tool契約と信頼境界は[`MCP-DESIGN.md`](MCP-DESIGN.md)、固定I/O Schemaは`schemas/mcp/v1/`にあります。既存CLIは人向け診断、CI、Release・binary管理の補助経路として残します。
+Agentの通常利用経路はlocal stdio MCP serverです。同じRustバイナリを`mcp` subcommandで起動すると、`next`、`submit`、`explain`、`contract-health`と、発行Actionに限定されたEvidence、Decision、Contract書込みToolを利用できます。Tool契約と信頼境界は[`MCP-DESIGN.md`](MCP-DESIGN.md)、固定I/O Schemaは`schemas/mcp/`にあります。既存CLIは人向け診断、CI、Release・binary管理の補助経路として残します。
 
 ```sh
 adf mcp --project .
 ```
 
 MCP serverは一つのProject rootへ固定され、stdoutをJSON-RPC専用にします。Action Resultは、`adf_next`が発行した`change_id`、Action ID、Context digestの完全一致でのみ受理します。再接続後は`adf_next`を再実行します。正本を再評価して同じActionが返る場合は、接続断前に保存したEvidence、Decision、Contractを提出時の出力として参照できます。
 
+`adf_submit`はResultを永続化した時点で応答し、次Actionは計算しません。応答の`next_required`が`true`なら、呼出し側が`adf_next`を別に実行します。`adf_submit`と`adf_next`は処理段階ごとの`timings_ms`を返します。
+
 ```sh
 sh scripts/tests/test-rust.sh
 ```
@@ -764,7 +768,7 @@ sources:
 | `src/project_runtime.rs` | 実Projectのconfig、Release、Git観測、Storeを接続 |
 | `src/migration.rs` | 現行CLI Projectを診断し、Migration Draftのレビュー検証、隔離候補の生成・整合性検証・明示適用を行う |
 | `schemas/v1/` | 保存Recordの言語非依存Schema |
-| `schemas/mcp/v1/` | Agent用MCP Toolの固定I/O Schema |
+| `schemas/mcp/v1/`、`schemas/mcp/v2/` | Agent用MCP Toolの固定I/O Schema。`adf_submit`出力はv2 |
 | `schemas/ci/v1/` | project所有のCI policy形式。Contract Healthの停止対象を明示する |
 | `schemas/benchmarks/v1/` | Detector benchmark corpusとreview済み正解・閾値の固定形式 |
 | `schemas/catalog/v1/` | 標準Signal Domain CatalogとFramework Detection Catalogの機械可読な固定形式 |

diff --git a/schemas/mcp/v1/next-output.schema.json b/schemas/mcp/v1/next-output.schema.json
@@ -25,6 +25,13 @@
           "type": "null"
         }
       ]
+    },
+    "timings_ms": {
+      "type": "object",
+      "additionalProperties": {
+        "type": "integer",
+        "minimum": 0
+      }
     }
   },
   "$defs": {

diff --git a/schemas/mcp/v2/submit-output.schema.json b/schemas/mcp/v2/submit-output.schema.json
@@ -0,0 +1,36 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "adf://schemas/mcp/v2/submit-output",
+  "title": "adf_submit output v2",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "schema_version",
+    "result_id",
+    "already_completed",
+    "next_required",
+    "timings_ms"
+  ],
+  "properties": {
+    "schema_version": {
+      "const": "2"
+    },
+    "result_id": {
+      "type": "string",
+      "pattern": "^result\\.[A-Za-z0-9._-]+$"
+    },
+    "already_completed": {
+      "type": "boolean"
+    },
+    "next_required": {
+      "const": true
+    },
+    "timings_ms": {
+      "type": "object",
+      "additionalProperties": {
+        "type": "integer",
+        "minimum": 0
+      }
+    }
+  }
+}
diff --git a/skill-src/adf-analyst/SKILL.md b/skill-src/adf-analyst/SKILL.md
@@ -189,8 +189,8 @@ The gap is the finding.
 ## Submit and continue
 
 Call `adf_submit` with the action id, the context digest from the action, and the
-payload. The control plane validates it, stores it, and returns the next action. Repeat
-until it hands the work to another role.
+payload. The control plane validates and stores it. After submission succeeds, call
+`adf_next` separately. Repeat until it hands the work to another role.
 
 If the orchestrator already exposes execution measurements, include them in the optional
 `execution` object: `duration_ms`, `model`, `input_tokens`, `output_tokens`, `tool_calls`,

diff --git a/skill-src/adf-builder/SKILL.md b/skill-src/adf-builder/SKILL.md
@@ -82,8 +82,9 @@ Every residual risk needs someone who accepts it and a date by which it is revis
 ## Submit and continue
 
 Call `adf_submit` with the action id, the context digest from the action, and the
-payload. The control plane validates it and returns the next action - usually a
-challenge run from a context independent of yours.
+payload. The control plane validates and stores it. After submission succeeds, call
+`adf_next` separately to receive the next action - usually a challenge run from a
+context independent of yours.
 
 If the orchestrator already knows execution time, model, token counts, tool calls, or
 retries, it may include them in the optional `execution` object. Do not add work solely to

diff --git a/skill-src/adf-challenger/SKILL.md b/skill-src/adf-challenger/SKILL.md
@@ -85,7 +85,8 @@ person who may decide.
 ## Submit and continue
 
 Call `adf_submit` with the action id, the context digest from the action, and the
-payload. The control plane validates it and returns the next action.
+payload. The control plane validates and stores it. After submission succeeds, call
+`adf_next` separately to receive the next action.
 
 If the orchestrator already knows execution time, model, token counts, tool calls, or
 retries, it may include them in the optional `execution` object. Do not run extra tracing