WebBlocks CMS · Contrat du moteur de rendu UI des blocs

La phase 1 définit le contrat public de rendu prévu entre les layouts, les slots et les types de bloc du CMS d'une part, et les primitives WebBlocks UI déjà livrées et chargées par le layout public d'autre part. Cette phase est purement documentaire. Elle ne réécrit pas encore les moteurs de rendu.

Vérifiées par rapport aux ressources réellement livrées et utilisées par le CMS :

CSS : https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-ui.css
CSS des icônes : https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-icons.css
JS : https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-ui.js

Primitives et motifs confirmés :

wb-content-shell
wb-content-header
wb-content-body
wb-content-footer
wb-promo
wb-callout
wb-link-list
wb-stat
wb-gallery
wb-alert
wb-rich-text
wb-rich-text-readable
wb-rich-text-compact
wb-rich-text-loose
wb-btn
wb-grid
wb-grid-2
wb-grid-3
wb-grid-4
wb-stack
wb-gap-1
wb-gap-2
wb-gap-3
wb-gap-4
wb-gap-6
wb-gap-8

Primitives absentes et lacunes de l'interface pour le moment :

wb-prose — INTROUVABLE dans les ressources livrées de WebBlocks UI. Considérez-le comme une lacune de l'interface et ne vous appuyez pas dessus pour le layout de la phase 2 ni pour l'alignement des moteurs de rendu.
wb-promo-muted — INTROUVABLE dans les ressources livrées de WebBlocks UI.
wb-promo-accent — INTROUVABLE dans les ressources livrées de WebBlocks UI.
wb-cluster-3 — INTROUVABLE dans les ressources livrées de WebBlocks UI.

Hooks JS livrés et vérifiés, pertinents pour le rendu public actuel :

data-wb-toggle="dropdown"
data-wb-toggle="modal"
data-wb-gallery-target
#wb-overlay-root

Les pages publiques utilisent désormais des modes explicites de composition du layout :

stack est le mode par défaut.
sidebar est utilisé lorsque la page dispose d'un slot de barre latérale rempli.
content est réservé aux futures pages de documentation ou éditoriales dotées de métadonnées explicites et ne doit pas être deviné à partir de l'URL ou du titre.
wb-content-shell n'est pas un conteneur universel et ne devrait apparaître que lorsque les métadonnées de la page prennent explicitement en charge une présentation de type content-shell.

Bloc du CMS	Primitive/motif WebBlocks UI	Statut	Priorité	Action suivante
layout public	wb-public-body, wb-public-main, wb-container	acceptable	P0 shell/layout	garder le shell stable et rapprocher le chrome propre à chaque slot des primitives documentées
slot d'en-tête	wb-section, wb-container, primitives de navigation/liste	faible	P0 shell/layout	aligner le chrome d'en-tête personnalisé sur les règles documentées du shell
slot principal	wb-public-main, wb-container, wb-content-shell	acceptable	P0 shell/layout	ajouter l'usage de wb-content-shell là où le contenu se lit comme un article ou de la documentation
slot de barre latérale	wb-grid, wb-stack, éventuellement un aside wb-content-shell	faible	P0 shell/layout	cesser de traiter les barres latérales génériques comme de fausses barres latérales applicatives
slot de pied de page	wb-section, wb-container, wb-grid, primitives de liste de liens/navigation	acceptable	P0 shell/layout	garder le pied de page sur les primitives de layout livrées et éviter les classes personnalisées supplémentaires
heading	hérité supprimé	retiré	P0 supprimé	ne pas le réintroduire ; header est le bloc canonique de titre
text	texte courant au rythme de wb-stack	acceptable	P2 qualité du contenu	conserver une sortie simple et éviter les habillages typographiques sur mesure
rich-text	wb-rich-text wb-rich-text-readable	acceptable	P2 qualité du contenu	conserver le texte courant sûr circonscrit à la primitive de texte enrichi livrée
html	HTML brut de confiance dans le conteneur de bloc public	acceptable	P3 ultérieur/personnalisé	le réserver à un usage éditorial/administratif de confiance et remonter tout contenu de superposition livré vers la racine de superposition partagée de la page
section	wb-section, éventuellement wb-promo	acceptable	P1 marketing public/docs	garder la section par défaut stable et réserver la sémantique promo aux variantes explicites
columns	wb-grid, wb-grid-2, wb-grid-3, wb-grid-4, wb-link-list	acceptable	P1 marketing public/docs	garder explicites les variantes pilotées par le parent et éviter de réintroduire des cartes conteneurs imposées
column_item	cellule simple, wb-card, wb-stat ou élément de liste de liens	acceptable	P1 marketing public/docs	garder le rendu de l'élément piloté par la correspondance columns.variant du parent
callout	wb-alert, éventuellement wb-callout	acceptable	P2 qualité du contenu	élargir la correspondance des variantes s'il existe un callout de barre latérale/d'aide livré
quote	blockquote sémantique, éventuellement une carte encadrée	acceptable	P2 qualité du contenu	rendre l'encadrement conditionnel plutôt que systématiquement en forme de carte
faq	carte question/réponse simple	acceptable	P3 personnalisé/repli	conserver le traitement stable en carte unique et laisser le dépliage groupé aux blocs accordéon
tabs	motif d'onglets interactifs	faible	P2 qualité du contenu	reporter tant qu'un véritable motif d'onglets livré n'existe pas
button	variantes de wb-btn	faible	P1 marketing public/docs	mapper toutes les variantes prises en charge par le CMS et ajouter la direction du groupe de boutons
image	figure, img, figcaption sémantiques	faible	P2 qualité du contenu	respecter le comportement du lien et n'ajouter un encadrement média que si nécessaire
gallery	wb-gallery plus la modale de la racine de superposition	acceptable	P1 marketing public/docs	continuer d'utiliser les hooks de galerie livrés et la racine de superposition centrale, en gardant le texte d'introduction hors du bloc Gallery lui-même
download	wb-btn ou CTA carte avec bouton	acceptable	P2 qualité du contenu	ajouter plus tard des variantes explicites carte/téléchargement
navigation-auto	primitives de navigation/liste, éventuellement wb-link-list	acceptable	P1 marketing public/docs	garder simples les menus simples et réserver les barres latérales de documentation aux véritables shells de documentation
menu	alias hérité de navigation-auto	acceptable	P3 ultérieur/personnalisé	le conserver uniquement pour les données migrées
contact_form	primitives de formulaire, wb-btn, wb-alert	acceptable	P1 marketing public/docs	conserver les champs structurés de l'éditeur et éviter les formulaires en HTML brut
hero	shell marketing wb-promo	acceptable	P1 marketing public/docs	garder le hero de premier plan, traduit et orienté action via des blocs bouton enfants
card-grid	motif de grille de cartes	faible	P1 marketing public/docs	garder stable la grille de cartes structurée actuelle et revoir plus tard une modélisation de premier plan
showcase-list	motif vitrine/galerie	faible	P3 ultérieur/personnalisé	soit le formaliser comme bloc vitrine de premier plan, soit le garder personnalisé
contact-info	liste de liens / carte de coordonnées	faible	P2 qualité du contenu	ne le promouvoir au premier plan que si les éditeurs en ont besoin au-delà des pages préchargées
code	motif de bloc de code	manquant	P2 qualité du contenu	ajouter une prise en charge de premier plan côté rendu/administration ou conserver délibérément le repli
list	primitive de liste	acceptable	P1 marketing public/docs	conserver l'éditeur dédié basé sur les lignes et préserver la compatibilité avec les réglages de style de repli hérités
table	motif wb-table	acceptable	P1 marketing public/docs	conserver l'éditeur dédié basé sur les lignes et préserver les lignes de réglages de style de repli héritées
accordion	motif de dépliage sémantique	acceptable	P1 marketing public/docs	conserver le moteur de rendu sémantique de premier plan avec des blocs enfants comme éléments
feature-grid	motif délégué columns.variant = cards	acceptable	P1 marketing public/docs	le maintenir publié comme alias de compatibilité, mais préférer columns pour les nouveaux contenus structurés
stats / metric-card	motif délégué columns.variant = stats	faible	P1 marketing public/docs	garder les alias honnêtes et n'ajouter de véritables contrats propres aux statistiques que s'ils deviennent portés par le produit
logo-cloud	grille de logos / bandeau de marques	faible	P1 marketing public/docs	ajouter une gestion structurée des médias s'il reste intégré au produit
testimonial	motif de témoignage délégué à la citation	faible	P2 qualité du contenu	garder le comportement d'alias honnête à moins qu'un contrat de témoignage autonome ne soit porté par le produit
timeline	motif de frise chronologique	faible	P2 qualité du contenu	ne le promouvoir que si le contenu chronologique constitue un véritable cas d'usage récurrent
pricing	motif de carte/grille tarifaire	faible	P1 marketing public/docs	ne le placer au premier plan qu'avec des offres et des fonctionnalités structurées
toc	navigation par table des matières	acceptable	P1 marketing public/docs	limiter la collecte du sommaire de la page aux seuls blocs header dotés d'une ancre explicite
breadcrumb	navigation par fil d'Ariane	manquant	P2 qualité du contenu	reporter jusqu'à ce que le shell de page publique en ait réellement besoin et qu'un motif livré soit confirmé
cookie-notice	motif partagé de bannière/modale de confidentialité	manquant	P3 ultérieur/personnalisé	garder l'interface de consentement dans le layout public plutôt que dans les moteurs de rendu de blocs

