Motir

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

⚠️ RE-FILED into MOTIR-3932 (2026-08-29) — and a re-file is a re-seal

This card was authored under MOTIR-3876 when that story was going to RENDER the public surface. It no longer does: motir-core becomes an application plus a public API, and every public page is rendered by motir-marketing. The chrome this asset draws is built by MOTIR-3932, so the design belongs beside it — a prerequisite takes the same parent as the card it gates.

Its blocked_by into the ADR is DROPPED as a leaf edge, not as a dependency: MOTIR-3932 is blocked_by MOTIR-3876, which holds the ADR, and readiness.blockedByAncestor carries it. A leaf edge across the container boundary would be cross-parent and is not owed.

The asset's scope is unchanged. It still draws one header, nav and footer for the landing, /explore, /docs and /legal — which is now more true than when it was written, because all four are served by one application on one origin instead of split across two. What changes is only that its consumer is in the other repository.

Advisory dispositions

• shape / likely-self-blocking-design (designCriterionIndex: 1, surfaceCriterionIndex: 2): NOT ACTED ON, and here is the reason. The rule this detector serves is that a card producing a design asset must not also build the surface rendered from it — one criterion column saying design asset, another saying rendered surface, means the design is a child rather than a criterion. Read criterion by criterion, both of the named criteria produce the ASSET. Criterion 1 is the three-file set at design/public-site/; criterion 2 is "One header and one footer are DRAWN IN THE ASSET, with the per-surface states" — its subject is the asset, and the word the detector matched on is "surface" inside a list of the states the asset must depict. This card builds nothing: no route, no component, no rendered page appears in any criterion, and the card that renders the chrome is MOTIR-3932's, in another repository. There is no criterion to cut.
• Recorded here rather than left silent because a detector that has not been disposed of is undischarged, and the next run to open this card would otherwise meet the same finding with no verdict.