Skip to content

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
144
planned
1,362
shipped

Motir · Work items

MOTIR-3158Done

Planning bug: a card carried its OWN design as criterion 1 and the UI criteria that consume it as criteria 4–5 — the planning-time design gate has no detector, so a leaf can be its own design blocker

Type · planning defect (a RECORD — no repository deliverable; the fix ships as three sibling cards, below) Parent · MOTIR-1465, the planner-bug home Discovered in · motir run MOTIR-3154, 2026-08-19 — the run claimed the card, verified its every claim against origin/main, and could not build it. Re-scoped by · motir run MOTIR-3158, 2026-08-19, at guard #5 — see What this re-plan changed, last section.

What happened

MOTIR-3154 was sealed as a childless bug leaf carrying seven acceptance criteria. Criterion 1 requires a design/ai-planning/ three-file amendment — the accepted and declined node treatments, plus an explicit re-decision of what the plan-detail canvas pane holds after approve. Criteria 4 and 5 are the UI code built against that drawing. The card is its own design blocker, and nothing in the plan could see that.

Every mechanism read green: status: todo, readiness.ready: true with openBlockers: [], validate_work_item valid: true with one advisory the author had already disposed of correctly. claim_next_ready would have handed it out.

Why this is a distinct finding from MOTIR-3108

MOTIR-3108 records the fourth prose discharge of the estimation gate, and MOTIR-3154 is also a fifth instance of that — 8 SP / 240 min on a leaf, where plan-rules/kind-leaf-deepen.md says "8 already means split" and 240 minutes is the human-estimate tell. That instance is logged as a comment on MOTIR-3108, where the class lives. This card is the OTHER limb, and it is a different detector:

  • 3108's shape is a NUMBER over a threshold. A checker for it is arithmetic — compare storyPoints and estimateMinutes against the gate. It is now built: MOTIR-3110, likely-over-gate-sizing, done.
  • This shape is a COMPOSITION of criteria: one criterion produces a design asset, another consumes it as a UI surface, on the same card. No threshold sees it, and it survives at any size.

plan-rules/kind-leaf.md states the rule without exception — "Every UI-touching subtask you plan — type: code as much as type: design — MUST be linked, at PLAN time, to BOTH (a) the design asset AND (b) the type: design subtask that produced (or will produce) it." On such a card (b) resolves to the card itself, which is the degenerate reading the rule never anticipated, and Principle #13 (design before code, within every Story) is inverted: the code ships in the same commit as the drawing, approved by the same click.

Why the plan already knew, and still could not act

MOTIR-3154's own gate-9 repeat-defect disposition names the correct shape in plain language:

"Disposition (b): the re-shape is acceptance criterion 1 — the design amendment that draws this surface across its whole lifecycle — and it is this card's first child, with the code criteria behind it."

It had no children. This is plan-rules/kind-leaf.md's "a card that declares its own split in prose has not split — THE SENTENCE IS THE SPLIT INSTRUCTION" landing on the design axis rather than the repo axis. The remedy was written into the one field no mechanism reads.

And the precedent was one card away: MOTIR-3070, the preceding bug on the same surface, cited by MOTIR-3154 in its own body, was expanded into exactly this shape — MOTIR-3082 (design) blocks MOTIR-3083 and MOTIR-3084, all three done. The author read that card and reproduced its prose, not its structure.

The cost, and why it is not hypothetical

Had the run built it, the design amendment and the four files written to match it would have arrived in one pull request. Half of that design re-opens a shipped decision — Story MOTIR-1775 / MOTIR-1782 deliberately decided the establish step should take the canvas pane after approve, and the shipped prop doc says so in its own words. Reviewing that re-decision in the same diff as its consequences is not a review of it.

THE DECISION THIS CARD OWED — likely-self-blocking-design is an ADVISORY, not a blocker (2026-08-19)