Le layout public possède le shell de toute la page et devrait conserver le contrat de base <body class="wb-public-body">.
Page Layout est le nom, côté éditeur, du mode de shell public extérieur.
Le champ de compatibilité stocké reste public_shell dans cette phase, mais les Page Layouts sont désormais des enregistrements gérés au niveau de l'installation dans l'administration.
Page Layout peut ajouter à cette classe de body de base des classes validées telles que layout-default ou layout-docs.
Les grandes régions de la page devraient d'abord être construites à partir des primitives de layout livrées de WebBlocks UI : wb-public-main, wb-container, wb-section, wb-stack, wb-grid.
wb-content-shell, wb-content-header, wb-content-body et wb-content-footer ont leur place dans la zone de contenu principale lorsque la page se lit comme un article, un guide, de la documentation ou du contenu éditorial. Il ne s'agit pas du chrome d'en-tête ou de pied de page du site entier.
#wb-overlay-root est l'unique point de montage partagé des superpositions publiques telles que la visionneuse de galerie, la modale de recherche publique et la modale de préférences de cookies.
Les layouts publics possèdent ce conteneur ; les blocs, les partials et le HTML de confiance peuvent y ajouter des enfants de superposition, mais ne doivent pas rendre de conteneurs racines de superposition concurrents.
Le HTML importé de confiance qui utilise les hooks de déclenchement livrés de WebBlocks UI doit préserver le contrat entre le déclencheur et sa cible. Si un déclencheur situé dans le contenu principal importé pointe vers une modale, un tiroir, un popover ou une visionneuse de galerie en dehors de <main>, l'extracteur doit remonter cette cible référencée dans le #wb-overlay-root partagé plutôt que de l'abandonner.
Lorsque le CMS pré-rend une couche de dialogue partagée sous #wb-overlay-root, cette couche doit rester non masquée afin que WebBlocks UI v2.7.12 puisse y transférer les cibles de modale et de galerie de confiance sans les laisser à l'intérieur d'un ancêtre masqué.

card possède article.wb-card comme racine de rendu, avec data-wb-public-block-type="card".
card_header possède div.wb-card-header, avec data-wb-public-block-type="card-header".
card_body possède div.wb-card-body, avec data-wb-public-block-type="card-body".
card_footer possède div.wb-card-footer, avec data-wb-public-block-type="card-footer".
Les régions de Card devraient rendre directement leurs propres racines et ne doivent pas recevoir de conteneurs publics génériques supplémentaires.
Le contrat normal de Card repose sur un contenu enfant composable au travers de ces trois régions, et non sur un moteur de rendu promo ou média intégré.
Les anciennes lignes Card enregistrées peuvent encore utiliser un moteur de rendu de repli minimal, mais uniquement lorsque la Card n'a aucune région Card enfant.
wb-sidebar est réservé à un véritable shell de navigation de documentation ou d'application. Les barres latérales génériques, marketing ou éditoriales, devraient rester du contenu aside ordinaire, composé à partir de wb-grid, wb-stack, de cartes, de callouts et de listes de liens.

Les wrappers de slot relèvent d'un comportement d'exécution déterministe, et non de réglages éditoriaux libres au niveau de la page.
Le handle de layout de page se résout d'abord vers un enregistrement Page Layout géré lorsqu'il existe, et les Page Layout Slots gérés de cet enregistrement servent ensuite à résoudre l'élément, les classes, les ids et les fragments structurels de confiance du wrapper de slot.
La comparaison dans Edit Page et Add Missing Layout Slots ne modifient la structure de la page qu'en créant les Page Slots manquants ; elles ne modifient pas la propriété du wrapper public.
Les champs HTML de confiance de Page Layout Slot n'existent que pour la structure de layout adjacente au wrapper. Ce n'est pas une surface de script, et les blocs restent propriétaires des racines de contenu rendues à l'intérieur du wrapper de slot.
Lorsqu'un slot d'en-tête public par défaut ne contient qu'un bloc Navbar, le CMS promeut le wrapper de slot en racine nav.wb-navbar, afin que le comportement sticky de WebBlocks UI ne soit pas contraint par une boîte d'en-tête parente trop basse.
wb-navbar--static reste la classe d'exclusion pour les blocs Navbar publics non sticky.
default associe header, main, sidebar et footer à des wrappers sémantiques et retombe sur div pour les slots inconnus.
docs associe header au wrapper de la navbar docs, sidebar au wrapper de la barre latérale docs et main au wrapper principal docs, tout en gardant wb-dashboard-shell détenu par la page.
Les layouts intégrés default et docs conservent des définitions gérées de repli afin que le rendu reste stable avant les lignes de slot relationnelles ou en leur absence.
Les blocs sont rendus à l'intérieur du wrapper de slot résolu et ne possèdent pas le balisage du shell de page.
Le comportement sticky de la navbar appartient à .wb-navbar. Le CMS ne doit pas ajouter une seconde classe sticky propre à la navbar sur le wrapper de slot ni sur la sortie du bloc navbar.
Lorsqu'un slot de page utilise source_type = shared_slot, le Shared Slot n'apporte que l'arborescence de blocs interne. Il ne doit rendre ni son propre shell de page ni son propre wrapper de slot.
La compatibilité du Shared Slot est vérifiée avant le rendu : la portée de site doit correspondre, le public_shell optionnel doit correspondre exactement au handle de layout de la page consommatrice et le slot_name optionnel doit correspondre au slot de la page consommatrice.
Les wrappers publics génériques de blocs doivent rester non sémantiques et ne doivent pas être utilisés pour les blocs de layout ou propriétaires de leur racine.
Le shell de page possède le shell extérieur, les wrappers de slot possèdent le wrapper de région, et les blocs propriétaires de leur racine possèdent leur propre élément racine public réel.
Les blocs propriétaires de leur racine doivent placer data-wb-public-block-type sur leur propre racine de renderer au lieu de recevoir un wrapper extérieur wb-public-block supplémentaire.

Correspondance prévue : région header construite à partir de wb-section et wb-container, avec les primitives de navigation et de liste livrées à l'intérieur.
Utilisez wb-stack ou wb-grid pour le rythme interne, selon que l'en-tête se lit comme une bannière empilée ou comme une barre de navigation horizontale.
La navigation principale ou légale peut être rendue via navigation-auto ou menu, mais le slot ne doit pas obliger les renderers de blocs à émettre du HTML propre à l'en-tête.
L'implémentation actuelle est faible parce que le slot d'en-tête possède plusieurs classes de chrome wb-public-* personnalisées. La phase 2A conserve intact le shell existant wb-section et wb-container et reporte à une passe ultérieure toute réduction sûre du chrome d'en-tête personnalisé.

Correspondance prévue : <main class="wb-public-main"> est la région de contenu principale.
Shell par défaut : wb-public-main > .wb-container > .wb-stack pour les piles de blocs ordinaires.
Shell éditorial/docs : wb-public-main > .wb-container > .wb-content-shell avec les sections optionnelles wb-content-header, wb-content-body et wb-content-footer.
La mise en page des blocs imbriqués doit utiliser wb-stack, wb-stack-, wb-gap-, wb-grid et wb-grid-* avant toute classe de wrapper personnalisée.
L'implémentation actuelle est acceptable car elle donne déjà au slot main un wrapper public stable et un rythme de blocs. La phase 2B ajoute des modes de layout explicites afin que wb-content-shell soit réservé plutôt qu'imposé à chaque page.

Correspondance prévue : aside adjacent au contenu principal via wb-grid ou une autre primitive de layout livrée.
Le contenu par défaut doit être un wb-stack de blocs d'appui, éventuellement regroupés dans un wb-card ou un wb-callout si cela correspond au contenu du bloc.
wb-sidebar ne doit être utilisé que lorsque la page rend explicitement un shell de navigation docs/application, pas pour du contenu marketing d'appui générique.
L'implémentation actuelle est faible car elle utilise encore un shell wb-public-sidebar personnalisé. La phase 2A supprime le wrapper extérieur wb-card imposé afin que les blocs internes décident s'ils se rendent en cartes ou en callouts.

Correspondance prévue : région footer construite à partir de wb-section, wb-container et wb-grid ou wb-stack.
Les listes de navigation doivent utiliser de simples primitives de navigation/liste ou wb-link-list lorsque le motif d'interface livré convient.
Les blocs de contenu d'appui peuvent se rendre normalement dans le pied de page ; ils ne devraient pas nécessiter de renderers de blocs propres au pied de page.
L'implémentation actuelle est acceptable car elle reste proche des primitives de layout livrées, avec seulement un peu de chrome de pied de page propre au CMS autour du contrôle des réglages de cookies.

Slug du bloc dans le CMS : header
Champs d'administration : text, level, anchor
Champs traduisibles : texte de title
Champs partagés : variant/level, réglage d'alignement, anchor
Sortie prévue dans WebBlocks UI : <h1>-<h6> sémantique selon level ; id optionnel issu de l'anchor partagé ; aucun wrapper inventé au-delà de l'élément de titre.
Implémentation actuelle : acceptable
Contrat de TOC : les anchors partagés explicites sont la seule source prise en charge pour le TOC, et le TOC public collecte les blocs header pourvus d'un anchor dans le même arbre de page rendu, y compris les descendants de layout imbriqués.
Notes pour les améliorations ultérieures du renderer/de l'administration : garder le comportement des anchors explicite, préserver la sortie sans wrapper et laisser la sémantique des titres à Header plutôt qu'à un bloc hérité parallèle.

