MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-3723

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

Done
Description

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

  1. 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 as MOTIR-<n>. validate_work_item's reference family scans for MOTIR-<n>, so it returned no reference advisory 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).
  2. The subsumption advisory fired on the wrong PR. It returned app/globals.css touched 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.
  3. 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-1152MOTIR-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 the plan-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_item can 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 the subsumption advisory 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 description
  • motir-meta/prompts/run.md — guard #4's empty advisories array is not a prior-art verdict block, which is what this run followed
  • motir-core/lib/services/validate_work_item's reference and subsumption advisory families