[huangruiteng]

Rejected accountable writebacks could lose their original Turn recovery, while a later maintenance surface_only refresh reported success without exposing the outstanding settlement. An unprofiled recovery guard could also return an unbound refresh template, leaving the same work in recovery again.

This change exposes settlement_recovery on rejected refreshes and state updates when receipts prove pending work. TS owns pending-Turn selection, original-binding checks and receipt qualification in one admitted snapshot; Python transports the request and renders the CLI result. Recovery uses the original Goal/Agent/Todo or replan/Turn, selects the complete CLI consumer, and offers the exact owed spend after verified writeback. Stale replan-context recovery remains mandatory. State-only success continues to mean only that the state update succeeded.

Validation covers real File and SQLite CLI journeys, heartbeat and visible-Goal spend sources, missing Turn input, conflicting bindings, other Agents, interrupted combined settlement, generated recovery commands, idempotent debit replay, replan-context changes, and unreadable recovery state. TS cases additionally cover snapshot consistency, Goal-instance fencing, legacy receipts, settled monitor work and rejection of mixed recovery/admission modes. The existing rejection diagnostic keeps its 4 KiB allowance, with a separate 2 KiB allowance for original-Turn recovery.

No historical receipt, live Goal, quota allocation or retry limit is rewritten by this change. This addresses recovery continuity rather than the retry-admission limit proposed in #8577.

Checks passed: 148 TS settlement tests; 17 CLI recovery/replan cases after the TS change; standard premerge canaries; control-plane TS typecheck; configured Python mypy plus scoped checks for the adapter/reader; Ruff; bilingual RFC gate and public-boundary scan. A broader 157-test Python regression run also passed during development. No production effectiveness or total-token improvement is claimed from these deterministic fixtures.

Follow-up for recovery without a Turn ID

A rejected or state-only refresh can now find an admitted autonomous replan from its original guard receipt when the caller omits the Turn ID. The readback validates the original obligation and effect in the existing snapshot. It returns the original guard command before verified writeback and the owed debit afterward. The persisted closeout marker governs whether that Turn is a prerequisite for later admission.

漏传 Turn ID 时，被拒绝的写回和维护刷新都能从原 guard 收据找回已准入的重规划。写回前返回原轮次的恢复命令，写回后只提供欠下的扣额。过期的重规划依据仍需先读取当前证据。

The full settlement/replan regression passed 220 Python tests at 7d810cc. After syncing main at eddd08d, the earlier head 465bcc1 passed 11 focused CLI tests, 196 TypeScript tests including the digest-owner check, the TypeScript typecheck, and standard premerge. Real File and SQLite cases reproduced the missing recovery on the prior code, then executed the returned recovery and replayed the debit twice with one committed spend.

That earlier head includes the merged steward digest-validator fix. Previous-head CI also reported a Frontstage copy contract mismatch, a Windows baseline output ceiling failure, and DNS failure during browser dependency installation. Digest fix #8596 · Frontstage fix #8590 · Windows baseline log · Browser setup log

Explicit-Turn recovery follow-up (90b629143)

The current head fixes the explicit unclaimed-Turn finding. A retained candidate binding is no longer sufficient to project settlement debt. Recovery reuses the existing work-admission result from the same snapshot, requires the original declared effect and matching replan obligation, and preserves verified partial writeback or spend. Identity conflicts remain visible.

The new real-CLI regression failed before this fix on both File and SQLite for heartbeat and visible-Goal profiles. The final commit passes all 9 refresh-recovery cases, including claim-required rejection, same-Turn admission after claiming, original identity, other-Agent and conflicting-binding rejection, interrupted writeback, and exactly-once debit replay. Two additional real File/SQLite replan journeys pass at the final commit, preserving missing-Turn recovery through the original obligation. All 307 related TypeScript tests, the control-plane typecheck, scoped Ruff, diff hygiene, bilingual gate and public-boundary scan pass.

The standard premerge run completed its other checks but retained one CLI output-budget timeout. Re-running that exact full check at this commit with the same 120-second limit passed in 27.48 seconds; no timeout or assertion was relaxed. Earlier failed runs remain historical evidence. Independent review of this new head is still required.

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max

本次评审对应提交 5860235b251cbd5887a2280f811ea0bb7de58a00。

[P2] 恢复漏传 Turn 的已准入重规划。 周期重规划的原 guard 已经持久化了 replan obligation 和 effect。漏传 --turn-instance-id 的 refresh-state 即使带了 --replan-obligation-id，也不返回 settlement_recovery。维护刷新同样无恢复入口，仍可能给出不带原 Turn 的通用重规划写回模板。 候选选择

动机 / Motivation

使用 refresh-state 恢复交付或维护状态的 Agent 和操作者，尤其是周期重规划正处于写回边界的 Agent。Agent 的交付写回被拒绝，或只写了升级状态时，原轮次的写回和扣额可能都还欠着。基线不在这两个刷新结果中交付原轮次的恢复命令。普通 Todo 的刷新现在能给出原 Turn 和下一条命令；写回后只给尚欠的扣额。恢复读取本身不追加 guard，也不扣额。普通 Todo 的刷新现在能给出原 Turn 和下一条命令；写回后只给尚欠的扣额。恢复读取本身不追加 guard，也不扣额。本轮只验证隔离的真实 File/SQLite CLI 和收据，不更改生产状态、配额或重试策略；无真实模型执行、生产安装或长期成本结论。周期重规划的原 guard 已经持久化了 replan obligation 和 effect。漏传 --turn-instance-id 的 refresh-state 即使带了 --replan-obligation-id，也不返回 settlement_recovery。维护刷新同样无恢复入口，仍可能给出不带原 Turn 的通用重规划写回模板。

改动思路 / Approach

应保留单快照、同一收据 owner 和单一续作命令。补齐已有重规划 guard 收据的候选选择，无需新增状态或扣额入口。 让 TypeScript 在一个已准入快照中选择欠账、核对原始绑定并验证收据；Python 只渲染结果。原写回尚欠时重新打开原 guard；写回已验证时只给尚欠扣额。保持旧的重规划依据校验。

具体改动 / Changes

关键代码讲解

规格以 docs/reference/required-work-context.md#bounded-settlement-results--有界结算结果 @ 23bc2e0 为准：ORIGINAL-TURN、ONLY-OWED-EFFECT 已验证；REPLAN-RECOVERY 未满足。选择和读回 通过同一个快照找到候选再核对原身份。CLI 适配 在拒绝和维护响应内追加独立 recovery；普通状态更新不变成写回。中断用例 在写回完成、扣额未开始时中断，再执行返回的原扣额两次，只落一笔。重规划依据过期时仍须先读当前依据再重试。

对主干的风险 / Risks

在真实 File 和 SQLite 上先推进两个普通 Turn，再触发周期重规划。原 guard 带 replan obligation 和 effect；省略 --turn-instance-id 的维护刷新及带 --replan-obligation-id 的拒绝刷新都没有 recovery。同一 fixture 补上原 Turn 后马上返回 writeback_required，身份完全相同，收据和扣额计数不变。原因是无 Turn 分支借用了只筛 closeout_required 的候选规则，重规划独占绑定不在其中。

语义与 CI 对齐

148 项 TypeScript 读回测试、类型检查、DCO、diff 与双语检查通过。第一次 33 项 Python 组合中一项周期计数失败；相同单项在基线和当前提交分别重跑通过。独立重规划复现是稳定的功能缺口。未查询托管 CI。

我的整体评价 / Verdict

普通 Todo 和写回后的精确扣额恢复可以保留。请补齐重规划在漏传 Turn 时的原身份恢复，保持其他 Agent、旧回执和冲突参数的边界。本次检查了 CLI 的失败与恢复提示；没有渲染界面改动。未验证生产安装或模型在真实会话中采用恢复结果。

English verdict: REQUEST_CHANGES. The original Todo and debit recovery work, but missing-Turn refresh still hides an admitted replan-only settlement on File and SQLite. Recover it from the positively admitted original receipt.

[loopx-agent]

[P2] 恢复漏传 Turn 的已准入重规划。 用现有周期重规划 fixture 在 File 和 SQLite 上复现：原 guard 的 settlement_identity 已有 replan_obligation_id 和 effect，不带 --turn-instance-id 的 refresh-state 即使显式传 --replan-obligation-id，也不返回 settlement_recovery；同一 Agent 的维护刷新也没有恢复入口。补上原 Turn 后立即返回同一 effect 的 writeback_required，收据和扣额计数不变。这里使用的 prior-Turn 候选只收 closeout_required，而 replan-only guard 不写这个 Todo 标记。请在同一已准入快照中识别正向准入的原重规划，保留冲突绑定和旧回执的拒绝，并补两个 provider 的无 Turn 用例。

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max

本次评审对应提交 465bcc1be18d7bb47211bf1167b4ca44e98e45c4。

[P2] 显式 Turn 会把未领取的候选当成待写回。 硬租约尚未领取时，guard 已经保存候选 Todo 绑定，但 execution_preparation 仍为 claim_required。显式带该 Turn 触发一次被拒绝的 refresh-state，新提交却给出 required=true、writeback_required 的 settlement_recovery。同一命令再次只读回 claim_required，形成错误恢复指引。

动机 / Motivation

从拒绝或维护刷新继续原工作的 LoopX Agent 与 CLI 操作者。Agent 的写回被拒绝或只做维护刷新时，可能无法从返回值找到已准入 Turn 的原结算身份。新提交补齐原评审指出的漏传 Turn 重规划路径。File 与 SQLite 都返回原 obligation、effect 和尚欠写回。普通 Todo 的部分提交只返回原扣额，重放只记一次。新提交补齐原评审指出的漏传 Turn 重规划路径。File 与 SQLite 都返回原 obligation、effect 和尚欠写回。普通 Todo 的部分提交只返回原扣额，重放只记一次。验证覆盖隔离的 File 与 SQLite 原生 CLI。生产运行、真实模型采用和托管 CI 未验证。硬租约尚未领取时，guard 已经保存候选 Todo 绑定，但 execution_preparation 仍为 claim_required。显式带该 Turn 触发一次被拒绝的 refresh-state，新提交却给出 required=true、writeback_required 的 settlement_recovery。同一命令再次只读回 claim_required，形成错误恢复指引。

改动思路 / Approach

共用同一快照和 typed receipt owner。补齐显式 Turn 的准入核验，同时保留原 replan 和已提交部分结算的恢复。 保留既有收据、原身份校验和无扣额读回。显式参数需要通过同一准入边界。

具体改动 / Changes

关键代码讲解

本次按 docs/reference/required-work-context.md#bounded-settlement-results--有界结算结果 @eddd08d7d0e73539672a276e55856207dea7eb3f 检查。ORIGINAL-REPLAN 和 ONE-OWED-DEBIT 已验证，READY-ADMISSION 的显式 Turn 路径有反例。先读原 guard，再读本次 CLI 返回。 重规划候选 核验 obligation、effect 和正向准入。 显式读回 直接取调用者的 Turn，随后证明原绑定与收据链。 CLI 适配器 保留拒绝结果，并附加重入原 guard 的指令。实际执行该指令仍返回缺租约。普通 Todo 写回已提交时，命令只推进原扣额，第二次执行命令会读回同一笔。

对主干的风险 / Risks

File 和 SQLite 上的漏传 Turn 正例已恢复原 obligation 与 effect。显式未领取反例在基线只拒绝写回，新提交还生成必做恢复动作。该动作重新读到领取前置条件。两边都没有写回或扣额。

语义与 CI 对齐

148 项 TypeScript、类型检查、Ruff、DCO 和双语检查通过。33 项 Python 有 31 项通过。两个 ordinary evidence 计数失败都发生在同秒写入。固定同秒后，原基线与新提交的预期均为 2 项，实测均为 1 项。该失败归于既有证据归并。两种 provider 的原生恢复反例独立复现。

我的整体评价 / Verdict

请求补显式 Turn 的准入核验。原评审的漏传 Turn 修复成立，继续保留已提交部分结算和原扣额重放。本次评审覆盖现有宿主与 CLI 行为。验证覆盖隔离的 File 与 SQLite 原生 CLI。生产运行、真实模型采用和托管 CI 未验证。

English verdict: REQUEST_CHANGES. The missing-Turn replan path is repaired. Explicit-Turn refresh still reports closeout debt for a claim-required Todo. Require positive admission before projecting recovery.

[loopx-agent]

[P2] 显式 Turn 也要确认原 guard 已准入。 在真实 File 和 SQLite 上，为一个无租约的 Todo 运行带 Turn 的 guard，得到 claim_required，normal_delivery_allowed=false。对同一 Turn 执行被拒绝的 surface_only refresh，新提交仍返回 required=true、writeback_required。执行给出的原 guard 只再次返回 claim_required。省略 Turn 的同一维护调用没有欠账。请在同一快照核验准备就绪或已成立的部分结算，再给显式路径投影待结算动作，并保留已准入重规划的正例。

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max

本次评审对应提交 90b62914377e5237cd6636dcf9320f687be95cd7。

本提交已覆盖前两轮的阻塞反例，当前无阻塞发现。

动机 / Motivation

使用 refresh-state 提交结果或维护状态的 Agent 和操作者。一次已准入的轮次写回失败后，操作者可能先做维护刷新。主干在两个入口都漏掉了原轮次尚欠的结算，操作者要自己找回身份和下一条命令。相同 File 和 SQLite 场景下，拒绝响应和维护刷新都指向原 Goal、Agent、工作绑定、Turn 和 effect。验证写回之前返回原 guard，写回之后只返回欠下的扣额，重复扣额仍只记一次。本次核验本地 CLI 的合成 Goal 和原生 File、SQLite。真实安装、Windows shell 和模型是否采用恢复提示仍待验证。

改动思路 / Approach

保留原结算 reader 作为唯一判决入口。新增的发现和展示分支挂在现有拒绝与维护入口，继续使用同一数据和操作边界。 发出恢复命令前，先从现有 provider 快照找到原轮次，再核对工作身份和准入证据。写回进度、配额来源与扣额指令沿用同一个收据 owner。 结算读取

具体改动 / Changes

关键代码讲解

按 docs/quota-allocation.md 在 708c68e7040559b2a4368002439570b90bc080b2 的收据契约核验 original-turn-receipts、owed-debit-only、maintenance-preserves-authority。GitHub 当前比较包含 136 个路径，其中 126 个路径和当前 main 的前后 blob 完全一致。实际进入主干的 10 个路径均已逐段核对。

selectCloseoutCandidates 给维护读取补上有正向准入证据的 replan 候选。readPendingCloseoutFromRequest 核对原 effect、工作准入及 obligation。attach_refresh_settlement_recovery 在被拒写回或维护结果中显示恢复入口。写回之后只给原 effect 欠下的扣额。 配额契约 刷新适配

对主干的风险 / Risks

最容易误判的是已绑定但未领取的候选，以及维护记录覆盖原工作时的同轮次恢复。File 和 SQLite 上，未领取时显式请求仍无欠账，领取后能读回同一原轮次。漏传 Turn 的周期重规划已能恢复，旧 basis 仍要求读回当前上下文。冲突 Todo 被拒。模拟写回后中断，执行两次恢复扣额只产生一笔。 真实入口测试 周期重规划

语义与 CI 对齐

本地标准 premerge、224 个 TypeScript 测试及类型检查通过。Python 扩展组 134 项通过。SQLite 的 verify-2-False 在当前 main 和本 head 都把 2 条普通证据合并成 1 条，比较了同一失败断言和未改动的证据去重代码。两种 provider 的恢复、错绑定、dry-run 和一次扣额已另行通过。托管 CI 未查。 普通证据投影

我的整体评价 / Verdict

两条旧阻塞均已验证修复，本次代码评审无阻塞发现。原线程的 GitHub 状态和 Change Quality 仍按其各自门槛核验。检查了实际 refresh-state 的 JSON 与 Markdown 结果。本次核验本地 CLI 的合成 Goal 和原生 File、SQLite。真实安装、Windows shell 和模型是否采用恢复提示仍待验证。

English verdict: APPROVE. The original admitted Turn is recoverable after a refused refresh or maintenance, and unclaimed candidates remain debt-free on File and SQLite.

The merge-base changed after approval.

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max

