acceptance: B7/D6/F4 三条工作台能力缺口的实现范围评估

## 结论先说

独立验收报告 `docs/reports/2026-09-08-chat-37-path-acceptance-report.md` 把 B7 / D6 / F4 三条都归为
「❌ 记分牌红（**能力未实现**）」，并指向已关闭的 #2114。**实测 SHA `92236df86783edecc265e60140ee4df2ef84c92d`（origin/main）后，这个归因对 B7 和 F4 是错的**：
两条能力的契约、API、组件与 v2 聊天面挂载**都在 main 上**，且有 30 条绿色组件测试逐条覆盖 spec 锚点。
只有 D6 存在一处真实缺口，而且是**局部**的（四项详情里「工具」一项是写死的占位文案），不是「没有折叠树」。

报告最初 grep 不到锚点的原因可以复现：产品代码在 `apps/web/components/`，不在 `apps/web/src/`。

| 条目 | 报告结论 | 本次分类 | 实际状态 |
|---|---|---|---|
| B7 条件性计划确认门 | 能力未实现 | **(a′) 已实现，报告结论过期** | 契约 + API + 组件 + 挂载齐全，且判定确为条件性 |
| D6 子 Agent 折叠树 | 能力未实现 | **(b) 局部缺口：契约/引擎缺子任务工具明细** | 折叠树 + 输入/耗时/结果为真；「工具」是占位符 |
| F4 失败态重试该步 / 修改输入 | 能力未实现 | **(a′) 已实现，报告结论过期** | 两个锚点均在 DOM，且刻意不渲染 restore-checkpoint |

---

## B7 —— `chat-task-workbench-workflow-states.spec.ts:131`

spec 断言两面：(a) 复杂任务出 `chat-task-workbench-plan-confirm`；(b) 简单提问该锚点 `toHaveCount(0)`。

证据链：

- 判定纯函数 `packages/contracts/src/plan-control.ts` 的 `evaluatePlanGate`（`PlanGateDecision` 定义在 `:118`，
`TaskRiskClass` 在 `:102`）——`todoCount === 0 → {required:false, reason:"no-plan"}`、
`=== 1 → single-step`、`>= 2 → {required:true, reason:"multi-step"}`，另有
`multi_step_high_risk → required:true` / `multi_step_low_risk → required:false, deliverPlan:true`。
**这正是 spec 要的条件性**：简单问答不产生 todo，`required` 恒 false，门不渲染。
- 后端派生：`apps/api/src/application/plan-control/get-plan-ledger.ts:83` 调 `evaluatePlanGate`，`:119` 把 `gate` 放进 ledger。
- 组件：`apps/web/components/plan-control/plan-confirm-gate.tsx`（`PlanGateDecisionWithRisk` 于 `:47`）。
- 挂载到 v2 聊天面：`apps/web/components/chat/copilotkit-v2-plan-control.tsx:373`
—— `{ledger.phase === "planning" && ledger.gate.required && ()}`，
双条件保证「非计划阶段」「不需要确认」两种情况都不渲染锚点。
- 组件测试（本次实跑，30/30 绿）：`apps/web/tests/ui/plan-confirm-gate-task-type-and-cards.test.tsx`、
`apps/web/tests/ui/plan-control-gate-and-recovery.test.tsx`。
- 最近一次实现落地：`8742702dd`（2026-09-04，`feat(plan-control): 任务类型标记 + 计划卡片两态`，PR #2680）。

**估点：0**（无实现工作）。剩余的是「记分牌 e2e 为什么仍然红」，属车道问题，见文末。

---

## D6 —— `chat-task-workbench-tool-events.spec.ts:93`

spec 断言：存在 `chat-task-workbench-subagent-node`、默认 `aria-expanded="false"`、点开后四项详情
`-input / -tools / -duration / -result` 全部可见。

证据链：

- 折叠树本体：`apps/web/components/chat/subtask-run-panel.tsx:170-171`（`aria-expanded={open}` + 节点锚点），
四项详情在 `:117 / :121 / :122 / :123`。
- 真实取数容器：`apps/web/components/chat/subtask-run-live-panel.tsx:28`，
轮询 `GET /agent-runs/:runId/subtask-runs`（`apps/web/lib/chat/use-subtask-runs.ts:35`）。
- v2 聊天面挂载链：`copilotkit-v2-panel-body.tsx:14` → `workbench/task-timeline.tsx:33/47`
→ `workbench/run-trace-panel.tsx:83`。

**真实缺口（(b)）**：`apps/web/components/chat/subtask-run-panel.tsx:121` 的「工具」一项写死为
`

工具明细 · 当前运行记录尚未提供

`。

根因在契约与上游，不在前端：`packages/contracts/src/subtask-run.ts:49` 的 `SubtaskRun` 字段为
`id / parentRunId / description / context / outputFiles / snapshot / artifactRefs / status / result / error / createdAt / updatedAt`
——**没有任何承载子任务工具调用记录的字段**。spec 只断言该锚点可见（现在可见），所以这条不是它红的原因，
但「用了哪些工具」这个能力确实空着，属于报告说对了一半的地方。

