@abelxiaoxing/cadence 1.3.0 → 1.4.0

package/README.md

@@ -6,7 +6,7 @@
 **Cadence** 是一个面向 Pi 的规范驱动四阶段工作流扩展包，内置可恢复的私有代理编排：
 
 - `/abel-init [project-path]` — 本地、固定顺序且幂等地初始化或安全修复 OpenSpec 与 AGENTS 托管索引，不派发子代理。
-- `/abel-design <requirement> | --change <change_name>` — 使用有界只读证据包解决行为与技术决策，生成经 Gate A（WHAT）和 Gate B（HOW）批准的 canonical delivery；不启动实现 Worker，不运行产品测试，也不修改产品代码。
+- `/abel-design <requirement> | --change <change_name>` — 使用有界只读证据包解决行为与技术决策，生成绑定 Gate A 用户授权与 Gate B 系统计划证明的 canonical delivery；不启动实现 Worker，不运行产品测试，也不修改产品代码。
 - `/abel-implement <change_name>` — 在私有不可变 revision 中执行已批准的 Red-Green-Refactor DAG，累计验证全部任务后才通过一次可恢复事务写入主工作区。
 - `/abel-diagnose <problem-description>` — 独立执行“复现 → 证伪 → 失败回归 → 最小修复”，不充当 Implement 的失败路由。
 
@@ -14,7 +14,12 @@
 加载本包会注册一个私有扩展与三个包内专业 Agent；`abel_dispatch` 工具注册但保持未激活，只有用户显式调用且包来源验证通过的 Design、Implement 或 Diagnose prompt 才会激活它。
 仓库中存在 Abel 文件、OpenSpec change、AGENTS 索引或普通文本都不会启动工作流；Init 也不会激活派发工具。
 
-共享工作流规则统一收录于包内 `abel-workflow` Skill；其发现信息同样明确要求先有显式 `/abel-*` 调用。
+四个命令各自包含本阶段需要的操作指引，不再依赖共享工作流 Skill；普通任务不会从技能列表中自动选用 Abel 工作流。
+Gate、交付校验和执行状态转换由控制面代码保证。
+只有用户通过交互输入或 RPC 显式提交对应斜杠命令才允许激活；扩展生成的命令不会展开工作流。
+当前任务的 Gate 回答与续轮保持阶段有效；用户结束工作流或转向无关任务时，父模型先调用 `{"action":"finish"}`，扩展等待活动操作停止并恢复原工具，保留可恢复进度。
+此退出同样适用于 Implement，不表示完成或丢弃。
+显式调用 Init 也会先退出已有阶段。
 
 Implement 只暴露 `start`、`status`、`resume`、`rebind`、`cancel` 和 `discard` 控制命令。
 `status` 完全本地可用；相同 operation id 幂等重放，进程、会话或 Worker 更换后仍从 durable checkpoint 继续。
@@ -24,7 +29,15 @@ Design 从第一步起统一使用 `action: "design"`：新需求通过 `start(r
 Design status 将可调用的 `legalOperations` 与顶层 `packetActions` 分开；显式退出只能发送 `{"action":"finish"}`，不能伪装成 `operation: "finish"`。
 
 普通 artifact、错误 Red、transport、environment、stale、conflict、baseline 与验证失败都留在同一 Implement run 中恢复。
-累计验证发现 introduced failure 时会自动重开责任任务做有界修复；自动预算耗尽后 `resume` 复用已有 baseline 和 phase facts。
+累计验证发现 introduced failure 时会自动重开责任任务做有界修复。
+artifact、stale candidate 与 verification 纠错会将具体失败码、修复策略和可用失败身份传给下一次 Worker。
+自动恢复预算以验证义务和阶段为依据，使用独立 SQLite 事实保存；普通 `resume`、重启、回滚、换路由、任务重命名和合同改写都不能重置额度。
+执行前持久化预留工作额度；内部修复也计入同一 run 的有限资源预算。
+系统保留 baseline 和 phase facts，并明确区分缺少能力、缺少决定与恢复额度耗尽。
+Worker 可读取同一任务各阶段已批准路径的并集，并按需申请 sealed roots 内的普通文件读取；新增读取会绑定合并与最终应用的 currentness，写入和删除仍限于当前阶段；超大补丁先自动尝试紧凑的完整提交，不能完整提交时保留进度，绝不接受部分补丁。
+Design 对明确需求尽量只进行一轮集中决策：先调查仓库约定，再一起呈现目标、关键技术取舍、推荐默认值及编译授权；编译器在记录有效计划时原子生成 Gate B 证明，无需第二次用户确认。
+相同计划重编译和仅修改决策引用不会重开 Gate。
+已完成 change 的新修订从同一 root/change 的最新私有 finalized delivery 继承未变化的决策与授权；仅技术变化保留 Gate A，行为契约变化仍重新生成相应证明。
 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` 操作。
