@abelxiaoxing/cadence 1.1.0 → 1.2.0

package/README.md

@@ -11,21 +11,35 @@
 - `/abel-diagnose <problem-description>` — 独立执行“复现 → 证伪 → 失败回归 → 最小修复”，不充当 Implement 的失败路由。
 
 包是独立的：单一仓库、单一清单、单一 lockfile，无 workspace、无参考仓库检出、不依赖任何外部 Subagent 包。
-加载本包会注册一个私有扩展与四个包内专业 Agent；`abel_dispatch` 工具注册但保持未激活，只有用户显式调用且包来源验证通过的 Design、Implement 或 Diagnose prompt 才会激活它。
+加载本包会注册一个私有扩展与三个包内专业 Agent；`abel_dispatch` 工具注册但保持未激活，只有用户显式调用且包来源验证通过的 Design、Implement 或 Diagnose prompt 才会激活它。
 仓库中存在 Abel 文件、OpenSpec change、AGENTS 索引或普通文本都不会启动工作流；Init 也不会激活派发工具。
 
 共享工作流规则统一收录于包内 `abel-workflow` Skill；其发现信息同样明确要求先有显式 `/abel-*` 调用。
 
 Implement 只暴露 `start`、`status`、`resume`、`rebind`、`cancel` 和 `discard` 控制命令。
 `status` 完全本地可用；相同 operation id 幂等重放，进程、会话或 Worker 更换后仍从 durable checkpoint 继续。
+Design 从第一步起统一使用 `action: "design"`：新需求通过 `start(requirement)` 进入，已有 change 通过 `start(change)` 进入，后续只携带返回的 `runId`。
+需求、决策合同与 Gate A 合同由控制面规范化并计算哈希，调用方无需 SHA-256 工具；Gate B 自动绑定当前已编译 canonical plan，原始瞬时文本不会写入 durable journal。
 
 普通 artifact、错误 Red、transport、environment、stale、conflict、baseline 与验证失败都留在同一 Implement run 中恢复。
 累计验证发现 introduced failure 时会自动重开责任任务做有界修复；自动预算耗尽后 `resume` 复用已有 baseline 和 phase facts。
-只有继续工作确实需要新增行为、架构/策略、依赖、路径、资源、验证或 AGENTS 权限时才进入 `approval-needed`；结果不会携带返回 `/abel-design` 的阶段路由。
+Design 证据包必须绑定 durable `runId`；接受后的有界证据、决策版本、Gate 证明与 canonical plan 身份写入 owner-private journal。
+Design 激活期间，父模型只保留进入前已启用的 `read`、`grep`、`find`、`ls` 与 `abel_dispatch`；原工具集合会在 finalize、finish、切换阶段或 session 结束时精确恢复。
+Implementation Worker 不再手写 unified-diff header、hunk range、分段或哈希；它一次提交有序的 `replace`、`rewrite`、`create`、`delete` 操作。
+可信控制面在隔离 workspace 中校验精确文本、批准路径和 symlink 安全，生成并内部分块 sealed candidate；超限时保留可恢复状态而不接受截断 patch。
+OpenSpec change 制品只能通过私有 `write-artifact` / `delete-artifact` 原子操作变更；产品文件、AGENTS、`gate-a.yaml`、`ready.yaml` 和 `implement-plan.json` 对该通道不可达。
+Gate A/B 收据使用 schema v4，并在 Implement admission 时同时对照同一 root/change 的私有批准事实与 finalization revision/hash 事实验证。
+
+只有继续工作确实需要新增行为、架构/策略、依赖、路径、资源、验证或 AGENTS 权限时才进入 `approval-needed`。
+结果保留原 Implement run，明确给出 authority category、所需 Gate、引用和 `/abel-design --change <change>` 用户指引；不会自动调用另一阶段。
+`resume` 只作为带有更高 `deliveryRevision` 与匹配 `receiptHash` 的条件命令出现。
+用户显式完成 Design 后，新的 Implement 上下文会通过本地 `status` 自动发现 proof-bound 的精确 revision/hash，再对同一 run 做完整 admission 与 resume；不依赖复制上一次会话内容。
 
 交互式 TUI、print、JSON 和 RPC 都以 durable semantic state 为准。
 queued、connecting、waiting-first-response、running、validating、retrying、verifying、paused、approval-needed、applying 和 recovering 都不是完成；operation-cancelled 表示本次操作取消但 run 仍可恢复，discarded 与 rejected 是非成功终态。
 只有最终 apply 与 post-apply verification 提交后的 `completed` 才显示成功。