Slug du bloc dans le CMS : text
Champs d'administration : content
Champs traduisibles : content
Champs partagés : aucun
Sortie prévue dans WebBlocks UI : paragraphe ou texte courant ordinaire ; n'utilisez un rythme wb-stack livré que lorsque plusieurs nœuds de texte l'exigent.
Implémentation actuelle : acceptable
Note de correspondance import/synchronisation : n'utilisez text/plain_text que pour du texte courant simple sans balisage de mise en forme en ligne sûr.
Notes pour les améliorations ultérieures du renderer/de l'administration : garder ce bloc simple et éviter d'en faire un pseudo-bloc de texte enrichi.

Slug du bloc dans le CMS : rich-text
Champs d'administration : content
Champs traduisibles : content
Champs partagés : aucun
Sortie prévue dans WebBlocks UI : texte courant assaini enveloppé dans wb-rich-text wb-rich-text-readable à l'aide de la primitive de texte enrichi livrée par WebBlocks UI.
Implémentation actuelle : acceptable
Modèle de stockage : Rich Text enregistre un fragment HTML sûr et restreint, pas des marqueurs Markdown. Les balises autorisées sont p, strong, em, code, a[href], ul, ol, li et br lorsque nécessaire. Les classes, styles, attributs d'événement, titres, médias, tableaux, boutons et le HTML non pris en charge sont supprimés lors de l'assainissement.
Comportement côté administration : l'éditeur d'administration est une surface contenteditable sans dépendance, synchronisée avec un champ de formulaire masqué. Il est volontairement limité à la mise en forme du texte courant et ne remplace ni Header, Button, Media, Table, Layout, HTML, ni les autres types de blocs dédiés.
Note de correspondance import/synchronisation : lorsque le texte courant importé contient une mise en forme en ligne sûre, plusieurs paragraphes ou des listes simples, il doit devenir rich-text plutôt que text.
Notes pour les améliorations ultérieures du renderer/de l'administration : garder Rich Text limité au texte éditorial sûr. wb-rich-text reste la primitive typographique publique. Les titres, médias, boutons, tableaux, layout et la composition de HTML brut restent des blocs ou des fonctionnalités distincts.

Slug du bloc dans le CMS : html
Champs d'administration : content
Champs traduisibles : content
Champs partagés : aucun
Sortie prévue dans WebBlocks UI : HTML de confiance brut à l'intérieur du wrapper public de bloc habituel.
Implémentation actuelle : acceptable
Notes pour les améliorations ultérieures du renderer/de l'administration : réserver ce bloc à un usage éditorial/administratif de confiance, documenter clairement le risque XSS et ne pas faire dépendre les éditeurs ordinaires de HTML WebBlocks collé pour le contenu normal. Lorsque le HTML de confiance inclut du balisage d'overlay livré par WebBlocks UI, le shell de page publique doit remonter ce contenu d'overlay interne dans le #wb-overlay-root partagé et détenu par la page, plutôt que de rendre des racines d'overlay dupliquées en ligne.

Slug du bloc dans le CMS : section
Champs d'administration : title, variant, content
Champs traduisibles : title, content
Champs partagés : variant
Sortie prévue dans WebBlocks UI : le wrapper par défaut utilise wb-section ; les variantes promo explicites peuvent être associées à wb-promo lorsque le motif livré convient ; les actions CTA doivent provenir de blocs enfants, pas de HTML brut.
Implémentation actuelle : acceptable
Règle de wrapper : le bloc Section possède la véritable racine <section class="wb-section ..."> et porte data-wb-public-block-type="section" sur cet élément. Les wrappers publics génériques de blocs ne doivent pas l'envelopper.
Notes pour les améliorations ultérieures du renderer/de l'administration : garder les sections par défaut stables, traiter promo comme une variante marketing explicite et conserver des boutons et groupes de boutons enfants structurés.
Comportement CTA promo : les blocs button enfants sont rendus dans wb-promo-actions ; les enfants qui ne sont pas des boutons continuent d'être rendus en dehors de la rangée de CTA.

header, section, container, grid, cluster, card et content_header sont des blocs de layout ou de shell de contenu propriétaires de leur racine et ne doivent pas recevoir de wrapper public générique de la boucle publique de blocs.
Section possède la racine sémantique <section class="wb-section"> lorsque nécessaire.
Container, Grid et Cluster possèdent leurs propres racines de layout non sémantiques, sauf si un renderer particulier en décide intentionnellement autrement.
Card possède sa racine <article class="wb-card">.
Card Header, Card Body et Card Footer possèdent leurs racines de région WebBlocks UI correspondantes et définissent ensemble la structure publique normale de Card.
Header possède sa racine de titre sémantique, telle que <h1> ou <h2>.
Content Header possède sa racine sémantique <header class="wb-content-header"> et rend toujours son titre sous forme de <h1 class="wb-content-title">.
La normalisation de la phase 3 Layout + Card garde ces blocs propriétaires de leur racine alignés entre les partials du renderer, Block::ownsPublicRoot(), le registre des contrats, la modale de contrat en lecture seule de l'administration et la commande d'audit des contrats.

Slug du bloc dans le CMS : hero
Champs d'administration : subtitle, title, content, variant
Champs traduisibles : subtitle comme surtitre, title comme titre, content comme texte d'appui
Champs partagés : variant, structure des blocs enfants
Sortie prévue dans WebBlocks UI : wb-promo > .wb-promo-copy avec wb-eyebrow, wb-promo-title, wb-promo-text et wb-promo-actions optionnels
Implémentation actuelle : acceptable
Notes pour les améliorations ultérieures du renderer/de l'administration : les actions CTA du hero doivent provenir de blocs button enfants, le HTML brut ne doit pas servir au contenu ordinaire du hero, et les réglages hero hérités importés ne doivent servir de repli que lorsque les champs traduits canoniques sont vides.
Comportement CTA du hero : les blocs button enfants sont rendus dans wb-promo-actions ; les enfants qui ne sont pas des boutons sont ignorés dans la rangée de CTA.
Règle de wrapper : hero possède désormais sa racine de renderer et y place data-wb-public-block-type="hero", de sorte que la boucle de slot ne doit pas ajouter de wrapper public extérieur générique.

