@abelxiaoxing/cadence 1.5.3 → 1.7.0

package/README.md

@@ -95,6 +95,37 @@ Design 同任务续轮重新收紧允许的工具集合，预检失败或暂停
 Implement 只暴露 `start`、`status`、`resume`、`rebind`、`cancel` 和 `discard` 控制命令。
 `status` 完全本地可用；相同 operation id 幂等重放，进程、会话或 Worker 更换后仍从 durable checkpoint 继续。
 Design 从第一步起统一使用 `action: "design"`：新需求通过 `start(requirement)` 进入，已有 change 通过 `start(change)` 进入，后续只携带返回的 `runId`。
+
+### 升级后的私有状态重置
+
+包服务首次打开当前工作区时，比较数据库记录的包版本与当前 `package.json.version`。
+升级或旧库没有包版本标记时，自动将该工作区整个私有状态目录（SQLite/WAL、`run-data/` 下的候选工作区、产物和事务记录）移入同工作区专属备份目录，然后创建新库。
+控制库损坏导致版本不可读、版本标记无效，或控制库缺失但仍有旧资源时，也整体备份并重新初始化，不尝试修复或解释旧运行。
+可读有效版本标记与当前版本一致时保留状态；同版本号下替换代码不会触发重置，也不自动诊断其他表的损坏。
+能读取有效旧版本时，降级拒绝打开，不自动清库；旧版本不可读时不声称能够判断升降级。
+当前包版本仅接受当前发布使用的 `major.minor.patch` 格式。
+安装包时不扫描用户目录，其他工作区各自在首次打开时处理；只读 `doctor` / `runs` 不触发重置。
+
+**升级意味着旧运行不再可续用：运行、审批证明、进度、检查点和预算不继承到新库。**
+仓库代码、未提交改动及 OpenSpec 文件不变，但旧交付缺少原私有证明，不能直接视为有效交付；需要重新建立可信交付。
+备份不自动恢复或删除。
+服务响应的 `packageStateReset` 显示原因、前后版本及备份路径（不可读旧版本为 `null`），并明确 `oldRunsAbandoned: true`、`workspaceRestored: false` 和风险提示，不输出数据库内容、环境变量值或凭据。
+备份位于 `<roots>/<workspace-hash>.package-state/backup-<uuid>`，该目录中的 `lock.sqlite3` 和 `reset.json` 是协调与中断恢复记录，不应手工修改。
+
+**重置前必须退出所有旧宿主及其执行进程；数据库记录为 running 或租约未过期，不等于进程仍存活，也不再作为结算门槛。**
+新包使用工作区专属 SQLite 写锁，在整个服务生命周期内互斥；并发宿主或版本读取实际遇到 SQLite 锁时返回 `package-state-in-use`。
+该锁不能约束不认识它的旧版本或自行脱离的后代进程，重置不代表已经终止这些进程。
+旧任务、操作、租约以及缺失／损坏／未结算的事务记录一律随旧目录备份，不再要求先恢复或结算，也不由新库管理。
+**重置不会回滚主工作区：此前 apply 中断可能留下部分改动，请先检查 Git diff，再开始新工作。**
+真实权限、I/O 或备份发布失败仍报错；不能因想清库就绕过文件系统安全边界。
+状态根、控制库路径及协调路径的符号链接仍拒绝；嵌套资源链接随目录重命名保留，不跟随其目标或删除目标内容。
+备份不依赖读取旧的每运行事务数据库，包括 `run-data/<runId>/transactions/apply.sqlite3`。
+可识别的降级返回 `package-state-downgrade-blocked`。
+中断后同版本重试按持久化意图继续，不重复备份；未完成重置时不允许换另一个目标版本。
+目录刷新沿用下文 Windows 能力边界，不声称 Windows 断电场景具备 POSIX 目录持久化保证。
+
+底层 `RunStore` 仍保留经结构校验的旧 `schema_meta` v2/v4 原子迁移，供原版本恢复和独立存储调用使用；包服务的上述重置策略优先执行。
+v2 迁移只补齐可空凭证字段且保持 `NULL`，不伪造审批；损坏或部分升级仍拒绝打开，迁移失败整体回滚。
 需求、决策合同与 Gate A 合同由控制面规范化并计算哈希，调用方无需 SHA-256 工具；Gate B 自动绑定当前已编译 canonical plan，原始瞬时文本不会写入 durable journal。
 `validate-plan-draft` 可在 `compile-plan` 前只读运行同一套编译检查，并以结构化 `taskId` / phase / field / verification 诊断定位问题；Design finalization 的安全诊断码也会进入错误详情与可展开 TUI，而不再只显示统一失败标题。
 随包提供的 [单任务计划示例](config/plan-draft.example.json) 展示精简 PlanDraft 和结构化 Gate A 合同；按实际仓库替换示例中的路径、证据与验证命令。
