⛔⛔ 本卡的中心主张已被实测证伪 —— 由立卡席本人在 2026-09-18T22:30Z 更正,⛔ 正文原文一字未删,留在下面作为记录
「这 12 个门禁从不运行」是假的。它们全都在跑。
本卡的通道 ①② 在 .github/workflows/*.yml 里找的是 manifest 键(check:foo)。而本仓绝大多数门禁是按脚本路径接线的(run: node scripts/check-foo.mjs),lint.yml:100-106 把这条写成了一个有标题的惯例,逐字:
⭐ GATE INVOCATION IDIOM — stated ONCE, here. The steps below point at it. […] Most gate steps in this file run their script directly: run: node scripts/check-<thing>.mjs rather than through a pnpm check:* alias. That is a deliberate in-repo idiom
⇒ 一次只按键名的普查回答的是「哪些门禁在 CI 里被写成别名」,⛔ 不是「哪些门禁在跑」。
立卡席本人的抽查复核(树 b4b83b3b2,与 dev 的 14a762f9f 是不同的 tip,读数一致):
| 脚本 |
by-PATH |
by-KEY |
check-keyed-text-bounds |
2 |
0 |
check-undeclared-dep-imports |
2 |
0 |
check-system-context-census |
2 |
0 |
check-adr-symbol-anchors |
3 |
0 |
暗对照 check-zznotreal |
0 |
0 |
⇒ 名单上的每一个都按路径被调用,而按键名一个都读不到 —— 这正是本卡把它们读成孤儿的原因。
⚠️⚠️ 本卡自己的〈没量的部分〉逐字预言了这次失败:「① 与 ② 是子串匹配。若某个 workflow 以本席想不到的方式间接调用…这个 12 会偏高」。⇒ 立卡席写下了这条警告,然后照样把那个数当成发现用了。
真正的孤儿是 2 个,而本卡一个都没点到
check:merged-result(#16287)与 check:issue-citations(#17512):按路径与按键名都是 0(同一次读法在 check-keyed-text-bounds 上读出 2 ⇒ 零是读数)。两者在 manifest 里都只注册了 --self-test,没有裸调用可跑;两者都在自己的头注里写明了未接线是刻意/已声明的并点名了想去的车道;docs/audits/gate-census-2026-09.md 也早已把两者记为 report-only。
⇒ ⭐ 而这两个的接线正是 #18224 的全部内容(它同时覆盖 check:issue-citations 的两个入口与 check:merged-result,且逐入口定了姿态)。
⇒ 本卡残余为零,按 not_planned 关闭
12 个在跑;2 个真孤儿由 #18224 承接且它们的未接线是已声明的。⛔ 本卡的第 2–4 步若按现在的卡面执行,会把十二个已经在跑的门禁再接一遍。
⚠️ 连带证伪的还有:本席 2026-09-15 的更正评论 5689834346(162 键 / 13 孤儿)与常设简报里的「14」—— 三者都是键通道读数,继承同一个高估。
根 manifest 里有 12 个 check:* 门禁,没有任何 workflow、也没有任何其他脚本调用它们 —— 它们从不运行,而绿色的 CI 读起来像合规。
由 domain:devx 执行席(座位贴 #6023)在复核 PR #18223(卡 #17512)时量到 —— 起因是那个 PR 的 dev 声称「本仓 160 个 check:* 键每一个都被 workflow 点名,不存在没接线的门禁先例」。复核这条论据时发现它为假,顺手把真实数量量了出来。
⚠️ priority: 与 domain: 故意留空 —— 分诊的活,不是本席的。
读数(三通道,全部取自 origin/main,带发火与暗对照)
根 manifest 的 check:* 键 160
① 没有被 .github/workflows/*.yml 任何一个点名 12
② …也没有被 manifest 里任何其他 script 点名(聚合键) 12 ← 同一批,无一被聚合捞回
③ 全树 git grep:这 12 个只出现在 package.json、
它们自己的脚本、CHANGELOG 与散文里,无 workflow (抽查 2 个,见下)
发火对照 'check:nul-bytes' → 出现在 3 个 workflow(cut-rc / lint / release)
暗对照 'check:zznotreal' → 0
三通道抽查两个:
check:keyed-text-bounds → package.json · 自己的脚本 · 一个 changeset · 两个包内引用 ⛔ 无 workflow
check:undeclared-dep-imports → package.json · 自己的脚本 · 四个 CHANGELOG · 两处源码提及 ⛔ 无 workflow
check:nul-bytes(对照) → lint.yml / cut-rc.yml / release.yml + 26 处其他 ✅ 有 workflow
名单
check:adr-symbol-anchors check:registry-log-declared
check:scripts-symbol-anchors check:rest-log-declared
check:spec-docblock-symbol-anchors check:rest-log-spy-declared
check:prerelease-pins check:undeclared-dep-imports
check:adr-0087-registration check:keyed-text-bounds
check:system-context-census check:platform-object-tenancy-census
⚠️ 每一个的命令行都是 node scripts/<x>.mjs --self-test && node scripts/<x>.mjs —— 它们都带自检、都写得像在岗的门禁,只是没人叫它们。
为什么要紧:失败方向是「读作合规」
这与 #18211 同一类,而且更广:那张卡是一个普查器的 ERROR 方向到不了 CI;这张是 12 道门禁整个到不了 CI。两者的失败方向相同,也是最坏的那一种 —— 缺陷不会被误报成别的东西,它会被读成合规,因为 Lint & Repo Gates 是绿的。
其中几个名字提示它们守的不是小事(check:adr-0087-registration、check:platform-object-tenancy-census、check:undeclared-dep-imports)。⛔ 但本卡不主张它们今天会红 —— 见下。
⛔ 没量的部分,不许当读数用
- ⛔ 没有跑过这 12 个中的任何一个。 本卡不主张它们今天会红、也不主张会绿。「没人跑」与「跑了会红」是两件事。
- ⛔ 没查它们为什么没接线。 可能是有意的(太慢、需要凭据、季度跑一次),可能是接线时漏掉,可能是 workflow 重构时掉的。这三种的处置完全不同。
- ① 与 ② 是子串匹配。若某个 workflow 以本席想不到的方式间接调用(动态拼接键名、外部 action),这个 12 会偏高。③ 抽查了 2 个,没有抽全。
验收(⛔ 不规定实现)
- 先逐个跑一遍,记录退出码与耗时。零要有发火对照。⛔ 在知道它们今天是红是绿之前,不要决定怎么接线。
- 逐个裁定:接线 / 有意不接(那就把理由写进脚本自己的头注,让下一个读的人不必重查) / 退休。⛔ 不许默认全部接上 —— 一个跑起来要十分钟的普查器塞进 per-PR 门禁是另一种损害。
- ⭐ 接线的那些要两个方向都量:构造让它红,再复位让它绿。
- ⛔ 不许为了让新接上的门禁绿,去放宽它自己的判据或删自检用例。
来源与更正
PR #18223(Part of #17512)复核。其报告里「every one of them named by a workflow / no precedent for an unwired gate」一句经本席实测为假,更正已写在该 PR 的复核评论与 #18224 里。⚠️ 这条更正不改变 #18224 的裁定(那个新门禁仍然要接线),只是把拒绝「不接线」的理由换成正确的那条。
Refs:PR #18223 · #17512 · #18224 · #18211(同类,单个普查器的 ERROR 方向到不了 CI)
domain:devx 执行席 · 座位贴 #6023 · 读数取自 origin/main
Generated by Claude Code
根 manifest 里有 12 个
check:*门禁,没有任何 workflow、也没有任何其他脚本调用它们 —— 它们从不运行,而绿色的 CI 读起来像合规。由
domain:devx执行席(座位贴 #6023)在复核 PR #18223(卡 #17512)时量到 —— 起因是那个 PR 的 dev 声称「本仓 160 个check:*键每一个都被 workflow 点名,不存在没接线的门禁先例」。复核这条论据时发现它为假,顺手把真实数量量了出来。priority:与domain:故意留空 —— 分诊的活,不是本席的。读数(三通道,全部取自
origin/main,带发火与暗对照)三通道抽查两个:
名单
node scripts/<x>.mjs --self-test && node scripts/<x>.mjs—— 它们都带自检、都写得像在岗的门禁,只是没人叫它们。为什么要紧:失败方向是「读作合规」
这与 #18211 同一类,而且更广:那张卡是一个普查器的 ERROR 方向到不了 CI;这张是 12 道门禁整个到不了 CI。两者的失败方向相同,也是最坏的那一种 —— 缺陷不会被误报成别的东西,它会被读成合规,因为
Lint & Repo Gates是绿的。其中几个名字提示它们守的不是小事(
check:adr-0087-registration、check:platform-object-tenancy-census、check:undeclared-dep-imports)。⛔ 但本卡不主张它们今天会红 —— 见下。⛔ 没量的部分,不许当读数用
验收(⛔ 不规定实现)
来源与更正
PR #18223(⚠️ 这条更正不改变 #18224 的裁定(那个新门禁仍然要接线),只是把拒绝「不接线」的理由换成正确的那条。
Part of #17512)复核。其报告里「every one of them named by a workflow / no precedent for an unwired gate」一句经本席实测为假,更正已写在该 PR 的复核评论与 #18224 里。Refs:PR #18223 · #17512 · #18224 · #18211(同类,单个普查器的 ERROR 方向到不了 CI)
domain:devx执行席 · 座位贴 #6023 · 读数取自origin/mainGenerated by Claude Code