qa: main 最近 40 次 push 验证 0 次绿（19 次一行没跑 + 11 次 e2e-full 真红）；稳定红核 3 条，S8 阅读位置被甩走 4079px

## 结论

**main 上最近 40 次 push 触发的 `harness-verify`，没有一次 `success`。**
19 次 `cancelled`（从未执行）、11 次 `failure`、2 次仍在跑，**0 次绿**。

按完成定义第 6、7 条（实现已合入 main ∧ 合入时刻 CI 全绿），
**main 当前处于「没有任何一次通过的合并后验证」的状态**——这不是某一条 spec 的问题，
是发布就绪度的问题，所以单独开一条。

## 取证

实测数据取自 `gh run list --workflow harness-verify --branch main --limit 40`，
采集时刻 2026-09-08T12:30Z，仓库 head `817a2b17b`。

```
main push run outcomes (last 40): {"cancelled":19,"failure":11,"running":2}
```

### 一、19 次 cancelled = 一行都没跑

抽查 run 34226085052（`5e641909e`）、34225795729（`c64a06d06`）、34225463889（`ba92132a9`）：
五个 job 的 `startedAt` 与 `completedAt` **完全相同**（例：`12:23:24Z -> 12:29:06Z`，
五个 job 逐字一致），即它们全程排在队列里、从未获得 runner 就被取消。

连续三个合并进 main 的 SHA 因此**零验证证据**。这与 #3091 描述的
「#3039 让每个 SHA 各自成组后 run 堆积」是同一条链，但 #3091 讲的是**部署链被饿死**；
本条讲的是**合并后验证本身从未产出**，后果不同（前者延迟发布，后者是完成定义失效）。

### 二、11 次 failure 里，红的**只有 `e2e-full` 一个 job**，且它是真跑了的

抽查最近四次 failure，每次都只有 `e2e-full` 红，且各跑满约 32 分钟
（真执行，不是 `EADDRINUSE` / runner 关机那类「红 ≠ 跑过」）：

| run | SHA | e2e-full 时长 | chat-read 结果 |
| --- | --- | --- | --- |
| 34221508209 | `92236df86` | 11:37:24 → 12:09:31 | 5 failed / 83 passed / 11 skipped |
| 34220747622 | `97f52b1cd` | 11:30:06 → 12:01:09 | 7 failed / 81 passed |
| 34219750348 | `7d8f66386` | 11:19:33 → 11:51:31 | 8 failed / 79 passed |
| 34218670488 | `f0fa1b9da` | 11:14:26 → 11:45:43 | 8 failed / 79 passed |

## 稳定红 vs 顺序相关红（按四趟的失败集取交集）

**稳定红核（4/4 趟，同一签名）——这三条每一趟都拦着 main：**

| spec | 失败断言 | 判定 |
| --- | --- | --- |
| `agent-workbench-scroll-acceptance.spec.ts:6`（S8） | `expect(Math.abs(boundingBox().y - top)).toBeLessThan(3)` → **Received: 4079** | **疑似产品缺陷**，见下 |
| `copilotkit-v2-roster-landing.spec.ts:191` | `mappingValue.streamingMessageId` 期待 `":1:assistant"`，实得裸 `"00f4b862-…"` | 疑似 #2999「D组：#2869 让 chat_message_id 映射退化」的同一条，**不另开** |
| `copilotkit-v2-tool-rendering.spec.ts:261`（D2） | `expect(streamFinished,"活动必须在运行流结束前可见").toBe(false)` → Received `true` | **待复验**：`c64a06d06`（「D2 活性判据别再跟 1.6s 的 run 赛跑」）在这四趟之后才合入，本条红全部取自修复前的 SHA，不作为开放缺陷计 |

**顺序相关红尾巴（每趟失败集互不相同，与 #3047 的约 25% 描述一致）：**
`agent-task-planning-hitl`（3/4 趟红，但行号每趟都不同：`:64` / `:64+:144` / `:223`）、
`copilotkit-v2-uiux-shots:119`（3/4，最新一趟反而 ✓）、
`agent-workbench-steering-acceptance:10`（2/4）、
`agent-chat-core-paths:104`、`copilotkit-v2-active-file-panel:100`、
`copilotkit-v2-persona-archived:86`、`copilotkit-v2-skill-mount:92`（各 1/4）。
另有 `chat-path-d4`（1/4）——已定性为 C4/D4 线程污染，见 **#3118**。

## S8：这一条看起来是真的产品缺陷，建议优先分诊

```
✘ agent-workbench-scroll-acceptance.spec.ts:6:5 › S8: ten rounds and one hundred tool activities retain the reading position
Error: expect(received).toBeLessThan(expected)
Expected: < 3
Received: 4079
> 39 | expect(Math.abs((await anchor.boundingBox())!.y - top)).toBeLessThan(3);
```

判据是「用真实点击折叠/展开一个**可见的**锚点，不滚动它，锚点的屏幕 y 不应移动」。
实测位移 **4079px** —— 展开运行轨迹会把用户正在读的位置整个甩走。
四趟稳定复现，位移量级远超阈值（不是 3px 边界抖动），因此不像时序运气。
与 #3032（上滚看历史后发消息不会拽回最新）方向相反、不是同一条。

## 我不做的事

按 QA 角色边界，本条只取证与分诊，不修代码、不改 spec、不动车道配置。
`e2e-full` 的 `Execute uncached trusted full gate` 步骤里另有一条
`✗ [test-listen-loopback] 1 处 listen(0) 绑通配地址（issue #2992）`，`5e641909e` 宣称已解开，
同样待在当前 head 上复验。

Start with the harness-verify workflow results and the named e2e specs, especially agent-workbench-scroll-acceptance.spec.ts:6. Run the full verification on a current main SHA, then confirm whether S8 still reproduces and separate it from the roster and D2 failures. Done means the relevant main push verification completes successfully and the confirmed blocking failure has a clear disposition.

Written by the indexing model from the issue text.