[finding][drivers] `checkDateBucketParity` 的每个调用点都写 `driver as never`，把 `BucketableDriver` 替身的编译期一致性整个抹掉 —— 且实测该 cast 并不必要

[os-zhuang]

在 #6212 批 A+E（PR 见下）实施期间实测发现，记录备查。观察类，不挂 pm:queue，请分诊轮定级。

现状

@objectstack/verify 导出 checkDateBucketParity(driver: BucketableDriver, opts?)，BucketableDriver 是它对被测驱动的结构替身（packages/verify/src/date-bucket-parity.ts）。全仓每一个调用点都把驱动 cast 成 never 再传进去：

调用点	写法
packages/qa/dogfood/test/date-bucket-parity-conformance.test.ts:49	checkDateBucketParity(make() as never, { … })
packages/drivers/driver-turso/src/date-bucket-parity.test.ts:43	checkDateBucketParity(driver as never, { … })
packages/drivers/driver-turso/src/date-bucket-parity.test.ts:128	checkDateBucketParity(driver as never, { … })

as never 之后，「这个驱动确实具备替身声明的那组方法」这件事一次也没有被检查过。替身存在的意义正是表达这组一致性，而 100% 的调用点把它关掉了——这与 #6212 正文记的是同一族事实（一个声明了却没人读的形状），只是发生在调用点而不是声明点，与 #6210 在 dogfood 踩的 DriverLike 同盲区。

实测：这个 cast 并不必要

在 date-bucket-parity-conformance.test.ts:49 把 as never 去掉后：

> @objectstack/dogfood@0.0.40-rc.4 typecheck
> tsc --noEmit
（无输出，退出码 0）

SqlDriver 与 SqliteWasmDriver 结构上本来就满足 BucketableDriver。注意这是在 #6212 批 A+E 已经把 BucketableDriver.aggregate 从 query: unknown 收窄为 DriverQuery 之后测的——收窄前只会更宽松，所以这是一处先于本次改动就已存在的死 cast。turso 的两处未单独实测（未改动该包），但它继承自 SqlDriver，预期同理，实施时需各自复核。

不是缺陷，别当缺陷派

运行期行为完全正确：checkDateBucketParity 照常跑，date-bucket 一致性照常被验证（dogfood 520 tests 全绿）。丢掉的只是编译期的一致性检查——今天没有人踩。所以判级请按观察类走。

代价是休眠的：哪天某个驱动少掉替身要求的一个方法，或者替身自身长出新成员，三个调用点一个都不会红，checkDateBucketParity 会在运行期抛 driver.aggregate is not a function 之类，而不是在 tsc 里被拦下。

如果要做

逐处去掉 as never 并各自复核 typecheck（dogfood 已实测可去；turso 两处待测）。若某处去掉后真的报错，那个报错本身才是有价值的产出——它会指出替身与真实驱动之间一处此前无人知晓的形状分歧，届时应先判断该改替身还是该改驱动，而不是把 cast 加回去。

⚠️ 同族但不在本单内、需要分别判断的：checkReadCoercion 的 CoercibleDriver 是否也有同样的调用点 cast（未实测）。

会话：session_01WyvqvKMG6asi9aXjKE6xtx（#6212 批 A+E 实施期间发现，未认领）

[os-zhuang]

发现来源：#6212 批 A+E 的 PR #6355（该 PR 不修本单，只在「顺带发现」一节引用）。

---

Generated by Claude Code

[os-zhuang]

认领本单开始实施。

• session ID: session_01WyvqvKMG6asi9aXjKE6xtx
• 分支: claude/issue-6354-date-bucket-parity-as-never

认领前已重读本单全部评论，除立单人的「发现来源」说明外无其他 session 的认领记录。

计划：从已包含 PR #6355（BucketableDriver.aggregate 收窄）的 origin/main 开分支，逐处独立复核三个调用点去掉 cast 后的 typecheck 结果；turso 两处不沿用 dogfood 结论。顺带实测 checkReadCoercion / CoercibleDriver 是否同形。

---

Generated by Claude Code

[os-zhuang]

✅ ACCEPT — PR #6396

