lhk229
2f3dd86fb3
静态委派：返工深度与澄清轮次改为链上推断，不新增持久字段
WP1（本轮只改生产代码，测试由下一工作包处理）：
- 新增 static_delegate_lineage_counters：沿 repair_of_delegation_id 反向重放整条
delivery 链，现算目标节点的 (repair_depth, clarification_round)。二者都是运行时
派生值，故意不落盘——若给 StaticDelegateDeliveryRecord 加 repair_depth 字段并用
#[serde(default)] 兜底，磁盘上已有的返工记录会读出 0，深度门失效，等于让
“返工的返工”漏洞原样复活（fail-open，不可接受）。链上推断对历史记录反而是精确
的：#165 之前不存在 NeedsUserInput，老记录天然被正确分类为“非澄清”。
传播规则：R3 根节点 depth=0/round=0；R1 澄清跳 round=parent.round+1、depth 不变
（不重置深度，否则可插一次澄清洗掉返工深度变成无限返工）；R2 返工跳
depth=parent.depth+1、round 重置为 0（返工后重新开工，不能吃掉澄清轮次预算）。
反向重放遇到重复 id、缺失节点或跳数超过 STATIC_DELEGATE_LINEAGE_MAX_HOPS 时
fail closed，返回 (u32::MAX, u32::MAX) 使调用方的门必然拒绝。
- 抽出 static_delegate_original_is_awaiting_clarification 作为“这一跳是否续接自
澄清”的唯一权威判据源，validate_static_delegate_repair_request_at 与
validate_static_delegate_clarification_continuation_at 共用，避免两处口径漂移。
- 重写 validate_static_delegate_repair_request_at 里原先无差别拒绝返工深度>=1 的
门：先用共享判据分类候选是澄清续接还是质量返工；返工路径按链上 depth 校验，
错误文案原样保留“静态委派返工深度最多为 1”（现有测试已断言该字符串）；澄清
路径改为按链上 round 校验，用新文案“静态委派澄清轮次已达上限”。函数签名不变。
- 澄清轮次上限按 source 区分：新增 static_delegate_clarification_round_limit_at，
通过 read_game_creator_agent_runtime_run_profile_binding 读取 binding.source，
AGENT_RUNTIME_SUPERVISOR_GAME_CHAT_SOURCE 取 1，其余取 3——game-chat 单主路径
定位零打扰，#165 从未承诺给它 3 轮预算。
验证：cargo check --all-targets 通过。cargo test 里
tests::collaboration::static_deliveries::clarification_continuation_chain_supports_multiple_rounds
按预期失败——它断言的是旧的“D2->D3 必被返工深度门拒绝”行为，新逻辑下 D2->D3 是
合法的第 2 轮澄清续接，测试留给下一工作包更新。project_supervisor_concurrent_repair_dispatch_creates_exactly_one_delivery
偶发失败，经对比 20 次 vs 20 次基线（约 10%-15% 失败率两边相当）确认是本机既有的
并发计时 flaky 测试，非本次改动引入的回归。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 03:38:17 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-13 03:38:17 +00:00
2026-08-05 19:15:46 +08:00
2026-07-17 16:56:46 +08:00