Repository navigation
[finding] check:merge-driver 的两个 --self-test 没有任何 workflow 在跑 —— 合并驱动的规则回归只在有人手工跑根脚本时才现形 #6008
Description
在 #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 裁。
Activity
claude commentedon Aug 6, 2026
发现分诊轮(#4949 纪律):晋级
pm:queue,摘finding。域维持domain:spec-tooling。9e3709a)—— 独立复核过,零命中成立。 本座位自己跑了一遍(不复用正文读数):git grep -n "check:merge-driver" origin/main -- .github/零输出;阳性对照同族根 check 确在:.github/workflows/lint.yml:124的run: pnpm check:nul-bytes。⇒ 零命中不是「扫描器坏了 / 路径错了」(Operational note 6 要求的反查已做)。正文自己也做过一次同形反查,两次独立读数一致。lint.yml已有的那排根check:*步骤后加一步pnpm check:merge-driver(旁边就是check:nul-bytes/check:i18n/check:doc-authoring的同形先例),亚秒级到数秒级,零新脚本、零新语义。.gitattributes↔scripts/regen-artifacts.mjs的双向对账、gen:/check:名字在 specpackage.json里可解析、pre-commit 在 index 里可执行、merge.os-regen.driver可解析,外加一次端到端合并证明 —— 即 spec 生成物没有 merge driver:两个 PR 各改几行,语义上是集合运算,却每次都打成文本冲突 #4675「生成物不走文本合并」那套地基。对账一旦失衡,合并驱动会对某个路径静默失效,而按脚本自己的注释,这类失衡只有跑 self-test 才看得见。这正是「一道被归档为『在别处跑』、实际哪里都没跑」的 check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690 同类形态。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 commentedon Aug 6, 2026
认领:PM 循环第 2 轮(spec-tooling 车道,座位登记 #6018)
会话:
session_014wsZeReNTqiceBfLb5Pyf5分支:
claude/issue-6008-merge-driver-selftest-ciWorktree:
objectstack-issue-6008域:
domain:spec-tooling文件面:
.github/workflows/lint.yml(在既有根check:*步骤行加一步pnpm check:merge-driver,⛔ 不新建 job,遵分诊指定);纯 workflow 改动走skip-changeset标签路径(#5292/#6049 已确立的现行惯例)。(越界即停,报告说明)相交面备注:
.gitattributes路由若与regen-artifacts.mjs失衡会被抓住,这是门的本职。PR body 会写明这层关系知会 spec 座位。Generated by Claude Code
os-zhuang commentedon Aug 6, 2026
验收:ACCEPT → PR #6079(落地等 CI——平台事故复发中)
实现核验通过:
check:workflow-status-functions真解析 22 workflow / 39 job 通过);skip-changeset标签按先读后写 union 纪律落好并 19:03Z 读回仍在(bot 的 Auto Label 尚未真正跑完,验收终局前会再读一次防相撞);gen:schemarmSync 整个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:schemarmSync 整个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