8.3.15 Copy — the `/design` showcase page's words + the nav label, at the marketing register (motir-marketing)

Write the words for motir.co/design — the public design showcase — into the marketing site's copy catalogue, at the same register the landing established.

The page's job is an argument, and the argument is carried by its copy: Motir builds you a product that is designed, and the proof is that Motir is wearing the same system it will hand you. The controls are self-explanatory; the framing is not.

Where the words go

messages/en.json gains a designShowcase namespace, and lib/copy.ts (export const copy = en, a plain typed import — deliberately not next-intl, see its own header) picks it up with no wiring change. copy.nav gains the showcase's nav label. One namespace per surface is the catalogue's existing arrangement — mirror it.

There is no zh catalogue in this repository and no locale segment, so the zh-parity gate that governs motir-core does not apply here. Do not add one.

What to write

• The page heading and its sub-line — what a visitor is looking at, and why it is on a marketing site rather than in a styleguide.
• One short line per axis — Style, Palette, Type — saying what that axis changes. ⚠️ AMENDED 2026-08-29 (at dispatch, see the comment): these sit as AxisField's help, not as AxisNote text. These sit as AxisNote text beside each picker. AxisNote({ name, tagline }) in @motir/design-system@0.1.0 renders the ACTIVE SELECTION out of STYLE_REGISTRY / PALETTE_REGISTRY / TYPE_REGISTRY — it is generated, never authored. The authored slot is AxisField({ name, help, … }), and a help with no name cannot mount the field, so each axis carries name + help (mirroring motir-core's components/onboarding/DesignStep.tsx wiring). Same three lines the card asked for, in the slot that renders them.
• The theme control's label and the Reset to default control's label. (ThemeSegmentedControl also takes a labels record, so the three chip labels — Light / Dark / System — come with it.)
• A closing line that connects the demo to the product: that the axes a visitor is playing with here are the same three a Motir project picks during onboarding. ⚠️ AMENDED 2026-08-29 (at dispatch, on rung-2 evidence — see the comment): and that the agent applies the choice to what it builds. That clause is CUT: the capability is not shipped. The onboarding design step persists the three axes onto the pre-plan baseline (PreplanSession.designChoice) and GenerationHandoff.tsx summarises them, but the value is rendered into no planner prompt and no dispatch prompt — git grep designChoice origin/main -- 'src/llm/*.ts' in motir-ai returns only the GenerationGrounding field declaration, and motir-core's lib/dispatch/promptTemplate.ts carries no design profile at all. Writing it would put a false statement on a public page. Do not restore it until a prompt reads the value — tests/copy.test.ts asserts it stays out, with the deletion condition in its own comment. Plan defect filed under MOTIR-1465.
• The nav label — one or two words, sitting beside Explore and Docs in SiteHeader. It names a page about design, not a page about tokens.

Register — the rules this catalogue already follows

• Never the word "tracker", and never "issue" for a work item — the product noun is work item.
• The three pillars, in full where the positioning is stated: AI planning, project management, and agent orchestration. Agents do design, decision, content, test and code work — so "the agent takes over the work", never "the coding agent".
• "agents", not "hosted coding agents"; no repo jargon on this page — its audience has not self-selected as having a codebase.
• Follow MOTIR-1144's voice: short, concrete, no superlatives, no "revolutionise".

Scope BOUNDARY

Words only. This card adds no route, no component and no layout — it writes messages/en.json and, where the key set changes shape, the catalogue's messages/README.md. It does not choose where the strings appear on the page (the design card) and does not render them (MOTIR-1043).

Acceptance criteria

• messages/en.json carries a designShowcase namespace with the heading, sub-line, three per-axis notes, the theme-control label, the Reset label and the closing line; and nav carries the showcase's nav label.
• Every string is reachable through copy.designShowcase.* / copy.nav.* with no change to lib/copy.ts — the static import already types the whole catalogue.
• messages/README.md describes the new namespace alongside the existing ones.
• grep -rin "tracker\|\bissue" messages/en.json returns no hit in the new strings (the product noun is work item), and where the positioning is stated it names all three pillars. (The new strings do not state the positioning — a visitor on /design meets all three pillars in footer.tagline, which the page renders. Disposition recorded in messages/README.md.)
• pnpm lint, pnpm format:check (prettier semi: false, singleQuote: true) and pnpm typecheck pass; pnpm test stays green.
• No zh catalogue is added.

Advisory dispositions

validate_work_item, projected over this plan, raised two advisory-severity references against this proposal. Neither applies.

• references MOTIR-1043 (todo), in the Scope BOUNDARY. DOES NOT APPLY, and the edge it suggests would be a cycle. MOTIR-1043 is blocked_by this card, not the reverse. The mention is an out-of-scope OWNER pointer — naming who renders the strings this card writes — which is the shape the boundary rule asks for and the detector cannot distinguish from a consumption.
• references the design card (todo), in the Scope BOUNDARY and the Context refs. DOES NOT APPLY. The two are deliberately PARALLEL: the words do not wait on the layout and the layout does not wait on the words, exactly as MOTIR-1143 and MOTIR-1144 ran for the landing. Both block the build card; neither blocks the other. The context ref is explicitly conditional — "read it… if it has landed first" — which is a convenience, not a prerequisite.

⚠️ A THIRD advisory appeared between authoring and dispatch, and it DOES NOT APPLY: wrong repository. subsumption / likely-in-flight names messages/en.json against open PR moooon-B-V/motir-core#2444. That pull request touches motir-core's messages/en.json and messages/zh.json (confirmed via gh pr view 2444 --json files); this card's targetRepo is motir-marketing, a different repository whose catalogue is a different file — and which has no zh.json at all. The detector matched the bare path across the repository boundary.

(Sibling cards are cited by CHIP rather than by their 8.3.x number throughout this card: this plan re-numbered all three when it moved them from story 8.8 to story 8.3, and a number in prose is exactly what does not survive that.)

Context refs

• motir-marketing messages/en.json — the catalogue to extend · messages/README.md · lib/copy.ts — the typed static import and its format() placeholder helper
• motir-marketing app/_components/SiteHeader.tsx — where copy.nav.* is read, and the two existing nav labels the new one sits beside
• @motir/design-system@0.1.0 dist/components/theme/AppearancePickers.d.ts — AxisField / AxisNote and the four pickers, and which of them takes AUTHORED copy
• motir-core components/onboarding/DesignStep.tsx — the shipped wiring of those components, and the settings.appearance.* / onboarding.design.* strings this page's register is consistent with
• MOTIR-1144 — the landing's copy + positioning card that established this register and this catalogue
• The design card — read it for which strings the layout actually asks for, if it has landed first