@@ -119,6 +150,18 @@ artifact、stale candidate 与 verification 纠错会将具体失败码、修复
 自动恢复预算以验证义务和阶段为依据，使用独立 SQLite 事实保存；普通 `resume`、重启、回滚、换路由、任务重命名和合同改写都不能重置额度。
 执行前持久化预留工作额度；内部修复也计入同一 run 的有限资源预算。
 系统保留 baseline 和 phase facts，并明确区分缺少能力、缺少决定与恢复额度耗尽。
+任务 `baselineVerification` 只读取 run 的原始不可变快照；只有 affected 输入均为原始安全普通文件时，编译器才允许省略并推导它。
+新增 Red 测试仍完整参与阶段、affected、累计和最终验收。
+独立任务共享四个执行槽位，单个任务结算后立即补位；其他 run 释放容量也会唤醒排队工作。
+局部 baseline 或能力缺失只阻塞相关任务及依赖者，完整验收和事务 apply 保留全局屏障。
+Design 的 `summary.parallelism` 展示最多四项互不冲突的初始任务组、明确标为后续兼容关系的任务对、producer 等待、串行原因和全局验证屏障。
+初始组假设共享槽位可用；实际运行仍检查容量、能力和 currentness。
+`summary.implementation` 同时展示已接受的验收/限制 ID、技术修订可用的写入范围、依赖与验证模式，让 Design 能检查后续修复是否有足够权限；摘要本身不授予权限，也不宣称运行环境已就绪。
+Design 集中解决用户决策和已知的外部前提，按受影响模块及必要集成修复确定政策范围，按精确文件划分初始任务。
+Implement 以已接受目标为持续执行目标：父代理负责范围内的推荐决策、拆分、修复、重新编译和继续执行；调度器持续填充四个共享槽位。
+父代理在仍有可执行后续动作时提前结束回合，宿主会重新读取同一 change 的本地状态，并接续同阶段工作，不需要用户再次发送“继续”。
+取消、退出、模型中断、待处理用户消息和无进展保护会阻止自动接续；接续不扩大授权、不重置恢复额度，也不将缺少凭据或服务的外部阻塞伪报为完成。
+进程中断后的 run 在用户再次显式调用 Implement 时提供同一 run 的恢复动作；已有 apply journal 的结算不消耗 Worker 额度，仍由引擎控制。
 Worker 可读取同一任务各阶段已批准路径的并集，并按需申请 sealed roots 内的普通文件读取；新增读取会绑定合并与最终应用的 currentness，写入和删除仍限于当前阶段；超大补丁先自动尝试紧凑的完整提交，不能完整提交时保留进度，绝不接受部分补丁。
 Design 对明确需求尽量只进行一轮集中决策：先调查仓库约定，再一起呈现目标、关键技术取舍、推荐默认值及编译授权；编译器在记录有效计划时原子生成 Gate B 证明，无需第二次用户确认。
 相同计划重编译和仅修改决策引用不会重开 Gate。
@@ -134,7 +177,10 @@ Gate A/B 收据只有一套 canonical 结构，并在 Implement admission 时同
 Design 完成主要决策后，Implement 中的新实施选择默认由父模型采用推荐方案，记录后继续执行；不再默认向用户追问。
 状态一次返回完整 `blockers`、稳定的 `decisionBatch`，并明确由父模型负责执行自动 `continuation`。
 父模型通过当前 Implement 内的 `action: "amend"` 修订同一 change、自动生成计划证明，再由普通 resume 发现并验证新交付；无需切换命令、重新确认或手动传递收据。
