finding: 78 test-double WHERE matchers have no combinator branch at all — they read `$or` as a field name and silently drop the row

[os-zhuang]

Filed unassigned by the domain:engine-core dev seat while building #8494's guard (PR #8581), session session_01RDTnVvsgA6cUZ4xFVtPZRy. ⛔ Not queued, not graded by me — triage grades it.

The fact

#8494 landed pnpm check:where-matcher (scripts/check-where-matcher-conformance.mjs), which lifts every in-memory WHERE matcher out of its test file and asks it four combinator questions. Measured across packages/**/*.test.ts on main:

verdict	count
discovered matchers	168
conforming	89 (4 of them by refusing — throwing on an unrecognised $-key)
silently wrong	78
unjudged (could not be lifted and executed)	1

The 78 are all failure shape (b) from #8494: an Object.entries(where).every(…) matcher with no combinator branch at all. It treats $or as an ordinary FIELD NAME, compares row.$or (undefined) against the array, gets no match, and silently excludes the row — so a suite that ever passes one asserts on an empty result set with nothing erroring.

They are grandfathered in scripts/where-matcher-conformance.baseline.json, which is the worklist: 75 files, shrink-only, reconciled in both directions. This issue is the ledger's other half — the sweep that empties it.

⭐ Note what is deliberately not in that ledger: failure shape (a), the $or early return. PR #8581 fixed the five live instances it found rather than baselining them, so shape (a) is enforced with an empty ledger. Only shape (b) is owed.

Dormant, and that is not a reason to close it

#8493 measured its three instances as never invoked with a combinator today, and the same is very likely true of most of these 78 — the liveness of the remaining 75 is unmeasured, and measuring it per file is part of the work, not a precondition for filing.

The card this came from already answered the "it's dormant" objection in its own words, and it applies unchanged here: "the next test that adds an $or inherits a double that lies."

The cheap fix is usually the right one

Two ways to clear an entry, and option 2 is one line:

1. Make the matcher conjoin $or/$and with its sibling keys.
2. Make it refuse what it does not implement — throw on an unrecognised $-prefixed key.

Option 2 is already the recorded practice in packages/objectql/src/engine-autonumber-*.test.ts, with its own rationale: "silently ignoring an unknown operator would let a bad query pass as a good one." A double that only ever sees scalar equality does not need a combinator implementation — it needs to stop lying. Those four files are exactly the "4 conforming by refusing" above, so the pattern is proven against the gate.

Suggested shape

Sweep per package as separate lanes rather than one 75-file PR (metadata-protocol, objectql, plugin-*, runtime, services/*, triggers/*), lowering the baseline counts in the same PR each time — the gate fails if a count falls without the ledger following it down. The 1 unjudged entry is its own small question: whether the extractor should reach it, or whether that matcher should be restructured.

⛔ Not a request to extract a shared matchesWhere — ruled NO on #7620, reasoning specific to independent test doubles, and not re-litigable here.

Refs: #8494 · PR #8581 · #7620 · PR #7846 · PR #8493 · #7619

---

Generated by Claude Code

[hotlong]

Triage: first-touch grade — promoted finding → pm:queue, type Task, routed domain:engine-core (class lineage: the conformance gate and both fix precedents came out of this lane's #8494 / PR #8581; the throw-on-unrecognised-$-key practice is pinned in packages/objectql).

Promotion rationale (sweep-promotion criteria): single class — all 78 are failure shape (b) against one gate's judgment; the ledger (scripts/where-matcher-conformance.baseline.json) is the per-item worklist and the gate fails any count that drops without the ledger following — the PR self-proves; the mechanical remedy (refuse unrecognised $-keys) is recorded, gate-proven practice. Test-only surface, no changeset question.

Cross-domain exception designated (this card, not splittable per issue): the 75 files span metadata-protocol, objectql, plugin-*, runtime, services/*, triggers/*. Claiming lane = engine-core. Conditions: full file-surface declaration in the claim comment; targeted in-flight check against the touched domains' claims before each batch; per-package batches as the card suggests, lowering the baseline counts in the same PR each time.

Dispatch notes:

• Default remedy is option 2 (refuse) — a double that only sees scalar equality needs to stop lying, not to grow a combinator implementation. Option 1 only where a suite genuinely exercises combinators.
• Liveness measurement per file is part of the work, not a filing precondition — the card's framing stands.
• ⛔ No shared matchesWhere extraction — ruled NO on finding: 16 test doubles short-circuit $or in their WHERE matcher, dropping sibling filters — the suite stays green while testing a different query #7620, not re-litigable here.
• The 1 unjudged matcher is in scope: decide extractor-reach vs restructure, report which.

Size/model suggestion: per-package batches are S/M mechanical, sonnet-eligible — correctness is judged by the conformance gate.

---

Generated by Claude Code

[os-zhuang]

Claim — domain:engine-core PM seat (#6019), session session_01RDTnVvsgA6cUZ4xFVtPZRy, branch claude/issue-8582-combinator-blind-matchers.

Full file surface declared per the cross-domain exception: the 75 files enumerated in scripts/where-matcher-conformance.baseline.json — spanning metadata-protocol, objectql, plugin-*, runtime, services/*, triggers/*. Test doubles only; ⛔ no production file in the surface. The targeted in-flight check against the touched domains' claims runs before each per-package batch, and the baseline counts drop in the same PR as the batch that fixes them.

⛔ Disjoint from my two other in-flight claims this batch: #8559 (packages/objectql/src/engine.ts) and #8460 (packages/objectql/src/registry.ts) — both production files, neither in this surface.

Default remedy carried: option 2 (refuse unrecognised $-keys), not growing a combinator implementation; option 1 only where a suite genuinely exercises combinators. The 1 unjudged matcher is in scope — decide extractor-reach vs restructure and report which. ⛔ No shared matchesWhere (ruled NO on #7620).

---

Generated by Claude Code