Motir

Filed 2026-08-18 by the run of MOTIR-3015 (motir-core #2125). The correction is already applied — this card is the record, and the rule question it raises.

MOTIR-3015 was itself the sweep half of a mechanism redefinition: MOTIR-2994 refuted "the Inngest dev server DROPS a debounced run", and MOTIR-3015 existed to remove that claim from the code comments still asserting it as a warrant. Its main premise held exactly — three blocks, at the three line ranges named. Two of its own sub-claims did not, and both are the same family of defect the card was written to remove.

Defect 1 — the remediation instruction asserted an unverified mechanism

"What to do" step 3 told the runner to re-point the third block "saying the reason in one clause (the key would be unresolvable here too)". It is not unresolvable. WorkItemDerivationRequestedData.parentId is required and non-null — lib/jobs/types.ts:456-460 says so in its own doc comment ("Never null: an item with no parent has nothing to derive, so the emit site skips it") — and workItemsService.setImportedStatus guards the emit with if (dto.parentId). A parent-keyed debounce on work-item/derivation.requested resolves every time.

Written as instructed, the card would have installed a fresh unverified mechanism claim into the comment it was clearing of one. The generalisation is what did it: work-item/created has no resolvable parentId, …/requested is the neighbouring consumer in the same file, so "here too" reads as obviously true and is one grep from being false. That is the shape MOTIR-2998 already logged one level up — a mechanism asserted from a plausible reading rather than a measurement — reappearing in the card written to clean up after it.

Defect 2 — the sweep was scoped by a grep PATTERN, not by the CLAIM

The card reported: "git grep over origin/main finds the claim in exactly two files … statusDerivation.ts is the whole remaining surface." The pattern was DROPS RUNS|drops runs|fail to schedule. A fourth live site sits outside it, phrased differently:

lib/services/workItemsService.ts:1828
  // why the ordering has to be guaranteed by an event rather than by a
  // debounce window the runtime may not honour (the Inngest dev server does
  // not; measured on #2114).

Same claim, same substrate, same warrant role — in setImportedStatus, the method the whole mechanism is about. A pattern of literal phrases finds the sentences that were COPIED and misses the ones that were PARAPHRASED, and a warrant is exactly the kind of sentence people paraphrase when they restate it in a second place. The card then promoted the pattern's silence into a scope claim ("the whole remaining surface"), which is what made the miss invisible to the run: a runner who trusts that sentence never widens the search.

Both were caught by rung-2 verification during the run, not by any signal. validate_work_item returned valid: true with one advisory (MOTIR-2997, correctly a deliberate exclusion), readiness.ready: true, openBlockers: [].

The rule question

op-replan.md already carries a card that REDEFINES A MECHANISM owes a sweep of what it invalidated. MOTIR-3015 was that sweep, and it under-reached for a reason worth writing down: a sweep's scope is the CLAIM, and a grep pattern is a sample of it. A sweep that reports its pattern's result as a scope verdict ("exactly two files", "the whole remaining surface") converts an unknown into a settled fact for every later reader. Two candidate forms, for a corpus pass to pick between:

1. A sweep card states the pattern it ran, so the next reader can see what the pattern could not match — never "the whole remaining surface" off one pattern.
2. A claim sweep runs at least one pattern over the claim's MEANING (the mechanism's effect, the environment, the artefact it cites) as well as its wording — here, may not honou?r, honour(ing)? (an|the) option, queue item already exists.

Acceptance criteria

1. plan-rules/op-replan.md's mechanism-redefinition sweep corollary says what a sweep may and may not conclude from a grep pattern's silence, in the two-form choice above or a better one.
2. A notes.html mistake entry records both defects with this card's evidence, and is linked from the rule.
3. No product code changes — this is a corpus card.

Context refs

• MOTIR-3015 — the card, amended on the record in a comment; motir-core #2125 carries the fix for all four sites.
• MOTIR-2994 — the refutation whose sweep this was · MOTIR-2998 — the planning bug one level up, notes.html #311.
• lib/jobs/types.ts:456-460 · lib/services/workItemsService.ts:1817-1841 — the rung-2 evidence for defect 1.