本次评审对应提交 90b62914377e5237cd6636dcf9320f687be95cd7。

本提交已覆盖前两轮的阻塞反例，当前无阻塞发现。

动机 / Motivation

使用 refresh-state 提交结果或维护状态的 Agent 和操作者。一次已准入的轮次写回失败后，操作者可能先做维护刷新。主干在两个入口都漏掉了原轮次尚欠的结算，操作者要自己找回身份和下一条命令。相同 File 和 SQLite 场景下，拒绝响应和维护刷新都指向原 Goal、Agent、工作绑定、Turn 和 effect。验证写回之前返回原 guard，写回之后只返回欠下的扣额，重复扣额仍只记一次。本次核验本地 CLI 的合成 Goal 和原生 File、SQLite。真实安装、Windows shell 和模型是否采用恢复提示仍待验证。

改动思路 / Approach

保留原结算 reader 作为唯一判决入口。新增的发现和展示分支挂在现有拒绝与维护入口，继续使用同一数据和操作边界。 GitHub 撤回上次批准后，本轮从 GitHub 的候选合并提交重新核对实际 main 与 head，树内容和本地合并结果一致。发出恢复命令前，先从现有 provider 快照找到原轮次，再核对工作身份和准入证据。写回进度、配额来源与扣额指令沿用同一个收据 owner。 结算读取

具体改动 / Changes

关键代码讲解

按 docs/quota-allocation.md 在 708c68e7040559b2a4368002439570b90bc080b2 的收据契约核验 original-turn-receipts、owed-debit-only、maintenance-preserves-authority。GitHub 当前比较包含 136 个路径，其中 126 个路径和当前 main 的前后 blob 完全一致。实际进入主干的 10 个路径均已逐段核对。GitHub 候选合并提交为 22e3ef6，两个父提交和树与本轮记录一致。

selectCloseoutCandidates 给维护读取补上有正向准入证据的 replan 候选。readPendingCloseoutFromRequest 核对原 effect、工作准入及 obligation。attach_refresh_settlement_recovery 在被拒写回或维护结果中显示恢复入口。写回之后只给原 effect 欠下的扣额。 配额契约 刷新适配

对主干的风险 / Risks

最容易误判的是已绑定但未领取的候选，以及维护记录覆盖原工作时的同轮次恢复。File 和 SQLite 上，未领取时显式请求仍无欠账，领取后能读回同一原轮次。漏传 Turn 的周期重规划已能恢复，旧 basis 仍要求读回当前上下文。冲突 Todo 被拒。模拟写回后中断，执行两次恢复扣额只产生一笔。 真实入口测试 周期重规划

语义与 CI 对齐

本地标准 premerge、224 个 TypeScript 测试及类型检查通过。本轮重新跑了 11 项 File/SQLite 恢复和对照用例，全部通过。相同源提交和 main 的扩展组此前 134 项通过。SQLite 的 verify-2-False 在当前 main 和本 head 都把 2 条普通证据合并成 1 条，比较了同一失败断言和未改动的证据去重代码。两种 provider 的恢复、错绑定、dry-run 和一次扣额已另行通过。托管 CI 未查。 普通证据投影

我的整体评价 / Verdict

两条旧阻塞均已验证修复，本次代码评审无阻塞发现。当前批准对应 GitHub 计算的候选合并树。原线程和 GitHub 的审批有效性仍需读回。检查了实际 refresh-state 的 JSON 与 Markdown 结果。本次核验本地 CLI 的合成 Goal 和原生 File、SQLite。真实安装、Windows shell 和模型是否采用恢复提示仍待验证。

English verdict: APPROVE. The original admitted Turn is recoverable after a refused refresh or maintenance, and unclaimed candidates remain debt-free on File and SQLite.

The merge-base changed after approval.

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=max

复审提交 90b6291。

动机 / Motivation