本单立单时的计数被自己的实施证伪了，而且证伪的方向是对的那一边。接受。

计数 3 → 10，且漏掉的那 5 处恰恰最该被检查

我立单时的表列了 3 个调用点，实测全仓是 10 —— 那张表只覆盖了「传真实驱动」的几处，漏掉同一文件里 5 个传假驱动（负向控制）的调用点，以及 checkReadCoercion 的 2 处。

PR 指出的这一点比补上计数更有价值：

负向控制那几个假驱动恰恰是最需要被替身检查的对象 —— 它们是手写字面量，最容易与替身失配，而 as never 把它们全部放行了。

真实驱动是从生产代码来的，本来就大概率满足替身；手写的假驱动才是会悄悄漂移的那一类。我立单时按「哪几处传的是真驱动」去数，正好把风险最高的一组数漏了。表已作废，以 10 为准。

新鲜度证据：这是我要的那个形状，而且它多证明了一件事

我在派工单里要求「给出确实读到了新 d.ts 的证据，不能只贴一个绿」。PR 的做法是先预判方向、再执行：往两个替身各加一行 __freshnessProbe(): void;（真实驱动不可能有的成员），重新 build @objectstack/verify，再 typecheck 两个消费方 —— dogfood 8 处 + turso 2 处 = 10，与删掉的 cast 数一一对应，探针已还原且 dist 中命中数回到 0。

这个读数同时证明了两件事，第二件是我没要求的：

1. 消费方读到的确实是刚 build 出来的新 d.ts（不是 §9 那种假绿）；
2. 每一个调用点现在都真的在受检 —— 不是「没报错」，是「检查活着且会咬人」。

用「一一对应」这个等式把两件事一起坐实，比分别断言两次更强。

「没拿到那个产出」如实说了

我在派工单里写过「若某处去掉后真的报错，那个报错就是本单最有价值的产出」。PR 明说没有拿到 —— 10 个 cast 全是死的，替身与三个真实驱动及 5 个手写假驱动的形状本来就一致。

并且给了 #6355 的收窄为什么不改变结论的类型系统层面的理由，而不是「测了就是绿」：接口里以方法简写语法声明的成员，参数按双变比较，所以把 aggregate 的 query 参数从 unknown 收窄，不会让一个原本满足替身的驱动变得不满足。这与 #6355 自己注释里写的是同一件事 —— 两处独立得出同一结论。

turso 两处也确认是独立 typecheck（driver-turso 是自己的 tsc program），没有沿用 dogfood 的结论。checkReadCoercion 按授权并入，判定依据给了（CoercibleDriver 就是 BucketableDriver 去掉 aggregate 和 supports，2 处同样在探针实验里变红），改动 2 行。

最该表扬的一句：拒绝声称一个自己没有的护栏

我在派工单里预判「删 cast 会让 erasure 测试面下降而变红」。实测没有下降，267 未动，原因是该棘轮的词汇表只匹配 query/options 参数上的 as any（及洗白链），不含 as never，三个改动文件也都不在它的 baseline 里。PR 报完这个事实之后加了一句：

不应把它说成本次改动的回归护栏 —— 事实是：目前没有任何门禁会阻止有人把 as never 加回去。

一个 dev 在门禁碰巧是绿的时候，主动说明「这个绿不构成保护」，正是本会话反复在防的那类假证据（#5018 / #4984 的死 pin、PINS_CHECKED 的幽灵检查）的反面。这条我另立单记了 —— 见下。

一处后续（我另立，不占本 PR）

本 PR 一次性清掉 10 个死 cast，但清理本身没有护栏：同样的东西明天可以原样加回来，任何门禁都不会响。已按这条实测另立单 #6398。

PR 顺带发现的 #6394（同文件 68 行 { bypassTenantAudit: true } as never，也是死 cast，但属 driver.create 的 options 门而非替身调用点）按 PD #10 另立、未扩大 diff，处置正确。

---

Generated by Claude Code

[os-zhuang]

更正上一条 ACCEPT 末尾的单号：「没有门禁阻止 as never 被加回来」那张单是 #6399，不是 #6398（我在建单前就把号写进了评论）。

---

Generated by Claude Code