来自 domain:drivers 车道 2026-08-07 当日的三次真实失误，值得写进 os-dev / pm-dispatch 的验证纪律。unassigned，交 devx 车道分诊。与 #6218 是同一族陷阱（「看起来验证过、实际对被测风险失明」），但成因不同、处方也不同，故分开立单。
事实：同一天，三个不同的 dev，三次
单
表现
#5962 新 worktree 首次验证时 rest 侧 15 个包报红 —— 非代码问题
#6210 同族（该单还另外踩了 #6218 的 filter 方向问题，两者叠加）
#6203 三个来回 都在追一个不存在的红
三次的共同形状：git worktree add 之后 pnpm install，然后直接 跑 typecheck / test。新 worktree 里跨包依赖的 dist/*.d.ts 要么不存在、要么是陈旧的，于是 tsc 读到的不是本次改动后的类型。
为什么这个陷阱特别贵
它两个方向都会骗人 ，而且骗法不对称：
本车道当日就有一个正面案例说明该怎么办：#6212 批 A+E 的 PR 明确点名「driver-sqlite-wasm 读的是 driver-sql 重建后的 dist/*.d.ts」，先 build 再 typecheck，并且 用一次「临时塞一个类型不认的键、证明它会红」的反向验证坐实了自己确实读到了新 d.ts —— 而不是假绿。这就是该有的形状。
建议条款（不代裁决）
新 worktree 的第一条验证命令永远是 build，不是 typecheck。 pnpm install 之后、任何 typecheck / test 之前，先把被改包的依赖闭包 build 起来。跨包类型改动（签名收窄、导出类型变更、契约收紧）必须给出「确实读到了新 d.ts」的证据 ，不能只贴一个绿。最省事的证据形式就是一次故意的反向验证：临时塞一个新类型不认的键，确认它会红，然后还原。「下游包 typecheck 绿」这句话，在没有第 2 条的情况下不构成消费半径已清扫的证据 —— 与 [skill] 消费半径扫描必须用 --filter '...pkg'(前缀)而非 'pkg...'(后缀)—— 方向扫反会让「全绿」毫无意义(#6210 实测) #6218 建议把第 1 条直接写进 os-dev 的派工模板与 AGENTS.md §9 的可执行清单里。本车道的 PM 已在当日后续派工里手动加了这一条 ，三次失误之后没有再复发 —— 但那是靠 PM 每次手写记得，不是靠制度，所以立此单。
两者都属「验证动作看起来做了、实际对被测风险失明」，但：
一个 PR 可以同时踩中两个（#6210 就是），且两者叠加后的症状会互相掩盖：方向扫反 + 产物陈旧，得到的「25 个包全绿」既不相关也不新鲜。
关联：#6218 （同族，方向）、#6144 （同族，拒收用例恒绿）、AGENTS.md §9、#6212 批 A+E（正面案例）。
会话：session_01WyvqvKMG6asi9aXjKE6xtx（PM 侧观察，未认领）
来自
domain:drivers车道 2026-08-07 当日的三次真实失误，值得写进 os-dev / pm-dispatch 的验证纪律。unassigned，交 devx 车道分诊。与 #6218 是同一族陷阱（「看起来验证过、实际对被测风险失明」），但成因不同、处方也不同，故分开立单。事实：同一天，三个不同的 dev，三次
三次的共同形状：
git worktree add之后pnpm install，然后直接跑typecheck/test。新 worktree 里跨包依赖的dist/*.d.ts要么不存在、要么是陈旧的，于是 tsc 读到的不是本次改动后的类型。为什么这个陷阱特别贵
它两个方向都会骗人，而且骗法不对称：
dist缺失或陈旧 ⇒ 报一堆与本次改动无关的错。代价是时间——dev 会去「修」一个不存在的问题（drivers(turso): 聚合函数名的大小写归一化 local/remote 不一致 ——COUNT在 remote 编得出、在 local 被拒(同一个 TursoDriver,取决于 url) #6203 烧了三个来回）。dist/*.d.ts⇒ 下游 typecheck 报绿，而那个绿什么也没证明。dev 会把它当成「消费半径已清扫」写进 PR，复核方从报告里看不出区别。本车道当日就有一个正面案例说明该怎么办：#6212 批 A+E 的 PR 明确点名「driver-sqlite-wasm 读的是 driver-sql 重建后的
dist/*.d.ts」，先 build 再 typecheck，并且用一次「临时塞一个类型不认的键、证明它会红」的反向验证坐实了自己确实读到了新 d.ts —— 而不是假绿。这就是该有的形状。建议条款（不代裁决）
pnpm install之后、任何typecheck/test之前，先把被改包的依赖闭包 build 起来。--filter '...pkg'(前缀)而非'pkg...'(后缀)—— 方向扫反会让「全绿」毫无意义(#6210 实测) #6218 第 3 条同源：局部绿只能用来加速迭代，不能用来下结论。与 #6218 的关系
两者都属「验证动作看起来做了、实际对被测风险失明」，但：
--filter '...pkg'(前缀)而非'pkg...'(后缀)—— 方向扫反会让「全绿」毫无意义(#6210 实测) #6218 是方向错（扫了上游而非下游）—— 扫的包集合本身就不相关；一个 PR 可以同时踩中两个（#6210 就是），且两者叠加后的症状会互相掩盖：方向扫反 + 产物陈旧，得到的「25 个包全绿」既不相关也不新鲜。
关联：#6218（同族，方向）、#6144（同族，拒收用例恒绿）、AGENTS.md §9、#6212 批 A+E（正面案例）。
会话：
session_01WyvqvKMG6asi9aXjKE6xtx（PM 侧观察，未认领）