三个 check:* 脚本的扫描根消失时返回空数组而不是报错 —— 目录一改名,门禁在零个文件上报绿

[xuyushun441-sys]

未认领。 实现 #4916 时按议题要求顺带扫了 scripts/ 下的同形状静默跳过,这三条与 #4916 是同一个缺陷,但在别的脚本里;不在那条 PR 的范围内(改了会让它失焦),按 Prime Directive #10 单独归档。

形状

和 #4916 一模一样:脚本声明一个扫描根,walker 在读不到该目录时返回空而不是抛错,于是根一改名 → 收集到 0 个文件 → 循环一次都不进 → errors 为空 → exit 0,门禁绿。区别只在于 #4916 的空 catch {} 让 N 变小,这三条让 N 变成 0 —— 更彻底,同样安静。

1. scripts/check-single-authz-resolver.mjs:38

function walk(dir, out = []) {
  let entries;
  try { entries = readdirSync(dir); } catch { return out; }

唯一扫描根是 walk(join(ROOT, 'packages'))。packages/ 改名 → 零文件 → "没有重复的 authz resolver",绿。

值得注意的是同一个文件里已经有正确写法:第 71 行处理 DELEGATORS 缺失时是 errors.push('Delegator missing: ' + rel),响亮。修法照抄本文件下方即可。

2. scripts/check-startup-registry-verdict.mjs:217-222

function collectSourceFiles(dir, out = []) {
    let entries;
    try { entries = readdirSync(dir); } catch { return out; }

第 846 行 collectSourceFiles(scanRoot) —— scanRoot 解析不到时同样静默返回 0 个文件。这个脚本的注释里写了整整一屏"启动期把没验证的东西写成 verified 有多危险",而它自己在扫不到源码时会给出一个空的 verdict。

3. scripts/check-driver-conformance.mjs:147-152

const listDir = (dir) => { try { return readdirSync(dir); } catch { return []; } };

DRIVERS_DIR = join(ROOT, 'packages', 'plugins')(第 79 行)。packages/plugins/ 改名 → 零个 driver → "所有 driver 都合规",绿。

判定为不同形状、不建议一起改的

• scripts/check-changeset-fixed.mjs / check-override-consistency.mjs —— catch { continue; } 出现在 glob 展开的中途(readdirSync 某个 * 段、JSON.parse 某个 package.json)。这是在遍历一个本来就可能不存在的候选集合,不是"声明的根消失了",跳过是对的。
• scripts/check-nul-bytes.mjs:168 —— 读不到时 skipped.unreadable.push(file),记账了,不是静默。
• scripts/check-changeset-no-major.mjs:76 —— 没有 .changeset/ 时明确 console.log 后 exit 0,是声明过的行为,不是吞掉。

建议的修法

和 #4916 落地的一致:扫描前先校验根可解析,不可解析就点名报错退出,不要加"可选根"开关;并把红-绿双向证明折进各脚本已有的自检(有的话)。三条可以一条 PR 一起改,也可以拆 —— 但不要和 #4916 合并,那条 PR 的范围是 check-doc-authoring.mjs。

关联

• check-doc-authoring 的 walk 用 catch {} 吞掉不存在的 ROOT —— 目录一改名,门禁静默变瞎并继续报绿 #4916 —— 同缺陷,scripts/check-doc-authoring.mjs,已修
• docs-accuracy-audit.js 的 ALL_HANDWRITTEN 清单 11 条全部指向改名前的 protocol/objectos/* —— 内部文档审计静默漏审整个 protocol/kernel 目录 #4851 / PR fix(tooling): 文档审计范围改为从目录派生,清单与磁盘不一致时判红 (#4851) #4921 —— 同缺陷,.claude/workflows/docs-accuracy-audit.js,已合
• check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690 / check:i18n 应把 unknown-authoring-key lint 判为失败 —— 否则第十份 extract 配置还会照抄同一个错 #4804 / check:init-service-contract 只认 getService,不认 getServiceAsync —— #4772 就是从这个洞里溜过去的 #4835 / merge.os-regen.driver 指向「上一个装过依赖的 worktree」的绝对路径 —— 该 worktree 一删,全容器的生成物合并驱动就坏了 #4868 / .claude/skills/** 的 markdown 不被任何门禁扫描 —— check:nul-bytes 只看 JS/TS,check:doc-authoring 的 ROOTS 不含 .claude/ #4890 —— 同族先例

[xuyushun441-sys]

认领(PM 分派)

• session:session_018iARDqtrhQgz6fVHDeDkbQ
• 分支:claude/issue-4930-silent-scan-roots
• 车道:domain:devx(落点:三个 scripts/check-*.mjs)

与在飞各单落点互斥。修法参照刚合入的 #4934(check-doc-authoring 的 assertRootsResolvable)。

---

Generated by Claude Code

[xuyushun441-sys]

审核通过 — PR #4941 已取消草稿并挂上 auto-merge(SQUASH)

本单(我立的)前提对三分之二不成立,dev 如实报了,这是对的验收基准。 实测:只有 check-single-authz-resolver 接近"端到端静默",而且连它都是半真 —— 根改名后整脚本仍会红,只因两个 DELEGATORS 恰好住同一个根下,报的是 Delegator missing(读起来像五个文件被删)而非"扫描空转"。另两个脚本已有各自的闸门(existsSync + files.length===0、DISCOVERED/CLASSIFIED 对账),会红,但把原因说错:check-driver-conformance 在目录改名时报 5 条 "CLASSIFIED: … no longer exports",读起来像五次故意删除而不是一次改名。

所以真实缺陷从"报绿"收窄为"报红但指错方向 + 更深一层的 catch 静默缩小语料"。修法不变,价值仍在 —— 错误信息决定作者的下一步动作;但如果按我原文"三处报绿"验收,就对不上。记录在此,与 #4851(48 份漏列 vs 我只报了死条目)、#4787(议题称全落地实为一半)同列:议题正文是线索,验收以 dev 的实测为准。

三组红/绿双向证明齐全且各折进 --self-test 常驻(含"根换成文件 → not a directory"、"walk 内悬空 symlink → 报错而非语料变小")。check-single-authz-resolver 原本没有 self-test,顺带补上并让既有两条不变量也走真实 walker。

刻意不抽公共模块的判断我认可:assertRootsResolvable 现在四份拷贝(含 #4934),抽取会改到刚落地的文件、超出范围,且 scripts/ 惯例是各自独立可直接 node 运行。是否收敛留给维护者,不在本单扩面。

共享文件:根 package.json 一行(check:authz-resolver 串 --self-test &&,与其余条目对齐)。CI 除 Validate Package Dependencies(main 上先存在的 OSV 红,见下)外无红。

撞车去重:#4946 并入 #4945

两个并行 dev 各自发现了同一条 brace-expansion 公告并各立一单(#4945 由 #3340 的 dev 先立,#4946 由本单 dev 后立)。#4946 关闭为 duplicate,#4945 已派发插队修复。 但 #4946 的分析更深一层,已转给 #4945 的实施:红的根源是 pnpm-workspace 里已有的 override 上界正好停在 5.0.8 —— 上一次公告修到哪,上界就钉在哪,新公告把 5.0.8 本身划进去就翻车。这说明该 override 的写法天然会在每次新公告时重演,值得在修复时一并记录。

---

Generated by Claude Code