lhk229
e43133875a
修通审批卡「修改/退回」路线：claim 重放冲突、park 死锁、返工额度串用
生产实测：出 GDD 后点「修改」而不是「批准」，修订委派从头到尾建不出来。盘上现场
（gameagent-c6948da6 / gameagent-347c9786）逐层剥出三个独立缺陷，前两个叠在一起，
修掉上层才露出下层。
1. claim 快照与 delivery 全等比较
claim 的 structuredResult 是「父 Agent 当时观察到了什么」的冻结快照；审批把
delivery 从 EvidenceReady 原地改写成 UserRevisionRequested 后，快照仍停在
EvidenceReady。claim 提交（含幂等重放）按全等判，于是 agent.run_status 每次
重放都 failed，Supervisor 永远拿不到回执。实测空转 43 轮，报「静态委派 claim
与 delivery 身份或结果冲突」。
改为「delivery 是不是 receipt 的合法后继」：除 contractStatus 外每字段逐字
不变、且方向唯一（EvidenceReady → UserRevisionRequested）才放行。原型没有
claim 这层快照，单一真相就地改，结构上不存在这个冲突。
2. park 死锁（被 1 掩盖）
修掉 1 之后 barrier 能正常求值了，userRevisionPending=1 却被
has_waiting() 计成「有在等的委派」，main_loop 于是 park 成「等待专业 Agent
委派回执 / 回执全部 ready 后自动唤醒当前父 run」——那条回执只能来自本 run
自己要创建的修订委派，等的是自己。实测 8 分钟零事件。
has_waiting() 里那个计数是承重的：三处自动恢复路径靠它挡住自动唤醒，
runtime_tools/delivery.rs 现场还有 debug_assert 钉着这份依赖。所以不动它，
另加 has_external_wait()（只计 waitingDelegations / unknownContractStatus），
两处 park 决策点改用它。两个谓词问的是相反的问题：自动恢复该不该收手 vs
当前这轮该不该 park。落进 main_loop 本来就写好的 user_revision_pending 分支
（phase=planning、next_step=调用 agent.delegate）即可。
3. 用户修订与质量返工共用「唯一返工轮」文案
用户修订跳带 repairOfDelegationId 但不是澄清续跑，落进 Repair 分支拿到
「这是对已认领委派 X 的唯一返工轮」——用户第一次点修改就被告知只能改这一次。
counter 层早就正确（lineage_counters 对该跳原样继承 depth/round），错的只有
这句话。新增 StaticDelegateHopNote::UserRevision，判据是原 delivery 的
contractStatus，并同澄清分支一样加 target == project-planning 门，做游戏 /
做素材的返工跳逐字保持 Repair——那句话是它们 replaceExisting=true 的唯一授权
信号。playbook 第 6 条同步改成「约束的是单条 delivery 不是整条链」。
原型对应的是 USER_REVISION_SOFT_LIMIT = 16，且超过只提示不拒绝。
守门三条，都验过非空转：
- revise 端到端补上此前缺失的那一步——mark 与 dispatch 之间的 claim 重放，正是
生产上唯一会失败的地方；并断言 !is_clear() && !has_external_wait() && has_waiting()
三者同时成立。把比较改回全等即复现生产原文错误。
- 128 种计数组合的 detail↔barrier 等价性测试里写死两个谓词的分叉点，合并回一个
就会炸。
- user_revision hop note 不得含「唯一返工轮」，须含「不消耗返工深度」「不是最后一轮」。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 06:58:27 +00:00
..
2026-08-22 13:17:26 +08:00
2026-08-26 06:58:27 +00:00
2026-08-24 16:27:33 +08:00
2026-08-24 16:27:33 +08:00
2026-08-22 13:17:26 +08:00