@praxisui/table 9.0.67 → 9.0.68-rc.1

package/docs/dynamic-filter-host-integration-guide.md

@@ -314,3 +314,27 @@ Para uma nova tabela enterprise:
 2. use overrides só onde a barra compacta realmente precisa;
 3. valide payload com backend antes de abrir opções avançadas;
 4. só então ligue tags, settings editor e variantes inline mais complexas.
+
+
+## Ciclo de vida dos editores do filtro
+
+Os painéis de preferências e de metadados são vinculados ao `DestroyRef` da origem
+pelo contrato `owner` do Settings Panel. Remover a origem encerra seus painéis e
+as assinaturas de Apply/Save. Um carregamento lazy concluído após a destruição
+do pai não abre um editor filho. O host deve destruir efetivamente o componente
+quando sua origem deixa de existir, em vez de apenas ocultá-lo por CSS.
+
+Salvar metadados no editor filho altera o rascunho do pai; a gravação da configuração
+continua pertencendo ao fluxo de Save do filtro. Destruir a origem não inicia Save
+e não implica cancelar requisições de gravação já iniciadas legitimamente.
+
+
+### Confirmação de Save nas preferências do filtro
+
+O painel aguarda a conclusão do storage antes de fechar. Apply permanece uma
+prévia sem gravação; erros de Save mantêm o rascunho aberto para nova tentativa.
+Conflitos 409/412 não são sobrescritos automaticamente. Alterações feitas durante
+uma requisição também permanecem abertas após a confirmação da versão enviada.
+O cache local de FilterConfigService é atualizado ou removido somente após sucesso
+de Save/Clear. A garantia corresponde ao storage configurado: o adapter local não
+constitui confirmação de gravação no backend.

package/docs/dynamic-filter-payload-contract.md

@@ -348,3 +348,8 @@ Toda documentação de filtro dinâmico precisa citar explicitamente:
 - quais falhas devolvem `400`.
 
 Sem isso, a doc tende a ficar “bonita na UI” e incompleta na integração real.
+
+
+## Linguagem editorial das saídas
+
+O descritor editorial registrado pelos providers oficiais do filtro e da Table distingue `change` (“Valores do filtro”) de `contextChange` (“Valores e rótulos do filtro”). O primeiro carrega os valores; o segundo inclui `filter`, `labels`, `fieldLabels` e `fields` para apresentação. Os títulos são resolvidos pelo PraxisI18nService (pt-BR/en-US, fallback e override do host), sem alterar nomes de outputs ou payloads. O Page Builder consome essa descrição pelo ComponentMetadataRegistry, preservando identificadores em detalhes técnicos.

package/docs/table-authoring-document-completeness-checklist.md

@@ -48,6 +48,19 @@ O documento será considerado completo quando:
 - [ ] `toCanonicalConfig()` não precisa buscar `advancedFilters.settings` no estado anterior do componente.
 - [ ] `applyTableConfig()` não depende mais de fallback implícito baseado no estado interno previamente aplicado.
 
+### Visibilidade dos filtros em páginas compostas
+
+No editor, **Visão geral e comportamento → Filtragem → Exibir filtros na tabela**
+controla `behavior.filtering.advancedFilters.enabled`. Desativar essa preferência
+oculta a barra interna; um widget de filtro conectado continua fornecendo critérios
+à tabela. Os critérios recebidos não dependem de renderizar a barra interna.
+
+A normalização de `advancedFilters.settings` pela aba Filtros deve preservar
+`enabled: false` explícito, inclusive ao ler, aplicar e salvar o documento.
+O editor nativo também publica configuração e bindings pelo evento existente
+`tableInputPatch`, para que o Page Builder atualize os inputs persistíveis antes
+de receber a próxima interação de outro widget.
+
 ### 5. Coerções contextuais
 
 - [ ] Coerção de `pagination.strategy` e `sorting.strategy` em modo local acontece em `toCanonicalConfig()`, não em `normalizeDocument()`.