Planning bug: a dedup wrote its blocker's new position in PROSE and left the card parented in a LATER epic — a permanent deadlock that `validate_work_item` reported and nothing read

A RECORD card. Filed 2026-08-17, after the user reported "2896 and 1167 are invalid — they will never be ready in epic 8." The plan defect is already REPAIRED (see § The repair); this card exists so the instance is logged and so the rule half is not double-counted.

What happened

The motir run MOTIR-2582 dedup on 2026-08-17 settled that the platform-staff gate is owned by Story 8.5 (launch readiness), created MOTIR-2896 as its single owner, and correctly carried over the blocker the losing card had been gated by — MOTIR-729, the keystone platform-staff ADR. It then wrote, on three separate cards, that the ADR had "moved ahead of launch readiness" and "must be sprinted WITH Story 8.5's slice, ahead of Sprint 41."

It never moved it. MOTIR-729 stayed 10.1.2, a subtask of Story 10.1 under Epic 10, in Sprint 41. Two defects followed from that one omission:

1. A cross-parent subtask edge. MOTIR-2896 (Story 8.5) blocked_by MOTIR-729 (Story 10.1) — every blocked_by joins siblings of the same kind under the SAME parent, and a need crossing epics is an epic-level edge.
2. A permanent DEADLOCK, which is the part that matters. Epic 10 is blocked_by Epic 8 (and Epic 9). Readiness cascades through the parent, so an Epic-8 card gated on an Epic-10 card can never become ready: MOTIR-2896 and MOTIR-1167 were permanently unready, and Story 8.5 — launch readiness, in_progress, high — could never finish. The same run also left MOTIR-730 blocked_by MOTIR-2896, the mirror cross-parent edge in the other direction.

The detector fired and nobody read it. validate_work_item("MOTIR-658") returned valid: false with exactly one blocker — MOTIR-2896 ← MOTIR-729 — from the moment the taker was created. That is MOTIR-2899's family (the post-condition is bound to a plan pass, so nothing validates a card created mid-run) and is not re-litigated here.

The repair (done 2026-08-17 — no work owed on the plan)

• MOTIR-729 move_to_parent Story 10.1 → Story 8.5, renumbered 10.1.2 → 8.5.17, moved out of Sprint 41 into the backlog with the rest of 8.5's slice. Its content is untouched.
• MOTIR-730's two blocked_by edges (onto MOTIR-729 and MOTIR-2896) removed and re-made as relates_to — the need is carried by the pre-existing epic-level edge Epic 10 blocked_by Epic 8, which already subsumed both. MOTIR-730 blocked → todo (still held by its ancestor).
• Referrers swept: MOTIR-729, MOTIR-2896, MOTIR-1167, MOTIR-730 — every 10.1.2 label, every "currently in Sprint 41" clause, and the prose that described the move as already-made.
• Post-state: validate_work_item("MOTIR-658") → valid: true; validate_work_item("MOTIR-727") → valid: true. Build chain, wholly inside Story 8.5: MOTIR-729 → MOTIR-2896 → MOTIR-1167.

The rule half — ONE clause, and it lands on an EXISTING card

Family count: ONE. Do not open a new motir-meta card. MOTIR-2913 (W5, todo, unrun) already edits plan-rules/op-replan.md limb (2) with the warrant "a taker inherits the loser's BLOCKERS, not only its scope." Its drafted text is what this instance falsifies, so the clause belongs there and nowhere else — posted as a comment on MOTIR-2913 on 2026-08-17.

Why the drafted widening was not enough — this is the finding. W5 tells the planner to DIFF the two cards' blocker sets and notice the odd one out. The pass did notice it. It wired the edge and wrote three paragraphs about its consequences. What it never did was ask where the inherited blocker now LIVES — so W5 as written would have produced exactly the plan that shipped. The missing sentence: an inherited blocker is a RE-FILE, not an edge — for each one, re-file it under the taker's parent or lift the need to the level where the two are siblings, and check the direction first, because when the blocker's ancestor is blocked_by the taker's ancestor, lifting is a cycle and leaving it is a deadlock. The lexical tell: a dedup that states a card's new position in prose without a move_to_parent.

Overlaps MOTIR-2878's W3 (the cross-parent edge) by SUBJECT but not by FILE — W3 lands in phase-skeleton.md, this in op-replan.md. Cross-refer, do not restate, and do not count them as two.

Acceptance criteria

• This card is a RECORD: it closes when MOTIR-2913 has landed its limb text including the re-file sentence — verified by git show origin/main:prompts/plan-rules/op-replan.md containing both the union clause and a sentence requiring the inherited blocker to be re-filed or lifted. No separate PR is owed by this card.
• The family count stated above is ONE; if a later reader is tempted to open a second motir-meta card for the cross-parent half, MOTIR-2878's W3 is the reason not to.
• No plan mutation is owed — the repair above is complete, and both validate_work_item verdicts quoted are re-runnable as the check.

Context refs

• MOTIR-2913 — the widening this finding amends; the clause is in its comments.
• MOTIR-2582 — the dedup that made the mistake. MOTIR-2897 — its record card, which caught the scope half and produced W5.
• MOTIR-2899 — why nothing validated the tree after the taker was created.
• MOTIR-2878 W3 — the cross-parent-edge widening, same subject, different file.
• prompts/plan-rules/phase-skeleton.md § "Never reach across a parent to sequence" + the three valid fixes (lift / re-file / split) — the rule that was already written and that the repair applied.