[loopx-agent]

当 Agent 在缺少执行证明时完成或取代任务，终结操作只返回底层拒绝，调用方容易转去手动检查和获取租约。现在该拒绝会先复用普通 todo claim 的真实 dry-run 准入判断：可认领时返回普通认领命令，并用返回的 claim_operation_id 重试原终结操作；不可认领时保留实际准入原因。

预览不授予执行权、不修改任务，也不自动获取租约。显式过期证明和无效托管引用继续走原有拒绝路径。普通 Markdown 恢复提示省去 Host 专用参数，JSON 保留原拒绝及类型化恢复数据。

验证：

• 真实 CLI 的 File / SQLite 回归测试：22 passed；同一新增回归对基线执行，两种后端均因缺少 recovery 而失败。
• 最终聚焦的 File / SQLite 执行权与恢复检查：6 passed，覆盖拒绝后不写入、真实认领后完成、完成重试不重复释放，以及不可安全认领的负例。
• 隔离 PostgreSQL 16.15：authority-store 381 passed、authority-service 11 passed，0 skips；测试容器已清理。
• Control-plane typecheck、差分检查、DCO、语义增量检查与 RFC 双语检查通过。
• 在显式固定当前检出目录的导入来源后，标准源码 premerge 通过：全部 16 项 smoke、差分/编译/RFC 双语检查通过，0 warnings，原 120 秒门限不变。此前两次 console-script 运行缺少实际导入来源记录；后续复现了继承路径导入安装版的情况。旧超时记录保留，不作为当前源码资格；单次扫描时间不证明稳定性能提升。

改动复用既有任务认领和终结 owner；只抽取了同域测试夹具以复用验证。未新增命令、设置、权限 owner 或独立产品入口。此提案尚未证明在长期运行中减少总成本；不把测试通过等同于实际采用或效果收益。

[loopx-agent]

Reviewer: actor_kind=model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=max

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

动机 / Motivation

Agent 在硬租约模式中完成或替换任务时，缺少当前执行证明会被拒绝。

补丁让完成任务的拒绝响应建议普通 claim，再引用返回的执行标识重试；同一分支也给 supersede 发出该建议，而公开 CLI 拒绝这个参数。

complete 的恢复链可运行；supersede 的新建议在取得租约后仍无法执行原操作，需要收窄命令范围或补齐公开契约。

本次审查不改变合并权限、配额记账、租约授权或前端配置，也不证明长程团队收益。

普通任务的最短有效恢复路径是复用现有身份完成准备，再重试同一操作并读回结果。没有缺失的用户决定时，不应要求人工复制租约内部字段；同样，自动生成的下一步必须由公开入口接受。成功返回一份预览或取得租约，都不能代替终结操作真正完成。

改动思路 / Approach

终结拒绝复用普通 claim 的只读预览是合适归属；建议必须按公开命令能力生成，投影不能宣称 consumer 尚未接受的参数。

当前边界是无执行证明时的终结恢复建议与 Markdown 展示；普通 claim、显式证明和终结写入继续由现有 typed owners 处理。

executeCoordinationTodoTerminalLifecycle 先完成原有身份、状态和权限判断。仅在缺少证明的拒绝后，调用现有 executeCoordinationTodoClaim 的 dry_run，从完整 canonical provider head 得到资格预览。预览异常被隔离，原拒绝仍是权威结果。真实 claim 与重试继续重新检查当前所有权、排除条件、依赖和写入范围，设计归属合理。

当前缺的是命令能力判断：共享终结 owner 同时处理 complete 和 supersede，新分支却给两者都生成要求执行标识的建议。公开契约只为 claim/update/complete 接受该参数。最小修复是把这份建议限定为支持引用的命令；若确实要扩展 supersede，应将参数校验、Python adapter、引用转发及真实终结回读一起完成。

具体改动 / Changes

审查提交为 2c936402bc79119e25d366c66b0d7363d7fe5f35；4 个文件，+143/-12。生产 TS 增加拒绝后的普通 claim 预览；Python Markdown 对 claim_task 隐藏 handoff_mode；Python 测试增加 complete 恢复闭环；TS conformance 增加无副作用、资格拒绝、预览失败和原终结重放覆盖。没有新数据库、设置或租约权限。

关键代码讲解

1. executeCoordinationTodoTerminalLifecycle 以 hard_lease、Agent role、未携带显式证明及两个既有拒绝码为条件调用 dry-run claim。它正确保留原拒绝，也明确写出预览不授予执行权，但遗漏 input.command 的公开能力范围。
2. executeCoordinationTodoClaim 是复用的现有资格与 CAS owner。dry-run 在提交前返回；真实 claim 仍检查排除、依赖和重叠范围。complete 引用结果后可以终结并释放一次，原操作重放不再次写入。
3. _render_lease_recovery 只投影结构化建议，但其条件也命中已有 update 恢复，所以可见诊断变化不只限于本次新增 complete 路径。

