@praxisui/dynamic-form 8.0.0-beta.2 → 8.0.0-beta.20

package/README.md

@@ -70,10 +70,11 @@ Peer dependencies (Angular v20):
 - `@angular/core` `^20.0.0`
 - `@angular/common` `^20.0.0`
 - `@angular/cdk` `^20.0.0`
-- `@praxisui/core` `^0.0.1`
-- `@praxisui/visual-builder` `^0.0.1`
-- `@praxisui/settings-panel` `^0.0.1`
-- `@praxisui/cron-builder` `^0.0.1`
+- `@praxisui/core` `^8.0.0-beta.12`
+- `@praxisui/rich-content` `^8.0.0-beta.10`
+- `@praxisui/visual-builder` `^8.0.0-beta.10`
+- `@praxisui/settings-panel` `^8.0.0-beta.10`
+- `@praxisui/cron-builder` `^8.0.0-beta.10`
 
 ## Quick Start
 
@@ -112,8 +113,16 @@ export class FormDemoComponent {
         rows: [
           {
             columns: [
-              { id: 'col-fullName', fields: ['fullName'] },
-              { id: 'col-email', fields: ['email'] },
+              {
+                id: 'col-fullName',
+                items: [{ kind: 'field', id: 'field-fullName', fieldName: 'fullName' }],
+                fields: ['fullName'],
+              },
+              {
+                id: 'col-email',
+                items: [{ kind: 'field', id: 'field-email', fieldName: 'email' }],
+                fields: ['email'],
+              },
             ],
           },
         ],
@@ -316,6 +325,19 @@ export class FormEditorLauncherComponent {
 
 Alternatively, when `enableCustomization` is true, `praxis-dynamic-form` renders a gear button that opens the editor internally.
 
+## Agentic Authoring & Manifest
+
+`praxis-dynamic-form` supports executable authoring contracts through the `ComponentAuthoringManifest`. This allows AI agents to perform structured, safe, and deterministic edits to the form configuration.
+
+- **Manifest:** `PRAXIS_DYNAMIC_FORM_AUTHORING_MANIFEST`
+- **Editable targets:** `field`, `section`, `row`, `column`, `visualBlock`, `formAction`, `formRule`, `message`, `layoutPlacement`, `localField`, `schemaBackedField`.
+- **Operations:** Covers field property updates, local field lifecycle, layout item manipulation, visual block authoring, rule management, and action configuration declared in `PRAXIS_DYNAMIC_FORM_AUTHORING_MANIFEST`.
+- **Validation:** Deterministic validators cover ID uniqueness, layout integrity, rich content document validity, local/schema-backed separation, destructive confirmation, and editor round-trip preservation.
+- **Examples/evals:** Fixtures cover local transient fields, schema-backed relabeling, layout moves, visual block add/move, visibility rules, unknown target rejection, destructive confirmation, and save/reopen without drift.
+- **Round-trip:** Preserves editor state and ensures that AI-generated patches are compatible with the visual editor.
+
+For more details on authoring manifests, see `docs/ai/agentic-authoring/component-authoring-contracts/README.md`.
+
 ## API Surface
 
 - Components: `PraxisDynamicForm`, `PraxisDynamicFormConfigEditor`, `JsonConfigEditorComponent`, `LayoutEditorComponent`
@@ -419,8 +441,16 @@ const formConfig: FormConfig = {
       rows: [
         {
           columns: [
-            { fields: ['fullName'] },
-            { fields: ['workEmail'] },
+            {
+              id: 'registration-full-name',
+              items: [{ kind: 'field', id: 'field-fullName', fieldName: 'fullName' }],
+              fields: ['fullName'],
+            },
+            {
+              id: 'registration-work-email',
+              items: [{ kind: 'field', id: 'field-workEmail', fieldName: 'workEmail' }],
+              fields: ['workEmail'],
+            },
           ],
         },
       ],
@@ -452,10 +482,71 @@ Notas:
 
 See public exports: `projects/praxis-dynamic-form/src/public-api.ts`.
 
+## Blocos visuais em colunas
+
+O layout de coluna usa `sections[].rows[].columns[].items[]` como contrato
+canônico ordenado. Itens `kind: 'field'` referenciam
+`fieldMetadata[].name`; itens `kind: 'richContent'` hospedam um
+`RichContentDocument` dentro da coluna e não entram em `fieldMetadata`,
+`formData` ou payload HTTP.
+
+`sections[].rows[].columns[].fields[]` permanece aceito como entrada de
+migração e como projeção derivada dos itens `kind: 'field'`, mas não deve ser
+usado para criar blocos visuais.
+
+No editor visual, **Campos da API** lista apenas campos existentes em
+`fieldMetadata[]` que ainda não aparecem em `columns[].items[]` como
+`kind: 'field'`. Ao adicionar um campo, o editor reinsere o item em `items[]`
+e mantém `fields[]` sincronizado como projeção; `fieldMetadata[]` não é
+alterado.
+
+**Adicionar bloco visual** oferece presets internos como texto, aviso,
+separador, card informativo, `callout`, `keyValueList`, `recordSummary`,
+`disclosure` e `emptyState`. Esses presets são apenas atalhos de authoring que
+geram documentos `praxis.rich-content` válidos para itens `kind: 'richContent'`;
+eles não criam novo `kind`, não criam `FieldMetadata` e não participam do
+payload de submit.
+
+O runtime do formulário também passa `hostCapabilities` canônicos para
+`@praxisui/rich-content`, permitindo:
+- `actionButton` despachar ações via a mesma trilha de `customAction`/`globalAction`
+  já usada pelo formulário;
+- `requiresCapabilities` resolver capacidades como `form.mode.edit`,
+  `form.mode.view`, `form.customization.enabled`, `form.resource.connected` e
+  `form.actions.submit`.
+
+Exemplo mínimo de uma coluna com campo, bloco visual e projeção `fields[]`:
+
+```json
+{
+  "items": [
+    {
+      "kind": "richContent",
+      "id": "identity-guidance-block",
+      "document": {
+        "schemaVersion": 1,
+        "nodes": [
+          {
+            "type": "paragraph",
+            "text": "Revise os dados principais antes de salvar."
+          }
+        ]
+      }
+    },
+    { "kind": "field", "id": "field-nome", "fieldName": "nome" },
+    { "kind": "field", "id": "field-email", "fieldName": "email" }
+  ],
+  "fields": ["nome", "email"]
+}
+```
+
+Guia completo: `projects/praxis-dynamic-form/docs/layout-items-visual-blocks.md`.
+
 ## Documentacao Tecnica da Lib
 
 - `projects/praxis-dynamic-form/src/lib/praxis-dynamic-form.json-api.md`
 - `projects/praxis-dynamic-form/docs/hot-metadata-updates.md`
+- `projects/praxis-dynamic-form/docs/layout-items-visual-blocks.md`
 
 ## Header de seção com avatar dinâmico
 
@@ -504,25 +595,30 @@ Os paths micro são normalizados para `fieldMetadata[].<prop>` para garantir que
 
 ## Regras de formulário (novo contrato)
 
-- Formato: cada regra tem `targetType` (`field | section | action | row | column`), `targets: string[]` (IDs canônicos do alvo), e `effect` com `condition` (`JsonLogicExpression | null`), `properties` e `propertiesWhenFalse`.
+- Formato: cada regra tem `targetType` (`field | section | action | row | column | visualBlock`), `targets: string[]` (IDs canônicos do alvo), e `effect` com `condition` (`JsonLogicExpression | null`), `properties` e `propertiesWhenFalse`.
+- Regra de negócio, política, elegibilidade, validação, compliance ou decisão compartilhada deve ser authorada no fluxo governado de `domain-rules`/`shared_rule_authoring`. `visualBlockGuidance` fica restrito a projeção visual opcional: quando uma decisão já governada precisar explicar impacto na UI, a materialização `form_config` pode gerar `type: "visualBlockGuidance"`, `targetType: "visualBlock"` e `metadata.origin: "llm"` com `metadata.reviewStatus: "pending"`; o editor aceita a projeção, marca como `accepted` e materializa `formRulesState` internamente para round-trip visual.
 - Compatibilidade: regras antigas (`context/targetField`) são migradas para `properties/targets` automaticamente; prefixes legados `section:/action:/row:/column:` continuam sendo normalizados quando representarem alvos tradicionais. Para header actions de seção, o ID canônico é preservado como `section:<sectionId>:header-action:<actionLogicalId>`.
 - Semântica de limpeza: valores `null` em `properties/propertiesWhenFalse` removem o override e retornam ao valor base do layout; ausência mantém o valor base.
 - Whitelist por tipo (somente propriedades a seguir são aplicadas; demais são descartadas e logadas em dev):
   - `field`: `visible`, `required`, `readonly`, `disabled`, `className`, `style`, `label`, `description`, `placeholder`, `hint`, `tooltip`, `prefixIcon`, `suffixIcon`, `prefixText`, `suffixText`, `defaultValue`, `options` (array `{label,value,disabled?}`), `appearance` (`fill|outline`), `color` (`primary|accent|warn`), `floatLabel` (`auto|always|never`), `hintPosition` (`start|end`), `validators` (primitivos por chave).
   - `section`: `visible`, `title`, `description`, `icon`, `sectionHeader` (objeto rico), `headerActions` (ações contextuais do cabeçalho) e tambem subpropriedades tipadas como `sectionHeader.mode`, `sectionHeader.sourceField`, `sectionHeader.initialsSourceField`, `sectionHeader.altField`, `sectionHeader.fallbackIcon`, `sectionHeader.emptyState`, `sectionHeader.size`, `sectionHeader.initialsMaxLength`, `className`, `style`, `collapsible`, `collapsed`, `headerTooltip`, `headerAlign` (`start|center`), `appearance` (`card|plain|step`), `stepLabel`, gaps (`gapBottom`, `titleGapBottom`, `descriptionGapBottom`), cores/tipografia (`titleColor`, `descriptionColor`, `titleStyle`, `descriptionStyle`).
   - `action`: `visible`, `disabled`, `loading`, `label`, `icon`, `tooltip`, `color` (`primary|accent|warn|basic`), `variant` (`raised|stroked|flat|fab`), `size` (`small|medium|large`), `className`, `style`.
-- IDs canônicos de regras para actions do header de seção usam o formato `section:<sectionId>:header-action:<actionLogicalId>`, evitando colisão com botões globais e com ações repetidas em seções diferentes.
-- Se a seção ainda não tiver `id`, o runtime aceita o fallback `header-action:<actionLogicalId>` por compatibilidade; para contratos persistidos, prefira sempre materializar `section.id`.
   - `row`: `visible`, `gap`, `rowGap`, `className`, `style`.
   - `column`: `visible`, `span`, `offset`, `order`, `hidden`, `align` (`start|center|end|stretch`), `padding`, `className`, `style`.
-- Runtime (FormRulesService): filtra por whitelist, converte tipos (enum/number/boolean/string), saneia objetos (`options/validators/style`), aplica remoção de chaves com `null` e retorna mapas `fieldProps/sectionProps/actionProps/rowProps/columnProps`.
-- Renderização: `PraxisDynamicForm` aplica overrides em campos/seções/ações/linhas/colunas (visibilidade, gaps, padding, classes, estilos, labels, etc.); colunas respeitam `align/span/offset/order/hidden/padding` vindo das regras.
+  - `visualBlock`: `visible`, `hidden`, `layout`, `className`, `rootClassName`, `style`, `text`, `title`, `message`; para documentos compostos, use `textNodeId`, `titleNodeId` ou `messageNodeId` para apontar o node textual seguro.
+- IDs canônicos de regras para actions do header de seção usam o formato `section:<sectionId>:header-action:<actionLogicalId>`, evitando colisão com botões globais e com ações repetidas em seções diferentes.
+- Se a seção ainda não tiver `id`, o runtime aceita o fallback `header-action:<actionLogicalId>` por compatibilidade; para contratos persistidos, prefira sempre materializar `section.id`.
+- Runtime (FormRulesService): filtra por whitelist, converte tipos (enum/number/boolean/string), saneia objetos (`options/validators/style`), aplica remoção de chaves com `null` e retorna mapas `fieldProps/sectionProps/actionProps/rowProps/columnProps/visualBlockProps`.
+- Renderização: `PraxisDynamicForm` aplica overrides em campos/seções/ações/linhas/colunas/blocos visuais (visibilidade, gaps, padding, classes, estilos, labels e texto seguro, conforme o tipo); colunas respeitam `align/span/offset/order/hidden/padding` vindo das regras.
+- Regras de `visualBlock` são visual-only: elas não criam `FieldMetadata`, `FormControl`, valor em `formData` ou payload HTTP. Use campo local com `submitPolicy` quando a experiência precisar de valor persistível ou leitura em `rawFormData`.
 
 ### Builder integrado
 
-- No editor visual, use a aba “Propriedades” (integrada ao builder) para selecionar o alvo (`targetType` + autocomplete de IDs de campos/seções/ações/linhas/colunas), escolher propriedades whitelisted e definir valores para `properties` (branch true) e `propertiesWhenFalse` (branch false). Botão “Limpar override” remove a propriedade (equivalente a `null`).
+- No editor visual, use a aba “Propriedades” (integrada ao builder) para selecionar o alvo (`targetType` + autocomplete de IDs de campos/seções/ações/linhas/colunas/blocos visuais), escolher propriedades whitelisted e definir valores para `properties` (branch true) e `propertiesWhenFalse` (branch false). Botão “Limpar override” remove a propriedade (equivalente a `null`).
+- Para `visualBlock`, o painel de propriedades exibe um seletor de node quando a propriedade é `text`, `title` ou `message`; o editor persiste `textNodeId`, `titleNodeId` ou `messageNodeId` automaticamente para evitar sobrescrever o node errado em documentos compostos.
+- No round-trip do builder, `config.type` continua sendo reservado para o tipo visual do node; semântica de regra como `visualBlockGuidance` é preservada internamente em `config.ruleType` e volta para `formRules[].type`.
 - A aba de Propriedades usa inputs tipados (enum/number/boolean/string/JSON) conforme o schema injetado; valores inválidos são ignorados.
-- O config editor fornece `targetSchemas` (campos/seções/ações/linhas/colunas) e `targetPropertySchemas` para o builder; `formRules` são salvas no formato canônico (sem `context/targetField`).
+- O config editor fornece `targetSchemas` (campos/seções/ações/linhas/colunas/blocos visuais) e `targetPropertySchemas` para o builder; `formRules` são salvas no formato canônico (sem `context/targetField`).
 
 ## Layout padrão (sem FormConfig)
 
@@ -665,14 +761,14 @@ Cobertura ja estabilizada:
 - `JSON` com edicao real e bloqueio de payload invalido
 - `Hooks`
 - `Acoes` (`Botoes Padrao` e `Layout`)
-- `Acoes` customizadas profundas (`showAlert` simples e estruturado)
+- `Acoes` customizadas profundas (`dialog.alert` com `globalAction` simples e estruturado)
 - `Comportamento`
 - `Mensagens`
 - `Dicas e Tooltips`
 
 Ajuste tecnico aplicado durante essa fase:
 - [praxis-dynamic-form-config-editor.ts](/mnt/d/Developer/praxis-plataform/praxis-ui-angular/projects/praxis-dynamic-form/src/lib/config-editor/praxis-dynamic-form-config-editor.ts) agora chama `this.jsonEditor?.updateJsonFromConfig(this.editedConfig)` em `onConfigChange(...)` para manter o editor JSON sincronizado com mudancas vindas de abas como `Hooks`.
-- [actions-editor.component.ts](/mnt/d/Developer/praxis-plataform/praxis-ui-angular/projects/praxis-dynamic-form/src/lib/actions-editor/actions-editor.component.ts) agora mescla catalogo legado + catalogo global do app para o editor de acoes customizadas.
+- [actions-editor.component.ts](/mnt/d/Developer/praxis-plataform/praxis-ui-angular/projects/praxis-dynamic-form/src/lib/actions-editor/actions-editor.component.ts) agora usa o catalogo global canonico do app para o editor de acoes customizadas.
 - [actions-editor.component.ts](/mnt/d/Developer/praxis-plataform/praxis-ui-angular/projects/praxis-dynamic-form/src/lib/actions-editor/actions-editor.component.ts) agora preserva draft local dos campos globais e usa `track` estavel em `actions.custom`.
 
 Comando base usado para rerodar suites isoladas:
@@ -720,6 +816,7 @@ Apache-2.0 – see the `LICENSE` packaged with this library or the repository ro
 - Fluxo de Schema (ETag/304, schemaId, reconciliação): `projects/praxis-core/docs/schema-flow.md` (canônico) e `docs/schemas/fluxo-schema.md` (resumo operacional)
 - Guia de implementação e metadados da cascata: `docs/CASCADE-NATIVA.md`
 - Padrões de endpoints (Options vs Filter) para selects: `projects/praxis-dynamic-fields/docs/generic-crud-service.md` (canônico) e `docs/DEVS-GENERIC-CRUD-SERVICE.md` (resumo operacional)
+- Recipe oficial de Entity Lookup corporativo com `RESOURCE_ENTITY`, `dependsOn`, `dependencyFilterMap`, reidratação por `by-ids` e política de seleção: `examples/ai-recipes/praxis-dynamic-form.entity-lookup-procurement.json`
 
 ## Verificação de Schema (ETag/If-None-Match)
 
@@ -747,3 +844,44 @@ Apache-2.0 – see the `LICENSE` packaged with this library or the repository ro
 - Quando `API_URL.default.baseUrl` for relativo (ex.: `'/api'`), a lib resolve a origem a partir de `location.origin` no browser. Isso cobre o cenário comum com proxy de dev (`/api`, `/schemas`).
 - Em SSR (sem `location.origin`), configure `baseUrl` absoluto (ex.: `https://api.acme.com/api`) para evitar erros do tipo “Invalid URL” ao construir chamadas de `/schemas/filtered`.
 - O `GenericCrudService.getSchemasFilteredBaseUrl()` retorna sempre uma URL absoluta; o `SchemaMetadataClient` também aceita `baseUrl` relativo quando há origin disponível.
+
+## Regras de Domínio Compartilhadas
+
+`praxis-dynamic-form` pode consumir regras materializadas pelo backend sem gravá-las dentro de `FormConfig`. O input `domainRules` é opt-in e combina as regras remotas com `config.formRules` no mesmo `FormRulesService`.
+
+```html
+<praxis-dynamic-form
+  formId="funcionarios-form-demo"
+  [config]="formConfig"
+  [domainRules]="{
+    enabled: true,
+    targetArtifactKey: 'funcionarios-form-demo',
+    targetLayer: 'form_config',
+    targetArtifactType: 'praxis-dynamic-form',
+    status: 'applied'
+  }">
+</praxis-dynamic-form>
+```
+
+- `targetArtifactKey` usa `formId`/`componentInstanceId` quando omitido.
+- `targetLayer` default: `form_config`.
+- `targetArtifactType` default: `praxis-dynamic-form`.
+- Para consumo runtime, prefira `status: 'applied'`; `pending_review` pertence a etapas de governança antes da aplicação.
+- `materializedPayload` pode ser um `FormLayoutRule` direto ou uma operação reconhecida, como `rule.visualBlockGuidance.add`, desde que essa operação seja tratada como projeção visual derivada e não como fonte primária da regra de negócio.
+- A rastreabilidade da regra compartilhada fica em `metadata.domainRule`.
+- Quando o backend enviar `decisionDiagnostics`, o runtime preserva esse envelope em `metadata.domainRule.decisionDiagnostics`, mantendo a explicação canônica da decisão semântica governada junto da regra derivada.
+
+E2E vivo com API real:
+
+```bash
+PAX_PROXY_TARGET=https://praxis-api-quickstart.onrender.com \
+node scripts/run-playwright-with-dev-host.js \
+  --port 4003 \
+  --path /funcionarios-form-demo \
+  --spec projects/praxis-dynamic-form/test-dev/e2e/funcionarios-form-demo-domain-rules.playwright.spec.ts
+```
+
+Validado em 2026-04-23 contra `praxis-api-quickstart` publicado no Render com
+`praxis-config-starter:0.1.0-rc.22`: o spec confirmou resposta 200 de
+`/api/praxis/config/domain-rules/materializations` e presença de materialização
+`form_config` com `operation: "rule.visualBlockGuidance.add"`.

package/docs/dynamic-form-authoring-document-semantics.md

@@ -0,0 +1,80 @@
+---
+title: "Dynamic Form Authoring Document Semantics"
+doc_type: "adr"
+component: "praxis-dynamic-form"
+status: "accepted"
+owner: "praxis-ui"
+last_updated: "2026-04-15"
+---
+
+# Dynamic Form Authoring Document Semantics
+
+## Decision
+
+`DynamicFormAuthoringDocument` e o snapshot canônico completo de autoria de `praxis-dynamic-form`.
+
+Ao aplicar um documento canônico:
+
+- `config` substitui integralmente a configuração anterior.
+- `bindings` substitui integralmente os bindings persistíveis anteriores.
+- ausência de `bindings.mode` implica limpeza do binding persistido e retorno ao modo default efetivo do host.
+- `contextSnapshot` substitui integralmente o contexto autoral persistido anterior.
+- ausência de `backConfig`, `presentation` ou `schemaPrefs` dentro de `contextSnapshot` significa remoção explícita do bloco ausente.
+
+Payloads legados ou parciais recebidos por APIs de compatibilidade, como `applyConfigFromAdapter(...)`, permanecem com semântica `merge-compat`: campos não informados devem ser preservados até migração completa para o contrato canônico.
+
+Valores de runtime/discovery, como `schemaUrl`, `submitUrl` e `submitMethod`, não fazem parte do `DynamicFormAuthoringDocument`. O editor pode exibi-los apenas como diagnóstico read-only do host atual, mas nunca os persiste em `bindings` ou `contextSnapshot`.
+
+## Field Metadata Editor Patches
+
+Patches vindos de `@praxisui/metadata-editor` para `fieldMetadata` seguem semantica de JSON Merge Patch no campo editado.
+
+Para `entityLookup`, o bloco `fieldMetadata[].optionSource` e aninhado e deve ser mesclado em profundidade. O dynamic-form deve preservar campos existentes, como `key`, `resourcePath`, `valuePropertyPath` e `capabilities.byIds`, quando o editor alterar apenas partes do contrato, como `dependsOn`, `selectionPolicy`, `detail` ou `capabilities.auditSnapshot`.
+
+Essa regra evita perda silenciosa do contrato canonico de Entity Lookup durante o fluxo: abrir editor -> aplicar/salvar -> reabrir editor -> runtime consumir.
+
+## Consequences
+
+- `backConfig`, `presentation` e `schemaPrefs` permanecem fora de `FormConfig`, mas fazem parte oficialmente do documento autoral persistível em `contextSnapshot`.
+- `Apply` e `Save` vindos do editor operam em modo `replace-all`.
+- `reset` do editor limpa todos os modos persistidos do artefato.
+- adapters legados continuam suportados sem limpeza destrutiva de contexto ausente.
+
+## Visual Blocks Inside Layout
+
+Blocos visuais dentro de seção, linha ou coluna devem seguir a decisão
+canônica registrada em:
+
+- `../../../docs/2026-04-dynamic-form-visual-blocks-layout-items-plan.md`
+- `../../../../docs/adr/ADR-0006-dynamic-form-layout-items-visual-blocks.md`
+- `./layout-items-visual-blocks.md`
+- `./dynamic-form-rules-authoring-plan.md`
+
+A semântica alvo é `FormColumn.items`, com uma union discriminada entre campo e
+rich content. `FormColumn.fields` pode ser aceito como entrada de migração para
+configurações antigas, mas não deve seguir como segunda fonte de verdade.
+
+O editor deve produzir e persistir o documento canônico, e o runtime deve
+consumi-lo sem adaptador oculto. O round-trip esperado é:
+
+`abrir editor -> adicionar bloco visual -> aplicar/salvar -> reabrir -> renderizar`
+
+Guardrail permanente:
+
+- bloco visual não entra em `fieldMetadata`;
+- bloco visual não cria `FormControl`;
+- bloco visual não entra no payload de submit;
+- bloco visual não usa `source`, `transient` ou `submitPolicy`.
+- operações AI para bloco visual devem escrever apenas em
+  `sections[].rows[].columns[].items[]`, usando itens `kind: 'richContent'`;
+- `sections[].rows[].columns[].fields[]` é apenas projeção/migração de campos
+  e não pode ser usado para representar bloco visual.
+- presets de bloco visual no editor são atalhos internos para criar
+  `RichContentDocument` com nodes já suportados por `@praxisui/rich-content`;
+  presets não introduzem novo `kind` nem contrato paralelo.
+- "Adicionar campo da API" reinsere somente campos já existentes em
+  `fieldMetadata[]` e ausentes de `columns[].items[]`; a operação escreve o
+  item `kind: 'field'` em `items[]` e preserva `fieldMetadata[]`.
+
+Em fase beta, não vamos deixar legado para trás sem migração, mas também não
+vamos manter legado como contrato paralelo permanente.

package/docs/dynamic-form-llm-rule-authoring-guide.md

@@ -0,0 +1,313 @@
+---
+title: "Dynamic Form LLM Rule Authoring Guide"
+slug: "dynamic-form-llm-rule-authoring-guide"
+description: "Guia operacional para criar, explicar, revisar e aplicar regras de Dynamic Form com apoio de LLM."
+doc_type: "guide"
+document_kind: "host-guide"
+category: "architecture"
+audience:
+  - "business-analyst"
+  - "frontend"
+  - "host"
+  - "platform-team"
+  - "llm-agent"
+level: "intermediate"
+status: "active"
+owner: "praxis-ui"
+tags:
+  - "dynamic-form"
+  - "rules"
+  - "llm"
+  - "json-logic"
+  - "governance"
+toc: true
+sidebar: true
+reading_time: "10 min"
+last_updated: "2026-04-22"
+source_of_truth:
+  - "projects/praxis-dynamic-form/docs/dynamic-form-rules-authoring-plan.md"
+  - "projects/praxis-dynamic-form/src/lib/ai/dynamic-form-rule-authoring-context.ts"
+  - "projects/praxis-dynamic-form/src/lib/ai/form-ai-capabilities.ts"
+  - "projects/praxis-dynamic-form/src/lib/utils/rule-authoring-diagnostics.ts"
+  - "projects/praxis-dynamic-form/src/lib/services/form-rules.service.ts"
+  - "projects/praxis-core/src/lib/models/form/rule-property.schema.ts"
+---
+
+# Dynamic Form LLM Rule Authoring Guide
+
+Este guia define como um analista, host corporativo ou agente LLM deve pedir,
+gerar, explicar, revisar e aplicar regras em `praxis-dynamic-form`.
+
+O objetivo e tirar a regra do improviso. A LLM nao deve "adivinhar codigo"; ela
+deve operar sobre o vocabulario autoral publicado pelo componente:
+
+- `formRules` e o contrato executavel.
+- `formRulesState` e estado interno do builder visual.
+- `fieldMetadata[].name` identifica campos de negocio.
+- `sections[].rows[].columns[].items[]` identifica layout canonico.
+- `RULE_PROPERTY_SCHEMA` define quais propriedades cada alvo aceita.
+- `rule-authoring-diagnostics` e `ruleDiagnosticsChange` fecham o ciclo de
+  validacao e explicacao.
+
+## Contrato de responsabilidade
+
+| Papel | Pode fazer | Nao deve fazer |
+| --- | --- | --- |
+| Analista | Descrever intencao, revisar impacto, aceitar ou rejeitar sugestao. | Editar `formRulesState` manualmente. |
+| LLM | Gerar proposta em `formRules`, explicar impacto e corrigir diagnostics. | Escrever JS, handler, funcao ou regra fora de Json Logic. |
+| Editor | Validar alvo, condicao, propriedades e round-trip visual. | Aplicar regra invalida silenciosamente. |
+| Runtime | Aplicar somente propriedades saneadas e emitir diagnostics. | Criar campos, controles ou payload a partir de visual block. |
+
+## Contexto minimo que a LLM precisa receber
+
+A LLM nao precisa analisar codigo em runtime. Ela precisa receber um pacote de
+conhecimento serializado pelo host/editor:
+
+```json
+{
+  "component": "praxis-dynamic-form",
+  "capabilityCatalogVersion": "v1.11",
+  "fields": [
+    { "name": "tipoContrato", "label": "Tipo de contrato", "type": "select" },
+    { "name": "dataFim", "label": "Data fim", "type": "date" }
+  ],
+  "targets": {
+    "field": ["tipoContrato", "dataFim"],
+    "section": ["dados-contratuais"],
+    "action": ["submit", "cancel"],
+    "visualBlock": ["aviso-lgpd"]
+  },
+  "allowedRuleProperties": {
+    "field": ["visible", "required", "disabled", "readonly", "label", "hint"],
+    "visualBlock": ["visible", "hidden", "text", "title", "message", "rootClassName"]
+  },
+  "visualBlockNodes": {
+    "aviso-lgpd": [
+      { "id": "title", "label": "Aviso LGPD", "kind": "card", "roles": ["title"] },
+      { "id": "message", "label": "Aviso", "kind": "text", "roles": ["text", "message"] }
+    ]
+  },
+  "existingRules": [],
+  "diagnostics": []
+}
+```
+
+Esse pacote deve ser derivado de `FormConfig`, do catalogo de capacidades e dos
+diagnostics atuais. Ele e o "mapa semantico operacional" do formulario.
+
+No runtime/editor, use `buildDynamicFormRuleAuthoringContext(config)` para
+montar esse pacote de forma canonica. A funcao publica:
+
+- remove campos `formHidden` dos alvos de regra;
+- coleta campos, secoes, linhas, colunas, actions e visual blocks;
+- publica `allowedRuleProperties` a partir de `RULE_PROPERTY_SCHEMA`;
+- publica `visualBlockNodes` com os nos editaveis de cada rich content block
+  quando regras puderem alterar `text`, `title` ou `message`;
+- inclui `existingRules` e `diagnostics`;
+- carrega guardrails permanentes para a LLM, incluindo a regra de que
+  `formRulesState` e gerado apenas por internals Praxis apos revisao humana.
+
+## Prompt recomendado para criar regra
+
+Use pedidos com intencao, alvo, condicao, efeito e criterio de aceite:
+
+```text
+Crie uma regra para o formulario de funcionario.
+
+Intencao: quando tipoContrato for "temporario", o campo dataFim deve ficar
+obrigatorio e visivel. Quando nao for temporario, dataFim deve ficar opcional.
+
+Use somente JSON Logic canonico.
+Use somente alvos existentes no target catalog.
+Nao altere formRulesState.
+Marque metadata.origin como "llm" e metadata.reviewStatus como "pending".
+Explique o impacto antes de aplicar.
+```
+
+Resposta esperada da LLM:
+
+```json
+{
+  "formRules": [
+    {
+      "id": "rule-data-fim-contrato-temporario",
+      "name": "Data fim obrigatoria para contrato temporario",
+      "description": "Exige data fim quando o contrato do funcionario for temporario.",
+      "metadata": {
+        "origin": "llm",
+        "reviewStatus": "pending"
+      },
+      "targetType": "field",
+      "targets": ["dataFim"],
+      "effect": {
+        "condition": {
+          "==": [{ "var": "tipoContrato" }, "temporario"]
+        },
+        "properties": {
+          "visible": true,
+          "required": true
+        },
+        "propertiesWhenFalse": {
+          "required": false
+        }
+      }
+    }
+  ]
+}
+```
+
+## Prompt para regra LGPD
+
+```text
+Crie uma regra LGPD para o formulario.
+
+Quando o campo consentimentoLgpd for false, o botao submit deve ficar
+desabilitado e o bloco visual aviso-lgpd deve mostrar a mensagem:
+"Aceite o termo de privacidade para continuar."
+
+Use targetType "action" para submit e "visualBlock" para aviso-lgpd.
+Nao coloque aviso-lgpd em fieldMetadata.
+Nao crie FormControl para aviso-lgpd.
+Use JSON Logic canonico.
+Deixe a sugestao pendente de revisao humana.
+```
+
+Resposta esperada:
+
+```json
+{
+  "formRules": [
+    {
+      "id": "rule-submit-bloqueado-sem-lgpd",
+      "name": "Bloquear envio sem consentimento LGPD",
+      "metadata": {
+        "origin": "llm",
+        "reviewStatus": "pending"
+      },
+      "targetType": "action",
+      "targets": ["submit"],
+      "effect": {
+        "condition": { "===": [{ "var": "consentimentoLgpd" }, false] },
+        "properties": { "disabled": true },
+        "propertiesWhenFalse": { "disabled": false }
+      }
+    },
+    {
+      "id": "rule-aviso-lgpd-sem-consentimento",
+      "name": "Aviso LGPD sem consentimento",
+      "metadata": {
+        "origin": "llm",
+        "reviewStatus": "pending"
+      },
+      "targetType": "visualBlock",
+      "targets": ["aviso-lgpd"],
+      "effect": {
+        "condition": { "===": [{ "var": "consentimentoLgpd" }, false] },
+        "properties": {
+          "visible": true,
+          "message": "Aceite o termo de privacidade para continuar."
+        },
+        "propertiesWhenFalse": {
+          "visible": false
+        }
+      }
+    }
+  ]
+}
+```
+
+## Prompt para explicar regra existente
+
+```text
+Explique esta regra para um analista de negocio.
+
+Responda com:
+1. Quando ela dispara.
+2. O que ela altera.
+3. Se afeta payload ou apenas UI.
+4. Riscos de negocio.
+5. Diagnostics que precisam correcao.
+```
+
+A explicacao deve traduzir Json Logic para linguagem de dominio e citar os
+alvos por label quando o contexto tiver label disponivel.
+
+## Prompt para corrigir diagnostics
+
+```text
+Corrija as regras abaixo usando os diagnostics do editor.
+
+Nao mude a intencao de negocio.
+Se um alvo nao existir, proponha o alvo existente mais proximo e explique.
+Se uma propriedade for rejeitada pelo schema, substitua por uma propriedade
+permitida ou remova com justificativa.
+Mantenha metadata.reviewStatus como "pending".
+```
+
+Mapeamento operacional:
+
+| Diagnostic | Acao esperada da LLM |
+| --- | --- |
+| `missing-targets` | Pedir ou preencher `targets`. |
+| `field-target-not-found` | Trocar por `fieldMetadata[].name` existente. |
+| `target-not-found` | Trocar por alvo existente no mesmo `targetType`. |
+| `invalid-condition` | Reescrever como Json Logic canonico. |
+| `unsupported-property` | Usar propriedade permitida por `RULE_PROPERTY_SCHEMA`. |
+| `unsupported-target-type` | Escolher um `targetType` permitido. |
+| `missing-effect` | Criar `effect.condition` e `effect.properties`. |
+| `rule-evaluation-error` | Simplificar condicao e remover operadores nao suportados. |
+
+Quando o diagnostic envolver apenas propriedade rejeitada, valor invalido ou
+valor parcialmente saneado, o editor tambem pode aplicar a acao deterministica
+`Corrigir`. Essa acao usa o mesmo sanitizer central do runtime, remove ou
+coage propriedades conforme `RULE_PROPERTY_SCHEMA` e regenera `formRulesState`.
+Use LLM quando a correcao exigir decisao semantica de dominio, por exemplo
+trocar uma propriedade inexistente por outra intencionalmente equivalente ou
+explicar por que uma regra deve ser removida.
+
+## Fluxo de aplicacao seguro
+
+1. Host/editor monta o pacote de contexto.
+2. LLM gera uma proposta por operacao autoral ou em `formRules`.
+   Para regra de negocio, politica, elegibilidade, validacao, compliance ou
+   decisao compartilhada, use `domain-rules`/`shared_rule_authoring` antes de
+   materializar `form_config`. Para uma projecao visual derivada de decisao ja
+   governada, aceite `operationId: "rule.visualBlockGuidance.add"` com
+   `type: "visualBlockGuidance"`, `targetType: "visualBlock"`,
+   `context: "notification"` e metadata pendente.
+3. Compilador/adapter rejeita qualquer tentativa de gravar `formRulesState`.
+4. Editor valida alvos, condicao e propriedades.
+5. Editor mostra diff e impacto para o analista.
+6. Analista aceita, edita ou rejeita.
+7. Ao aceitar, editor marca `metadata.reviewStatus: "accepted"`.
+8. Editor tenta gerar `formRulesState` por conversor interno.
+9. Runtime aplica regra e emite `ruleDiagnosticsChange` se houver problema.
+
+## Guardrails permanentes
+
+- Nunca persistir codigo executavel em regra.
+- Nunca editar `formRulesState` diretamente por LLM.
+- Nunca tentar contornar essa regra no patch final: `compileAiResponse` e
+  `applyPatch` tambem rejeitam escrita direta em `formRulesState`.
+- Nunca materializar regra visual direto no estado do builder. O editor preserva
+  semantica de `formRules[].type` usando `config.ruleType` internamente no
+  round-trip.
+- Nunca criar alvo que nao exista no mapa de targets.
+- Nunca usar propriedade fora do schema permitido.
+- Nunca tratar `visualBlock` como campo.
+- Para `visualBlock` com varios nos editaveis, usar o node id correspondente em
+  `textNodeId`, `titleNodeId` ou `messageNodeId`.
+- Nunca esconder erro de regra: todo descarte deve virar diagnostic ou status.
+- Regras LLM entram como `pending`; aceite humano e uma decisao explicita.
+
+## Sinal de prontidao para runtime
+
+Uma regra esta pronta para runtime quando:
+
+- todos os targets existem;
+- a condicao e Json Logic valida;
+- as propriedades passam pelo whitelist;
+- o impacto foi explicado;
+- o preview true/false foi revisado;
+- a origem/revisao esta coerente;
+- o runtime nao emite diagnostic apos aplicar.