Planning bug: MOTIR-2872's real blocker was wired `relates_to`, and its advisory landed in the tier guard #4 tells you to skip

Filed by the motir run MOTIR-2872 that could not start (2026-08-16). The correction is already applied — this card is telemetry, not scheduled work.

The defect

MOTIR-2872 re-measures and partitions the third class of MOTIR-2862's 2026-08-15 partition. Every one of its five acceptance criteria writes on top of that partition:

• AC 1 appends "a dated section" to docs/rls-runtime-role-inventory.md, immediately after the section MOTIR-2862 adds.
• AC 2 states "the before/after count for MOTIR-2865's class and MOTIR-2871's class by name" — the before numbers (166, 240) and the class names are defined in MOTIR-2862's section.
• AC 4 files "one create_work_item per class", extending MOTIR-2862's own "Cards filed from this partition" ledger.

MOTIR-2862 is in_review, not merged. Verified on origin/main @ 923366e9:

The edge owed was blocked_by. What the plan carried was relates_to — a reference, which gates nothing. So readiness returned ready: true with openBlockers: [], and validate_work_item returned valid: true, on a card whose deliverable cannot be written.

The two edges the card did carry (blocked_by MOTIR-2865, MOTIR-2871) were both satisfied — both merged, at 1ce054ff and 8d9acbf2. The card's own step 1 gate ("after both predecessors have MERGED") was therefore met, which is precisely why nothing else looked wrong.

Why this instance is not MOTIR-2831 or MOTIR-2848

Same family (MOTIR-2075 → MOTIR-2433 → MOTIR-2831 → MOTIR-2848), different failure point — and this one indicts a sentence in the runbook rather than an author:

• MOTIR-2831 — eight likely-missing-edge advisories fired and no step consumed them. A consumption failure.
• MOTIR-2848 — validate_work_item returned an empty advisories array. A detection failure.
• Here the advisory fired, correctly, and at the tier the runbook filters out. A triage-routing failure.

validate_work_item MOTIR-2872 returned:

MOTIR-2734 → likely-missing-edge   (referenced in AC 5)
MOTIR-2862 → advisory              (the real blocker)
MOTIR-2864 → advisory

run.md guard #4's advisory block instructs: "For every likely-missing-edge, git ls-tree / git grep origin/main for the file, symbol or test the criterion names." Followed literally, that check runs on MOTIR-2734 — which is blocked and downstream — and never runs on MOTIR-2862, the one reference that was actually unbuildable.

The severity split is working exactly as documented (likely-missing-edge == the reference sits inside the acceptance criteria). The hole is structural: MOTIR-2872's ACs name only its two satisfied predecessors, while the unmerged dependency it appends to is named in the description prose and Context refs. A card can therefore have its true blocker sorted into the lower bucket because its ACs are written about the work rather than about the substrate.

Correction applied by this run

• link_work_items MOTIR-2872 blocked_by MOTIR-2862 — the edge the authoring pass owed.
• transition_status MOTIR-2872 → Blocked (todo → blocked).
• No branch cut, no worktree, no measurement run. Per guard #4: did not branch off origin/main to rebuild MOTIR-2862's half, and did not stack onto the unmerged branch.

Residual — a rule question this card does NOT settle

Whether run.md guard #4's triage sentence should widen from "for every likely-missing-edge" to "for every advisory whose referenced item is not done". Argument for: the severity tier is a hint about where the reference appears, not about whether the substrate exists, and only the latter is what the guard is checking. Argument against: one occurrence, and the widening costs a git ls-tree per advisory. Left open deliberately — see notes.html and the two-homes rule before promoting.