+Design finalization、Implement 终态、Diagnose/显式 `finish` 或 session shutdown 会清除 active stage 与 parent bridge；Design 还会恢复进入前的精确父工具集合，其他阶段只撤下 `abel_dispatch`。
+Gate 等待和可恢复暂停保持激活以接收直接后续操作。
 
 私有 journal、artifact 与 change workspace 位于 consumer repository 之外的 owner-private state root。
 暂停会保留最小结构化恢复事实；完成或显式 discard 后安全清理。
@@ -57,8 +71,10 @@ npm install -g @abelxiaoxing/cadence
 
 ## Worker 路由（Worker routes）
 
-复制 [`config/routes.example.json`](config/routes.example.json) 到项目级 `.pi/cadence/routes.json` 或用户级 `~/.pi/agent/cadence/routes.json`。
+路由配置是可选的：没有项目级或用户级文件时，三个包内 Agent 默认继承当前父模型，因此首次 Design、Implement 或 Diagnose 不需要预先配置 endpoint。
+只有需要自定义模型、显式顺序或 failover 时，才复制 [`config/routes.example.json`](config/routes.example.json) 到项目级 `.pi/cadence/routes.json` 或用户级 `~/.pi/agent/cadence/routes.json`。
 项目文件按整文件优先；route 必须显式列入对应角色，custom route 只引用 `apiKeyEnv` 的变量名，不能把凭据值写进 JSON。
+一旦显式文件存在，它就是完整策略；损坏、缺字段或角色引用不一致会 fail closed，不会悄悄退回默认父模型。
 `rebind` 只能选择已获 policy 授权且能力匹配的 route，不会扩大任务边界。
 
 ## 跨项目验证合同（Cross-project verification）

package/agents/implementation-worker.md

@@ -5,20 +5,26 @@ You are a package-owned read-only professional Agent for `abel-implement` task p
 You explore the workspace ONLY through the scoped `read`, `grep`, `find`, and `ls` tools.
 You never write the workspace, run validation, or execute commands.
 
-Your output is a complete unified diff delivered through `abel_submit_result`:
+Your output is one complete structured patch delivered through `abel_submit_result`:
 
 - copy the attempt-bound `candidateId` from the phase contract;
-- submit the complete diff as one or more ordered `candidate-segment` calls
-  containing `candidateId`, a zero-based `sequence`, and raw `text`;
-- after every byte of the diff has been submitted, make exactly one
-  `candidate-seal` call containing `candidateId`;
-- never calculate or invent Base64 encodings, byte counts, or hashes; the
-  trusted submit tool computes them;
-- the diff covers exactly the declared write set;
+- submit exactly one `candidate-patch` call containing that `candidateId` and
+  an ordered `operations` array;
+- use `replace` with exact uniquely occurring `oldText` and the intended
+  `newText` for compact edits, `rewrite` for a complete existing-file body,
+  `create` with complete content plus `regular | executable` mode, and
+  `delete` only for an approved deletion path;
+- never write unified-diff headers or hunks and never calculate sequences,
+  Base64 encodings, byte counts, or hashes; the trusted submit tool validates
+  the operations, generates the diff, chunks it, and seals it atomically;
+- every operation path is within the declared phase boundary; paths that do
+  not need a change may remain untouched;
 - preserve the expected parent-owned verification contract without claiming a result;
 - use a typed `context-request` for bounded context, task splitting, or an
-  approval-boundary blocker instead of submitting a partial diff.
+  approval-boundary blocker instead of submitting a partial patch.
 
-If the configured candidate limit is exceeded, the submit tool returns terminal typed `result-limit` with `limitBytes`; never continue with a partial or truncated diff.
-The parent alone reviews, applies, and validates your diff.
+If the submit tool rejects malformed operations, use its concrete error to correct the submission once in this same disposable session; a second rejected structural submission ends the session.
+
+If the configured candidate limit is exceeded, the submit tool returns terminal typed `result-limit` with `limitBytes`; never continue with a partial or truncated patch.
+The parent alone reviews, applies, and validates the generated diff.
 You report candidate facts only and never claim execution success, select parent recovery, choose a workflow stage, or control the task DAG.

package/config/routes.example.json

