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-3871

Planning bug: a copy card scripted a PUBLIC marketing claim about an unshipped capability — no gate checks a customer-facing sentence against the product, because the precondition rule only asks whether the card can be BUILT

To Do
Description

What happened

MOTIR-3862 (8.3.15, the /design showcase's copy) instructed its closing line to say "that the agent applies the choice to what it builds" — a factual claim about Motir, destined for a public marketing page. The capability does not ship.

The run cut the clause and shipped the true half. This card is about why the clause was written.

The evidence (rung 2, origin/main in both repositories, 2026-08-29)

What ships:

  • motir-core app/api/ai/pre-plan/route.ts PATCHaiPreplanService.saveDesignChoice persists { styleId, paletteId, typeId } onto motir-ai's PreplanSession.designChoice.
  • motir-core components/onboarding/GenerationHandoff.tsx reads it back and renders a summary line for the user.
  • motir-ai carries it as far as GenerationGrounding.designChoice (src/llm/treeGeneration.ts:559).

What does not:

  • git grep designChoice origin/main -- 'src/llm/*.ts' in motir-ai returns only that field declaration. No prompt renderer reads it.
  • lib/dispatch/promptTemplate.ts in motir-core carries no design profile at all.

So the value is captured, previewed and summarised, and then consumed by nothing that plans or dispatches work. The product's own copy is careful about exactly this — onboarding.design.lead says "This whole page previews your choice — and only this page" and footerNote says "This styles your project, not Motir". The marketing card would have been the one surface that over-claimed.

Why no gate caught it

The precondition-verification rule (plan-rules/phase-deepen.md) and its run-time backstop (run.md guard #4) both ask one question: does the substrate this card CONSUMES exist? For a copy card the answer is yes and stays yes — the catalogue exists, the file is writable, the card is fully buildable. The card's subject matter was never checked, because on a copy card the subject matter is not a dependency. Nothing in either half asks "is the sentence this card is scripting TRUE?"

Three things made it invisible:

  1. The card was otherwise exemplary. It pinned its repo, sized itself at 2 points, drew a hard scope boundary, and carried a considered ## Advisory dispositions section. It reads as careful, which is the shape run.md already warns about one guard over — "a card that quotes, agrees and defers looks considered".
  2. validate_work_item cannot see it. Its families are structural — references, shape, subsumption, sizing. A false claim about the product is none of them, and the array it returned for this card named only two out-of-scope owner pointers and one cross-repository path match.
  3. The claim is plausible and nearly true. The choice IS captured; it IS carried into the grounding object. A reader checking casually finds designChoice in both repositories and stops. The gap is one hop further in — the field is declared and never rendered — and it is exactly the hop a card author does not take.

The generalisable shape

A card whose deliverable is CUSTOMER-FACING TEXT is asserting things about the product, and an assertion has a truth value that the substrate check does not test. copy / content / legal / design cards can all carry one. This is the mirror of the phase-deepen.md NEGATIVE limb (a card explaining a defect by what does not exist owes the grep): there the card's claim is that something is ABSENT and it owes evidence; here the card's claim is that something is PRESENT — a shipped capability — and nothing asks for any.

Acceptance criteria

  • plan-rules/type-bars.md (or type-code.md's neighbour for the copy/content bar — whichever the MANIFEST routes) gains a rule: a card that scripts customer-facing text naming a product capability must cite where that capability ships, verified to the point of CONSUMPTION, not to the point of storage. The tell to name: a value that is persisted and typed is not thereby used — grep for a READER, not for the identifier.
  • The rule states the discriminator: the precondition check asks whether the card can be BUILT; this one asks whether what it SAYS is true, and a copy card passes the first trivially.
  • It cites this incident and MOTIR-3862 as the fixture, with the two commands that settled it.
  • plan-rules/ASSIGNMENT.md is updated if the rule lands in a pack whose span it records.

Not in scope

  • Building the capability. Whether an agent should build to the project's chosen look is a product decision nobody has made; this card does not make it and does not file for it. The copy simply stops claiming it.
  • MOTIR-3862 itself — amended on the record and shipped, with a test asserting the claim stays out until a prompt reads the value.