规格基准为 docs/project-agent-todo-contract.md，版本 2f544f969236f5dbbe858720108c41d07be60a6c。Write Contract implemented：预览和拒绝无 provider 写入；Administrative edits and explicit execution proof implemented：显式部分或异主证明不被丢弃、替换；Lifecycle Contract not_met：新生成的 supersede 恢复无法经公开 CLI 进入原终结操作。

对主干的风险 / Risks

[P2] 不要向 supersede 建议其公开入口拒绝的执行引用。 在隔离的 File 与 SQLite provider 上，给 open、可执行的 Agent Todo 发出无证明的 todo supersede，新分支返回 claim_task，随后要求 todo supersede --claim-operation-id。照此执行时普通 claim 成功，重试却返回 --claim-operation-id is supported only by todo claim/update/complete，Todo 没有终结，已取得的执行租约仍需按原 owner 处理。

这个反例在当前 head 两种 provider 上均失败。不可变基线只有原拒绝，没有这份误导性建议；因此问题来自新增分支的命令范围。可在此分支加 complete 限定，保留 supersede 原有恢复边界；若扩展公开契约，则应在同一修复中补齐前述 consumer。不能通过省略证明或重试前清理权限检查使测试通过。

本次独立验证未查询或等待 GitHub CI：

• PASS / FAIL：两个恢复测试文件在当前 head 为 34 通过、4 失败；complete 新增真实 File/SQLite 恢复、重放和严格证明用例通过。
• PASS：不可变基线的同组现有用例与两项独立 supersede 对照共 38 项通过；专门的同脚本 supersede 对照两项通过，均无误导建议。
• FAIL：当前 head 的公开 supersede→claim→原命令重试反例，两项均被参数校验拒绝；重试没有额外终结写入。
• FAIL：4 个既有 active/released、File/SQLite update 恢复用例缺少原 Markdown handoff_mode 行。JSON 仍保留该字段。应恢复预期作用域，或明确说明并验证这个共享展示变化后更新相应期待，保留当前失败记录。
• PASS：TypeScript typecheck 与 File/SQLite 的 24 个具名 managed-execution 用例通过；另一个按名字过滤后没有匹配用例的文件不计入该覆盖。
• PASS：真实隔离 PostgreSQL 16.15 authority-store 381 项、authority-service integration 2 项通过，均无跳过，临时容器已删除；没有使用活动 Goal 或生产数据库。
• PASS：标准 premerge：6 direct checks; 16 selected; gate passed; failures []; manual holds 0。选中检查通过没有覆盖公开 supersede 参数反例，也未抹去单独执行的失败用例。

语义与 CI 对齐

继续复用既有 claim_task、执行引用及 typed 拒绝码即可，没有新增词汇注册或迁移需要。此处是恢复建议覆盖了不支持的命令，现有权限判断本身仍严格。复审至少需要公开 File/SQLite 的 supersede 恢复结果和重放、complete 正向路径、显式证明与阻塞负例，以及共享 Markdown 用例的清晰处置。

我的整体评价 / Verdict

当前结论为 REQUEST_CHANGES，阻塞点是公开入口无法执行生成的恢复方案。生产机制的体量和 owner 选择合适；缺口可通过同域的小改动完成，不需要拆出新的授权或恢复框架。用户体验与连续工作记为 regression：部分调用者会先取得租约，再进入原本没有的新重试死路。

检查了 Todo CLI 与共用 Markdown 错误投影；本 PR 没有渲染页面改动。 无渲染页面需要验证；真实模型或已安装应用采用未验证。

不可变基线与当前 head 的对照保留了完整错误、参数和状态回读，没有把相同拒绝码当作语义等价。claim 预览不授予权限，原有历史 receipt、显式证明及 provider 兼容路径应继续保留。本次源码和隔离数据库验证不能证明已安装体验或长程收益，也不构成合并授权。

English verdict: REQUEST_CHANGES at 2c936402bc79119e25d366c66b0d7363d7fe5f35 — supersede receives an unsupported claim-reference retry on File and SQLite. Standard premerge and PostgreSQL checks pass, but this public recovery path and four shared rendering expectations remain unresolved.

[loopx-agent]

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

未发现当前 head 的阻塞问题。此为独立代码评审结论；合并仍需单独的权限与 readiness。

Reviewer: actor_kind=model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=max

Exact head: 7e23a7859814a9f6dfbc9aefbc2ca5cf020e9e14；whole-PR base: 2f544f969236f5dbbe858720108c41d07be60a6c。审阅完整 base-to-head diff，并核对当前 target main 225698b313f3bcd5c967220013b4a2254c586792；没有沿用作者验证作为独立验收。

动机

受影响调用方：以 hard_lease 执行普通任务、在 complete 缺少执行证明时需要恢复原操作的 Agent。

原 complete 只拒绝缺少 lease/proof；新响应先用现有 ordinary claim owner 做只读资格预览，合资格时给出 claim 再重试原 complete 的指引。

