Skip to content

check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690

Description

@os-zhuang

#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。

为什么值得单独记一笔

  1. 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 是真信号)」。既然值得有,它就该真的会红。

  2. 这正好撞在 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 就是这条描述的那个反面样本。

  3. 它和已知的门禁洞(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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions