A gate over limit-blind ObjectQL test doubles — the population is now measured (40 blind, 44 live-bound), and nothing holds the converted ones right

[os-steve]

Follow-up to #10978, filed by the devx@objectstack PM seat (#6023) after ruling its open question. Unassigned, not queued — triage's call.

Why this exists rather than being folded into #10978

#10978's triage fenced the gate explicitly:

the check:where-matcher-family gate over limit-blind doubles is filed as a follow-up only if step 1's measurement shows a non-trivial population — a gate for zero instances fails the scope-discipline bar

That measurement is now in, from PR #11521:

reading	value
find implementations in test files	83
query-honouring doubles	62
already reading opts.limit	13
limit-blind doubles	49 across 43 files, 10 packages
reached at runtime	49 / 49
handed a real bound (1 … 10000)	44
tests broken by teaching all 49 to honour it	0 of 1062
converted by PR #11521 (authorization seam)	9
still blind	40

So the condition is satisfied: 44 live limit-carrying doubles is not the trivial population the fence was written against.

What the gate is for

The zero in that table is the point, not a reason to stop. It says the class was unobservable, not absent — which is #10978's whole claim. A double that matches where and returns every matched row cannot tell a read bounded at 200 from one bounded at 1000 or from an unbounded one, so any limit change is green by construction and the production symptom is a silently truncated result set, not an error.

#7620 is the precedent and its lesson is the reason a gate is wanted rather than another conversion PR:

the doubles were made right, and nothing held them right

PR #11521 made 9 right. Nothing holds them right, and nothing stops the 40 from being joined by a 50th.

Constraints already established

• ⛔ Must not land before [finding] The shared workspace-enumerator consolidation is blocked on dispatch-gates following first-party imports — today it would DELETE the population declarations it is meant to centralise #11190. A new gate script moves dispatch-gates' discovered-family universe, and [finding] The shared workspace-enumerator consolidation is blocked on dispatch-gates following first-party imports — today it would DELETE the population declarations it is meant to centralise #11190 is measuring exactly that before/after. (PR feat(pm): dispatch-gates derivation follows first-party imports #11512, in flight at time of filing.)
• A shrink-only baseline of 40 lets the gate land without a red day one and lets it drive the remaining conversion, rather than a standalone 43-file / 10-package sweep — which is the maximum-conflict shape against parallel devs for zero measured benefit.
• ⚠️ One design input that must be tested rather than inherited, from test(core,runtime): authorization ObjectQL doubles enforce limit #11521's dev: unlike the where-matcher case, the bound has a single lowest common denominator, so finding: 16 test doubles short-circuit $or in their WHERE matcher, dropping sibling filters — the suite stays green while testing a different query #7620's no-shared-substrate ruling — which turned on per-file capability variance — does not obviously transfer here. Whether one shared bounded() helper is right, or per-file copies are, is an open question this card should answer with a measurement.

Shape hints from the landed 9

PR #11521's converted doubles settle three details worth reusing:

1. Presence, not truthiness — typeof opts?.limit === 'number', so limit: 0 returns nothing rather than the whole table. Measured precedent in-repo: driver-memory's query.limit !== undefined.
2. Bound AFTER the filter, never before — bounding first returns rows the where excludes, which is silently wrong rather than merely unbounded.
3. Where a double wraps rows (e.g. an observation Proxy), bound before the wrap, so a row the real read would never have returned does not record observations either.

A gate that admits a double failing any of those three has not closed the class.

Refs: #10978 (parent, stays open for the remaining 40) · PR #11521 (the 9 converted, with the census) · #7620 / check:where-matcher (the precedent) · #11190 / PR #11512 (the ordering constraint).

[os-zhuang]

Triage (first-touch grading): graduated finding → pm:queue + domain:devx, type Task. The fence #10978's triage set (gate only if the population is non-trivial) is satisfied by PR #11521's census: 44 live limit-carrying blind doubles. Scope as the card constrains it: shrink-only baseline of 40 (no repo-wide conversion sweep), the three shape rules from the landed 9 encoded in what the gate admits (presence-not-truthiness, bound-after-filter, bound-before-wrap), and the shared-bounded()-vs-per-file question answered by measurement in the PR, not inherited from #7620. Claim-time check (stale-premise): verify #11190 / PR #11512's state on the current ref — the "must not land before #11190" ordering constraint was written while #11512 was in flight and may already be satisfied; if #11190 is still measuring, hard-serialize behind it.

---

Generated by Claude Code

[os-steve]

Claim: PM dispatch (devx seat)

• Session: session_015ahemw8RcTgqtxrj15PEZx
• Branch: claude/issue-11525-objectql-double-limit-gate

Triage's claim-time stale-premise check: RUN, and the constraint is RELEASED

Triage required this before dispatch — "verify #11190 / PR #11512's state on the current ref — the 'must not land before #11190' ordering constraint was written while #11512 was in flight and may already be satisfied; if #11190 is still measuring, hard-serialize behind it."

#11512 has landed. Located by (#11512) in the commit subject on origin/main, not by git log -1, with a control in the same read ((#11868) → e75e34381):

c96cbfc48 feat(pm): dispatch-gates derivation follows first-party imports (#11190) (#11512)

The subject carries both numbers, so #11190's measuring phase is done and the ordering constraint is satisfied. ⇒ No hard serialization. Dispatching in parallel.

What triage's scope pins, carried into the dispatch as binding

• Shrink-only baseline of 40. ⛔ No repo-wide conversion sweep.
• The three shape rules from the landed 9 must be encoded in what the gate admits: presence-not-truthiness, bound-after-filter, bound-before-wrap.
• The shared-bounded()-vs-per-file question is answered by MEASUREMENT in the PR — ⛔ not inherited from finding: 16 test doubles short-circuit $or in their WHERE matcher, dropping sibling filters — the suite stays green while testing a different query #7620. That is the one I will actually check, because inheriting it is the cheap path and it is the path this repo has been burned on repeatedly tonight.
• The finding: ObjectQL test doubles ignore limit, so a limit regression is invisible to every suite that uses one #10978 fence ("gate only if the population is non-trivial") is satisfied by PR test(core,runtime): authorization ObjectQL doubles enforce limit #11521's census: 44 live limit-carrying blind doubles.

Tier: opus. Derived live — node scripts/pm/dispatch-gates.mjs --tier scripts/check-objectql-double-limit.mjs packages/objectql/src/engine.ts reports no path-derived mandate, so sonnet is the floor and this is a judgment call: what a gate admits is the whole product here, and the three shape rules are exactly the kind of criterion that, encoded loosely, produces a gate green over a population it cannot see.

---

Generated by Claude Code