WebBlocks CMS · Contratto del renderer UI dei blocchi

La fase 1 definisce il contratto pubblico di rendering previsto tra i layout, gli slot e i tipi di blocco del CMS e le primitive di WebBlocks UI già distribuite e caricate dal layout pubblico. Questa fase è solo documentale. Non riscrive ancora i renderer.

Verificate rispetto agli asset effettivamente distribuiti e utilizzati dal CMS:

CSS: https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-ui.css
CSS delle icone: 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

Primitive e pattern confermati:

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

Primitive mancanti e lacune dell'interfaccia per ora:

wb-prose — NON TROVATO negli asset distribuiti di WebBlocks UI. Consideratelo una lacuna dell'interfaccia e non fateci affidamento per il layout della fase 2 o per l'allineamento dei renderer.
wb-promo-muted — NON TROVATO negli asset distribuiti di WebBlocks UI.
wb-promo-accent — NON TROVATO negli asset distribuiti di WebBlocks UI.
wb-cluster-3 — NON TROVATO negli asset distribuiti di WebBlocks UI.

Hook JS distribuiti e verificati, rilevanti per l'attuale rendering pubblico:

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

Le pagine pubbliche utilizzano ora modalità esplicite di composizione del layout:

stack è la modalità predefinita.
sidebar viene utilizzata quando la pagina ha uno slot di barra laterale popolato.
content è riservata a future pagine di documentazione o editoriali con metadati espliciti e non deve essere dedotta dall'URL o dal titolo.
wb-content-shell non è un wrapper universale e dovrebbe comparire soltanto quando i metadati della pagina supportano esplicitamente una presentazione di tipo content-shell.

Blocco del CMS	Primitiva/pattern di WebBlocks UI	Stato	Priorità	Azione successiva
layout pubblico	wb-public-body, wb-public-main, wb-container	accettabile	P0 shell/layout	mantenere stabile la shell e avvicinare il chrome specifico degli slot alle primitive documentate
slot dell'intestazione	wb-section, wb-container, primitive di navigazione/elenco	debole	P0 shell/layout	allineare il chrome personalizzato dell'intestazione alle regole documentate della shell
slot principale	wb-public-main, wb-container, wb-content-shell	accettabile	P0 shell/layout	aggiungere l'uso di wb-content-shell dove il contenuto si legge come articolo o documentazione
slot della barra laterale	wb-grid, wb-stack, facoltativamente un aside con wb-content-shell	debole	P0 shell/layout	smettere di trattare le barre laterali generiche come finte barre laterali applicative
slot del piè di pagina	wb-section, wb-container, wb-grid, primitive di elenco di link/navigazione	accettabile	P0 shell/layout	mantenere il piè di pagina sulle primitive di layout distribuite ed evitare classi personalizzate aggiuntive
heading	legacy rimosso	ritirato	P0 rimosso	non reintrodurlo; header è il blocco canonico di intestazione/titolo
text	testo del corpo nel ritmo di wb-stack	accettabile	P2 qualità dei contenuti	mantenere un output semplice ed evitare wrapper tipografici su misura
rich-text	wb-rich-text wb-rich-text-readable	accettabile	P2 qualità dei contenuti	mantenere il testo del corpo sicuro circoscritto alla primitiva di testo ricco distribuita
html	HTML grezzo attendibile nel wrapper del blocco pubblico	accettabile	P3 successivo/personalizzato	mantenerlo limitato all'uso editoriale/amministrativo attendibile e spostare qualsiasi contenuto di overlay distribuito nella radice di overlay condivisa della pagina
section	wb-section, facoltativamente wb-promo	accettabile	P1 marketing pubblico/docs	mantenere stabile la sezione predefinita e riservare la semantica promo a varianti esplicite
columns	wb-grid, wb-grid-2, wb-grid-3, wb-grid-4, wb-link-list	accettabile	P1 marketing pubblico/docs	mantenere esplicite le varianti guidate dal genitore ed evitare di reintrodurre card wrapper forzate
column_item	cella semplice, wb-card, wb-stat o voce di elenco di link	accettabile	P1 marketing pubblico/docs	mantenere il rendering della voce guidato dalla mappatura columns.variant del genitore
callout	wb-alert, facoltativamente wb-callout	accettabile	P2 qualità dei contenuti	ampliare la mappatura delle varianti se esiste un callout distribuito per barra laterale/aiuto
quote	blockquote semantico, facoltativamente una card incorniciata	accettabile	P2 qualità dei contenuti	rendere la cornice condizionale anziché sempre simile a una card
faq	semplice card domanda/risposta	accettabile	P3 personalizzato/ripiego	mantenere il trattamento stabile a card singola e lasciare la divulgazione raggruppata ai blocchi accordion
tabs	pattern di schede interattive	debole	P2 qualità dei contenuti	rinviare finché non esiste un vero pattern di schede distribuito
button	varianti di wb-btn	debole	P1 marketing pubblico/docs	mappare tutte le varianti supportate dal CMS e aggiungere la direzione del gruppo di pulsanti
image	figure, img, figcaption semantici	debole	P2 qualità dei contenuti	rispettare il comportamento del link e aggiungere la cornice media solo quando serve
gallery	wb-gallery più il modale della radice di overlay	accettabile	P1 marketing pubblico/docs	continuare a usare gli hook di galleria distribuiti e la radice di overlay centrale, mantenendo il testo introduttivo fuori dal blocco Gallery stesso
download	wb-btn oppure CTA card con pulsante	accettabile	P2 qualità dei contenuti	aggiungere in seguito varianti esplicite card/download
navigation-auto	primitive di navigazione/elenco, facoltativamente wb-link-list	accettabile	P1 marketing pubblico/docs	mantenere semplici i menu semplici e riservare le barre laterali di documentazione a vere shell di documentazione
menu	alias legacy di navigation-auto	accettabile	P3 successivo/personalizzato	mantenerlo solo per i dati migrati
contact_form	primitive di form, wb-btn, wb-alert	accettabile	P1 marketing pubblico/docs	mantenere i campi strutturati dell'editor ed evitare form in HTML grezzo
hero	shell di marketing wb-promo	accettabile	P1 marketing pubblico/docs	mantenere l'hero di primo livello, tradotto e orientato all'azione tramite blocchi pulsante figli
card-grid	pattern a griglia di card	debole	P1 marketing pubblico/docs	mantenere stabile l'attuale griglia di card strutturata e rivedere in seguito una modellazione di primo livello
showcase-list	pattern vetrina/galleria	debole	P3 successivo/personalizzato	formalizzarlo come blocco vetrina di primo livello oppure mantenerlo personalizzato
contact-info	elenco di link / card con dati di contatto	debole	P2 qualità dei contenuti	promuoverlo a primo livello solo se gli editor ne hanno bisogno oltre le pagine precaricate
code	pattern di blocco di codice	mancante	P2 qualità dei contenuti	aggiungere un supporto di primo livello nel renderer e nell'amministrazione oppure mantenere deliberatamente il ripiego
list	primitiva di elenco	accettabile	P1 marketing pubblico/docs	mantenere l'editor dedicato basato sulle righe e preservare la compatibilità con le impostazioni di stile di ripiego legacy
table	pattern wb-table	accettabile	P1 marketing pubblico/docs	mantenere l'editor dedicato basato sulle righe e preservare le righe di impostazioni di stile di ripiego legacy
accordion	pattern di divulgazione semantico	accettabile	P1 marketing pubblico/docs	mantenere il renderer semantico di primo livello con blocchi figli come voci
feature-grid	pattern delegato columns.variant = cards	accettabile	P1 marketing pubblico/docs	mantenerlo pubblicato come alias di compatibilità, ma preferire columns per i nuovi contenuti strutturati
stats / metric-card	pattern delegato columns.variant = stats	debole	P1 marketing pubblico/docs	mantenere onesti gli alias e aggiungere veri contratti specifici per le statistiche solo se diventano di proprietà del prodotto
logo-cloud	griglia di loghi / striscia di marchi	debole	P1 marketing pubblico/docs	aggiungere una gestione strutturata dei media se resta parte del prodotto
testimonial	pattern di testimonianza delegato alla citazione	debole	P2 qualità dei contenuti	mantenere onesto il comportamento dell'alias, a meno che un contratto autonomo di testimonianza non diventi di proprietà del prodotto
timeline	pattern di linea temporale	debole	P2 qualità dei contenuti	promuoverlo solo se i contenuti di linea temporale sono un caso d'uso ricorrente reale
pricing	pattern card/griglia di prezzi	debole	P1 marketing pubblico/docs	renderlo di primo livello solo con piani e funzionalità strutturati
toc	navigazione dell'indice dei contenuti	accettabile	P1 marketing pubblico/docs	mantenere la raccolta dell'indice della stessa pagina solo sui blocchi header con ancora esplicita
breadcrumb	navigazione breadcrumb	mancante	P2 qualità dei contenuti	rinviare finché la shell della pagina pubblica non ne ha davvero bisogno e non è confermato un pattern distribuito
cookie-notice	pattern condiviso di banner/modale sulla privacy	mancante	P3 successivo/personalizzato	mantenere l'interfaccia di consenso nel layout pubblico anziché nei renderer dei blocchi

