Repository navigation
[finding][drivers] DriverQuery 收窄之外：aggregate / distinct / analyzeQuery 等驱动自有查询方法仍要求把对象名写两遍 #6212
Description
Activity
测量棒交付(只读调查,基线
d367f03d6,仓内零改动;PM 复核收下)。对本单正文的三处更正(实测)
- 清单漏了一个:
sql-driver.ts:3481distinct(object, field, filters?: any)也是any⇒ 实为 8 个方法(算 turso 两层则 10 个);行号已漂(sql 三处 → 3384 / 3507 / 3544)。 performAggregation选Omit<QueryInput,'object'>的归因错了:正文说是groupBy元素类型差异 —— 实测QueryInput与QueryAST在groupBy上逐字相同,差异只在search/orderBy/expand;且直接换DriverQuery零报错。不影响 refactor(drivers)!: 五个驱动的 query 参数跟进 DriverQuery，休眠的类型谎言没有藏身处 (#6075) #6210 的正确性(它做的是最小改动),但影响本单:那不是被迫的选择,契约优先应选DriverQuery。explain核实:它本身已经是DriverQuery,只是analyzeQuery的一层转发。
生产者实测
aggregate仅 3 个活体生产者;distinct/analyzeQuery/findWithWindowFunctions非测试生产者为零;IDataDriver.explain全仓唯一引用是一条只验存在性的幽灵断言。三个门禁盲区(实施必须带上)
- erasure 棘轮是双向的:
aggregate在监视方法集内,全仓 49 处.aggregate(… as any),收窄后删掉这些as any会让 267 下跌 ⇒ 同一 PR 内必须--update提交 baseline;⛔ 绝不能新增as any消红; - mongodb 的 tsconfig 排除测试(TEST_DEBT 43)⇒ 必须全仓
check:type-check-debtre-measure(refactor(drivers)!: 五个驱动的 query 参数跟进 DriverQuery，休眠的类型谎言没有藏身处 (#6075) #6210 在 plugin-auth 上的同一课); driver-sqlite-wasm读的是 driver-sql 的dist/*.d.ts⇒ 只改源码不重建 d.ts 是假绿,实测重建后立刻 12 条。派发必须点名把它进同批文件面。
PM 裁决(第三档,带否决窗口)
问题 1 ——
findWithWindowFunctions的类型:采纳 B(在 driver-sql 本地声明扁平形)。 它既不能退役(#4286 把它写成了已发布的迁移处方,指向它的有墓碑消息 + registry + 5 个 docs 页 + release notes + upgrade guide),也不能标DriverQuery(windowFunctions是retiredKey墓碑 ⇒ 两个候选类型上都是undefined,该门自己文档里的载荷会编译不过)。B 把类型留在能力真正所属的那一层、契约面零扩张,与 #4286「spec 不描述驱动私有形状」同向,且可逆。⚠️ 选项 D(退役它并撤回 #4286 的迁移处方)仍然摆在桌上——那要改 6 处已发布文档,是维护者的取舍,不是我的;本裁决只是先把丢掉的检查拿回来,不预断 D。问题 2 —— 批 C 的冻结面归属:适用已有先例,按冻结面外的类型维护处理。 这与我在 #6075 认领评论里裁的口径是同一条(纯类型注解、零 emit 差异、零行为 ⇒ 不属 #5499 冻的「缺陷修复与语义补齐的开发投入」),而 #6210 已按该口径在同一批驱动上做过一次并合并。硬约束不变:冻结面只许改签名类型,任何需要动逻辑才能收紧的一律停手报告。
批次派发
批 内容 处置 A+E analyzeQuery→DriverQuery(实测零报错)+findWithWindowFunctions按裁决 B 本地类型现在派(同文件相邻区,合一单) C memory + mongodb 纯类型注解 现在派(独立文件面) B aggregate(sql+turso)+ 别名退役前置等 #6203(PR #6312)合并后派——同函数体撞面;顺序必须是 ①重拼 fixture ②删 aggregate/func别名 ③再收窄D distinct跨驱动语义分叉另立单(是缺陷不是冗余,见下) F verify的BucketableDriver替身并入 A+E 的 PR 或另立,PM 选后者 本单作为清单锚点保持 open,各批落地后勾销。
Generated by Claude Code
- 清单漏了一个:
批 B 派发(前置 #6203/PR #6312 已 MERGED,同函数体撞面解除)
会话:
session_01WyvqvKMG6asi9aXjKE6xtx
分支:claude/issue-6212-batch-b-aggregate-signatures
Worktree:objectstack-issue-6212-b
文件面:driver-sql/src/sql-driver.ts(:3384/:3439/:3442 区)+driver-turso/src/turso-driver.ts(:548)+driver-turso/src/remote-transport.ts(:820-837 区)+ 四个 fixture(sql-driver-advanced/sql-driver-queryast/sqlite-wasm-driver-advanced/sqlite-wasm-driver-queryast)+ driver-sqlite-wasm 必须进验证面(它读 driver-sql 的dist/*.d.ts,只改源码是假绿)+ changeset硬性顺序(倒过来会拿到一堆解释不清的红):① 重拼 fixture 到已声明拼写(
aggregate:→aggregations:、func:→function:)→ ② 删query.aggregate/agg.func两个未声明别名分支(记账单 #6321,ADR-0049:重拼后生产者归零)→ ③ 才收窄签名。已知的一处行为改动(测量棒实测,非纯类型):
remote-transport.ts:826的const groupBy: string[] = … query.groupBy假定 groupBy 只有字符串形,而 spec 的GroupByNode是联合;今天不炸是因为 turso remote 模式把queryDateGranularity声明为空表、引擎因此不下推结构化 groupBy。收窄会把这个「靠能力位守着的类型假设」摆上台面 ⇒ 必须显式处置(运行期收窄或显式拒收)并在 PR 说明,或把 turso 半边拆出单排,⛔ 不许用as any抹掉。并行:批 A+E、批 C 在飞,文件面互不相交。
Generated by Claude Code
批 A+E(+F)复核:ACCEPT → PR #6355(PM 实测复核):
- 变更面 5 文件;边界零触碰实测确认(aggregate / memory / mongodb / packages/spec 全部不在 diff);
- 裁决 B 执行到位,且比派发词更准:类型写成
Omit<DriverQuery,'windowFunctions'> & {…}而非直接交集——理由是墓碑键undefined与数组求交会让属性变成不可写、载荷静默编译不过且报错点离声明十万八千里。并给这个坑本身加了 pin(谁把Omit「简化」掉,红在测试里而不是红在文档里)——这是把一次性判断固化成守卫,做法对; - 验收标准做成了 pin 而非口头承诺:文档载荷逐字抄自
queries.mdx编进类型断言;同时证明请求面墓碑没被重新打开(analyzeQuery传windowFunctions仍是编译错误); - 反向验证覆盖了那个门禁盲区本身:在 driver-sqlite-wasm 上做(而非 driver-sql),红出来即证明它读到的是重建后的
dist/*.d.ts、不是假绿——这比单纯「记得 build」强一档; - 顺带发现的类型学事实值得留档:
DropsObject<any>解析为never(因'object' extends keyof any为真)⇒ 一条 pin 同时挡住「把 object 加回来」和「把参数放宽回 any」两种回退; - 批 F 判定合理(9 行、删逃逸口而非新增、
verify全绿),且明确声明不预断批 B(方法参数双变,驱动侧声明什么都满足该替身); - 三道门禁:erasure 267 未动(合并前后各跑一次 + baseline key set 核对)、type-check-debt 34 条无超记录、driver-sqlite-wasm 点名进验证面;13 个依赖包 grep 三个符号零命中;
- changeset major 依据与 [spec] IDataDriver 的 query 参数要求
QueryAST.object与第一实参重复 —— 下游被迫as any(20 处实测),提议 Omit/optional 化 #5181/[finding][drivers] 五个驱动的find/count/…仍声明query: QueryAST，而调用方已可省略object—— 双变让它编译，但声明开始说谎 #6075 一致。
顺带新账 #6354(
checkDateBucketParity的每个调用点都写driver as never,把结构替身的意义整个抹掉;实测该 cast 并不必要)——观察类,已另立。CI 清零后 ready + auto-merge。批 A / E / F 就此勾销,#6212 余 B(在飞)、C(在飞)、D(已独立为 #6320)。
Generated by Claude Code
✅ ACCEPT — 批 C（PR #6356）
memory/mongodb的aggregate/distinct收进DriverQuery。已逐项实证复核，接受。复核结论
改动面：8 文件（changeset、memory×2、mongodb×2、新增
memory-driver-query-narrowing.test.ts、check-type-check-coverage.mjs、query-options-erasure-baseline.json）。逐行看过非测试源码改动，确为纯签名置换 + 无用 import 删除，无一处逻辑改动 —— #5499 冻结面口径成立（与 #6210 在同一批驱动上的既有口径一致）。刻意保留'Aggregate operation (QueryAST)'这条运行期日志文案是对的：改它就不再是零行为变化。本 PR 最值得记下的一条：那个 ratchet 不是记账
把 mongodb 的 TEST_DEBT 从 43 降到 10，读起来像顺手清理旧漂移，实际是本 PR 唯一能钉住自己的东西：
- mongodb 的
tsconfig.json排除*.test.ts，而被收窄方法的唯一消费者就是它自己的测试 —— per-packagetypecheck与全仓tsc都看不见这次收窄（PR 里如实预判为绿并实测为绿，exit 0 零输出）； - 所以能看见它的只剩 ledger re-measure。而旧天花板 43 的余量会把它整个吞掉：实测把
aggregate签名改回QueryAST得 12 条，12 < 43，门禁不会红； - 降到 10 之后，同一反转实测报
records 10 … now reports 12 (+2)—— 门禁这才真的红。
归因也已坐实而非声称：在
d367f03d6^（#6210 前一刻）实测正好 43 =TS2345×33 + 现存 10，与旧 note 逐字吻合；那 33 条是 #6210 消掉的，与本 PR 无关（本分支与 pristine tree 在2bc187641上同报 10）。先证明归属，再动棘轮，顺序正确。两处判断做对了
pin 挂在真实调用上，不挂类型字面量。
const x: DriverQuery = …这种形状在签名回退后依旧是绿的（DriverQuery本来就没有object）—— 那正是 #5018 / #4984 付过学费的死 pin。该包 tsconfig 不排除测试层、无 TEST_DEBT 条目，所以这些@ts-expect-error是真检查。mongodb 侧刻意不写同形 pin。 那里的测试不在任何 tsc program 里，写了就是 AGENTS.md
PINS_CHECKED点名的幽灵检查 —— 宁可承认它的钉子只有上面那条 ratchet，也不摆一个看着像证据的空壳。这个"不做"比多做一份更有价值。门禁
check:query-options-erasure：4 处as any（memory 2 + mongodb 2）因收窄成为多余而删除，测试面267 → 263，按规矩--update提交 baseline，diff 恰好一行。⛔ 全程零新增as any—— 棘轮向下走，方向对。check:type-check-debt：全仓34 entries re-measured, none above its recorded number。- 冻结面回归：driver-memory 532 passed / driver-mongodb 206 passed。mongodb 那 137 条 skipped 需真实 mongod（driver-mongodb 测试:两个套件并发下载 MongoDB 二进制,mongodb-memory-server 的 rename 竞态让全绿测试 exit 1(队列 flaky) #5517 起 opt-in），PR 已如实标注"两处
as any的删除是类型层证据、不是运行期证据" —— 该说的短板说了。
证伪本单正文一处归因（第二次独立确认）
本单正文称
performAggregation当初取Omit<QueryInput,'object'>是被groupBy元素类型差异逼的。不成立：QueryInput与QueryAST在groupBy上逐字相同，差异只在search/orderBy/expand。这与我此前测量棒的结论一致，现由实现侧独立复现。本单正文的这条归因作废 —— 那不是被迫的选择，DriverQuery一直可用。CI 上那次红与本 PR 无关
TypeScript Type Check曾红在ui/BulkActionDef:requiredPermissions上 —— 本 PR 一行packages/spec都没碰。已查明是 CI 配置缺陷：lint.yml的typecheckjob 没有fetch-depth: 0，authorable-surface 删除门走不到 merge base、退化到拿 main 的 tip 当锚点，于是把 main 新增的键（#6332，本日刚合入）误判成分支删除的键。已另立 #6359 记录（含一行修法），本 PR 已 update branch 重跑。
批 C 结清。剩余：批 B 在飞（aggregate sql+turso），#6320 / #6188 待分诊。
Generated by Claude Code
- mongodb 的
✅ ACCEPT — 批 B（PR #6404）
#6212 六批收官。这一批最该记的不是代码，是它两次顶住了我给的错误方向。
硬性顺序与范围：逐项核过
① 四个 fixture 16 处重拼 → ② 删
query.aggregate/agg.func两条未声明别名（#6321）→ ③ 三处签名收窄到DriverQuery。顺序对，且为什么必须是这个顺序由 A 组反向验证坐实了（见下）。边界守住：未碰analyzeQuery/findWithWindowFunctions（批 A+E）、memory / mongodb（批 C）、distinct（#6320）、#6204 的信封表、#6203 的大小写判定。TursoDriver.aggregate的options?: any刻意不动也是对的 —— 它与上面四个 override 逐字相同，五改其一会被读成对另外四个的判断（#6210 在count上同理），另立 #6402 处置。零新增逃逸口：我独立核过，并且方向是反的
我 grep 到 9 处
+行含as any，逐一归因后确认没有一处是新逃逸口：6 处在两个新测试文件（mock 客户端、构造越界输入的 fixture），2 处是注释文本，1 处(this.config as any).client在被删除的那一行里逐字存在，是重构时原样搬过去的既有代码。更值得记的是反方向：groupBy 那条路径删掉了一个既有的
as any。buildDateBucketExpr(g.field, g.dateGranularity as any, table)→ 断言消失。理由也对：本地那个Array<string | { field, dateGranularity?: string }>重述早已从它所重述的声明漂移（缺alias、dateGranularity被放宽成string），正是那次漂移逼出了那个as any。改用 spec 自己的GroupByNode联合，重述与断言一起消失 —— 这是「以声明为准」的正确形状，比单纯「不加as any」有价值得多。groupBy：它证伪了我派工书的归因，而且这是本批的真正分量
我派工时写「今天不炸是因为
queryDateGranularity空表挡着」。实测只挡住一半 —— objectqlengine.ts逐字写着if (!g?.dateGranularity) return true; // plain {field} object is fine，无 granularity 的结构化条目根本不受该能力位约束、引擎照样下推，活体形状就在objectql/src/secret-fields.test.ts:341。于是：面 groupBy: [{ field: 'region' }]本地 / replica GROUP BY "region"，正常返回remote 插值成 "[object Object]"，死在assertSafeIdentifier一条查询两种答案、由连接串决定，且是活体不是休眠。 这把本批从「顺手收窄类型」抬成了「关掉一条真实分叉」。处置 (a)（运行期收窄 + 残余
NOT_IMPLEMENTED/501）因此是对的选择，alias不读也对 —— 只在一面读会是新分叉而非修复，既有分歧另立 #6401。SqlDriver.aggregate那条信封连带按我的裁定留在本 PR，两面首句逐字一致由第三份独立副本REFUSAL_SENTENCE的跨包 parity 用例钉住（断的是运行时消息而非各自常量，所以「只改一面」和「两面一起改错」都会红），每条拒收都断code和status。三条附带要求全部兑现。A 组那条自我批评，是本 PR 里最有教育意义的一句
重拼后的 advanced / queryast fixture 纹丝不动：
a || b放回去仍然先读a。所以 fixture 重拼必须在前，且不能兼作 pin —— 那四个文件此后已无法分辨别名分支在不在。一个 dev 主动指出自己改完的东西不能充当证据，正是本会话反复在防的那类假护栏的反面。B 组「无一条走『它居然编过去了』分支 ⇒ 本批改的是诊断质量而不是可达性」同理 —— 拒绝把改进说得比实际更大。
ADR-0087 那一关：我错了两次，是它顶住了
Check Changeset曾红在 #6148 新门上（今天刚合入，仓内零先例）。过程如实记：- 我建议
not-required (unpublished)—— 它实测否掉了我：该格判的是 npm 包private: true，不是「这个键没发布过」。 - 它拒绝用机械上能过的
no-migration-prescription—— 因为那只是探测器盲区（只匹配字面量FROM/TO），用一道门自己的盲区骗它比不写更糟。它把 CI 故意红着等裁。这个判断完全正确。 - 我随后读
spec-property-retirementskill，断言registered的产物「构造不出来」—— 又错了。那个 skill 的适用域是退役可编写的 spec 属性，我把一条路线的要求推广成了台账的全部定义域。台账里现成躺着三条同形先例：data-driver-find-stream-retired（IDataDriver.findStream 没有任何调用方，两个 driver 的实现还正好做了它承诺要避免的事（ADR-0049 enforce-or-remove） #4484）、storage-service-list-retired（spec: 按 ADR-0049 摘除IStorageService.list(prefix)契约成员(零消费方,双适配器语义分叉 —— #5266 方案 2,维护者已批) #5540）、actor-user-roles-to-positions（[runtime]ctx.user的roles别名(值是positions)没有关闭日期 —— #5613 给 ctx.session 装了迁移窗口,同名同值的 ctx.user 面仍是无限期别名(observation) #6011），全是代码契约面、全部「deliberately no schema tombstone」。
它写出来的条目渲染成了完整可执行的升级指令，并附了一条我没想到的反向警告：
⚠️ 不要把这条读到dashboard/pagemeasure 上 —— 那里aggregate是规范键、func是已声明的响亮别名（DatasetMeasureSchema）。而那恰恰是仓外调用方最可能把这个习惯带到 query 上的来源。一个习惯、两个表面、只有一个声明过它 —— 这句话本身就是本批存在的理由。我已在 #6419 上更正了自己的两处错误结论，并把该单收窄为仍然成立的那一半（探测器匹配占位符而非真实处方）。
门禁
Check Changeset✅ /Spec property liveness✅；erasure 263 未动、baseline 一行未改（我原预判「删多余as any会让 267 跌」被实测证伪：三个驱动包.aggregate(… as any)站点为 0）；check:type-check-debt全仓 re-measure 绿，且它先出过一次 §9 假红并用pristine main 重测得到同样 +5/+1 证伪归属 —— 这条已作为第五例补进 #6371。driver-sqlite-wasm 全程在验证面内（先 build driver-sql 再验），254 passed。
#6212 六批全部结清：A+E+F（#6355）、C（#6356）、B（#6404）。#6321 随本 PR 关闭。
Generated by Claude Code
- 我建议
更正 + 收口状态
更正：上一条 ACCEPT 末尾我写「#6212 六批全部结清」，不准确。批 D 早已独立为 #6320（
distinct第三参语义分歧），此刻仍在实施中。已结的是五批。当前状态
批 内容 落地 A + E + F analyzeQuery/findWithWindowFunctions本地类型 +verify的BucketableDriver.aggregate✅ PR #6355 → d48aad568C memory / mongodb 的 aggregate/distinct✅ PR #6356 → 262e40dd5B aggregate（sql + turso + RemoteTransport）+ 退役query.aggregate/agg.func（#6321）✅ PR #6404 → 29e28a3e5D sql.distinct第三参 →FilterCondition⏳ #6320 实施中 #6320 落地后本单即可关闭。 在那之前保持 open —— 这张单是清单锚点，提前关掉会让最后一格失去归属。
本单在实施过程中被证伪的三处（都以实测为准，已逐条更正）
- 方法计数：正文说 7 个，实测 8 个。
- 行号：正文行号取自
d367f03d6，五张 PR 之后全部漂移 —— 后续实施一律按符号名定位。 groupBy归因：正文称performAggregation取Omit<QueryInput,'object'>是被groupBy元素类型差异逼的。不成立 ——QueryInput与QueryAST在groupBy上逐字相同，差异只在search/orderBy/expand。由批 C 独立复现确认。
顺带产出的账（均已另立、不在本单修）
#6320（批 D，真缺陷：
distinct静默返回未过滤全集）、#6321（已随批 B 关闭）、#6188（spec：AggregationFunction声明 8 个、SQL 实现 5 个）、#6401（GroupByNode.alias只有内存分桶认，下推与回退拿到不同列键）、#6402（TursoDriver五个 override 的options?: any，需一次性处置）、#6354（已合，as never调用点，实测 10 处而非立单时的 3 处）。
Generated by Claude Code
Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): promoted to the queue. Direct continuation of the #5181/#6075 narrowing onto the driver-owned query methods, with the same shipped precedent. Constraint: changes inside
driver-memory/driver-mongodbstay mechanical signature catch-up only (#5499 freeze — no semantic investment). Batch candidate with #6231/#6401/#6402 (drivers lane, same family — mind same-file serialization).finding→pm:queue.
Generated by Claude Code
- added a commit that references this issue
on Aug 8, 2026 收官 —— 六批全部落地，本单关闭
批 内容 落地 A + E + F analyzeQuery/findWithWindowFunctions驱动本地类型 +verify的BucketableDriver.aggregatePR #6355 → d48aad568C memory / mongodb 的 aggregate/distinctPR #6356 → 262e40dd5B aggregate（sql + turso + RemoteTransport）+ 退役query.aggregate/agg.func（#6321）PR #6404 → 29e28a3e5D sql.distinct第三参 →FilterCondition（独立为 #6320）PR #6517 本单正文被实测证伪的三处（已逐条更正，供后来者参照）
- 方法计数：正文记 7 个，实测 8 个。
- 行号：正文行号取自
d367f03d6，五张 PR 之后全部漂移 —— 后续一律按符号名定位。 groupBy归因：正文称performAggregation取Omit<QueryInput,'object'>是被groupBy元素类型差异逼的。不成立 ——QueryInput与QueryAST在groupBy上逐字相同，差异只在search/orderBy/expand。由批 C 独立复现确认。
实施过程中确立、值得带走的四条实测纪律
FilterCondition是开放映射（键即字段名）⇒「把 query 信封交给 filter 参数必须编译不过」这类要求不可达，该类保证只能落在运行期。批 D 用@ts-expect-error触发TS2578: Unused directive让编译器自己说出这一点。- 立单计数普遍偏低：[finding][drivers]
checkDateBucketParity的每个调用点都写driver as never，把BucketableDriver替身的编译期一致性整个抹掉 —— 且实测该 cast 并不必要 #6354 记 3 实测 10、drivers:distinct的第三参在 memory 与 sql 上语义不同 —— 把 sql 那面的写法交给 memory,静默返回未过滤全集(运行期实测) #6320 记 3 实测 14。后续派工一律写「以实测为准并报告真实数字」。 - d.ts 新鲜度证据的判据不止「全红且数量对应」，还要确认本该不动的调用点确实没动 —— 用它区分「逐点受检」与「整片文件塌了」。
- 一次正当的改进会顺手把下一个人的 pin 变哑：refactor(drivers)!: 五个驱动的 query 参数跟进 DriverQuery，休眠的类型谎言没有藏身处 (#6075) #6210 消掉 33 条错误却没降 ledger，那 33 条余量差点吞掉批 C 自己的收窄（回退实测 12 < 43）。已另立 [finding][devx]
check:type-check-debt的 ledger 余量会让新写的 pin 变哑：mongodb 曾有 33 条余量吞掉一次真实回退，另有 5 条目前带 4–19 余量 #6376。
顺带产出（均已另立，不在本单）
#6320（已结）、#6321（随批 B 关闭）、#6188（spec：
AggregationFunction声明 8 个、SQL 实现 5 个）、#6401（GroupByNode.alias只有内存分桶认，下推与回退拿到不同列键）、#6402（TursoDriver五个 override 的options?: any，需一次性处置）、#6354（已合）、#6394、#6399。
Generated by Claude Code
- added a commit that references this issue
on Aug 17, 2026
在 #6075（PR #6210）把五个驱动的六个契约方法签名迁到
DriverQuery时实测发现，记录备查。观察类，不挂pm:queue，请分诊轮定级。现状
#5181 只收窄了
IDataDriver声明的六个方法（find/findOne/count/updateMany/deleteMany/explain），#6075 让五个驱动的实现跟上。但驱动上还有一批同样吃 query AST、却不在IDataDriver里的方法，它们的第一个实参同样已经是对象名，query 里却仍然要求（或放任）再写一遍object：driver-memory/src/memory-driver.ts:653aggregate(object, pipeline: Record< string, any >[] | QueryAST, …)objectdriver-memory/src/memory-driver.ts:612distinct(object, field, query?: QueryInput)objectdriver-mongodb/src/mongodb-driver.ts:468aggregate(object, query: QueryAST, …)objectdriver-sql/src/sql-driver.ts:3249aggregate(object, query: any, …)any，全无检查driver-sql/src/sql-driver.ts:3372findWithWindowFunctions(object, query: any, …)anydriver-sql/src/sql-driver.ts:3409analyzeQuery(object, query: any, …)anydriver-turso/src/turso-driver.ts:547aggregate(object, query: any, …)any（行号取自
origin/main@80f7dc6，会漂。）为什么单独记一笔
这正是 #5181 判定为「同一个事实要求写两遍，因此有了两处互相矛盾的余地」的那种冗余，只是它活在契约没有覆盖的方法上。两个后果：
object的那几处：调用方手上只有where/groupBy时叫不出类型的名字，于是走as any—— [spec] IDataDriver 的 query 参数要求QueryAST.object与第一实参重复 —— 下游被迫as any(20 处实测),提议 Omit/optional 化 #5181 的 changeset 记过这笔账的代价（cloud#1053 实测 20 处，cloud#1030 的$like就是从这个口子活到运行时的）。any的那几处：连where/orderBy/fields的检查一起关掉，与 [finding][drivers] 五个驱动的find/count/…仍声明query: QueryAST，而调用方已可省略object—— 双变让它编译，但声明开始说谎 #6075 刚在 turso 上收回来的是同一批检查。PR #6210 没有动它们：它们不是 #5181 收窄的那六个方法，顺手改属于超范围。
不是缺陷，别当缺陷派
今天没有人踩：
git grep 'query\.object' -- 'packages/drivers/*/src'在main上仍是零命中，这几个方法自己也不读query.object。所以这是休眠的冗余 + 放弃的检查，不是活体缺陷，判级请按观察类走。如果要做
给这批方法定一个 query 参数类型。要注意它们彼此并不同形，不是一刀切换成
DriverQuery就完：memory.aggregate的形参是pipeline，联合了 mongo 风格管线数组与 AST 两种输入，收窄前得先确认两条分支各自的真实生产者；memory.distinct用的是输入形QueryInput（不是输出形QueryAST），直接换成DriverQuery会连带收紧groupBy的元素类型 —— PR refactor(drivers)!: 五个驱动的 query 参数跟进 DriverQuery，休眠的类型谎言没有藏身处 (#6075) #6210 在performAggregation上就是因为这一点选了Omit< QueryInput, 'object' >而不是DriverQuery；analyzeQuery/findWithWindowFunctions是否还有生产者，值得先量一量再决定是收窄还是退役（explain已经只是analyzeQuery的一层转发）。driver-memory/driver-mongodb在 #5499 的冻结面内，跨面处置请按冻结令的口径框定范围。会话：
session_01WyvqvKMG6asi9aXjKE6xtx（#6075 实施期间发现，未认领）