[loopx-agent]

Revising the wait on an already deferred Todo is correctly refused without a lifecycle transition, but its recovery currently repeats the same inadmissible command. The diagnostic now offers the existing administrative resume, followed by a separately reviewed deferral with a new operation and current provider revision. It changes recovery guidance only: admission, retained lease history, ownership and execution authority keep their existing owners.

The real public CLI regression executes the emitted recovery and checks complete task preservation, stale CAS/proof and wrong-owner refusal, dry runs and replay after a newer wait. Active same/foreign holders remain fenced. Existing typed resume probing and retry construction are shared with the prior reopen diagnostic; no new protocol vocabulary or authority exception is introduced. English and Chinese recovery guidance is updated together.

Validation:

• The same new CLI oracle fails against the unchanged base and passes with the fix; the final four File/SQLite cases pass, including the later replay assertions.
• The broader Python administrative/lifecycle selection passes 34 tests. The deferred TypeScript module passes 14 tests.
• The administrative TypeScript module passes all 78 File/SQLite/isolated-real-PostgreSQL cases; the real PostgreSQL authority-store suite passes 382 tests. No live Goal is used as a fixture.
• Typecheck, focused Ruff, diff-scoped semantic advisory, full semantic inventory smoke, bilingual diff check and the public boundary scan pass. The semantic scan retains its documented unresolved coverage limits.
• An auxiliary PostgreSQL service run passes nine checks and skips one integration check; it does not establish full service qualification. No installation, model run, benchmark job, merge or long-horizon benefit is claimed.

Target: main. This is a bounded ordinary task-recovery correction; broader controller/executor contract convergence and installed host adoption remain separate work.

[loopx-agent]

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

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

未发现阻塞项。 审查 head 1212ccc10c57e365826e0c9f378f203ec67005ea；批准结论仅覆盖本次恢复修复。

动机 / Motivation

在 hard_lease 模式下，需要修改 deferred Todo 等待条件的当前任务 owner。

旧提示让 owner 重试被同一生命周期规则拒绝的 deferred→deferred 编辑；新提示先明确恢复为 open，再以新 operation 和最新 revision 重新延期，避免恢复循环。

实际生成的 CLI 恢复命令可执行；任务内容、claim 与已退役 lease 历史保留，恢复后通过新 claim 继续写入有效进展。

本 PR 不授予执行权限，不扩大同状态等待编辑，不改变 scheduler，也不替整个 Goal 证明长期收益。

改动思路 / Approach

该修复直接复用已有生命周期判定，共享恢复构造器足以解决真实命令死循环；扩大写权限反而改变边界。

当前边界是拒绝诊断到合法恢复和后续执行的完整路径，不包含新的执行准入。

这里需要的是能执行的恢复指引。继续允许 deferred → deferred 会增加新的准入语义；复用既有 open + clear_resume_when 可以保留当前 owner、旧租约历史与新的执行检查。新等待条件仍需独立理由、新 operation 和最新 provider revision，每一步都能单独回读。诊断本身没有执行权限，恢复后也要重新 claim，才能产生实际工作写入。

情况	旧诊断	当前 head
已延期，修改等待条件	重试同状态，仍遭拒绝	先恢复 open 并清除旧等待，再审核新等待
显式旧/部分 proof	拒绝并要求核验	保持核验，不降级绕过
恢复后执行	需要新 claim	仍需新 claim，旧引用不能复活

具体改动 / Changes

本次共 5 个文件，+187/-19。生产变更集中在 task_lease_proof.ts 的恢复描述构造，英文和中文参考说明同步；其余三处测试分别覆盖普通 CLI、延期生命周期和元数据编辑。canonical Todo 写入、延期准入、lease 获取与调度器都没有增加第二套规则。检索 base/head 的相邻 todo_update_admission.ts、todo_update.ts 与 todo_deferred_lifecycle.ts 后，确认本次直接复用了现有合法恢复条件。

关键代码讲解

• todoUpdateLeaseRecovery：从完整 canonical Todo、claim、lease 和实际 handoff mode 构造恢复信息。它先尊重显式 proof 和活跃 holder 的拒绝边界，再判断是否能合法恢复；输出是普通 CLI 参数，不能替 caller 完成授权。
• reopenRetry：让原有 blocked reopen 与新 deferred recovery 使用同一个命令构造路径。它清除旧等待条件，剔除不属于这次恢复的工作编辑字段，并要求新的 operation、理由与当前 CAS，减少两个恢复分支逐渐分叉的风险。

验证采用不可变 base 816a14b1f674736285cd7aa61dc1fb19594c90d2 与当前 head。相同的四个新增公开回归在旧 base 精确失败于返回 deferred 而非 open，在 head 通过。另一个独立 CLI 探针加入 52 个无关 Todo，并在第一次 lease 后创建新任务，检验同 Goal 内其他任务可编辑、外部 actor 被拒、旧 claim 无法重新执行、恢复不改历史，最后通过新 claim 实际写入并回读有效进展。它验证了恢复后继续工作的结果，未以错误码或一条成功回执代替整个路径。

验收基准是变更前的 docs/reference/handoff-mode.md，spec_revision=816a14b1f674736285cd7aa61dc1fb19594c90d2。审查标准逐项对应如下，head 中改写的说明不能自行证明这些旧要求已满足。

• Lease-proof rejections：Recovery is not permission; explicit stale or partial proof remains rejected. 已验证；28Python/92TS stale/active proof cases
• Resume with：Resume with status open, clear-resume-when and a reason; the next execution requires a fresh lease. 已验证；base4fail/head4pass and independent CLI continuation2pass

对主干的风险 / Risks

最强回归风险是把 owner 的恢复指引误当作执行授权，或恢复时丢失先前内容和 lease 历史。当前代码沿用 typed 生命周期判断，显式旧 proof 仍要求核验；真实 CLI 探针在恢复前后比较完整 canonical 快照，并在恢复后挑战旧 claim，再以新 claim 继续工作。它没有通过删除历史、扩大 owner 或增加同状态例外来“修好”恢复。

本地 PASS：28 项 Python、92 项 TS（File/SQLite/隔离真实 PostgreSQL，0 skip），控制面 typecheck、相关 Ruff、RFC/diff 检查、语义增量 advisory，以及 standard premerge 的 5 项直接检查和 19 项所选检查。旧 base 的四个失败是针对原缺陷的反例；最初私有验证 harness 的导入路径设置错误已留存并修正，未作为产品失败。没有查询或等待远端 CI。

本次没有新增配置、Actor 生命周期或通用协议词汇，也没有自动加载的 Agent 指令变更。恢复 prose 的 actor、顺序、理由、fresh operation/current revision、scope、停止与后续新 claim 要求逐项核对。模型是否理解并采用提示、持续团队成本是否下降仍未测量，不能由检查数量或本次批准推导。

我的整体评价 / Verdict

APPROVE。这个范围提供了可执行的恢复路径，并通过实际后续任务写入证明恢复后可以继续工作；额外框架或放宽准入都无必要。CQR 已记录并按当前范围验证有效。Inspected docs/reference/handoff-mode.md and task_lease_proof.ts: CLI diagnostics/reference prose only, no rendered presentation change. 模型理解与长期团队收益仍是未测量边界。本结论不代表整个 Goal 完成，不授予合并，也不替代 unchanged-head 的独立 merge readiness。

English verdict: APPROVE — head 1212ccc. No blocking finding; executable recovery and fresh-claim continuation verified locally. Merge authority is separate.