在 #4688 (双源 C11)跑源码审计组时顺手发现,与该簇无关,按第十条军规立此单记录,未开工 。
现象
check:generated 把 8 个「无生成物的纯源码审计」列为 deliberately-not-run。逐个核对它们在 CI 里的落点:
门禁
接进的 workflow
check:liveness
spec-liveness-check.yml
check:empty-state
spec-liveness-check.yml
check:variant-docs
lint.yml + spec-liveness-check.yml
check:strictness-ledger
lint.yml + spec-liveness-check.yml
check:exported-any
lint.yml
check:dual-source-exports
lint.yml
check:skill-examples
lint.yml
check:react-declaration-parity
无 —— 不在任何 workflow 里
复现:
$ grep -rl " check:react-declaration-parity" .github/workflows/
# (无输出)
而且即便有人手工跑,不带 MANIFEST 时它也不做任何事:
$ pnpm --filter @objectstack/spec check:react-declaration-parity
⚠ react-blocks declaration parity: manifest unavailable (set MANIFEST=…) — skipping.
$ echo $?
0
两件事叠起来:这个门禁当前不存在任何一条能让它变红的路径。 没接 CI,手工跑又默认 skip 并退出 0。
为什么值得单独记一笔
AGENTS.md 里专门有一段讲这个门禁的历史 —— 它原名 check:react-conformance,声称能确认组件「ACTUALLY implement」spec props,而它根本做不到;kind:'react' 页面上 record:* 四个 block 全部失效——契约 publish 的 objectName/recordId 渲染器根本不读(#4340 后续) #4413 就这样让 4 个 dead block 从它的绿灯里过去了,check-react-blocks-conformance 比的是两份声明,不是声明↔实现——#4413 全程它都是绿的(Prime Directive #10 落在门禁自己身上) #4472 才改名并重新定范围。文档的结论是「The gate is still worth having(spec-only / registry-only / missing 是真信号)」。既然值得有,它就该真的会红。
这正好撞在 AGENTS.md「Route & surface ownership」第 3 条上:Absence must be loud —— 「a verifier that silently degrades (reusing a stale build, skipping a check it could not run) is worse than no verifier, because it reports success. Prefer failing to falling back.」跳过 + 退出 0 就是这条描述的那个反面样本。
它和已知的门禁洞(spec 门禁盲区:可作者化 key 的「默认值 / 约束」变更不被任何 gate、tombstone 或 conversion 记录(#4650 / #4659 同族) #4666 默认值/约束不被记录、authorable-surface 的 tombstone 门禁可被手编基线绕过 —— 删掉基线行就删掉了证据(#4638 / #4643 已两次这样过绿) #4650 手编基线、build-schemas.ts 检查 (b) 用叶名匹配 conversion surface —— 无关簇的 .type 就能让一个 tombstone 冒充「已登记迁移」 #4659 绿≠登记正确、packages/spec 的「编译期 pin」是失效的:tsconfig 排除了 *.test.ts,vitest 也不做类型检查 #4642 编译期 pin 空转)是同一族但不同的 问题:那些是「门禁看不见某类变化」,这个是「门禁根本没被调用」。检索 open issue 未见重复。
可能的处置方向(留给维护者定,未做取舍)
接进 lint.yml,并让缺 MANIFEST 时报错退出非 0 ,而不是 skip —— 符合「Prefer failing to falling back」。
或者:如果 manifest 在本仓天然拿不到(它来自 sibling repo objectui 的 registry config),那"接不进 CI"本身才是根因,需要先决定 manifest 从哪来;在那之前至少让 check:generated 把它标成「结构上无法运行」而不是与其余 7 个并列的「deliberately not run」,后者读起来像是有人跑。
关联
#4472 (改名 + 重定范围)、#4413 (4 个 dead block 从绿灯过)、#4203 / #4232 (未分类脚本导致的门禁休眠先例)、#4688 (发现时的上下文)
Generated by Claude Code
在 #4688(双源 C11)跑源码审计组时顺手发现,与该簇无关,按第十条军规立此单记录,未开工。
现象
check:generated把 8 个「无生成物的纯源码审计」列为 deliberately-not-run。逐个核对它们在 CI 里的落点:check:livenessspec-liveness-check.ymlcheck:empty-statespec-liveness-check.ymlcheck:variant-docslint.yml+spec-liveness-check.ymlcheck:strictness-ledgerlint.yml+spec-liveness-check.ymlcheck:exported-anylint.ymlcheck:dual-source-exportslint.ymlcheck:skill-exampleslint.ymlcheck:react-declaration-parity复现:
而且即便有人手工跑,不带
MANIFEST时它也不做任何事:两件事叠起来:这个门禁当前不存在任何一条能让它变红的路径。 没接 CI,手工跑又默认 skip 并退出 0。
为什么值得单独记一笔
AGENTS.md 里专门有一段讲这个门禁的历史 —— 它原名
check:react-conformance,声称能确认组件「ACTUALLY implement」spec props,而它根本做不到;kind:'react' 页面上 record:* 四个 block 全部失效——契约 publish 的 objectName/recordId 渲染器根本不读(#4340 后续) #4413 就这样让 4 个 dead block 从它的绿灯里过去了,check-react-blocks-conformance 比的是两份声明,不是声明↔实现——#4413 全程它都是绿的(Prime Directive #10 落在门禁自己身上) #4472 才改名并重新定范围。文档的结论是「The gate is still worth having(spec-only/registry-only/missing是真信号)」。既然值得有,它就该真的会红。这正好撞在 AGENTS.md「Route & surface ownership」第 3 条上:Absence must be loud —— 「a verifier that silently degrades (reusing a stale build, skipping a check it could not run) is worse than no verifier, because it reports success. Prefer failing to falling back.」跳过 + 退出 0 就是这条描述的那个反面样本。
它和已知的门禁洞(spec 门禁盲区:可作者化 key 的「默认值 / 约束」变更不被任何 gate、tombstone 或 conversion 记录(#4650 / #4659 同族) #4666 默认值/约束不被记录、authorable-surface 的 tombstone 门禁可被手编基线绕过 —— 删掉基线行就删掉了证据(#4638 / #4643 已两次这样过绿) #4650 手编基线、build-schemas.ts 检查 (b) 用叶名匹配 conversion surface —— 无关簇的
.type就能让一个 tombstone 冒充「已登记迁移」 #4659 绿≠登记正确、packages/spec 的「编译期 pin」是失效的:tsconfig 排除了 *.test.ts,vitest 也不做类型检查 #4642 编译期 pin 空转)是同一族但不同的问题:那些是「门禁看不见某类变化」,这个是「门禁根本没被调用」。检索 open issue 未见重复。可能的处置方向(留给维护者定,未做取舍)
lint.yml,并让缺MANIFEST时报错退出非 0,而不是 skip —— 符合「Prefer failing to falling back」。objectui的 registry config),那"接不进 CI"本身才是根因,需要先决定 manifest 从哪来;在那之前至少让check:generated把它标成「结构上无法运行」而不是与其余 7 个并列的「deliberately not run」,后者读起来像是有人跑。关联
#4472(改名 + 重定范围)、#4413(4 个 dead block 从绿灯过)、#4203 / #4232(未分类脚本导致的门禁休眠先例)、#4688(发现时的上下文)
Generated by Claude Code