Recorded here, as the card's own deliverable. Non-blocking, kind: "shape", exactly like likely-repo-straddle. Five reasons, and the first is dispositive on its own:

  1. The shape family is non-blocking by construction, and that is load-bearing. All three shipped members — likely-ordering-violation, likely-repo-straddle, likely-over-gate-sizing — leave valid and blockers untouched, and validate_work_item's own contract says advisories "never affect valid or blockers". A single blocking member would split that contract and force every consumer (the MCP tool, the /api/v1 work-loop schema, the CLI client, claim_next_ready) to branch on severity.
  2. The predicate is lexical over criterion prose, so it has a real false-positive class. A design card whose criteria also name its own .png export or the area's design-notes.md; a card that amends an existing asset and adjusts the one rendered surface that reads it. Blocking would hold those out of the ready set, and the advisory channel has no exemption mechanism to release them.
  3. A card mid-re-plan must stay claimable — and a card that is its own design blocker is precisely the card a re-plan is in the middle of splitting.
  4. Where the enforcement needs to bite, it already does, and it is not this. run.md guard #3 PAUSES a run about to build UI with no drawing. This advisory's job is to make the composition VISIBLE at the two moments a person can act cheaply — when the author seals the card, and when a run claims it — not to be a second, weaker copy of guard #3.
  5. likely-repo-straddle is the closest sibling by construction — it reads criteria and returns a 1-based index to cut at — and it is advisory. This card's original Fix-direction paragraph already argued the same.

The remedy — THREE cards, one per repository

The fix has a product-code half and a planning-rule half, and the rule half has two homes. run.md: "A defect with both halves is two cards, not one card filed twice." Proposed on plan cmt0nyykx00s1i3phklcyax8h:

cardrepoparentpts / min
1validate_work_item gains a likely-self-blocking-design shape advisory + the fixturemotir-coreMOTIR-2200, beside MOTIR-31105 / 60
2the design gate's NON-SELF limb in plan-rules/kind-leaf.mdmotir-metaMOTIR-14642 / 30
3the mirror into THE_DESIGN_GATE / SHARED_PLANNING_RULES, blocked_by (2)motir-aiMOTIR-14641 / 25

The detector is independent of the prose; either may land first. Card 3 is a scope ADDITION this card did not originally name — the two-homes rule, argued on the plan.

This card holds none of them up and consumes nothing they produce, which is why it carries no blocked_by edge to any of them: a planner-bug record is telemetry about the planner, the correction is already applied by the time it is filed, and nobody scheduled it.

Acceptance criteria

  • The decision is recorded on this card: advisory or blocking, with the reason. DONETHE DECISION THIS CARD OWED, above: advisory, five reasons.
  • If advisory: validate_work_item emits a shape advisory…card 1 (motir-core).
  • The rule's text in plan-rules/kind-leaf.md gains the degenerate reading explicitly…card 2 (motir-meta), mirrored by card 3 (motir-ai).
  • run.md's guard #4 advisory block reads the new advisory at DISPATCH time. ALREADY TRUE — no card. See What this re-plan changed.
  • A test fixture reproduces MOTIR-3154's criteria set as authored on 2026-08-19card 1, amended to a labelled RECONSTRUCTION. See What this re-plan changed.

What remains on this card: nothing to build. It is the durable account of the defect, the decision, and where the three halves went.

