[huangruiteng]

A benchmark or fleet Monitor can observe many cases, but monitor_changed:<todo_id> currently fences every waiter on one global generation. A terminal transition for one case therefore wakes unrelated waiting Todos and can trigger duplicate reconciliation or replanning.

This change adds an optional scoped form, monitor_changed:<todo_id>@<scope>, paired with quota monitor-poll --material-change-scope <scope>. LoopX retains a bounded scope-to-generation projection while preserving the existing global predicate unchanged. Provider receipts, replay/conflict checks, Todo projections, CLI adapters, and benchmark-toolkit guidance all carry the same scope. The Monitor refuses a 129th distinct scope instead of evicting evidence needed by an existing waiter.

The two new metadata fields extend the existing canonical Monitor metadata contract. TypeScript remains the decision owner; Python only validates and projects the same wire contract.

Original proposal validation (recorded at e58446bd; full-suite results below predate the recovery fix):

• full TypeScript control-plane suite: 6,158 passed, 77 skipped, 0 failed
• npm run typecheck:control-plane
• affected TypeScript suites: 121 passed
• provider receipt suite: 22 passed
• focused Python monitor/adapter/CLI suites: 138 passed
• examples/control_plane/quota-resume-gated-open-todo-smoke.py
• semantic-vocabulary-drift-smoke.py
• historical Todo read-model upgrade suite: 18 passed
• generated coordination contract check
• staged RFC bilingual check
• public-boundary scan over all changed files

Review follow-up

The scoped wait was accepted by public Todo authoring but checkpoint recovery interpreted a slash scope as part of the Todo identity, while a colon scope disappeared from its dependency basis. The fallback source selector also omitted the Monitor. This follow-up fixes those existing consumers without changing scope generations, admission, receipts, or quota policy.

• Checkpoint recovery and planning relations now share a dependency projection backed by the TypeScript resume parser.
• The existing Python read codec extracts the same scoped Todo reference for bounded fallback transport; TypeScript still owns readiness and fallback decisions. Only direct dependencies are transported; duplicate identities fail closed.
• Public File/SQLite regression cases retain the exact authored scope, reject stale dependency evidence, stop the isolated runtime, resume the original Turn, and replay without rewriting the original result or charging again.
• Integrated the proposal with main at 7e239ae4 using a merge, preserving the existing PR history.

Validation for the recovery fix:

• Regression sensitivity: the final six-case public CLI harness produced 4 failed / 2 passed before the fix (slash and colon scopes failed on both providers; global controls passed). After the fix, 6/6 passed, including verified runtime exit/restart and replay.
• 96 Python tests passed across checkpoint read context, provider fencing, fallback disposition, and resume adapters. This includes ownership, identity, concurrent writers, missing/replaced/stale contexts, bounded transport, invalid tokens, and global/scoped waits.
• 140 TypeScript tests passed across seven relevant suites: checkpoint read context, task graph, resume conditions, Monitor metadata, monitor-poll commit, canonical monitor-poll, and shadow outbox.
• Control-plane typecheck, focused Ruff, generated coordination contract, semantic-vocabulary drift smoke, RFC bilingual diff check, and git diff checks passed.
• Quota resume-gated-open-Todo smoke passed in an isolated runtime; public-boundary scan passed over all ten repair paths using an empty isolated registry.

The broader original full suite was not rerun for this follow-up. This is source-level recovery qualification; installed App/Lark adoption, live models, long-running benchmark outcomes, and independent approval of the new head remain separate.

[loopx-agent]

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

发现一个阻塞问题，结论绑定 e58446bd79641dbda55833760ffbe26209ee2599。

[P1] scoped 条件尚未接入现有 checkpoint 依赖解析。 公开 todo update 能接受 monitor_changed:todo_scope_monitor@case-a/run-1，但原 Turn 的 checkpoint-context 把整个后缀当成 Todo ID，报 checkpoint dependency todo_scope_monitor@case-a/run-1 is absent。scope 合法包含冒号时，例如 @case-a:run-1，旧正则则不匹配，返回的 basis.dependencies 为空。两种情况都已在真实临时 File 和 SQLite 上独立复现；完整源中存在该 Monitor，不能把读取遗漏解释成对象不存在。

动机 / Motivation

一个 Monitor 同时观察多个对象时，等待其中一个对象的 Agent 会被无关变化唤醒。
原来对象 B 的变化也会唤醒等待对象 A 的任务；新 scoped 条件能隔离这次唤醒，但当前版本尚不能完整通过既有 checkpoint 恢复。
已验证独立 scope 的 generation 隔离；真实 File/SQLite 恢复仍会报错或漏掉依赖，交付需补齐这一现有消费者。
本评审不执行 benchmark、模型、安装或合并，也不把合成检查当作实际长期收益。