@@ -33,11 +46,16 @@ OpenSpec change 制品只能通过私有 `write-artifact` / `delete-artifact`
 Gate A/B 收据只有一套 canonical 结构，并在 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 为准。
+Design 完成主要决策后，Implement 中的新实施选择默认由父模型采用推荐方案，记录后继续执行；不再默认向用户追问。
+状态一次返回完整 `blockers`、稳定的 `decisionBatch`，并明确由父模型负责执行自动 `continuation`。
+父模型通过当前 Implement 内的 `action: "amend"` 修订同一 change、自动生成计划证明，再由普通 resume 发现并验证新交付；无需切换命令、重新确认或手动传递收据。
+交付校验失败和任务过大也能进入该修订通道，不必伪装成用户决策。
+修订有独立的持久化预算：每个 run 最多 64 次变更尝试，失败也计数，成功操作重放和只读检查不计数。
+自动修订保留 Design 目标、明确限制与验收标准；Worker 仍必须等待新计划通过完整校验才能使用新权限。
+新证明尚未就绪时，`resume` 只列为条件命令；证明就绪后可直接恢复，由控制层读取版本和哈希。
+增量修订或用户主动选择的 Design 完成后，新的 Implement 上下文都能本地发现并校验交付，继续同一 run。
+
+交互式 TUI、print、JSON 和 RPC 都保留 durable semantic state；父模型有自动继续动作时，TUI 显示 recovering，不把内部待编译状态显示成用户待确认，也不提示用户手动 resume。
 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`。
@@ -47,6 +65,36 @@ Gate 等待和可恢复暂停保持激活以接收直接后续操作。
 暂停会保留最小结构化恢复事实；完成或显式 discard 后安全清理。
 不会持久化凭据、环境值、原始 prompt、隐藏推理、完整子会话或原始模型输出。
 
+## 内部边界与运行验证
+
+扩展入口负责宿主生命周期与服务装配，交付加载和验证适配器分别由独立模块负责。
+工作流入口保留原有导出，状态机仍是唯一状态转换权威；执行服务通过类型化接口返回事实。
+测试检查模块依赖无环，以及子会话无法导入主工作区应用和 run 状态权限。
+
+新身份统一采用 UTF-16 码元排序，不依赖宿主语言环境。
+旧 workspace manifest 按已保存的条目顺序验证原身份；已绑定批准证明的历史交付可保留原有集合顺序，仍需验证原始字节哈希和私有批准事实。
+普通交付解析保持严格规范化。
+
+私有 SQLite 表结构集中声明，打开时检查必需列、类型、空值约束、主键、唯一键、外键和 STRICT 属性；已支持的补列在同一事务中执行。
+结构不符会在业务操作前拒绝，不自动重建或清空已有状态。
+
+原生 I/O 线程以预构建的纯 JavaScript 随包发布，安装到 node_modules 后无需运行时 TypeScript 加载器。
+`bun run check` 会检查线程构建产物是否与源码一致；修改相关源码后运行 `bun run build:workspace-io` 更新。
+Git 快照与工作区物化由可信本地 I/O 线程执行，不占用宿主事件循环；Git 枚举默认限制为 30 秒，支持取消，线程退出后才返回。
+物化优先使用写时复制，始终使用独立 inode 并验证复制内容。
+元数据查询只校验 manifest，实际使用产物时再校验字节；未变更文件继续由保留的祖先 revision 持有，整个 run 的私有数据仍在终态统一清理。
+
+Linux CI 单独安装并要求 Bubblewrap，验证实际隔离边界、后代进程取消，以及 Red → 状态重开 → Green → 累计验证 → Apply → Post-apply。
+可在已配置 Bubblewrap 的 Linux 主机本地运行：
+
+```sh
+CADENCE_REAL_ISOLATION=1 bun run test:target test/isolation-real.integration.test.ts
+node --experimental-strip-types scripts/benchmark-workspace.mjs 1000
+```
+
+基准输出快照、物化耗时、文件数、字节数及父事件循环延迟；耗时取决于文件系统和仓库大小。
+真实隔离测试显式启用后，缺少可用后端会失败，不会跳过。
+
 ## 安装（Install）
 
 ### 在 pi 中快速安装（推荐）
@@ -119,10 +167,14 @@ bun run test:target test/openspec-cli.test.ts test/design-delivery.integration.t
 一旦显式文件存在，它就是完整策略；损坏、缺字段或角色引用不一致会 fail closed，不会悄悄退回默认父模型。
 旧配置的顶层数字标记 `2` 会被安全迁移为当前 canonical 结构；其他编号会以专用诊断码明确拒绝。
 inherited route 声明的能力会与当前父模型真实能力取交集，不能通过夸大的配置绕过 admission。
-transport 与 malformed structural result 都只在声明的 route 顺序内做有界 failover；只有一个 route 时会原地重试一次，多个 route 时按顺序切换。
+Implement 保留 16,000 context / 8,000 output 的最低容量要求；任务复杂度估算只影响自动选择的优先级，满足最低要求的 route 仍可作为 fallback 或显式 rebind。
+transport 与 malformed structural result 都只在声明的 route 集合内做有界 failover；优先选择达到容量估算的 route，同一优先级保持声明顺序，只有一个 route 时会原地重试一次。
 相同 pause 的安全指纹与重复计数通过 `status` 暴露，凭据、URL 和原始输出仍保持私有。
 `rebind` 只能选择已获 policy 授权且能力匹配的 route，不会扩大任务边界。
 
+验证归因使用完整失败集合；大基线以哈希校验的私有 artifact 持久化，Worker 和状态只接收最多 256 条失败摘要。
+非 Vitest 失败身份由执行入口、参数和失败证据决定，不受合同显示 ID 影响。
+
 ## 跨项目验证合同（Cross-project verification）
 
 Cadence 不要求 consumer repository 提供 `check` 或 `test:target` 脚本。
@@ -186,10 +238,63 @@ bun run check:agents          # AGENTS 索引校验
 
 ```sh
 bun run verify      # check && lint && test && pack:check（发布前全套校验）
