@abelxiaoxing/cadence 1.6.0 → 1.8.0

package/README.md

@@ -10,7 +10,7 @@
 
 1. 安装 Node.js >=22.13、Git、Pi，以及 `@fission-ai/openspec@1.5.0`。
 2. 在 Pi 中安装：`pi install npm:@abelxiaoxing/cadence`。
-3. 默认 Implement 需要可用的 Linux Bubblewrap；Windows 请使用 WSL。
+3. 默认 Implement 使用 Linux Bubblewrap；Windows x64 可信项目可显式选择 `host-trusted`，构建与验收见 [Windows 原生执行](docs/windows-host-trusted.md)。
 4. 首次进入项目先运行 `/abel-init`，然后 `/abel-design <需求>`，确认集中呈现的目标与方案，设计完成后运行 `/abel-implement <change>`。
 5. 暂停时先查看原因和建议，不要靠反复 resume 或重启“碰运气”；未完成的工作会保留。
 
@@ -50,7 +50,9 @@ export ABEL_VERIFICATION_TIMEOUT_MS=900000
 可信模式仍在独立候选目录执行，并复制依赖以避免普通缓存写入修改 consumer 的依赖，但**不是沙箱**：测试可访问宿主文件、网络及显式继承的环境变量，产生的外部副作用不能回滚。
 HOME、临时目录和报告仍独立；PATH 复用宿主，仓库内 workspace 链接映射到候选代码。
 该模式仍要求 Linux Bubblewrap 的 PID namespace 管理后代进程（包括 detached 后代），但不隔离宿主文件和网络；缺少该能力时暂停，不回退到普通进程组。
