acceptance: D4 skill 三态 / A5 冷启动首屏 复核 —— 两条均已有非恒真断言且在阻塞车道绿，派工前提过期

## 结论：两条都**不是**缺口 —— 派工书的前提已过期

派工书说「D4 报告判为真实缺口」「A5 只有 warmup 没有断言」。**两条都不成立**。
不写新 spec：现有断言已覆盖且非恒真，再补一份就是把同一事实声明在两处（AGENTS.md 硬约束）。

核对基准 SHA：`92236df86783edecc265e60140ee4df2ef84c92d`（`origin/main`，2026-09-08）。
报告 SHA `303d00224` 是它的祖先（`git merge-base --is-ancestor` 通过）。

---

### 一、报告本身就判两条为 ✅（派工书读反了）

`docs/reports/2026-09-08-chat-37-path-acceptance-report.md` §3 逐条表：

| # | 报告结果 | 报告写的证据 |
| --- | --- | --- |
| A5 | ✅ | `chat-path-a5-cold-start-first-paint.spec.ts:31` ✓ |
| D4 | ✅ | `chat-path-d4-skill-three-states.spec.ts:57` ✓ |

D4 还被报告 §7 列进「本轮证据最硬的一批」8 条核心路径里（第 6 条）。
报告全文零处把 D4 或 A5 记为缺口。

### 二、CI 取证（不只读报告）

`gh run view 34210666232 --log`（报告引的那次 `e2e-full`）：

```
10239 ✓ 31 [chat-read] › e2e/chat-path-a5-cold-start-first-paint.spec.ts:31:5 › @path:A5 冷启动首屏：… (13.1s)
10241 ✓ 33 [chat-read] › e2e/chat-path-d4-skill-three-states.spec.ts:57:5 › @path:D4 skill 三态：… (18.5s)
4412 ✅ apps/web/e2e/chat-path-a5-cold-start-first-paint.spec.ts [covered] ← apps/web/playwright.chat-read.config.ts
4415 ✅ apps/web/e2e/chat-path-d4-skill-three-states.spec.ts [covered] ← apps/web/playwright.chat-read.config.ts
```

**车道**：两条都不在选跑的 `chat-path-coverage` 里，而是已搬进**阻塞车道 `chat-read`**
（`apps/web/playwright.chat-read.config.ts:263` 的 `testMatch` 逐字含两个文件名）。
矩阵 `.harness/instructions/chat-path-coverage-matrix.md:183-184` 记的是「A5 连续第 3 次绿 / D4 连续第 2 次绿 → 已搬进 chat-read」。
派工书说的「二跑 ✓ 过一次」不是「只过一次」，是**升车道所需的连绿计数**。

### 三、断言不是恒真门（本仓九次「全绿但空转」的检查）

**D4** —— 三态各读**互不相同**的真实信号，任一被改坏都会红：

- ① 目录态：`apps/api/scripts/loopback-deep-agent-provider.ts:244 skillCatalogReachedUpstream()`
只在 system prompt 里同时出现「产品源码 `buildDeepAgentSkillCatalogBlock` 生成的目录块头一行」
和 `- :` 时才回显。头一行**从产品源码取，不抄字面量**（`:228`）——目录格式变了替身跟着变。
开关未给全时 `return false`（恒 false，不是恒 true）。
- ② 正文态：`:259 mountedSkillReachedUpstream()` 只看 `body.config.configurable.org_skills[].content`，
**不看 system prompt**。所以「把全文贴回 system prompt 而 org_skills 漏了」这种实现在这里如实 false → 红。
- ③ 执行态：spec 读**产品自己的**审计 journal `GET /agent-runs/:runId/execution-events`，
断言这一轮 `.not.toContain("call_skill")`。断言的是「①②为真 **不蕴含** ③」——
正是「混为一谈」唯一可判的形态。「③为真时 journal 有 call_skill」刻意不重复证（`copilotkit-v2-hitl.spec.ts` 已钉）。

两个回显前缀是不同字面量（`[skill-catalog-seen:]` vs `[skill:]`，`apps/web/e2e/chat-read-fixture.ts:148,370`），
①冒充②在 spec 层就对不上。

Python 侧同样不混：`apps/deep-agent-service/src/deep_agent_service/native_skill_activity.py`
只发 `metadata_discovered` / `body_read` 两个 stage，**从不发「执行成功」**（模块 docstring 首行：
"never inferred execution success"）。`observe_skill_execute` → `complete_cat_read` 把
`cat SKILL.md` 记成 `body_read` 而非执行事实，且要求**精确单条 cat + 完整 stdout 摘要等于钉死的包内摘要**。
反证已在库：`tests/test_native_skill_execute_activity.py::test_truncated_failed_and_wrong_stdout_cannot_prove_cat`
（exit_code=1 / truncated / 假 stdout 三种情况 `facts==[]`）。
#3065 改的是身份判定（frontmatter `name` ≠ `stable_name` 时降为 warning，不再炸 run），
**没有动 stage 的划分**，三态区分未被削弱。

**A5** —— `chat-path-a5-cold-start-first-paint.spec.ts:31` 的真断言，不是 warmup：

- `expect(input).toBeVisible()` **且 `.toBeEditable()`** —— 派工书担心的「只有 warmup」正是这条 spec
头注自己写的**动机**（「`chat-route-warmup.global-setup.ts` 只把路由编译热，本身不断言任何用户可见状态」）。
它是问题陈述，不是现状。composer 永久 disabled 这条会红。
- `expect(getByTestId("copilotkit-v2-error")).toHaveCount(0)` —— 首屏不许以错误横幅收场。
- 耗时只**记录**进 `a5-cold-start.json`，`toBeGreaterThan(0)` 只挡「计时器没跑」。
**刻意不判阈值**：SLO 唯一事实源是 `.harness/instructions/chat-agent-performance-acceptance.md`，
在这里现编数字就是造第二个事实源。这个取舍是对的，不改。

---

### 建议

关掉本 issue，不开 PR。若要在 #3026 下继续投入 D4/A5，真正剩下的口子是别的：
D4 的原生运行时那半在**所有 e2e 车道上零覆盖**（#3052：无任何车道开 `KERNEL_NATIVE_RUNTIME=1`），
回环替身结构上测不到 `native_skill_activity.py` 的事实流——那是 #3052 的范围，不是补一条 web spec 能解决的。

Refs #3026

Read docs/reports/2026-09-08-chat-37-path-acceptance-report.md §3 and inspect the named A5 and D4 specs plus the chat-read configuration. Confirm the cited passing runs and coverage entries, then close this issue without adding another spec; the separate native-runtime gap remains in #3052.

Written by the indexing model from the issue text.