-bun run pack:check  # 真实 tarball 53 成员清单校验
+bun run pack:check  # 真实 tarball 56 成员清单校验
 bun run traceability:check   # 162 条 active Requirement/Scenario 引用精确解析且唯一归属
 ```
 
 ## 许可（License）
 
 MIT — 详见 [LICENSE](LICENSE) 与 [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md)。
+
+## 验证执行环境与明确恢复
+
+验证使用独立 HOME、Vite 缓存和报告目录；consumer 依赖保持只读。
+Vitest 的 JSON 报告与普通 stdout/stderr 分离，日志超过捕获预算只截取头尾，不终止正常测试。
+报告缺失、损坏或超限属于验证不可用，不作为产品失败基线或自动改代码的理由。
+已封存候选在环境故障后可重新验证，并在存储重开后复用；即使自动生成次数已耗尽，普通 resume 仍可只复验该候选，不启动新的补丁生成。
+非 Vitest 的 Red 证据通过有界流式匹配保留，不受日志头尾截取影响。
+完整的已批准 package-script 可包含组合命令、引号和嵌套脚本；包管理器在隔离环境中解释，manifest、lockfile 和项目配置绑定 currentness。
+配置注释和普通值不触发禁用词检查；有效的凭据或宿主执行配置仍被拒绝。
+计划已授权的 manifest/配置写入可在隔离候选中验证；未授权路径仍需匹配设计时哈希，实际入口脚本仍必须与批准命令相同，执行期间的输入漂移仍会使验证失效。
+专门的 Vitest 合同仍拥有 JSON reporter、测试数量及 Red 身份检查，复合脚本不会自动获得断言级语义。
+
+自动纠错耗尽后，普通 resume、rebind 和重启不充值。
+父代理可使用 status 返回的 `recovery.additionalAttempt`，作为 resume 的 `recovery` 字段明确追加一次尝试；失败后再次暂停，历史消耗保持。
+累计工作额度按成功接纳过的最大阶段数增长，任务重命名、重复编译及缩小后恢复原规模不增加额度。
+宿主可在启动前设置 `ABEL_WORK_MAX_UNITS`（默认 512）和 `ABEL_VERIFICATION_MAX_REPORT_BYTES`（默认 67108864）；Worker 不能调整这些资源设置。
+前者在 run 中固定，后者用于每次独立报告的有界读取。
+
+## 结构化授权与验证模式
+
+新 Design 的 Gate A 使用 `ChangeContract`：目标、稳定验收 ID 与验证义务、明确限制，以及允许的写入范围、依赖和验证模式。
+控制面保存规范化的非敏感权威值并注入计划；重排任务不能删除验收或扩大政策。
+自动 amendment 保留 Gate A，不能改写已接受的 proposal/spec 或行为决定。
+旧文本授权继续可读，其修订保留原有验证义务与保守范围。
+
+任务默认 `verificationMode: "behavior"`，继续执行 Red/Green。
+明确授权的 `mechanical` 和 `refactor` 模式采用基线与后置验证，从 Green 开始，不生成 Red 候选。
+机械修改限于文档、数据与配置文件；重构不能改写已接受的验证入口；声明公共行为变化时仍需 Red。
+全部模式保留累计验证与事务应用。
+
+验证证据现在绑定安装后的依赖内容、runner 和适配器政策。
+依赖身份采集在可取消 I/O 线程中执行；工具缓存不参与身份。
+环境漂移会暂停验证，恢复后重建基线并重验保留阶段。
+
+## 真实模型工作流评估
+
+开发仓库提供独立评估入口，消费项目和 Git 历史均在临时目录创建，结束后清理。
+默认只验证真实 Pi 的包来源与命令激活，不调用模型：
+
+```sh
+bun run eval:workflow
+bun run eval:workflow --live --scenario small-fix --output /tmp/cadence-evaluation.json
+bun run eval:workflow --live --scenario multiple-tasks
+bun run eval:workflow --live --scenario restart-recovery
+bun run eval:workflow --live --scenario missing-capability
+```
+
+`--live` 使用 Pi 当前配置的模型，也可传 `--model provider/model`；需要可用的 Provider、OpenSpec 和 Linux Bubblewrap。
+报告记录完成状态、用户介入、重复修订、耗时及宿主报告的 token/成本；最终行为另由隔离 oracle 检查。
+模型服务不可用、阶段停滞、取消与 Design 完成都不会被计为 Implement 成功。
+缺少能力的场景用于观察保留状态，不能把任意停滞当作正确恢复。
+无原始对话落盘。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abelxiaoxing/cadence",
-  "version": "1.3.0",
+  "version": "1.4.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",
@@ -40,11 +40,13 @@
     "pack:check": "node scripts/pack-check.mjs",
     "traceability:check": "node scripts/traceability-check.mjs",
     "verify": "bun run check && bun run lint && bun run test && bun run pack:check",
-    "check": "node scripts/check-syntax.mjs && tsc --noEmit",
+    "check": "node scripts/check-syntax.mjs && bun scripts/build-workspace-io.mjs --check && tsc --noEmit",
     "lint": "biome check . && rumdl check .",
     "test": "vitest run",
     "test:target": "vitest run",
-    "check:agents": "node scripts/check-agents.mjs"
+    "check:agents": "node scripts/check-agents.mjs",
+    "build:workspace-io": "bun scripts/build-workspace-io.mjs",
+    "eval:workflow": "node --experimental-strip-types scripts/evaluate-workflow.mjs"
   },
   "peerDependencies": {
     "@earendil-works/pi-coding-agent": "*",

package/prompts/abel-design.md

@@ -6,13 +6,21 @@ tags: [abel, design, openspec, PBT, evidence]
 argument-hint: "<requirement> | --change <change_name>"
 ---
 
-Load the bundled `abel-workflow` Skill and read the complete value inside `<abel-request>` without tokenizing it a second time.
+This procedure applies only when the user explicitly invokes `/abel-design`.
+Reading this file, mentioning the command, or finding OpenSpec artifacts does not activate it.
+Read the complete value inside `<abel-request>` without tokenizing it a second time.
 
 <abel-request>
 $ARGUMENTS
 </abel-request>
 
 <!-- ABEL:PROMPT:abel-design -->
+
+This stage is scoped to the invoked task.
+Direct answers and same-task continuations stay in this stage.
+If the user ends the workflow or requests an unrelated task, first send `{"action":"finish"}` to `abel_dispatch`, then handle the new task normally with the restored tools.
+Exit preserves resumable work and never means completion or discard.
+Never start another stage automatically.
 <!-- ABEL:START -->
 
 # Design outcome
@@ -20,7 +28,8 @@ $ARGUMENTS
 Design resolves product and technical decisions, collects cited evidence, and compiles one trusted delivery.
 It never launches an implementation Worker, creates a product-code candidate, applies a product diff, runs Red/Green/Refactor, or mutates the main workspace.
 
-If the requirement/change is missing, absent, ambiguous, or not unique, stop before exploration and ask one focused question.
+If no requirement can be identified or several changes cannot be distinguished, ask one focused question about the target.
+Otherwise investigate first: resolve discoverable unknowns from repository evidence and choose reversible defaults within existing authority; only unresolved substantive choices require a user decision.
 An explicit `--change <name>` resumes only that existing change; never reinterpret a misspelling as a new requirement.
 
 ## Write boundary
@@ -112,6 +121,18 @@ Do not put prompts, transcripts, hidden reasoning, credentials, environment valu
 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.
 
+Aim for one consolidated user decision round for a clear requirement.
+Investigate repository evidence before asking about implementation details.
+Present the observable contract, any substantive technical trade-offs, and your recommended defaults together; include authorization to mechanically compile and seal the plan within those choices.
+An explicit acceptance of that complete proposal covers both its behavior and the presented technical choices.
+Do not ask a second time merely because the compiler has now produced the exact task DAG or receipt.
+Ask a further focused question only when new evidence changes a substantive choice that was not covered by the accepted proposal.
+Explain that difference, retain all other decisions, and group related unresolved choices into the same question.
+Existing instructions and accepted same-task decisions are authorization evidence; do not require the user to restate them.
+Design settles the goal, main decisions, explicit constraints, and non-goals.
+Make the implementation delegation clear in the accepted proposal: the parent will choose its recommended solution for later implementation choices within those constraints, record material decisions, and continue to verified results without another selection or confirmation round.
+Do not ask the user to approve this delegation separately or attempt to enumerate every future implementation detail.
+
 Gate A approves the complete WHAT: goal, observable scenarios, failures, scope/non-goals, compatibility/migration/security policy, and success criteria.
 Before approval, present the unresolved behavior decisions together.
 After explicit approval:
@@ -129,6 +150,8 @@ The control plane generates the canonical behavior-contract hash; the returned p
 `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.