Slug du bloc dans le CMS : columns
Champs d'administration : title, subtitle, content, variant, column_items répétable
Champs traduisibles : title, subtitle, content, texte des column_item enfants
Champs partagés : variant, ordre des enfants, liens des enfants, structure
Sortie prévue dans WebBlocks UI : conteneur de layout pour enfants répétables via wb-grid, wb-grid-2, wb-grid-3, wb-grid-4, ou un wb-grid générique lorsque le nombre est dynamique.
Implémentation actuelle : acceptable
Correspondance des variantes :
cards -> conteneur de grille avec chaque enfant rendu comme wb-card > .wb-card-body
plain -> conteneur de grille avec du contenu enfant empilé et sans cadre
stats -> conteneur de grille avec les éléments enfants rendus comme wb-stat
links -> wb-link-list avec les éléments enfants rendus en lignes de liste de liens
Notes pour les améliorations ultérieures du renderer/de l'administration : laisser au bloc parent la responsabilité du choix de présentation, afin que le contenu existant de column_item reste simple et réutilisable.

Slug du bloc dans le CMS : column_item
Champs d'administration : title, url, content
Champs traduisibles : title, content
Champs partagés : url
Sortie prévue dans WebBlocks UI : une cellule de grille pouvant être rendue en contenu simple, wb-card, wb-stat, wb-link-list-item ou tout autre traitement de cellule livré, selon la variante du parent ou de l'élément.
Implémentation actuelle : acceptable
Notes pour les améliorations ultérieures du renderer/de l'administration : column_item reste une unité de contenu simple et délègue désormais la présentation publique à son bloc columns parent. La correspondance stats actuelle est volontairement prudente car il n'existe pas encore de champ de valeur numérique dédié.

Slug du bloc CMS : cta
Champs d'administration : subtitle, title, content, CTA principal géré, CTA secondaire géré, variant
Champs traduisibles : subtitle en surtitre, title en titre, content en texte d'accompagnement, ainsi que les libellés des button enfants
Champs partagés : variant, les URL des CTA enfants, l'ordre des enfants
Sortie WebBlocks UI attendue : section de style promo wb-card wb-promo avec wb-promo-copy et wb-promo-actions
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : conservez les libellés de CTA rattachés à la langue sur les boutons enfants, gardez les URL de CTA partagées et évitez de réintroduire des charges utiles de CTA pilotées par settings.
Règle de wrapper : cta possède désormais sa propre racine de rendu et place data-wb-public-block-type="cta" sur cette racine ; la boucle de slots ne doit donc pas ajouter de wrapper public externe générique.

Slug du bloc CMS : feature-grid
Champs d'administration : title, subtitle, content, feature_items répétables
Champs traduisibles : title, subtitle, content, le texte des feature-item enfants
Champs partagés : l'ordre des enfants, les liens des enfants, la structure
Sortie WebBlocks UI attendue : la même structure publique de grille de cartes que celle utilisée par columns.variant = cards
Implémentation actuelle : acceptable en tant qu'alias de compatibilité
Notes pour de futures améliorations du moteur de rendu ou de l'administration : conservez Feature Grid adossé au code source et documenté, mais indiquez explicitement qu'il délègue actuellement au moteur de rendu partagé des cartes de Columns au lieu de posséder un balisage feature-grid distinct.

Slug du bloc CMS : feature-item
Champs d'administration : title, url, content
Champs traduisibles : title, content
Champs partagés : url
Sortie WebBlocks UI attendue : la même coque d'élément de type carte que celle utilisée par column_item dans la présentation en cartes de Columns
Implémentation actuelle : acceptable en tant qu'alias de compatibilité
Notes pour de futures améliorations du moteur de rendu ou de l'administration : conservez Feature Item documenté comme un contrat d'enfant auxiliaire adossé au code source tant qu'il délègue encore à la présentation en cartes partagée de Column Item.

Slug du bloc CMS : callout
Champs d'administration : title, variant, content
Champs traduisibles : title, content
Champs partagés : variant
Sortie WebBlocks UI attendue : le comportement d'avis/alerte correspond à wb-alert-* ; les variantes de barre latérale ou d'aide peuvent correspondre à wb-callout si cette primitive existe dans WebBlocks UI.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : gardez la correspondance des tonalités explicite et n'introduisez d'autres coques de callout que lorsque l'UI livrée les propose.

Slug du bloc CMS : quote
Champs d'administration : content, title, subtitle
Champs traduisibles : content, title, subtitle
Champs partagés : aucun
Sortie WebBlocks UI attendue : un blockquote sémantique ; n'utilisez le cadre de carte ou de callout livré que lorsque la citation est intentionnellement présentée comme un témoignage ou une carte encadrée.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : autorisez une variante de citation sémantique sans cadre et n'utilisez testimonial que si cela devient un motif distinct de premier plan.

Slug du bloc CMS : faq
Champs d'administration : title, content
Champs traduisibles : title, content
Champs partagés : aucun
Sortie WebBlocks UI attendue : un simple contenu question/réponse dans une coque stable wb-card et wb-stack.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : FAQ reste simple et rétrocompatible. Lorsqu'il est utilisé comme enfant d'un bloc de la famille accordion, son title et son content font office de résumé et de corps du volet dépliant.

Slug du bloc CMS : accordion
Champs d'administration : title, content
Champs traduisibles : title, content
Champs partagés : la structure et l'ordre des blocs enfants
Sortie WebBlocks UI attendue : des volets dépliants groupés et sémantiques à l'aide de <details> et <summary>, sans JS d'accordéon spécifique ni classes inventées.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : les blocs enfants fournissent les éléments dépliants. Les blocs dépourvus de title et de content exploitables sont ignorés plutôt que rendus sous forme de wrappers vides.

Slug du bloc CMS : faq-list
Champs d'administration : les mêmes attentes éditoriales que accordion
Champs traduisibles : hérités du bloc parent et des éléments enfants
Champs partagés : la structure et l'ordre des blocs enfants
Sortie WebBlocks UI attendue : identique à accordion ; ce slug est désormais un alias transitoire plutôt qu'un motif distinct à long terme.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : gardez l'ancien contenu fonctionnel, mais orientez les futurs usages de volets dépliants groupés vers accordion.

Slug du bloc CMS : tabs
Champs d'administration : title, subtitle, content
Champs traduisibles : title, subtitle, content
Champs partagés : aucun
Sortie WebBlocks UI attendue : un véritable jeu d'onglets interactif si tabs reste un bloc de premier plan.
Implémentation actuelle : faible
Notes pour de futures améliorations du moteur de rendu ou de l'administration : tabs est explicitement reporté jusqu'à ce que WebBlocks UI livre un véritable motif d'onglets. Le traitement actuel en simple carte ne subsiste que comme repli de compatibilité et n'est pas promu.

