lhk229
c1a8ca6481
Project CI / Repository checks (pull_request) Failing after 16s
Project CI / Backend tests (pull_request) Failing after 16s
Project CI / Frontend tests (pull_request) Successful in 3m40s
Project CI / Native shell tests (pull_request) Successful in 19m47s
GDD 审批卡不再被两张伪卡压住
立项策划提交 Fast GDD 后，界面上同时冒出三样东西：一句「待回答问题未能读取，请稍后
重试」、一张 plan.submit_gdd 的拒绝/确认卡，以及被压在下面的 GddApprovalCard。前两样
都是伪的。
plan.submit_gdd 的 pending 是审批卡的载体，不是等待批准的动作——planning/pending.json
的 submission.pendingActionId 指向的正是它，交互面是审批卡的批准/修改/退回。它和
user.input_request 是同一性质，而且运行时策略明确拒绝把它转成通用确认 pending
（「Runtime-owned create-only 提交」），那个确认按钮点下去必然失败。所以把载体判据从只认
user.input_request 扩成两个工具都认，并改名 agentRuntimePendingActionHasDedicatedCard。
同时补上第四个渲染面：协作 Agent 列表也无条件把 pendingToolAction 画成通用确认卡，上一次
只改了开发者面板、总控概览卡和聊天视图三处。
「待回答问题未能读取」则是另一回事：审批等待复用了 waiting-for-user-input 这个 phase，但
它没有 userInputRequest，只看 phase 就会把一次正常的等待报成读取失败。给
ProjectSupervisorRuntimePanel 加一个 planGddAwaitingDecision 入参，由两个调用处按
planGddState.pendingApproval 传下来，等审批时不再报这句错。
新增用例同时断言三条：审批未决时不出现「待回答问题未能读取」、不出现 plan.submit_gdd
确认卡、审批卡的批准按钮在位。两条判据都做过 A/B——各自关掉后对应的伪卡都会冒出来。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 07:53:15 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-22 07:53:15 +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