+A later behavior decision invalidates both Gates; a later technical decision or changed plan compilation invalidates Gate B only.
+Compiling identical canonical bytes after unchanged decisions preserves the existing plan revision and both Gates, even with a new operation id.
 
 ## Technical contract and ImplementPlan
 
@@ -145,10 +168,16 @@ Each task must seal:
 - AGENTS impact/target and managed-only ownership;
 - precise context sufficient for a fresh Worker without a conversation transcript.
 
+Seal the supporting repository files needed by the whole task, including callers, types, fixtures, and conventions; Workers may read the union of that task's approved phase paths.
+Writes and deletes remain phase-local.
+This task-wide read authority is part of the proposal, not an ad hoc escalation during Implement.
+Keep tasks small enough for one complete patch using compact exact replacements, and separate independent outputs during planning.
+
 Impact closure must name affected existing tests and fixtures; a suite made only from newly added tests is insufficient.
 For public UI or API work, seal the relevant route authorization, page state, API response and contract, public HTML/template/theme behavior, and an approved browser E2E check when those surfaces are affected.
 
 The plan admits only shell-free `vitest`, `package-script`, `static-check`, or ordered `steps` contracts.
+`dev-browser` is required only by an approved browser E2E contract; its absence does not block unrelated tasks or stages.
 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.
 
