Jyotisha/docs/tasks/TASK-sync6-gate-red-20261007.md

# TASK · sync6 合入后 staging 门禁仍红：「Frontend and database tests」中断（2026-10-07）

- 基线：`origin/staging` @ `2df6ee72`（sync6 `fb8277bf` + Claude 门禁补修）。staging 线上仍部署 `0ed45a4b`。
- 对照：上一次绿的门禁 run 3206（`0ed45a4b`）。
- 分支 / worktree：`codex/sync6-gate-red-20261007` / `.worktrees/sync6-gate-red-20261007`（只有需要改代码时才建）。
- 执行方：产品负责人本机（有 Docker）。
- BUG 编号：开工时核对 `docs/BUG_HISTORY.md` 最大号（写作时 BUG-1270）。

## 1. 事实

| run | 提交 | 结果 | 停在哪一步 |
| --- | --- | --- | --- |
| 3211 | `fb8277bf` | failure | Python 快速门（扫描金样 D5/D11 未更新）；后续步骤 **skipped** |
| 3213 | `2df6ee72` | failure | 快速门、隐私扫描、Python 打包都通过；「Frontend and database tests」15:12:39 开始、15:28:17 失败；随后 lint 与 build 标 **failure、用时 0 秒** |
| 3206 | `0ed45a4b` | success | 同一步只用 6 分半（07:12:48–07:19:15） |

run 3213 的网页日志（`https://git.copse.top/root/Jyotisha/actions/runs/3213/jobs/6841/logs`）只到 15:12:59：测试开跑 20 秒后再没有任何输出，没有失败名单，也没有 TAP 尾部摘要。运行机都是 `xiaoxin`（runner_id 11）。

Claude 在 Linux 上对 `2df6ee72` 的复核（无 Docker，数据库测试被跳过）：

- Python 全量：62 条失败，与基线 `5cc8e504` 逐名相同；快速门通过；隐私扫描 0 项。
- 前端 `npm test`：4990 项、失败 24，与基线逐名相同；`tsc` 0；lint 0 error。
- 本轮前端改动只有测试与 fixture（scoring-11 版本字面量、跨午夜 fixture、扫描金样）以及 `engine-client.ts` 一行默认版本号。数据库迁移用正则 `scoring-(9|[1-9][0-9]+)` 接受 scoring-11，没有写死 scoring-10。

## 2. 三种可能（按可能性排序）

1. **运行机中途掉线**：日志中断加上后续步骤「failure 0 秒」（正常失败是 skipped），更像 runner 失联后被 Gitea 判超时，与代码无关。
2. **门禁上才会卡住的测试**：只在有真实 PostgreSQL 时才跑的 `database-*.test.ts`，或某条测试在 CI 环境卡住；BUG-1254 的「10 分钟无槽位易手才判失败」与这次约 15 分钟的时长对得上。
3. **内存或磁盘耗尽**：运行机 OOM 时也会表现为日志中断。

## 3. 决策记录

产品 2026-10-07：Claude 出任务书，产品本机执行。不改 `.gitea/workflows/**`，不提升 main。

## 4. 步骤

| # | 做什么 | 判定 |
| --- | --- | --- |
| S1 | 在 Gitea 网页对 run 3213 点「重新运行」（Re-run），这不改 workflow | 绿：判为可能 1，在 BUG 记录写 `resolved`（runner 偶发），然后做 S5。红：继续 S2 |
| S2 | 本机检出 `2df6ee72`，设 `CI=1` 跑 `npm test --prefix frontend`（会把完整 TAP 写到 `frontend/gate-logs/frontend-tests.tap`），记下总耗时，看有没有哪个文件超过 5 分钟 | 有失败或超时：记下测试名和报错原文，做 S3。全绿：做 S4 |
| S3 | 同样在 `0ed45a4b` 上跑 S2，对比两边的失败名单与耗时 | 只有 `2df6ee72` 失败的才算本轮引入。按 AGENTS §5 写 BUG（报错原文、触发条件、根因），在分支上修复，写三栏，推 staging |
| S4 | 门禁机排查：让管理员看 `xiaoxin` 在 15:12–15:28（UTC）的 runner 日志、内存（OOM killer）与磁盘 | 写进 `docs/research/pre_work_error_ledger.md`（ERR 编号顺延），附证据 |
| S5 | 门禁绿后核对部署 | `https://staging.jyotisha.chat/api/health` 的 `deployment.gitCommit` = 最近一次含门禁路径改动的 staging 提交；`/login` 200；未登录 `/api/account` 401 |

## 5. 记录

`docs/BUG_HISTORY.md`（新编号；若是 runner 偶发，关联 BUG-1254、BUG-266）、`docs/tasks/README.md` 状态板。日志里不要贴密钥或令牌。

## 6. 让步

S4 可以延后，S1、S5 不让步。