check-single-authz-resolver 的 walk 只收 `.ts`,`packages/` 下 12 个 `.mts` 从不被扫描(observation)

[hotlong]

在 #5916(PR #6056)补扫描语料下限断言时顺带量到的残余,与该 PR 的修法正交,不在其申报面内,故单独记录。

观察

scripts/check-single-authz-resolver.mjs 的 walk() 收集条件是:

else if (e.endsWith('.ts') && !e.endsWith('.test.ts') && !e.endsWith('.d.ts')) out.push(p);

'x.mts'.endsWith('.ts') 为 false(ts 前一个字符是 m 而非 .),.cts 同理。所以声明的扫描根 packages/ 下的 .mts / .cts 一个都不进语料 —— 检查 (1)「不存在重复的请求上下文解析器」这个结论,是在不包含它们的集合上得出的。

origin/main@efedd28 实测:

packages/ 下 .mts/.cts:   12
packages/ 下 .ts:       3053

12 个文件全部在 packages/spec/scripts/ 下(check-strictness-ledger.mts、liveness/*.mts 等构建/存活性脚本)。

今天是休眠的,不是漏判

逐个查过这 12 个文件,没有任何一个同时引用 sys_user_role 与 sys_user_permission_set,即没有一个会触发该门禁的启发式。所以今天没有真实漏判,用户也碰不到 —— 按 observation 归档,不带 pm:queue,请分诊裁定。

风险是形状上的:若日后有请求上下文解析逻辑落到 .mts/.cts(或仓库整体迁移扩展名),这道门会在看不见它的情况下继续印绿,正是 #4930 / #5916 这一族反复关的那种"门跑了但没读到"。

与 #5916 的关系(为什么不是同一件事)

• check-single-authz-resolver 的扫描语料没有下限断言:根解析成功但一个文件都没扫到仍然绿(observation) #5916 落地的是按根下限:每个 SCAN_ROOTS 条目至少产出 1 个文件。本条它结构上看不见 —— packages/ 产出 3053 个 .ts,远在下限之上,而那 12 个文件照样不在语料里。
• 也不是维护者在 check-single-authz-resolver 的扫描语料没有下限断言:根解析成功但一个文件都没扫到仍然绿(observation) #5916 明确否掉的高水位棘轮(那是"语料缩水但非空"的通用问题)。本条是一个具体的、可判定的扩展名过滤问题:声明要扫 packages/,实际只扫了它的一个扩展名子集。

可能的修法(供分诊参考,未实现)

1. 把过滤器放宽到 /\.(m|c)?ts$/ 并保持 .d.ts / .test.ts 排除 —— 语料变大,需确认那 12 个脚本不会误触发启发式(实测不会);
2. 或明确记录"只扫 .ts 是有意的",把理由写进模块头,让下一个读者不必重新推导。

按 1 更贴近"声明即执行":门禁声称读遍 packages/,那就该真的读遍。

相关:#5916(按根下限,已由 PR #6056 落地)、#4930 / #4916(死根按名报错)、#4932(同族先例)、#4690(「提取失败必须红」出处)。

[claude]

发现分诊轮(#4949 纪律):晋级 pm:queue(摘 finding),域维持 domain:devx(落点 scripts/ 门禁类,按 SKILL 域表)。

过时前提检查(origin/main @ 9e3709a,逐条实测)

• walk() 的收集条件仍是 e.endsWith('.ts') && !e.endsWith('.test.ts') && !e.endsWith('.d.ts')(scripts/check-single-authz-resolver.mjs:122),SCAN_ROOTS = ['packages'](:70)—— 正文成立;
• packages/ 下 .mts/.cts 12 个、.ts 3053 个(正文两个数原样复现),12 个全部在 packages/spec/scripts/ 下;
• 休眠性逐个复核:12 个文件对 sys_user_role / sys_user_permission_set 的命中数全部 0/0(启发式见 audit() 检查 (1) 的 src.includes(...) && src.includes(...)),阳性对照 packages/core/src/security/resolve-authz-context.ts 两词都命中 ⇒ 今天确无漏判;但检查 (1) 的「未发现重复解析器」这个结论,确实是在不含这 12 个文件的语料上得出的。

为什么晋级(而不是持有)

这是「门跑了,但没读遍它声明要读的东西」的 restore-invariant 形状(同族 #4930 / #4916 / #5916):判据明确、无产品取舍、落点单文件。修法 1(过滤器放宽到 /\.(m|c)?ts$/,保留 .d.ts / .test.ts 排除)的风险已由上面那条实测预先排除 —— 语料变大后那 12 个文件都不触发启发式,不会引入新的红。

硬串行(实测,非推断)

全仓 34 条 open PR 的文件面逐条拉过:只有 PR #6056(#5916,已 ready)动 scripts/check-single-authz-resolver.mjs(+146/-14),且其 diff 不含扩展名过滤那一行(它加的是零文件下限断言)。两者正交但同文件 ⇒ 本单排在 #6056 合入之后,⛔ 不要两单各改一半同一个文件(Operational note 8 的形状)。

范围钉死

只治扩展名过滤 + 一条回归断言(「.mts 真的进了语料」本身要有测试,否则下一次改回去照样静默)。⛔ 不动 SCAN_ROOTS、不重写 #5916 的下限断言逻辑、不搭高水位棘轮(维护者在 #5916 已明确否掉)。

相邻但不收敛:#5475(同样这 12 个文件落在任何 tsconfig 的 include 之外)—— 那是类型检查覆盖,本单是门禁扫描语料,两套机制两个落点,仅交叉链接,⛔ 不并单。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code