lhk229
ddb8eaec37
澄清转述 pending 不再被自己的任务身份校验判成 needs-reconciliation
D11 里 Runtime 代 Supervisor 汇总子 Agent 澄清问题时，pending 动作的 task 字段
存的不是本 run 的任务，而是一段 Runtime 生成的转述指令（provider_recovery.rs
的「子 Agent 需要用户澄清后才能继续。delegationId=…」），delegationId 就编码在
前缀之后，另有四处按这个前缀反解绑定关系。
但 validate_agent_runtime_pending_context 会拿 pending.task 与 runtime
.current_task 做相等比较，而落等待态的 persist_game_creator_agent_user_input_
wait 只改 status/phase/waiting_on，从不同步 current_task。其余五个 pending 创建
点传的都是 run 的真实 task，相等断言对它们成立；转述这一处永不可能成立。
后果是必现而非抖动：用户答完问题、观察已落盘（status=observed-approved）后，
resume 立刻被判 needs-reconciliation，整条立项策划链在第一次澄清就断。
实测证据（run 14）：
runtime.currentTask = 做个横版像素解谜小游戏，主角是个能操控自己影子的小机器人。（29 字符）
pending.task = 子 Agent 需要用户澄清后才能继续。delegationId=delegation-ec059abd…（355 字符）
任务日志 27 条全部是前者；plan 根没有 autonomous completion contract，
autonomous_effective_root_task_at 两侧都走 fallback，比较退化成裸文本相等。
这条路径此前从未执行过——澄清信封在 run 11/12/13 一次都没触发，缺陷因此一直
藏在 0 轮问询后面。
只豁免文本相等这一条。agent/task_id/session/run/source 五项身份检查在它之前已
全部通过，轮次检查在它之后继续执行，转述 pending 本身也只能由 Runtime 在本 run
内生成，所以不放开任何跨 run 或跨身份的重放面。没有选择改 pending 的持久格式：
task 字段被当载荷用是既成事实，四处反解加在途 pending 迁移，风险与收益不成比例。
顺带把散落五处的同一段 strip_prefix 链收成 user_input.rs 的一个共用判据。抄本
之间一旦漂移，转述路径会静默失去与原 delivery 的绑定，那是比本次更难查的故障。
回归测试双向变异验证：恢复严格比较则转述被拒（红），整条删掉则被改写 task 的
pending 不再被拒（红）。受影响测试组单线程 124 passed / 0 failed。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 05:19:34 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-21 05:19:34 +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