Il layout pubblico possiede la shell dell'intera pagina e dovrebbe mantenere il contratto di base <body class="wb-public-body">.
Page Layout è il nome rivolto all'editor per la modalità della shell pubblica esterna.
Il campo di compatibilità memorizzato resta public_shell in questa fase, ma i Page Layout sono ora record gestiti a livello di installazione nell'area di amministrazione.
Page Layout può aggiungere a quella classe di body di base classi validate come layout-default o layout-docs.
Le regioni principali della pagina dovrebbero essere costruite anzitutto con le primitive di layout distribuite di WebBlocks UI: wb-public-main, wb-container, wb-section, wb-stack, wb-grid.
wb-content-shell, wb-content-header, wb-content-body e wb-content-footer appartengono all'area del contenuto principale quando la pagina si legge come articolo, guida, documentazione o contenuto editoriale. Non sono il chrome di intestazione o di piè di pagina dell'intero sito.
#wb-overlay-root è l'unico punto di montaggio condiviso per gli overlay pubblici, come il visualizzatore della galleria, il modale di ricerca pubblica e il modale delle preferenze sui cookie.
I layout pubblici possiedono quel wrapper; blocchi, partial e HTML attendibile possono contribuire con figli di overlay, ma non devono renderizzare contenitori radice di overlay concorrenti.
L'HTML importato attendibile che utilizza gli hook di attivazione distribuiti di WebBlocks UI deve preservare il contratto tra trigger e destinazione. Se un trigger all'interno del contenuto principale importato punta a un modale, un drawer, un popover o un visualizzatore di galleria esterno a <main>, l'estrattore deve spostare la destinazione referenziata nel #wb-overlay-root condiviso invece di scartarla.
Quando il CMS pre-renderizza un livello di dialogo condiviso sotto #wb-overlay-root, quel livello deve restare non nascosto affinché WebBlocks UI v2.7.12 possa portare al suo interno le destinazioni attendibili di modali e gallerie senza lasciarle dentro un antenato nascosto.

card possiede article.wb-card come radice del renderer, con data-wb-public-block-type="card".
card_header possiede div.wb-card-header, con data-wb-public-block-type="card-header".
card_body possiede div.wb-card-body, con data-wb-public-block-type="card-body".
card_footer possiede div.wb-card-footer, con data-wb-public-block-type="card-footer".
Le regioni della Card dovrebbero renderizzare direttamente le proprie radici e non devono ricevere wrapper pubblici generici aggiuntivi.
Il normale contratto della Card prevede contenuti figli componibili attraverso quelle tre regioni, non un renderer promo o media integrato.
Le righe Card salvate in passato possono ancora utilizzare un renderer di ripiego minimale, ma soltanto quando la Card non ha regioni Card figlie.
wb-sidebar è riservato a una vera shell di navigazione per documentazione o applicazioni. Le barre laterali generiche di marketing o editoriali dovrebbero restare normale contenuto aside, composto con wb-grid, wb-stack, card, callout ed elenchi di link.

I wrapper di slot sono comportamento deterministico di runtime, non impostazioni editoriali libere a livello di pagina.
L'handle del layout di pagina si risolve prima su un record gestito Page Layout quando disponibile, e i Page Layout Slots gestiti di quel record vengono poi usati per risolvere elemento, classi, id e frammenti strutturali fidati del wrapper di slot.
Il confronto in Edit Page e Add Missing Layout Slots cambiano la struttura della pagina solo creando i Page Slots mancanti; non cambiano la proprietà del wrapper pubblico.
I campi HTML fidati di Page Layout Slot esistono solo per la struttura di layout adiacente al wrapper. Non sono una superficie per script, e i blocchi restano proprietari delle radici di contenuto renderizzate dentro il wrapper di slot.
Quando uno slot di intestazione pubblico predefinito contiene solo un blocco Navbar, il CMS promuove il wrapper di slot alla radice nav.wb-navbar, così il comportamento sticky di WebBlocks UI non è vincolato da un riquadro di intestazione padre troppo basso.
wb-navbar--static resta la classe di esclusione per i blocchi Navbar pubblici non sticky.
default mappa header, main, sidebar e footer su wrapper semantici e ricade su div per gli slot sconosciuti.
docs mappa header sul wrapper della navbar dei docs, sidebar sul wrapper della barra laterale dei docs e main sul wrapper principale dei docs, mantenendo wb-dashboard-shell di proprietà della pagina.
I layout integrati default e docs conservano definizioni gestite di ripiego, così il rendering resta stabile prima delle righe di slot relazionali o in loro assenza.
I blocchi vengono renderizzati dentro il wrapper di slot risolto e non possiedono il markup dello shell di pagina.
Il comportamento sticky della navbar appartiene a .wb-navbar. Il CMS non dovrebbe aggiungere una seconda classe sticky specifica della navbar al wrapper di slot né all'output del blocco navbar.
Quando uno slot di pagina usa source_type = shared_slot, lo Shared Slot contribuisce solo l'albero di blocchi interno. Non deve renderizzare un proprio shell di pagina né un proprio wrapper di slot.
La compatibilità dello Shared Slot viene verificata prima del rendering: l'ambito del sito deve corrispondere, l'opzionale public_shell deve corrispondere esattamente all'handle del layout della pagina consumatrice e l'opzionale slot_name deve corrispondere allo slot della pagina consumatrice.
I wrapper pubblici generici dei blocchi devono restare non semantici e non devono essere usati per blocchi di layout o proprietari della radice.
Lo shell di pagina possiede lo shell esterno, i wrapper di slot possiedono il wrapper di regione e i blocchi proprietari della radice possiedono il proprio vero elemento radice pubblico.
I blocchi proprietari della radice devono collocare data-wb-public-block-type sulla propria radice di renderer invece di ricevere un ulteriore wrapper esterno wb-public-block.

Mappatura prevista: regione header costruita con wb-section e wb-container, con all'interno le primitive di navigazione ed elenco fornite.
Usate wb-stack o wb-grid per il ritmo interno, a seconda che l'intestazione si legga come banner impilato o come barra di navigazione orizzontale.
La navigazione principale o legale può essere renderizzata tramite navigation-auto o menu, ma lo slot non dovrebbe richiedere ai renderer di blocco di emettere HTML specifico dell'intestazione.
L'implementazione attuale è debole perché lo slot di intestazione possiede diverse classi di chrome wb-public-* personalizzate. La fase 2A mantiene intatto lo shell esistente di wb-section e wb-container e rimanda a un passaggio successivo qualsiasi riduzione sicura del chrome di intestazione personalizzato.

Mappatura prevista: <main class="wb-public-main"> è la regione di contenuto principale.
Shell predefinito: wb-public-main > .wb-container > .wb-stack per le normali pile di blocchi.
Shell editoriale/docs: wb-public-main > .wb-container > .wb-content-shell con sezioni opzionali wb-content-header, wb-content-body e wb-content-footer.
Il layout dei blocchi annidati dovrebbe usare wb-stack, wb-stack-, wb-gap-, wb-grid e wb-grid-* prima di qualsiasi classe wrapper personalizzata.
L'implementazione attuale è accettabile perché dà già allo slot main un wrapper pubblico stabile e un ritmo dei blocchi. La fase 2B aggiunge modalità di layout esplicite, così wb-content-shell resta riservato invece di essere imposto a ogni pagina.

Mappatura prevista: aside adiacente al contenuto principale tramite wb-grid o un'altra primitiva di layout fornita.
Il contenuto predefinito dovrebbe essere uno wb-stack di blocchi di supporto, eventualmente raggruppati in un wb-card o un wb-callout se ciò corrisponde al contenuto del blocco.
wb-sidebar dovrebbe essere usato solo quando la pagina renderizza esplicitamente uno shell di navigazione docs/app, non per generici contenuti di marketing di supporto.
L'implementazione attuale è debole perché usa ancora uno shell wb-public-sidebar personalizzato. La fase 2A rimuove il wrapper esterno wb-card forzato, così i blocchi interni decidono se renderizzarsi come card o come callout.

Mappatura prevista: regione footer costruita con wb-section, wb-container e wb-grid o wb-stack.
Gli elenchi di navigazione dovrebbero usare semplici primitive di navigazione/elenco oppure wb-link-list quando il pattern di interfaccia fornito è adatto.
I blocchi di contenuto di supporto possono essere renderizzati normalmente dentro il piè di pagina; non dovrebbero richiedere renderer di blocco specifici del piè di pagina.
L'implementazione attuale è accettabile perché resta vicina alle primitive di layout fornite, con solo un minimo di chrome di piè di pagina specifico del CMS attorno al controllo delle impostazioni dei cookie.

Slug del blocco nel CMS: header
Campi di amministrazione: text, level, anchor
Campi traducibili: testo di title
Campi condivisi: variant/level, impostazione di allineamento, anchor
Output previsto in WebBlocks UI: <h1>-<h6> semantico in base a level; id opzionale dall'anchor condiviso; nessun wrapper inventato oltre all'elemento di intestazione.
Implementazione attuale: accettabile
Contratto del TOC: gli anchor condivisi espliciti sono l'unica fonte supportata per il TOC, e il TOC pubblico raccoglie i blocchi header con anchor dallo stesso albero di pagina renderizzato, inclusi i discendenti di layout annidati.
Note per successivi miglioramenti di renderer/amministrazione: mantenere esplicito il comportamento degli anchor, conservare l'output privo di wrapper e mantenere la semantica dei titoli in capo a Header invece che a un blocco legacy parallelo.

Slug del blocco nel CMS: text
Campi di amministrazione: content
Campi traducibili: content
Campi condivisi: nessuno
Output previsto in WebBlocks UI: paragrafo o testo corrente ordinario; usate un ritmo wb-stack fornito solo quando serve per più nodi di testo.
Implementazione attuale: accettabile
Nota di mappatura import/sync: usate text/plain_text solo per testo corrente semplice senza markup di formattazione inline sicuro.
Note per successivi miglioramenti di renderer/amministrazione: mantenere semplice questo blocco ed evitare di trasformarlo in uno pseudo blocco di testo ricco.

Slug del blocco nel CMS: rich-text
Campi di amministrazione: content
Campi traducibili: content
Campi condivisi: nessuno
Output previsto in WebBlocks UI: testo corrente sanificato racchiuso in wb-rich-text wb-rich-text-readable usando la primitiva di testo ricco fornita da WebBlocks UI.
Implementazione attuale: accettabile
Modello di archiviazione: Rich Text salva un frammento HTML sicuro e limitato, non marcatori Markdown. I tag consentiti sono p, strong, em, code, a[href], ul, ol, li e br quando serve. Classi, stili, attributi di evento, titoli, media, tabelle, pulsanti e HTML non supportato vengono rimossi durante la sanificazione.
Comportamento in amministrazione: l'editor di amministrazione è una superficie contenteditable priva di dipendenze, sincronizzata con un campo di form nascosto. È volutamente limitato alla formattazione del testo corrente e non sostituisce Header, Button, Media, Table, Layout, HTML o altri tipi di blocco dedicati.
Nota di mappatura import/sync: quando il testo corrente importato contiene formattazione inline sicura, più paragrafi o elenchi semplici, dovrebbe diventare rich-text anziché text.
Note per successivi miglioramenti di renderer/amministrazione: mantenere Rich Text limitato al testo editoriale sicuro. wb-rich-text resta la primitiva tipografica pubblica. Titoli, media, pulsanti, tabelle, layout e composizione di HTML grezzo restano blocchi o funzionalità separati.

Slug del blocco nel CMS: html
Campi di amministrazione: content
Campi traducibili: content
Campi condivisi: nessuno
Output previsto in WebBlocks UI: HTML fidato grezzo dentro il normale wrapper pubblico del blocco.
Implementazione attuale: accettabile
Note per successivi miglioramenti di renderer/amministrazione: riservare questo blocco a un uso editoriale/amministrativo fidato, documentare chiaramente il rischio XSS e non far dipendere gli editor ordinari da HTML WebBlocks incollato per i contenuti normali. Quando l'HTML fidato include markup di overlay fornito da WebBlocks UI, lo shell della pagina pubblica dovrebbe sollevare quel contenuto di overlay interno nel #wb-overlay-root condiviso e di proprietà della pagina, invece di renderizzare radici di overlay duplicate inline.

Slug del blocco nel CMS: section
Campi di amministrazione: title, variant, content
Campi traducibili: title, content
Campi condivisi: variant
Output previsto in WebBlocks UI: il wrapper predefinito usa wb-section; le varianti promo esplicite possono mappare su wb-promo quando il pattern fornito è adatto; le azioni CTA dovrebbero provenire da blocchi figli, non da HTML grezzo.
Implementazione attuale: accettabile
Regola del wrapper: il blocco Section possiede la vera radice <section class="wb-section ..."> e porta data-wb-public-block-type="section" su quell'elemento. I wrapper pubblici generici dei blocchi non devono avvolgerlo.
Note per successivi miglioramenti di renderer/amministrazione: mantenere stabili le sezioni predefinite, trattare promo come variante di marketing esplicita e mantenere strutturati i pulsanti e i gruppi di pulsanti figli.
Comportamento della CTA promo: i blocchi button figli vengono renderizzati in wb-promo-actions; i figli non pulsanti continuano a essere renderizzati fuori dalla riga CTA.

header, section, container, grid, cluster, card e content_header sono blocchi di layout o di shell di contenuto che possiedono la propria radice e non dovrebbero ricevere un wrapper pubblico generico dal loop pubblico dei blocchi.
Section possiede la radice semantica <section class="wb-section"> quando serve.
Container, Grid e Cluster possiedono le proprie radici di layout non semantiche, a meno che uno specifico renderer non scelga intenzionalmente diversamente.
Card possiede la propria radice <article class="wb-card">.
Card Header, Card Body e Card Footer possiedono le rispettive radici di regione di WebBlocks UI e insieme definiscono la normale struttura pubblica di Card.
Header possiede la propria radice di titolo semantica, come <h1> o <h2>.
Content Header possiede la propria radice semantica <header class="wb-content-header"> e rende sempre il proprio titolo come <h1 class="wb-content-title">.
La standardizzazione della fase 3 di Layout + Card mantiene allineati questi blocchi proprietari della radice tra i partial del renderer, Block::ownsPublicRoot(), il registro dei contratti, la modale di contratto in sola lettura dell'amministrazione e il comando di audit dei contratti.

Slug del blocco nel CMS: hero
Campi di amministrazione: subtitle, title, content, variant
Campi traducibili: subtitle come occhiello, title come titolo, content come testo di supporto
Campi condivisi: variant, struttura dei blocchi figli
Output previsto in WebBlocks UI: wb-promo > .wb-promo-copy con wb-eyebrow, wb-promo-title, wb-promo-text e wb-promo-actions opzionali
Implementazione attuale: accettabile
Note per successivi miglioramenti di renderer/amministrazione: le azioni CTA dell'hero dovrebbero provenire da blocchi button figli, l'HTML grezzo non dovrebbe essere usato per il normale contenuto dell'hero e le impostazioni hero importate legacy dovrebbero agire solo come ripiego quando i campi tradotti canonici sono vuoti.
Comportamento della CTA dell'hero: i blocchi button figli vengono renderizzati in wb-promo-actions; i figli non pulsanti sono ignorati nella riga CTA.
Regola del wrapper: hero ora possiede la propria radice di renderer e vi colloca data-wb-public-block-type="hero", quindi il loop dello slot non deve aggiungere un wrapper pubblico esterno generico.

Slug del blocco nel CMS: columns
Campi di amministrazione: title, subtitle, content, variant, column_items ripetibile
Campi traducibili: title, subtitle, content, testo dei column_item figli
Campi condivisi: variant, ordinamento dei figli, link dei figli, struttura
Output previsto in WebBlocks UI: contenitore di layout per figli ripetibili tramite wb-grid, wb-grid-2, wb-grid-3, wb-grid-4 oppure un wb-grid generico quando il numero è dinamico.
Implementazione attuale: accettabile
Mappatura delle varianti:
cards -> contenitore a griglia con ogni figlio renderizzato come wb-card > .wb-card-body
plain -> contenitore a griglia con contenuto figlio impilato e senza cornice
stats -> contenitore a griglia con gli elementi figli renderizzati come wb-stat
links -> wb-link-list con gli elementi figli renderizzati come righe di elenco di link
Note per successivi miglioramenti di renderer/amministrazione: mantenere nel blocco padre la responsabilità della scelta di presentazione, così il contenuto esistente di column_item può restare semplice e riutilizzabile.

Slug del blocco nel CMS: column_item
Campi di amministrazione: title, url, content
Campi traducibili: title, content
Campi condivisi: url
Output previsto in WebBlocks UI: una cella di griglia che può essere renderizzata come contenuto semplice, wb-card, wb-stat, wb-link-list-item o altro trattamento di cella fornito, a seconda della variante del padre o dell'elemento.
Implementazione attuale: accettabile
Note per successivi miglioramenti di renderer/amministrazione: column_item resta una semplice unità di contenuto e ora delega la presentazione pubblica al blocco columns padre. L'attuale mappatura stats è volutamente conservativa perché non esiste ancora un campo di valore numerico dedicato.

Slug del blocco CMS: cta
Campi di amministrazione: subtitle, title, content, CTA principale gestita, CTA secondaria gestita, variant
Campi traducibili: subtitle come occhiello, title come titolo, content come testo di supporto, oltre alle etichette dei button figli
Campi condivisi: variant, gli URL delle CTA figlie, l'ordinamento dei figli
Output previsto di WebBlocks UI: sezione in stile promozionale wb-card wb-promo con wb-promo-copy e wb-promo-actions
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete le etichette delle CTA di proprietà della lingua sui pulsanti figli, mantenete condivisi gli URL delle CTA ed evitate di reintrodurre payload di CTA basati su settings.
Regola del wrapper: cta ora possiede la propria radice di rendering e colloca data-wb-public-block-type="cta" su tale radice, quindi il ciclo degli slot non deve aggiungere un wrapper pubblico esterno generico.

Slug del blocco CMS: feature-grid
Campi di amministrazione: title, subtitle, content, feature_items ripetibili
Campi traducibili: title, subtitle, content, il testo dei feature-item figli
Campi condivisi: l'ordinamento dei figli, i link dei figli, la struttura
Output previsto di WebBlocks UI: la stessa struttura pubblica a griglia di card utilizzata da columns.variant = cards
Implementazione attuale: accettabile come alias di compatibilità
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete Feature Grid supportato dal codice sorgente e documentato, ma rendete esplicito che attualmente delega al renderer condiviso delle card di Columns invece di possedere un markup feature-grid distinto.

Slug del blocco CMS: feature-item
Campi di amministrazione: title, url, content
Campi traducibili: title, content
Campi condivisi: url
Output previsto di WebBlocks UI: lo stesso guscio di elemento in stile card utilizzato da column_item nella presentazione a card di Columns
Implementazione attuale: accettabile come alias di compatibilità
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete Feature Item documentato come contratto di figlio di supporto basato sul codice sorgente finché continua a delegare alla presentazione a card condivisa di Column Item.

Slug del blocco CMS: callout
Campi di amministrazione: title, variant, content
Campi traducibili: title, content
Campi condivisi: variant
Output previsto di WebBlocks UI: il comportamento di avviso/alert corrisponde a wb-alert-*; le varianti per barra laterale o aiuto possono corrispondere a wb-callout se quella primitiva esiste in WebBlocks UI.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete esplicita la corrispondenza dei toni e introducete gusci di callout alternativi solo quando la UI rilasciata li prevede.

Slug del blocco CMS: quote
Campi di amministrazione: content, title, subtitle
Campi traducibili: content, title, subtitle
Campi condivisi: nessuno
Output previsto di WebBlocks UI: un blockquote semantico; utilizzate la cornice a card o callout rilasciata solo quando la citazione è presentata intenzionalmente come testimonianza o card incorniciata.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: consentite una variante di citazione semantica senza cornice e utilizzate testimonial solo se diventerà un pattern autonomo di primo livello.

Slug del blocco CMS: faq
Campi di amministrazione: title, content
Campi traducibili: title, content
Campi condivisi: nessuno
Output previsto di WebBlocks UI: semplice contenuto domanda/risposta in un guscio stabile wb-card e wb-stack.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: FAQ resta semplice e retrocompatibile. Quando è usato come figlio di un blocco della famiglia accordion, il suo title e il suo content fungono da riepilogo e corpo dell'elemento a scomparsa.

Slug del blocco CMS: accordion
Campi di amministrazione: title, content
Campi traducibili: title, content
Campi condivisi: la struttura e l'ordinamento dei blocchi figli
Output previsto di WebBlocks UI: elementi a scomparsa raggruppati e semantici tramite <details> e <summary>, senza JS di accordion personalizzato né classi inventate.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: i blocchi figli forniscono gli elementi a scomparsa. I blocchi privi di un title e di un content utilizzabili vengono saltati anziché resi come wrapper vuoti.

Slug del blocco CMS: faq-list
Campi di amministrazione: le stesse aspettative editoriali di accordion
Campi traducibili: ereditati dal blocco padre e dagli elementi figli
Campi condivisi: la struttura e l'ordinamento dei blocchi figli
Output previsto di WebBlocks UI: lo stesso di accordion; questo slug è ora un alias di transizione e non un pattern separato di lungo periodo.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete funzionante il contenuto esistente, ma orientate l'uso futuro degli elementi a scomparsa raggruppati verso accordion.

Slug del blocco CMS: tabs
Campi di amministrazione: title, subtitle, content
Campi traducibili: title, subtitle, content
Campi condivisi: nessuno
Output previsto di WebBlocks UI: un vero set di schede interattivo se tabs resta un blocco di primo livello.
Implementazione attuale: debole
Note per futuri miglioramenti del renderer o dell'amministrazione: tabs è esplicitamente rinviato finché WebBlocks UI non rilascia un vero pattern di schede. L'attuale trattamento a card semplice resta solo come fallback di compatibilità e non viene promosso.

Slug del blocco CMS: button
Campi di amministrazione: title, url, subtitle, variant
Campi traducibili: title
Campi condivisi: url, subtitle/target, variant, relazione facoltativa con un media allegato
Output previsto di WebBlocks UI: corrispondenza esplicita delle varianti wb-btn per primary, secondary, outline, ghost e danger; i valori sconosciuti devono ricadere su wb-btn wb-btn-primary.
Implementazione attuale: accettabile
Corrispondenza delle varianti:
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
sconosciuto o vuoto -> wb-btn wb-btn-primary
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete isolata la compatibilità con allegati e download, rendete <button type="button"> solo quando non esiste un URL e formalizzate un blocco gruppo di pulsanti di primo livello solo quando gli editor ne avranno bisogno oltre alle righe di pulsanti figli.

I blocchi sezione di tipo hero e promozionale dovrebbero modellare le CTA con blocchi button figli.
Le righe di CTA promozionali vengono rese in wb-promo-actions.
Al di fuori dei contesti promozionali, le normali righe di azione possono utilizzare le utility cluster rilasciate, come wb-cluster wb-cluster-2.
Un blocco button-group di primo livello è per ora rinviato; l'attuale modello a pulsanti figli supporta già righe di CTA strutturate senza aggiungere nuova architettura di blocchi.

Slug del blocco CMS: image
Campi di amministrazione: media_id, subtitle, url, title
Campi traducibili: title come didascalia, subtitle come testo alternativo
Campi condivisi: media_id, url
Output previsto di WebBlocks UI: figure, img ed eventualmente figcaption semantici; utilizzate le classi media/card rilasciate solo quando l'immagine è incorniciata intenzionalmente.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: la Fase 3 ora mantiene didascalia e testo alternativo sul percorso di traduzione dell'immagine, conserva l'URL di collegamento condiviso facoltativo e mantiene un output semantico privo di wrapper quando il media esiste.

Slug del blocco CMS: gallery
Campi di amministrazione: righe compatte dell'elenco Gallery Items, impostazioni di presentazione condivise di Gallery e modali di metadati per singolo elemento
Campi traducibili: alt_text, caption, overlay_title e overlay_text per ciascun elemento della galleria, tramite block_gallery_item_translations
Campi condivisi: selezione e ordinamento dei media della galleria, colonne, spaziatura, variante, proporzioni, modalità didascalie, modalità overlay e interruttore lightbox
Output previsto di WebBlocks UI: il pattern gallery di WebBlocks con il visualizzatore montato sotto #wb-overlay-root; gli hook gallery rilasciati di WebBlocks UI dovrebbero guidare per primi l'interazione.
Implementazione attuale: accettabile
Contratto di rendering pubblico: Gallery non emette più un'intestazione o un paragrafo introduttivo pubblici. I valori legacy di titolo e descrizione di Gallery possono restare memorizzati nei record più vecchi, ma vengono ignorati dal renderer pubblico. I media di Gallery con proporzioni fisse conservano l'immagine intera con adattamento contain centrato, così le immagini in stile screenshot non vengono ritagliate all'interno dei riquadri fissi.
Contratto editoriale: quando servono intestazioni di sezione o testi esplicativi, utilizzate Content Header più Plain Text o Rich Text prima del blocco Gallery.
Note per futuri miglioramenti del renderer o dell'amministrazione: il renderer attuale scrive i media ordinati canonici della galleria tramite block_media, risolve i testi di ciascun elemento di proprietà della lingua tramite block_gallery_item_translations, conserva gli elementi di fallback legacy per i contenuti salvati in precedenza e mantiene data-wb-gallery-target abbinato a un unico modale visualizzatore condiviso sotto #wb-overlay-root.

Slug del blocco CMS: download
Campi di amministrazione: title, subtitle, media_id, variant
Campi traducibili: title, subtitle
Campi condivisi: media_id, variant
Output previsto di WebBlocks UI: una CTA di file come wb-btn, oppure una wb-card compatta più un wb-btn quando la variante richiede più contesto.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: la Fase 3 ora mantiene l'etichetta visibile e il testo di supporto nelle traduzioni testuali, conserva la proprietà condivisa del media e della variante del pulsante e sopprime l'output di una CTA non funzionante quando non esiste una sorgente media.

Slug del blocco CMS: contact_form
Campi di amministrazione: heading, intro_text, submit_label, success_message, recipient_email, send_email_notification, store_submissions
Campi traducibili: heading, intro_text, submit_label, success_message
Campi condivisi: recipient_email, send_email_notification, store_submissions
Comportamento previsto: l'invio pubblico memorizza prima il messaggio, poi tenta una notifica email sincrona al destinatario risolto; le viste di amministrazione dovrebbero mostrare uno stato compatto della notifica e un dettaglio sicuro dell'errore quando la consegna fallisce.
Endpoint pubblico di invio: modulo nativo del browser POST /contact-messages con CSRF, campo di controllo antispam nascosto generato dal CMS, validazione obbligatoria di name, email e message, subject facoltativo e comportamento di successo generico per gli invii con il campo di controllo compilato.
Note: la sovrascrittura del destinatario nel blocco ha la precedenza, poi il contact_recipient_email del sito pubblico corrente, poi CONTACT_RECIPIENT_EMAIL e infine MAIL_FROM_ADDRESS come ultimo fallback locale sicuro quando non è configurato alcun destinatario di contatto esplicito.

Slug del blocco CMS: video
Campi di amministrazione: title, content, url, media_id
Campi traducibili: title, content
Campi condivisi: url, media_id
Output previsto di WebBlocks UI: <video controls> semantico per le sorgenti dirette, oppure un <iframe> di provider sicuro solo per URL YouTube/Vimeo note, all'interno di un semplice guscio wb-card.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: la Fase 3 ora dota Video di un form di amministrazione e di un percorso di salvataggio dedicati, mantiene tradotti i testi visibili, conserva il rendering che privilegia i media ospitati e ricade su un semplice link esterno per gli URL sconosciuti sicuri invece di incorporarli in modo non sicuro.

Slug del blocco CMS: audio
Campi di amministrazione: title, content, url, media_id
Campi traducibili: title, content
Campi condivisi: url, media_id
Output previsto di WebBlocks UI: <audio controls> semantico all'interno di un semplice guscio wb-card.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: la Fase 3 ora dota Audio di un form di amministrazione e di un percorso di salvataggio dedicati, mantiene tradotti i testi visibili e sopprime i controlli vuoti quando non esiste una sorgente utilizzabile.

Slug del blocco CMS: file
Campi di amministrazione: title, content, url, media_id
Campi traducibili: title, content
Campi condivisi: url, media_id
Output previsto di WebBlocks UI: una card di file compatta con un'azione di download/apertura wb-btn wb-btn-secondary.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: la Fase 3 ora dota File di un form di amministrazione e di un percorso di salvataggio dedicati, mantiene tradotti i testi visibili e rende esplicito il contratto condiviso di sorgente media-o-URL senza generare ancore vuote non valide.

Slug del blocco CMS: map
Campi di amministrazione: title, content, url
Campi traducibili: nessuno
Campi condivisi: title, content, url
Output previsto di WebBlocks UI: un semplice riepilogo della posizione con un pulsante esterno Open map, non un widget mappa personalizzato.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete l'implementazione incentrata sul link finché non sarà disponibile un vero pattern di mappa/embed rilasciato.

Slug del blocco CMS: slider
Campi di amministrazione: asset di galleria ordinati e testo opzionale
Campi traducibili: nessuno
Campi condivisi: gli asset e la struttura
Output previsto di WebBlocks UI: nessun renderer promosso nella Fase 4; utilizzate gallery o altri blocchi media strutturati quando possibile.
Implementazione attuale: debole
Note per futuri miglioramenti del renderer o dell'amministrazione: slider resta rinviato perché non esiste un pattern carousel di WebBlocks UI confermato e rilasciato su cui valga la pena standardizzarsi.

Slug del blocco CMS: code
Campi di amministrazione: title, content
Campi traducibili: title, content
Campi condivisi: settings.language opzionale
Output previsto di WebBlocks UI: sorgente con escape all'interno di un <pre><code> semantico, senza HTML iniettato e senza dipendenze per l'evidenziazione della sintassi.
Implementazione attuale: accettabile
Nota sulla mappatura di importazione/sincronizzazione: gli snippet grezzi o su più righe, come gli esempi <pre><code> e i blocchi di inclusione dei pacchetti, devono diventare code e non rich-text.
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete il rendering del codice sicuro e privo di dipendenze. I metadati facoltativi sul linguaggio possono essere esposti dalle impostazioni, ma un editor di codice completo o uno stack di syntax highlighting restano intenzionalmente fuori dall'ambito della Fase 3.

Slug del blocco CMS: toc
Campi di amministrazione: title
Campi traducibili: title
Campi condivisi: nessuno
Output previsto di WebBlocks UI: un wb-link-list costruito a partire dai blocchi header con ancora già presenti nella stessa pagina.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: l'implementazione della Fase 3 resta intenzionalmente minimale. Viene renderizzata solo quando i blocchi Header espongono già ID di ancora espliciti e non tenta un parsing complesso delle intestazioni né la generazione automatica delle ancore.

Slug del blocco CMS: navigation-auto
Campi di amministrazione: navigation_menu_key
Campi traducibili: nessuno
Campi condivisi: settings.menu_key
Output previsto di WebBlocks UI: un elenco di navigazione del sito che utilizzi semplici primitive nav/list oppure wb-link-list quando opportuno; non simulate una sidebar di documentazione a meno che il page shell non sia davvero un docs shell.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete il blocco focalizzato sul rendering degli alberi di navigazione e lasciate che sia lo slot o il page shell a decidere se l'output è navigazione di intestazione, di piè di pagina o di documentazione.

Slug del blocco CMS: menu
Campi di amministrazione: navigation_menu_key
Campi traducibili: nessuno
Campi condivisi: settings.menu_key
Output previsto di WebBlocks UI: lo stesso di navigation-auto; questo blocco resta un alias legacy per i dati migrati.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: mantenete il supporto per i contenuti più vecchi, ma preferite navigation-auto nell'esperienza di amministrazione e nei seed futuri.

tabs, slider, menu e faq-list sono ancora slug legacy in fase di bozza nel catalogo del CMS, non contratti core pubblicati.
showcase-list e contact-info esistono tuttora soltanto come blocchi di compatibilità per il rendering pubblico e in questa fase non vengono promossi nel catalogo core pubblicato.
Questa fase documenta onestamente quei percorsi, conserva il rendering di compatibilità dove è già rilasciato e aggiunge una sanificazione sicura dei link pubblici definiti nelle impostazioni, senza introdurre un nuovo sistema JavaScript per tabs o slider.

Slug del blocco CMS: contact_form
Campi di amministrazione: heading, intro_text, submit_label, success_message, recipient_email, send_email_notification, store_submissions
Campi traducibili: title/heading, content/intro, submit_label, success_message
Campi condivisi: recipient_email, send_email_notification, store_submissions
Output previsto di WebBlocks UI: i campi del modulo usano le primitive di form di WebBlocks UI; l'azione di invio usa wb-btn; il feedback temporaneo di successo viene mostrato una sola volta come toast di WebBlocks UI sotto il #wb-overlay-root pubblico condiviso, mentre gli errori di validazione e i problemi correggibili dall'utente restano inline vicino al modulo con wb-alert.
Implementazione attuale: accettabile
Note per futuri miglioramenti del renderer o dell'amministrazione: conservate i campi strutturati del modulo, tenete le impostazioni operative fuori dai testi editoriali, mantenete i destinatari predefiniti a livello di sito sul record del sito anziché in JSON arbitrari del blocco ed evitate di costringere gli editor a incollare markup di form grezzo o a usare mailto: come surrogato dell'invio.

Blocco CMS	Stato attuale	Direzione desiderata	Note
card-grid	solo rendering pubblico	dovrebbe restare transitorio	Il renderer ora riproduce la stessa struttura wb-grid e wb-card di columns.variant = cards, ma dipende ancora da settings.items. Per i nuovi contenuti strutturati preferite Columns.
showcase-list	solo rendering pubblico	dovrebbe restare fallback/personalizzato	Attualmente si tratta di contenuto seed specifico per showcase e non dovrebbe diventare core a meno che il pattern non si ripeta su più siti. I trigger pubblici sulle immagini devono continuare a rispettare il contratto gallery rilasciato, emettendo data-wb-gallery-target e registrando un'unica modale viewer condivisa sotto #wb-overlay-root.
contact-info	solo rendering pubblico	dovrebbe diventare di prima classe	Se gli editor continuano a usare schede di metadati di contatto, un piccolo blocco strutturato è preferibile a contenuti personalizzati guidati dalle impostazioni. Il rendering di compatibilità attuale ora ignora gli URL non sicuri delle impostazioni invece di emettere ancore non valide o pericolose.
code	renderer pubblico di prima classe	accettabile	Il rendering sicuro con è ora disponibile; funzionalità di editing più ricche restano un lavoro futuro facoltativo.
list	renderer pubblico di prima classe	accettabile	Esiste ora un rendering dedicato di elenchi basato sulle righe; mantenete la compatibilità con i contenuti legacy guidati dalle impostazioni.
table	renderer pubblico di prima classe	accettabile	Esiste ora un rendering dedicato di tabelle basato sulle righe; mantenete la compatibilità con le righe legacy delle impostazioni.
accordion	renderer pubblico di prima classe	accettabile	La divulgazione raggruppata usa ora semantico e blocchi figli invece del markup di ripiego basato sulle impostazioni.
feature-grid	alias di compatibilità pubblicato	dovrebbe restare transitorio	Il renderer pubblico delega a columns.variant = cards; per i nuovi contenuti preferite Columns, ma mantenete Feature Grid documentato perché è basato su sorgenti reali ed è rilasciato.
stats	solo alias	dovrebbe confluire in Columns	Il renderer pubblico delega al percorso esistente columns.variant = stats e dovrebbe restare documentato come comportamento di alias anziché come contratto pubblicato autonomo.
metric-card	alias di prima classe	dovrebbe confluire nelle primitive stat	Il renderer pubblico usa ora la stessa impostazione wb-stat della variante stats di Columns.
logo-cloud	solo fallback	dovrebbe diventare di prima classe	Promuovetelo solo se esiste un'esigenza ricorrente di righe strutturate di loghi o media.
testimonial	solo alias	dovrebbe confluire in Quote	Il renderer pubblico delega alla variante testimonial di quote e dovrebbe restare documentato come comportamento di alias anziché come contratto pubblicato autonomo.
timeline	solo fallback	dovrebbe diventare di prima classe	Promuovetelo solo con milestone strutturate e un pattern di interfaccia chiaro e rilasciato.
pricing	solo fallback	dovrebbe diventare di prima classe	Perché valga la pena promuoverlo, un blocco di pricing necessita di campi strutturati per piani, funzionalità e CTA.
toc	renderer pubblico di prima classe	accettabile	Il rendering minimale dell'indice usa ora le ancore Header esistenti e wb-link-list; il comportamento della sezione attiva resta rinviato.
breadcrumb	solo fallback	dovrebbe diventare di prima classe	Aggiungetelo solo quando lo shell pubblico richiede davvero una navigazione breadcrumb.
cookie-notice	solo fallback	dovrebbe restare fallback/personalizzato	L'interfaccia pubblica di consenso vive già nello shell del layout, quindi questo blocco non dovrebbe competere con il pattern di privacy condiviso.

I renderer Blade devono privilegiare le classi wb-* rilasciate.
Nessuna nuova classe CSS pubblica creata ad hoc, se non documentata come lacuna di WebBlocks UI.
Nessuno script inline nei renderer dei blocchi.
I blocchi interattivi devono usare prima di tutto i data hook rilasciati di WebBlocks UI.
Il JS specifico del CMS appartiene a public/cms/js solo quando è necessario.
I contenuti di overlay, dialog e modali devono usare #wb-overlay-root.
I campi di amministrazione non devono obbligare gli editor a incollare HTML grezzo di WebBlocks UI per i blocchi normali.
Quando possibile, i blocchi devono esporre campi strutturati e varianti, non HTML grezzo.
README.md deve essere aggiornato dopo modifiche significative al comportamento del renderer o dell'amministrazione.

Solo documentazione.
Definire il contratto del renderer.
Nessuna riscrittura del renderer per ora.

Allineare il layout pubblico e i wrapper degli slot.
Garantire che il contenuto principale possa essere renderizzato con wb-content-shell dove opportuno.
Aggiungere test per l'output delle classi di shell e slot.

Rendere card-grid, button-group e qualsiasi futuro pattern autonomo di stats o testimonial di prima classe solo quando diventano contratti reali di proprietà del prodotto anziché semplici alias.
Aggiungere i moduli di amministrazione e il supporto nel registro delle traduzioni dove serve.

Fase 3 completata: i blocchi pubblici core sono ora allineati con le primitive di WebBlocks UI.

Migrare i contenuti di documentazione seed o dimostrativi verso blocchi di prima classe.
Eliminare la dipendenza da HTML grezzo o da settings.items dove esiste già un blocco strutturato.

Primitive verificate di WebBlocks UI

Modalità di layout della fase 2B

Matrice

Layout della pagina e slot

Layout pubblico

Card

Wrapper degli slot

Slot header

Slot main

Slot sidebar

Slot footer

Blocchi di contenuto principali

`header`

`text`

`rich-text`

`html`

`section`

Regola dei wrapper di layout

`hero`

`columns`

`column_item`

`cta`

`feature-grid`

`feature-item`

`callout`

`quote`

`faq`

`accordion`

`faq-list`

`tabs`

`button`

Righe di CTA

`image`

`gallery`

`download`

`contact_form`

`video`

`audio`

`file`

`map`

`slider`

`code`

`toc`

`navigation-auto`

`menu`

Nota legacy / transitoria della Fase 3

`contact_form`

Blocchi deboli o solo pubblici

Regole del renderer

Piano delle fasi

Fase 1

Fase 2

Fase 3

Fase 4