-交付校验失败和任务过大也能进入该修订通道，不必伪装成用户决策。
+父控制面从原始快照证明的 baseline 输入缺陷和任务过大可以进入该修订通道，不必伪装成用户决策。
+单独的错误码、hash/receipt 异常、不安全路径和未知错误不授予修订权限。
+相同 baseline 合同、输入和环境下的失败会持久保留，重复 resume 不再执行相同失败检查或启动 Worker；可观测前提变化后才在原预算内恢复。
+baseline 专属修订保留兼容的已提交阶段、任务成果与原 run。
 修订有独立的持久化预算：每个 run 最多 64 次变更尝试，失败也计数，成功操作重放和只读检查不计数。
 自动修订保留 Design 目标、明确限制与验收标准；Worker 仍必须等待新计划通过完整校验才能使用新权限。
 新证明尚未就绪时，`resume` 只列为条件命令；证明就绪后可直接恢复，由控制层读取版本和哈希。
@@ -294,6 +340,18 @@ CLI 的其他版本必须满足相同 JSON 协议；新增支持版本应加入
 
 **此矩阵不代表原生 Implement 隔离已全平台可用。**
 默认隔离后端仍为 Linux Bubblewrap；Windows/macOS 的原生隔离、ACL 与完整文件应用语义需要单独实现和验收，缺少隔离能力时保持暂停，不降级为主工作区直接执行。
+
+目录持久化在 Windows 上单独处理：仅当已打开的目录句柄执行 `fsync` 返回 `EPERM` 时，标记为不支持目录刷新屏障。
+普通文件仍须在发布前成功 `fsync`；目录打开/关闭、权限、其他 I/O 及 POSIX 目录刷新错误不会被忽略。
+内容哈希校验、原子发布、SQLite 事务意图、CAS 与回滚记录继续生效；Windows 的进程中断恢复不等于 POSIX 目录屏障提供的断电持久性保证。
+
+以下是底层同版本恢复语义，不是跨包版本保留运行的承诺；跨版本以“升级后的私有状态重置”策略为准，旧运行会被放弃而非恢复。
+若同版本运行在存储异常后停留于 `running / phase-running`，请先停止旧宿主，完整备份 owner-private state root（含 SQLite、WAL 及 artifacts/workspaces），再加载同版本修复。
+用原工作区和原 state root 查询同一 change；重新打开时会在确认无有效执行租约后将遗留运行转为 `paused / operation-interrupted`，apply 中断则进入 `recovering`。
+按本地 `status` 提供的 `resume` 继续原运行，不需要重新 Design、重新 start、discard 或手动修改数据库。
+恢复保留交付绑定、阶段检查点、验证证据和已消耗预算，不返还预算、不伪造 Red/Green 结果；下一次执行仍须满足原有环境和隔离要求。
+不要为绕过 Windows 隔离限制而直接移动状态目录或更改工作区身份。
+
 可信 Linux 项目可以显式选择上面的 `local-trusted` 候选目录执行模式。
 
 本地可用 `CADENCE_REAL_OPENSPEC=1` 启用真实 CLI 测试（Windows 可用 PowerShell 设置 `$env:CADENCE_REAL_OPENSPEC = "1"`），然后运行：
@@ -420,6 +478,8 @@ Vitest 的 JSON 报告与普通 stdout/stderr 分离，日志超过捕获预算
 
 自动纠错耗尽后，普通 resume、rebind 和重启不充值。
 父代理可使用 status 返回的 `recovery.additionalAttempt`，作为 resume 的 `recovery` 字段明确追加一次尝试；失败后再次暂停，历史消耗保持。
+`continuation.kind: "inspect-recovery"` 将已知故障交给父代理调查并选择具体修复策略；它是指导信息，不是新的 dispatch action。
+纠错耗尽时，`conditionalCommands` 明确给出需要原样携带恢复凭据的 resume 条件；有证据支持的计划调整仍需经过同一 change 的编译和验证。
 累计工作额度按成功接纳过的最大阶段数增长，任务重命名、重复编译及缩小后恢复原规模不增加额度。
 宿主可在启动前设置 `ABEL_WORK_MAX_UNITS`（默认 512）和 `ABEL_VERIFICATION_MAX_REPORT_BYTES`（默认 67108864）；Worker 不能调整这些资源设置。
 前者在 run 中固定，后者用于每次独立报告的有界读取。

package/config/plan-draft.example.json

@@ -57,6 +57,9 @@
           }
         }
       },