改动思路 / Approach

计数仍由既有 TS Monitor owner 管理是合理的；依赖身份却继续由多处字符串拆分解释，必须复用同一 scope-aware parser，才能让恢复与规划读取同一对象。
在本 PR 内补齐 checkpoint 与 fallback 的 scoped 依赖解析和真实恢复回归；无需引入新调度器或扩大为整个 benchmark 重构。
设计仍利用既有 Monitor observation、provider CAS 和 receipt。每次匹配变化记录该 scope 对应的 generation；等待任务保存同一 scope 的 baseline，独立工作继续可执行。单独为每个对象建 Monitor 是更小的既有替代，但会增加 watcher 数量；扩展共享 owner 可以合理成立，前提是原有恢复路径完整采用它，不能只让新 parser 和 serializer 互相证明。

具体改动 / Changes

改动前规范为 docs/project-agent-todo-contract.md，版本 ac62962255322cd80a5b701a4187c6f47bc17d8c。文档无这些条款的编号，本评审使用定位标签：MON-generation-fence 对应原 generation/replay 和独立工作规则，局部实现通过；MON-current-recovery 对应完整依赖及现有恢复边界，目前不满足。

关键代码讲解

• advanceMonitorScopeGeneration 在既有全局 generation 旁保留 scope 摘要到最新 generation 的映射；最多 128 项，第 129 项拒绝，保留旧等待证据。它是派生投影，不是新的授权 owner。
• parseResumeWhen 新接受 @scope 并分离 Monitor ID，但这个解释没有到达 checkpoint_read_context.dependencies 和 select_fallback_source_items。后者仍把含 scope 的完整 target 交给 Todo ID normalization，也会漏掉直接依赖。
• observationObject 将 scope 绑定 material observation、provider plan、receipt 与 replay 冲突；这一传输路径的定向测试通过，但不能覆盖上述缺失消费者。

完整 diff 为 42 路径 +658/-46，包含两个既有 canonical metadata 字段扩展、CLI/投影/历史 codec、文档和回归。没有因为局部 green 而把整体恢复视为完成。

对主干的风险 / Risks

独立 PASS：六个 TS suite 共 127 项、零跳过；五个 Python 模块共 184 项、零跳过；control-plane typecheck 通过。quick 的机械检查通过，仍保留 benchmark_sensitive 人工评审 hold。未查询或等待 CI。

独立 FAIL：同一六案例 harness 先通过公开 Todo 更新并核 canonical readback，再运行原 Turn 的真实 checkpoint-context。两种 provider 的 global control 均成功带回 Monitor；slash scope 两例报错，colon scope 两例缺少依赖，最终为 4 failed / 2 passed。最早的测试导入错误和后续直接种子版本另存；上述结论来自改正后包含公开 authoring 的完整复现，不把 harness 错误算产品回归。

语义与 CI 对齐

最小修复是复用同一 scope-aware typed parser，更新当前 checkpoint 与 fallback 的目标提取，完整保留 Monitor 来源。回归须从公开更新经过真实 File/SQLite 的原身份恢复，覆盖无 scope、slash/colon scope、缺失目标、依赖变化、重启和重放；不得靠删 scope、改成全局等待或删除原回执绕过。现有未绑定输出及所有 receipt 的完整 base/head parity、App/Lark scoped 操作旅程仍未资格；这些未知保留，不要求本 PR 运行模型或承包长期 benchmark。

我的整体评价 / Verdict

局部 scope 隔离已得到证据，但当前整体延续能力有回归，用户可能被困在不能完成的 checkpoint 恢复。计数 owner 的放置可以保留；依赖解析应在本 PR 内统一，避免长期维护多套字符串语法。共享 vocabulary 的扩展尚未与所有当前消费者对齐，因此当前 head 不能批准。本 PR 没有渲染页面差异；已检查现有 Todo/Monitor 展示与 native steward 调用，问题在共享恢复路径。scoped 操作的完整 App/Lark 旅程、真实安装采用与长程收益未验证。

English verdict: REQUEST_CHANGES

[loopx-agent]

