@praxisui/list 9.0.0-beta.4 → 9.0.0-beta.5

package/docs/2026-03-executive-list-platform-backlog.md

@@ -70,18 +70,19 @@ Objetivo: suportar a referencia aberta e preparar cenarios reais.
 
 ### Itens
 
-- Evoluir `ListExpansionSectionDef` com `metadata` e `component`.
-- Evoluir `expansion` com `dataSource`, `schemaContract` e `rendering`.
-- Implementar `expansion.dataSource.mode = inline`.
-- Implementar `expansion.dataSource.mode = resource`.
-- Implementar `expansion.dataSource.mode = resourcePath`.
-- Implementar interpolacao por `paramsMap`.
-- Implementar `resourceAllowList`.
-- Bloquear `resourcePath` absoluto ou com scheme.
-- Implementar cache por item expandido.
-- Implementar cancelamento ao colapsar.
-- Implementar sanitizacao de schema com `allowedNodes`.
-- Implementar shell visual `attached` para detail row.
+- [x] Evoluir `ListExpansionSectionDef` com `metadata`, `component` e `rich-content`.
+- [x] Implementar detail inline por `expansion.sections`.
+- [x] Hospedar `RichContentDocument` em `expansion.sections[].type = rich-content`.
+- [x] Implementar shell visual `attached` para detail row.
+- [ ] Evoluir `expansion` com `dataSource`, `schemaContract` e `rendering` para detail remoto.
+- [ ] Implementar `expansion.dataSource.mode = resource`.
+- [ ] Implementar `expansion.dataSource.mode = resourcePath`.
+- [ ] Implementar interpolacao por `paramsMap`.
+- [ ] Implementar `resourceAllowList`.
+- [ ] Bloquear `resourcePath` absoluto ou com scheme.
+- [ ] Implementar cache por item expandido.
+- [ ] Implementar cancelamento ao colapsar.
+- [ ] Implementar sanitizacao de schema com `allowedNodes`.
 
 ### Criterios de aceite
 

package/docs/2026-03-executive-list-reference-checklist.md

@@ -58,7 +58,7 @@ Confirmar, ponto a ponto, que a evolucao proposta para a `praxis-list` cobre a r
 
 ## Checklist de Detail Remoto
 
-- [ ] A expansao pode operar com dados inline.
+- [x] A expansao pode operar com dados inline.
 - [ ] A expansao pode operar com `resource`.
 - [ ] A expansao pode operar com `resourcePath`.
 - [ ] O `resourcePath` suporta `paramsMap`.
@@ -72,7 +72,7 @@ Confirmar, ponto a ponto, que a evolucao proposta para a `praxis-list` cobre a r
 - [ ] As metricas suportam layouts diferentes sem hacks.
 - [ ] O trailing suporta diferentes combinacoes de alertas/owner/acoes.
 - [ ] O bloco de identidade suporta variacao de badge, subtitulo e adornos.
-- [ ] A expansao suporta sections declarativas adicionais.
+- [x] A expansao suporta sections declarativas adicionais.
 
 ## Cobertura Esperada do Contrato
 
@@ -86,6 +86,7 @@ Confirmar, ponto a ponto, que a evolucao proposta para a `praxis-list` cobre a r
 - `expansion.dataSource`
 - `expansion.schemaContract`
 - `expansion.rendering`
+- `expansion.sections[].type = rich-content`
 
 ### Cobertura completa, mas recomendando renderer dedicado
 

package/docs/adr/2026-03-list-inline-expansion-v1.md

@@ -2,9 +2,11 @@
 
 ## Status
 
-Proposto.
+Aceito e implementado no runtime atual.
 
-Nao implementado no runtime atual.
+Atualizado em 2026-06 para refletir a evolucao de `expansion.sections` com
+`metadata`, `component` e `rich-content`, alem da materializacao estruturada de
+JSON em `itemsExpr`.
 
 ## Problema
 
@@ -28,7 +30,7 @@ Consequencias da ausencia de contrato formal:
 
 Tratar expansao inline como evolucao formal do contrato do `praxis-list`, com escopo reduzido e governado.
 
-Regras normativas da proposta V1:
+Regras normativas da V1:
 
 1. A V1 cobre apenas `layout.variant = 'list'`.
 2. A V1 adiciona dois blocos novos ao contrato: `interaction` e `expansion`.
@@ -37,7 +39,8 @@ Regras normativas da proposta V1:
 5. O conteudo expandido e composto por secoes com tipos fechados e previsiveis.
 6. `cards` e `tiles` ficam fora do escopo da V1.
 7. `selection` e expansao podem coexistir, mas o trigger padrao deve favorecer icone dedicado quando houver selecao ativa.
