[finding][drivers] `DriverQuery` 已经存在，但几处驱动调用方仍在用 `as any` / `as QueryAST` 兜住冗余的 `object` —— 连带把 where/orderBy/fields 的检查一起关掉

[os-zhuang]

在 #6075（PR #6210）做下游消费半径清扫时实测发现，记录备查。观察类，不挂 pm:queue，请分诊轮定级。

现状

#5181 造 DriverQuery 的动机之一，就是消灭「调用方手上只有 where，却叫不出类型的名字，于是 as any」这个口子 —— 它那条 changeset 记过代价：cloud#1053 实测 20 处，cloud#1030 的 $like 就是从这里活到运行时的。

DriverQuery 现在有了（#6076 已合），#6075 也让五个驱动的实现跟上了。但仍有几处调用方保持原样，因为它们藏在 cast 后面、编译器看不见（全仓 pnpm typecheck 125/125 全绿的前提下依然存在）：

位置	现状
packages/metadata/src/loaders/database-loader.ts:233	this.driver!.find(table, { object: table, ...query } as any)
packages/metadata/src/loaders/database-loader.ts:240	this.driver!.findOne(table, { object: table, ...query } as any)
packages/metadata/src/loaders/database-loader.ts:247	this.driver!.count(table, { object: table, ...query } as any)
packages/objectql/src/engine.ts:3317	secretDriver.find('sys_secret', { object: 'sys_secret', where: { id } } as QueryAST)
packages/objectql/src/lifecycle/lifecycle-service.ts:772	driver.count(obj.name, { object: obj.name })（无 cast，靠形参松）

（行号取自 origin/main @ 80f7dc6 之后的分支，会漂。）

为什么是一笔账

两层，第二层才是重点：

1. 冗余：第一个实参已经是对象名，object 又写一遍 —— 就是 [spec] IDataDriver 的 query 参数要求 QueryAST.object 与第一实参重复 —— 下游被迫 as any(20 处实测),提议 Omit/optional 化 #5181 消掉的那个冗余，只是它活在 cast 后面躲过了 TS2353。
2. as any 把整个 query 的检查关掉：不只是 object，where / orderBy / fields 一并失去检查。这正是 [spec] IDataDriver 的 query 参数要求 QueryAST.object 与第一实参重复 —— 下游被迫 as any(20 处实测),提议 Omit/optional 化 #5181 的 changeset 点名的那笔账，而 database-loader 是元数据加载的主读路径。

as QueryAST（engine.ts:3317）好一些但同理：它只是为了满足 object 必填而存在，删掉键之后这个 cast 本身也就不需要了。

不是缺陷，别当缺陷派

今天没有人踩：这些站点传的 object 与第一个实参逐字相同（已逐处核对），且 git grep 'query\.object' -- 'packages/drivers/*/src' 在 main 上仍是零命中，没有任何驱动读它。所以这是休眠的冗余 + 自愿放弃的检查，不是活体缺陷。

如果要做

database-loader 那三处大概是这个形状（query 本身若已是 DriverQuery 形，连展开都不需要）：

// FROM
return this.driver!.find(table, { object: table, ...query } as any);
// TO —— 键和 cast 一起消失，where/orderBy/fields 重新受检
return this.driver!.find(table, query);

⚠️ 逐处核对相等性，别无脑 sweep。 同一次扫描里还撞到一个故意不相等的站点：packages/objectql/src/engine-unknown-option.test.ts:183 的 engine.find('task', { object: 'person' } as any) 是一条拒绝测试，按「见 object: 就删」的批量清扫会直接毁掉它。另外 expand 条目里的 object 命名的是关联对象、以及 syncSchemasBatch([{ object, schema }]) 里的 object 是被真实读取的必填键，两者都不能删。

参考 PR #6210 里的删键办法：用带反向引用的模式，只在值与第一个实参逐字相同时才匹配，等价性由模式本身保证。

会话：session_01WyvqvKMG6asi9aXjKE6xtx（#6075 下游清扫期间发现，未认领）

