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-2879Done

(motir-ai) Mirror W2/W3/W4 into `SHARED_PLANNING_RULES` — the measurement arrow, the cross-parent edge, and the story title as a checklist

Repo: motir-ai. One PR. The mirror half of the two-homes rule for the widenings filed by the motir run MOTIR-1465 sweep. blocked_by the motir-meta card, which carries the full evidence for every clause — read it there; this card deliberately does not restate the argument, so the two homes cannot drift into two different justifications for one rule.

plan-rules/SHARED_PLANNING_RULES is a pinned mirror: a boundary-CONTRACT pair, TWO coordinated PRs, not a straddle to re-plan (run.md guard #5, second check).

⚠️ CORRECTED 2026-08-17, read on origin/main before writing a line of it. This card was filed naming src/llm/treeGeneration.ts, which is where the constant used to live. It does not live there any more — that file only re-exports it (export { SHARED_PLANNING_RULES } from './planningRulePacks.js';). The citation was stale on the day it was written, which is the exact class this sweep spent the day correcting; recorded rather than silently fixed.

The mirror has been split into the SAME pack tree as plan-rules/. src/llm/planningRulePacks.ts (501 lines) holds ~32 named rule constants, each tagged with its pack in CORPUS_ORDER, and SHARED_PLANNING_RULES is now a DERIVED composition of all of them (CORPUS_ORDER.map(([, text]) => text).join('\n')), alongside PLANNING_RULE_PACKS, resolvePlanningRulePacks, composePlanningRules and legalPlanningRuleCells. So a widening is edited into a named CONSTANT, not appended to one blob, and it lands in the pack its plan-rules/ counterpart lands in.

The edit targets, verified on origin/main

clauseconstant in planningRulePacks.tsits packpresent?
W2 measurement limbDEPENDENCY_GRAPH_IS_THE_BUILD_SEQUENCEphase-skeleton✅ carries the REUSE / VERIFIABILITY / UI-COMPOSITION axes. VERIFIABILITY is the near neighbour and does not reach it: it wires a consumer to the card that PRODUCES the runtime output, not to the card that makes a MEASUREMENT trustworthy
W3 no-legal-lift limbDEPENDENCY_GRAPH_IS_THE_BUILD_SEQUENCEphase-skeleton✅ and the defect is mirrored in full: "Every blocked_by edge is between two SIBLINGS of the SAME KIND under the SAME PARENT (epic↔epic; story↔story under one epic; subtask↔subtask under one story). NO edge crosses a level or a parent — a cross-parent need is a dependency one level UP (lift it to where the two nodes are siblings)." That is the sentence with no legal move for MOTIR-2768MOTIR-2764, word for word, in the SHIPPED planner
W4 title as coverage checklistSTORY_LEVEL_JOURNEY_AUDIT (with COUNT_THE_VERIFICATION_RECIPE adjacent)kind-story
W4b enumeration SIZE axisAC_SATISFIABLE_INSIDE_THE_BOUNDARYphase-deepen✅ it already carries three axes — ACTOR, SURFACE, ORDERING — so W4b is a FOURTH axis on an existing enumeration, not a new rule
W5 QUANTITYA_CONTEXT_REF_THAT_EXPLAINS_IS_A_CLAIMphase-deepen✅ the paragraph is there in full, and its sibling limb THE_REF_HALF_OF_A_GREP_TARGET is mirrored at 1 980 characters — so the REF limb crossed and the QUANTITY limb has nothing to cross yet

The gap probe, run against a populated baseline so a zero means something (the MOTIR-2361 technique). blocked_by → 54 · deliverable → 38 · ONLY → 25 · enumerat → 19 · title → 17 · coverage → 11 · origin/main → 5 · CARDINALITY → 3 · git show → 2 · repeat-defect → 1 — against quantity 0 · projection 0 · denominator 0 · threshold 1. W5 is genuinely absent; every paragraph it extends is present.

⚠️ One placement mismatch to expect, not to fix here. The QUANTITY clause lands in plan-rules/core.md (gate 2 of the per-card checklist), while the mirror files the same rule under phase-deepen. The two homes already disagree about that rule's pack; carry the WORDS, keep the mirror's existing placement, and do not re-pack anything as a side effect.

What is mirrored, and what is NOT

clausehomemirrored here
W1 — guard #4 reads the whole advisories arrayprompts/run.mdNOrun.md is the build/serve runbook, which has no mirror. Do not go looking for it.
W2 — the dependency-arrow audit's MEASUREMENT limbplan-rules/phase-skeleton.mdyes
W3 — the blocked_by boundary rule's NO-LEGAL-LIFT limbplan-rules/phase-skeleton.mdyes
W4 — a container title is a coverage checklist at authoring time (+ W4b, the enumeration SIZE axis, if kept)the story-composition packyes
W5 — gate 2's QUANTITY clause: a threshold, share, count or projection may not be written into a criterion unless the measurement producing it was RUN, at the criterion's own scope, with the constants it depends on READplan-rules/core.md, via MOTIR-2702 (motir-meta PR #196)yes — added 2026-08-16; MOTIR-2702 named no mirror half, which is the gap the MOTIR-1465 sweep found. Its evidence is the four-instance family #257–#260, argued on MOTIR-2687

Acceptance criteria

  1. SHARED_PLANNING_RULES carries W2, W3, W4 and W5 in the same words as the motir-meta card's landed text — quoted from that PR's diff, not paraphrased from this card.
  2. W3's default-then-limb ORDER is preserved. The mirror must not read as though the cross-parent prohibition were repealed: lift first, wire the leaf edge only when lifting would create a cycle or block a container on work only one child needs.
  3. Any clause DROPPED from the motir-meta card during its review is dropped here too, and this card's body records which — a mirror that carries a rejected clause is worse than no mirror.
  4. A test in tests/planningRulePacks.test.ts asserts each mirrored clause's distinctive phrase is present, in the existing style of that file's rule assertions.
  5. Written defensively about merge order. Either PR may merge first; neither depends on the other's runtime behaviour.

Context refs

  • src/llm/planningRulePacks.ts — the rule constants, CORPUS_ORDER, and the derived SHARED_PLANNING_RULES. 501 lines but ~272 characters per line, so read it with python; a naive backtick scan also mis-terminates, because the rule text contains markdown code spans.
  • src/llm/treeGeneration.ts — the RE-EXPORT only. Nothing to edit here.
  • tests/planningRulePacks.test.ts — the per-rule assertions to copy (tests/treeGeneration.test.ts also exists and asserts gate 14's ORDERING phrase list; check both before adding a duplicate).
  • The motir-meta half and all evidence: the four widenings' card under MOTIR-1464.
  • The records the clauses come from, all children of MOTIR-1465: MOTIR-2791 and MOTIR-2863 (W2) · MOTIR-2848 and MOTIR-2831 (W3) · MOTIR-2798 and MOTIR-2844 (W4).