@@ -174,28 +203,25 @@ The canonical `ImplementPlan` contains:
 - tasks and regular-file outputs;
 - target/affected/full-suite baselines and normalized failure identity policy;
 - change-level affected, full-suite, and post-apply verification;
-- an explicit `artifactCorrection.maxAttempts` of 2-3 total candidate launches per task phase and operation, including the initial launch;
+- an explicit `artifactCorrection.maxAttempts` of 2-3 attempts for a verification obligation and phase, including the initial attempt; operation ids, rollback lineage, route changes, task renaming, and rewording do not replenish it;
 - bounded in-boundary repair policy and attribution classes `pre-existing | introduced | unresolved | environment`;
 - parent-owned `tasks.md` tracking;
 - when required, one sealed managed-block AGENTS operation per approved target, including impact, owning task ids, complete marker-bounded content, and verification.
 
-Use the shared readiness proof to require an executable static closure with no diagnostics.
+Use the code-owned readiness proof to require an executable static closure with no diagnostics.
 A write set grants authority but never proves that an output exists.
 Every absent future input must be a unique declared output from a transitive dependency.
 
 ## Gate B and trusted delivery
 
-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, 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"}}
-```
+Gate B is a code-owned plan certificate, not a second user decision round.
+The accepted proposal covers behavior, substantive technical choices, and authority to compile their realization.
+Ask about any newly discovered substantive choice before recording that changed decision; preserve all existing decisions by id instead of restating their contract text.
+`compile-plan` atomically records the validated plan and its Gate B proof after the current Gate A and substantive decisions.
+Do not request a separate Gate B confirmation or an extra approve-gate call after successful compilation.
+Finalization still validates strict OpenSpec artifacts, traceability, graph closure, and the current private proofs.
 
-Then request finalization:
+Request finalization:
 
 ```json
 {"action":"design","request":{"operation":"finalize-delivery","runId":"<run-id>","operationId":"<unique-operation>"}}
