A scalar `data.id` beside a NON-scalar `where.id` still silently drops the predicate — the remaining silent shape after the #11142 refusal, pinned by #5748

[os-zhuang]

Found while implementing #11142 (the unequal-scalar where.id refusal). Filed separately and unassigned: acting on it would reverse another #5748-pinned verdict (a SCALAR data.id still outranks where and multi), which is a maintainer decision, not a rider on that card — the same reason #11142 itself was filed off #11009.

The shape

await engine.update(obj, { id: 'rec_1', title: 'x' }, { where: { id: { $in: ['a', 'b'] } }, multi: true });

resolveEngineUpdateDispatch rules by-id with the payload id bound (rec_1): the truthy scalar data.id outranks where and multi alike (#5748 ruling A, pinned in engine-update-dispatch.test.ts — a SCALAR data.id still outranks where and multi, first assertion). The $in predicate over ids — and the declared multi: true — are silently discarded. Same for an array or null where.id beside a scalar payload id.

Why #11142 did not cover it

#11142's ruling scoped the refusal to a truthy scalar where.id different from the payload id ("truthy scalar where.id 响亮拒绝"), and its PR pins the non-scalar neighbour explicitly as out of the ruled scope so the refusal cannot creep. #11009's unhonoured-keys refusal does not reach it either: the only where key is id. So after both refusals land, this is the last where.id-shaped declaration the by-id update path drops with no diagnostic.

What a fix has to decide

1. Refuse a payload-sourced by-id dispatch whose where.id is a non-scalar predicate (same loud-refusal family). Reverses the remaining half of the ObjectQL.update 的 data.id 不做标量测试 —— 载荷里的算子对象被当成主键绑定,且盖过显式 options.multi: true #5748 pin — needs a ruling.
2. Leave it, on the grounds that a payload id is the row address and a caller that also writes an id-set predicate wrote a contradiction too rare to arm. That keeps one silent shape in a family otherwise made loud (ObjectQL.update 的 data.id 不做标量测试 —— 载荷里的算子对象被当成主键绑定,且盖过显式 options.multi: true #5748 payload operator-objects, A compare-and-set where on a by-id update is silently inert — the extra predicate keys never reach the driver, and SqlHttpOutbox.redeliver's status guard is one of them #11009 extra keys, A scalar data.id beside a DIFFERENT scalar where.id silently drops the where.id predicate — the one unhonoured-predicate shape #11009's refusal deliberately left standing #11142 unequal scalars).

Worth noting for the triage: unlike #11142's shape (which could at least be spelled by folding ingresses), no ingress in this repo constructs this pair — the ingress survey on PR #11229 found the non-scalar where.id production sites (outbox sweeps) never carry a payload id.

Refs: packages/metadata-core/src/engine-update-dispatch.ts (the #11142 boundary comment names this shape as deliberately untouched), #5748, #11009, #11142.

---

Generated by Claude Code

[os-zhuang]

Triage: needs-user-decision, domain:engine, Task — acting on this reverses the remaining half of the #5748-pinned verdict (a SCALAR data.id still outranks where and multi), and a pin flip on a ruled behaviour is the manual floor regardless of how small the diff is.

[facets-block]

• 实际业务需求:仓内测量(PR fix(objectql,metadata-core): refuse a by-id update whose scalar where.id names a different row than the payload id #11229 的 ingress 普查)显示没有任何一处会构造「标量 payload id + 非标量 where.id」这对矛盾——现时痛感为零;但 SDK 外部调用方可以写出它,写出即静默丢谓词与 multi: true。
• 项目长远合理性:这是「静默丢弃⇒响亮拒收」家族(ObjectQL.update 的 data.id 不做标量测试 —— 载荷里的算子对象被当成主键绑定,且盖过显式 options.multi: true #5748 operator-objects、A compare-and-set where on a by-id update is silently inert — the extra predicate keys never reach the driver, and SqlHttpOutbox.redeliver's status guard is one of them #11009 多余键、A scalar data.id beside a DIFFERENT scalar where.id silently drops the where.id predicate — the one unhonoured-predicate shape #11009's refusal deliberately left standing #11142 不等标量)收口后最后一个静默臂;留着它,家族不变量就带着一个例外,例外会被当先例引用。
• 防 AI 写代码犯错:静默丢谓词正是 AI 批量犯错被掩盖的温床——AI 生成的调用方写出矛盾对时,响亮拒收当场教会它,静默丢弃让错误数据落库。四轴中本轴最重。
• 创业阶段不扩散需求:改动极小(dispatch 判定处加一个拒收分支 + 翻一条 pin);不是能力扩张,是家族一致性收尾。

一句话问题:by-id 更新路径上「标量 data.id 旁站着非标量 where.id 谓词」这最后一个静默丢弃形状,是补进响亮拒收家族,还是按「payload id 即行地址、矛盾对太罕见」接受留存?

选项	代价
1 响亮拒收(同家族错误码/文案),翻转 #5748 pin 的剩余半条	反转一条已裁 pin(须按翻转纪律:删除/反转断言,⛔ 不修绿;随卡带全仓 pin 清扫两句);外部调用方若依赖旧静默行为会开始收到拒绝
2 维持现状,把「deliberately silent」写进边界注释与 pin 文案,家族宣言带一个具名例外	家族不变量永久带例外;未来读者需要知道为什么这一臂例外

推荐 1(置信度高):四轴同向——防 AI 轴与长远轴强推,业务轴的「零仓内构造」恰好说明拒收的破坏半径为零,创业轴成本可忽略。裁决格式:回「1」/「2」;1 ⇒ 晋级 pm:queue(engine 席,派发词按 pin 翻转纪律带全仓清扫条款),2 ⇒ 关闭本卡、注释+pin 文案的具名例外化开 S 卡。

---

Generated by Claude Code

[claude]

Maintainer ruling recorded (atomic four-part write)

Ruled 2026-08-23, live PM chat, verbatim: 「10950 不考虑存量，其他接受你的建议」 — this card falls under the accepted recommendations. Ruled: option 1 — the scalar-data.id-beside-non-scalar-where.id shape joins the loud-refusal family (same error-code/wording family as #5748/#11009/#11142). needs-user-decision → pm:queue in the same stroke. Dispatch riders (pin-flip discipline): the remaining half of the #5748 pin (a SCALAR data.id still outranks where and multi) is deliberately REVERSED — delete/invert the assertion, never green-wash it; the dispatch carries the repo-wide pin-sweep two-liner.

---

Generated by Claude Code

[os-zhuang]

Claim — engine seat, session session_01RfyXxZ2WPjcjhuXpiQQc3y, branch claude/issue-11230-scalar-data-id-nonscalar-where-refusal. pm:queue → pm:dispatched in one label write, read back.

Dispatched on the maintainer's ruling of 2026-08-23, recorded on this card. Quoted verbatim, not paraphrased:

「10950 不考虑存量，其他接受你的建议」

⇒ option 1: this shape joins the loud-refusal family (same error-code and wording family as #5748 / #11009 / #11142). The dispatch order carries the two riders the ruling attached, and both are stated to the dev as non-negotiable:

1. The remaining half of the ObjectQL.update 的 data.id 不做标量测试 —— 载荷里的算子对象被当成主键绑定,且盖过显式 options.multi: true #5748 pin is deliberately REVERSED — a SCALAR data.id still outranks where and multi. Delete or invert the assertion. ⛔ Never green-wash it, never adjust it until it passes. A pin that was ruled to flip must visibly flip.
2. The repo-wide pin sweep two-liner rides along, so no other pin is left asserting the old silent behaviour.

The seam this card will hit, named before it is hit

#11142 — the immediately preceding member of this family — landed in packages/objectql/src/engine-update-dispatch.ts, packages/metadata-core/src/engine-update-dispatch.ts and packages/objectql/src/engine.ts, and appended to packages/spec/src/api/error-code-ledger.zod.ts. That last file is domain:spec territory, and whether cross-lane error-code ledger appends are pre-approved as a class is a standing open question this seat has already raised (#6017).

Instruction to the dev: follow the #11142 precedent exactly — same family, same mechanics, and the ruling itself says "same error-code/wording family" — and name the spec-file touch prominently in the PR body so the spec seat can object on the record if it disagrees. ⛔ Do not invent a new error code shape, and ⛔ do not touch anything else in packages/spec.

Scope note

The card's own four-axis analysis measured zero in-repo constructors of the contradictory pair, which is what makes the blast radius of refusing it approximately nil — an external SDK caller can still write it, and today that silently drops both the predicate and multi: true. That is the argument, and it is the card's, not an inflation of it: the business axis reads "no present pain", and the case rests on the AI-error axis and family consistency.

Serialization

Dispatched alongside #11374 (driver-sql MySQL schema sync), which shares no file with this card. All 10 currently-open PRs are in spec / docs / rest / qa — none touches objectql or metadata-core. Measured.

⚠️ #11293 is deliberately NOT dispatched in this batch. Its landing site (hook-body ctx accessor) is not yet established, and metadata-core/src/engine-update-dispatch.ts — this card's file — appears in the hook-dispatch grep. Rather than assert a disjointness I have not measured, that card waits for the next round. This seat made exactly that mistake earlier today on #11201 and is not repeating it.

Duplicate probe, both legs positive-controlled: no open PR claims this number, and git ls-remote origin 'refs/heads/*issue-11230*' is empty against 98 live *issue-* branches.

---

Generated by Claude Code