MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-2692

(motir-meta) Land RUNG 1 + GATE 1's rewrites in the written playbook — the second home, or the rules are half-landed

To Do
Description

Repo: motir-meta. One PR. The second home of two rules whose shipped mirror is being changed in motir-ai.

A RULE HAS TWO HOMES. prompts/plan-rules/core.md and motir-ai's SHARED_PLANNING_RULES carry the same corpus, the two repositories cannot see each other, and nothing reconciles them automatically. A rule corrected in one home and not the other is HALF-LANDED: we plan by the new rule and ship the old one, which is the inverse of dogfooding.

This card is separate from its twins for one mechanical reason — MOTIR-2624 is a motir-ai story whose parent-run produces a motir-ai PR, and a motir-meta change cannot ride it. It is parented to the epic rather than that story so the one-repo-per-PR shape stays intact.

What lands here

1. RUNG 1 — from MOTIR-2689

The shipped mirror's rung was rewritten because it was unfollowable: it said "CHECK it — never assert from memory" while the planning pass had no read path to any reference product. Three changes, all of which apply verbatim to the written playbook:

  • THE REFERENCE PRODUCT, not "THE MIRROR PRODUCT" — and no "tool". the tool it clones/competes with presumes the planned product is a tool; this corpus plans arbitrary products, and "reference product … the tool" is redundant besides.
  • Per FEATURE, not per project. the FEATURE is the query, not the project. A project-level competitor that does not implement the behaviour in front of you proves nothing, and this is what makes an IMPORTED project (which never ran discovery, so has no recorded comparable set) a normal case rather than a special one.
  • CITE what you checked — the product, the surface, and where you saw it — and an explicit exit: if no reference is reachable, SAY SO on the card and fall to rung 2 rather than describing an implementation you did not observe.

⚠️ One clause does NOT transfer verbatim. The shipped text points at web_search as the tool that discharges the rung. The written playbook's reader is a coding agent in a terminal with its own tools, so name the CAPABILITY ("search the web / open the product's docs") rather than the shipped tool name.

2. GATE 1 — from MOTIR-2691

Gate 1 sends the planner to search the plan tree for existing work. In the shipped planner that search is a substring filter, which is why 2691 adds semantic candidate-finding. Land whatever wording 2691 settles on, and only after it does — this half depends on that card's outcome, so it may split into its own follow-up rather than blocking this one.

Do this

  1. Read the shipped text as merged in motir-ai and mirror it — do not re-derive the wording, and do not improve it in passing. Divergence introduced by re-writing is the failure this card exists to prevent.
  2. Apply the same edits to any plan-rules/ pack, plan-procedure.md or run.md passage that quotes either rule or the phrase "mirror product".
  3. grep the whole prompts/ tree for mirror product and clones/competes — the rung is cited by name elsewhere and a renamed heading leaves dangling references.
  4. Branch docs/<slug> with NO MOTIR-<n> in the branch or the PR title (the motir-meta sync rule); put the card reference in the PR BODY.

Acceptance criteria

  1. prompts/plan-rules/core.md's rung reads THE REFERENCE PRODUCT, is per-FEATURE, names no "tool", requires a citation, and carries the cannot-reach-one exit.
  2. Its wording matches the merged motir-ai text except where the shipped tool name is deliberately generalised — and that difference is noted inline so a later reader does not "fix" it back.
  3. Every other prompts/ passage quoting the rule or the phrase "mirror product" is updated; the grep in step 3 returns no stale hit.
  4. Gate 1's half either lands with 2691's settled wording, or is carved into its own card with the reason recorded.
  5. Branch and PR title carry no MOTIR-<n>; the PR body cites this card.

Context refs

  • prompts/plan-rules/core.md — the decision-authority ladder and Gate 1.
  • prompts/plan-rules/MANIFEST.md · DECISION.md — which pack carries what.
  • MOTIR-2689 — the rung's diagnosis and the shipped rewrite.
  • MOTIR-2691 — Gate 1's, whose wording this waits on.