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).