test(判据): ★★★ 套件从 10-02 10:46 起一条都没跑过 —— 补接线 + 结算登记数

**零读数 24 小时，仓库里没有任何记录**（DEBTS.json 58 条里 grep「没接进」0 命中）。

漏接线的三个（都来自 aeb1f41 / 2f17f62，都比 run-all.mjs 最后一次改动晚）：
    test/inbox-fallback-poll.test.mjs   ← SSE 兜底轮询（探测 total 变化）
    test/sse-credentials.test.mjs      ← SSE 订阅跟账号凭证走
    test/web-comment-only.test.mjs

**为什么严重（三层放大）**：
1. 自检 2「每个 *.test.mjs 都要在清单里」在跑任何判据**之前** exit(1)
   ⇒ 实测 RESULT 行数 = **0**
2. npm test = run-all && vitest && typecheck ⇒ vitest（270 格）与
   typecheck **一起不跑** —— 而两者单独跑都是绿的
3. 失败信息只有一行中文 stderr，**不含"红"字样**，看起来像"环境问题"
⇒ 下一个人据上一份报告继续推断"判据在把守" ⇒ **报告的证据等级被系统性高估**。
守卫本身**不删**（漏接线绝不静默是真价值），代价靠「新增即接线」这条义务兜。

**顺带结算的登记数漂移**（都在 clean HEAD 上就红，非本次引入）：
· harmony-window 9→10、appearance-defaults 7→8、harmony-2in1 23→24
  （"自报条数 > 登记条数"是显式的编辑义务：只判下界时多出来的条数删掉不红）
· harmony-appearance 28→29 —— 配合工作树里别人新增的那条设备判据
· static-criteria 5→4 —— appearance-defaults 已上设备并移出 STATIC_ONLY，
  **移出名单时忘了回头改这笔登记**，由 commit-hygiene 的机器镜像抓住
· debt-visibility REGISTERED['harmony-appearance'] 4→6 —— 两处都是
  **散文**（一处引用文件既有句子、一处在报错文案里），按该文件既有先例登记
  并注明；⚠️ 写那段说明时不能引用词表里的词，否则本文件自己数超（实测 12→14 即红）

**commit-hygiene 基线推进**：7d081095 与 477479a37 两条 `fix(harmony):` 改了
"鸿蒙源码 + 另一侧判据"，按本仓口径该标 `跨端:`。二者**已推送到 origin 与
origin-https**（merge-base --is-ancestor 实测为真）⇒ 不能 amend；也不往 MARKERS
放行 `fix(harmony):`（那等于永久允许"说单端、实际改两端"）。唯一正确处置是
推进基线 + 具名记下。已验证：COMMIT_HYGIENE_BASELINE 覆盖后 pass=4 fail=0。

**CRITERIA.md 新增 §6.0「怎么读判据的数」** —— 原有 17 节全在讲「怎么写」，
缺的就是这一半，而今天两起独立事件都出在它：
· 6.0.1 接线守卫的失效形状是「全停」不是「那一条不跑」；ran 必须 == SUITE 条数
· 6.0.2 退出码只能来自不接管道的运行（`cmd >file 2>&1; echo $?`）。
  **本会话我连踩 5 次** `cmd | tail -N` ⇒ 报的是 tail 的码。实例：
  npm test|tail-80（真实：0 条判据跑过）、npm test|tail-30（真实：vitest 根本没跑）、
  tsc --noEmit|tail-20（**碰巧**也是 0 —— 事实为真但**当时无根据**，仍须重取证）
· 6.0.3 && 链里「全绿」要问**真跑到那一环了吗**（red 之后的东西根本没跑，
  而日志里「有 RESULT 行」与「无下游输出」可以同时出现）
· 6.0.4 判据变红先问「判据用的工具本身可信吗」（读取器的缺陷是**静默**的）
· 6.0.5 **当你就是改工具的人**：第一假设是「我弄坏了它」不是「代码回归」——
  「判据过期了」这个反应本身就错，它默认了「我改的是正确的东西」。
  附本次三次改错的下游依赖表，以及"下游依赖是**行为依赖**，
  codegraph 那类符号图看不见"。

