[bug] run-tests.sh 是文档声称的必过门，却不在任何 CI workflow 里

[PanQiWei]

What happened

bash run-tests.sh 是 AGENTS.md §10 与 CONTRIBUTING「before you open a PR」列为必须以 ALL TESTS PASSED 收尾的一道门，但没有任何 CI workflow 运行它。

于是这道门在实际执行上只靠人工自觉。而它已经漏了：60bc0f13 (#209) 合入时带进了两条从未跑绿的测试，并在 main 上一直红到 2026-07-28 被发现。期间 ccm-ci 对每个相关 commit 都报 success。

证据

CI 的 required check build-and-check 只聚合两个 job：

build-and-check  needs: [ccm, plugin-contracts]

plugin-contracts 实际只跑：

tests/content/skill-knowledge-scaffold.test.mjs
tests/content/plugin-release-package-contract.test.mjs
tests/content/trusted-release-bundle.test.mjs
node scripts/skill-knowledge.mjs check --stage K0     ← 只到 K0，不是 K3
node scripts/check-release-knowledge-boundary.mjs

grep -rn "run-tests" .github/workflows/ → 零命中。

tests/content/ 下目前有 60+ 个测试文件，CI 只选跑其中 3 个。

漏掉的两条（已在分支 feat/issue-211-user-unknowns 修复，但机制缺口仍在）

两条都来自 60bc0f13 (#209)，且都与同一个 commit 引入的代码/守卫互相矛盾：

1. skill-overlay-v3-skills-swap-commit.test.mjs 的 v4: 用例测的是 projectAndPublishSkillsSurface 的 legacy beforePublish 接缝——而同一个 PR 把该接缝改成了显式拒绝。
2. skill-overlay-v9-whole-host-atomic.test.mjs 断言 plugin/dist/<host>/knowledge 存在——而同一个 PR 加的 check-release-knowledge-boundary.mjs 正是为了保证它不存在（knowledge/ 是 repo-only，禁止进 dist/package/release）。

一个 PR 内自相矛盾却能合入，正说明这道门没有机制执行。

What you expected

要么 run-tests.sh 真的成为 CI 门的一部分，要么 AGENTS.md / CONTRIBUTING 不再把它写成必过的硬门。文档声称的门与机制执行的门应当一致。

可能的修法（未定，需要权衡）

1. 把 run-tests.sh 整体接进 plugin-contracts —— 最直接，但本地实测全套约 90 分钟（attestation-regen-convergence 会重跑整条 attestation 流水线；skill-knowledge 隔离测试每个 case 建隔离仓跑全量投影）。直接上 CI 的 runner 成本需要评估，且与 #212 刚做的「reduce redundant Actions usage」方向相反。
2. 扩 plugin-contracts 的测试名单到 tests/content/ 全集 —— 比 (1) 轻，但仍需评估时长。
3. 分层：把快的 content 测试接进每 PR 的 required check，把重的（attestation / 隔离投影）放 nightly 或 ci: label 触发（仓库已有 ci:macos-live 这个 opt-in label 先例）。
4. 只加一道防回归的窄门：至少保证「测试文件与它测的代码在同一个 PR 内不自相矛盾」——但这个不好机械表达。

倾向 (3)，因为它同时解决「门要真」和「不烧 runner」两个约束，且仓库已有同型先例。具体阈值与切分需要先量各测试文件的实际耗时。

附带观察

本仓测试时长与知识图规模是超线性关系的：skill-knowledge 那批测试每个 case 都建隔离仓跑全量四 host 投影，图每长一个 module，每个 case 都变慢。这会让 (1) 随时间越来越贵，也是倾向 (3) 的理由之一。

Fit with cc-master's design

• 不涉及 hooks，不触碰 board narrow waist
• 不改变 ship-anywhere 口径
• 纯 CI / 工程门问题，不改分发 skill 语义

[PanQiWei]

补充：成本结构与切分建议

把 run-tests.sh 整体搬进 workflow 不合适，但结论不是「门不该机制化」——是这个套件当前的形状不是 CI 形状。

成本从哪来

tests/content/                       68 个文件
其中会「建隔离仓 + 跑真实四 host 投影」   15 个

判据是文件里有没有 copyMinimalSkillKnowledgeRepo() + spawnSync('bash', ['scripts/sync-plugin-dist.sh', ...])。

这些 case 的模式是：建一个隔离仓 → 跑全量四 host 投影 → 然后断言一个局部不变式（符号链接被拒 / knowledge 不在 dist / 无 .write- 残留）。也就是拿端到端集成测试的代价，去测单元级的不变式，且几十个 case 各自重复付同一笔昂贵设置。

已测到的数（本机 Linux / Node 24，2026-07-28）：

• 全套 run-tests.sh ≈ 90 分钟
• 单个 case 38–135 秒（如 v9: Codex skills-only final bytes include entry-pin 101s、v3: live skills symlink is refused 100s）
• attestation-regen-convergence.test.mjs 单独 20+ 分钟（它重跑整条 attestation 流水线两遍做字节稳定性对拍）

而且它超线性恶化

那 15 个文件里每个 case 都跑全量四 host 投影，知识图每长一个 module，所有这些 case 都变慢。本轮往图里加了一个 module 之后，套件比之前更慢了。直接把它接进每 PR 的门，等于给这条上升曲线接上账单——与 #212 刚做的「reduce redundant Actions usage」方向相反。

建议：三层切分

层	内容	目标时长	触发
L1	不需要真实投影的 content 测试（约 53 个）+ skill-knowledge check --stage K3 + parity matrix --check + skill-lint.sh + hook 测试	< 5 min	每 PR required
L2	需要投影产物的断言，但共享一次 fixture——建一次隔离仓、跑一次四 host 投影，多个断言复用	< 10 min	每 PR required
L3	真正必须各自独占一份干净世界的：TOCTOU 接缝注入、late-fault、attestation convergence	不限	nightly 或 ci: label（仓库已有 ci:macos-live opt-in 先例）

L2 是收益最大的一笔：把 N × 60 秒 变成 1 × 60 秒 + N × 毫秒。那 15 个文件里多数断言只是读投影产物，并不需要独占世界；真正需要独占的是「在投影中途注入故障」那几条，它们归 L3。

注意 check --stage K3：CI 现在只跑 --stage K0（只做 envelope/id 扫描），而 K3 才跑完整 schema + binding + graph 不变式 + 四 host projection。K3 本身很快（秒级），这一条应当立刻进 L1——它是本 issue 描述的那类「测试与代码自相矛盾」最直接的守卫。

三个诚实的边界

1. L1/L2 的切分靠读代码，不是靠测量。 判据是文件里有没有 copyMinimalSkillKnowledgeRepo，没有 per-file 实测耗时。落地前应先跑一次带 per-file 计时的采集，让阈值有实测支撑。
2. L2 是测试重构，不是 CI 配置。 共享 fixture 会引入 case 间耦合（一个 case 弄脏 fixture 就污染后面的），需要设计只读约束。不该在本 issue 里顺手做，应当是独立任务。
3. attestation-regen-convergence 建议直接判 L3。 它测的是「重算两遍字节相同」——一个确定性属性，不是每次改动都会破的东西。为它在每个 PR 花 20 分钟性价比很差；nightly 破了也是当天发现。

落地顺序

三层可以拆三个 PR，L1 先上就能立刻堵住本 issue 描述的大部分漏洞（纯 workflow 配置，无需改测试）。L2 独立排期。L3 是 label/nightly 配置。

[PanQiWei]

补充二：对 run-tests.sh 的完整点评（成本根因 + 逐族判定）

上一条给了三层切分。继续挖之后发现上一条的 L2 是次优解，真正的根因在别处。以下是完整发现。

---

1. 根因：入口高度，不是测试数量

scripts/skill-knowledge/path-authority.mjs     603 行
  其中 spawnSync / execSync / child_process     0 处   ← 纯函数
tests/ 中直接引用 path-authority 的文件         0 个   ← 没有任何直接单测

而五个文件、约 29 个 case 在测同一族路径判定：

文件	入口
skill-knowledge-isolated-repo-boundary	copyMinimalSkillKnowledgeRepo
skill-overlay-v3-containment-safe-read	+ sync-plugin-dist.sh
skill-overlay-v10-candidate-entry-trust	+ runCompile / compile-candidate-host / resolveTrustedCandidateHostDist
skill-overlay-v11-candidate-root-boundary	同上
skill-overlay-bridge-path-escape	+ sync-plugin-dist.sh

一个纯函数的判定（「这个路径该不该被拒」），被从最外层端到端入口跑了约 29 次，每次付一遍全量四 host 投影。 resolveTrustedCandidateHostDist 更是被 v10 和 v11 各自通过完整投影验了一遍。

代价不在测了什么，在从多高的地方测。

因此把上一条的 L2（共享 fixture）降为次优：共享 fixture 只是让昂贵设置少跑几次；下沉入口是让它根本不必跑。

修正后的第一优先级 —— L0：给 path-authority.mjs / compile/trusted-host-dist.mjs 写直接单测（毫秒级），端到端只保留 2–3 条代表性 case，用来证明「守卫确实接在链路上」而非重复验证判定本身。29 → 3，且覆盖不降反升（纯函数能穷举边界，端到端只能抽样）。

---

2. 一个必须先讲清的反面：这些不变式不能删

看到约 50 个 case 全是符号链接逃逸、路径穿越、fail-closed、拒绝篡改，很容易得出「这是给单机 dev 工具做的过度加固」。这个结论是错的：

1. 调用者是 agent，不是人。 输入包含 plugin/src/knowledge/** 这类 agent 可写的内容——路径可被构造，威胁模型成立。
2. 它们写的是 plugin/dist，即分发面。 路径逃逸的后果是往发布产物写东西，是供应链后果。
3. 仓内有 25KB 的 design_docs/skill-knowledge-graph/trusted-projection-transaction.md，说明这套加固是有意设计，不是攒出来的。

拿「这是内部工具」当理由删安全测试，是典型的合理化。要动的是形状，不是存在性。

---

3. 逐族判定

测试族	判定	依据
路径逃逸族（v3 / v10 / v11 / bridge / isolated-repo，~29 case）	不变式全留，入口下沉到 L0	见 §1
attestation-regen-convergence（2 case，20+ 分钟）	唯一可直接质疑存在必要性的	它测幂等性（「重算两遍字节相同」）。而幂等破了的后果是 registry 漂移 → sync 当场拒绝发布——这是会立即自暴露的失败，不是静默的。为一个自暴露的失败在每次全量跑里花 20 分钟，性价比最差。至少降 nightly；也可论证删除
skill-knowledge-change-codex-review-fixes（18 case）	保留，但应停止这种增长方式	case 名即来源：CODEX-F1/F2/…/A/B/C/D/E。这是把一次 review 的每条 finding 逐条固化。它锚定的是那次 review 提到的点，不是模块的不变式空间；边际价值递减，且这类测试集会随每次 review 线性膨胀
skill-overlay-marker-strictness（6 case）	保留，可下沉	测 malformed 输入 hard-fail，同样是纯判定，不需要全量投影

---

4. run-tests.sh 脚本本身的可优化点

读了 99 行全文，四处：

1. bash 段完全串行（L57–68）：tests/hooks/test_*.sh 与 tests/scripts/test_*.sh 都是 for 循环逐个跑，无并发。这些多是快测试，但串行累加仍是净损失。
2. 套件内嵌一次真实投影（L74）：bash scripts/sync-plugin-dist.sh --host codex --skills-only 是套件的一个步骤，本身就要分钟级。
3. 无 per-file 计时：node --test $node_tests 不带任何计时汇总。这直接导致本 issue 的三层切分只能靠读代码判断，不能靠测量。 建议先加一次 --test-reporter 计时采集，让阈值有实测支撑。
4. 不早停（fail=1 累加）：设计上是为了一次跑出全部失败，合理；但代价是即使第一个测试就挂，也要付满 90 分钟。若接进 CI，建议 required 层早停、完整层不早停。

---

5. 关于本 issue 的原始现象，一个补充解释

「测试与它测的代码在同一个 PR 内自相矛盾还能合入」——除了「CI 不跑 run-tests.sh」这个直接原因，还有一层放大：套件跑一次 90 分钟。

一个 90 分钟的本地门，实际执行率必然低。门的成本与它被绕过的概率正相关。 所以「把它变快」和「把它接进 CI」不是两件可选的事，是同一件事的两半——只接不快，会得到一个人人 --no-verify 的 CI。

---

6. 建议的落地顺序（修正版）

步	内容	性质	前置
0	node --test 加计时采集，跑一次拿 per-file 实测	一次性测量	—
1	check --stage K3 进 CI（当前只跑 K0，而 K3 秒级且正是本 issue 那类矛盾最直接的守卫）	纯配置，零成本立即见效	—
2	L0 入口下沉：给 path-authority / trusted-host-dist 写直接单测，29 个端到端 case 压到 3	测试重构	0
3	attestation-regen-convergence 降 nightly / ci: label	纯配置	—
4	快测试集进每 PR required；重的走 nightly（仓库已有 ci:macos-live opt-in 先例）	CI 配置	0,2,3

第 1 步值得单独强调：它是纯配置、秒级、零新增成本，且直接针对本 issue 的现象。 其余都可以慢慢排。