-8. A API canônica so deve promover esse contrato para `Active` depois de implementacao, testes de acessibilidade e exemplos oficiais.
+8. A API canonica deve hospedar documentos `RichContentDocument` quando a detail row precisar de composicao editorial rica, acoes internas e layout moderno.
+9. A identidade de renderizacao da linha deve ser independente de `selection.compareBy`, para suportar recursos relacionais em que IDs de selecao ou entidades se repetem.
 
 ## Motivacao
 
@@ -48,8 +51,9 @@ Objetivos:
 - manter integridade do contrato;
 - evitar hacks de playground como falsa demostracao de capacidade;
 - preservar acessibilidade e navegacao por teclado;
-- limitar a V1 a um conjunto pequeno de padroes forte, em vez de abrir um renderer arbitrario;
+- limitar a V1 a um conjunto pequeno de padroes fortes, em vez de abrir um renderer arbitrario;
 - dar base formal para examples, authoring e documentacao futura.
+- permitir detail rows corporativas mais ricas usando o contrato canonico de rich content, sem criar uma DSL visual paralela dentro da lista.
 
 Referencia visual-alvo desta evolucao:
 
@@ -106,8 +110,17 @@ expansion?: {
   sections: Array<{
     id: string;
     title?: string;
-    type: 'info-list' | 'chip-list' | 'timeline' | 'key-value';
-    itemsExpr: string;
+    type:
+      | 'info-list'
+      | 'chip-list'
+      | 'timeline'
+      | 'key-value'
+      | 'metadata'
+      | 'component'
+      | 'rich-content';
+    itemsExpr?: string;
+    document?: RichContentDocument;
+    documentExpr?: string;
     emptyLabel?: string;
   }>;
 };
@@ -126,6 +139,11 @@ Semantica:
   - renderer fechado e governado da secao.
 - `itemsExpr`
   - expressao que aponta para a colecao renderizada a partir do item atual.
+  - pode resolver arrays/objetos JSON; o runtime materializa a estrutura em vez de exibir JSON cru.
+- `document`
+  - documento canonico `RichContentDocument` para secoes `type: 'rich-content'`.
+- `documentExpr`
+  - expressao que resolve um `RichContentDocument` por item, inclusive quando a origem vier serializada como JSON.
 - `emptyLabel`
   - fallback local ou global quando a secao nao tiver conteudo.
 
@@ -203,6 +221,58 @@ Array<{
 }>
 ```
 
+### `metadata`
+
+Uso:
+
+- propriedades regulatórias;
+- fatos operacionais densos;
+- pares chave-valor com enfase visual.
+
+Shape esperado:
+
+```ts
+Record<string, unknown> | Array<{ key: string; value: string }>
+```
+
+### `component`
+
+Uso:
+
+- componente governado registrado pelo host;
+- renderer operacional permitido por contrato.
+
+Observacao:
+
+- deve continuar sendo resolvido por contrato de widget/componente conhecido;
+- nao deve virar escape hatch para template arbitrario local.
+
+### `rich-content`
+
+Uso:
+
+- detalhe editorial moderno;
+- property sheets, action cards, badges, metricas e blocos compostos;
+- conteudo rico reutilizavel em dialogs, tabs, dashboards e expansoes.
+
+Shape esperado:
+
+```ts
+{
+  type: 'rich-content';
+  document?: RichContentDocument;
+  documentExpr?: string;
+}
+```
+
+Regras:
+
+- a lista hospeda o documento canonico de `@praxisui/rich-content`;
+- acoes internas sao mediadas por `hostCapabilities` da propria lista;
+- `confirmMessage` usa o mesmo `GLOBAL_DIALOG_SERVICE` das acoes nativas;
+- eventos sao reemitidos em `actionClick` com `payload?` e `source: 'rich-content'`;
+- isso nao autoriza HTML livre nem detail builders locais.
+
 ## Exemplo V1
 
 ```ts
@@ -259,6 +329,26 @@ const config = {
         itemsExpr: '${item.proximosEventos}',
         emptyLabel: 'Sem eventos futuros.',
       },
+      {
+        id: 'governed-detail',
+        title: 'Detalhe governado',
+        type: 'rich-content',
+        document: {
+          kind: 'praxis.rich-content',
+          version: '1.0.0',
+          nodes: [
+            {
+              type: 'propertySheet',
+              title: 'Relacionamento',
+              columns: 2,
+              items: [
+                { label: 'Conta', valueExpr: '${item.nomeConta}' },
+                { label: 'Risco', valueExpr: '${item.risco}' },
+              ],
+            },
+          ],
+        },
+      },
     ],
   },
 };
@@ -273,6 +363,10 @@ const config = {
 - persistencia cross-page do estado aberto;
 - nesting de expansao dentro de expansao.
 
+Observacao: `rich-content` nao contradiz a restricao de HTML arbitrario. Ele e
+um contrato canonico, validavel e hospedado pela plataforma, usado quando a
+expansao precisa de composicao visual rica sem perder governanca.
+
 ## Acessibilidade e WCAG AA
 
 Requisitos minimos da implementacao: