diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index a9f8391..8bc6635 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -10,18 +10,66 @@ name: CI
 # 见 DevDocs/00-踩坑记录-p2.md T7）。历史实现只作源码参考，**没有构建方式**（见 README：
 # 它的 manifest 整份是 workspace 继承写法，离开 workspace 后连解析都过不了）。
 
+# ---- 夜间全量矩阵（M266 / T30）：为什么是 schedule，而不是 push dev ----
+# 上面那套门禁的前提是「有人往 main 推东西」，而本仓的实际节奏是**日常只推 dev**、main 一个月只在
+# 发版那一刻动一次 ⇒ 全量矩阵一个月跑一次，一次爆 5 个红，全部是早已存在的平台依赖问题。
+# `schedule` 就是补这个缺口的入口：每晚在 main 的末梢上跑一轮，把「平台回归的发现延迟」从一个月
+# 压到一天。
+#
+# **不要顺手把它改成 `push: branches: [dev]`。** 本文件的矩阵 = 两个 OS 的 build release + 两个 OS 的
+# test + 两个 OS 的 clippy + fmt + runtime-smoke + update-e2e。挂到 dev 上等于每次提交烧一轮四平台
+# 矩阵，成本与排队都不可接受（dev 白天是开发时间）；而 24 小时一轮就足以把平台回归压到 T+1。
+# 这是**故意的取舍**：抓得住「平台回归 T+1 就能看见」，抓不住「当天的错当天见」。dev 线的快守门
+# （fmt / clippy / guards / gpu 自测）在 dev-guards.yml，那边刻意不上全量 test / build，理由见其头部。
+#
+# schedule 的五条语义边界（省得下次重新查；每条都能在 GitHub 文档里对上原文）：
+#   ① 定时只在**默认分支**上生效：cron 跑的是 **main 的末梢**，dev 上尚未合入的内容**不在这一轮里**。
+#      所以「dev 已经有人天天看着了」这句话是**错的**——dev 线只有 dev-guards.yml 那几道快守门
+#      （fmt / clippy / guards / gpu 自测），全量矩阵在 dev 上一次都没跑过。另外这份文件必须先合进
+#      main，cron 才会第一次响：合并之前一次都不会跑。
+#   ② 失败要向人喊话：`::error::` 注解由 test 作业的 shell 步骤自己产出，不读 event 上下文，这半条
+#      与 push 一样。但**收件人不是「默认分支的维护者」**——文档原话是 "Notifications for scheduled
+#      workflows are sent to the user who last modified the cron syntax in the workflow file"：
+#      谁最后一次改这行 `cron`，就一直收它的告警，所以这行 cron 的改动者要当成值班人。
+#   ③ 逐个 job 核过 `github.event` 依赖：除 concurrency 组那一处（`github.event_name`）与
+#      runtime-smoke-macos 的 `if: github.event_name == 'workflow_dispatch'`（schedule 下为假 ⇒ 跳过，
+#      它本来就只是手动探针）之外，其余 job 与矩阵里**没有任何** event 表达式，夜间不会空转。
+#   ④ 定时运行必须与 push main **分列到不同的 concurrency 组**：两者的 `github.ref` 都是
+#      `refs/heads/main`，同组 + `cancel-in-progress` 会让它们互相取消 —— 而**取消不是红**。
+#      一个经常被静默取消的夜间入口比没有更坏：「昨晚没报错」会变成一句假话。所以 group 里带了
+#      event_name（证据强度见 `concurrency:` 上方那几条注释，别当成已在 runner 上实证过）。
+#   ⑤ **它自己会悄悄停**：public 仓库的 scheduled workflow 在仓库 60 天无活动后会被**自动 disable**
+#      （文档："In a public repository, scheduled workflows are automatically disabled when no
+#      repository activity has occurred in 60 days"）。这是「夜里那轮某天不再响、而且没人发现」的
+#      真实失效模式，比红更隐蔽；本仓若是 public 就适用，发现入口不跑了先看那条 disable 提示。
+#
+# 时间：`17 19 * * *`。GitHub 按 UTC 解释 cron（文档："By default, scheduled workflows run in UTC"），
+# 所以它是 **19:17 UTC = 本地（UTC+8）次日 03:17**，本文件不再出现第二种换算口径。
+# 为什么是 17 分：文档只说 "the start of every hour" 是高负载期，且 "If the load is sufficiently high
+# enough, some queued jobs may be dropped"（负载过高时排队任务会被**丢弃**，不只是延迟），并建议错开
+# "a different time of the hour"。文档没有「:30 也挤」这条依据，所以这里只避开整点。
+
 on:
   push:
     branches: [main]
   pull_request:
   workflow_dispatch:
+  # 夜间全量矩阵（M266 / T30，理由与取舍见文件头）：19:17 UTC = 本地次日 03:17。
+  schedule:
+    - cron: '17 19 * * *'
 
 env:
   CARGO_TERM_COLOR: always
   RUST_BACKTRACE: 1
 
 concurrency:
-  group: ci-${{ github.ref }}
+  # 加了 schedule 之后这一行必须带上 event_name：定时运行落在默认分支上，`github.ref` 同样是
+  # `refs/heads/main`，与「push main」落进同一个组 ⇒ 配上 cancel-in-progress 就是两者互相掐死
+  # （夜里那轮被白天的推送取消 = 那一夜没有结果，而取消不是红，正是本次要填的洞）。带事件名之后：
+  # push↔push 仍按 ref 互斥（原有行为一字未变），定时自成一列，既不会被推送取消，也不去取消推送。
+  # 证据强度：以上是 **GitHub 文档语义**（schedule 事件的 ref 是默认分支、取消按 group 判定），
+  # **没有在真实 runner 上构造并发验证过**——本地造不出两个并发 run。别把它当实测结论引用。
+  group: ci-${{ github.event_name }}-${{ github.ref }}
   cancel-in-progress: true
 
 jobs:
diff --git a/docs/backend-cjk-evidence-matrix.md b/docs/backend-cjk-evidence-matrix.md
index ccbbd00..4973b21 100644
--- a/docs/backend-cjk-evidence-matrix.md
+++ b/docs/backend-cjk-evidence-matrix.md
@@ -7,11 +7,16 @@
 
 | 通道 | 位置 | 后端 |
 |---|---|---|
-| CI 冒烟截屏 | `.github/workflows/ci.yml:101` | `--software-renderer`（强制 CPU） |
-| CI 交互冒烟 | `.github/workflows/ci.yml:246`、`:283` | `--software-renderer` |
-| Linux 容器冒烟 | `packaging/linux-smoke-docker.sh:90` | `--software-renderer` |
+| CI 冒烟截屏 | `.github/workflows/ci.yml` 的 `test` 作业「出四张像素守门用的图并写进 $GITHUB_ENV（仅 Windows）」那一步 | `--software-renderer`（强制 CPU） |
+| CI 交互冒烟 | 同上文件的 `runtime-smoke` 作业「在 Xvfb 里跑一帧并截图」、`runtime-smoke-macos` 作业「尝试截图」两步 | `--software-renderer` |
+| Linux 容器冒烟 | `packaging/linux-smoke-docker.sh` 里「2) 跑容器：构建 → xvfb 截图 → 像素判定」那一段的 `xvfb-run` | `--software-renderer` |
 | D30 视觉验收（人工，按协议出图） | `DevDocs/PlanDoc/`（视觉验收协议） | 同上（CI 同款命令） |
 
+> **锚点一律用「作业名 + 步骤名」，不用 `文件:行号`。** 这条规则不是本次改动造出来的：本次改动的
+> base（`main`）上，上面 ci.yml 那三处行号里只有 `:101` 对得上，`:246` / `:283` 早就指偏了（分别落在
+> 依赖安装步和一行注释上；`linux-smoke-docker.sh:90` 那时是对的）。也就是说行号锚点本来就在腐，
+> 而 workflow 只会越来越长——要定位就按上表的名字 `grep` 作业名 / 步骤名，别再写回行号。
+
 `--renderer=auto`（默认）会挑 wgpu；`--software-renderer` 强制 tiny-skia。CI 走后者是**有意的**：
 容器/无 GPU 机器上没有 Vulkan/DX12 设备，硬要 wgpu 会红在一句「adapter 创建失败」上，与皮肤无关。