[P1] 新 scoped token 需要同步更新现有 checkpoint/fallback 依赖读取器。公开 todo update 接受 monitor_changed:todo_scope_monitor@case-a/run-1 后，真实 File/SQLite 的 checkpoint-context 都报 checkpoint dependency todo_scope_monitor@case-a/run-1 is absent；合法 @case-A:run-1 则得到空 basis.dependencies。两组 global control 均正常。请让 checkpoint_read_context.dependencies 和 fallback_source.select_fallback_source_items 复用同一 scope-aware target parser，并补公开更新到原 Turn checkpoint 恢复的两后端回归，保留 scope 和原回执。

[loopx-agent]

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

[P2] 让不同范围的相同结果各自推进。 同一个 Monitor 上，让 A、B 各提交一次 --material-change，分别带不同范围，内容摘要相同。在 File 和 SQLite 上，A 唤醒自己的任务；B 带后续任务提交时被拒，去掉后续任务则返回成功，但 B 仍不可运行。这里用 Monitor 全局的上次摘要决定 advances，B 的范围代次因此不更新。请在既有事务里按范围区分新结果，同时保留全局规则和精确重放；用 A、B 同摘要、各自重复的用例覆盖。 monitor_metadata.ts:204

[P2] 在缺少后续任务的修复指引中保留原范围。 执行 todo update --resume-when monitor_changed:todo_public_watch@case-b/run-2 但缺少独立后续任务时，两种存储均返回不带范围的 waiting_todo.resume_when，轮询配方也没有范围参数。按指引重试会让 A 的变化重新唤醒 B。请把 Monitor ID 和规范化的范围条件分别传给诊断，并让实际 CLI 负例验证原条件和匹配参数都保留。 provider_update.py:197

动机 / Motivation

一个 Monitor 可以替多个用例或运行跟踪结果。等待某次运行结果的任务，应该只在那次运行有实质变化时继续。 例如 A 已结束、B 仍在跑。原来的全局等待会被 A 的结果一起唤醒，B 的任务可能重复检查还没就绪的结果。 这次为等待和轮询加入同一个范围标识。实测 A 能唤醒 A 和全局等待；但 B 若产生与 A 相同的结果摘要，B 的等待仍停在原地。 这个改动只负责从观测恢复任务，继续沿用原 Todo、租约和写入权限。

要交付可用的范围等待，还需要让不同范围的真实变化独立推进，并让修复指引和前端操作保留原范围。

改动思路 / Approach

调用方在 Todo 的恢复条件和 Monitor 的轮询里使用同一范围。既有 TypeScript 事务继续负责观测、代次和后续任务，Python 负责传输和读取。直接沿用全局条件会重复唤醒；每个用例另建 Monitor 会重复调度和领取。共享 Monitor 的范围条件值得做，但只有每个范围能独立推进，才减少这些重复工作。旧恢复错误已修复，当前两个失败都发生在新范围的常规操作里。继续用现有事务，在交付前补齐独立推进和修复指引。本次范围是恢复条件、权威观测和依赖读取。

具体改动 / Changes

关键代码讲解

• poll 从原 Monitor 读上次结果摘要，再决定是否调用 advanceMonitorScopeGeneration 更新这次范围。当前摘要比较跨范围，因此同内容的 B 被算成 A 的重复。需要在现有事务中区分范围证据。monitor_metadata.ts:204
• todoResumeDependencyId 从已校验的条件取 Monitor ID，范围仍留在等待条件上。dependencies 用这个 ID 读原任务的依赖；Python 的 bounded fallback 同样只补实际 Monitor。resume_condition.ts:254 checkpoint_read_context.ts:24 fallback_source.py:145
• _raise_public_update_rejection 也取出了实际 Monitor ID，但结构化指引只收到这个 ID，丢掉了原等待范围。provider_update.py:197

以修订 7e239ae4a3e3738208c50da4b742ccba63e43356 的 docs/project-agent-todo-contract.md 为规范。Monitor generation fence 和 Independent advancement 在 B 的合法事件中未满足；Typed authoring and replay 的原回执恢复已复验，但修复指引仍丢范围；Existing global waits 的就绪、代次和历史回执保持。GitHub 旧基点显示 259 个路径；212 个额外路径已进主干。以共同祖先 7e239ae 核对 47 路径 +811/-63。当前主干 c0b6ade 的模拟合并干净，同 47 路径的净行内容一致。

对主干的风险 / Risks

