模型调度设计审查

节点已写 claimed/start_requested 收据、尚未获得 start 确认时崩溃；中央 expire 把任务回 queued 并清 machine_id/lease_token。重启后 recover 携旧令牌补报 complete 被 409 拒绝却仍 halted；acknowledge 要求远端 machine_id 等于本节点（queued 或已换主时 403）；中央 release 只接受 needs_reconciliation。收据文件名仅按 task_id 命名，同节点重领原任务也被旧收据拒绝。

一次执行前崩溃 → 该节点 worker 此后每次启动都因旧收据退出 2，原任务与后续任务都无法经现有入口继续，须人工改收据。

修复方向：收据按租约（lease_token/attempt）区分执行尝试；提供「核实旧租约未启动且已失效 → 封存收据」的可审计确认入口，保留旧令牌隔离。

start 子命令捕获所有异常后，只按「任务当前是否 running」判断，便写 needs_infra_review、halt campaign、记 unknown_completion——不核对本次调用是否取得启动权。执行者 B 的重复/迟到请求在入口被正确拒绝，却把执行者 A 正在运行的任务改写；A 的 runner 继续跑，账本不再表示其状态，整批停派。

A 已启动求解并阻塞等待 runner；B 并发调用同一实例 start → B 被拒 → CLI 异常处理把 A 的 running 改 needs_infra_review + campaign halted。

修复方向：未知完成处理限定在本次调用成功提交启动权之后；状态更新加本次尝试身份条件；补经 CLI 入口的重复启动回归测试。

Pipeline 允许 lane_solver_limits A=1或2/B=1（e2_pipeline.py:77，ready 模板已配 A=2）；但 install_guards 的 e2_dispatch_guard trigger 固定「同 lane 不得已有 solver」——装了 guard 的账本上第二个 A 在 UPDATE running 时被 ABORT。不装 guard 时，queue.start 事务只原子检查全局<2，不查 lane：两个不同 state_db 的控制器可各启动一个 B，突破 B=1。

带旧 guard 的账本 + A=2 配置 → 第二个 A 通过 Pipeline 准入后被 SQL 拒绝，作业失败并停派；无 guard + 双控制器 → B 路双开。实际部署账本是否装 guard 未核验（须逐账本查 trigger）。

修复方向：把冻结 lane 额度纳入账本原子启动检查；显式迁移或拒绝不兼容的旧 guard。

准备/后处理阶段用 subprocess.run(timeout) 终止直接子进程，但不在阶段所有者处核验后代进程或容器停止。阶段 TimeoutExpired 退出被 worker 视为普通 failed，协调器立即释放槽位与内存预留。

preparation_command 已启动本题容器，setup 阻塞超过 preparation_timeout → 外层 Python 杀 helper、finally 无法执行 → Docker 容器继续由 daemon 运行；节点领取新任务时旧容器仍占 CPU/内存。后处理创建独立资源时同窗口。

修复方向：阶段所有者核验后代/容器停止；无法确认清理时上报 needs_reconciliation 而非普通 failed。

Agent 达到 job_timeout_seconds 或状态查询抛错后，worker 直接提交 needs_reconciliation 并移除活动任务，不调用已有的取消+idle 核验路径（该路径存在于 cancel 流程：机器 online、execution/phase idle、无 activeTurn、queuedTurnCount=0）。中央保留预留（正确），但会话继续执行消耗资源与模型额度。

已取得 session/user turn 的 Agent 持续 busy 到截止 → worker 上报未知并退出监督 → 底层会话继续跑；此后调协调器 cancel 只返回已有未知状态。HANDOFF 记录过实际超时后 session 仍 busy、须人工取消并确认 fresh idle 的事件——该流程未固化进超时代码。

修复方向：到期时先尝试精确取消并核验停止；无法确认再保留未知态交人工对账。

常驻 run 在清理前确定退出码，随后立即设置 _heartbeat_stop；同一个 Event 又控制 Agent 监测与取消确认。它让正在等待状态的 Agent 直接走超时出口，或让取消确认在首次 busy 观察后提前截断（stop_timeout 10s < cancel_timeout 45s）。

Agent 刚查询到 busy、等待下次轮询时收到 stop → 主循环先选定返回 0 → finally 设 _heartbeat_stop → 任务线程被唤醒后直接报 agent_job_timeout，未发送 Lody 取消；已选定的返回值不再改变。另一路径：取消已发送但首次查询仍 busy，等待事件提前截断后续 idle 确认。

修复方向：停止确认完成后才关闭监测；退出码按最终清理状态确定。

MCP create 请求未返回身份时，取消或超时退出唯一消费回包的路径；迟到身份不持久化，也不用收据里的稳定 operationId 走 resume 找回。拒绝重放避免了主动重复 create（正确），但无法找回并停止已受理的会话。

Lody 已受理 create、回包在途时协调器要求取消 → worker 记录 create_pending_without_session_identity 并退出 → 底层会话随后开始执行，回包被丢弃；重启只上报未知态。

修复方向：按原 operationId 做身份对账与停止流程（服务端 resume 合同已存在）。