@@ -205,6 +231,8 @@ Finalization revalidates both current private Gate proofs, the stored plan, stri
 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`.
 
+Finalization serializes artifact mutation through an expiring ownership lease; never bypass a lease conflict or manually repair code-owned receipt bytes.
+
 The canonical receipts bind the Gate A and Gate B approval revisions, canonical contract hashes, and owner-private record hashes.
 `ready.yaml` references the plan path, 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.
@@ -216,15 +244,19 @@ Every other byte remains bound.
 
 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.
+A new revision of a completed change inherits decisions, Gate authority, and the canonical plan from the latest completed owner-private finalization for that same root and change.
+Evidence packets are not inherited as current observations: recheck affected repository facts.
+Technical-only changes keep Gate A; changed behavior invalidates both Gates.
 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.
+A mechanical hash, formatting, checkbox, stale path, or traceability repair regenerates only invalidated artifacts and does not reopen a user decision.
+Reopen Gate A only for changed behavior authority; ask about changed substantive technical authority only when it is not already accepted.
+The compiler regenerates Gate B as needed without a separate confirmation.
 Report the exact invalidated decision/artifact instead of restarting the whole Design process.
 
 Endpoint/transport failure in an evidence packet pauses that packet and retains other evidence.
 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.
+Report `READY_TO_IMPLEMENT` only when strict validation passes, user decisions are resolved and both private proofs are current, 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.
@@ -234,3 +266,25 @@ Never send `operation: "finish"`; exit only with `{"action":"finish"}`.
 Do not implement product code and do not archive, publish, release, stage, or commit implicitly.
 
 <!-- ABEL:END -->
+
+## Structured authority for new work
+
+Use a structured `ChangeContract` as the Gate A `contract` for new designs: `goal`, `acceptance` (stable `id`, accepted `statement`, complete structured `verification`), `constraints` (stable `id` and `statement`), and `policy` (`writeRoots`, allowed dependency names in `dependencies`, and `verificationModes`).
+Use `behavior` by default; explicitly permit `mechanical` or `refactor` only for suitable work.
+Present the accepted goal, constraints and scope together with the recommended choices.
+Do not include secrets or raw conversation in the contract.
+
+Code normalizes and hashes the object.
+The journal retains the normalized authority and injects it into compiled plans; callers do not compute hashes.
+Keep acceptance IDs and statements stable when reshaping a plan.
+Compilation rejects missing acceptance verification, outside-policy writes/dependencies, or substituted authority.
+Historical prose approvals remain readable; their existence does not authorize new scope.
+
+Mechanical tasks may write document/data/config files (`.md`, `.txt`, `.json`, `.yaml`, `.yml`, `.toml`, `.lock`).
+Refactor tasks preserve accepted verifier inputs.
+Both must declare no public behavior change and require an explicitly allowed mode in Gate A. Specify task `verificationMode` and Green (plus optional Refactor); omit Red in the draft.
+The compiler handles its internal compatibility representation.
+Runtime captures baseline and executes Green with affected, cumulative and post-apply verification, without generating a Red candidate.
+Behavior tasks continue to require Red/Green.
+
+An AGENTS checkpoint additionally requires its exact target path in `policy.writeRoots`; a broad source root does not grant AGENTS authority.

package/prompts/abel-diagnose.md

@@ -3,7 +3,9 @@ description: Diagnose and minimally repair one or more existing bugs
 argument-hint: "<problem-description>"
 ---
 
-Load the bundled `abel-workflow` Skill before work and read the complete value inside `<abel-request>` without tokenizing it a second time.
+This procedure applies only when the user explicitly invokes `/abel-diagnose`.
+Reading this file, mentioning the command, or finding OpenSpec artifacts does not activate it.
+Read the complete value inside `<abel-request>` without tokenizing it a second time.
 
 <abel-request>
 $ARGUMENTS
@@ -11,6 +13,12 @@ $ARGUMENTS
 
 <!-- ABEL:PROMPT:abel-diagnose -->
 
+This stage is scoped to the invoked task.
+Direct answers and same-task continuations stay in this stage.
+If the user ends the workflow or requests an unrelated task, first send `{"action":"finish"}` to `abel_dispatch`, then handle the new task normally with the restored tools.
+Exit preserves resumable work and never means completion or discard.
+Never start another stage automatically.
+
 The request must uniquely identify one or more existing defects.
 If required input is missing or ambiguous, stop before work and ask one focused question.
 
@@ -41,6 +49,7 @@ For each defect, keep this order:
    Run the regression after every edit and the affected suite after refactoring.
 6. Compare the full suite with baseline and require no introduced failure.
    Classify any AGENTS impact and apply only a verified managed-region update at a stable parent checkpoint.
+   Preserve every byte outside `<!-- ABEL:AGENTS-INDEX:START -->` and `<!-- ABEL:AGENTS-INDEX:END -->`; never give a Worker an AGENTS write path or put runtime/session ids, credentials, or approval state in the index.
 
 If reproduction is unavailable, root-cause evidence is insufficient, the regression cannot witness the defect, or an external capability is unavailable, return `paused` with the exact safe evidence and a concrete resume condition.
 Do not invent a repair.