Design — one public chrome for motir.co: the landing, /explore, /docs and /legal under a single header, nav and footer

Type: design · Executor: coding_agent · Ships the three-file asset in motir-core at design/public-site/: design-notes.md + public-site.mock.html + public-site.png.

The surface

motir.co will serve four surfaces that today wear two different chromes on two different hosts, and neither knows about the other:

This card draws one header, nav and footer for all four, and the states each surface puts it in.

What the move makes newly drawable — and this is the point of the card

ExploreTopBar renders Product and Pricing as non-interactive <span> labels, with a comment explaining why: "Product / Pricing are future marketing pages, so they render as non-interactive LABELS rather than dead links a crawler would 404 on." Its brand mark links to /, which on the application host is app/page.tsx — a redirect to /sign-in. On motir.co that link reaches the landing, so the brand lockup becomes a real home link and the nav gains its first genuine sibling set. SiteFooter likewise omits Product, Pricing, Blog and About because they do not exist.

The asset decides what the nav holds when the pages that exist are /, /explore, /docs, /legal — and how a label that is still a placeholder is drawn, since some remain.

⚠️ The ACCESS PATH this asset must draw

Every surface's entrance, in the parent surface, at the pixel:

1. How /explore is reached from the landing — the nav item, and any in-page entrance the landing's own body offers.
2. How /docs and /legal are reached — /docs from the nav (it already has a treatment, per ExploreTopBar's current prop); /legal from the footer, which is where it is reached from today and where the asset must keep it, because marking Explore as aria-current on a legal page "would tell a screen reader the wrong thing" — that reasoning is in the shipped component and is not to be undone.
3. The application doors — Sign in / Start free, which remain the only deliberate cross-host links, and must read as leaving.
4. The route back from /explore into a public project — a cross-host link once /p/* moves, so the asset draws it as a normal link and does not assume same-origin.

Composition, not redrawing

It composes shipped assets rather than re-specifying them:

• motir-marketing/design/marketing/design-notes.md + landing.mock.html — the landing's own layout and its three doors. This asset does NOT redraw the landing body; it draws the chrome around it and states so.
• motir-core/design/brand/design-notes.md §7c — the BrandMark lockup at 26px and its rhythm in a py-3 bar.
• @motir/design-system primitives + --el-* element tokens and the element-semantic shape tokens; no Tier-0 --color-*, no raw rounded-* / p-*.

Acceptance criteria

• The three-file set exists at design/public-site/ — design-notes.md, the mock, and a rendered .png — and the notes carry the surface table plus the panel index the convention expects.
• One header and one footer are DRAWN IN THE ASSET, with the per-surface states: landing (no current item), /explore (current), a topic page, /docs (current), /legal (current on neither, by the shipped reasoning above).
• The access path for each of the four entrances above is VISUALISED IN THE ASSET, in its parent surface, not described in prose.
• Placeholder nav items are drawn with a treatment that is visibly not a link, and the notes name which items are placeholders as of the asset's date, with the rule for promoting one.
• Every colour is an --el-* token and every shape an element-semantic token; the notes list the primitives composed and cite @motir/design-system rather than re-specifying them.
• Measured at 1280 and 390 CSS px, with the fold stated for each.
• The notes' ## ⚠️ Planning flags section names anything the asset found that no card owns, with a key for each — a flag naming no card is not a flag.
• The GIVES / TAKES sweep is run and recorded: grep the asset for every MOTIR-<n>, and for each say whether it gives or takes an element, a structure or a premise — and amend that card's acceptance criteria in the same pass. The landing-port card and the 301 card are both in scope of that sweep.

Advisory dispositions

shape · likely-self-blocking-design (criteria 1 and 2) — NOT REAL, and here is the check that settles it. The detector fires when a childless card is its own design blocker: one criterion PRODUCES a design and another CONSUMES it by building the surface. Criterion 1 produces the asset; criterion 2 was read as consuming it.

It does not apply because no criterion on this card builds anything. Every verb in the list resolves inside design/public-site/: criterion 2's drawn, criterion 3's visualised, criterion 4's drawn. Nothing here renders a component, edits a route or touches app/. The surfaces that CONSUME this asset are separate cards — the landing port and the redirect card — and both are blocked_by this one, which is the correct shape rather than the self-blocking one.

The two words that most likely tripped it (drawn, visualised in its parent surface) have been qualified in place — IN THE ASSET — so a later reader reaches the same verdict without re-deriving it. That is the whole action taken; the criteria's substance is unchanged, because the substance was never the problem.

Context refs

• motir-core/app/(public)/explore/_components/ExploreTopBar.tsx · ExploreFooter.tsx — the shipped chrome and the reasoning in its comments
• motir-core/app/(public)/_components/PublicTopBar.tsx — the OTHER public chrome, which this asset does NOT unify (it belongs to /p/*)
• motir-marketing/app/_components/SiteHeader.tsx · SiteFooter.tsx · design/marketing/
• motir-core/design/brand/design-notes.md · motir-core/app/tokens/
• The ADR this is blocked_by — the host table it draws to