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
145
planned
1,361
shipped

Motir · Work items

MOTIR-4135To Do

Planning bug: gate 14(c)'s ORDERING signal is an ENUMERATION of four phrases, and "measured after the change" is not one of them — MOTIR-4095 sealed a post-merge criterion with `advisories: []`

Type · planning defect (rule text). Parent · MOTIR-1465, the planner-bug home. Discovered in · MOTIR-4095, during its own motir run on 2026-09-01.

What happened

MOTIR-4095's acceptance criterion 3 read:

"Measured after the change on a real merge burst of ≥3 back-to-back merges: every merge's sha has an Acceptance video push run … Record the run ids and shas in an add_comment on this card."

A workflow's concurrency.group expression is read from the workflow file at the pushed commit, so that measurement is only possible after the card's own pull request merges — at which point the status sync flips the card done and nobody ever takes it. The run had to cut the criterion and propose a verification card for it (plan cmtj63yxb0125hvphq93tb1la).

Root cause — the gate exists, is correct, and its SIGNAL is an enumeration

plan-rules/core.md gate 14(c) ORDERING is exactly the right gate and its instruction is exactly right:

"does the criterion read on state that exists only AFTER this card's own PR has merged? … Its signal is purely lexical too: "merged to main", "once this lands", "after release", "on main" — and EVERY criterion at or below the first line carrying one belongs to a different card."

AC 3 carries none of those four phrases. It says "after the change" — a fifth family ("after this ships", "once the new expression is live", "on a real merge burst") that names the same moment in the vocabulary of the DIFF rather than of the BRANCH. A gate whose signal is declared purely lexical and then enumerated is read as a membership test, and this criterion is not a member.

Nothing downstream caught it either, and both were behaving correctly:

  • validate_work_item MOTIR-4095{"valid": true, "blockers": [], "advisories": []}. The shipped likely-ordering-violation detector matches phrases, so it inherits the same list.
  • readinessready: true, openBlockers: []. Gate 14(d) is the reason: the card's real precondition is its own merge, which is not a work item and has no edge to be missing.

This is the same shape the corpus already names in the artifact-obtainable check — "THE LIST ABOVE IS NOT THE TEST — the QUESTION is … if a second class ever turns out to be missing from the list, delete the list rather than extend it again" — arriving at gate 14(c), which does not carry that instruction.

Fix direction

Do not add a fifth phrase. Restate 14(c)'s signal as the QUESTION with the phrases demoted to examples, on the artifact-obtainable check's own precedent, and say the discriminator out loud: does the criterion name a moment that can only arrive after this card's diff is on the default branch? — which reaches "after the change", "once this ships", "in the next release" and the next phrasing nobody has thought of.

Two homes, and both are owed ([[planning-rule-has-two-homes]]): the pack text in motir-meta prompts/plan-rules/core.md, and its mirror in motir-ai SHARED_PLANNING_RULES. A rule changed in one home only is a rule the shipped planner and the runbook disagree about.

Consider whether the shipped detector follows. likely-ordering-violation returns a criterion index, so it needs some matcher; widening its phrase set is a smaller, separate question from the rule text and should be decided on its own evidence rather than assumed.

Acceptance criteria

  1. plan-rules/core.md gate 14(c) states its signal as a QUESTION, with the four phrases explicitly labelled examples rather than the test, and carries the delete-the-list-rather-than-extend-it instruction the artifact-obtainable check already carries.
  2. The same change lands in motir-ai's SHARED_PLANNING_RULES mirror of that rule, so the two homes do not disagree.
  3. The new text is checked against this card's own fixture: applied to "Measured after the change on a real merge burst", it fires.
  4. Whether likely-ordering-violation's matcher is widened is answered on the card — either changed, or stated as deliberately unchanged with the reason.

Resolution

Open.