来自 PR #6210(#6075 实施)的真实失误,值得写进 os-dev / pm-dispatch 的验证纪律。unassigned,交 devx 车道分诊。
事实
#6210 收窄五个驱动的方法签名(源码级破坏性变更),按纪律做了「消费半径清扫」,用的是:
pnpm --filter '@objectstack/driver-sql...' ... typecheck # → 报告 25 个包全绿
CI 全仓 typecheck 随即红在 @objectstack/dogfood#typecheck(120 个任务里 118 绿)。
根因:pnpm 的省略号有方向——
| 写法 |
含义 |
'pkg...'(后缀) |
该包 + 它依赖的包(上游闭包) |
'...pkg'(前缀) |
该包 + 依赖它的包(下游消费者) |
签名收窄、导出类型变更、契约收紧这一类改动打到的永远是下游,而后缀写法扫的是上游——于是「25 个包全绿」这句话在方法论上与被测风险完全无关,却读起来像一次充分的清扫。
建议条款(不代裁决)
- 「消费半径清扫」的规范命令是
--filter '...<pkg>'(前缀),或直接全仓 pnpm typecheck / pnpm test;
- 报告里出现「N 个包全绿」时,必须同时写出用的哪个方向,否则复核方无法判断这句话的含义;
- 破坏性/契约收紧类改动,以全仓门禁为准,局部闭包只能用来加速迭代、不能用来下结论。
关联:#6210 / #6075(出处)、#6144(同类:拒收用例必须断言 code+status,否则在目标驱动上恒绿)——两者是同一族「看起来验证过、实际对被测风险失明」的陷阱。
来自 PR #6210(#6075 实施)的真实失误,值得写进 os-dev / pm-dispatch 的验证纪律。unassigned,交 devx 车道分诊。
事实
#6210 收窄五个驱动的方法签名(源码级破坏性变更),按纪律做了「消费半径清扫」,用的是:
CI 全仓 typecheck 随即红在
@objectstack/dogfood#typecheck(120 个任务里 118 绿)。根因:pnpm 的省略号有方向——
'pkg...'(后缀)'...pkg'(前缀)签名收窄、导出类型变更、契约收紧这一类改动打到的永远是下游,而后缀写法扫的是上游——于是「25 个包全绿」这句话在方法论上与被测风险完全无关,却读起来像一次充分的清扫。
建议条款(不代裁决)
--filter '...<pkg>'(前缀),或直接全仓pnpm typecheck/pnpm test;关联:#6210 / #6075(出处)、#6144(同类:拒收用例必须断言 code+status,否则在目标驱动上恒绿)——两者是同一族「看起来验证过、实际对被测风险失明」的陷阱。