Build the shared public chrome in motir-core — one header, nav and footer for /explore and /docs

Type: code · Executor: coding_agent · Repo: motir-core · ONE PR.

MOTIR-3880 draws one public chrome and no card builds it. The design produces the three-file asset at design/public-site/; this card is the motir-core half of using it — the header, nav and footer that /explore, /explore/topic/* and /docs render inside on the brand host.

What is true today

motir-core serves those surfaces through ExploreTopBar / ExploreFooter (app/(public)/explore/_components/), which were built for one host and show it: Product and Pricing render as non-interactive <span> labels, with a comment explaining that they are future marketing pages "so they render as non-interactive LABELS rather than dead links a crawler would 404 on", and the brand mark links to /, which on the application host is a redirect to /sign-in. motir-marketing renders its own SiteHeader / SiteFooter for the landing. Two chromes, two repositories, neither aware of the other.

What this card delivers

The chrome the design specifies, composed from the design system, applied to every surface this repository serves on the public host — with the states the asset draws: signed-out, signed-in, the current-page treatment per surface, and the responsive collapse.

The nav's links become real where the design says they do. The brand mark reaches the landing rather than a sign-in redirect, and any label the asset promotes to a link must resolve — on the brand host — to something that exists. A label the design leaves as a label stays a label; this card does not invent destinations.

Boundary

• It is the motir-core half only. motir-marketing renders the same chrome for the landing and /legal; that half belongs with the surfaces it wraps — MOTIR-3909 for /legal, MOTIR-656 for the landing. One design asset, two implementations, and they must not drift — say in the PR how a future change to the asset reaches both.
• It does not move any URL — that is the host-branch card, which this one does not depend on: the chrome is correct on either hostname.
• It does not touch /p/*, which is MOTIR-3877's and joins the same chrome there.

Acceptance criteria

• /explore, /explore/topic/* and /docs render the chrome the asset draws — header, nav, footer — matching its layout and composing the primitives it names.
• Every state the asset draws is implemented and covered: signed-out, signed-in, current-page per surface, and the responsive collapse.
• No link in the chrome resolves to a 404 or to a sign-in redirect on the brand host; any label the asset keeps as a label is still not a link.
• The chrome is one component set, used by all three surfaces — asserted, so a fourth surface cannot quietly grow a second copy.
• AA contrast holds in both themes for every element the asset introduces.
• ≥90% coverage on the files this PR touches.

Context refs

• MOTIR-3880 — the design asset this builds; wired blocked_by
• motir-core/app/(public)/explore/_components/ — ExploreTopBar / ExploreFooter, the chrome being replaced
• motir-marketing/app/_components/ — SiteHeader / SiteFooter, the other implementation to stay consistent with
• motir-core/CLAUDE.md — the component and token reuse conventions

Advisory dispositions

• reference → MOTIR-3877 (advisory): not consumed. Named in this card's boundary as explicitly out of scope — /p/* joins the same chrome under its own story, later and independently.
• reference → MOTIR-656 (advisory): not consumed. It owns the motir-marketing implementation of the same asset. The two halves are independent — neither blocks the other, and the asset is what keeps them consistent. The duplication is named on this card deliberately rather than wired as a dependency it is not.