验证	观察
PASS · 原 checkpoint 恢复	File 与 SQLite 上，修复前同一 CLI 用例为 4 失败 / 2 通过，当前头 6/6。斜杠和冒号范围都保留原 Monitor 依赖；旧依据会被拒，重新读取后补齐原 Turn，重启和重放不改原回执、不再扣额。
FAIL · 两个范围的相同摘要	A 和 B 使用同一个 Monitor 和两次独立观测。把同一份终态内容的摘要用于 A 和 B，A 推进到 1。B 请求创建独立后续任务时被拒；仅提交观测则返回成功并追加回执，但 B 的范围代次保持 0，Todo 仍待恢复。换一个摘要后，B 推进到 2 并可继续。File 与 SQLite 一致。
FAIL · 缺少后续任务	缺少后续任务时，CLI 返回的结构化修复指引把 monitor_changed:todo_public_watch@case-b/run-2 写回成 monitor_changed:todo_public_watch，且轮询参数没有范围。按该指引修复会重新绑定全局等待。
PASS · 无范围对照与容量限制	未指定范围时，基线与当前头在 File 和 SQLite 均保持同一结果：未变化不唤醒，首次变化唤醒，同摘要不再次增加代次。当前公开回执的嵌套 transition 仍新增两个 null 字段；旧输出没有它们。 SQLite 实际轮询中，第 129 个不同范围被拒，权威状态和运行索引逐字保持；已有范围仍可推进，保留 128 个范围。
PASS · 聚焦与静态	184 项 Python、64 项 Monitor 兼容性测试、140 项 TypeScript。类型检查、工作流范围 Ruff、生成契约、双语 RFC 和差异检查通过。
FAIL · 本地标准预检	标准本地预检 6 项直接检查全通过，19 项选定检查中 18 项通过，语义词汇 smoke 在 120 秒门限超时。 同命令单独复跑通过；原批次超时保留。
GAP · 操作入口	以实际 Task 编辑器使用的解析器验证：todo_done 通过，旧 Monitor 条件和新斜杠／冒号范围均返回 null，Review 按钮会禁用。编辑器能展示已设的条件和状态；该验证只覆盖源码的输入门。 参见 todo-resume-condition.ts:2、context-drawer.tsx:773 和 现有交付要求。

语义与 CI 对齐

新增两个字段扩展既有 Monitor 元数据词汇，TypeScript 仍是写入和就绪判定的唯一来源。第 129 个范围的拒绝不会丢失既有证据。未指定范围时的业务行为保持，但旧回执形状新增了两个空字段，建议省略或明确记录。核心用例和结构化指引的失败都在本地复现，托管 CI 状态未查。独立验证覆盖源码 CLI、真实 File/SQLite 和 Task 编辑器的输入函数。未验打包 App、Lark 操作、真实模型、长时间运行或 PostgreSQL；没有查询托管 CI。

我的整体评价 / Verdict

请求修改当前提交。前一轮发现的原任务恢复问题已经解决；实际轮询仍可能让第二个用例永久等不到自己的结果，错误指引也会让修复后的等待重新跟踪全局。在现有 TypeScript Monitor 事务中，以范围和结果证据判定 scoped 变化，保留未指定范围时的原全局规则和原 effect 的精确重放。让修复响应携带原 scoped 条件和对应轮询参数，沿用同一 typed authoring owner。 保留现有 Monitor 所有权，补齐已有 Task 操作入口的可用路径和读回；无需另建调度或授权机制。下轮以两种存储的等摘要反例、精确重复和结构化修复后的实际唤醒结果复验。

English verdict: REQUEST_CHANGES for 52b22068f8f53555d91772005d030bed72ea5d47. Distinct scopes can suppress each other's material transition when their results share a digest, and the public repair recipe drops the requested scope.

[loopx-agent]

[P2] 让不同范围的相同结果各自推进。 同一个 Monitor 上，让 A、B 各提交一次 --material-change，分别带不同范围，内容摘要相同。在 File 和 SQLite 上，A 唤醒自己的任务；B 带后续任务提交时被拒，去掉后续任务则返回成功，但 B 仍不可运行。这里用 Monitor 全局的上次摘要决定 advances，B 的范围代次因此不更新。请在既有事务里按范围区分新结果，同时保留全局规则和精确重放；用 A、B 同摘要、各自重复的用例覆盖。

[loopx-agent]

[P2] 在缺少后续任务的修复指引中保留原范围。 执行 todo update --resume-when monitor_changed:todo_public_watch@case-b/run-2 但缺少独立后续任务时，两种存储均返回不带范围的 waiting_todo.resume_when，轮询配方也没有范围参数。按指引重试会让 A 的变化重新唤醒 B。请把 Monitor ID 和规范化的范围条件分别传给诊断，并让实际 CLI 负例验证原条件和匹配参数都保留。