使用 PowerShell 的操作者，在原轮次等待写回、安装启动器路径含空格或 registry 路径含单引号时，会遇到这个问题。 当前提交能找回同一轮次并返回恢复命令。命令使用 POSIX 引号，原样复制到 PowerShell 时解析失败或拆坏 registry 参数。 File 和 SQLite 两次原样执行均退出 1。把同一组参数逐项传给仓库的 PowerShell 启动脚本后，两例均能读取原 Goal、Agent、Todo 和 Turn，仍各一张准入回执、零扣额。 PowerShell 复验用 macOS 上的 7.6.9 与实际仓库脚本。本轮验证本地 File、SQLite 和现有源码 CLI。原生 Windows、独立安装与托管 CI 的结果仍待验。 本轮逐项核对 ORIGINAL-TURN-RECEIPTS、OWED-DEBIT-ONLY、MAINTENANCE-RECOVERY-COMMAND。当前的恢复文本无法在受影响的 PowerShell 路径进入原轮次，操作者需要手工重组参数。 现有回执契约

改动思路 / Approach

本次范围是已准入轮次的刷新恢复、同一快照的原回执读取和宿主命令呈现。保留原 TypeScript snapshot 与 CLI renderer 边界，修复显示的 shell 文本。 TypeScript 在同一 provider 快照中找原候选，核对 effect、工作准入和已有部分回执。Python 在拒绝或维护结果上显示这个动作。显示层沿用 POSIX 引号，PowerShell 直接运行时无法到达原 guard。 读取与准入 · CLI 投影

具体改动 / Changes

• 保留原两项修复。未领取的显式候选不会被列为欠结算。省略 Turn 的已准入重规划能按原 obligation 恢复，旧上下文仍须先读取。写回后的恢复沿既有扣额入口重放。JSON 和 Markdown 使用同一命令。 选择原候选 · 原入口用例
• 独立核对本次实际合入的 10 个路径。GitHub 比较还列出先前进入主干的改动。主干随后更新两个 Dashboard 聊天文件，合入范围与恢复代码一致。 维护与拒绝入口
• 本地源码验证 29 通过，包含原两项发现的真实 File 与 SQLite 对照。另有 8 个周期用例在主干和候选合入树都被同一工作区校验拒绝，双方均未追加写回。候选合入树新增同一轮次的恢复提示。154 个 TypeScript 结算读取测试通过。 最新主干的候选合入净改 10 文件，+578/-24。Ruff、双语门与 diff 检查通过。最新主干相对实际测试树只多两个 Dashboard 聊天文件。

对主干的风险 / Risks

PowerShell 复验用 macOS 上的 7.6.9 与实际仓库脚本。本轮验证本地 File、SQLite 和现有源码 CLI。原生 Windows、独立安装与托管 CI 的结果仍待验。 原样命令在启动器路径带空格时，PowerShell 把被引用的脚本当成字符串，报出 cli-bin 解析错误。registry 路径含单引号时，POSIX 拼接令 CLI 收到额外参数。状态更新本身可以成功，原轮次仍等写回。 待执行命令

我的整体评价 / Verdict

请求修改。两项既有收据问题保持修复。新增 P2 会挡住受影响的 PowerShell 用户继续原轮次。复用宿主命令呈现层，从结构化 argv 生成 next_cli_actions 和后续必要的读取命令。PowerShell 使用调用运算符和原生字符串引用。将返回文本原样交给实际 .ps1，在 File 与 SQLite 上核验原身份、零额外准入和扣额。

English verdict: REQUEST_CHANGES. The exact proposed recovery text fails in PowerShell for a launcher path with spaces or a registry path with an apostrophe. Passing the same arguments through the shipped launcher recovers the original Turn on File and SQLite.

[loopx-agent]

[P2] 返回当前 PowerShell 可直接执行的恢复命令。 使用 PowerShell 的操作者，在原轮次等待写回、安装启动器路径含空格或 registry 路径含单引号时，会遇到这个问题。 File 和 SQLite 两次原样执行均退出 1。把同一组参数逐项传给仓库的 PowerShell 启动脚本后，两例均能读取原 Goal、Agent、Todo 和 Turn，仍各一张准入回执、零扣额。 复用宿主命令呈现层，从结构化 argv 生成 next_cli_actions 和后续必要的读取命令。PowerShell 使用调用运算符和原生字符串引用。将返回文本原样交给实际 .ps1，在 File 与 SQLite 上核验原身份、零额外准入和扣额。