🔴 P0 phase-00 F14 是假 passing —— 它的 verification 现在红着，而两道门都不会跑它

## 结论：**F14 标着 `passing`，但它的第 7 条 verification 在当前 main 上是红的，且红在一条真回归上。**

由 coord-chat-e2e 在做 #512 时发现并上报（它**没有自己动 feature status**，正确）。**coord-main 独立复核 + 实跑确认。**

实测 SHA `775e3757`。

---

## 一、证据链

### ① F14 的 verification 第 7 条

```
status: "passing"
verification[6]: "pnpm --filter web run e2e"
```

### ② 那条命令**不在任何 CI job 里**

```
# 正样本：证明 grep 能在 workflows 里量出东西
grep -rn "verify:fullstack-smoke" .github/workflows/*.yml → 2 命中 ✓

# 主张
grep -rn "run e2e" .github/workflows/*.yml
→ deploy-devportal.yml:58 pnpm --filter @repo/devportal run e2e ← devportal，不是 web
```

**`pnpm --filter web run e2e` 零命中。**

### ③ `harness verify` 也不会再跑它

`passing` **不可逆**（`AGENTS.md` 硬约束）。F14 一旦转 passing，verify 不再重跑它的 verification。

⇒ **两道都不跑。这条 spec 从 F14 转 passing 那一刻起就再没被执行过。**

### ④ **实跑结果：红的**

coord-main 亲自跑（隔离单跑，排除"别的 config 的 spec 被默认 config 捞进来缺环境"的干扰）：

```
pnpm exec playwright test e2e/responsive.spec.ts

89 passed | 1 failed
[chromium] › e2e/responsive.spec.ts:39:11 › mobile-375（375px） › /projects/p1 无横向溢出

Expected: Array []
Received: Array [ "NAV[project-tabs] → 超出 220px（scrollW=547 clientW=327 overflow-x=auto）" ]
```

⚠ **这是真回归，不是环境问题。** 我先跑了全量 `pnpm --filter web run e2e` 得 14 failed，但其中 13 条是别的 config 的 spec 被默认 config 捞进来、缺 DB/API 环境所致 —— **不能拿它下结论**。隔离单跑后只剩这 1 条，它是 `responsive.spec.ts` 自己的断言，打的是真实 DOM 溢出。

---

## 二、为什么这条特别贵

F14 的 notes 用它宣布：

> UC-0.4 R8「**V1–V10 无一依赖人工判断**」的承诺现已全部兑现

而 phase-01 另有**四份 `ui-preview/README.md`** 以「它有断言」为由**省略了响应式截图**。

⇒ **一个「不依赖人工判断」的承诺，现在只由一次一次性的人工运行支撑，而那次运行之后代码已经改了很多轮。** 这正是 `AGENTS.md` 完成定义要防的形状：

> 没有证据 = 没有完成。「代码写完了」「看起来能跑」都不算完成。

它比 `chat-read.spec.ts`（#512）**更隐蔽**，因为它**看起来有人跑** —— verification 列表里白纸黑字写着那条命令。

---

## 三、`harness doctor` 为什么没抓到

doctor 查的是：evidence 非空 + 含 exit 0 + 有对应 issue + 已合入 main + 派生视图一致。

**它不查「verification 命令今天还跑不跑得过」，也不查「那条命令有没有进门控」。**

⇒ 这是审计链上一个真实的盲区：**一条 feature 可以永久停在 passing，而它赖以为证的命令早已失效、且没有任何机制会发现。**

---

## 四、范围（三件，可拆）

### A. 修那条回归
`/projects/p1` 在 375px 下 `NAV[project-tabs]` 横向溢出（`scrollW=547 clientW=327`）。要么修布局，要么按 spec 自己的提示加 `data-allow-x-scroll="理由"` —— **但后者要有真理由，不是为了消红**。

### B. 把 `responsive.spec.ts` 接进门控
⚠ coord-chat-e2e 报告：它需要独立一轮 `next dev`（webServer 与 fullstack-smoke 不兼容）⇒ **属新增 CI 时间预算**。单 runner 是硬瓶颈（见 #470），所以要权衡：接进 `e2e-full` 的**一步**（step 不是 job）可能是更省的解，照 #512/PR #515 对 `chat-read` 的做法。

### C. 🔴 **补一道 doctor 检查：passing 的 verification 必须仍可执行且在门控内**
这是三件里最值钱的。建议形态：

- doctor 对每条 `passing` feature，核它的 `verification` 命令**是否至少有一条被某个 CI job 或 npm script 覆盖**；
- 覆盖不到的 ⇒ **FAIL 或显式登记豁免**（带署名与理由）。

⚠ **不要做成「重跑所有 passing 的 verification」** —— 那会让 doctor 变成全量回归，跑不动、最后被 skip。要查的是**可达性**不是**结果**。

**反证不可省**：造一个 verification 指向不存在命令的假 passing，doctor 必须变红。

---

## 五、feature status 我不动

`AGENTS.md`：**agent 不能把 feature 直接标成 passing，也不能反向改**。`passing` 不可逆是刻意设计。

⇒ **coord-main 不动 F14 的 status，上交人类。** 需要人类决定：
1. F14 是否要退回（若机制允许）；
2. 还是保留 passing 但把这条回归与门控缺口作为独立 feature 处理。

**Owner**：coord-architecture（doctor 与门控属其 areas）｜ **优先级**：**P0**
**发现者**：coord-chat-e2e（做 #512 时的连带审计）——**它没有自己接、没有改 status，正确**

Start with e2e/responsive.spec.ts and reproduce the mobile-375 failure using pnpm exec playwright test e2e/responsive.spec.ts. Then inspect .github/workflows/*.yml, the e2e-full setup, AGENTS.md, and the harness doctor checks. Done means the regression is addressed, responsive.spec.ts is reachable from CI, and doctor rejects a passing verification that no CI job or npm script covers.

Written by the indexing model from the issue text.