Motir

Filed by the motir run of MOTIR-2994 (2026-08-18, motir-core#2122). The correction is already applied — this is the telemetry.

What the card claimed

MOTIR-2994's headline and its "The measurement" section state a mechanism, in the scheduler, as established fact:

Two same-key events close together make the second fail to SCHEDULE at all. Not delayed, not coalesced — the run never happens, and nothing surfaces to the caller.

What the probe found

Driven against the same scheduler the log came from — inngest-cli 1.27.0, SDK 4.5.0, scripts/experiments/inngest-debounce-coalescing.mjs — the claim did not reproduce once:

• 4–30 events, same key and distinct keys, sent serially, concurrently and as one batched send, with and without timeout: every burst produced exactly the contracted run count.
• error enqueueing debounce job: queue item already exists appeared 0 times in ~20 trials.

"Fixed in between" is excluded, per the reproduce-at-the-reporter's-base rule: inngest-cli is pinned at 1.27.0 at both the reporter's base (3913fb9d) and origin/main, lib/jobs/defineJob.ts is byte-identical across the window, and no commit touched it. So this was never reproduced, not repaired.

The real defect — found by the probe, and sufficient to explain the E2E's 3 runs where 4 required on its own — is that an unresolvable debounce key MERGES: events whose key expression names a field they do not carry all land in ONE bucket instead of skipping the debounce, so N unrelated events yield one run. MOTIR-2902 used key: 'event.data.parentId' on work-item/created, where a root item has no parent.

The planning defect

A card is entitled to assert an OBSERVATION; asserting a MECHANISM needs a controlled reproduction, and the card's own text shows it knew the difference. MOTIR-2994 carries an explicit ⚠️ block recording that the FIRST reading of the same log ("the dev server ignores debounce") was wrong — then states the SECOND reading in the same declarative voice, with no more evidence behind it than the first had. One log line supports "a run went missing and this error was present". It does not identify which of several mechanisms produced it, and the corrected reading here was wrong in a way that pointed the fix at the wrong half of the option.

The cost was not the wasted work — it was nearly the opposite. The scoped work (a probe, a class guard, a disposition, the docs) was right and shipped whole. The exposure is that a run reaching a green probe could reasonably have concluded "premise false, nothing to do" and closed a card whose real defect was one experiment away, in a different cell of the matrix.

The rule this argues for

A card whose premise is a mechanism inferred from a log — as opposed to a behaviour someone watched — says which reading it is, in the card, so the run inherits the uncertainty instead of the conclusion. The authoring-side half of plan-rules/phase-deepen.md's NEGATIVE limb, one step over: a card explaining a defect by a mechanism owes the reproduction, or owes the words "inferred, unreproduced".

Also worth recording

Two of the four acceptance criteria named docs/decisions/code-graph-index-fleet.md §7 and lib/jobs/definitions/codeGraphRefresh.ts:89 precisely and correctly, and the card's scope survived its premise being wrong intact. This is a good card with one over-claimed sentence, not a bad card — which is the interesting part, because the over-claim is in exactly the sentence a reader trusts most.