Skip to content
Motir
Start free

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
Follow  — continues on app.motir.co
Request a featureAtom feed

← Motir · Work items

MOTIR-3076Done

Planning bug: a card said its mechanism must be MEASURED and then made one hypothesis an acceptance criterion

MOTIR-3066 did the hard half of notes.html #306 correctly and then undid it in the half that binds.

Repo: motir-meta (stated here rather than pinned — motir-meta is not one of this project's connected repositories, so targetRepo cannot carry it).

What it got right

Its prose is explicit that the mechanism is the first deliverable: "Deciding which is the first deliverable; a fix written before that is a guess." That is exactly the remedy #306 prescribes, and most defect cards skip it.

What it got wrong

Acceptance criterion 4 reads:

No truncate helper acquires the shared tables in an order different from any other, asserted rather than reviewed.

That is a REPAIR, it is criterion-shaped and checkable, and it is owed only if the deadlock turns out to be truncate-vs-truncate. Criterion 1 says that question is open. So the card simultaneously demands a measurement and gates shipping on one of its possible answers.

The measurement (MOTIR-3066's PR) refuted the premise. Postgres named both transactions: the other side of the deadlock was an ordinary bound SELECT, whose lock order comes from the QUERY PLAN. No convention among truncate helpers can constrain a query plan, so criterion 4 could never have been the fix. The real cause was an abandoned Promise.all arm in workItemsService.getQuickView — a product bug, in the same test file, one test earlier.

Criterion 4 was still worth satisfying (two files were out of step and are now aligned, with a guard). A criterion can be worth doing and still be wrong about why — which is what makes this hard to see on review.

The correction, and where it lives

plan-rules/kind-bug.md already carries the repeat-defect trigger; #306's lesson lives in notes.html and has no RULES-tier form. The gap is a per-criterion check at authoring time, so it belongs with the other per-card gates.

Acceptance criteria

  1. plan-rules/kind-bug.md (or plan-rules/core.md's gate checklist, whichever the author judges the right altitude) carries a check of the form: when a card states that its mechanism is unknown and must be measured, no acceptance criterion may name a repair that only one candidate mechanism implies. The check is stated as a question an author asks of each criterion in turn — "is this owed under every hypothesis I listed?" — not as prose commentary.
  2. The rule says what to DO with a criterion that fails the question: move it to a follow-up card, or keep it under an explicit "defensive, whatever the cause" label that does not gate shipping. Both dispositions are named; "drop it" is not one of them.
  3. The rule cites MOTIR-3066 as its fixture, including the detail that the failing criterion was nonetheless worth satisfying — the trap is a criterion that is useful AND mis-motivated, not a useless one.
  4. notes.html mistake #319 is referenced, not restated (the LESSON tier already holds the narrative; this is the RULES-tier form of it).

Context refs

  • motir-meta/notes.html #319 — the lesson this card is the rule-tier half of.
  • motir-meta/notes.html #306 — the prior entry, whose prompt hint this card's fixture obeyed in prose and violated in criteria.
  • motir-meta/prompts/plan-rules/kind-bug.md · plan-rules/core.md — the two candidate homes.
  • MOTIR-3066 — the fixture.