@praxisui/stepper 7.0.0-beta.0 → 8.0.0-beta.0

package/README.md

@@ -198,6 +198,16 @@ validateStep = async ({ step, formGroup, formData }) => {
 - Eventos: `selectedIndexChange`, `selectionChange`, `widgetEvent`, `animationDone`, `stepFormReady`, `stepFormValueChange`
 - Veja: `projects/praxis-stepper/src/public-api.ts`
 
+## Conteudo Editorial por Etapa
+
+O conteudo editorial do stepper usa a mesma base de rich content da plataforma:
+
+- `steps[].stepBlocksBeforeForm`: `RichContentDocument` renderizado antes do formulario da etapa
+- `steps[].stepBlocksAfterForm`: `RichContentDocument` renderizado depois do formulario da etapa
+- `steps[].widgets`: reservado para componentes avancados host-owned, como listas de selecao e upload, quando nao houver equivalente canonico em rich content
+
+Novo authoring nao deve usar `widgetsBeforeForm` para copy, cards, avisos ou conteudo editorial. O wizard adapter converte `blocks`, `zones` e `cards` para `RichContentDocument` automaticamente.
+
 ## Wizard Form (FT-like) — Experimental
 
 O `PraxisWizardFormComponent` é um wrapper experimental que traduz um JSON de wizard em `StepperMetadata` + `FormConfig` e aplica um layout inspirado no Financial Times.
@@ -217,10 +227,10 @@ export class FtWizardDemo {
 ```
 
 Notas:
-- `widgetsBeforeForm` permite inserir cards/infos antes do formulário em cada etapa.
-- `blocks` (wizard) permite inserir conteúdos editoriais (benefits/content/notice/divider) antes ou depois do formulário.
+- `stepBlocksBeforeForm` e `stepBlocksAfterForm` recebem rich content antes/depois do formulário em cada etapa.
+- `blocks` (wizard) permite inserir conteúdos editoriais (benefits/content/notice/divider) antes ou depois do formulário; o adapter converte esses blocos para `RichContentDocument`.
 - `zones` (wizard) permite separar blocos em `intro`, `body` e `footer` (mapeados para before/after form).
-- `contentBlock` permanece suportado por compatibilidade, mas entrou em deprecação formal para novo authoring. O destino preferencial de convergência é `widget:rich-text-block`.
+- `contentBlock` e demais blocos editoriais convergem para nodes de rich content no novo contrato, sem criar widgets locais para novo authoring.
 - Cada bloco pode definir `id` (string) para gerar `blockId` estável em runtime; sem `id`, o fallback usa índice posicional.
 - `blocks` e `zones` são mutuamente exclusivos no contrato. Se ambos forem enviados, `zones` tem prioridade no runtime.
 - O wizard faz validação runtime (campos essenciais e exclusividade de `blocks`/`zones`). Em `devMode`, lança erro para facilitar o debug; em produção, emite `console.warn`.