Slug du bloc CMS : button
Champs d'administration : title, url, subtitle, variant
Champs traduisibles : title
Champs partagés : url, subtitle/cible, variant, relation facultative avec un média joint
Sortie WebBlocks UI attendue : une correspondance explicite des variantes wb-btn pour primary, secondary, outline, ghost et danger ; les valeurs inconnues doivent se rabattre sur wb-btn wb-btn-primary.
Implémentation actuelle : acceptable
Correspondance des variantes :
primary -> wb-btn wb-btn-primary
secondary -> wb-btn wb-btn-secondary
outline -> wb-btn wb-btn-outline
ghost -> wb-btn wb-btn-ghost
danger -> wb-btn wb-btn-danger
inconnu ou vide -> wb-btn wb-btn-primary
Notes pour de futures améliorations du moteur de rendu ou de l'administration : gardez la compatibilité pièce jointe/téléchargement isolée, ne rendez <button type="button"> que lorsqu'il n'y a pas d'URL, et ne formalisez un bloc de groupe de boutons de premier plan que lorsque les éditeurs en auront besoin au-delà des rangées de boutons enfants.

Les blocs de section de type hero et promo doivent modéliser les CTA à l'aide de blocs button enfants.
Les rangées de CTA promo sont rendues dans wb-promo-actions.
En dehors des contextes promo, les rangées d'actions ordinaires peuvent utiliser les utilitaires de cluster livrés, tels que wb-cluster wb-cluster-2.
Un bloc button-group de premier plan est reporté pour l'instant ; le modèle actuel à boutons enfants prend déjà en charge des rangées de CTA structurées sans ajouter de nouvelle architecture de blocs.

Slug du bloc CMS : image
Champs d'administration : media_id, subtitle, url, title
Champs traduisibles : title en légende, subtitle en texte alternatif
Champs partagés : media_id, url
Sortie WebBlocks UI attendue : figure, img et, éventuellement, figcaption sémantiques ; n'utilisez les classes média/carte livrées que lorsque l'image est encadrée intentionnellement.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : la Phase 3 conserve désormais la légende et le texte alternatif sur le chemin de traduction de l'image, préserve l'URL de lien partagée facultative et maintient une sortie sémantique sans wrapper lorsqu'un média existe.

Slug du bloc CMS : gallery
Champs d'administration : lignes compactes de la liste Gallery Items, réglages de présentation partagés de Gallery et fenêtres modales de métadonnées par élément
Champs traduisibles : alt_text, caption, overlay_title et overlay_text de chaque élément de galerie, via block_gallery_item_translations
Champs partagés : la sélection et l'ordre des médias de la galerie, les colonnes, l'espacement, la variante, le rapport d'aspect, le mode des légendes, le mode de superposition et l'interrupteur de lightbox
Sortie WebBlocks UI attendue : le motif de galerie WebBlocks avec la visionneuse montée sous #wb-overlay-root ; les hooks de galerie livrés de WebBlocks UI doivent piloter l'interaction en priorité.
Implémentation actuelle : acceptable
Contrat de rendu public : Gallery n'émet plus de titre ni de paragraphe d'introduction publics. Les anciennes valeurs de titre et de description de Gallery peuvent subsister dans des enregistrements plus anciens, mais le moteur de rendu public les ignore. Les médias de Gallery à rapport d'aspect fixe conservent l'image entière avec un ajustement contain centré, afin que les images de type capture d'écran ne soient pas rognées dans les tuiles fixes.
Contrat éditorial : lorsque des titres de section ou du texte explicatif sont nécessaires, utilisez Content Header plus Plain Text ou Rich Text avant le bloc Gallery.
Notes pour de futures améliorations du moteur de rendu ou de l'administration : le moteur de rendu actuel écrit les médias de galerie ordonnés canoniques via block_media, résout les textes propres à chaque élément et rattachés à la langue via block_gallery_item_translations, préserve les anciens éléments de repli pour le contenu enregistré autrefois et maintient data-wb-gallery-target associé à une seule fenêtre modale de visionneuse partagée sous #wb-overlay-root.

Slug du bloc CMS : download
Champs d'administration : title, subtitle, media_id, variant
Champs traduisibles : title, subtitle
Champs partagés : media_id, variant
Sortie WebBlocks UI attendue : un CTA de fichier sous forme de wb-btn, ou une wb-card compacte accompagnée d'un wb-btn lorsque la variante nécessite davantage de contexte.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : la Phase 3 conserve désormais le libellé visible et le texte d'aide dans les traductions de texte, préserve la propriété partagée du média et de la variante de bouton, et supprime la sortie d'un CTA cassé lorsqu'aucune source média n'existe.

Slug du bloc CMS : contact_form
Champs d'administration : heading, intro_text, submit_label, success_message, recipient_email, send_email_notification, store_submissions
Champs traduisibles : heading, intro_text, submit_label, success_message
Champs partagés : recipient_email, send_email_notification, store_submissions
Comportement attendu : l'envoi public enregistre d'abord le message, puis tente une notification par e-mail synchrone au destinataire résolu ; les vues d'administration doivent afficher un état compact de la notification ainsi qu'un détail d'échec sûr lorsque la remise échoue.
Point de terminaison public d'envoi : formulaire natif du navigateur POST /contact-messages avec CSRF, champ de contrôle anti-spam masqué généré par le CMS, validation obligatoire de name, email et message, subject facultatif et comportement de succès générique pour les envois dont le champ de contrôle est rempli.
Notes : la surcharge du destinataire au niveau du bloc l'emporte d'abord, puis le contact_recipient_email du site public courant, puis CONTACT_RECIPIENT_EMAIL, puis MAIL_FROM_ADDRESS en dernier repli local sûr lorsqu'aucun destinataire de contact explicite n'est configuré.

Slug du bloc CMS : video
Champs d'administration : title, content, url, media_id
Champs traduisibles : title, content
Champs partagés : url, media_id
Sortie WebBlocks UI attendue : un <video controls> sémantique pour les sources directes, ou un <iframe> de fournisseur sûr uniquement pour les URL YouTube/Vimeo connues, à l'intérieur d'une simple coque wb-card.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : la Phase 3 dote désormais Video d'un formulaire d'administration et d'un chemin d'enregistrement dédiés, garde les textes visibles traduits, préserve un rendu qui privilégie les médias hébergés et se rabat sur un simple lien externe pour les URL inconnues sûres plutôt que de les intégrer de manière risquée.

Slug du bloc CMS : audio
Champs d'administration : title, content, url, media_id
Champs traduisibles : title, content
Champs partagés : url, media_id
Sortie WebBlocks UI attendue : un <audio controls> sémantique à l'intérieur d'une simple coque wb-card.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : la Phase 3 dote désormais Audio d'un formulaire d'administration et d'un chemin d'enregistrement dédiés, garde les textes visibles traduits et supprime les contrôles vides lorsqu'aucune source exploitable n'existe.

Slug du bloc CMS : file
Champs d'administration : title, content, url, media_id
Champs traduisibles : title, content
Champs partagés : url, media_id
Sortie WebBlocks UI attendue : une carte de fichier compacte avec une action de téléchargement/ouverture wb-btn wb-btn-secondary.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : la Phase 3 dote désormais File d'un formulaire d'administration et d'un chemin d'enregistrement dédiés, garde les textes visibles traduits et rend explicite le contrat partagé de source média ou URL sans produire d'ancres vides non valides.

Slug du bloc CMS : map
Champs d'administration : title, content, url
Champs traduisibles : aucun
Champs partagés : title, content, url
Sortie WebBlocks UI attendue : un simple résumé de localisation avec un bouton externe Open map, et non un widget de carte spécifique.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : gardez l'implémentation centrée sur le lien tant qu'un véritable motif de carte ou d'intégration livré n'est pas disponible.

Slug du bloc CMS : slider
Champs d'administration : ressources de galerie ordonnées et texte facultatif
Champs traduisibles : aucun
Champs partagés : les ressources et la structure
Sortie WebBlocks UI attendue : aucun moteur de rendu promu en Phase 4 ; utilisez gallery ou d'autres blocs média structurés lorsque c'est possible.
Implémentation actuelle : faible
Notes pour de futures améliorations du moteur de rendu ou de l'administration : slider reste reporté car il n'existe aucun motif de carrousel WebBlocks UI confirmé et livré sur lequel il vaudrait la peine de se standardiser.

Slug du bloc CMS : code
Champs d'administration : title, content
Champs traduisibles : title, content
Champs partagés : settings.language facultatif
Sortie WebBlocks UI attendue : source échappée à l'intérieur d'un <pre><code> sémantique, sans HTML injecté ni dépendance de coloration syntaxique.
Implémentation actuelle : acceptable
Note de correspondance import/synchronisation : les extraits bruts ou multilignes, tels que les exemples <pre><code> et les blocs d'inclusion de paquets, doivent devenir des blocs code et non rich-text.
Notes pour de futures améliorations du moteur de rendu ou de l'administration : gardez le rendu du code sûr et sans dépendances. Des métadonnées de langage facultatives peuvent être exposées depuis les réglages, mais un éditeur de code complet ou une pile de coloration syntaxique restent volontairement hors du périmètre de la Phase 3.

Slug du bloc CMS : toc
Champs d'administration : title
Champs traduisibles : title
Champs partagés : aucun
Sortie WebBlocks UI attendue : un wb-link-list construit à partir des blocs header déjà ancrés sur la même page.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : l'implémentation de la Phase 3 reste volontairement minimale. Elle ne s'affiche que lorsque les blocs Header exposent déjà des identifiants d'ancre explicites et ne tente ni analyse complexe des titres ni génération automatique d'ancres.

Slug du bloc CMS : navigation-auto
Champs d'administration : navigation_menu_key
Champs traduisibles : aucun
Champs partagés : settings.menu_key
Sortie WebBlocks UI attendue : une liste de navigation du site utilisant de simples primitives nav/liste ou wb-link-list lorsque c'est approprié ; ne simulez pas une barre latérale de documentation si le shell de page n'est pas réellement un shell de documentation.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : gardez le bloc centré sur le rendu des arbres de navigation et laissez le slot ou le shell de page décider si la sortie est une navigation d'en-tête, de pied de page ou de documentation.

Slug du bloc CMS : menu
Champs d'administration : navigation_menu_key
Champs traduisibles : aucun
Champs partagés : settings.menu_key
Sortie WebBlocks UI attendue : identique à navigation-auto ; ce bloc reste un alias hérité pour les données migrées.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : conservez la prise en charge des anciens contenus, mais préférez navigation-auto dans l'expérience d'administration et dans les futurs seeds.

tabs, slider, menu et faq-list restent des slugs hérités au stade de brouillon dans le catalogue du CMS, et non des contrats fondamentaux publiés.
showcase-list et contact-info n'existent toujours que comme blocs de compatibilité pour le rendu public et ne sont pas promus dans le catalogue fondamental publié à cette phase.
Cette phase documente honnêtement ces chemins, conserve le rendu de compatibilité là où il est déjà livré et ajoute une désinfection sûre des liens publics issus des réglages, sans introduire de nouveau système JavaScript d'onglets ou de slider.

Slug du bloc CMS : contact_form
Champs d'administration : heading, intro_text, submit_label, success_message, recipient_email, send_email_notification, store_submissions
Champs traduisibles : title/heading, content/intro, submit_label, success_message
Champs partagés : recipient_email, send_email_notification, store_submissions
Sortie WebBlocks UI attendue : les champs du formulaire utilisent les primitives de formulaire de WebBlocks UI ; l'action d'envoi utilise wb-btn ; le retour de succès transitoire s'affiche une seule fois sous forme de toast WebBlocks UI dans le #wb-overlay-root public partagé, tandis que les erreurs de validation et les échecs corrigeables par l'utilisateur restent en ligne près du formulaire avec wb-alert.
Implémentation actuelle : acceptable
Notes pour de futures améliorations du moteur de rendu ou de l'administration : préservez les champs de formulaire structurés, gardez les réglages opérationnels hors du contenu éditorial, conservez les destinataires par défaut du site sur l'enregistrement du site plutôt que dans un JSON de bloc arbitraire, et évitez d'obliger les éditeurs à coller du balisage de formulaire brut ou à utiliser mailto: comme substitut d'envoi.