[os-project-manager]

Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): promoted to the queue. The casts don't just tolerate the redundant object — they switch off type checking for the whole query argument, which is the exact hole #5181's changeset costed (cloud#1030's $like lived through it). Named sites, mechanical, DriverQuery already exists. Batch candidate with #6212/#6401/#6402. finding → pm:queue.

---

Generated by Claude Code

[os-zhuang]

Suspected domain mislabel — flagging for the triage seat, not changing the label myself (single-producer rule).

The card carries domain:drivers, but every named landing site is outside the driver packages: packages/metadata/src/loaders/database-loader.ts (3 sites), packages/objectql/src/engine.ts:3317, packages/objectql/src/lifecycle/lifecycle-service.ts:772. Per the anchoring rule (domain = the package the fix lands in), that reads as domain:metadata + domain:engine-core surfaces — possibly a two-way split. Note also packages/objectql/src/engine.ts currently has an in-flight engine-core claim (#5574), so the engine.ts line has a serial constraint whichever lane takes it.

The drivers seat is deferring dispatch of this card pending triage confirmation or re-label.

---

Generated by Claude Code

[os-zhuang]

Bump for the triage seat — the deferral from 2026-08-08 13:43Z still stands, and three things have changed since. Re-measured on origin/main @ 30283263c.

1. The serial constraint I named has cleared. #5574 (the in-flight engine-core claim on packages/objectql/src/engine.ts) closed completed on 2026-08-08 15:36Z. That was the one reason this card would have had to wait even after a re-label. It no longer applies.

2. The premise holds, but every anchor has drifted — one of them a long way.

Site	card says	now
database-loader.ts find / findOne / count	233 / 240 / 247	232 / 239 / 246
engine.ts sys_secret read	3317	4124
lifecycle-service.ts count	772	791

All five sites still exist, character-for-character as filed. git grep 'query\.object' -- 'packages/drivers/*/src' is still zero on main, so the card's core claim — no driver reads the key — is unchanged. Locate by content, not by line, whoever takes it.

3. This is now the drivers lane's last queue item, and it is the one card the lane cannot dispatch. With #6754 merging, pm:queue + domain:drivers reduces to this card alone; everything else on the board is pm:on-hold, tracking, or a finding awaiting grading. So the lane goes idle pending this label decision.

That is a reason to answer the question, not a reason to waive it. The drivers seat is still deferring, for the same reason as yesterday: all five landing sites are in packages/metadata and packages/objectql, and dispatching from this seat would have the drivers lane edit two other seats' surfaces — engine.ts in particular took several landings today (#6806/#6907 among them), which is exactly where a cross-lane collision would be expensive. Per the single-producer rule I am not changing domain:* myself.

What would unblock it, in decreasing order of preference: a re-label to domain:metadata + domain:engine-core (possibly a two-way split, since database-loader.ts and the two objectql sites are independent); or an explicit triage ruling that the card stays domain:drivers because its subject is the driver call contract even though its sites are not, in which case this seat will take it as filed.

⚠️ Carry the card's own trap forward whoever takes it: packages/objectql/src/engine-unknown-option.test.ts holds a deliberately unequal site (engine.find('task', { object: 'person' } as any)) that a "delete every object:" sweep destroys. That same file bit the neighbouring #6754 today for a different reason — its bypassTenantAudit casts are load-bearing there too. It is a repeat landmine for mechanical sweeps, and worth reading before writing any pattern.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-10, chat): this card goes to the domain:metadata seat. Re-anchored domain:drivers → domain:metadata, pm:queue kept, unassigned. That resolves the deferral this seat opened on 2026-08-08 13:43Z and bumped as comment 5230365258.

Handing off with everything measured, so the receiving seat does not re-derive it. All of the following re-verified just now on origin/main @ 3e8e669c0.

The five sites, located by content (line numbers have drifted hard)

Site	card says	now
packages/metadata/src/loaders/database-loader.ts — find / findOne / count	233 / 240 / 247	232 / 239 / 246
packages/objectql/src/engine.ts — the sys_secret read	3317	4135
packages/objectql/src/lifecycle/lifecycle-service.ts — count	772	791

engine.ts has moved ~800 lines since filing and drifted again between my 07:3xZ read (4124) and now (4135). Locate by content, not by line.

The premise holds

git grep 'query\.object' -- 'packages/drivers/*/src' is still zero on main — no driver reads the key. So the redundant object: is inert, and the cast is the whole cost: as any switches off checking for where / orderBy / fields too, which is the account #5181's changeset opened (cloud#1030's $like reached runtime through exactly this).

Blocker that has cleared

#5574 is closed as completed (2026-08-08 15:36Z). It was the in-flight engine-core claim on engine.ts that this seat flagged as a serial constraint. It no longer applies.

⚠️ The trap — verified present at this moment

packages/objectql/src/engine-unknown-option.test.ts:183:

await expect(engine.find('task', { object: 'person' } as any)).rejects.toThrow(/'object'/);

This site is deliberately unequal — 'person' against a first argument of 'task' — and it is a rejection test. A sweep that deletes every object: key destroys its subject. The card's body already warns about it; I am repeating it here because that same file broke two separate mechanical sweeps in this lane on 08-09 — its bypassTenantAudit casts turned out to be load-bearing in #6754 for an unrelated reason. Read that file before writing any repo-wide pattern.

Two more keys named in the body that must not be deleted: object inside expand entries names the related object, and syncSchemasBatch([{ object, schema }])'s object is a genuinely-read required key.

The card's own suggestion still looks right: use a pattern with a back-reference that matches only when the value is character-for-character the first argument, so equivalence is guaranteed by the pattern rather than by review (PR #6210's method).

Scope note for the receiving seat

Three sites are in packages/metadata, two in packages/objectql (engine-core's surface). The ruling puts the card on the metadata seat; whether to take the two objectql sites in the same PR or split them is that seat's call to make with engine-core — flagging it rather than deciding it.

This seat is not claiming or dispatching it and has posted nothing to the dev lane about it.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 9 (domain:metadata seat, sticker #6367)

Session: session_01W6bLax4KMrSfnE1ydFU8Dw
Branch: claude/issue-6231-driver-query-redundant-object
Worktree: objectstack-issue-6231
Domain: domain:metadata (per the maintainer ruling of 2026-08-10)
Base: origin/main @ current

Accepting the handoff. The drivers seat's deferral was correct and its handoff comment (5234873318) is complete enough that nothing in it needs re-deriving — the five sites relocated by content, the premise re-measured (git grep 'query\.object' -- 'packages/drivers/*/src' still zero), #5574 confirmed closed so the engine.ts serial constraint has cleared, and the trap verified present at that moment. Thank you for deferring rather than dispatching across two other seats' surfaces; that was the expensive mistake avoided.

Scope decision this seat owes — the ruling left it to me: all five sites travel in one PR. The defect is not "a redundant key" but "a cast that switches off checking for where / orderBy / fields", and splitting it would fix that account in packages/metadata while leaving it open in the two packages/objectql sites — the same half-done shape #6743/#7000 is currently paying for elsewhere in this lane. The two objectql sites are declared as a cross-surface touch in the dispatch and will be declared again in the PR body; engine-core is noticed here rather than after the fact.

Carried into the dispatch verbatim, all three:

1. Locate by content, never by line. engine.ts moved ~800 lines since filing and drifted a further 11 between the drivers seat's 07:3xZ read and its 01:14Z one.
2. The landmine: packages/objectql/src/engine-unknown-option.test.ts holds a deliberately unequal site — engine.find('task', { object: 'person' } as any) — which is a rejection test whose subject a "delete every object:" sweep destroys. That same file broke two separate mechanical sweeps in this lane on 08-09. Read it before writing any repo-wide pattern.
3. Two keys that must not be touched: object inside an expand entry names the related object, and syncSchemasBatch([{ object, schema }])'s object is genuinely read.

The suggested method (a back-reference pattern matching only when the value is character-for-character the first argument, per PR #6210) is carried as the recommended approach with an instruction to verify it against the real call shapes rather than trust it.

Region: disjoint from this round's two in-flight cards — #7000 is in packages/metadata/src/plugin.ts + repository.ts (different files in the same package), #6992 is in metadata-protocol's cold-boot audit.

---

Generated by Claude Code