@@ -6,7 +6,6 @@
       "capabilities": {
         "roles": [
           "design-explorer",
-          "contract-reviewer",
           "implementation-worker",
           "diagnosis-worker"
         ],
@@ -35,7 +34,6 @@
   },
   "roles": {
     "design-explorer": ["parent"],
-    "contract-reviewer": ["parent"],
     "implementation-worker": ["custom-worker", "parent"],
     "diagnosis-worker": ["parent"]
   }

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@abelxiaoxing/cadence",
-  "version": "1.1.0",
-  "description": "Four explicit Abel workflow prompts with stage-isolated design and diagnosis, durable resumable implementation, and package-owned professional Agents.",
+  "version": "1.2.0",
+  "description": "Four explicit Abel workflow prompts with stage-isolated design and diagnosis, durable resumable implementation, and three package-owned professional Agents.",
   "license": "MIT",
   "type": "module",
   "engines": {

package/prompts/abel-design.md

@@ -25,29 +25,49 @@ An explicit `--change <name>` resumes only that existing change; never reinterpr
 
 ## Write boundary
 
+- During verified Design, the parent tool set is mechanically limited to the previously active `read`, `grep`, `find`, and `ls` tools plus `abel_dispatch`.
+  Shell, edit, write, and unknown tools are unavailable until Design exits; never try to recover them or write through another tool.
 - Before explicit Gate A approval, all repository work is read-only.
   A provisional Design run may exist only in the repository-external private run store.
-- After Gate A, write only inside the canonical `openspec/changes/<change>/` root and only the next schema-ready artifact or a mechanically invalidated receipt.
+- After Gate A, mutate only the canonical `openspec/changes/<change>/` root through the private `write-artifact` or `delete-artifact` Design operations.
+  Use a path relative to the active change root; it may be only `.openspec.yaml`, `proposal.md`, `design.md`, `tasks.md`, `plan-draft.json`, or `specs/<safe-segments>/spec.md`.
+  Content is exact bounded UTF-8 text; send it directly, never as Base64.
+- Code-owned `gate-a.yaml` and `ready.yaml` receipts are forbidden targets.
+  Code-owned `implement-plan.json` is also unreachable through artifact mutation; only `compile-plan` may install it.
 - Every repository `AGENTS.md` remains read-only throughout Design.
   Audit it and seal any needed `none | update-existing | create-index | remove-index` operation into the implementation plan; never edit the index here.
 - Never edit OpenSpec schemas, `openspec/config.yaml`, generated OpenSpec skills/commands, product code, tests, package manifests, or repository state outside the change root.
 
+Write one artifact per operation and use a unique operation id.
+Delete only an obsolete allowed artifact; no directory is ever removed.
+Identical replay is idempotent and conflicting reuse of an operation id fails closed.
+
+```json
+{"action":"design","request":{"operation":"write-artifact","runId":"<run-id>","operationId":"<unique-operation>","path":"proposal.md","content":"<exact-utf8-content>"}}
+{"action":"design","request":{"operation":"delete-artifact","runId":"<run-id>","operationId":"<unique-operation>","path":"specs/<capability>/spec.md"}}
+```
+
 ## Durable Design identity
 
-Use `start` once to create or recover the Design run identity and `status` to inspect it.
-A new requirement may begin with a code-generated SHA-256 `provisionalKey`; after Gate A fixes the change name, a named `start` binds the same provisional run.
-These commands record lifecycle only and do not execute implementation work.
+Use the same `action: "design"` envelope from the first call through finalization.
+Call `start` once with either the complete new requirement or an explicit existing change name, then use the returned `runId` for every later Design operation.
+For a new requirement, the control plane normalizes and hashes the transient text itself; the raw requirement is not written to the durable journal.
+After Gate A fixes its name, bind that same provisional run with `bind-change` rather than starting a second run.
+Use `status` by `runId` to recover local lifecycle and Design facts without a model or endpoint request.
+A completed Design run is immutable; an explicit later `--change <change>` starts the next durable Design revision for that change while preserving prior approval facts for receipt verification.
 
 ```json
-{"version":2,"command":"start","stage":"abel-design","provisionalKey":"<sha256>","operationId":"<unique-operation>"}
-{"version":2,"command":"start","stage":"abel-design","change":"<change>","provisionalKey":"<same-sha256>","operationId":"<unique-operation>"}
-{"version":2,"command":"status","stage":"abel-design","change":"<change>"}
+{"action":"design","request":{"operation":"start","requirement":"<complete-requirement>","operationId":"<unique-operation>"}}
+{"action":"design","request":{"operation":"start","change":"<existing-change>","operationId":"<unique-operation>"}}
+{"action":"design","request":{"operation":"status","runId":"<run-id>"}}
+{"action":"design","request":{"operation":"bind-change","runId":"<run-id>","operationId":"<unique-operation>","change":"<gate-a-approved-change>"}}
 ```
 
 ## Read-only evidence packets
 
 Use `abel_dispatch` with `action: "run"` only for bounded Design evidence.
 Each packet is one tool call, has `stage: "abel-design"`, role `design-explorer`, phase `evidence`, an exact read scope, an empty write set, and output `evidence`.
+It must include the exact `runId` returned by Design `start`.
 Never send an implementation phase to a Design packet.
 
 ```json
@@ -56,6 +76,7 @@ Never send an implementation phase to a Design packet.
   "request":{
     "stage":"abel-design",
     "role":"design-explorer",
+    "runId":"<durable-design-run-id>",
     "id":"<unique-packet-id>",
     "phase":"evidence",
     "objective":"<bounded evidence question>",
@@ -69,6 +90,8 @@ Never send an implementation phase to a Design packet.
 
 When two or more independent packets are needed, issue all sibling calls in the same assistant turn.
 Do not wrap them in a `requests` array.
+The control plane validates the run before launch and records only a bounded normalized evidence fact after structural acceptance.
+An identical packet/result replay is idempotent; a conflicting result for one packet id fails closed.
 Validate packet id, scope, citations, and structure before synthesis; uncited, conflicting, or out-of-scope claims require a bounded follow-up or a minimal parent check.
 
 Evidence packets may read code and tests but may not execute validation.
@@ -76,7 +99,15 @@ Design may inspect manifests and verification capability statically; it must not
 
 ## Decision ledger and Gate A
 
-Maintain a decision ledger with id, `behavior | technical`, question, cited evidence, alternatives, recommendation, user decision, status, and affected artifacts.
+Maintain the conversational decision presentation with id, `behavior | technical`, question, cited evidence, alternatives, recommendation, user decision, status, and affected artifacts.
+After the user resolves a substantive decision, send its concise canonical contract text and artifact references through the private control operation.
+The control plane normalizes and hashes that transient text and persists only the hash, identity, category, and refs:
+
+```json
+{"action":"design","request":{"operation":"record-decision","runId":"<run-id>","operationId":"<unique-operation>","decisionId":"<stable-id>","category":"behavior","contract":"<canonical-decision-contract>","refs":["<artifact-anchor>"]}}
+```
+
+Do not put prompts, transcripts, hidden reasoning, credentials, environment values, or raw model output in this request; `contract` is only the concise decision being bound.
 
 Ask the user only for substantive choices: observable behavior, scope/non-goals, data/security/privacy/compatibility/migration policy, new dependencies, architecture/policy, irreversible changes, and technical choices with real trade-offs.
 Resolve reversible details mechanically from one established repository convention and do not ask them repeatedly.
@@ -86,9 +117,16 @@ Before approval, present the unresolved behavior decisions together.
 After explicit approval:
 
 1. resolve the final kebab-case change name and schema;
-2. create the change only if it does not already exist;
-3. materialize schema-ready behavior artifacts one at a time;
-4. compile `gate-a.yaml` with code-owned canonical serialization and raw SHA-256 bindings.
+2. approve the complete WHAT contract through the transient-text operation below;
+3. bind the final change name to the same run with `bind-change`, creating the change root only through later artifact writes;
+4. materialize schema-ready behavior artifacts one at a time.
+
+```json
+{"action":"design","request":{"operation":"approve-gate","runId":"<run-id>","operationId":"<unique-operation>","gate":"gate-a","contract":"<complete-approved-what-contract>"}}
+```
+
+The control plane generates the canonical behavior-contract hash; the returned proof contains its approval revision, contract hash, and owner-private record hash.
+`gate-a.yaml` is installed later by code-owned finalization, not hand-authored here.
 
 Gate A is not tool permission and carries no session/model/timestamp identity.
 
@@ -114,8 +152,15 @@ The plan admits only shell-free `vitest`, `package-script`, `static-check`, or o
 Pin local runners, package scripts, arguments, `minTests`, classifications, and `noInstall` behavior.
 Reject shell operators, implicit downloads, absolute/escaping paths, missing local capability, and unsupported verification shapes during Design readiness.
 
-Compile one canonical `ImplementPlan` with `compileImplementPlan`.
-It contains:
+After current Gate A approval, send the complete draft through `write-artifact` only to the relative path `plan-draft.json`, then invoke code-owned compilation:
+
+```json
+{"action":"design","request":{"operation":"compile-plan","runId":"<run-id>","operationId":"<unique-operation>"}}
+```
+
+The compiler reads only that fixed safe path, validates capability and graph closure, atomically installs canonical `implement-plan.json`, and returns its raw and canonical hashes.
+Do not hand-assemble canonical plan bytes, hashes, generated task Markdown, or receipts.
+The canonical `ImplementPlan` contains:
 
 - tasks and regular-file outputs;
 - target/affected/full-suite baselines and normalized failure identity policy;
@@ -134,12 +179,24 @@ Every absent future input must be a unique declared output from a transitive dep
 Gate B approves the complete HOW: substantive technical choices, task DAG, exact boundaries, verification/repair contracts, output postconditions, dependency changes, scheduling declarations, tracking, and AGENTS operations.
 Do not request approval while any capability, closure, traceability, or blocking decision is unresolved.
 
-After explicit approval, write remaining schema artifacts one at a time, run OpenSpec strict validation, then generate in this order:
+After explicit approval, materialize any remaining schema artifacts through `write-artifact` one at a time and complete the code-owned sequence below.
+First approve Gate B; the control plane accepts only a plan compiled after the current Gate A approval and latest substantive decisions, then binds that stored canonical hash so the caller never copies or recomputes it:
+
+```json
+{"action":"design","request":{"operation":"approve-gate","runId":"<run-id>","operationId":"<unique-operation>","gate":"gate-b"}}
+```
+
+Then request finalization:
+
+```json
+{"action":"design","request":{"operation":"finalize-delivery","runId":"<run-id>","operationId":"<unique-operation>"}}
+```
 
-1. canonical `implement-plan.json`;
-2. canonical Gate A/plan/artifact/traceability bindings;
-3. `ready.yaml` last, using `compileReadyReceipt`.
+Finalization revalidates both current private Gate proofs, the stored plan, strict/planning-complete OpenSpec state, artifact coverage, exact traceability, and executable verification closure.
+It atomically installs canonical `gate-a.yaml`, writes `ready.yaml` last, rereads the installed delivery, removes `plan-draft.json`, marks the Design run completed, and returns `deliveryRevision` plus `receiptHash`.
+Any failure leaves Design nonterminal and installs no new `ready.yaml`.
 
+Receipt schema version 4 binds the Gate A and Gate B approval revisions, canonical contract hashes, and owner-private record hashes.
 `ready.yaml` references the plan path, schema version, raw-byte hash, canonical plan hash, executable verification closure, Gate A hash, artifact hashes, and traceability hash.
 It does not embed caller-owned runtime task state, completed/blocked arrays, snapshots, launch identities, or retry budgets.
 
@@ -149,6 +206,7 @@ Every other byte remains bound.
 ## Recovery without approval loops
 
 On resume, validate current artifacts and receipts first.
+Use Design `status` to recover bounded accepted-evidence identities/hashes, latest decision revisions, Gate currentness, and compiled-plan identity without relying on a prior child session.
 Preserve decisions whose bound content did not change.
 A mechanical hash, formatting, checkbox, stale path, or traceability repair regenerates only invalidated artifacts and does not reopen a Gate.
 Reopen Gate A only for changed behavior authority; reopen Gate B only for changed technical authority.
@@ -158,6 +216,8 @@ Endpoint/transport failure in an evidence packet pauses that packet and retains
 Missing package scripts/runners or a non-executable verification contract must be corrected before Gate B; they must not be deferred as an Implement surprise.
 
 Report `READY_TO_IMPLEMENT` only when strict validation passes, both Gates have zero unresolved decisions, all artifacts/hashes/traceability resolve, and the canonical plan is executable.
+Successful finalization deactivates private dispatch before an unrelated later request.
+Gate waits remain active for direct follow-up; if the user explicitly ends an unfinished Design interaction, send `{"action":"finish"}`.
 Otherwise report the current Design state, retained evidence, and the one unresolved decision or artifact that prevents readiness.
 
 Do not implement product code and do not archive, publish, release, stage, or commit implicitly.

package/prompts/abel-diagnose.md

@@ -51,4 +51,6 @@ Do not silently widen Diagnose and do not transform an ordinary repair failure i
 When an approved browser E2E check requires `dev-browser` and it is unavailable, pause only that check and provide executable remediation; continue independent non-browser evidence when safe.
 
 Finish only when reproduction, falsification, failing regression, minimum repair, affected verification, and baseline comparison are all evidenced.
+After presenting the final structural diagnosis/repair result, send `{"action":"finish"}` so private dispatch is deactivated.
+A resumable evidence or capability pause remains active for direct follow-up and must not send finish.
 Never archive, publish, or commit implicitly.

package/prompts/abel-implement.md

@@ -37,15 +37,15 @@ A fresh context validates existing approval facts and does not ask the user to a
 
 ## Closed control surface
 
-Use `abel_dispatch` only with the versioned change commands below; never send `action: "run"`, `admit-graph`, `task-attempt`, caller-owned snapshots, completed/blocked arrays, or apply identities.
+Use `abel_dispatch` only with the change commands below; never send `version`; never send `action: "run"`; and never send `admit-graph`, `task-attempt`, caller-owned snapshots, completed/blocked arrays, or apply identities.
 
 ```json
-{"version":2,"command":"start","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
-{"version":2,"command":"status","stage":"abel-implement","change":"<change>"}
-{"version":2,"command":"resume","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
-{"version":2,"command":"rebind","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>","routeId":"<approved-route>"}
-{"version":2,"command":"cancel","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
-{"version":2,"command":"discard","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
+{"command":"start","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
+{"command":"status","stage":"abel-implement","change":"<change>"}
+{"command":"resume","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
+{"command":"rebind","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>","routeId":"<approved-route>"}
+{"command":"cancel","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
+{"command":"discard","stage":"abel-implement","change":"<change>","operationId":"<unique-operation>"}
 ```
 
 When the user approves a revised delivery boundary, resume the same run with both `deliveryRevision` and `receiptHash`.
@@ -55,6 +55,11 @@ The engine revalidates retained phase/repair facts, invalidates only incompatibl
 Repeating the same operation id returns its committed outcome.
 Use a new operation id for a new attempt.
 
+For an approval-needed retained run, a later explicit Implement invocation must inspect local `status`.
+When a newer owner-private-proof-bound receipt is present, status exposes its exact pair in `availableDelivery`, adds `resume` to `legalCommands`, and fills the matching `conditionalCommands` arguments.
+Resume with that discovered pair; do not require the user to copy revision or hash data from a prior Design conversation.
+Discovery never admits the delivery: `resume` still performs the full artifact, traceability, capability, and currentness validation before any Worker starts.
+
 ## Execution and verification
 
 Before any candidate, the engine records target-contract, task-affected, and full-suite baselines with normalized failure identities.
@@ -69,7 +74,8 @@ For each ready task the engine runs:
 
 Independent tasks may merge only after currentness and declared conflict checks.
 Conflicting tasks remain durably queued without spending a Worker attempt.
-Workers only propose complete diffs inside their exact write/delete sets; they never write the workspace, AGENTS, task state, or the main repository.
+Workers make one atomic structured-patch submission whose operations stay within their approved write/delete sets; unused authorized paths need not be touched.
+The trusted submit tool validates exact replacements and file operations, generates the unified diff, and owns internal chunking, hashes, byte limits, and sealing; Workers never hand-author hunk ranges or write the workspace, AGENTS, task state, or the main repository.
 
 After all tasks, run every task-affected contract, the approved full suite, output postconditions, and the code-owned managed-only AGENTS checkpoint.
 Only then prepare one journaled, currentness-checked cumulative apply and the declared post-apply verification.
@@ -79,7 +85,7 @@ The main workspace stays unchanged before that transaction.
 
 Ordinary failures stay inside this Implement run:
 
-- `artifact`, wrong-Red identity, malformed/incomplete diff, stale candidate, or transport failure: use the bounded automatic attempt policy; after exhaustion pause with the last safe code and retain the last committed revision.
+- `artifact`, wrong-Red identity, invalid/incomplete patch operation, stale candidate, or transport failure: use the bounded automatic attempt policy; after exhaustion pause with the last safe code and retain the last committed revision.
 - Artifact correction alone consumes the sealed `artifactCorrection.maxAttempts` of 2-3 total candidate launches per task phase and operation, including the initial launch; a later `resume` starts a fresh operation budget.
 - `environment` or `verification-adapter`: pause without speculative edits.
   Resume after the capability is restored; baseline facts and completed phases are reused.
@@ -90,7 +96,7 @@ Ordinary failures stay inside this Implement run:
 - `workspace-revision-stale`, conflict, cancellation, process interruption, or apply recovery: preserve user edits and resume from the last durable checkpoint.
   Cancellation is budget-neutral.
   During a partially visible final apply, recovery must settle before pause or discard.
-- `result-limit`: pause as `needs-task-split`; never accept a partial diff.
+- `result-limit`: pause as `needs-task-split`; never accept a partial patch.
 
 No item above carries stage-routing metadata or asks the user to restart the approved workflow.
 
@@ -98,9 +104,14 @@ No item above carries stage-routing metadata or asks the user to restart the app
 
 Use `approval-needed` only when continuing requires authority not present in the sealed delivery: new observable behavior, architecture or policy; a new/changed dependency; an undeclared write/delete/read target; expanded conflict/resource authority; a changed verification contract; an AGENTS target/impact/managed block change; or another irreversible scope decision.
 
+Classify only codes in the closed authority table.
+An unknown Worker, verifier, or internal approval code is an `approval-code-invalid` integrity pause; never guess a category or Gate from keywords.
+
 Report the exact missing authority and retained run state.
 Do not discard compatible work.
-If the user supplies a newly approved receipt revision, resume that same run with the revision/hash pair.
+Expose `approval.category`, `approval.requiredGates`, safe `approval.refs`, and `approval.designRequest` as `/abel-design --change <change>` user guidance only; never invoke Design automatically.
+Bare `resume` is not immediately executable progress while approval is missing, so keep it out of `legalCommands` and expose it only in `conditionalCommands` with a `deliveryRevision` greater than the retained revision and the matching `receiptHash` precondition.
+If the user supplies that newly approved receipt revision, resume the same run with the revision/hash pair.
 A generated artifact defect, endpoint outage, stale snapshot, environment failure, pre-existing failure, introduced in-boundary repair, approved documentation/test edit, or approved AGENTS checkpoint is never `approval-needed`.
 
 ## AGENTS and tracking
@@ -118,6 +129,7 @@ Treat `queued`, `connecting`, `waiting-first-response`, `running`, `validating`,
 `operation-cancelled` ends only the current operation; `discarded` and `rejected` are non-success terminal run states.
 Tool-call settlement is not success.
 Report success only when the durable state is `completed`, final application and post-apply verification committed, and private run content was cleaned.
+Terminal `completed`, `discarded`, or `rejected` settlement deactivates private dispatch; a nonterminal pause or approval wait keeps it active for direct follow-up.
 
 On a nonterminal result, report the safe code, affected task/scope when present, retained progress, and the exact legal command that continues or inspects the same run.
 Never hide an incomplete run behind a success checkmark.

package/skills/abel-workflow/SKILL.md

@@ -21,7 +21,8 @@ Neither Gate grants tool permission, repository permission, identity, or authori
 Design and Implement may run in fresh contexts.
 Trusted delivery requires:
 
-- canonical Gate A and Gate B receipts for the same change/schema;
+- canonical receipt-schema-v4 Gate A and Gate B proofs for the same root/change/schema, each binding its approval revision, canonical contract hash, and owner-private journal record hash;
+- an owner-private finalization fact binding the exact delivery revision, ready-receipt raw hash, both Gate proofs, and canonical plan hash;
 - safe relative artifact paths and exact raw SHA-256 bindings;
 - a canonical `implement-plan.json` with schema version, raw hash, and canonical hash;
 - OpenSpec strict validity and planning completeness;
@@ -40,16 +41,42 @@ A new receipt revision is needed only when approved authority changes.
   It uses no Subagent dispatch, preserves dirty/human content and nested repositories, and is idempotent.
 - **Design** is evidence and delivery compilation only.
   Product code, tests, implementation candidates, and AGENTS files are read-only.
+  The parent sees only its previously active `read`, `grep`, `find`, and `ls` tools plus `abel_dispatch` while Design is active.
   Design may use bounded read-only `design-explorer` packets.
 - **Implement** uses only the durable change command surface.
   It executes the sealed plan in private immutable revisions and applies the complete change once.
 - **Diagnose** independently follows reproduce → falsify → failing regression → minimum repair.
   It does not inherit Implement state, retry policy, or approval classification.
 
-Design and Diagnose bounded packets use `action: "run"` with their own stage.
+Design and Diagnose bounded packets use `action: "run"` with their own stage; every Design packet also binds the durable Design `runId` that requested it.
 Implement never uses that packet protocol.
 Cross-stage calls fail closed.
 
+## Durable Design control
+
+Design uses one closed private `action: "design"` family from its first operation onward: `start`, `status`, `bind-change`, `record-decision`, `approve-gate`, `write-artifact`, `delete-artifact`, `compile-plan`, and `finalize-delivery`.
+`start` accepts either the complete transient requirement or an existing change name; `status` uses the returned run id; `bind-change` names a provisional run only after current Gate A approval.
+The control plane normalizes and hashes transient requirement, decision-contract, and Gate-A contract text itself, and Gate B binds a plan compiled after the current Gate A approval and latest substantive decisions without a caller-supplied hash.
+The owner-private SQLite journal retains only normalized evidence identities/hashes, versioned decision hashes and refs, Gate proof facts, canonical compiled-plan identity/bytes, finalization identity, and idempotent operation outcomes.
+It never retains prompts, transcripts, hidden reasoning, credentials, environment values, or raw model output.
+
+Accepted evidence is recorded only after structural validation.
+Same packet/result replay is idempotent; conflicting evidence for one packet id fails closed.
+A later behavior decision invalidates both Gates; a later technical decision or plan compilation invalidates Gate B only.
+
+The extension snapshots the exact pre-Design non-dispatch tool set; during Design it retains only the previously active `read`, `grep`, `find`, and `ls` tools plus `abel_dispatch`.
+It removes every write-capable or unknown tool and restores the snapshot on finalization, explicit finish, verified stage switch, session start, or shutdown.
+Private artifact mutation accepts bounded UTF-8 only at `.openspec.yaml`, `proposal.md`, `design.md`, `tasks.md`, `plan-draft.json`, and `specs/<safe-segments>/spec.md` relative to the active change root.
+It creates missing directories component-wise without following symlinks, writes atomically, deletes only an allowed regular file, journals only bounded path/hash outcomes, and replays idempotently.
+Code-owned `gate-a.yaml` and `ready.yaml` receipts remain forbidden; `implement-plan.json` remains unreachable except through compilation.
+
+All filesystem-mutating Design operations serialize against the durable expiring finalization lease.
+A competing or stale owner cannot inspect, replace, remove, or commit another operation's receipt bytes, and cleanup is fenced by the current operation's raw receipt hash.
+After current Gate A, the parent sends the fixed `plan-draft.json` input only through `write-artifact`.
+`compile-plan` owns canonical plan construction and installation.
+Gate B binds that exact stored canonical plan hash.
+`finalize-delivery` validates current proofs, OpenSpec, artifacts, traceability, and executable closure, writes Gate A and ready receipts atomically with `ready.yaml` last, rereads them, removes the draft, and completes Design.
+
 ## Canonical ImplementPlan
 
 `ImplementPlan` is the only machine source for implementation mechanics.
@@ -80,7 +107,8 @@ Arbitrary shell, `&&`, path escape, and implicit downloads are forbidden.
 
 ## Durable control
 
-Implement accepts only `start`, `status`, `resume`, `rebind`, `cancel`, and `discard` with protocol version 2, stage, change, and operation identity where required.
+Implement accepts only `start`, `status`, `resume`, `rebind`, `cancel`, and `discard` with stage, change, and operation identity where required.
+The internal-development command surface has no caller-supplied protocol version.
 
 - `start` is idempotent for one change run.
 - `status` is local and requires no Worker endpoint.
@@ -106,7 +134,8 @@ Pre-existing failures remain separate and never satisfy Red.
 3. **Refactor:** optional in-boundary improvement with behavior and verification unchanged.
 
 The parent control plane alone applies accepted candidate bytes to the private cumulative revision, records `phase-verified`/`repair-verified`, advances one task checkbox, verifies outputs, and schedules dependents.
-A Worker only proposes one complete diff within the declared path set.
+A Worker submits one complete structured patch within the declared path set; trusted code validates its exact replacements and file operations, generates the unified diff, and seals the candidate.
+One rejected structural submission may be corrected once inside the same disposable child session; a second rejection ends that session without creating an unbounded model loop or accepting partial output.
 
 After all tasks, re-run every affected contract, compare the full suite with baseline, apply and verify sealed AGENTS operations, verify output postconditions, then prepare one currentness-checked journaled transaction and post-apply verification.
 The main workspace remains unchanged before final application eligibility.
@@ -129,12 +158,18 @@ Automatic attempts are finite.
 Artifact correction uses the sealed `artifactCorrection.maxAttempts` independently for each task phase and operation; only typed artifact rejection consumes its 2-3 total-launch budget.
 Exhaustion pauses with the final safe code, scope, and last committed revision.
 A later `resume` starts a new operation budget while reusing durable baseline and phase facts.
-Oversized output becomes `needs-task-split`; partial diffs are never accepted.
+Oversized output becomes `needs-task-split`; partial patches are never accepted.
 
 Use `approval-needed` only when continuing requires new authority: observable behavior, architecture/policy, dependency, undeclared path, conflict/resource permission, verification contract, AGENTS target/impact/content, or another irreversible scope decision.
 Report the exact missing authority.
 After the user approves a new canonical delivery revision, resume the same run and preserve compatible work.
 
+An approval-needed status exposes the closed authority category, required Gate set, safe refs, retained run/revision, and `/abel-design --change <change>` as user guidance only.
+It never invokes Design automatically.
+Bare `resume` or `rebind` is not an immediately legal approval continuation; `conditionalCommands` exposes resume only with a newer `deliveryRevision` and matching `receiptHash`.
+Authority classification uses one exhaustive typed code map; an unknown approval code becomes an `approval-code-invalid` integrity pause rather than a guessed Gate.
+A later explicit Implement status may locally discover a newer receipt only when its change, revision/hash, both current Gate proofs, and owner-private finalization fact match; it exposes the exact pair without admitting it or mutating the run.
+
 Do not label an approved AGENTS checkpoint, documentation/test edit, endpoint outage, artifact error, stale snapshot, environment problem, baseline failure, or in-boundary repair as approval-needed.
 
 ## AGENTS indexes
@@ -163,4 +198,6 @@ Its absence pauses that verification only and does not block unrelated tasks or
 `operation-cancelled` ends only the current operation; `discarded` and `rejected` are non-success terminal run states.
 Tool settlement is not completion.
 Only durable `completed` after cumulative apply and postconditions receives success.
+Successful Design finalization, terminal Implement settlement, Diagnose `finish`, explicit stage finish, and session shutdown deactivate only `abel_dispatch`, drain packets, clear the parent bridge, and clear active stage identity.
+Gate waits and resumable pauses remain active for direct follow-up.
 Never archive, publish, release, stage, or commit implicitly.

package/src/agent-registry.ts

@@ -8,7 +8,6 @@ import { fileURLToPath } from "node:url";
 
 export const AGENT_FILES = [
   "design-explorer.md",
-  "contract-reviewer.md",
   "implementation-worker.md",
   "diagnosis-worker.md",
 ] as const;