Bloc CMS	État actuel	Direction souhaitée	Notes
card-grid	rendu public uniquement	devrait rester transitoire	Le moteur de rendu reprend désormais la même structure wb-grid et wb-card que columns.variant = cards, mais il dépend toujours de settings.items. Préférez Columns pour les nouveaux contenus structurés.
showcase-list	rendu public uniquement	devrait rester en repli/personnalisé	Il s'agit actuellement de contenu seedé propre à showcase, qui ne devrait pas devenir fondamental à moins que le motif ne se répète sur plusieurs sites. Les déclencheurs d'image publics doivent continuer à respecter le contrat gallery livré en émettant data-wb-gallery-target et en enregistrant une seule fenêtre modale de visionneuse partagée sous #wb-overlay-root.
contact-info	rendu public uniquement	devrait devenir un bloc de premier ordre	Si les éditeurs continuent d'utiliser des cartes de métadonnées de contact, un petit bloc structuré vaut mieux qu'un contenu personnalisé piloté par les réglages. Le rendu de compatibilité actuel ignore désormais les URL non sûres des réglages au lieu d'émettre des ancres invalides ou dangereuses.
code	moteur de rendu public de premier ordre	acceptable	Le rendu sûr en est désormais en place ; des fonctions d'édition plus riches restent un chantier futur facultatif.
list	moteur de rendu public de premier ordre	acceptable	Un rendu de listes dédié fondé sur les lignes existe désormais ; conservez la compatibilité avec le contenu hérité piloté par les réglages.
table	moteur de rendu public de premier ordre	acceptable	Un rendu de tableaux dédié fondé sur les lignes existe désormais ; conservez la compatibilité avec les lignes héritées des réglages.
accordion	moteur de rendu public de premier ordre	acceptable	Le dépliage groupé utilise désormais des éléments sémantiques et des blocs enfants au lieu d'un balisage de repli issu des réglages.
feature-grid	alias de compatibilité publié	devrait rester transitoire	Le moteur de rendu public délègue à columns.variant = cards ; préférez Columns pour les nouveaux contenus, mais gardez Feature Grid documenté car il repose sur du code livré.
stats	alias uniquement	devrait fusionner avec Columns	Le moteur de rendu public délègue au chemin existant columns.variant = stats et devrait rester documenté comme un comportement d'alias plutôt que comme un contrat publié autonome.
metric-card	alias de premier ordre	devrait fusionner avec les primitives de statistiques	Le moteur de rendu public suit désormais la même orientation wb-stat que la variante stats de Columns.
logo-cloud	repli uniquement	devrait devenir un bloc de premier ordre	Ne le promouvez que s'il existe un besoin récurrent de rangées structurées de logos ou de médias.
testimonial	alias uniquement	devrait fusionner avec Quote	Le moteur de rendu public délègue à la variante testimonial de quote et devrait rester documenté comme un comportement d'alias plutôt que comme un contrat publié autonome.
timeline	repli uniquement	devrait devenir un bloc de premier ordre	Ne le promouvez qu'avec des jalons structurés et un motif d'interface livré et clair.
pricing	repli uniquement	devrait devenir un bloc de premier ordre	Pour valoir la peine d'être promu, un bloc de tarification a besoin de champs structurés pour les offres, les fonctionnalités et les CTA.
toc	moteur de rendu public de premier ordre	acceptable	Le rendu minimal du sommaire utilise désormais les ancres Header existantes et wb-link-list ; le comportement de section active reste reporté.
breadcrumb	repli uniquement	devrait devenir un bloc de premier ordre	Ne l'ajoutez que lorsque le shell public exige réellement un fil d'Ariane.
cookie-notice	repli uniquement	devrait rester en repli/personnalisé	L'interface publique de consentement vit déjà dans le shell de mise en page ; ce bloc ne devrait donc pas concurrencer le motif de confidentialité partagé.

Les moteurs de rendu Blade doivent privilégier les classes wb-* livrées.
Aucune nouvelle classe CSS publique ponctuelle, sauf si elle est documentée comme une lacune de WebBlocks UI.
Aucun script en ligne dans les moteurs de rendu de blocs.
Les blocs interactifs doivent d'abord utiliser les data hooks livrés de WebBlocks UI.
Le JS propre au CMS n'a sa place dans public/cms/js que lorsque c'est nécessaire.
Le contenu des overlays, des boîtes de dialogue et des fenêtres modales doit utiliser #wb-overlay-root.
Les champs d'administration ne doivent pas obliger les éditeurs à coller du HTML WebBlocks UI brut pour les blocs ordinaires.
Dans la mesure du possible, les blocs doivent exposer des champs structurés et des variantes, pas du HTML brut.
README.md doit être mis à jour après toute modification significative du comportement du moteur de rendu ou de l'administration.

Documentation uniquement.
Établir le contrat du moteur de rendu.
Pas encore de réécriture du moteur de rendu.

Aligner la mise en page publique et les conteneurs de slot.
Garantir que le contenu principal puisse être rendu avec wb-content-shell lorsque c'est pertinent.
Ajouter des tests pour la sortie des classes de shell et de slot.

Ne rendre card-grid, button-group et tout futur motif autonome de statistiques ou de témoignages de premier ordre que lorsqu'ils deviennent de véritables contrats portés par le produit plutôt que de simples alias.
Ajouter les formulaires d'administration et la prise en charge dans le registre de traduction là où c'est nécessaire.

Phase 3 terminée : les blocs publics fondamentaux sont désormais alignés sur les primitives de WebBlocks UI.

Migrer le contenu de documentation seedé ou de démonstration vers des blocs de premier ordre.
Supprimer la dépendance au HTML brut ou à settings.items là où un bloc structuré existe.

Primitives WebBlocks UI vérifiées

Modes de layout de la phase 2B

Matrice

Layout de page et slots

Layout public

Card

Conteneurs de slot

Slot header

Slot main

Slot sidebar

Slot footer

Blocs de contenu principaux

`header`

`text`

`rich-text`

`html`

`section`

Règle des wrappers de layout

`hero`

`columns`

`column_item`

`cta`

`feature-grid`

`feature-item`

`callout`

`quote`

`faq`

`accordion`

`faq-list`

`tabs`

`button`

Rangées de CTA

`image`

`gallery`

`download`

`contact_form`

`video`

`audio`

`file`

`map`

`slider`

`code`

`toc`

`navigation-auto`

`menu`

Note héritée / transitoire de la Phase 3

`contact_form`

Blocs faibles ou uniquement publics

Règles du moteur de rendu

Plan des phases

Phase 1

Phase 2

Phase 3

Phase 4