可观察结果：独立 File/SQLite 真实 CLI 验证无写预览、普通 claim、原 complete 重试、幂等重放及后续任务的 claim/update；原 supersede 拒绝和共享 update 展示保持不变。

边界：不扩展 supersede 的公开 claim 语法，不自动 claim 或授予执行权，不认证已安装宿主、真实模型采用或长期完整成本净收益。

改动思路

接受契约为 docs/project-agent-todo-contract.md，spec_revision 2f544f969236f5dbbe858720108c41d07be60a6c。映射 criterion_id Write Contract、Lifecycle Contract、Administrative edits and explicit execution proof：普通写操作必须由当前 canonical authority 和原 operation identity 决定；complete 不能凭历史 receipt 获取执行权，恢复也不能悄悄产生 claim。

流程为 complete 缺证明 → 原拒绝 + ordinary claim 的 dry-run 预览 → 调用方显式 claim → 用返回的 claim_operation_id 重试原 complete。预览不授权、不写 Todo/lease/receipt；实际 claim 会再次检查当前资格。这个边界比复制一套 eligibility 或教调用方拼 raw lease 字段更清晰。

复用 executeCoordinationTodoClaim 的 dry_run 和既有 typed terminal refusal；Python 仅渲染结果，不能猜测 claim 资格或新增执行 owner。

本次边界：只修复 complete 的可执行恢复指引与对应显示；supersede 不再收到其不支持的 retry 参数。

具体改动

• executeCoordinationTodoTerminalLifecycle 只在 Agent hard_lease、complete、缺少显式 proof 且原 typed refusal 为相应原因时做预览；显式 stale/foreign proof 不自动刷新。预览不可用仍保留原拒绝。
• executeCoordinationTodoClaim 仍是唯一 ordinary claim 资格 owner，沿用当前 source、注册、排除/阻塞、scope、lease 冲突和 CAS 检查。dry_run 返回前不会进入 commit。
• _render_lease_recovery 仅在 claim_task 且 retry 为 loopx todo complete 时收窄 mode 展示，既有 update 消费者保持原输出。

这是完整五路径 +157/-12 的重新评审。相对前次 2c936402bc79119e25d366c66b0d7363d7fe5f35，当前 7e23 的修复分别限制 complete 和 Markdown selector。前次关于 supersede 收到不支持的 --claim-operation-id retry、以及共享 update Markdown 漂移的发现，已分别用原反例和完整共享测试独立核验；旧发现和讨论保留。

本次独立执行：原 handoff/claim 模块 34 项、完整 task-lease recovery 模块 40 项、File/SQLite/NoKV managed-execution conformance 39 项全部通过。冻结真实 CLI probe 在 base 上得到两个 complete 缺恢复指引的预期失败、两个 supersede parity 通过；当前四项均通过，继续验证实际 ordinary claim、原 complete retry、无变更重放，以及新 successor 的普通 claim/update 确实持久化。

使用隔离的真实 PostgreSQL 16.15、分离数据库和合成 tenant，完整 store 382 项、service 2 项通过，零跳过；仅本次拥有的容器已删除并读回不存在。初次初始化探测曾撞到临时 init server，属于测试准备失败、尚未运行产品测试；改为 final server 的 TCP readiness 后完整重跑，没有改产品或降低 gate。TypeScript typecheck、Ruff、changed-path Ruff、mypy 和标准 premerge 通过（6 项 direct checks，18/18 项 selected checks；零失败、零 manual hold）。

对主干的风险

最强风险是诊断变成隐式 claim，或恢复指令与实际 public grammar 脱节。独立状态/provider revision 快照和 TS conformance 覆盖无效证明、不可执行 actor、阻塞/排除/重叠 lease、观察失败、幂等与 release-once；真实 CLI probe 证明恢复可继续原意图及后续工作。supersede 在当前边界内保留原拒绝，没有借修复扩展其语法。

没有新增状态 owner、持久 schema、权限或默认自动执行。现有 soft/advisory 和共享 update 路径保留；不将 preview 的 reason 或历史 receipt 视为授权。没有修改生产 Goal、registry 或活动 lease 以测试。DCO、完整 diff/GH 路径、公私扫描和 source 清洁检查通过。wait_for_ci=false，没有查询、轮询或等待 CI；无渲染视口变化。已安装宿主、真实模型采用和长期完整成本收益仍未验证。

我的整体评价

当前 head 已修复前次两个具体阻塞，且完整 PR 的动机、existing-owner 复用、authority 边界、真实恢复和后续任务路径均有独立证据。简化已通过限制 complete 范围和复用 ordinary claim 完成；没有必要引入新的恢复框架。代码批准不撤销任何尚未独立授权的 dismissal/merge gate。

English verdict: APPROVE. Complete-only ordinary-claim recovery is non-authorizing, executable, and independently verified across the supported authority paths.