★ 顺带记一条取证教训：本机每条命令都吐一行 libpcre 的
  `no version information` 噪声 ⇒ 某次 grep 的输出被它吞掉，
  我把"命令返回空"当成了"没有匹配"。**空输出要连退出码一起看**，
  这与 6.0.2 是同一族，只是这次发生在我自己的取证上。

docs/DEBTS.json

@@ -19,11 +19,11 @@
   "debts": [
     {
       "id": "static-criteria",
-      "count": 5,
+      "count": 4,
       "due": "本工作区能装、能点设备（探针三值转 true 时自动变红）",
-      "where": "client/electron/test/run-all.mjs 的 STATIC_ONLY（2026-09-19 起 harmony-admin 那条已升级为设备判据、移出名单 ⇒ 6 → 5：test/harmony-appearance.test.mjs、test/harmony-logic.test.mjs、test/cross-client-theme.test.mjs、test/appearance-defaults.test.mjs、test/harmony-imageprep.test.mjs）",
+      "where": "client/electron/test/run-all.mjs 的 STATIC_ONLY（当前 4 条：test/harmony-appearance.test.mjs、test/harmony-logic.test.mjs、test/cross-client-theme.test.mjs、test/harmony-imageprep.test.mjs）· 历史：2026-09-19 harmony-admin 那条已升级为设备判据、移出名单 ⇒ 6 → 5；2026-10-02 appearance-defaults 上设备（判据改为「落盘键真的带账号段」，已在真机验过红绿）并移出名单 ⇒ 5 → **4**",
       "kind": "scope",
-      "note": "2026-09-19：`harmony-admin` 的条目**已升级**（管理页真的能打开、列表真的渲染出用户行）并移出 STATIC_ONLY ⇒ 本笔 6 → 5。剩下的五次升级按\"每条缺什么设备侧验证\"逐条来，不为了把数字消成 0 而凑 —— 凑出来的设备判据只是把\"没验\"换成\"假装验了\"。\n\n2026-09-19 再更新：`cross-client-theme` **升级了一半** —— 新增一条设备判据（读悬浮球像素：品牌色真的画成 `#2563EB`；且球上图标与底色 WCAG 对比度 ≥3:1），并顺手钉了一条静态防线（`Theme.surface` 不得当代的前景色）。**它仍留在 STATIC_ONLY 名单里**，因为 `.ets` 那半只有悬浮球这一处上了设备 —— 其余令牌仍是静态对齐。「一半」要写出来，不能让名单看起来像没动过。"
+      "note": "2026-09-19：`harmony-admin` 的条目**已升级**（管理页真的能打开、列表真的渲染出用户行）并移出 STATIC_ONLY ⇒ 本笔 6 → 5。剩下的四次升级按\"每条缺什么设备侧验证\"逐条来，不为了把数字消成 0 而凑 —— 凑出来的设备判据只是把\"没验\"换成\"假装验了\"。\n\n2026-09-19 再更新：`cross-client-theme` **升级了一半** —— 新增一条设备判据（读悬浮球像素：品牌色真的画成 `#2563EB`；且球上图标与底色 WCAG 对比度 ≥3:1），并顺手钉了一条静态防线（`Theme.surface` 不得当代的前景色）。**它仍留在 STATIC_ONLY 名单里**，因为 `.ets` 那半只有悬浮球这一处上了设备 —— 其余令牌仍是静态对齐。「一半」要写出来，不能让名单看起来像没动过。\n\n★★ 2026-10-03 结算 5 → 4：`appearance-defaults` 已上设备（`62b7c94`），并从 STATIC_ONLY 移出 ⇒ 登记数必须跟着减，否则 `commit-hygiene` 的「可见副本不许漂移」那条会红。**这次漂移的真实成因是：移出名单那一步改了 `run-all.mjs`，却没回头改这笔登记** —— 与本仓反复出现的「同一个数字的多个副本各改各的」同族，而机器镜像（`commit-hygiene.test.mjs:180-196` 只比对 count 与 STATIC_ONLY.length）正是唯一抓住它的地方。"
     },
     {
       "id": "mails-status-derived",
@@ -463,6 +463,14 @@
       "where": "client/harmony/AppScope/app.json5:3（bundleName=com.jianf.agentmail）· client/harmony/entry/src/main/resources/rawfile/agconnect-services.json（AGC 配置；build/ 下那份是产物）· server/internal/handler/push.go:16,58,119,150（三条端点）+ push_test.go · client/harmony/entry/src/main/ets/api/PushService.ets（433 行、9 处 try+catch、catch 内 0 抛错/提示）· MainPage.ets:1874,1886,1925（通知路由）",
       "kind": "鸿蒙 Push Kit **契约已全部落地，唯一剩余阻塞是真实设备**：包名（AGC 拒 harmony 保留字）已改、AGC 配置在位、服务端三条端点齐备、客户端『推送是可选通道、不报错不阻塞』逐条查实（catch 内 0 抛错）。但 `push_tokens` **0 行** —— `getToken` 只能在带华为账号的真机上取，无模拟器路径",
       "note": "★★★ 2026-09-30 登记。pi `1f9ff3b4`（2026-09-15 11:06:06）给了鸿蒙 Push Kit 客户端半边契约 + 包名硬约束，\n**账本里此前没有这条线的任何条目**（`getToken`/`com.jianf.agentmail`/`PushService` 均 0 命中）。\n本轮实测确认:**契约已全部落地，唯一剩余阻塞是真实设备**。\n\n## ① 包名硬约束：已落地（AGC 拒 `harmony` 保留字）\n\n```\nAGC 原话: 应用包名中包含敏感词或者保留字符\"harmony\"\n用户定:   **com.jianf.agentmail**   （AGC APP ID 6917616450599975320，个人身份）\n实测: client/harmony/AppScope/app.json5:3  \"bundleName\": \"com.jianf.agentmail\" ✓\n      全工程 grep `com.agentmail.harmony` = **0 处** ✓（无残留）\n```\n\n## ② AGC 配置：在位\n\n```\nclient/harmony/entry/src/main/resources/rawfile/agconnect-services.json  ← 源（工程约定位置）\nclient/harmony/entry/build/default/intermediates/res/default/resources/rawfile/  ← 构建产物副本\n★ 两者都在; app_id/package_name 已与 AGC 一致\n```\n\n## ③ 服务端契约：三条端点齐备\n\n```\nserver/internal/handler/push.go:16   设备推送登记 —— /api/v1/me/devices/push-token\n                            :58     POST   /api/v1/me/devices/push-token   （上报）\n                            :119    DELETE /api/v1/me/devices/push-token   （注销）\n                            :150    GET    /api/v1/me/devices/push-token   （查询）\nserver/internal/handler/push_test.go 有对应测试\n```\n\n## ④ ★ 客户端\"必须是可选通道\"契约：已完全落实（本轮逐条查过）\n\npi 的第④条要求: 取不到 token / 没权限 / 上报失败 / 服务端未开推送 ⇒\n**静默跳过，不报错、不阻塞、不弹失败提示**; 主通道仍是 SSE。\n```\nclient/harmony/entry/src/main/ets/api/PushService.ets（433 行）\n  9 处调用全部 try+catch 包裹（:136 :140 :147 :151 :171 :182 :214 :226 :243 :253 :264）\n  ★ ★ catch 块里 `throw` / `showToast` / `promptAction` / `console.error` = **0 处**\n    ⇒ **全部静默**，与第④条一致\n通知点击跳转（第③条 data 形状）:\n  MainPage.ets:1874  PushService.setRouteListener(…)   ← 收到通知后路由\n  MainPage.ets:1925  PushService.pendingRoute            ← 冷启动时补取\n  MainPage.ets:1886  clearRouteListener()                ← 页面销毁清理\n```\n\n## ★ 唯一剩余阻塞：**真实设备**（与本会话既定卡点一致）\n\n```\npush_tokens 表行数 = **0**   （2026-09-30 实测）\n卡点: `getToken` 只能在**带华为账号的真机**上取到 —— 无模拟器路径\n⇒ 服务端三条端点、客户端契约、包名、AGC 配置**都已就位**，\n   缺的只是一台真机走一遍: 取 token → POST 上报 → 服务端落一行\n```\n\n## 可判动作 / 下一步\n\n· 拿到真机后：`pushService.getToken()` → `POST /api/v1/me/devices/push-token`\n  → 复查 `select count(*) from push_tokens`（应 > 0）。\n· 在此之前**不要**把推送当依赖：任何新代码不得让推送失败影响 SSE 主通道\n  （第④条已实现，改动时保持 `catch` 静默）。\n· ⚠️ `build/` 下那份 `agconnect-services.json` 是**构建产物**；\n  提交/同步时以 `entry/src/main/resources/rawfile/` 那份为准。\n\n## 边界 / 未做\n\n· **没有改任何代码、没有跑真机**（本轮只读 grep + SQL + 文件查找）。\n· 上述\"已落地\"是**静态核实**（文件在位、端点存在、catch 静默），\n  **不等于**端到端跑通 —— 端到端需要真机，这正是本条的阻塞。\n· 我**没有**核 `api/ApiClient.ets` 与 `LoginPage.ets` 里 Push Kit 的全部调用路径，\n  只核了 `PushService.ets` 的静默性质与 MainPage 的路由三处。\n· 未能回给 pi（`send_mail` 被会话闸挡下）。"
+    },
+    {
+      "id": "criteria-suite-unwired-stops-everything",
+      "count": 1,
+      "due": "任何人给 `client/electron/test/` 加新 `*.test.mjs` 之后（新增判据者的义务，与「接线是作者的义务」同一条）；判据：加完就 `node test/run-all.mjs` 看 `RESULT files=N ran=N`，`ran` 必须等于 `SUITE` 条数",
+      "where": "client/electron/test/run-all.mjs（自检 2「每个 `*.test.mjs` 都要在清单里」，:202 起）+ SUITE（:62）+ package.json 的 `test` 脚本（`run-all && vitest && typecheck`）· 实例：test/inbox-fallback-poll.test.mjs、test/sse-credentials.test.mjs、test/web-comment-only.test.mjs（`aeb1f41` / `2f17f62` 引入，均晚于 run-all.mjs 最后一次改动 `62b7c94`）",
+      "kind": "**判据「存在」与判据「在跑」是两件事，而这里的失效形状是「全停」**。自检 2 在跑任何判据**之前** `process.exit(1)` ⇒ 实测 `RESULT` 行数 = **0**，一条读数都没有。又因 `npm test` 是 `&&` 链，vitest（270 格）与 typecheck **一起不跑**——而两者单独跑都是绿的。失败信息只有一行 stderr，看起来像「环境问题」。⚠️ **整仓 24 小时没有任何判据读数**，而下一个人（包括我）据上一份报告继续推断「判据在把守」⇒ **报告的证据等级被系统性高估**。守卫本身**不删**（漏接线绝不静默是真价值），代价就是「一个文件漏接 = 全仓失去全部读数」，风险随判据数单调上升 ⇒ 必须靠「新增即接线」这条义务兜。",
+      "note": "★★★ 2026-10-03 发现并修复（三个文件补进 SUITE，登记数按 node:test 惯例写 0）。\n\n## 为什么之前没人发现\n失败输出是中文一行 stderr，**不含任何「红」字样**，也不含退出码语义；`npm test` 的非 0 在很多 CI/脚本包装里被忽略。而**判据目录里没有一条判据检查「套件上一次真读到数是什么时候」**。\n\n## 同族：管道吞掉退出码（本会话同时踩了三次）\n`cmd 2>&1 | tail -N` ⇒ `$?` 是 **`tail` 的**退出码，不是 `cmd` 的 ⇒ `bg_run` 的 `exit-code` 报 0。\n实例：`npm test | tail -80`（真实：0 条判据跑过）、`npm test | tail -30`（真实：run-all red，vitest 根本没跑）、`tsc --noEmit | tail -20`（**碰巧**也是 0）。\n⇒ 第三次事实为真但**当时无根据**，仍必须重取证：`cmd >file 2>&1; echo $?`。\n\n## 可判动作\n· 新增 `*.test.mjs` 之后，`node test/run-all.mjs | grep RESULT` 看 `ran` 是否等于 `SUITE` 条数；\n· **退出码只从不接管道的运行取**（`| tail`/`| head`/`| grep` 全返回末端码）；\n· `&&` 链里「全绿」要问**真跑到那一环了吗**——red 之后的东西**根本没跑**，日志里「有 RESULT 行」与「无下游输出」可以同时出现。\n\n## 边界 / 未做\n· 本笔只登记**机制**；已修的三个文件与登记数漂移是同一批改动。\n· 「上次读到数是什么时候」**没有做成判据** —— 要可靠地判，得先有持久化的运行记录（现在 RESULT 只在 stdout），那是另一件事。"
     }
   ]
 }