lhk229
0bd41112b4
瞬态重试恢复不再被策划用量折叠边界判成自杀
策划子 Run 第一次 tool-plan 请求撞上 HTTP 524，通用重试机制留下 retry sidecar 并
唤醒同一个 run；该 run 重新走到新请求边界时，fold_plan_provider_usage_before_new_request
把「本 run 自己那条未收口的 exchange」判成 PLAN_PROVIDER_USAGE_DEFERRED 硬失败。
于是子 Run 直接 failed，回执退化为 needs-repair，逼总控走完整的查状态→认领→返工
委派流程，一轮实测白烧四轮 Provider 请求。等于策划子 Run 撞上任何一次 502/524
都必定自杀。
延期判据本身没错——它的第一条就是「该 run 存在 retry sidecar」，而这恰恰是重试
恢复的必经状态。折叠是记账动作：exchange 没收口时本来就不该计入 session，跳过一
次是正确的，收口后的下一个边界会补上；真正裁决重放还是重发的是下游 retry / handoff
身份比对，它本来就预期 sidecar 还在。
边界函数改为接收本次请求所属的 run，只豁免「延期完全由该 run 自己造成」这一种。
三个 runtime_actions 边界传当前身份；planning_coordinator 三处在派生后继 session，
子 Run 的在途 exchange 对它们仍是硬阻塞，传 None，行为不变。内部折叠额外返回延期
来源，公开枚举与既有调用方签名不动。
用例覆盖四个方向：本 run 放行、别的 run 仍硬失败、None 调用方行为不变，以及收口
后用量仍如数折叠进 session（豁免是延后记账，不是丢账）。已实测关掉豁免后该用例
复现线上原话。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 12:29:11 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-20 12:29:11 +00:00
2026-08-05 19:15:46 +08:00
2026-07-17 16:56:46 +08:00
2026-08-17 12:42:29 +08:00