finding: check-where-matcher-conformance cannot grade an INVERTED survivor filter — the control probe drops it, so a delete double's combinator blindness stays ungraded

[qq9340100]

Filed while working #8615 (PR #8661), which extended check-where-matcher-conformance's
discovery to single-parameter .filter() callbacks that capture their where from an
enclosing scope.

The gap

That extension proposed 64 new structural candidates. The behavioural control probe seated
62 and dropped 2. The 2 it dropped share one shape — an inverted survivor filter inside
a delete double:

const survivors = rowsOf(table).filter(
 (r) => !Object.entries(o?.where ?? {}).every(([k, v]) => r[k] === v),
);

The control probe admits a candidate only when f(ROW, MATCH) === true and
f(ROW, MISS) === false. An inverted predicate answers false/true, so it is dropped as
OUT_OF_SCOPE — correctly, by the gate's own definition: it is not a row-selecting
predicate.

But it carries the identical failure shape (b) the gate exists to catch, one negation away.
A $or handed to one of these is read as an ordinary field name, row.$or is undefined,
.every() returns false, the negation makes it true — and the row survives a delete
that should have removed it. The suite then asserts on a table that was never modified,
with nothing erroring. Same silence, opposite sign.

Why this was not "fixed" in #8661

Teaching the control probe to recognise a negated predicate means inferring intent from
syntax — deciding that a leading ! means "invert my expectations". That is precisely the
naming-and-shape reasoning the gate's header rules out ("membership is decided by behaviour,
not by a name"), and a probe that guesses wrong in this direction grades a non-matcher as a
matcher, which is worse than not grading it.

The two known instances were fixed on their merits in #8661 (they now refuse an
unrecognised $-key), and the limit is pinned there as a self-test fixture
(FIXTURE_CAPTURED_NEGATED) so it stays a known limit rather than drifting into an
accidental one. What remains open is that the gate still cannot grade this spelling: a
new inverted survivor filter written tomorrow is invisible to it, exactly as the single-param
capture was before #8615.

Measured state

• instances found on main at filing: 2, both fixed in test(where-matcher): discover single-param filter callbacks that capture their where #8661
  • packages/plugins/plugin-email/src/attachment-reclaim.test.ts
  • packages/plugins/plugin-webhooks/src/auto-enqueuer.test.ts
• both are DORMANT — no suite currently hands either one a $or/$and (verified: the
  refusals changed no test outcome across 11,257 tests)
• structural candidates the probe currently drops for this reason: 2 of 64

Options, not investigated further

1. Give the battery a second admission mode: a candidate that answers the control probe
   exactly inverted (false/true) is seated as an INVERTED matcher and graded against a
   negated battery. Keeps the criterion behavioural — inversion is measured, not read off a
   ! token.
2. Leave it ungraded and rely on the pinned fixture plus review. Cheapest, and honest, but
   it is the same "a gate that cannot see a class of instance" argument check-where-matcher-conformance's discovery heuristic misses single-param inline filter closures — 16 files carry the same shape-(b) blind spot, undetected #8615 was filed on.

Option 1 looks structurally right and is the same move #8615 made one level down, but the
false-positive load of a second admission mode is unmeasured and that measurement is the
work here, not the coding.

Refs: #8615 (the discovery extension that surfaced this), #8661 (the PR), #8494 (the gate),
#8582 / #7620 (the original sweeps).

[hotlong]

Finding round — HOLD. finding → pm:on-hold, domain:devx. Date: 2026-08-14. Source: triage seat grading (⛔ not a maintainer ruling).

Premise re-verified on origin/main @ 00ee416: the gate (scripts/check-where-matcher-conformance.mjs) and its baseline (scripts/where-matcher-conformance.baseline.json) are both live; the limit is pinned as the card describes.

Why hold rather than promote. Everything that is live here has already been fixed: both known inverted survivor filters refuse an unrecognised $-key as of #8661, both were dormant (the refusals changed no outcome across 11,257 tests), and the limit is pinned as a self-test fixture (FIXTURE_CAPTURED_NEGATED) so it is a known limit rather than a drifting one. What remains is that the gate cannot grade a spelling that has 2 instances in the repo, both already correct.

And the work is not the coding — the card says so plainly, and I agree with its own analysis: a second admission mode's false-positive load is unmeasured, and a probe that mis-seats a non-matcher as a matcher is worse than not grading it, because it manufactures confidence. Dispatching today buys an unmeasured risk to close a gap with zero measured instances.

Named restart conditions (any one lifts the hold — ⛔ a hold without a droppable exit is a card nobody can legally revive):

1. A third inverted survivor filter appears in any sweep or review — i.e. the spelling is being written again rather than being a two-instance historical accident.
2. check-where-matcher-conformance's discovery is extended again for any reason. check-where-matcher-conformance's discovery heuristic misses single-param inline filter closures — 16 files carry the same shape-(b) blind spot, undetected #8615 made exactly this move one level down; a second admission mode is far cheaper to design while that machinery is already open, and the false-positive measurement can ride the same battery run.
3. A measured false green attributable to a delete double's combinator blindness — that converts this from coverage debt to a live defect and it should be re-graded as one, ⛔ not resumed as this card.

Opportunistic trigger files (per the hold discipline — a restart condition nobody can see is not a condition). Name this card in the dispatch order of any card whose file surface intersects:

• scripts/check-where-matcher-conformance.mjs
• scripts/where-matcher-conformance.baseline.json
• the FIXTURE_CAPTURED_NEGATED self-test fixture

A PR already opening the gate's admission logic should pick this up as a declared add-on, ⛔ not as a silent extra.

⛔ Explicitly not deferred by this hold: nothing in #8661 changes. The two instances stay fixed and the fixture stays pinned; if the fixture is ever deleted, that is restart condition 1 by another route.

---

Generated by Claude Code