+      "baselineVerification": {
+        "use": "add-test"
+      },
       "affectedVerification": {
         "use": "add-test"
       },

package/config/plan-draft.multiple-tasks.example.json

@@ -93,6 +93,9 @@
           }
         }
       },
+      "baselineVerification": {
+        "use": "add-test"
+      },
       "affectedVerification": {
         "use": "add-test"
       },
@@ -196,6 +199,33 @@
           }
         }
       },
+      "baselineVerification": {
+        "kind": "steps",
+        "id": "double-affectedVerification",
+        "classification": "expected-green",
+        "steps": [
+          {
+            "kind": "static-check",
+            "id": "double-green-add-affectedVerification",
+            "runner": {
+              "kind": "node",
+              "script": "test/add.test.mjs"
+            },
+            "args": [],
+            "classification": "expected-green"
+          },
+          {
+            "kind": "static-check",
+            "id": "double-green-own-affectedVerification",
+            "runner": {
+              "kind": "node",
+              "script": "test/double.test.mjs"
+            },
+            "args": [],
+            "classification": "expected-green"
+          }
+        ]
+      },
       "affectedVerification": {
         "kind": "steps",
         "id": "double-affectedVerification",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abelxiaoxing/cadence",
-  "version": "1.5.3",
+  "version": "1.7.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",

package/prompts/abel-design.md

@@ -144,6 +144,14 @@ 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.
 
+Design owns the user decision boundary for this change.
+Discuss the outcome and real constraints here, including likely repair scope, dependency choices, environment prerequisites that require the operator, and any irreversible operation.
+Treat the task DAG as the initial execution strategy: the parent may revise its technical decomposition, supply context, repair failures, and recompile within the accepted contract during Implement.
+Do not make incidental file lists or a guessed decomposition into product constraints.
+Choose `policy.writeRoots` to cover the affected modules, their regression tests, and necessary integration repairs justified by repository evidence; keep initial phase writes precise.
+An explicit user authorization for repository-wide work may be represented by `"."`; never infer it from convenience, and still name any authorized AGENTS target exactly.
+Set dependency and verification-mode policy from the accepted choices, so known requirements do not become authorization requests during execution.
+
 ## 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`).
@@ -235,7 +243,7 @@ Each task must seal:
 - stable id, objective, exact dependencies and edge reasons;
 - exact phase-local read/write/delete paths and output producers;
 - Red, Green, optional Refactor structured verification and exact verification inputs;
-- task-affected and repair verification contracts;
+- an original-revision `baselineVerification`, task-affected and repair verification contracts;
 - conflicts, resources, verification locks, dependency changes, impact closure, and existing-test evidence;
 - AGENTS impact/target and managed-only ownership;
 - precise context sufficient for a fresh Worker without a conversation transcript.
@@ -244,6 +252,25 @@ Seal the supporting repository files needed by the whole task, including callers
 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.
+Give each dependency its reason in task context: a consumed producer output, an unresolved shared interface, or a concrete resource constraint.
+Use `summary.parallelism.initiallyRunnableGroup` to inspect the bounded, conflict-free initial group, assuming shared slots are available.
+The labelled static pairs describe eventual compatibility; inspect producer waits, all serialization causes, and global verification barriers before claiming concurrency.
+Runtime capacity and capabilities still require Implement admission.
+Keep reads precise so unrelated module tasks can run concurrently; shared interface or manifest changes need one explicit owner and dependent consumers.
+
+For work spanning independent modules, plan independent tasks that can fill the four shared Worker slots, followed by dependent integration where necessary.
+Do not chain tasks merely to prescribe an order or put every task behind the same resource label.
+Do not split a small task solely to increase Worker count.
+Use `summary.implementation` to inspect the accepted amendment policy and stable acceptance/constraint IDs alongside the initial phase permissions.
+Its `review-only` authority and `runtimePrerequisites: "not-assessed"` are explicit: it neither grants broader scope nor certifies a working environment.
+Before finalizing, resolve known missing runners, supported execution profile, required services, and credentials with the user in Design when repository evidence cannot resolve them.
+Record the observed prerequisites and recovery approach in `design.md`; retain the existing prohibition on executing product tests during Design.
+Do not describe a known unavailable prerequisite as ready for unattended execution.
+
+Task `baselineVerification` may be omitted only when every affected input is a safe regular file in the original snapshot; the compiler then projects that exact affected contract.
+For a new Red test, declare its output and keep it in the phase, affected, repair, cumulative and post-apply contracts.
+Bind the original baseline to executable existing regression coverage or an existing full suite, without creating that future test in the baseline or dropping acceptance.
+An existing file which is also a future modification output remains readable at its original bytes for baseline verification.
 
 Impact closure must name affected existing tests and fixtures; a suite made only from newly added tests is insufficient.
 In `impactClosure.relatedTests`, `current-task` means this task edits that test: its path must appear in a phase's `write` set.
@@ -277,7 +304,7 @@ Do not hand-assemble canonical plan bytes, hashes, generated task Markdown, or r
 The canonical `ImplementPlan` contains:
 
 - tasks and regular-file outputs;
-- target/affected/full-suite baselines and normalized failure identity policy;
+- target-contract identities, task original-baseline contracts, full-suite baseline and normalized failure identity policy;
 - change-level affected, full-suite, and post-apply verification;
 - 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`;
@@ -286,7 +313,10 @@ The canonical `ImplementPlan` contains:
 
 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.
+Every absent future input must be a unique declared output available at its consumer's phase: the same task's current/prior phase, or a completed transitive dependency.
+Affected/repair consume final task outputs; cumulative and post-apply consume outputs at their global barriers.
+A deletion must have a causally later rewrite before consumption.
+Original baseline contracts cannot consume future outputs.
 
 ## Gate B and trusted delivery
 

package/prompts/abel-implement.md

@@ -40,6 +40,16 @@ Do not end the turn merely because a control call returns a nonterminal state.
 Follow its parent-owned continuation until verified completion or a concrete blocker that cannot be resolved within available capabilities and budgets.
 Keep routine decisions and repairs internal; give brief progress updates during sustained work and include material implementation choices in the final result.
 
+Treat the accepted goal as active work until the control plane proves completion.
+An internal pause is a checkpoint for the parent to investigate, repair, or replan, not the end of the user's request.
+Design owns product decisions; Implement owns execution and chooses compliant technical solutions without handing those choices back to the user.
+Use all available independent Worker slots through the engine's DAG scheduler; do not replace it with serial manual task calls or launch Workers outside the admitted graph.
+If the parent ends a turn while an actionable continuation remains, the host can schedule another same-stage parent turn after rereading local status.
+That continuation is internal workflow guidance, not a new user request or additional approval.
+Follow its current control-plane evidence; never replay an old command solely because it appeared in an earlier reminder.
+Repeated status reads and identical failed operations are not progress: change the recovery strategy, gather concrete evidence, or preserve the run with the specific remaining external condition.
+Explicit cancellation, stage exit, or an interrupted model turn stops automatic continuation.
+
 ## Trusted admission
 
 Before the first Worker launch, load the current `ready.yaml` and referenced canonical `implement-plan.json`; verify both current owner-private Gate proofs and the finalization fact binding the exact delivery revision, receipt hash, and canonical plan hash, plus the Gate A binding, raw and canonical hashes, OpenSpec strict/planning status, Requirement → Scenario → Verification → Task traceability, capability closure, exact path/output contracts, repair policy, tracking contract, and sealed AGENTS operations.
@@ -79,8 +89,12 @@ Discovery never admits the delivery: `resume` still performs the full artifact,
 
 ## Execution and verification
 
-Before any candidate, the engine records target-contract, task-affected, and full-suite baselines with normalized failure identities.
+Before a task's candidate, the engine records that task's explicit original-baseline contract and the global full-suite baseline with normalized failure identities.
+Task baselines are collected on demand and cached by contract, original revision, owner and environment; a local unavailable baseline does not require unrelated tasks to stop.
+The immutable original snapshot remains the source after amendments.
+Later main-workspace additions cannot repair its missing inputs.
 A pre-existing failure remains separate and never satisfies Red or becomes evidence that this change caused it.
+Only comparable verification obligations can reuse failure attribution; new tests remain part of affected, cumulative and final acceptance.
 
 For each ready behavior task the engine runs:
 
@@ -90,6 +104,9 @@ For each ready behavior task the engine runs:
 4. Parent-owned task completion and exactly one `tasks.md` checkbox update in the private cumulative revision.
 
 Independent tasks may merge only after currentness and declared conflict checks.
+The engine shares four execution slots across runs and refills them after individual task settlement, including capacity released by another run.
+Dependencies consume only completed producer tasks and valid outputs.
+Cancellation and close wait for every launched operation to settle before resources are released.
 Conflicting tasks remain durably queued without spending a Worker attempt.
 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.
@@ -111,10 +128,13 @@ Ordinary failures stay inside this Implement run:
   A run shares one cumulative work budget: 24 plus three units per largest admitted phase count, bounded by the host limit captured at run start (default 512).
   Recompiling, renaming or returning to a previous plan size never adds credit; a genuinely larger admitted decomposition may increase capacity without refunding consumption.
   Execution reserves work durably before launch, including nested repair proposals; restart and post-launch cancellation do not refund consumed work.
-- `environment` or `verification-adapter`: the executor pauses without speculative edits.
+- `environment` or `verification-adapter`: the affected task pauses while safe independent work continues; required global verification remains a completion barrier.
   The parent inspects local diagnostics and restores available prerequisites using existing authorized capabilities, then resumes; baseline facts and completed phases are reused.
   Do not request user input for a prerequisite the parent can restore.
   Missing external credentials or unavailable services are reported only after local alternatives have been checked.
+  A retained baseline prerequisite identifies its owner, original revision, input/producer or capability, and minimum recovery condition.
+  Repeating resume with the same failure prerequisites does not repeat the failed verification or launch a Worker.
+  A changed observable environment or valid revised contract permits bounded recovery within the retained budgets.
 - `pre-existing`: keep as baseline evidence.
   It does not authorize a code change and does not fail completion unless the change worsens it.
 - `introduced` in a task-affected contract: reopen the owning task as `repairable`, perform the minimum bounded repair inside its approved paths, record `repair-verified`, and re-run attribution automatically.
@@ -141,6 +161,12 @@ A rebind may repair endpoint configuration but does not grant a new incident bud
 If a revised delivery already exists, local status also discovers its exact revision/hash for an exhausted run; resume with `availableDelivery` without asking the user to copy receipt data.
 When `recovery.additionalAttempt` is present, the parent may make a concrete decision to retry once within remaining work capacity.
 Copy that object into an ordinary resume request's optional `recovery` field; do not invent incident keys or failure sequences.
+When `continuation.kind` is `inspect-recovery`, use its bounded diagnostic and recommendation to choose the next recovery strategy before issuing another execution command.
+This object has no dispatch `action` or `command`; never submit it as tool arguments.
+For an exhausted incident, `conditionalCommands` supplies a resume conditional on the exact retained recovery grant even though ordinary unqualified resume is unavailable.
+An evidence-bound correction batch may also permit revising the task decomposition or context within the accepted contract.
+Choose a concrete correction from the retained failure, preserve completed work, and resume only after the relevant prerequisites or compiled delivery are valid.
+For a capability or route investigation, use the available parent tools to establish what changed before resuming; do not repeatedly probe an unchanged prerequisite.
 The default reason is `parent-directed-retry`; `route-changed` and `context-extended` additionally require control-plane evidence.
 This consumes one launch without resetting automatic correction history; another failure pauses again.
 Do not turn the availability of this option into an unconditional retry loop or another user approval round.
@@ -159,14 +185,17 @@ The parent resolves new implementation choices with its recommended option under
 `approval-needed` is an internal requirement to compile updated authority before a Worker continues, not a request for user input.
 `decisionBatch.resolution` identifies the parent as decision owner and `continuation` identifies the automatic next action.
 Follow it in this turn.
-`owner` and `automatic` are status metadata, not tool arguments.
+`owner`, `automatic`, `kind`, `reason`, and `metadata` are status guidance, not tool arguments.
 For amendment use the exact `decisionBatch.continuation` envelope plus `request`; for resume send the closed command envelope with a new operationId.
 A changed batch must cite the new evidence; never ask separately for each task's copy of the same decision.
 Retain the Implement stage and original run.
 `decisionBatch.continuation` supplies the exact `action: "amend"`, change, and batchId for the narrow private artifact revision channel.
 After selecting the recommended solution, use that envelope with a `request` containing the existing closed Design artifact operations: start the same change, retain inherited decisions, record the parent-selected changes, write the required change artifacts, compile, and finalize.
 This is implementation delegation from the accepted Design, not a fabricated new user answer.
-The same channel is available for the allowlisted `delivery-invalid`, `needs-task-split`, and `task-split-needed` technical pauses; these do not need a user decision or a fabricated approval-needed classification.
+The same channel is available for `needs-task-split`, `task-split-needed`, and original-baseline defects proven by parent-owned prerequisite evidence and included in the current batch.
+A bare `delivery-invalid` or `input-missing` code supplies no amendment authority.
+Unsafe paths, unknown errors, receipt/hash and currentness failures require restoration of trusted prerequisites.
+Baseline-only amendments retain compatible committed phases and task evidence, and invalidate only incompatible baseline/attribution evidence; they preserve the run and budgets.
 Each run permits 64 mutating amendment attempts in a dedicated persistent budget.
 Failed writes/compilations consume that budget, successful operation replay is free, and restart or a new batch does not replenish it.
 Read-only status/preflight does not consume it.
@@ -183,11 +212,14 @@ This channel does not activate Design, admit evidence packets, allow a different
 Keep the approved goal and explicit constraints stable.
 Automatic amendments retain Gate A and the structured ChangeContract.
 They cannot renew Gate A, replace behavior decisions, or rewrite proposal/spec artifacts.
+Even when a Worker classifies its preferred option as requiring Gate A, choose an alternative that satisfies the existing accepted behavior; the batch does not authorize renewing that Gate.
 Resolve implementation gaps within the accepted goal, constraints and policy; when no conforming solution exists, report that concrete contract blocker and preserve progress rather than repeatedly attempting an invalid amendment.
 Never weaken acceptance criteria just to obtain a passing result.
 The compiler supplies Gate B automatically.
 Finish all known items in the batch before finalizing, then issue ordinary resume.
 Local delivery discovery supplies the newer verified revision/hash; do not ask the user to copy receipts or switch commands.
+After an explicit Implement invocation for a process-interrupted run, follow the returned `resume-interrupted-operation` or `settle-apply-recovery` continuation using the ordinary closed resume command.
+Apply-journal settlement does not spend Worker work units; its continuation may remain available after those units are exhausted, and the engine still controls settlement before any further execution.
 An unchanged resume cannot bypass a pending decision, and stale batch ids or unrelated revision runIds are rejected.
 The user may explicitly choose a full Design discussion, but it is not the recovery instruction for an Implement blocker.
 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`.

package/src/apply-transaction.ts

@@ -23,6 +23,7 @@ import { DatabaseSync } from "node:sqlite";
 import type { ArtifactStore } from "./artifact-store.ts";
 import { compareCanonicalStrings } from "./canonical.ts";
 import { isValidRelativePath } from "./contracts.ts";
+import { syncDirectory } from "./directory-sync.ts";
 import { observeSafePath } from "./safe-path.ts";
 import { configureSqlite, ensureSqliteSchema } from "./sqlite-schema.ts";
 import { APPLY_SCHEMA } from "./storage-schema.ts";
@@ -247,15 +248,6 @@ function ensurePrivateDirectory(directory: string): void {
   chmodSync(directory, 0o700);
 }
 
-function syncDirectory(directory: string): void {
-  const descriptor = openSync(directory, constants.O_RDONLY);
-  try {
-    fsyncSync(descriptor);
-  } finally {
-    closeSync(descriptor);
-  }
-}
-
 function entryEqual(left: WorkspaceEntry, right: WorkspaceEntry): boolean {
   if (left.kind !== right.kind) return false;
   return (

package/src/artifact-store.ts

@@ -14,6 +14,7 @@ import {
   writeFileSync,
 } from "node:fs";
 import path from "node:path";
+import { syncDirectory } from "./directory-sync.ts";
 
 const SHA256 = /^[a-f0-9]{64}$/u;
 
@@ -58,15 +59,6 @@ function ensureDirectory(directory: string): void {
   chmodSync(directory, 0o700);
 }
 
-function syncDirectory(directory: string): void {
-  const descriptor = openSync(directory, constants.O_RDONLY);
-  try {
-    fsyncSync(descriptor);
-  } finally {
-    closeSync(descriptor);
-  }
-}
-
 function writeAtomic(target: string, bytes: Uint8Array): void {
   const directory = path.dirname(target);
   ensureDirectory(directory);