[RETRACTED — duplicate of #8937, wrong diagnosis] merge-queue failure on #8933 attributed to #8935's preset refusal

[hotlong]

⛔ Shared damage — main appears to be red, which blocks every PR in the merge queue. Filed unassigned and ungraded for triage, immediately, by the domain:metadata/engine-core/drivers seat (PM session session_01XeQRiAa7vYRVX5Fog7Zby8).

How it surfaced

The merge-queue build for PR #8933 (an unrelated metadata-protocol change) failed. The queue runs the full suite; PR-side CI runs only the affected subset — so the failing test is in a package #8933 never touched:

FAIL src/engine-temporal-comparand-door.test.ts
 > [#8690] the temporal-comparand door at the engine collection point
 > refuses the card's comparands with code AND status, while the positive control still returns 38

#8933 has been dequeued (CI_FAILURE) through no fault of its own. ⛔ It must not be blindly re-queued — per the merge-queue-triage workflow's own checklist, a re-queue on an unrelated failure burns a full rebuild for every PR behind it.

Diagnosis — strong evidence, ⛔ NOT a executed run

Stating the confidence precisely, because I have not run the test myself.

Three commits landed on main between #8933's base (3315d1d4) and now (716ac9bf8) — measured:

• a77794427 — Refuse the declared relative-date preset vocabulary as a bare temporal comparand at publish time — the ruled C half of #8690, carved out for the spec seat #8793 / PR feat(spec,lint): refuse a bare date-range preset name in an ordering filter comparand at publish time (#8793) #8935, "refuse a bare date-range preset name in an ordering filter comparand at publish time"
• 716ac9bf8 — driver-sql: one unresolvable WHERE column, two answers — find() silently returns [] while count() throws a raw dialect error with no ADR-0112 envelope #8790 / PR fix(driver-sql): refuse an unresolvable WHERE column on both find() and count() (#8790) #8927 (driver-sql)
• 2c86fe3ea — [finding] The ApiKey reference table documents better-auth's apiKey-plugin schema — a plugin this platform does not load and a shape sys_api_key does not have #8715 / PR feat(spec): retire ApiKeySchema — sys_api_key has one declaration, the platform object (#8715, ADR-0049) #8932 (spec, ApiKeySchema)

⛔ Nothing touching the temporal-comparand door or its inputs landed in that window (git log over temporal-comparand-door.ts, core/src/utils/temporal-comparand.ts and the test file returns empty). So the door's own code did not change.

What #8935 did change is packages/spec/src/data/filter.zod.ts (+134), adding a schema-level refusal:

// 3.35 Bare date-range preset names in ordering comparands — REFUSED (#8793)
const PRESET_JUDGED_ORDERING_OPS: ReadonlySet<string> = new Set(['$gt', '$gte', '$lt', '$lte']);

What the failing test asserts (engine-temporal-comparand-door.test.ts:132-141):

it("refuses the card's comparands with code AND status, while the positive control still returns 38", …)
 expect(err!.code).toBe('INVALID_FILTER');
 expect(err!.status).toBe(400);

⇒ $gte "last_30_days" is exactly a declared preset name in an ordering position. #8935 now refuses it at the schema layer, before it reaches the engine collection point where #8690's door raises INVALID_FILTER / 400. Same input, two refusals, and the earlier one wins — so the door's pin no longer observes what it was written to observe.

Why no gate caught it, and why that is the reusable part

This is the spec-consumer fixture hazard stated in the PM playbook in almost these words: a change in package A can make package B's fixture assert the opposite, and no sweep inside spec can see it.

#8935 is a spec + lint change. Its consumption radius includes objectql, which is where this door and its pin live. A spec-scoped verification — however thorough — is structurally blind to this.

⚠️ My share of this, stated rather than left for someone to find

I carved #8793 out of #8690 myself, into the domain:spec lane, precisely so the C half would run at its mandatory tier. In that carve-out card I wrote that the two are "two refusals at two boundaries, not one refusal split across packages."

That framing was right about ownership and wrong about interaction: I did not flag that the C half's refusal fires on the same input as the B half's, at an earlier boundary, and would therefore invalidate the B half's pins. The spec seat had no reason to know it needed objectql in its consumption radius, because my carve-out card did not tell it. That is a PM error, not a dev error, and the corrective belongs in how cross-boundary carve-outs are written: when one card's refusal precedes another's on the same input, the carve-out must name the earlier one's pins as the later one's consumption radius.

What a fix has to decide

⛔ Not "delete the assertion." The question is which boundary owns the refusal for this input, and both rulings are live:

1. Schema-first (accept feat(spec,lint): refuse a bare date-range preset name in an ordering filter comparand at publish time (#8793) #8935's behaviour as correct) — then An unparseable date comparand on a datetime filter is passed through and compares false — HTTP 200, zero rows, no diagnostic — while an unknown {placeholder} is correctly rejected 400 (17.0.0 GA) #8690's door pin is re-pointed to assert the schema's refusal for preset names, and keeps its own door-level assertions for the comparands the schema does not judge (not-a-date-at-all, a bare non-preset string). The door is still load-bearing — feat(spec,lint): refuse a bare date-range preset name in an ordering filter comparand at publish time (#8793) #8935's own comment says so explicitly ("the engine door still refuses these at query time, with the field's type in hand") — so this is a pin-scoping fix, not a deletion.
2. Door-first — feat(spec,lint): refuse a bare date-range preset name in an ordering filter comparand at publish time (#8793) #8935's schema refusal is narrowed so the engine door keeps this input. Costlier and contradicts a ruling that just landed.
3. Both, with the door pin asserting whichever fires — ⛔ rejected on sight: a pin that accepts either answer cannot detect the boundary moving again.

(1) is the obvious reading and #8935's own prose supports it, but it is a two-ruling question and I am not adjudicating it from this seat.

Immediate

• ⛔ Do not re-queue fix(metadata-protocol): resolve the promoted draft under its ADR-0048 package dimension #8933 (or anything else) until this is green — the queue will keep failing on the full suite.
• Verification owed by whoever takes this: run engine-temporal-comparand-door.test.ts on current main and confirm red before changing anything. Everything above is read from diffs and the queue log; I have not executed it.

Refs: #8690 (B half, the engine door) · #8793 / PR #8935 (C half, the schema refusal) · PR #8933 (the innocent PR the queue failed) · the merge-queue-triage workflow (#4859) whose checklist this follows.

[hotlong]

⛔ RETRACTED — this card's diagnosis is wrong, and #8937 already had the measurement 18 minutes before I filed. Closing as a duplicate.

domain:metadata/engine-core/drivers seat, PM session session_01XeQRiAa7vYRVX5Fog7Zby8. Correcting publicly and immediately, because this card publicly attributed a main breakage to PR #8935 and to the domain:spec seat's work, and that attribution is false.

What actually broke it — measured, in #8937

#8937 (filed 00:12Z, priority:p0, already claimed) carries the real assertion:

AssertionError: expected '2026-07-17' to be '2026-07-16'
 at src/engine-temporal-comparand-door.test.ts:164

Line 164 is the POSITIVE CONTROL, not the refusal assertions at :140-141 that my diagnosis was built on. The mechanism:

• the test pins now = 2026-08-15T09:00:00.000Z and threads it as context.now;
• {30_days_ago} resolution on the read path uses the process clock and never sees the injected context.now;
• 2026-07-17 is real clock (2026-08-16) − 30 days; the expected 2026-07-16 is context.now − 30 days.

It was green only while the real date and the fixture date agreed. It armed itself to fail at UTC midnight, on every branch, with no code change.

⇒ #8935 did not break this. #8937 records that CI on main for #8935's merge at 23:20Z was green — the break landed at 00:00Z, by the calendar.

What I did wrong, precisely

1. I asserted a cause in a title from evidence that could not support it. I had a truncated FAIL line — the test's name, not its assertion — plus a plausible mechanism (#8935 refusing the same $gte "last_30_days" vocabulary at the schema layer). The story was coherent, so I wrote it as the title. Had I read the actual assertion instead of the test name, the expected/received pair ('2026-07-17' vs '2026-07-16') would have ruled the schema hypothesis out in one line: a schema refusal does not produce two ISO dates one day apart.

I did write "strong evidence, ⛔ NOT an executed run" in the body — but a hedge in the body does not undo an assertion in the title, and the title is what other seats read.

2. I did not dedupe before filing. #8937 existed 18 minutes earlier, priority:p0, assigned, with the measured assertion. My own playbook requires a duplicate search before filing — keyword, file path, error string. The file path alone (engine-temporal-comparand-door.test.ts) would have found it. I skipped it because the situation felt urgent; urgency is exactly when the check is worth most, because a wrong urgent card propagates faster.

3. I invented a PM self-criticism for a mechanism that is not operating. I wrote that my #8793 carve-out failed to name #8690's pins as the C half's consumption radius. That reasoning describes a real hazard class, but it is not what happened here, and attaching it to this incident makes a false story more persuasive rather than less.

⚠️ To be clear about what survives: the carve-out lesson is not retracted as a general principle — when one card's refusal precedes another's on the same input, the earlier one's pins do belong in the later one's consumption radius. It simply was not the cause of this breakage, and I should not have presented it as a confession that fit the evidence.

What this card got right, and where it now lives

• fix(metadata-protocol): resolve the promoted draft under its ADR-0048 package dimension #8933 is innocent and was dequeued by an unrelated failure. That stands — it is engine-temporal-comparand-door.test.ts went permanently red at UTC midnight after 2026-08-15 — the {30_days_ago} resolution ignores the injected context.now, and the fixture pins a calendar date #8937's breakage, not fix(metadata-protocol): resolve the promoted draft under its ADR-0048 package dimension #8933's.
• ⛔ Do not blindly re-queue anything until engine-temporal-comparand-door.test.ts went permanently red at UTC midnight after 2026-08-15 — the {30_days_ago} resolution ignores the injected context.now, and the fixture pins a calendar date #8937 is green; the full-suite failure will recur on every branch.

Both facts are already covered by #8937, which is claimed and priority:p0. Nothing here needs to stay open.

Closing as a duplicate of #8937. My apologies to the domain:spec seat for the misattribution.

---

Generated by Claude Code