lhk229
7e3fd411a1
审查发现1：澄清恢复的锁序重排改为让出本轮，不再掐掉整批 resume
M1C-2b 为澄清 pending 新增的「drop 执行锁 -> 取项目锁 -> 重取执行锁」重排块，
两次取锁都用裸 `?`。执行锁的重取只等 25 x 10ms，而用户刚提交澄清回答时那把锁
会被 move 进后台续跑任务、持有整个 Provider 回合，稳超等待上限；错误经
recovery_scan 的裸 `?` 上抛，掐掉 for agent_id 循环里整批 Agent 的恢复，并把一次
纯瞬时的锁竞争直接返回给前端。
锁被占恰恰说明别处正在推进，是最不该判失败的时候。同一个 commit 里的姊妹代码
（planning session 恢复窗口）已经写对：项目锁按 transient 判据 continue，执行锁
用非阻塞 try_acquire 拿不到就 continue。
- AgentRuntimePendingActionResume 新增不带锁的 Deferred，表示两把锁都已释放、
本轮让出；批量扫描的三处 match 一律 continue
- 项目锁改为 transient 判据让路，其余错误仍带上下文上抛
- 执行锁改用 try_..._with_wait：等待宽限不变，超时是「本轮没轮到」而非「恢复失败」
- Runner 定向续跑不是批量扫描，Deferred 仍如实报错，文案沿用执行锁自己的措辞
- 回归 planning_clarification_recovery_defers_when_execution_lane_is_still_held：
按住项目锁把恢复卡在重排窗口，抢走执行锁后放开项目锁，断言必须 Deferred。
变异验证：回退成阻塞版 `?` 后该用例报出
"Agent Runtime 正在执行该 Agent 的其他任务：project-supervisor"
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 05:33:36 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-18 05:33:36 +00:00
2026-08-05 19:15:46 +08:00
2026-07-17 16:56:46 +08:00
2026-08-17 12:04:31 +08:00