lhk229
2a44169ddb
Project CI / Repository checks (pull_request) Failing after 14s
Project CI / Backend tests (pull_request) Failing after 14s
Project CI / Frontend tests (pull_request) Successful in 4m4s
Project CI / Native shell tests (pull_request) Successful in 16m7s
澄清卡不再叠一张通用确认卡，策划根委派免确认
子 Agent 要提问时，Runtime 在 parent-wake 屏障处把问题包成 user.input_request
pending（ensure_static_delegate_user_input_wait_at_locked），同一份问题再投影成
userInputRequest。这个 pending 只是问题的载体，user.input_request 也从来不在
GAME_CREATION_APP_COMMANDS 的 confirm 集合里，没有任何确认语义。但三个渲染面都
无条件把 pendingToolAction 也画成通用待确认卡，于是同一个请求出现两遍：上面是问答
卡，下面是拿 tool 名当标题、拿 questionCount/questionsSha256 这种取证摘要当副标题
的确认卡，还和问答卡在聊天视图里糊在一起。
加 agentRuntimePendingActionIsUserInputCarrier，在开发者 Runtime 面板、项目总控
概览卡和聊天视图三处统一把通用确认面判掉，只留问答卡。
立项策划根 Run 的 agent.delegate 同时改为免确认。plan 根的工具面按阶段收窄到「当前
唯一能推进链路的动作」，Delegate 阶段就只广告 agent.delegate 一个工具，让用户确认
「要不要执行唯一能做的那件事」没有决策含量，返工那一轮同理；这条链上真正由人把关的
关口是 §13.0 的 Fast GDD 审批卡，不动。source 只作弱判据，命中后必须过
validate_project_supervisor_plan_root_binding_at 强判据，否则做游戏那条根的委派确认
会被漂移或伪造的 binding 悄悄放开；绑定读盘只发生在本来就要确认的 agent.delegate
这一个组合上。
新增两条用例：Rust 侧一起断言 plan 根 delegate 免确认、plan 根上 agent.spawn_isolated
照旧确认、gui 根 delegate 照旧确认；前端侧断言载体 pending 只渲染问答卡，且
user.input_request 与 questionsSha256 都不出现在界面上。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 07:09:50 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-22 07:09:50 +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