Planning bug: two stories in different epics planned the SAME deliverable (`@motir/design-system`) two days apart, with no edge — MOTIR-1524 shipped it and MOTIR-1456 stayed claimable for eight weeks
Filed by motir run MOTIR-1456 (2026-08-27), which claimed the card, verified its criteria against origin/main and the public npm registry, and halted at guard #4 having built nothing. The correction is already applied to the plan — plan cmtc2ebe6007thvn8asc35vhl, awaiting review — so this card holds nothing up and joins no sprint.
The defect
MOTIR-1456 (8.3.11, under Story MOTIR-656 / Epic 8) was authored 2026-06-30: "Shared design-system package — extract motir-core tokens + primitives for cross-repo reuse."
MOTIR-1524 (under Epic 7) was authored 2026-07-02 — two days later — with the title "Package the 3-axis design system as @motir/design-system." Same artifact, same package name, same extraction.
Neither card references the other. No blocked_by, no relates_to, no mention in either body. MOTIR-1524's subtree ran to completion (MOTIR-1525 → 1526 → 1527 → 1535 / 1536 / 1537 → 1528 → 1530, plus bug 1538 and cleanup 1546 — all done) and published @motir/design-system@0.1.0 to public npm on 2026-07-02T22:14:57Z. MOTIR-1456 was never touched by any of it, and no field on it changed. Eight weeks later it still read todo · ready: true · openBlockers: [] · valid: true, with two of its three acceptance criteria already satisfied on main.
Why nothing caught it
- The reference detector had nothing to key on. MOTIR-1456 cites its dependencies as
[[wiki-links]]into the auto-memory corpus and as prose — "blocks 8.3.6" — never asMOTIR-<n>.validate_work_item'sreferencefamily scans forMOTIR-<n>, so it returned noreferenceadvisory for this card at all. This is the authoring half of the gap: cite a sibling by its id, never by description (plan-rules/phase-skeleton.md). - The
subsumptionadvisory fired on the wrong PR. It returnedapp/globals.csstouched by#2305(MOTIR-3440, a streaming sweep) — true, and irrelevant. The PRs that actually subsumed the card,#1484(MOTIR-1526) and#1490(MOTIR-1527), were not surfaced. A path-level most-recent-PR match is structurally poor at pointing to the merge that delivered your card's scope. - Cross-epic duplicates are never adjacent. Both stories were reasonable in their own subtree — 8.3 needed a shared package so motir-marketing could stay on-brand; Epic 7 needed one so the scaffold agent could apply a stored
designChoice. No sibling glance, parent-scoped read, or board column connects a card under Epic 8 to a card under Epic 7. Only a project-wide search for the DELIVERABLE finds it, and neither authoring pass ran one.
Cost
One motir run session spent on verification instead of building; the card and the whole 8.3 marketing-landing chain behind it (MOTIR-1152 → MOTIR-1154) carried a stale premise for eight weeks. No wrong code shipped — the run halted before opening a worktree. Had it not, it would have re-extracted a package that already exists and re-published a name already taken.
What is genuinely left
Not nothing: the brand chrome (components/brand/BrandMark.tsx, components/brand/waveBand.ts, the .brand-* block in app/globals.css) is absent from the package, and whether Motir's trademark may ship inside a GPL-3.0 package that every scaffolded third-party product installs is undecided. That is the decision card the submitted plan adds beside MOTIR-1456 — a separate finding, not this bug.
Acceptance criteria
- The authoring half is closed for this shape: a card whose acceptance criteria name a shared, named artifact (a package, a module, a service) cites the card that owns that artifact by
MOTIR-<n>, so the reference detector can see it. Land it as a rule in theplan-rules/pack that owns citation-by-id, or show that the existing rule already says it and the gap was that nobody applied it — either outcome is an acceptable close, stated with the evidence. - The detection half is assessed, not necessarily built: state whether
validate_work_itemcan reasonably flag "another card's title names the same artifact yours does", and if it can, file the card; if it cannot, say why in the close-out so the next occurrence is not re-litigated. - The close-out names the merged PRs that subsumed MOTIR-1456 (
#1484,#1490) and the reason thesubsumptionadvisory did not.
Context refs
- MOTIR-1456 (
relates_to) — the card that stalled · MOTIR-1524 and its subtree — the story that delivered it motir-meta/prompts/plan-rules/phase-skeleton.md— cite a sibling by id, not by descriptionmotir-meta/prompts/run.md— guard #4's emptyadvisoriesarray is not a prior-art verdict block, which is what this run followedmotir-core/lib/services/—validate_work_item'sreferenceandsubsumptionadvisory families