AT-T014..T046 通用缺口：§1 第 3 条要求的 trace（能力 ID + 实现来源 + 耗时）既无字段也无任何测试断言

> 来自 #3005（AT 验收 B4+B5）。实测 SHA `94f6dda037ca94da73d1b0a6359763a54db832a3`。本 issue 是**横跨 21 项的通用缺口**，不针对单个工具。

## 结论

验收方案 §1 把 trace 列为 `PASS` 的六个必要条件之一（第 3 条）：

> trace 包含**能力 ID**、**实际实现来源**、run、actor、org、输入摘要、结果和**耗时**，不包含凭据。

本仓有承载 trace 的表，但**缺两个字段、且零测试断言**。严格按 §1 读，我负责的 21 个 WX-T **没有一项**能达到 PASS。这个口径影响面太大，不该由验收方单方面决定，故单独立案请裁决。

## 证据（实测，非推断）

### ① 有承载，但缺「能力 ID」与「实现来源」两列

在真实 PG16 上跑完全部迁移后：

```
\d agent_run_steps
id, org_id, run_id, seq, kind, status, started_at, ended_at, input_digest, output_digest,
failure_code, tool_name, tool_args_summary, tool_result_summary, planning_note,
tool_call_id, input_full_content_enc, output_full_content_enc

\d mcp_tool_executions
org_id, run_id, tool_call_id, tool_name, args_digest, status, result, created_at,
server_id, review_id, attempt_id, lease_epoch, deadline_at, isolation_request_id,
local_stop_ack_at, finished_at, broker_started_at
```

对照 §1 第 3 条逐项：

| §1 要求 | 现状 |
|---|---|
| org / run / actor | `org_id`、`run_id` 有；actor 需经 `agent_runs` 关联，不在行内 |
| 输入摘要 / 结果 | `tool_args_summary` / `tool_result_summary` / `*_digest` 有 |
| 耗时 | `started_at`/`ended_at` 可算；`mcp_tool_executions` 有 `broker_started_at`/`finished_at` |
| **能力 ID（WX-T0xx）** | **无此列**。只有 `tool_name`（`wx_canvas_read` 这类规范名）。目录里 canonical_name ↔ WX-T ID 是 1:1，可推导，但**推导关系没有任何机械绑定**——目录改名不会让任何东西变红 |
| **实际实现来源** | **无此列**。同一个 `tool_name` 走 native 直调、MCP broker 还是 skill 内调用，只能靠"落在哪张表"间接猜 |
| 不包含凭据 | 有实测保障，但只在 SQL 一处（见下） |

### ② 零测试断言过标准工具调用会留下 trace 行

```
grep -rln "agent_run_steps" apps/api/tests/agent-runtime apps/api/tests/agent-run
```

命中的文件里，`agent_run_steps` 全部出现在**夹具 INSERT**（`INSERT INTO agent_run_steps(... 'context_built','succeeded' ...)`）而不是断言里。我这一轮实测跑绿的 **21 个工具相关测试文件、共 100+ 条用例**（canvas 4、web 18、document 6、scheduler 6+3+3、skill-draft 4、audio 9、image 6、browser 30、SQL 3+3）中，**没有一条**断言「调用 `wx_canvas_read` 之后 `agent_run_steps` 多了一行、且这一行长这样」。

也就是说：把 trace 写入整段删掉，上述全部测试**照样绿**。

### ③ 唯一有实测保障的相邻事实：凭据不泄露（只在 SQL 一处）

`apps/api/tests/agent-runtime/standard-sql-source-real-db.test.ts` 里有：

```ts
expect(output).not.toContain('sql-test');
expect(output).not.toContain('postgresql');
expect(output).not.toContain('sql-internal-key');
```

这是好的形状，但它守的是**工具输出**，不是 trace 行；而且只有 SQL 这一组有，其余 17 个工具没有对应断言。

## 请裁决的口径问题

三选一，选哪个都会改变本轮（以及后续所有轮）的定级结果：

- **A. 严格执行 §1 第 3 条**：21 项全部记 PARTIAL，直到 trace 补齐 + 有断言。诚实，但会让「验收结论」这一轮几乎不携带信息量。
- **B. 拆成两条判据**：把「trace 存在且不含凭据」作为 PASS 必要条件，把「trace 含能力 ID 与实现来源」降级为独立的可观测性缺口另行跟踪。这样单工具的功能/权限结论仍然可读。
- **C. 修方案措辞**：若「能力 ID」本就打算用 canonical_name 承载（目录 1:1 可推导），则 §1 第 3 条应改成「能力规范名」，并**同时**补一条机械绑定（canonical_name 集合 ≡ 目录声明集合的集合相等断言，形状照抄 `template-registry-19-key-displayname.test.ts`），否则改名漂移仍然无人拦。

我本轮先按 **B** 出定级表并在每一项上标注 trace 未验证，等裁决后如需按 A 或 C 重算，我改表。

## 无论选哪条都要补的（建议）

一条最小断言：任取一个标准工具，调用成功后读 `agent_run_steps`，断言新增行的 `tool_name`/`org_id`/`run_id` 正确、`ended_at >= started_at`、且 `tool_args_summary` 不含任何凭据字面量。今天这条不存在，等于 trace 这一层完全没有回归网。

Start by reading the §1 trace requirement and the migrations for agent_run_steps and mcp_tool_executions, then review the standard-tool tests under apps/api/tests/agent-runtime and apps/api/tests/agent-run. Compare options A, B, and C with the existing trace schema and the named SQL test. Done requires a decided criterion plus regression coverage for a successful tool trace and credential exclusion.

Written by the indexing model from the issue text.