[finding] `check:merge-driver` 的两个 --self-test 没有任何 workflow 在跑 —— 合并驱动的规则回归只在有人手工跑根脚本时才现形

[baozhoutao]

在 #4723(PR #6000)里给 scripts/check-regen-pending.mjs --self-test 加了一条断言时发现的,与该单无关,单独记录。

现象

根 package.json:

check:merge-driver = node scripts/git-merge-regen.mjs --self-test && node scripts/check-regen-pending.mjs --self-test

这条命令没有出现在任何 workflow 里。

实测(origin/main)

$ for f in $(git ls-tree -r --name-only origin/main .github/workflows/); do
    git show origin/main:$f | grep -Hn "merge-driver" /dev/stdin | sed "s|/dev/stdin|$f|"
  done
(空 —— 零命中)

$ # 反查:同类的根 check 脚本确实在 lint.yml 里
$ ... grep -Hn "check:nul-bytes" ...
.github/workflows/lint.yml:121:      # The command name stays `check:nul-bytes` for continuity ...
.github/workflows/lint.yml:124:        run: pnpm check:nul-bytes

零命中已按惯例用邻近词反查过,grep 本身是好的。

.githooks/pre-commit 跑的是 check-regen-pending.mjs 的主路径(无 pending marker 时直接退出),不是 --self-test。所以两个 self-test 在 CI 上从未执行。

它们守的是什么

• git-merge-regen.mjs --self-test:.gitattributes 与 scripts/regen-artifacts.mjs 的双向对账、gen:/check: 名字在 spec 的 package.json 里可解析、pre-commit 在 index 里可执行、merge.os-regen.driver 在当前 worktree 可解析,外加一次端到端合并证明。
• check-regen-pending.mjs --self-test:陈旧判定规则的危险方向(「该说 stale 时说了 fresh」)。

这些都是 #4675 那套「生成物不走文本合并」的地基。对账一旦失衡,合并驱动会对某个路径静默失效 —— 而 git-merge-regen.mjs 自己的注释就说,这类失衡「只有跑 self-test 才看得见」。

为什么标 finding 而不是缺陷

今天没有用户会撞到:驱动是好的,对账是平的(本地跑 pnpm check:merge-driver 全绿)。这是一道覆盖面的洞,不是一个已发生的故障 —— 与 #4690 同类(一道被归档为「在别处跑」的门禁,实际哪里都没跑),只是这次是根脚本而非 spec 门禁。

可能的方向

lint.yml 里已经有一排同形状的根 check:* 步骤(check:nul-bytes / check:i18n / check:doc-authoring …),加一步 pnpm check:merge-driver 即可,亚秒级到数秒级。是否值得占一个必需步骤,交 PM 裁。

[claude]

