fix(quota): admit due auxiliary monitors after primary settlement

[huangruiteng]

Problem / 问题

A completed advancement may be durably refreshed and charged before its independently leased, due Monitor records the first observation. The existing auxiliary admission rejected the exact primary binding once settlement reached settled; replay also retained a historical open-Turn continuation after primary closeout. This caused a legitimate observation to fail without permitting any new advancement.

主推进已经写回并完成唯一扣额后，独立取得租约的到期 Monitor 仍应能登记首次观察。原准入把 settled 当作观察禁入条件；重放还可能读回历史“Turn 未结束”状态。此次修正不增加推进、扣额或外部观察重试权限。

Implementation / 实现

• Reuse the existing TypeScript exact settlement readback for auxiliary admission and current continuation; no parallel Python decision source or storage provider.
• Allow the first independently admitted due observation after primary settlement. Preserve exact Turn/Todo/actor identity, advancement lifecycle, ordinary due-work gates and canonical Monitor lease/provider CAS.
• On executed commit and durable replay, a verified settled primary reports current_turn_settled=true, next_turn_required=true; it never reopens the paid Turn or adds a delivery/spend identity.
• Extend existing tests and the bilingual observation protocol rather than adding a feature flag, new schema or duplicate configuration/UI owner.

Validation / 验证

• TypeScript focused Monitor/auxiliary settlement: 45 passed, no skips; settlement readback/phase regression: 48 passed, no skips.
• Real CLI ordering and replay on legacy, File and SQLite: 8 passed. Existing related monitor/identity/priority regressions: 9 passed.
• npm run typecheck:control-plane, Python Ruff and git diff --check: passed.
• Real isolated PostgreSQL authority-store conformance: 301 passed, and service integration 1 passed, no skips. These cover the existing provider/lease contract, not a PostgreSQL CLI execution of the new first-post-spend ordering.
• An optional historical authority-reactivation rehearsal was attempted but not passed: its pre-reactivation baseline cannot open the current File store schema. It is not evidence for this ordering fix; the affected real File/SQLite CLI paths above passed.

User entry points and limits / 产品入口与边界

The affected entry point is CLI/managed-Turn execution and its existing typed continuation/readback. No settings field, Monitor schedule schema or frontend/Lark control changes. Existing frontend Monitor creation/editing and schedule projections keep their current canonical owner. No new UI path is required; this is not a claim of new frontend/Lark rendering acceptance.

本 PR 不修改真实 Goal、历史观察或账户操作，不切换默认运行时。控制面修复保持 maintainer review-required；合并并升级后，再以原身份和当前到期／租约状态验收真实 Agent 恢复。

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

精确评审版本：f876989cfbd0afa1ebf5e7f07904edd1bd6f6d2a。没有发现阻断项；这是自评审证据，不替代维护者 review 或合并授权。本文只评价该修复切片，不宣称真实 Agent 已升级恢复。

动机

真实调用顺序可以是：主推进完成、写回、唯一扣额，然后独立租约的到期 Monitor 登记首次观察。旧版错误地把主任务 settled 当成观察禁入条件，迫使 Agent 重新协调；历史回执还可能在重放时错误宣称原 Turn 未结束。同一真实 CLI 合成场景的 legacy、File、SQLite 三臂已复现旧版拒绝，修复版均生成一个观察回执且仍只有一次主任务扣额。这是有用的恢复增量，不是投研目标或部署闭环已经完成。

改动思路

最强反对理由是：直接解除结算拒绝会不会借旧 Turn 执行新推进、借旧租约登记任意观察？实现保留原身份、actor、生命周期、due-work 和 provider 租约/CAS，只移除主任务已结算这一错误限制。只删这一判断仍不能修好重放的错误下一步，所以复用已有 TS readQuotaSettlement 为现有 continuation 推导当前状态；不增设标志、第二个结算引擎或 Python 决策源。Python 保留真实 CLI/后端桥接与独立结算读回，storage provider 不承担新的准入规则。

具体改动

关键代码讲解

1. readAuxiliarySettlement，544 行：以 runtime、Goal、观察 actor、原 settlement Todo 和 Turn 精确读回，禁用身份推断和无绑定放行。它复用已验证的 settlement owner，不另存手工同步状态。
2. auxiliaryMonitorAllowed，556 行：当前首个观察仍需原推进 open/done、归属匹配、未排除 actor、真实结算身份和普通到期门；只不再把 settled 当拒绝理由。历史 pending admission 的恢复限制没有扩展到新 effect。
3. projectAuxiliaryContinuation，1499 行：仅执行成功的辅助观察投影已核验结算；已结算返回必须 fresh Turn，保留禁止同 Turn 独立结算。payloadFor 和 durable replay 都调用它，不修改历史观察身份或重跑 provider。

TS 测试扩展了结算前后 11 组身份、生命周期和门禁反例，增加首次观察晚于扣额与 pending-effect 跨结算重放。真实 CLI 测试复用原有 fixture，覆盖 legacy/File/SQLite 两种顺序、canonical active lease、独立读回、重复 spend 和观察重放。协议中英文同步披露默认修正，不用改 golden 隐藏旧错误。

对主干的风险

主要风险是错放其他 Todo/Turn/actor 或重放再次推进。45 项 TS 聚焦测试、48 项 settlement 回归和真实 CLI 8 项排序/重放加 9 项相关回归已覆盖这些边界；精确 baseline/head 对照保留了旧版完整 identity-conflict 诊断与新版本的已结算下一步。数据源来自精确身份读回，不依赖开放列表的展示上限，done 不被当成验收完成。新增成本是辅助 commit/replay 的当前 settlement readback；没有新的无限重试或持久维护状态。

补充同一 File 真实 CLI 的 base/head 反例：同 Goal 的非 Monitor 主 Todo、缺失 Todo、错误 Turn、错误 actor 都拒绝，完整诊断一致且零观察写入。已结算加错误 target 这一双重错误，旧版先被错误结算 fence 拒绝，修复版由正确的 due-target gate 拒绝；这是有意的诊断优先级修正，不能写成字节等价。修复版随后完成原合法观察、重放、独立结算读回、租约释放和重复 spend 验证，证明不只是记录阻塞。

真实隔离 PostgreSQL 的现有 store/service 集成通过，但不是新顺序的 PostgreSQL CLI 端到端证明。额外历史 reactivation rehearsal 因旧基线不能打开当前 File schema 未通过，明确不计为此修复验收。这个 PR 不修改 provider 存储/迁移或晋升，不能把补充测试扩写成生产恢复证明。CLI/managed Turn 是受影响入口；没有新配置、前端或 Lark 控件，现有 Monitor schedule 继续使用 canonical owner。

语义与 CI 对齐

复用现有 quota_settlement_progress_v0、quota_turn_continuation_v0 和 Monitor admission 语义，没有新词表或并行权威。结算后首个辅助观察由拒绝改为允许、重放按当前结算返回，这是已披露并实测的有意变化，不主张字节等价。按 Goal 的评审配置不查询或等待 GitHub CI；精确 head 的本地 premerge 19/19、4 个直接检查和 public boundary 均通过。

额外输出预算检查仍失败：loopx_turn_plan/crowded/json 为 14514 字符，上限 14500。在不可变基线 d5354afc49078765a579bddc0bfcb78b470984a4 与本 head 用同一解释器、同一命令均复现同一完整断言，相关 runner、fixture、预算与 Turn plan 路径未改；修复准入和重放另有上述独立通过证据，故归为 pre_existing_unrelated，不计通过、不提高上限。另一次误用已安装旧运行时的 canary 出现 60 秒子进程超时，不冒充本 head 的验证。以上均保留为独立风险；评审 APPROVE 不替代维护者 merge readiness。

我的整体评价

长程持续工作和用户体验均得到改善：合法观察不再被扣额先后顺序卡住，重放不会引导对已付费 Turn 再次推进。范围只覆盖原有准入与回执链，可独立测试和撤销；后续是维护者合并、安装任务升级与实际投研 Agent 当前 due/lease 的一次验收。兼容保留的是已有持久 receipt 和 provider 桥接，新增 helper 共享确切身份构造，无需更大框架；这次 bounded future-facing pass 已应用。仍不宣称完整跨平台发布或真实采用成功。

English verdict: APPROVE - exact head f876989; verified first post-settlement auxiliary admission and truthful replay without extra debit/delivery. Legacy/File/SQLite real-CLI comparison and focused regressions pass. Maintainer merge and post-upgrade live adoption remain separate.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

独立评审：#5171，完整 head f876989cfbd0afa1ebf5e7f07904edd1bd6f6d2a；不可变基线 d5354afc49078765a579bddc0bfcb78b470984a4。本次重新执行当前 policy11 的整份评审，未继承作者自评审结论。

动机

该 PR 解决现有辅助观察的一种合法顺序：主任务先完成 writeback 和一次 spend，独立、到期且有合法租约的 Monitor 随后首次观察。相同冻结输入在基线的 legacy、File、SQLite CLI 都被已结算状态误拒绝，留下零次观察和一次主任务扣额。这个拒绝会阻断 Monitor 更新 cadence；旧回放还可能继续显示原 Turn 未结算。本次验收针对这个明确缺口，未把它扩大为整条长期运行路线已经完成。

改动思路

观察准入与主任务结算分别沿用现有权威。TypeScript 先读取原 Goal、Agent、Todo、Turn 的精确已提交身份，再检查 primary 生命周期与观察者、due Monitor、普通 gate；provider 仍校验当前独立租约及 CAS。原任务已经支付不会成为观察的拒绝理由，也不会授予新的 delivery。返回时和精确回放时重新读取当前原任务进度，使 continuation 与已有 settlement_resume 对齐。该读回发生在 provider 边界后，保留其“当前”含义；直接复用可能陈旧的 preflight 快照并不等价。持久化历史回执继续表达当时事实。

具体改动

完整 diff 为四个文件 +143/-44，其中生产代码 +40/-14。双语协议明确披露过去的首次观察拒绝与现在的新默认，说明普通 Monitor 权限、单次扣额和独立工作必须取得新 Turn。Python 真实 CLI 测试以 spend_first 增加 legacy/File/SQLite 三种顺序；TypeScript 在 pending 与 settled 两种状态执行同一组拒绝边界，并覆盖首次观察及当前回放。没有新增模块、CLI 参数、配置开关或持久化字段，普通 Python transport、lease provider 与协议版本均复用既有实现。

关键代码讲解

• loopx/control_plane/quota/monitor_poll_commit.ts:544 readAuxiliarySettlement 统一构造精确 readQuotaSettlement 请求，禁用推断 Turn 与无绑定读取；准入与返回投影共享既有类型化结算规则。
• :556 auxiliaryMonitorAllowed 仅去掉 settled 排除条件。原 identity、open/done advancement、同 actor、claim/exclusion、due target 与普通 gate 仍须成立；它不能替代 provider 的当前 lease/CAS。
• :1499 projectAuxiliaryContinuation 只在执行的辅助观察、当前已验证 settled 时更新内存响应，设置 current_turn_settled 与 next_turn_required；不允许同 Turn 新的独立结算，也不写历史回执。
• :1890 replayDurableReceipt 继续通过原 artifact/index 校验恢复精确 effect，复制历史 payload 后再应用当前 continuation。File 回放中业务文件、索引与 Monitor transaction 回执不变。

对主干的风险

最强反例是：移除旧 fence 后，已支付的 Turn 被用来观察外部 Monitor、绕过租约或再次扣额。我在实际 File CLI 插入不存在目标、主 Todo 冒充 Monitor、错误 Turn、错误 target 和错误 lease key，全部拒绝并保留零新观察与一次既有扣额；错误租约时 canonical 独立读回完全相同。随后正确原请求成功，精确回放保持一观察、一扣额、settled 与 fresh-Turn 提示，resume.next_step 为空，没有 settlement_owed。150 个无关已完成 canonical Todo 的完整原路径也通过。

同一容器的前三项完整失败 payload 在两版逐字相同；错误 target 与错误租约的诊断优先级是有意变化：基线先报 settled identity conflict，新版分别进入 due target 与 provider lease_cas_mismatch 拒绝。不能把这两项写成字节 parity。普通非辅助 owner 的14组完整结果/错误则全部相同，无归一化。首版私有“整个 runs 目录字节不变”探针失败；补充诊断确认只变了 index.jsonl.lock 的锁 owner，所有业务历史不变，原失败保留。

语义与 CI 对齐

复用既有 settlement/Monitor 词汇和 TS owner，未引入另一个状态模型。当前 managed review 配置不读取远端 CI。受影响 admission 与 leased-monitor 的全部 native 测试 head 31/base 28 项通过（新版8项顺序测试、23项租约与进程恢复）；原三模块命令在 head36/base41 项成功后中断，额外77项通用 settlement 模块未完整执行，不能称整组通过，相关 TS head93/base81；声明的 TS typecheck、mypy20、focused Ruff、diff 与 DCO 通过。原输出预算检查在同命令、不可变 base/head 都失败：loopx_turn_plan/crowded/json emitted 14514 chars; baseline ceiling is 14500，38个预算/Turn 因果代码文件相同。根据当前评审契约归因，此失败对本 PR 代码结论不阻断；它仍是红项，严格质量资格及完整 premerge 保持 hold，未调高上限。

我的整体评价

代码结论为 APPROVE：它在现有 owner 内关闭已复现的顺序缺口，使到期观察在主任务已结算后继续产生实际结果，并让用户取得真实的当前恢复提示。真实 CLI 的重放、释放租约与重复 spend 验证了持续推进与单次效果，而不是只验证一次成功调用。未来改动的局部简化已落实为两个同领域共享 helper；没有必要增加状态框架或重写历史版本。前端/Lark 没有新增设置或专门 monitor-poll consumer，现有 CLI/managed 返回就是受影响入口，已实际验证。

批准范围是当前 source 行为；预算红项和严格 receipt/premerge hold 必须保留。没有验证新顺序的 PostgreSQL 实际 CLI、部署中的 managed consumer 或活跃 Goal，也未升级运行时或自行合并。维护者决定后续资格与合并；本次不把作者已有的 PG 补充测试计作独立新顺序证据。

English verdict: APPROVE - f876989; independently verified first due auxiliary observation after primary settlement, current replay and lease refusal/recovery; native 31/28, TS93/81 and full ordinary parity14. Unchanged base/head CLI budget14514>14500 remains red; strict qualification/premerge held. No live/PG CLI or merge claim.