-原生 macOS/Windows 不提供此执行模式，Windows 可使用 WSL。
+`local-trusted` 仅用于 Linux。
+Windows x64 使用独立的 `host-trusted` 后端，见 [配置、构建与验收说明](docs/windows-host-trusted.md)；macOS 暂不支持。
+包含原生 helper 的 Windows x64 安装包在 [GitHub Release](https://github.com/abelxiaoxing/cadence/releases/tag/v1.8.0) 下载；npm 通用包可显式构建 helper 后配置使用。
 依赖副本准备、替换与清理在 I/O Worker 中执行，复制支持取消并等待线程退出；大型依赖复制仍有额外成本；需要安装新依赖、宿主浏览器缓存或服务启动编排时仍需配置/准备，不会自动下载。
 
 可选宿主参数还包括 `ABEL_BWRAP_PATH`、`ABEL_FIRST_PROGRESS_MS` 和 `ABEL_STREAM_IDLE_MS`。
@@ -150,6 +152,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。
@@ -165,7 +179,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` 只列为条件命令；证明就绪后可直接恢复，由控制层读取版本和哈希。
@@ -324,7 +341,9 @@ inspection 不可用时不再级联误报 traceability 输入缺失，且绝不
 CLI 的其他版本必须满足相同 JSON 协议；新增支持版本应加入契约测试。
 
 **此矩阵不代表原生 Implement 隔离已全平台可用。**
-默认隔离后端仍为 Linux Bubblewrap；Windows/macOS 的原生隔离、ACL 与完整文件应用语义需要单独实现和验收，缺少隔离能力时保持暂停，不降级为主工作区直接执行。
+默认隔离后端仍为 Linux Bubblewrap。
+Windows x64 的显式 `host-trusted` 使用 Job Object 管理验证进程，不提供文件或网络安全隔离；真实原生支持以 Windows CI 验收结果为准。
+缺少所选后端时保持暂停。
 
 目录持久化在 Windows 上单独处理：仅当已打开的目录句柄执行 `fsync` 返回 `EPERM` 时，标记为不支持目录刷新屏障。
 普通文件仍须在发布前成功 `fsync`；目录打开/关闭、权限、其他 I/O 及 POSIX 目录刷新错误不会被忽略。
@@ -463,6 +482,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/.env.example

@@ -19,3 +19,9 @@ GROK_API_KEY=
 # TAVILY_ENABLED=true
 # TAVILY_API_URL=https://api.tavily.com
 # TAVILY_API_KEY=
+
+# Explicit Windows x64 trusted host verification (not a filesystem/network sandbox).
+# ABEL_EXECUTION_MODE=host-trusted
+# ABEL_WINDOWS_JOB_HELPER=C:\CadenceNative\windows-job.exe
+# ABEL_VERIFICATION_TIMEOUT_MS=600000
+# ABEL_VERIFICATION_ENV=DATABASE_URL,NODE_ENV

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.6.0",
+  "version": "1.8.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

@@ -13,7 +13,6 @@ import {
   realpathSync,
   renameSync,
   rmdirSync,
-  rmSync,
   unlinkSync,
   writeFileSync,
 } from "node:fs";
@@ -24,6 +23,8 @@ import type { ArtifactStore } from "./artifact-store.ts";
 import { compareCanonicalStrings } from "./canonical.ts";
 import { isValidRelativePath } from "./contracts.ts";
 import { syncDirectory } from "./directory-sync.ts";
+import { isExecutionRetained } from "./execution-retention.ts";
+import { removePathSync } from "./remove-path.ts";
 import { observeSafePath } from "./safe-path.ts";
 import { configureSqlite, ensureSqliteSchema } from "./sqlite-schema.ts";
 import { APPLY_SCHEMA } from "./storage-schema.ts";
@@ -161,6 +162,8 @@ export interface ApplyTransactionHooks {
     path: string;
     index: number;
   }) => void | Promise<void>;
+  /** Production executors settle their process scope before cancellation returns. */
+  awaitPostApplySettlement?: boolean;
   postApply?: (input: {
     transactionId: string;
     root: string;
@@ -412,10 +415,10 @@ function writeExclusiveFile(
     syncDirectory(directory);
     return true;
   } catch (error) {
-    rmSync(temporary, { force: true });
+    removePathSync(temporary, { force: true });
     throw error;
   } finally {
-    rmSync(temporary, { force: true });
+    removePathSync(temporary, { force: true });
   }
 }
 
@@ -587,7 +590,8 @@ export async function verifyCumulativeRevision(
       verificationId: input.verificationId,
     };
   } finally {
-    rmSync(temporary, { recursive: true, force: true });
+    if (!isExecutionRetained(temporary))
+      removePathSync(temporary, { recursive: true, force: true });
   }
 }
 
@@ -1247,11 +1251,13 @@ export class ApplyTransaction {
             }),
           );
           void execution.catch(() => undefined);
-          postApply = signal
-            ? await raceWithAbort(execution, signal)
-            : await execution;
+          postApply =
+            signal && !this.#hooks.awaitPostApplySettlement
+              ? await raceWithAbort(execution, signal)
+              : await execution;
         } finally {
-          rmSync(isolatedRoot, { recursive: true, force: true });
+          if (!isExecutionRetained(isolatedRoot))
+            removePathSync(isolatedRoot, { recursive: true, force: true });
         }
       }
     } catch (error) {
@@ -1260,6 +1266,13 @@ export class ApplyTransaction {
       if (settled) return settled;
       if (!journal.pendingIntent && !signal?.aborted) throw error;
     }
+    if (isExecutionRetained(this.root)) {
+      journal = this.#load(transactionId);
+      journal.state = "recovering";
+      journal.code = "isolation-termination-unconfirmed";
+      this.#save(journal);
+      return { ok: false, transactionId, state: "paused", code: journal.code };
+    }
     journal = this.#load(transactionId);
     const settled = this.#settledOutcome(journal);
     if (settled) return settled;
@@ -1350,6 +1363,13 @@ export class ApplyTransaction {
   ): Promise<ApplyTransactionOutcome> {
     const existing = this.#active.get(transactionId);
     if (existing) return existing.promise;
+    if (isExecutionRetained(this.root))
+      return Promise.resolve({
+        ok: false,
+        transactionId,
+        state: "paused",
+        code: "isolation-termination-unconfirmed",
+      });
     const controller = new AbortController();
     const forwardAbort = () => {
       if (!controller.signal.aborted) {

package/src/build-windows-job.mjs

@@ -0,0 +1,95 @@
+// Explicit operator/release build only. Never invoked on import, install or verification.
+import { spawnSync } from "node:child_process";
+import { createHash } from "node:crypto";
+import { mkdirSync, readFileSync, rmSync, writeFileSync } from "node:fs";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+
+function main() {
+  const args = process.argv.slice(2);
+  if (
+    process.platform !== "win32" ||
+    process.arch !== "x64" ||
+    args.length !== 2 ||
+    args[0] !== "--output"
+  )
+    throw new Error(
+      "Windows x64 required; usage: node build-windows-job.mjs --output <directory>",
+    );
+  const output = path.resolve(args[1]);
+  const compiler = path.join(
+    process.env.VCToolsInstallDir ?? "",
+    "bin/Hostx64/x64/cl.exe",
+  );
+  if (!path.isAbsolute(compiler))
+    throw new Error(
+      "Select the installed MSVC x64 developer environment first",
+    );
+  const sdkVersion = process.env.WindowsSDKVersion?.replace(/[\\/]+$/u, "");
+  if (!sdkVersion || !/^10\.0\.\d+\.0$/u.test(sdkVersion))
+    throw new Error("Windows 10 SDK required");
+  const version = spawnSync(compiler, [], {
+    shell: false,
+    encoding: "utf8",
+    timeout: 10000,
+    maxBuffer: 16384,
+  });
+  const compilerVersion =
+    `${version.stdout ?? ""}${version.stderr ?? ""}`.match(
+      /19\.(?:3\d|4\d)\.\d+/u,
+    )?.[0];
+  if (!compilerVersion) throw new Error("MSVC 19.3x/19.4x required");
+  mkdirSync(output, { recursive: true });
+  const source = fileURLToPath(new URL("./windows-job.c", import.meta.url));
+  const helper = path.join(output, "windows-job.exe");
+  rmSync(`${helper}.json`, { force: true });
+  rmSync(helper, { force: true });
+  const result = spawnSync(
+    compiler,
+    [
+      "/nologo",
+      "/W4",
+      "/WX",
+      "/O2",
+      "/MT",
+      "/utf-8",
+      "/DUNICODE",
+      "/D_UNICODE",
+      source,
+      `/Fe:${helper}`,
+      `/Fo:${path.join(output, "windows-job.obj")}`,
+    ],
+    {
+      shell: false,
+      cwd: output,
+      encoding: "utf8",
+      timeout: 60000,
+      maxBuffer: 65536,
+    },
+  );
+  writeFileSync(
+    path.join(output, "build.log"),
+    `${result.stdout ?? ""}${result.stderr ?? ""}`,
+  );
+  if (result.error || result.status !== 0)
+    throw new Error("Native build failed; inspect build.log");
+  const hash = (file) =>
+    createHash("sha256").update(readFileSync(file)).digest("hex");
+  writeFileSync(
+    `${helper}.json`,
+    `${JSON.stringify({ version: 2, arch: "x64", sourceSha256: hash(source), helperSha256: hash(helper), compilerSha256: hash(compiler), compilerVersion, sdkVersion }, null, 2)}\n`,
+    { flag: "wx" },
+  );
+  console.log(`Built ${helper}`);
+}
+if (
+  process.argv[1] &&
+  path.resolve(process.argv[1]) === fileURLToPath(import.meta.url)
+) {
+  try {
+    main();
+  } catch (error) {
+    console.error(error.message);
+    process.exitCode = 1;
+  }
+}

package/src/candidate-workspace.ts

@@ -21,6 +21,12 @@ export function runGitApply(
     const child = spawn(
       "git",
       [
+        // Candidate patches bind exact bytes, independent of host checkout
+        // preferences. Git's Windows autocrlf default must not rewrite them.
+        "-c",
+        "core.autocrlf=false",
+        "-c",
+        "core.eol=lf",
         "apply",
         ...(checkOnly ? ["--check"] : []),
         "--recount",