Implémentation UI

Charge cette ressource uniquement quand extraction/latest.json, son manifeste figé et le build/build-plan.json correspondant existent et passent la vérification d'intégrité. Elle est propriétaire de l'implémentation, pas de la comparaison finale ou de l'acceptation de la boucle de correction.

Lis references/interaction-runtime-contract.md, references/layout-blueprint-contract.md, references/control-and-visual-fidelity-contract.md et references/ui-normalization-contract.md.

Construis uniquement à partir de specs figées acceptées ou provisoires nommées par le plan de build. Ne lis pas les observations brutes ni ne parcoure la source pour combler les lacunes. Quand l'implémentation expose un fait manquant, crée une extraction-gap request propriétaire. Utilise le budget de récupération limité restant ; après épuisement, implémente provisoirement la portion fiable et continue les unités non liées.

Construis d'abord le CSS global, les tokens, les déclarations exactes de polices locales et la chrome partagée à partir des specs figées. La chrome partagée inclut chaque barre utilitaire/promo, en-tête, navigation et pied de page. Le pied de page est une unité d'implémentation et de QA de première classe même s'il est normalement représenté par shared-chrome.spec.json plutôt que par une section numérotée. Utilise les logos exacts et les assets matérialisés ; ne recréé jamais la marque en tant que texte. Préserve la hiérarchie des listes déroulantes, la direction source, l'empreinte viewport de l'en-tête et le comportement du défilement, la copie visible en premier viewport, l'architecture d'information du pied de page et la propriété d'état de contrôle (y compris les pseudo-éléments et les icônes imbriquées).

Méthode requise section par section

Pour la route home, crée ou rafraîchis docs/site-clone/build/section-implementation.json. Elle est indexée par les hashes du manifeste et de l'unité et contient la fondation, les métadonnées, la chrome partagée, les composants récursifs et les sections dans l'ordre de dépendance. Le statut est implemented, verified, provisional ou user-accepted. Ne marque pas une entrée vérifiée à partir d'une inspection de code seule.

Implémente exactement une entrée à la fois :

1. Lis uniquement la spec figée de cette entrée et ses dépendances figées déclarées.
2. Construis une seule racine clone/composant discret pour cette unité. Ne fusionne pas les bandes source séparées en une section générique parente et n'utilise pas les médias ou la copie d'une bande source ultérieure comme substitut à l'unité actuelle.
3. Fais correspondre son canvas, ses calques d'arrière-plan, son conteneur, ses régions sémantiques, ses relations, sa géométrie de texte, son rôle de média et son reflow réactif avant le polish décoratif. La composition et le rôle de média d'arrière-plan sont des verrous d'identité.
4. Applique les marqueurs exacts data-rp-section / data-rp-layout pour les sections numérotées ; utilise les marqueurs data-rp-chrome pour la chrome partagée. Implémente les marqueurs de scène requis et le bootstrap d'interaction public avant le mouvement optionnel.
5. Vérifie l'unité rendue aux viewports desktop, tablette et mobile capturés. Marque-la verified uniquement quand elle correspond assez étroitement à son artifact source pour procéder ; sinon, corrige cette même unité avant de commencer la suivante.

Après que chaque entrée soit vérifiée, exécute la boucle de gap pleine page. Classe chaque découverte à son entrée ledger propriétaire ou shared-chrome et corrige dans cette unité ; ne cache jamais un décalage de section antérieure avec un style global ou une réécriture de section non liée. Charge la feuille de style de normalisation uniquement dans ses verrous d'identité déclarés ; elle peut améliorer la géométrie locale et l'accessibilité mais ne peut pas redessiner l'identité source.

Utilise Astro pour l'UI statique/riche en contenu et React uniquement pour les îles interactives utiles. Sélectionne uniquement les éléments épinglés du registre approuvé local par un humain et enregistre la décision/les rejets dans build/component-selection.json. La sélection déterministe fait correspondre la demande de composant figée aux capacités approbées et hashées, et écrit les axes résolus, les slots, les états, la composition et la contractRef. Lis d'abord l'artifact de sélection. Uniquement quand il sélectionne un élément, lis le contract.md exact sélectionné pour les directives concises de liaison/adaptation. Ne scanne pas le registre ni ne lis la capacité JSON, les approbations, les licences, la source des composants, les avis des candidats, la provenance ou la documentation en direct pour le raisonnement. Quand aucun élément ne se qualifie, utilise le constructeur personnalisé limité. Ne devine jamais une variation proche ni ne récupère une dépendance de registre flottante pendant une migration.

Ne rapporte pas l'UI comme complète après l'avoir écrite et ne marque jamais une unité provisoire vérifiée. Laisse un projet exécutable et tous les marqueurs/contrats runtime en place, puis retourne au superviseur racine pour vérification.