What this re-plan changed (2026-08-19, motir run MOTIR-3158, guard #5)

Why the run stopped. This card's opening line reads "a record; no repository deliverable, which is why no targetRepo is pinned" — and its criteria then named four repository deliverables in TWO repositories. plan-rules/core.md gate 1: "go criterion by criterion and name the repo each one is discharged in; two repos in that column is a split, however the sentence is punctuated." A childless leaf is one worktree and one PR; it physically cannot ship in two repos, and picking one at run time is a forbidden per-repo scope decision.

Two criteria were amended on the record rather than carried into a card:

  1. The run.md guard-#4 criterion is already satisfied. MOTIR-2878's W1 merged as ab9dac8 and widened guard #4 to read the WHOLE advisories array, every family and every severity: "THE FAMILY LIST IS NOT THE TEST — the QUESTION is… An entry whose family you do not recognise is disposed of on that question and named in the report — never skipped for being off a list." A new advisory is therefore read at dispatch for free, and adding a fourth name to that paragraph's example list would work against the paragraph's own instruction — the same block warns that "writing prose to duplicate a check that already runs is the exact inversion notes.html #219 records." Nothing to build.
  2. The fixture criterion's substrate no longer exists. It asked for MOTIR-3154's criteria "as authored on 2026-08-19 — the seven-criterion leaf". get_work_item_activity on MOTIR-3154 records {kind: 'fieldEdited', field: 'descriptionMd'} at 2026-08-19T20:53:52.716Z, with storyPoints 8 → none and estimateMinutes 240 → none — its re-plan's modify, materialized fifteen minutes after this card was created (20:38:38.338Z). The tenant retains no prior descriptionMd; activity parts carry from/to for status, priority and links only. notes.html #329 and the motir run MOTIR-3154 comment both PARAPHRASE criteria 1 / 4 / 5 — neither quotes the set. Card 1 therefore carries a labelled RECONSTRUCTION table and is the fixture's durable source. A criterion authored against a body that its own sibling re-plan was about to overwrite is worth noticing in its own right; it is filed as its own planning bug.

Nothing was archived. This card survives, amended in place, which is the correct treatment for a record.

Advisory disposition (validate_work_item, re-run at re-plan time — MOTIR-2899)

valid: true, blockers: [], three advisories, all disposed:

  • MOTIR-3154 (in_progress, likely-missing-edge) → relates_to only, deliberately, and MORE so after the re-plan. It is the card this defect was found ON. This card now consumes nothing from it at all: the fixture's source moved onto card 1 as a reconstruction precisely BECAUSE MOTIR-3154's body is not a stable artifact. The detector is independent of whether that card is ever built.
  • MOTIR-3108 (todo, advisory) → no edge, deliberately. The sibling limb of the same run's finding, recorded there as its fifth instance. Different detector (a threshold vs a criteria composition); either may land first, and neither reads the other's output.
  • MOTIR-3130 (todo, advisory) → no edge — the reference was a MISLINK, corrected at filing. This card never meant to name MOTIR-3130; two of its MOTIR-3108 links carried MOTIR-3130's cuid, so the scanner read a reference that was never intended. (Worth noting as a hazard in its own right: a motir:<cuid> link renders the linked item's key, so a wrong cuid is invisible in the rendered body and surfaces only as an advisory naming a card you never mentioned.)

MOTIR-2878 stays wired as blocked_by and is done — the keep-the-edge rule: it re-gates correctly if a human ever re-opens that card.

Context refs

  • Plan cmt0nyykx00s1i3phklcyax8h — the three-card split, with the full guard-#5 reasoning.
  • MOTIR-3154 — the card the defect was found on. Its body has been re-scoped since; notes.html #329 is the durable account of what it said.
  • MOTIR-3108MOTIR-3110 (done) — the sibling limb of this finding, and the record→build-card split this re-plan reproduces.
  • MOTIR-2878MOTIR-2879 — the (motir-meta)(motir-ai) pairing cards 2 and 3 follow.
  • MOTIR-3070MOTIR-3082 / MOTIR-3083 / MOTIR-3084 — the correct shape, one card away, on the same surface.
  • plan-rules/kind-leaf.md — the planning-time design gate ("no exceptions") and the prose-split-not-performed rule.
  • plan-rules/core.md gate 1 — the criterion-by-criterion method, on the repo axis, that this detector generalises to the design axis, and the gate that caught this card.
  • run.md guard #3 (the design gate) · guard #4 (the advisory block, widened by W1) · guard #5 (the one-repo-per-subtask gate that fired here).