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 · Roadmap

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: []`

Opened by Zhu Yue ·

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.

Discussion

No comments yet.

Adding to this discussion signs you in on app.motir.co and brings you back to this request.

Add a comment