Planning bug: the `validate_work_item` post-condition is bound to a PLAN PASS, so no card created mid-run is ever checked by the mechanism built to catch exactly this — MOTIR-2011's family, ×7

Repo: motir-meta. One PR. Filed by the motir run MOTIR-2887 that could not start (2026-08-17). The plan correction is already applied; what this card changes is a post-condition.

The instance

MOTIR-2887 was created mid-run by the motir run MOTIR-2880 session, under notes.html #27. Its acceptance criteria then consume, by name, four things that exist only on MOTIR-2880's open PR #2073 — tests/rls/systemContextScan.ts, system-context-arm-guard.test.ts, that card's docs/rls-runtime-role-inventory.md entry, and a 26-failure baseline that is the residual after #2073's eleven sites land. The edge owed was blocked_by; what the card carried was relates_to. So readiness returned ready: true with openBlockers: [], and the card sat todo + high where claim_next_ready was entitled to take it.

First conclusion, and why it was wrong

The obvious reading is that log-bug.md step 4 asks only "does the new bug BLOCK the run?" and never the mirror, "does it CONSUME what the run has not merged?" — so widen step 4. That is the wrong card, and MOTIR-2280 is the precedent for refusing it. The governing sentence already exists, is already sharp, and already covers this case verbatim — plan-rules/core.md gate 4:

And the commonest case by far is NOT absence — it is a precondition that already HAS a card which simply is not done yet. Then the edge is blocked_by, NEVER relates_to. … The DISCHARGE is mechanical: resolve every work-item chip in the body to its STATUS before sealing — not done ⇒ blocked_by. … an AC that names a not-done card is a missing blocked_by until proven otherwise.

Warrant: MOTIR-2011 · 2026-08-01 · ×6

Its fixture even records the same-session sub-case: "MOTIR-2011's body named MOTIR-2007 three times … and was authored ONE MINUTE after it by the same session." And log-bug.md step 3 already routes there — "⚠️ A bug logged mid-run is a card — seal it under the per-card gate checklist in plan-rules/core.md" — which is MOTIR-2179, already done. So this is a diligence miss against a rule that exists, is cited on the path that created the card, and has been reworded enough. It is the seventh instance.

The actual gap — a post-condition bound to the wrong scope

CORPUS-MAINTENANCE.md's THIRD TIER decision (2026-08-05, MOTIR-2164's family, notes.html #225) settles what to do here: "when a check's own design premise is that it needs no judgement — a phrase list, a column, a count — the remedy for it not firing is to MECHANIZE it, never to sharpen it." Gate 4's discharge is exactly that shape: resolve each chip to its status, compare to done. No judgement.

And it is already mechanized, in shipped code. validate_work_item's advisories array names every card the description references without a blocked_by edge, at severity likely-missing-edge when the reference sits inside the acceptance criteria. On MOTIR-2887 it returned exactly the right answer:

MOTIR-2880 → likely-missing-edge
MOTIR-2882 → advisory

Nobody called it until dispatch. grep -rn validate_work_item prompts/:

A card created by log-bug.md step 3, by run.md guard #4 step 1, or by guard #5's per-repo split is not created inside a plan pass, so the one mandatory call never fires on it. MOTIR-2179 carried the checklist citation across to those paths and stopped there; the validate post-condition was never carried with it. The result is that the mechanism built to answer this question is consulted only by whoever tries to run the card — which is why every instance of this family is caught at dispatch, by a guard, after the card has already been sealed, ranked and made claimable.

That is the whole finding: the answer was one MCP call away from the author, and the author was never told to make it.

What to do

Add the post-condition to the paths that CREATE a card outside a plan pass, in the same mechanical form plan-procedure.md already uses for plan passes: after sealing, call validate_work_item on the new card (or its parent) and resolve every advisory before moving on — a reference advisory naming a not-done item is a blocked_by to wire, not a note to leave.

Acceptance criteria

• prompts/log-bug.md step 3's sealing block gains the post-condition: after create_work_item + the explanationMd follow-up, call validate_work_item on the new card and dispose of every advisories entry — wire the blocked_by where the referenced item is not done, or say per entry why it is not consumed.
• prompts/run.md guard #4 step 1 and guard #5's per-repo children carry the same post-condition, worded identically, so the three create-outside-a-plan-pass paths do not drift.
• Each site states that the disposition covers every advisory entry, both families (reference and shape) — not only likely-missing-edge. This is the create-time half of MOTIR-2878's W1, which widens the same read at DISPATCH time; say so at both sites so the two are not mistaken for one edit.
• plan-rules/core.md gate 4's warrant count goes ×6 → ×7, citing MOTIR-2887. No line is added to core.md — its 620-line cap is contested by MOTIR-2898 and this change is a single character.
• notes.html carries the lesson with its prompt-hint, count bumped, and states explicitly that the widening this run first reached for — a mirror arm on log-bug.md step 4 — was rejected, with MOTIR-2280's diligence-vs-totality discriminator as the reason. A rejected widening that is not recorded gets re-proposed.
• The PR body states whether SHARED_PLANNING_RULES needs a mirror. Expected answer: no — this is a command-file PROCEDURE post-condition, not a planning RULE, and motir-ai's create path is log_planning_bug / aiWorkItemsService.fileBug rather than a prompt. Verify rather than assert; if the hosted filer seals a card without validating it, that is a motir-ai card to file, not a clause to add here.

Context refs

• prompts/plan-rules/core.md gate 4 — the governing rule and its MOTIR-2011 ×6 warrant.
• prompts/plan-rules/fixtures/core.md#precondition-blocked-by-not-relates-to — P4.2 / P4.3, including the same-session sub-case.
• prompts/plan-procedure.md §"THEN VALIDATE THE PLAN TARGET" — the post-condition to copy, and the scope word that excludes these paths.
• prompts/log-bug.md step 3 — the sealing block; step 4 is the one this card decided NOT to widen.
• prompts/run.md guard #4 (advisory block, and step 1's create_work_item) and guard #5.
• prompts/plan-rules/CORPUS-MAINTENANCE.md §THE THIRD TIER — mechanize, do not re-word.