package-files-exist 门禁的 ratchet 失败消息只描述了两条陈旧路径中的一条(「the path now resolves」)

[yinlianghui]

发现于 #3665 的实施(PR 待开)。观察类记录,不在该单完成范围内(#3665 的文件面明确 ⛔ 该测试文件其余断言一行不动)。

事实

scripts/__tests__/package-files-exist.test.ts 的 ratchet 断言 the objectui#3647 baseline only shrinks,其失败消息首行写死为:

A KNOWN_MISSING entry is stale — the path now resolves, so the defect is fixed.
Delete its line from KNOWN_MISSING in this file to bank the progress.

而 stale 的判据是 !stillMissing.has(relPath),missing 又是从 declared(= 各包 files 展开)里筛出来的。所以一条基线条目变陈旧有两条路径:

1. 路径被创建 —— 条目仍在 files 里,但 fs.existsSync 为真。这是消息描述的那条,也是 PR test(scripts): 补门禁——package.json files 声明的条目必须在磁盘真实存在 (#3663) #3667 逆向验证 C 实测的那条(建出 packages/cli/templates/)。
2. 声明被删除 —— 条目从 files 里删掉,于是它根本不再进入 declared,自然也不在 stillMissing 里。

#3665 走的正是第 2 条(两个 templates 目录从未存在、也不该存在,正确修法是删声明)。实测输出:

AssertionError: A KNOWN_MISSING entry is stale — the path now resolves, so the defect is fixed.
Delete its line from KNOWN_MISSING in this file to bank the progress.

packages/cli/templates (objectui#3665)
packages/create-plugin/templates (objectui#3665)

此时 packages/cli/templates 并没有 resolve —— 它依然不存在,只是不再被声明。消息的诊断句与现场不符。

影响(为什么记为观察类)

• 补救指令仍然正确:「Delete its line from KNOWN_MISSING」在两条路径下都是该做的事,所以不会把人引向错误动作。
• 失真的只是诊断句里的归因:读者按字面去 ls 那个路径会发现它不存在,从而怀疑门禁自身坏了。
• #3665 落地后 KNOWN_MISSING 已清空,这条消息在下一条基线条目被挂账之前不会再触发 —— 所以今天没有人会撞上。

可能的处置(供分诊裁决,未实施)

把首行改成同时覆盖两条路径,例如:

A KNOWN_MISSING entry is stale — the path now exists, or the `files` entry that
declared it is gone. Either way the defect is fixed.

#3665 的 PR 里已经把这两条路径写进 KNOWN_MISSING 上方的文档注释(该注释本就是描述被删条目的,必须随之更新),但断言消息本身未动 —— 那超出该单的文件面。

---

Generated by Claude Code

[yinlianghui]

认领(PM 派发)。Session: session_01GTRjn8xBqp75dk7kFupVRt;分支 claude/issue-3674-ratchet-message-both-paths。文件面:scripts/__tests__/package-files-exist.test.ts 的棘轮失败消息(断言逻辑不动,仅消息覆盖两条陈旧路径:路径已 resolve / 声明已删除 — #3665 实测第二条时消息归因与现场不符)。前置已落:PR #3687 已在 main(dcff16e)。逆向验证:两条路径各演一遍(fixture 层建路径 / 删声明),消息各自归因正确。

---

Generated by Claude Code

[yinlianghui]

验收 ACCEPT → PR #3701(session_01GTRjn8xBqp75dk7kFupVRt)。

已核:单文件 +24/−3;F0-F3 四预测全中(F3 若返绿即证伪三路径主张 — 把自己的主张放上可证伪台面);红绿判决改前改后逐字节相同(谓词零动的机械证明);scripts 套件 339 测试绿;CI 0 失败。

裁决记录(三项记入方法库):

1. 第三条路径的发现方式:读谓词的两个过滤条件而非只信 issue 的计数 — 「消息遗漏成因」类修复先枚举谓词的全部转真路径。
2. 自查出正在修的同一错误类(第二 commit:「declaration was deleted」超出「今天无声明匹配」的可观察面)— 修归因失真的 PR 自己不得引入新的归因超断言,这是 docs(scripts): 按真实机制改写两处 Lychee 门禁描述,并删掉 judgeHref 重复注释 (#3587) (#3648) #3656 规矩在归因语句上的延伸。
3. causeOf 从谓词同一份数据推导,不另建事实来源 — 诊断与判定同源的原则(与 fix(app-shell): expand view edit-gate union failures into per-field diagnostics #3624 的「读判定那次运行自身的错误组」同宗)。
4. prettier 伪红的排除过程正确(npx 拉 stock prettier — 正是 删掉 prettier 依赖不足以消灭假红陷阱:pnpm exec 会沿 PATH 落到全局 prettier 上 #3682 护栏覆盖的形态,经 origin/main 对照确认非本改动引入)。
5. 三路径不另立单的判断正确(同一主张的计数更正,非独立缺陷)。

---

Generated by Claude Code