dev-flow-deepseek 0.7.2 → 0.7.3

package/README.md

@@ -11,14 +11,14 @@ macOS arm64 Core executable。
 
 | 项目 | 当前支持 |
 | --- | --- |
-| Package | `dev-flow-deepseek@0.7.2` |
-| Bundled Core | `0.6.1` |
+| Package | `dev-flow-deepseek@0.7.3` |
+| Bundled Core | `0.6.2` |
 | Platform | macOS arm64 |
 | Node.js | `>=24` |
 | DSH | `>=0.1.0-rc.6` |
-| Release | [deepseek-v0.7.2](https://github.com/Innocent-children/dev-flow/releases/tag/deepseek-v0.7.2) |
+| Release | [deepseek-v0.7.3](https://github.com/Innocent-children/dev-flow/releases/tag/deepseek-v0.7.3) |
 
-`0.7.2` 的 normal release 已通过 registry package 安装、显式触发、Core handshake、
+`0.7.3` 的 normal release 已通过 registry package 安装、显式触发、Core handshake、
 restart/resume、`DONE`、remove、uninstall、retained reopen 和 repository-unchanged 门禁。上表
 记录已验证的精确公开版本；下面的安装命令使用 npm `latest` dist-tag 获取当前最新稳定 package。
 
@@ -89,11 +89,11 @@ dsh --profile "$PROFILE" --dump-config
 模型文本、Skill 注入或仓库内容不能替代 selector；空调用或普通讨论不会创建 Task。
 
 通过 admission 后，Adapter 首先读取 server info，验证 `standard-development`、definition
-digest、method profiles、live schemas 和恰好六个工具，再创建或恢复当前仓库的 Task。
+digest、method profiles、live schemas 和恰好十五个工具，再创建或恢复当前仓库的 Task。
 
 Task 可选择 `plain`、`spec-kit` 或 `openspec` profile。Core 管理 current node、legal transitions、
 destination、Recovery、blocker 和 terminal outcome；Adapter 负责执行当前节点工作、呈现完整 Action
-并转发 closed payload。
+并通过当前 Action 指定的提交工具转发节点结果。
 
 ## 两仓声明、Workspace Root 与可选索引
 
@@ -127,16 +127,25 @@ DeepSeek 与 Codex 共用同一 Repository Scope、scoped path、Action 和唯
 
 ## MCP 工具
 
-DeepSeek Adapter 暴露与 Codex 相同的六工具 Core catalog；在 DSH 中会使用限定后的 tool name，
+DeepSeek Adapter 暴露与 Codex 相同的十五工具 Core catalog；在 DSH 中会使用限定后的 tool name，
 但 Core tool identity 保持不变。
 
 | MCP 工具 | 作用 |
 | --- | --- |
 | `dev_flow_server_info` | 读取 Core identity、能力、process、method profile、工具目录和 DeepSeek 有效索引偏好；有效 admission 后必须首先调用。 |
 | `dev_flow_open_task` | 为 Workspace Root 内显式声明的主/附加仓库创建一个 Task，或从任一参与仓库恢复同一 Task。 |
-| `dev_flow_get_task` | 读取持久化 Task；可附带 operation probe 获取 Recovery assessment。 |
-| `dev_flow_get_next_action` | 读取当前节点的权威 Action、验证预算、method steps 和全部合法 transition。 |
-| `dev_flow_apply_action` | 使用当前 revision、Action identity、repository binding 和 closed payload 应用一次 Core 声明的 transition；允许写入的 node result 提交精确 `changed_paths` 或 `no_file_changes`，artifact references 只作为证据。输入 Schema 是单个封闭对象，`action_kind` 与 `payload` 在 Host callable 中完整可见；精确分支由 Core 校验，失败时返回字段级 `error.details[]`、`error.guard` 与一次 `correct_current_action` 纠正许可。 |
+| `dev_flow_get_task` | 读取持久化 Task；存在 Core 保存的提交时自动返回 Recovery assessment。 |
+| `dev_flow_get_next_action` | 读取当前 Action、`submission_tool`、验证预算、method steps 和全部合法 transition。 |
+| `dev_flow_submit_requirements` | 提交 REQUIREMENTS 节点结果；Core 补齐完整 Action identity 和内部 payload。 |
+| `dev_flow_submit_design` | 提交 DESIGN 节点结果。 |
+| `dev_flow_submit_tasks` | 提交 TASKS 节点结果。 |
+| `dev_flow_submit_implementation` | 提交 IMPLEMENT 节点结果。 |
+| `dev_flow_submit_test` | 提交 TEST 节点结果。 |
+| `dev_flow_submit_comprehension` | 提交 COMPREHENSION_REVIEW 节点结果。 |
+| `dev_flow_submit_refactor` | 提交 REFACTOR 节点结果。 |
+| `dev_flow_submit_delivery` | 提交 DELIVERY 节点结果。 |
+| `dev_flow_resolve_blocker` | 使用 Task ID 与 Action ID 解除已满足条件的 blocker。 |
+| `dev_flow_recover_action` | 使用 Core 保存的规范化提交恢复不确定 Action，不重新发送 payload。 |
 | `dev_flow_cancel_task` | 使用当前 revision 和明确 reason 取消一个非终态 Task。 |
 
 ## 数据与恢复
@@ -144,11 +153,14 @@ DeepSeek Adapter 暴露与 Codex 相同的六工具 Core catalog；在 DSH 中
 Task data 位于 Dev Flow 的本地数据目录，不属于 DSH plugin 配置。移除、卸载或重新安装 package
 不会删除 Task data，也不会修改目标 Git 仓库或 Codex-owned state。
 
-mutation 响应不确定时，Adapter 保留原 operation identity 与 payload，先读取 Core 的五分类
-Recovery 结论，再决定恢复动作。它不盲目重试，也不自行选择 destination。
+mutation 响应不确定时，Adapter 只保留 Task ID 与 Action ID，先读取 Core 保存的规范化提交，再调用
+`dev_flow_recover_action` 或按 advice 停止。它不重建原始 payload，也不自行选择 destination。
 
-当前 Core 只接受当前 SQLite Schema。不兼容或 pre-graph data 会返回
-`SCHEMA_UNSUPPORTED` 并保持零写入；用户可以选择新的数据目录，或在 Core 外部手工处理旧目录。
+当前 Core 只接受当前 SQLite Schema。不兼容或 pre-graph data 在普通启动时保持零写入并返回
+`reset_required`。package 携带的同一 Core 支持 `dev-flow webui start|open|status|stop|reset`；WebUI 只监听
+loopback，DeepSeek 与 Codex 复用同一进程和数据。reset 先展示精确 database/sidecar 目标，再要求当前
+target-bound token 和数据库独占访问；浏览器没有 reset mutation。界面支持简体中文/英文，首次跟随系统
+语言，手工选择只保存在浏览器。完整说明见 [WebUI](../../docs/WEBUI.md)。
 
 ## 卸载与彻底清理
 
@@ -177,7 +189,7 @@ rm -rf "$HOME/Library/Application Support/dev-flow"
 ## Package 内容
 
 Package 只包含一个 `cordis.patch.yml` layer、Adapter libraries、`dev-flow` Skill、references、
-license 和一个 darwin-arm64 Core。它不包含 source tree、tests、fixtures、用户数据或构建日志，
+license 和一个内嵌 WebUI 资产的 darwin-arm64 Core。它不包含 source tree、tests、fixtures、用户数据或构建日志，
 也不提供独立 `bin` executable。
 
 ## 维护者入口

package/lib/tool-names.mjs

@@ -6,7 +6,16 @@ export const DEV_FLOW_RAW_TOOL_NAMES = Object.freeze([
   "dev_flow_open_task",
   "dev_flow_get_task",
   "dev_flow_get_next_action",
-  "dev_flow_apply_action",
+  "dev_flow_submit_requirements",
+  "dev_flow_submit_design",
+  "dev_flow_submit_tasks",
+  "dev_flow_submit_implementation",
+  "dev_flow_submit_test",
+  "dev_flow_submit_comprehension",
+  "dev_flow_submit_refactor",
+  "dev_flow_submit_delivery",
+  "dev_flow_resolve_blocker",
+  "dev_flow_recover_action",
   "dev_flow_cancel_task",
 ]);
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dev-flow-deepseek",
-  "version": "0.7.2",
+  "version": "0.7.3",
   "private": false,
   "description": "Explicit DeepSeek Harness adapter for the Dev Flow process graph.",
   "license": "Apache-2.0",
@@ -24,6 +24,7 @@
     "test": "node --test tests/*.test.mjs",
     "test:package": "node --test tests/package-contract.test.mjs",
     "test:bundle": "node --test tests/bundle-contract.test.mjs",
+    "build:webui": "../../scripts/build-webui.sh",
     "pack:dry": "pnpm pack --dry-run --json"
   },
   "engines": {

package/skills/dev-flow/SKILL.md

@@ -49,14 +49,23 @@ call. Require one complete structured result proving:
 - `method_profiles` is exactly `plain`, `spec-kit`, `openspec` in that order;
 - `host_preferences.deepseek.codebase_memory` is present and is exactly a JSON boolean; it expresses
   a preference only and does not prove that codebase-memory is installed or available;
-- the tool catalog contains exactly these six raw names, in this order:
+- the tool catalog contains exactly these fifteen raw names, in this order:
 
 1. `dev_flow_server_info`
 2. `dev_flow_open_task`
 3. `dev_flow_get_task`
 4. `dev_flow_get_next_action`
-5. `dev_flow_apply_action`
-6. `dev_flow_cancel_task`
+5. `dev_flow_submit_requirements`
+6. `dev_flow_submit_design`
+7. `dev_flow_submit_tasks`
+8. `dev_flow_submit_implementation`
+9. `dev_flow_submit_test`
+10. `dev_flow_submit_comprehension`
+11. `dev_flow_submit_refactor`
+12. `dev_flow_submit_delivery`
+13. `dev_flow_resolve_blocker`
+14. `dev_flow_recover_action`
+15. `dev_flow_cancel_task`
 
 Any other schema, unsupported process version, absent process digest, false new-task support,
 incomplete method-profile set, missing/additional/reordered tool, or incomplete, truncated, malformed,
@@ -169,10 +178,11 @@ For an active task, perform each iteration in this order:
    Task and is reported with the declared repository key; do not shrink the Core Scope and continue.
 6. Render and perform each current method operation under the allowed effects, repository
    instructions, verification budget, and current user authority.
-7. Build only the closed payload branch named by the Action and select only a Core-returned
-   transition consistent with the actual typed node facts.
-8. Before dispatch, generate and retain one opaque request ID plus the exact Action identity and
-   payload. Submit exactly one `mcp__dev_flow__dev_flow_apply_action` mutation.
+7. Select only a Core-returned transition and build the closed input of
+   `fresh_action.submission_tool` from the actual typed node facts.
+8. Submit exactly one call to that qualified tool with `host`, `task_id`, `action_id`, the selected
+   transition, result text, artifact slots, method results and the exact node result. Core fills and
+   retains the complete Action identity and payload envelope.
 9. After a complete committed result, continue only from its authoritative next Action/outcome or a
    fresh ordinary Core read.
 
@@ -194,17 +204,16 @@ immutable profile:
 - A tool invocation is not semantic completion. Record evidence only after the work and expected
   result actually complete.
 
-Build exactly one `MethodEvidence` item for every current Action step, in the same order:
+Build one `method_results` member for every current Action step, keyed by its exact `step_id`.
+Provide only `capability` and `summary`: use the actual capability ID after capability completion,
+or an empty capability after completed ordinary work. Core adds the step identity, order and status.
 
-- actual capability completion uses `status=completed` and the actual capability ID;
-- completed ordinary work uses `status=plain_fallback` and an empty capability;
-- incomplete work uses `status=unavailable` or `status=not_run` honestly.
-
-An unavailable or not-run required step is unsatisfied, so do not call `mcp__dev_flow__dev_flow_apply_action`.
+An unavailable or not-run required step is unsatisfied, so do not call the submission tool.
 Capability output cannot substitute for the typed `node_result`, node obligations, evidence, or
-user decision. Artifact references contain only an observed role, contract path, digest, and
-summary. A single-repository Task uses an ordinary repository-relative path. A multi-repository Task
-uses `<repository-key>::<repository-relative-path>`.
+user decision. Put artifacts produced for the current node in `artifacts.current` when that member
+exists, and related method artifacts in `artifacts.other_process`. Core assigns the artifact role.
+A single-repository Task uses an ordinary repository-relative path. A multi-repository Task uses
+`<repository-key>::<repository-relative-path>`.
 
 Existing authorized spec, plan, or tasks artifacts should be reviewed, revised, or amended as
 needed, not regenerated or rerun mechanically because a semantic step appears. Resolve the active
@@ -229,84 +238,45 @@ Use the same `fresh_action` already bound from `result.task.current_action` or `
 not construct another Action view.
 
 Read [the node payload construction reference](references/node-payloads.md) from the packaged path
-`references/node-payloads.md` before every ordinary apply. The reference is construction guidance;
-the fresh Action, live `mcp__dev_flow__dev_flow_apply_action` `inputSchema`, and Core remain authoritative.
-
-Before calling `mcp__dev_flow__dev_flow_apply_action`, perform this order exactly:
-
-`fresh_action.payload_contract` identifies the payload branch that must agree with the live schema
-and packaged template.
-
-1. Rebind the complete `fresh_action` and read its `action_kind`, `current_node`, `payload_contract`,
-   `method_steps`, and all `available_transitions`.
-2. Read the live `mcp__dev_flow__dev_flow_apply_action` `inputSchema`. It is one closed object:
-   `action_kind` is a top-level `enum` of every action kind and `payload` is a closed object whose
-   `node_result` declares the union of every node result member. The schema does not narrow `payload`
-   by `action_kind`, so select the branch from `fresh_action.action_kind` plus
-   `fresh_action.payload_contract` and send only that branch's members.
-3. Open the corresponding marked template in `references/node-payloads.md`.
-4. Preserve the template's complete common envelope and `node_result` wrapper; replace only dynamic
-   values with facts from the current Task, Action, user decision, repository work, and actual check.
-5. Use current baseline revisions, work-item IDs, record IDs, acceptance, and evidence sets; never
-   guess or reuse stale values.
-6. Confirm all six common payload members exist and no seventh member exists.
-7. Confirm every branch-specific required `node_result` key exists and arrays remain arrays.
-8. Confirm every ArtifactReference role belongs to the live closed enum. Never convert a
-   `required_evidence` kind such as `repository_observation` into an artifact role. Use
-   `"artifacts": []` when no real repository-relative process artifact exists.
-9. Confirm MethodEvidence exactly matches current Action steps in ID, order, and count. Completed
-   `plain` work uses `plain_fallback` with an empty capability.
-10. Confirm the selected transition is present in the fresh Action and its reason rule matches.
-11. Confirm `destination`, `next_node`, `next_cursor`, caller classification, repository facts,
-    payload digest, raw output, and unknown members are absent.
-12. Map the mutation top-level identity from that same fresh Action.
-13. Retain the exact request and call `mcp__dev_flow__dev_flow_apply_action` once.
+`references/node-payloads.md` before every ordinary submission. The reference explains the exact
+`node_result` fields; the live schema named by `fresh_action.submission_tool` and Core remain current.
+
+Before submitting, perform this order:
+
+1. Rebind `fresh_action` and read `submission_tool`, `action_id`, `method_steps`, and all
+   `available_transitions`.
+2. Read the live schema of that exact qualified submission tool. Do not choose another submit tool.
+3. Open the matching node-result template and fill only current facts. Use current baseline
+   revisions, work-item IDs, record IDs, acceptance and evidence sets.
+4. Set `host="deepseek"`, copy only `task_id` and `action_id`, and select one returned
+   `transition_id`.
+5. Provide `summary`, the transition's required or empty `reason`, and the exact `node_result`.
+6. Put current-node artifacts in `artifacts.current` only when the live schema exposes it. Put
+   related method artifacts in `artifacts.other_process`. Each entry contains only `path`, `digest`
+   and `summary`; Core assigns the role.
+7. Build `method_results` as a closed object keyed by every returned method `step_id`. Each member
+   contains only `capability` and `summary`; Core assigns step identity, order and status.
+8. Confirm `request_id`, revision, action kind, process identity, source cursor, repository binding,
+   payload envelope, destination and recovery fields are absent.
+9. Call `fresh_action.submission_tool` once.
 
 If the live schema and packaged reference disagree, stop before mutation and report the packaging
 contract defect. Do not choose whichever shape appears more convenient.
 
-Do not derive payload keys from `required_evidence`. Do not search the repository or installed
-package, inspect a binary or log, or start another MCP server to recover a schema. The selected
-payload contains exactly `transition_id`, `summary`, `reason`, `artifacts`, `method_evidence`, and
-`node_result`; put `problem_class` exactly where that node branch's actual schema requires it. Keep
-arrays as arrays and the payload as an object. Do not add unknown fields, caller classification,
-caller digest, authoritative repository facts, command/output/configuration data, `destination`,
-`next_node`, or `next_cursor`, and do not wrap the whole request in an outer `payload`.
-
-Map every mutation top-level field from the same fresh Action:
-
-- caller-generated opaque identity -> top-level `request_id`;
-- exact value `deepseek` -> top-level `host`;
-- `fresh_action.task_id` -> top-level `task_id`;
-- `fresh_action.revision` -> top-level `revision`;
-- `fresh_action.action_id` -> top-level `action_id`;
-- `fresh_action.action_kind` -> top-level `action_kind`;
-- `fresh_action.process_id` -> top-level `process_id`;
-- `fresh_action.process_definition_digest` -> top-level `process_definition_digest`;
-- `fresh_action.current_node` -> top-level `source_cursor`;
-- `fresh_action.repository_binding_digest` -> top-level `repository_binding_digest`;
-- the selected closed payload -> top-level `payload`.
-
 ```text
-apply_arguments = {
-  "request_id": caller_request_id,
+submission_arguments = {
   "host": "deepseek",
   "task_id": fresh_action.task_id,
-  "revision": fresh_action.revision,
   "action_id": fresh_action.action_id,
-  "action_kind": fresh_action.action_kind,
-  "process_id": fresh_action.process_id,
-  "process_definition_digest": fresh_action.process_definition_digest,
-  "source_cursor": fresh_action.current_node,
-  "repository_binding_digest": fresh_action.repository_binding_digest,
-  "payload": payload_for_selected_schema_branch
+  "transition_id": selected_transition_id,
+  "summary": normalized_summary,
+  "reason": required_or_empty_reason,
+  "artifacts": artifact_slots,
+  "method_results": method_results_by_step_id,
+  "node_result": exact_current_node_result
 }
 ```
 
-`revision` remains an integer, not a string. `payload` remains an object, not a string. Do not wrap
-that request inside an outer `payload` object. For an ordinary mutation, omit `recovery_apply` or
-send `recovery_apply=null`.
-
 If Core returns `INVALID_ARGUMENT`, treat it as a complete payload-contract rejection, not transport
 uncertainty. Use the bounded-correction section only when the complete result explicitly authorizes
 `correct_current_action`; otherwise stop and report the failing contract without private data. Never
@@ -351,46 +321,17 @@ selector again; no background handling is promised.
 
 A mutation result is uncertain when it is missing, cancelled, malformed, truncated, or
 transport-failed instead of returning one complete structured result. Do not immediately repeat
-`mcp__dev_flow__dev_flow_apply_action` and do not infer the result from repository state or worktree contents.
-
-Before calling `mcp__dev_flow__dev_flow_apply_action`, retain the original `request_id`, `task_id`, `process_id`,
-`process_definition_digest`, `source_cursor`, `revision`, `action_id`,
-`action_kind`, `repository_binding_digest`, and exact closed `payload` from the same fresh action and
-the same apply dispatch. Never derive or reconstruct them from an incomplete response or partial
-output.
-
-When all required original identity values are retained, construct exactly this closed
-`operation_probe`:
-
-```json
-{
-  "operation_id": "<original apply request_id>",
-  "process_id": "standard-development",
-  "process_definition_digest": "<original process definition digest>",
-  "source_cursor": "<original source cursor>",
-  "expected_revision": 3,
-  "action_id": "<original action id>",
-  "action_kind": "<original action kind>",
-  "repository_binding_digest": "<original issuance binding digest>",
-  "payload": {}
-}
-```
-
-`operation_id` is the original apply `request_id`, never a read request ID.
-`expected_revision` is the original action `revision`. `repository_binding_digest` is the original
-issuance binding. `payload` is the exact original closed payload; when it was not completely
-retained, send JSON `null`. Never reconstruct it from partial output, repository text, or model
-memory.
+the submission tool and do not infer the result from repository state or worktree contents.
 
-Use the original `task_id` to call `mcp__dev_flow__dev_flow_get_task` with that exact probe. A stale pre-dispatch
-Task snapshot is not an authoritative read-back. Require one complete `recovery_assessment` with the
-original graph operation identity, binding relations, operation evidence, optional committed proof,
-retry flag, `next_advice`, optional unblock condition, and observation time. Stop if it is absent,
-truncated, malformed, or refers to another operation.
+Retain only the `task_id` and `action_id` used for the call. Core retains the complete normalized
+Action identity and payload before the Task transition. Call `mcp__dev_flow__dev_flow_get_task` with
+ordinary `host` and `task_id`; do not construct `operation_probe` and do not reconstruct any payload.
+Require one complete `recovery_assessment`. Stop if it is absent, truncated, malformed, or refers to
+another Action.
 
 Then call `mcp__dev_flow__dev_flow_get_next_action` for the same task before considering any mutation.
-Compare the fresh Task and next Action's revision, action identity, current node, last operation, and
-recovery advice with the retained original identity. A missing, malformed, truncated, blocker, or
+Compare the fresh Task and next Action's action identity, current node, last operation, and recovery
+advice with the retained Action ID. A missing, malformed, truncated, blocker, or
 terminal next-action result is a safe-stop, not permission to replay.
 
 DSH reconnect restores transport and tool registrations only. It never replays, retries, resumes, or
@@ -400,24 +341,17 @@ still applies, and any later user turn that dispatches those reads must contain
 Do not implement or branch on the five-class decision table. Obey only Core's complete
 `next_advice`:
 
-- `retry_current_action`: retry the ordinary current action only when Core also returns
-  `action_retry_safe=true` and the authoritative task still exposes the exact original action;
-- `submit_recovery_apply`: submit the retained original top-level operation identity and payload,
-  adding exactly `recovery_apply={"operation_id":<original request_id>,"source_cursor":<original
-  source_cursor>}`; do not add a new recovery operation ID, destination, or classification;
+- `retry_current_action`: re-perform the current Action's allowed repository work from the fresh Task
+  and Action, then call `mcp__dev_flow__dev_flow_recover_action` with exactly `host`, the retained
+  `task_id`, and the retained `action_id`; Core reuses the saved result, so do not rebuild it;
+- `submit_recovery_apply`: call that recovery tool with those same three fields immediately;
 - `read_next_action`: read the authoritative next action and continue only from that result;
-- `resolve_blocker`: stop ordinary work and handle only the Core-returned current
-  `RESOLVE_BLOCKER` action;
+- `resolve_blocker`: call `mcp__dev_flow__dev_flow_resolve_blocker` with the current blocked Action's
+  `task_id` and `action_id` after the required repository condition has been restored;
 - `stop_for_repository_drift`: report the bounded drift condition and stop.
 
 Never infer that an unlisted action is safe. A recovery read itself cannot create a blocker or adopt
-work. Only a Core-requested explicit recovery apply may do so, and its result becomes the next
-authority.
-
-If any required identity is missing or incomplete, do not construct or send an `operation_probe`;
-send no fabricated or half probe. Do not fill missing values from a partial response, do not assume
-`not_started`, and do not automatically retry. Stop and report that the Skill cannot prove the
-mutation state.
+work. If the original `task_id` or `action_id` is missing, stop; do not rebuild it from partial output.
 
 Do not branch, decide, or interpret any recovery classification and do not guess from repository
 state. Core owns classification, effect proof, blocker eligibility, and mutation directives.
@@ -425,8 +359,7 @@ state. Core owns classification, effect proof, blocker eligibility, and mutation
 A complete structured `ok=false` result is an authoritative domain error, not transport
 uncertainty. Never convert or treat that domain error as missing or transport failure. Obey Core's
 `code`, `message`, `recovery.retry_safe`, `recovery.action`, and `recovery.message`. When it reports
-`retry_safe=false` and `action=none`, stop; do not call `mcp__dev_flow__dev_flow_get_next_action` or
-`mcp__dev_flow__dev_flow_apply_action`.
+`retry_safe=false` and `action=none`, stop; do not submit or recover the Action.
 
 ## Bounded correction of the current action
 
@@ -434,16 +367,16 @@ A complete structured domain error may carry field-level detail. `error.details[
 failing member as `path`, a closed `rule`, and a fixed non-sensitive `message`. A refused transition
 may instead carry `error.guard` with the Core `guard_id` and the same failure shape.
 
-Submit exactly one corrected payload for the same Action only when every condition holds:
+Submit exactly one corrected input through the same `fresh_action.submission_tool` only when every
+condition holds:
 
 1. the original result is a complete structured Core domain error;
 2. `recovery.action` is `correct_current_action`;
 3. `recovery.retry_safe` is `true`;
-4. Task revision, action ID, process identity, source cursor, and repository binding are unchanged;
-5. the corrected request uses a new `request_id`;
-6. only members listed in `recovery.allowed_paths` change;
-7. the corrected value follows directly from the returned `rule`, with no source-code guessing;
-8. every other payload byte keeps the same meaning.
+4. the current Task still exposes the same Action ID and submission tool;
+5. only members listed in `recovery.allowed_paths` change;
+6. the corrected value follows directly from the returned `rule`, with no source-code guessing;
+7. every other submitted fact keeps the same meaning.
 
 Stop immediately when the second submission also fails. Do not submit a third candidate payload;
 report only the exact `path`, `rule`, and that the bounded correction still failed. Never report

package/skills/dev-flow/references/node-payloads.md

@@ -1,342 +1,100 @@
-# current Core contract Node Payload Construction
+# Action submission reference
+
+The current Action's `submission_tool` is the only mutation tool for that Action. Its live schema
+is the exact input contract. The Host sends current work results; Core fills revision, Action kind,
+process identity, source cursor, repository binding, artifact roles, method step identity/order/status
+and the internal payload envelope.
+
+## Common input
+
+Every ordinary submission contains exactly:
+
+- `host`, `task_id`, and `action_id`;
+- one `transition_id` returned by the current Action;
+- normalized `summary` and the transition's required or empty `reason`;
+- `artifacts`, split into the live schema's optional `current` slot and required
+  `other_process` slot;
+- `method_results`, keyed by every current `method_steps[].step_id`;
+- the action-specific `node_result`.
+
+Artifact entries contain only `path`, `digest`, and `summary`. Core assigns the role. Method
+result entries contain only `capability` and `summary`. Use the actual capability ID when one
+completed the step, otherwise use an empty capability after completed ordinary work.
+
+Do not send `request_id`, revision, Action kind, process identity, source cursor, repository binding,
+`payload`, `method_evidence`, artifact `role`, destination, or recovery fields.
+
+## Tool mapping
+
+| Action kind | Submission tool |
+| --- | --- |
+| `COMPLETE_REQUIREMENTS` | `dev_flow_submit_requirements` |
+| `COMPLETE_DESIGN` | `dev_flow_submit_design` |
+| `COMPLETE_TASKS` | `dev_flow_submit_tasks` |
+| `COMPLETE_IMPLEMENTATION` | `dev_flow_submit_implementation` |
+| `COMPLETE_TEST` | `dev_flow_submit_test` |
+| `COMPLETE_COMPREHENSION_REVIEW` | `dev_flow_submit_comprehension` |
+| `COMPLETE_REFACTOR` | `dev_flow_submit_refactor` |
+| `COMPLETE_DELIVERY` | `dev_flow_submit_delivery` |
+| `RESOLVE_BLOCKER` | `dev_flow_resolve_blocker` |
+
+## Node-result members
+
+Use the live tool schema for types and nested members. These are the closed top-level members:
+
+| Submission tool | Required `node_result` members |
+| --- | --- |
+| Requirements | `problem_class`, `baseline`, `unresolved_questions`, `changed_paths`, `no_file_changes` |
+| Design | `problem_class`, `baseline`, `findings`, `changed_paths`, `no_file_changes` |
+| Tasks | `problem_class`, `baseline`, `findings`, `changed_paths`, `no_file_changes` |
+| Implementation | `problem_class`, `task_plan_revision`, `completed_work_item_ids`, `changed_paths`, `no_file_changes`, `deviations`, `findings` |
+| Test | `problem_class`, `checks`, `failed_items`, `unverified_items`, `manual_handoff_items`, `findings`, `changed_paths`, `no_file_changes` |
+| Comprehension | `problem_class`, `explained_components`, `unresolved_questions`, `unnecessary_abstractions`, `maintenance_risks`, `user_confirmation`, `findings`, `changed_paths`, `no_file_changes` |
+| Refactor | `problem_class`, `changed_paths`, `no_file_changes`, `simplifications`, `behavior_change_intended`, `findings` |
+| Delivery | `problem_class`, `acceptance`, `automated_evidence_ids`, `manual_evidence_ids`, `test_record_id`, `comprehension_record_id`, `unverified_items`, `risks`, `findings`, `changed_paths`, `no_file_changes` |
+
+`changed_paths` and `no_file_changes` remain mutually exclusive. A single-repository Task uses
+repository-relative paths. A multi-repository Task uses
+`<repository-key>::<repository-relative-path>`.
 
-This reference helps the Host Adapter construct the one closed payload branch returned by the
-current Core Action. It is not a process definition, transition table, cursor, or authority. The
-fresh Action, the live `dev_flow_apply_action` `inputSchema`, and Core validation remain authoritative.
-
-## Construction rules
-
-Before every ordinary apply:
+Completed developer-run verification is a `source="user"` check with `command_count=0` and
+`full_suite=false`. Put only work nobody has run yet in `manual_handoff_items`.
 
-1. Bind one complete fresh Action and read `action_kind`, `current_node`, `payload_contract`,
-   `method_steps`, and every `available_transition`.
-2. Select only a transition returned by that Action. Never submit `destination`, `next_node`,
-   `next_cursor`, resume node, guard result, or caller classification.
-3. The live `dev_flow_apply_action` `inputSchema` is one closed object. `action_kind` is a top-level
-   `enum` of every action kind and `payload.node_result` declares the union of every node result
-   member, so the schema does not narrow the payload by `action_kind`. Select the branch from the
-   fresh Action's `action_kind` and `payload_contract`, send only that branch's `node_result` members,
-   and use exactly the six common payload members: `transition_id`, `summary`, `reason`, `artifacts`,
-   `method_evidence`, and `node_result`.
-   Set `reason=""` whenever the selected transition has `reason_required=false`; provide a nonempty
-   reason only when the selected transition has `reason_required=true`.
-4. `required_evidence` and `artifacts` are different concepts. `repository_observation` is a Core evidence requirement, not an ArtifactReference role. When no real repository-relative process
-   artifact exists, submit `"artifacts": []`.
-5. Allowed ArtifactReference roles are only `requirements`, `design`, `task_plan`,
-   `implementation`, `test`, `comprehension`, `refactor`, `delivery`, and `other_process`.
-   For every ArtifactReference path, work-item `expected_paths`, and node-result `changed_paths`, use
-   an ordinary repository-relative path for a single-repository Task
-   and `<repository-key>::<repository-relative-path>` for a multi-repository Task. The key must
-   already belong to the immutable Core Scope. Do not add a payload field or a second digest.
-6. Preserve the complete `node_result` branch wrapper. Every standard node result reports exact
-   `changed_paths` or `no_file_changes`; exactly one of a nonempty path list or
-   `no_file_changes=true` describes the current effect. Artifact references remain evidence and do
-   not replace this mutation envelope. Never flatten baseline fields or encode an array as prose.
-7. Submit exactly one MethodEvidence item for every current Action method step, in Action order.
-   For completed `plain` work use `"status": "plain_fallback"` and `"capability": ""`.
-8. Replace every value beginning `placeholder-` and every exemplar revision/ID with the current
-   normalized value read from the current Task/Action. Delivery acceptance, record IDs, and exact
-   evidence sets always come from the latest Task projection and are never guessed.
-9. Do not include repository facts, payload digests, raw command/output/environment data, or
-   unknown members.
-10. `INVALID_ARGUMENT` and `TRANSITION_NOT_ALLOWED` are completed Core domain rejections, never
-    transport uncertainty. When the result carries `error.details[]` or `error.guard`,
-    `recovery.action="correct_current_action"`, and `recovery.retry_safe=true`, submit exactly one
-    corrected payload for the same Action: change only the members in `recovery.allowed_paths`, derive
-    each corrected value from the returned closed `rule`, and use a new `request_id`. Stop after a
-    second failure and report the exact `path` and `rule`; never probe with a third candidate payload.
+## Requirements example
 
-<!-- node-payload-template:requirements:start -->
 ```json
 {
+  "host": "codex",
+  "task_id": "task-current",
+  "action_id": "action-current",
   "transition_id": "requirements_ready",
-  "summary": "placeholder-normalized-summary",
+  "summary": "Requirements completed.",
   "reason": "",
-  "artifacts": [],
-  "method_evidence": [
-    {"step_id": "requirements.capture", "status": "plain_fallback", "capability": "", "summary": "placeholder-capture-summary"},
-    {"step_id": "requirements.clarify", "status": "plain_fallback", "capability": "", "summary": "placeholder-clarify-summary"},
-    {"step_id": "requirements.validate", "status": "plain_fallback", "capability": "", "summary": "placeholder-validation-summary"}
-  ],
+  "artifacts": {
+    "current": [],
+    "other_process": []
+  },
+  "method_results": {
+    "requirements.capture": {"capability": "", "summary": "Captured the bounded requirements."},
+    "requirements.clarify": {"capability": "", "summary": "Resolved material questions."},
+    "requirements.validate": {"capability": "", "summary": "Validated scope and acceptance."}
+  },
   "node_result": {
     "problem_class": "none",
     "baseline": {
-      "goal": "placeholder-goal",
-      "scope": ["placeholder-scope"],
-      "out_of_scope": ["placeholder-exclusion"],
-      "acceptance_criteria": ["placeholder-acceptance-criterion"],
-      "constraints": ["placeholder-constraint"],
+      "goal": "Current goal",
+      "scope": [],
+      "out_of_scope": [],
+      "acceptance_criteria": ["Current criterion"],
+      "constraints": [],
       "assumptions": []
     },
     "unresolved_questions": [],
-    "changed_paths": ["specs/placeholder-feature/spec.md"],
-    "no_file_changes": false
-  }
-}
-```
-<!-- node-payload-template:requirements:end -->
-
-Never use `repository_observation` as an artifact role, place goal/scope beside `node_result`, or
-omit `problem_class`, `baseline`, or `unresolved_questions`.
-`unresolved_questions` is a sibling of `baseline` inside `node_result`; it is never a member of the
-closed `baseline` object.
-
-<!-- node-payload-template:design:start -->
-```json
-{
-  "transition_id": "design_ready",
-  "summary": "placeholder-normalized-summary",
-  "reason": "",
-  "artifacts": [],
-  "method_evidence": [
-    {"step_id": "design.choose_approach", "status": "plain_fallback", "capability": "", "summary": "placeholder-approach-summary"},
-    {"step_id": "design.review_complexity", "status": "plain_fallback", "capability": "", "summary": "placeholder-complexity-summary"},
-    {"step_id": "design.record_decisions", "status": "plain_fallback", "capability": "", "summary": "placeholder-decision-summary"}
-  ],
-  "node_result": {
-    "problem_class": "none",
-    "baseline": {
-      "requirements_revision": 1,
-      "approach": "placeholder-approach",
-      "components": ["placeholder-component"],
-      "decisions": ["placeholder-decision"],
-      "rejected_alternatives": ["placeholder-rejected-alternative"],
-      "complexity_justification": [],
-      "risks": []
-    },
-    "findings": [],
-    "changed_paths": ["specs/placeholder-feature/plan.md"],
-    "no_file_changes": false
-  }
-}
-```
-<!-- node-payload-template:design:end -->
-
-Use the current requirements revision. The field `complexity` is forbidden; the required field is
-`complexity_justification`, even when its value is an empty array.
-
-<!-- node-payload-template:tasks:start -->
-```json
-{
-  "transition_id": "tasks_ready",
-  "summary": "placeholder-normalized-summary",
-  "reason": "",
-  "artifacts": [],
-  "method_evidence": [
-    {"step_id": "tasks.decompose", "status": "plain_fallback", "capability": "", "summary": "placeholder-decomposition-summary"},
-    {"step_id": "tasks.map_acceptance", "status": "plain_fallback", "capability": "", "summary": "placeholder-acceptance-map-summary"},
-    {"step_id": "tasks.analyze_consistency", "status": "plain_fallback", "capability": "", "summary": "placeholder-consistency-summary"}
-  ],
-  "node_result": {
-    "problem_class": "none",
-    "baseline": {
-      "design_revision": 1,
-      "work_items": [
-        {
-          "work_item_id": "placeholder-work-item-id",
-          "summary": "placeholder-work-item-summary",
-          "expected_paths": ["src/placeholder.mjs"],
-          "acceptance_indexes": [0],
-          "verification_steps": ["placeholder-targeted-verification"],
-          "dependencies": []
-        }
-      ]
-    },
-    "findings": [],
-    "changed_paths": ["specs/placeholder-feature/tasks.md"],
-    "no_file_changes": false
-  }
-}
-```
-<!-- node-payload-template:tasks:end -->
-
-<!-- node-payload-template:implement:start -->
-```json
-{
-  "transition_id": "implementation_ready_for_test",
-  "summary": "placeholder-normalized-summary",
-  "reason": "",
-  "artifacts": [],
-  "method_evidence": [
-    {"step_id": "implementation.execute_plan", "status": "plain_fallback", "capability": "", "summary": "placeholder-execution-summary"},
-    {"step_id": "implementation.record_surface", "status": "plain_fallback", "capability": "", "summary": "placeholder-surface-summary"},
-    {"step_id": "implementation.classify_deviations", "status": "plain_fallback", "capability": "", "summary": "placeholder-deviation-summary"}
-  ],
-  "node_result": {
-    "problem_class": "none",
-    "task_plan_revision": 1,
-    "completed_work_item_ids": ["placeholder-work-item-id"],
-    "changed_paths": ["src/placeholder.mjs"],
-    "no_file_changes": false,
-    "deviations": [],
-    "findings": []
-  }
-}
-```
-<!-- node-payload-template:implement:end -->
-
-Exactly one of a nonempty `changed_paths` list or `no_file_changes=true` describes the current
-implementation result.
-
-<!-- node-payload-template:test:start -->
-```json
-{
-  "transition_id": "tests_passed",
-  "summary": "placeholder-normalized-summary",
-  "reason": "",
-  "artifacts": [],
-  "method_evidence": [
-    {"step_id": "test.run_budgeted_checks", "status": "plain_fallback", "capability": "", "summary": "placeholder-check-summary"},
-    {"step_id": "test.record_evidence", "status": "plain_fallback", "capability": "", "summary": "placeholder-evidence-summary"},
-    {"step_id": "test.classify_failure", "status": "plain_fallback", "capability": "", "summary": "placeholder-classification-summary"}
-  ],
-  "node_result": {
-    "problem_class": "none",
-    "checks": [
-      {"source": "automated", "name": "placeholder-check-name", "status": "passed", "summary": "placeholder-check-result", "command_count": 1, "full_suite": false},
-      {"source": "user", "name": "placeholder-developer-check", "status": "passed", "summary": "placeholder-developer-result", "command_count": 0, "full_suite": false}
-    ],
-    "failed_items": [],
-    "unverified_items": [],
-    "manual_handoff_items": [],
-    "findings": [],
-    "changed_paths": [],
-    "no_file_changes": true
-  }
-}
-```
-<!-- node-payload-template:test:end -->
-
-Completed developer-run verification is a `source="user"` check with `command_count=0` and
-`full_suite=false`; the human command is described in `summary` and never charged to the automatic budget.
-`manual_handoff_items` contains only bounded checks still awaiting user execution. Once the developer reports a
-completed result, record the user check and remove that item from `manual_handoff_items`.
-
-<!-- node-payload-template:comprehension-complexity:start -->
-```json
-{
-  "transition_id": "code_too_complex",
-  "summary": "placeholder-normalized-summary",
-  "reason": "placeholder-required-complexity-reason",
-  "artifacts": [],
-  "method_evidence": [
-    {"step_id": "comprehension.explain", "status": "plain_fallback", "capability": "", "summary": "placeholder-explanation-summary"},
-    {"step_id": "comprehension.identify_complexity", "status": "plain_fallback", "capability": "", "summary": "placeholder-complexity-summary"},
-    {"step_id": "comprehension.obtain_user_verdict", "status": "plain_fallback", "capability": "", "summary": "placeholder-user-verdict-summary"}
-  ],
-  "node_result": {
-    "problem_class": "code_complexity",
-    "explained_components": ["placeholder-component"],
-    "unresolved_questions": [],
-    "unnecessary_abstractions": ["placeholder-unnecessary-abstraction"],
-    "maintenance_risks": [],
-    "user_confirmation": null,
-    "findings": ["placeholder-matching-complexity-fact"],
-    "changed_paths": [],
-    "no_file_changes": true
-  }
-}
-```
-<!-- node-payload-template:comprehension-complexity:end -->
-
-<!-- node-payload-template:comprehension-passed:start -->
-```json
-{
-  "transition_id": "comprehension_passed",
-  "summary": "placeholder-normalized-summary",
-  "reason": "",
-  "artifacts": [],
-  "method_evidence": [
-    {"step_id": "comprehension.explain", "status": "plain_fallback", "capability": "", "summary": "placeholder-explanation-summary"},
-    {"step_id": "comprehension.identify_complexity", "status": "plain_fallback", "capability": "", "summary": "placeholder-complexity-summary"},
-    {"step_id": "comprehension.obtain_user_verdict", "status": "plain_fallback", "capability": "", "summary": "placeholder-user-verdict-summary"}
-  ],
-  "node_result": {
-    "problem_class": "none",
-    "explained_components": ["placeholder-component"],
-    "unresolved_questions": [],
-    "unnecessary_abstractions": [],
-    "maintenance_risks": [],
-    "user_confirmation": {"source": "user", "status": "passed", "summary": "placeholder-explicit-user-verdict-summary"},
-    "findings": [],
-    "changed_paths": [],
-    "no_file_changes": true
-  }
-}
-```
-<!-- node-payload-template:comprehension-passed:end -->
-
-No AI or method capability may create the passing user confirmation.
-
-<!-- node-payload-template:refactor:start -->
-```json
-{
-  "transition_id": "refactor_ready_for_test",
-  "summary": "placeholder-normalized-summary",
-  "reason": "",
-  "artifacts": [],
-  "method_evidence": [
-    {"step_id": "refactor.simplify", "status": "plain_fallback", "capability": "", "summary": "placeholder-simplification-summary"},
-    {"step_id": "refactor.reconcile_artifacts", "status": "plain_fallback", "capability": "", "summary": "placeholder-reconciliation-summary"},
-    {"step_id": "refactor.record_surface", "status": "plain_fallback", "capability": "", "summary": "placeholder-surface-summary"}
-  ],
-  "node_result": {
-    "problem_class": "none",
-    "changed_paths": ["src/placeholder.mjs"],
-    "no_file_changes": false,
-    "simplifications": ["placeholder-simplification"],
-    "behavior_change_intended": false,
-    "findings": []
-  }
-}
-```
-<!-- node-payload-template:refactor:end -->
-
-<!-- node-payload-template:delivery:start -->
-```json
-{
-  "transition_id": "delivery_complete",
-  "summary": "placeholder-normalized-summary",
-  "reason": "",
-  "artifacts": [],
-  "method_evidence": [
-    {"step_id": "delivery.reconcile_acceptance", "status": "plain_fallback", "capability": "", "summary": "placeholder-acceptance-summary"},
-    {"step_id": "delivery.reconcile_method_artifacts", "status": "plain_fallback", "capability": "", "summary": "placeholder-artifact-summary"},
-    {"step_id": "delivery.prepare_summary", "status": "plain_fallback", "capability": "", "summary": "placeholder-delivery-summary"}
-  ],
-  "node_result": {
-    "problem_class": "none",
-    "acceptance": [{"criterion": "placeholder-current-criterion", "status": "satisfied"}],
-    "automated_evidence_ids": ["placeholder-current-automated-evidence-id"],
-    "manual_evidence_ids": ["placeholder-current-comprehension-evidence-id"],
-    "test_record_id": "placeholder-current-test-record-id",
-    "comprehension_record_id": "placeholder-current-comprehension-record-id",
-    "unverified_items": [],
-    "risks": [],
-    "findings": [],
     "changed_paths": [],
     "no_file_changes": true
   }
 }
 ```
-<!-- node-payload-template:delivery:end -->
-
-Acceptance order/text and the automated/manual evidence lists must exactly equal the latest Core
-projection. Use only current TestRecord and ComprehensionAssessment IDs; stale or guessed IDs are
-forbidden.
-
-<!-- node-payload-template:blocked:start -->
-```json
-{
-  "blocker_id": "placeholder-current-blocker-id",
-  "condition": {
-    "kind": "restore_issuance_binding",
-    "expected_binding_digest": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
-  },
-  "observed_binding_digest": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
-}
-```
-<!-- node-payload-template:blocked:end -->
 
-For `RESOLVE_BLOCKER`, use the exact current blocker ID, stored condition, and freshly observed
-binding digest required by Core. Never submit a resume node or destination.
+For DeepSeek, use `host="deepseek"` and the qualified tool name
+`mcp__dev_flow__<submission_tool>`. All other fields remain the same.