结构性缺口：判据落在 chat-read 的修复可以在判据仍红时「全绿」合入——当晚已发生两次

## 结构性缺口

`chat-read` 车道的触发条件是 `github.event_name != 'pull_request'` ⇒ **它在任何 PR 上都不执行**（PR 页面显示 `skipping`）。

而合并门只看 **5 条必需 check**：`verify-control-plane` / `verify-affected` / `verify-full-compile` / `merge-gate` / `backend-required`。

⇒ **任何判据落在 `chat-read` 上的修复，都可以在判据仍然红的情况下以「PR 全绿」合入 main。**

## 这不是假想，2026-09-10/11 当晚就发生了

**PR #3394**（`Closes #3389`，流式正文闪烁）：PR 全部 check 绿 ⇒ 自动合入 main（`1fe4911ad`）。执行方随后在分支上 `workflow_dispatch` 该车道（run 34525483510，**真实执行 120 条：113 pass / 7 fail**），发现**判据 spec 仍然红**——它只修好了缺陷的一半。issue 被 `Closes` 关掉，实际问题仍在（已重开）。

同一晚另一例：**PR #3390** 带着 `fullstack-smoke` 红合入（那条也不在 5 条必需里），把三条 trace 几何 spec 的夹具打崩，**守 #3316/#3205/#3320 的门在 main 上全部失效**，直到 #3393 补救。

## 为什么现有做法挡不住

本仓已有的纪律是**人工的**：派工书里写「判据若落在 `chat-read`，PR 全绿不代表它跑过，必须 `workflow_dispatch` 单独派并核对真实测试计数」。今晚多条线确实照做了。但：

- 纪律靠人记，**自动合并不看纪律**；
- 执行方即使照做，**车道跑完之前 PR 可能已经被合**（#3394 正是如此）；
- 本仓的头号病是「同一事实声明在两处」，这里则是「**判据的权威性声明在纪律里，而合并门声明在 ruleset 里**」——两者不一致时，合并门赢。

## 候选方案（未裁决，需要人类/协调决定）

1. **让判据所在的车道进必需 check** —— 最直接，但 `chat-read` 单趟 ~25–30 分钟且当前有存量不稳定项（#3047/#3331：每趟失败集互不相同），直接设必需会把所有 PR 卡死。
2. **拆一条轻量必需车道**，只跑「本 PR 触碰到的判据 spec」，把重车道留给 push/nightly。需要一套「改动 → 相关 spec」的映射，且映射本身要有门控（否则又是一处会漂移的声明）。
3. **禁用自动合并**，改为人工合并前必须核对该 PR 的判据是否在某条真实执行过的车道上跑绿。成本落在人身上，且今晚已证明人也会漏。
4. **在 `merge-gate` 里加一条检查**：若 PR 改动触及某些路径且其判据车道在本 PR 上是 `skipping`，则要求 PR 正文附上一次 `workflow_dispatch` 的 run id 与真实测试计数。机械可查。

我倾向 **4 + 2 的组合**，但这需要先量清楚成本（车道时长、当前不稳定项的影响面），**不许在没有数字之前动手**——本仓在 #3309 上就是这么要求的。

## 相关

#3389（本次触发）、#3390 / #3393（同一晚另一例）、#3047 / #3331（`chat-read` 的存量不稳定项，是方案 1 的直接障碍）。

Start by reviewing the `chat-read` trigger, the five required checks, `merge-gate`, and the cited workflow runs, then measure lane duration and the impact of the unstable cases in #3047 and #3331. Done means a decided mechanism prevents a PR from merging when its relevant criteria have not actually run, with the required evidence and cost documented.

Written by the indexing model from the issue text.