Filed by the domain:spec PM seat, session session_01G4138K1EG7kQ81FNba5Kp4, as condition C1 of the isolated contract-tier review of PR #15464 (card #14426). Filed unassigned, for triage. ⛔ Not folded into #14426 — that card's fence is explicit ("the #13553 guard's comment only", three named prose sites), the text below is a fourth site outside it, and it is present at that PR's merge-base, so it is not that PR's defect.
Not a duplicate: #13357, #13494, #13495 and #13549 are all closed (they are the rulings and the behaviour fixes); none of them is "the comment recording the decision state is now false". Searched before filing.
The text, measured on origin/main (e8c7956c4), packages/drivers/driver-memory/src/memory-matcher.ts:309-313
// ⚠️ `$eq` ONLY, deliberately. The exemption is written over the
// OPERATOR and not over "the comparand is null", because the latter
// spelling would have moved `$in: [null]` / `$nin: [null]` with it —
// and those are #13357's cells, `needs-user-decision`, held for the
// maintainer. They are measured byte-identical across this change.
Why it is false on the same tree
Three independent records on origin/main say those cells were decided:
So the package states the decision state two ways, thirty lines apart, and the stale one is the one an author reading the guard arrives at first.
Why it is worth a card rather than a silent fix
needs-user-decision is a live protocol state with a named reader (the maintainer's inbox). A source comment that asserts a cell is sitting in that state, when the door two packages over refuses the shape by ruling, is the shape that produces a second escalation of a settled question — the failure mode the enforce-or-remove policy exists to prevent. It is also exactly the class of drift a comment-only re-pointing card (#14426) is meant to close, one site short.
Shape of the fix
Comment-only, in the same file: re-point the parenthetical at the 2026-08-31 ruling the way memory-matcher-null-value-and-comparand.test.ts:56 and filter-comparand-shape.ts:92 already do — the $eq-only exemption's reasoning is unaffected (writing the exemption over the operator rather than over "the comparand is null" is still right; what changed is that the shapes it declined to move are now refused at the validation entrance, not held). ⛔ No arm, guard condition or behaviour changes; the negative pin memory-null-list-member-unreachable.test.ts already covers the door.
Whether it is folded into a later comment-repair card in this package or fixed on its own is triage's to decide.
Refs: #14426 (the sibling prose-repoint card whose review found this) · PR #15464 · #13357 · #13495 · #13494 · #13549 · #13553 (the guard this comment sits above) · #14080 (the 2026-09-01 ordering ruling)
Filed by the
domain:specPM seat, sessionsession_01G4138K1EG7kQ81FNba5Kp4, as condition C1 of the isolated contract-tier review of PR #15464 (card #14426). Filed unassigned, for triage. ⛔ Not folded into #14426 — that card's fence is explicit ("the #13553 guard's comment only", three named prose sites), the text below is a fourth site outside it, and it is present at that PR's merge-base, so it is not that PR's defect.Not a duplicate: #13357, #13494, #13495 and #13549 are all closed (they are the rulings and the behaviour fixes); none of them is "the comment recording the decision state is now false". Searched before filing.
The text, measured on
origin/main(e8c7956c4),packages/drivers/driver-memory/src/memory-matcher.ts:309-313Why it is false on the same tree
Three independent records on
origin/mainsay those cells were decided:packages/spec/src/data/filter-comparand-shape.ts:92—## Refused BY RULING, 2026-08-31: a null list member (#13357), with:314pointing thenullListMemberErrordoor back at it and:502naming "the null-member carve-out (2026-08-31 ruling, [finding] driver-memory's matcher answers a NULL comparand inconsistently across the two readings of "no value" —$in:[null]/$nin:[null]disagree while$null/$ne:nullagree #13357)".packages/spec/CHANGELOG.md:2973—e398863: feat(spec): refuse null in list-comparand positions — $in / $nin members and $between bounds (#13357, #13495).packages/drivers/driver-memory/src/memory-matcher-null-value-and-comparand.test.ts:56, already reads in the past tense: "They wereneeds-user-decisionwhen driver-memory's reference matcher answers{$eq: null}with NO MATCH on a MISSING key — it is the one surface of five that does not read$eq: nullas the null predicate (#5332) #13494/driver-memory's reference matcher answers{$between: [null, null]}with EVERY valued row — the range arm's two comparisons are both false against a null bound, so a bounded range stops bounding #13495/driver-memory's reference matcher matches a NULL-VALUED row against a well-formed bounded$between— the live mingo path excludes it, so one package answers one filter two ways #13549 landed".So the package states the decision state two ways, thirty lines apart, and the stale one is the one an author reading the guard arrives at first.
Why it is worth a card rather than a silent fix
needs-user-decisionis a live protocol state with a named reader (the maintainer's inbox). A source comment that asserts a cell is sitting in that state, when the door two packages over refuses the shape by ruling, is the shape that produces a second escalation of a settled question — the failure mode the enforce-or-remove policy exists to prevent. It is also exactly the class of drift a comment-only re-pointing card (#14426) is meant to close, one site short.Shape of the fix
Comment-only, in the same file: re-point the parenthetical at the 2026-08-31 ruling the way
memory-matcher-null-value-and-comparand.test.ts:56andfilter-comparand-shape.ts:92already do — the$eq-only exemption's reasoning is unaffected (writing the exemption over the operator rather than over "the comparand is null" is still right; what changed is that the shapes it declined to move are now refused at the validation entrance, not held). ⛔ No arm, guard condition or behaviour changes; the negative pinmemory-null-list-member-unreachable.test.tsalready covers the door.Whether it is folded into a later comment-repair card in this package or fixed on its own is triage's to decide.
Refs: #14426 (the sibling prose-repoint card whose review found this) · PR #15464 · #13357 · #13495 · #13494 · #13549 · #13553 (the guard this comment sits above) · #14080 (the 2026-09-01 ordering ruling)