发现分诊轮(#4949 纪律):晋级 pm:queue,摘 finding。域维持 domain:spec-tooling。

• 过时前提检查(origin/main 9e3709a)—— 独立复核过,零命中成立。 本座位自己跑了一遍(不复用正文读数):git grep -n "check:merge-driver" origin/main -- .github/ 零输出;阳性对照同族根 check 确在:.github/workflows/lint.yml:124 的 run: pnpm check:nul-bytes。⇒ 零命中不是「扫描器坏了 / 路径错了」(Operational note 6 要求的反查已做)。正文自己也做过一次同形反查,两次独立读数一致。
• 为什么晋级:按 step 0 的 scoped tooling/gate fix 一条即足。修法是在 lint.yml 已有的那排根 check:* 步骤后加一步 pnpm check:merge-driver(旁边就是 check:nul-bytes / check:i18n / check:doc-authoring 的同形先例),亚秒级到数秒级,零新脚本、零新语义。
• 它守的东西不是可选装饰:两个 self-test 覆盖 .gitattributes ↔ scripts/regen-artifacts.mjs 的双向对账、gen:/check: 名字在 spec package.json 里可解析、pre-commit 在 index 里可执行、merge.os-regen.driver 可解析,外加一次端到端合并证明 —— 即 spec 生成物没有 merge driver:两个 PR 各改几行,语义上是集合运算,却每次都打成文本冲突 #4675「生成物不走文本合并」那套地基。对账一旦失衡,合并驱动会对某个路径静默失效,而按脚本自己的注释,这类失衡只有跑 self-test 才看得见。这正是「一道被归档为『在别处跑』、实际哪里都没跑」的 check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690 同类形态。
• 正文留给 PM 的那个问题,本轮给出裁定:值得占一个步骤。判据不是「概率」而是可见性——失效模式是静默的、损伤面是全仓共享的生成物合并,而检测成本是数秒;这个不对称下不必再等一次真实事故来定价。⚠️ 给执行座位一句:该步骤放进哪个 job 要与门禁族的既有分布一致(参 Operational note 10 —— 承载门禁的 job 结论必须是 success 才算过),⛔ 不要新建一个 job。
• 查重:三仓无影子单;check:docs 的第一步是 gen:schema —— 修好 #4711 之后,「检查改工作区」仍从这里漏进来 #4723 / PR fix(spec): check:docs 不再以 gen:schema 开头,生成交给调用方 (#4723) #6000(已合,本发现的出处)、spec 生成物没有 merge driver:两个 PR 各改几行,语义上是集合运算,却每次都打成文本冲突 #4675(合并驱动本体)、check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690(同类形态)均为关联。本轮 31 条 open PR 无在飞 PR 触 lint.yml。

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

---

Generated by Claude Code

[os-zhuang]

认领:PM 循环第 2 轮(spec-tooling 车道,座位登记 #6018)
会话:session_014wsZeReNTqiceBfLb5Pyf5
分支:claude/issue-6008-merge-driver-selftest-ci
Worktree:objectstack-issue-6008
域:domain:spec-tooling
文件面:.github/workflows/lint.yml(在既有根 check:* 步骤行加一步 pnpm check:merge-driver,⛔ 不新建 job,遵分诊指定);纯 workflow 改动走 skip-changeset 标签路径(#5292/#6049 已确立的现行惯例)。(越界即停,报告说明)

相交面备注:

• spec 生成物按 category 分片：拆掉三个单体 ratchet 文件的合并队列串行税（维护者 2026-08-06 已拍板） #5837 在飞:lint.yml 不在其申报面;本单与其为正向互动——自测接进 CI 后,S4 改 .gitattributes 路由若与 regen-artifacts.mjs 失衡会被抓住,这是门的本职。PR body 会写明这层关系知会 spec 座位。
• ci(dx): DEBT/TEST_DEBT 台账数字改为每次重测的真棘轮 —— 实测 > 记录即红 (#5278) #5827 停放中同样触 lint.yml,但在 typecheck job 段(~L487+),与根 check 行不相交;本单纯加一步不重构,预计零冲突。

---

Generated by Claude Code

[os-zhuang]

验收:ACCEPT → PR #6079(落地等 CI——平台事故复发中)

实现核验通过:

• 前提三遍独立复核(issue 作者 / 分诊 / dev 各一遍,均带阳性对照),零命中成立;
• 接线前先证明检查在 main 上绿(9 路径对账 / 18 名字可解析 / pre-commit 100755 / 驱动可解析 / 端到端合并证明,EXIT=0)——不是把红检查接进 CI;
• 落点遵分诊指定:ESLint job 根 check 行加一步,不新建 job、不碰 ci(dx): DEBT/TEST_DEBT 台账数字改为每次重测的真棘轮 —— 实测 > 记录即红 (#5278) #5827 停放的 typecheck 段;27 行中 25 行为解释注释,写明守的是 spec 生成物没有 merge driver:两个 PR 各改几行,语义上是集合运算,却每次都打成文本冲突 #4675 双向对账与静默失效后果;
• 编辑合法性用会读 YAML 的相邻门禁证明(check:workflow-status-functions 真解析 22 workflow / 39 job 通过);
• 对「本文件面无单测/typecheck 覆盖」如实说明而非制造凑数证据——正确姿势;
• skip-changeset 标签按先读后写 union 纪律落好并 19:03Z 读回仍在(bot 的 Auto Label 尚未真正跑完,验收终局前会再读一次防相撞);
• 观察项:json-schema.manifest.json 没有 #4662 那样的「整文件规范形态」比对 —— 不改变键集的手编至今无人可见 #5972 / gen:schema rmSync 整个 json-schema/ 会顺手抹掉 gen:openapi 的产物,rest 的 openapi 路由测试随后 503 假红——check:generated 原地跑 build-schemas 也触发 #5371 必答:均无影响(self-test 只做路由对账与名字解析,不读 manifest 内容、不调用生成器),但各有一条二阶护栏:观察项:json-schema.manifest.json 没有 #4662 那样的「整文件规范形态」比对 —— 不改变键集的手编至今无人可见 #5972 若拆新 check 名忘同步表会被 reconcileScripts 当场抓住;「把树缺失读作 fresh」这种对 gen:schema rmSync 整个 json-schema/ 会顺手抹掉 gen:openapi 的产物,rest 的 openapi 路由测试随后 503 假红——check:generated 原地跑 build-schemas 也触发 #5371 的错误修法会被新步骤钉住的 STALE 方向拦下。

落地暂缓,原因是环境不是 PR:GitHub Actions 事故 ~17:59Z 复发(runner 领取停摆,全仓 17:54 后创建的 run 无一启动),#6079 的门禁 job 排队未被领取。平台恢复、本 PR 的 ESLint job(含新步骤自证)结论 success 后,由 PM 转 ready + 入队。

---

Generated by Claude Code