Rp UI Implementation

Build global CSS, tokens, exact local font declarations, and the shared chrome from frozen specs first. Shared chrome includes every utility/promo bar, header, navigation, and footer. The footer is a first-class implementation and QA unit even though it is normally represented by shared-chrome.spec.json rather than a numbered section. Use exact logos and materialized assets; never recreate branding as text. Preserve dropdown hierarchy, source direction, header viewport footprint and scroll behavior, first-viewport visible copy, footer information architecture, and control-state ownership (including pseudo-elements and nested icons).

Required section-by-section method

For the home route, create or refresh docs/site-clone/build/section-implementation.json. It is keyed by the manifest and unit hashes and contains foundation, metadata, shared chrome, recursive components, and sections in dependency order. Status is implemented, verified, provisional, or user-accepted. Do not mark an entry verified from code inspection alone.

Implement exactly one entry at a time:

1. Read only that entry’s frozen spec and its declared frozen dependencies.
2. Build one discrete clone root/component for that unit. Do not merge separate source bands into a generic parent section, and do not use a later source band’s media or copy as a substitute for the current unit.
3. Match its canvas, background layers, container, semantic regions, relationships, text geometry, media role, and responsive reflow before decorative polish. Composition and background-media role are identity locks.
4. Apply the exact data-rp-section / data-rp-layout markers for numbered sections; use data-rp-chrome markers for shared chrome. Implement required scene markers and the public interaction bootstrap before optional motion.
5. Check the rendered unit at the captured desktop, tablet, and mobile viewports. Mark it verified only when it matches its source artifact closely enough to proceed; otherwise fix that same unit before beginning the next one.

After every entry is verified, run the full-page gap loop. Triage every finding to its owning section or shared-chrome ledger entry and fix in that unit; never paper over an earlier section mismatch with global styling or an unrelated section rewrite. Load the normalization stylesheet only within its declared identity locks; it may improve local geometry and accessibility but may not redesign source identity.

Use Astro for static/content-heavy UI and React only for useful interactive islands. Select only pinned items from the local human-approved registry and record the decision/rejections in build/component-selection.json. Deterministic selection matches the frozen component request against the approved, hash-pinned capabilities and writes the resolved axes, slots, states, composition, and contractRef. Read the selection artifact first. Only when it selects an item, read that exact selected contract.md for concise binding/adaptation guidance. Do not scan the registry or read capability JSON, approvals, licenses, component source, candidate reviews, provenance, or live documentation for reasoning. When no item qualifies, use the bounded custom builder. Never guess a nearby variation or fetch a floating registry dependency during a migration.

Do not report the UI as complete after writing it, and never label a provisional unit verified. Leave a runnable project and all runtime markers/contracts in place, then return to the root supervisor for verification.