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
145
planned
1,361
shipped
Follow  — continues on app.motir.co
Request a featureAtom feed

← Motir · Work items

MOTIR-2142Done

(motir-ai) MIRROR the claim-vs-pointer gate into `SHARED_PLANNING_RULES` — a code fact a card asserts must have been grepped on origin/main

A standing planning RULE has TWO homes and only one of them has been written. MOTIR-2095 added the claim-vs-pointer gate to motir-meta/prompts/plan-rules.md (the manual planner, PR #114). This card lifts the same rule into SHARED_PLANNING_RULES so the SHIPPED planner learns it too — the same two-homes shape MOTIR-2089 executed for the previous pair of rules.

The rule being mirrored

A card may not assert a code fact — a policy branch, a helper, an exported symbol, a column, a route, an enum value, a config key — as EXISTING unless it was grepped on origin/main at authoring time. The tell is lexical and lives in the card's ## Context refs: a line that EXPLAINS what a file contains rather than POINTING at where to look. Only an explanation can be wrong, and an annotated file:path is exactly what a discharged precondition check looks like — so a fact written from memory inherits that credibility and passes every other gate. Ungrepped ⇒ demote to a bare pointer, or phrase the criterion as an obligation ("add X if absent"). Fixture: a context ref named an RLS system-admin branch that did not exist; a job built to it would have scanned zero rows and repaired nothing, green.

What to do

  1. Read the landed block in motir-meta/prompts/plan-rules.md (the A CONTEXT REF THAT EXPLAINS IS A CLAIM block beside the precondition-verification rule, plus the clause added to per-card gate 2). Its body was deliberately written free of motir-meta-only references, so this is a LIFT, not a rewrite.
  2. Append it into the precondition-verification region of SHARED_PLANNING_RULES in src/llm/treeGeneration.ts, matching the surrounding register — a single dense paragraph, ALL-CAPS for the load-bearing clauses, no notes.html / plan-rules.md / MOTIR-id references (the mirror is product-generic; strip provenance the way the neighbouring rules do), and the fixture stated generically (an access-control predicate the card's mechanism rests on) rather than by migration filename.
  3. Update the doc comment above SHARED_PLANNING_RULES if it enumerates the rules it carries.
  4. Run the repo's existing prompt/contract tests — if a test asserts the rules block's shape or a phrase inventory, extend it for the new clause.

Acceptance criteria

  • SHARED_PLANNING_RULES carries the claim-vs-pointer gate: an asserted code fact must be grepped on origin/main, the explain-vs-point tell, and the demote-or-phrase-as-obligation remedy.
  • The wording contains no reference to notes.html, plan-rules.md, motir-meta, or any MOTIR key — it reads as a standing product-generic rule, like its neighbours.
  • Any test that pins the rules block's content is updated and green; pnpm lint / pnpm typecheck / the changed test files pass.
  • ONE PR against motir-ai, title carrying this card's MOTIR-<id>.

Context refs

  • src/llm/treeGeneration.ts — where to look for SHARED_PLANNING_RULES and its doc comment.
  • motir-meta/prompts/plan-rules.md — where to look for the landed block to lift.
  • MOTIR-2089 — the prior mirror card; its PR is the shape to follow.