补齐要动的面（分阶段）：

1. **契约**：`SubtaskRun` 增补可选 `toolCalls: z.array({ name, startedAt, durationMs, status })`，向后兼容。约 1 点。
2. **API**：`subtask-run` 读模型把子 run 的工具事件汇总进列表响应；需要一次迁移或从既有 run 事件表投影。约 2 点。
3. **引擎**：`apps/deep-agent-service` 侧子任务回调需上报工具调用（目前 `POST /internal/subtask-runs` 只回结果）。约 2–3 点，**风险最高，需要 deep-agent-service 归属方参与**。
4. **前端**：把占位文案换成真实列表。约 0.5 点。

**建议：按 (b) 处理，先由 coordinator 裁定第 3 步的归属再开工。** 另附一条独立观察：
`run-trace-panel.tsx:54` 的 `hasSubtasks` 判据是 `entry.kind === "tool" && entry.text === "spawn_async_task"`
——若记分牌剧本的 `deepAgentMultiStepTrigger` 不产生 `spawn_async_task` 事件，整棵树根本不挂载，
锚点自然找不到。这一条要用剧本取证，属车道问题，不属能力问题。

---

## F4 —— `chat-task-workbench-workflow-states.spec.ts:187`

spec 断言：`chat-task-workbench-phase-indicator` 的 `data-phase="failed"`；
`chat-task-workbench-failure-retry-step` 与 `-edit-input` 均可见；
`chat-task-workbench-failure-restore-checkpoint` 必须 `toHaveCount(0)`。

证据链：

- `apps/web/components/plan-control/plan-failure-recovery.tsx:15-16` 导出两个锚点常量，`:40` / `:43` 渲染两个按钮；
文件头注 `:11` 明确说明**故意不渲染** restore-checkpoint（对齐 2026-08-26 人类裁决 (c)，
`packages/contracts/src/plan-control.ts` 已整条删除 `restoreCheckpoint`）——spec 的第三条断言因此天然成立。
- 挂载：`apps/web/components/chat/copilotkit-v2-plan-control.tsx:284` 的 ``，
失败步骤定位用 ledger 的 `failedStepIndex/failedStepLabel`（同文件 `:58` 头注）。
- 相位指示器：`apps/web/components/plan-control/plan-phase-indicator.tsx`；七态枚举
`packages/contracts/src/plan-control.ts:76`（含 `failed`）。
- 控制动作枚举 `RunControlAction`（`plan-control.ts:141`）已含 `"retry-step"` / `"edit-input"`，
迁移 `apps/api/migrations/20260827030000_f976_plan_control_run_control.sql` 已落库。
- 组件测试（本次实跑绿）：`apps/web/tests/ui/plan-control-gate-and-recovery.test.tsx`。

**估点：0**（无实现工作）。

---

## 为什么记分牌仍然红（不在本次范围，但必须写清）

三条能力齐了，e2e 仍红只可能来自：剧本触发词没走出预期相位、锚点渲染需要的 ledger 未在替身链路生成、
或该车道设计上就是记分牌（见 `.harness/instructions/multi-agent-coordination.md`）。
本次任务明确禁止起 docker / 本地真栈 / 自行 dispatch e2e-full，因此**不作断言**——
这需要一次带证据的 e2e 取证，请 coordinator 决定派给谁。

## 建议顺序

1. **先做 e2e 取证**（B7 / F4）：能力已在 main，先证明红是剧本/车道问题还是集成问题。做完再决定是否还需要产品改动。
2. **再排 D6 的 (b) 方案**：四步里第 3 步（deep-agent-service 上报工具调用）先定归属。
3. 无论结论如何，`docs/reports/2026-09-08-chat-37-path-acceptance-report.md` 的 B7 / F4 归因需要更正
（本次未动 docs/reports，按分工留给报告作者）。

## 本次已做的机械验证

- 实测 SHA：`92236df86783edecc265e60140ee4df2ef84c92d`（`origin/main`）
- `./init.sh` 通过
- `pnpm exec vitest run tests/ui/plan-control-gate-and-recovery.test.tsx tests/ui/plan-confirm-gate-task-type-and-cards.test.tsx tests/ui/subtask-run-panel.test.tsx`（cwd = `apps/web`）→ **3 files / 30 tests 全绿**

未提交任何代码改动：B7 / F4 无可做，D6 判为 (b) 按规矩不动手。

Start with packages/contracts/src/subtask-run.ts and apps/web/components/chat/subtask-run-panel.tsx, then trace the subtask-runs API and the deep-agent-service POST /internal/subtask-runs path. Run the three named UI test files to confirm the existing anchors, and use the coordinator's decision on ownership before changing the contract, API, engine reporting, or frontend display. Done means tool-call details flow through the system and the B7/F4 e2e and report status are resolved with evidence.

Written by the indexing model from the issue text.