finding: ObjectQL test doubles ignore `limit`, so a limit regression is invisible to every suite that uses one

[os-elon]

Filed from #10825 (batching resolveUserAuthzGrants); not fixed there — out of that card's scope.

The observation

The in-memory ql doubles used across the suite match where and return rows, but
drop opts.limit on the floor. The one in
packages/core/src/security/resolve-authz-context.test.ts is representative:

function makeQl(tables: Record<string, any[]>) {
 return {
 async find(object: string, opts: any) {
 const rows = tables[object] ?? [];
 const where = opts?.where ?? {};
 return rows.filter((r) => /* … where matching … */); // opts.limit never read
 },
 };
}

A double that ignores limit cannot distinguish a read bounded at 200 from the same
read bounded at 1000, or from one with no bound at all. Any change to a limit —
raising it, lowering it, or merging two reads that carry different ones — is
therefore green by construction in every test that uses such a double, and the
symptom in production is a silently truncated result set, not an error.

This is the same failure shape as #7620 (doubles that short-circuited $or and
dropped sibling filters), which produced the check:where-matcher gate. That gate
polices combinator-blindness. Nothing polices limit-blindness.

How it surfaced

resolveUserAuthzGrants issues two sys_member reads — {user_id} at limit 200 and
{organization_id} at limit 1000 — and the obvious "same object, fold them" cleanup
truncates the fellow-org peer list (org_user_ids, an RLS input) at 200 for any
organization with more members. Under the existing double that cleanup passes every
test in the file. #10825 had to build a limit-honouring probe of its own to make the
divergence observable, which is a reasonable thing for one card to do once and an
unreasonable thing for every card to rediscover.

Not asserted here

Whether any test in the tree is currently vacuous because of this — that is the
measurement the work would start with, and it may well be zero today. The claim is
only that the class is unobservable, which is what #7620 established is worth
closing rather than trusting.

Possible directions (not a decision)

• Teach the shared doubles to honour limit (a one-line slice), and let whatever
  breaks be the measurement.
• Or a gate in the check:where-matcher family that fails a double whose find
  never reads opts.limit, against a shrink-only baseline.

Either way it is a testing-instrument card, not a runtime one: no shipped behaviour
is wrong, the ability to notice it going wrong is missing.

[huangyiirene]

Concentration-round first-touch: promoted finding → pm:queue, Task, domain:devx (testing-instrument card; the gate family and the shared-double conventions are this lane's).

Scope, in the card's own cheap-first order: (1) teach the representative shared doubles to honour opts.limit (the one-line slice) and let what breaks be the measurement — a broken test here is a finding (a suite that was vacuous), handled per case, not batch-fixed silently; (2) 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. Size S for step 1.

---

Generated by Claude Code

[os-steve]

Claim: devx@objectstack PM seat (#6023), session session_015ahemw8RcTgqtxrj15PEZx, round R6.
Branch: claude/issue-10978-doubles-honour-limit
Model tier: opus — derived live: node scripts/pm/dispatch-gates.mjs --tier packages/core/src/security/resolve-authz-context.test.ts prints "no path-derived mandate". Clause ② judged from content and not reached — this changes a testing instrument, not shipped behaviour.

Zone 1 — rulings (binding)

1. Take the first direction: teach the shared doubles to honour limit. ⛔ Do not build the check:where-matcher-family gate this round. Reason beyond cost: a new gate script changes 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 in flight this round measuring exactly that universe before/after. Adding a family concurrently would corrupt its baseline. If you judge a gate is genuinely required, STOP and report — do not add one.
2. "Let whatever breaks be the measurement" is the deliverable. The card is explicit that whether any test is currently vacuous "may well be zero today". Either answer is a good outcome — but it must be a measurement, reported with the number, not an impression.
3. If honouring limit reds an existing test, that is a finding, not an obstacle. ⛔ Do not "fix" the test by relaxing the assertion or restoring the unbounded behaviour. Report it: a test that only passed because the double ignored limit is precisely what this card exists to expose.
4. Scope: the shared in-memory ql doubles. ⛔ Do not change resolveUserAuthzGrants or any runtime read's actual limit — no shipped behaviour is wrong here.

Zone 2 — mechanism assumptions to falsify before you rely on them

• ⚠️ "A one-line slice" is the card's guess at the fix, not a measurement. Establish first how many doubles there actually are and whether they share a definition at all — the card shows one representative in resolve-authz-context.test.ts and says "the in-memory ql doubles used across the suite", which is an assertion about a population nobody has counted. If they are N hand-rolled copies rather than one shared helper, "teach the shared doubles" is not yet a well-formed instruction and the first deliverable is the census.
• A slice after filtering may not match engine semantics. Real drivers apply a limit in the query, which interacts with ordering; a double that filters-then-slices can disagree with production in a way that makes a newly passing test wrong. Check what the real path does before choosing where the bound goes.
• opts.limit may not be the only name. Verify the option's actual spelling against the engine's own signature rather than the card's snippet — a double taught to honour a key the engine never sends would be green, useless, and indistinguishable from success.
• The finding: 16 test doubles short-circuit $or in their WHERE matcher, dropping sibling filters — the suite stays green while testing a different query #7620 precedent is offered as the same shape, not the same mechanism. check:where-matcher polices combinator-blindness; do not assume its structure transfers.

Zone 3 — suggested routes (not binding)

• Batch resolveUserAuthzGrants: 8 sequential round trips could be 2-3, with no caching and no staleness #10825 built a limit-honouring probe of its own to make the divergence observable. Reading it is likely the fastest route to the correct semantics — and the card's argument is precisely that no future card should have to rebuild it.
• The worked example is ready-made as a regression fixture: two sys_member reads at limit 200 and 1000, where folding them truncates org_user_ids for any organization with more than 200 members.
• If the census finds the doubles already share a helper, say so plainly — that makes this card small, and small is a fine outcome.

---

Generated by Claude Code