@softize/opus 29.0.0 → 31.0.0

package/docs/adr/0043-neutral-surfaces-and-interactions-use-opaque-role-tokens.md

@@ -71,3 +71,55 @@ distinguíveis e voltariam a depender de modifiers locais.
 - primitives neutras usam os mesmos tokens em light e dark, sem receitas locais equivalentes;
 - testes cobrem a projeção dos tokens e os estados de tabela, toggle, menu e navegação lateral;
 - a aplicação consumidora é compilada e verificada em páginas com canvas, card, formulário e grid.
+
+## Calibração da navegação — 2026-10-20
+
+O fundo `muted` opaco distingue a sidebar no claro, mas dá peso excessivo a essa área extensa
+no escuro. `sidebar` passa a representar a superfície de navegação, com `foreground` para o
+texto: usa `muted` no claro e `control` no escuro, acompanhando os eixos de aparência existentes.
+Os consumidores usam `bg-sidebar`, sem transparência nem ramificações locais por tema.
+
+Recalibrar `muted` globalmente alteraria também botões e fundos discretos já aprovados. Manter
+receitas `dark:` nos consumidores duplicaria a decisão. O alias semântico permite ajustar a
+navegação independentemente, sem introduzir outro controle de aparência ou mudar o fundo padrão
+da primitive Sidebar. Os testes de aparência incluem o novo papel nas verificações de contraste
+do texto, e a aplicação verifica as sidebars de Configurações e dos recursos nos dois temas.
+
+## Canvas branco no claro — 2026-10-20
+
+O preset claro passa a usar branco puro em canvas, controles, cards e popovers. A calibração
+quase branca anterior separava pouco as superfícies e ainda deixava o fundo geral acinzentado.
+Bordas, espaçamento e elevação continuam distinguindo as regiões; a sidebar mantém seu tom
+próprio. Esta decisão substitui a exigência de diferença de luminosidade entre essas superfícies
+no preset claro. Estados de interação, bordas e tema escuro preservam os valores calibrados.
+
+Com o canvas branco, a sidebar clara é recalibrada para luminosidade de 95% no preset,
+1,5 ponto abaixo de `muted`. Isso reforça a separação da navegação sem alterar os estados
+neutros globais. O token escuro continua no degrau de `control`.
+
+## Navegação interna — referência visual de 19/10/2026
+
+A referência fornecida distingue barra global, navegação interna e conteúdo. A calibração
+adotada cobre a navegação interna, quase branca (`#fcfcfc`), sobre conteúdo branco. O fundo da
+sidebar geral permanece como estava, por decisão explícita do produto. `sidebar` fica um ponto
+abaixo do canvas no claro e no degrau de `control` no escuro. Isso substitui a calibração clara
+de 95% acima.
+
+No preset claro, a seleção usa `#f0f0f0`. Hover usa um degrau intermediário (`#f4f4f4`) e pressão
+um degrau mais definido (`#e8e8e8`), pois esses estados não estão demonstrados na referência.
+Os tokens de interação continuam compartilhados entre os componentes. O escuro não muda.
+Os testes verificam as superfícies e os estados em conjunto, inclusive a leitura do texto.
+
+## Calibração escura — referência visual de 19/10/2026
+
+A referência escura usa conteúdo `#181818`, navegação interna `#1d1d1d`, seleção `#2f2f2f`
+e borda `#363636`. O canvas sobe para 9,4% de luminosidade no preset; a camada elevada fica
+em 11,4% e o controle em 10,4%. A sidebar interna acompanha a camada elevada. Muted, hover,
+seleção e pressão preservam os valores do preset escuro já calibrados.
+
+A primeira calibração preservou a base anterior da navegação global. Na validação seguinte,
+o produto definiu que a sidebar geral deve parecer contínua com o fundo, como no light.
+`sidebar-global` passa a acompanhar `background` nos dois temas. O fundo permanece opaco:
+a continuidade vem da igualdade de cor, sem depender de composição alpha. A navegação interna
+mantém seu papel distinto. A primitive Sidebar não impõe fundo; o hospedeiro escolhe o token.
+Os testes cobrem os valores, contraste do texto e a aplicação dos papéis nas duas regiões.

package/docs/adr/0044-neutral-appearance-derives-from-bounded-axes-per-mode.md

@@ -35,8 +35,11 @@ declara os presets dos dois modos e usa as entradas claras; `.dark` troca para a
 aplicação pode gravar os dois conjuntos no mesmo elemento, e alternar o tema não exige reaplicar
 nada.
 
-Com os eixos no preset, a derivação reproduz exatamente os valores calibrados pela ADR 0043. Quem
-não personaliza não percebe diferença.
+Na adoção inicial, os presets reproduziam os valores calibrados pela ADR 0043. A calibração de
+19/10/2026 reforça fundos discretos, estados e bordas no claro, separa `muted` de hover no escuro
+e reforça as bordas escuras. A escala continua opaca e o zero continua sendo o piso: os valores
+salvos dos quatro eixos são preservados, mas passam a atuar sobre a nova calibração. Os valores
+de referência atuais estão em `tests/ui/appearance-tuning.test.ts`.
 
 ### Limites
 
@@ -131,3 +134,25 @@ com os primitives existentes.
   opacos nos dois temas;
 - a aplicação consumidora verifica visualmente os extremos de cada eixo em páginas com canvas,
   card, formulário e grid, nos dois modos.
+
+## Ajuste do preset claro — 2026-10-20
+
+Canvas e controle passam a branco puro, acompanhando cards e popovers (emenda da ADR 0043).
+A separação inicial entre essas superfícies é zero no claro; o eixo de camadas continua podendo
+ampliá-la. A base dos estados neutros permanece um ponto abaixo do canvas para preservar a
+calibração de sidebar, muted, interação, borda e texto. O preset escuro permanece igual.
+
+## Calibração escura por referência — 19/10/2026
+
+O preset escuro passa a canvas de 9,4%, camada elevada de 11,4% e controle de 10,4%. A base
+mínima do canvas é 5,5%, em vez de preto puro; os eixos ainda só ampliam as separações a partir
+do preset. Os offsets de estado são compensados para manter muted, hover, seleção e pressão.
+Borda fica em 21%. `sidebar-global` acompanha o canvas nos dois temas, conforme a atualização da ADR 0043.
+
+## Redução proporcional do dark — 19/10/2026
+
+Após a calibração pela referência, as superfícies, linhas e estados neutros do dark recebem
+um fator final de 0,95 na luminosidade HSL. O fator é aplicado uma única vez na cor resultante,
+sem acumular redução entre canvas, controle e camada. A proporção entre esses valores é
+preservada; texto, primary, contextos semânticos e tema claro ficam inalterados. A calibração
+permanece interna ao tema, sem uma nova preferência pessoal.

package/docs/adr/0045-surface-replaces-content-and-card.md

@@ -17,6 +17,9 @@
   `Surface`.
 - **Não altera:** `Page`, `Dialog`, `Drawer` e `Pane`, que mantêm famílias, slots e mídia próprios.
 
+A ADR 0063 substitui parcialmente esta decisão: `SurfaceMeta` passa a representar a faixa
+de metadados; o contador na linha do título passa a usar `SurfaceCount`.
+
 ## Contexto
 
 Quem monta uma tela precisa delimitar e nomear um trecho dela: uma seção da página, um grupo de

package/docs/adr/0060-surface-composition-separates-chrome-and-intro.md

@@ -159,3 +159,145 @@ o título em uma composição inline com quebra, sem criar um novo slot estrutur
 
 `contentClassName` em Page e PageBody configura largura e alinhamento internos; `className`
 controla a moldura e o viewport, respectivamente. Presentation fora do shell preserva largura total.
+
+## Revisão de 16/10/2026 — Page com cabeçalho único
+
+A validação no consumidor Grand Brasil substitui o formato com intro de Page: título, ações
+e retorno pertencem ao header fixo; metadados vêm abaixo da linha principal. A Page ocupa
+a largura disponível, usa recuo de 2rem, título de 1,5rem, linha mínima de 2,25rem e ações
+`default`/`icon`. Regiões são sempre seccionadas. Drawer, Dialog e Surface mantêm as opções
+existentes e controles compactos. A separação entre `flow` e `fill` continua governando
+rolagem, sem alterar a anatomia.
+
+`PageBack` é uma ação de ícone com destino explícito e tooltip, primeira na região de ações.
+Breadcrumb não compõe a Page. A composição antiga de intro/navegação não é o caminho
+canônico e os consumidores devem migrar para PageHeader; Presentation gera a mesma estrutura.
+A alternativa de classes por consumidor foi descartada por repetir o contrato visual.
+Testes de Page, Presentation e anatomia cobrem medidas, heading único, retorno, estados
+integrais e preservação dos modais.
+
+Experimento local após a revisão: Page usa recuo de 1rem nas regiões, igual aos modais
+seccionados. O título também usa 1,125rem, como nos headers de Drawer e Dialog. As ações
+mantêm o tamanho normal de Page.
+
+Ajuste local seguinte: os cabeçalhos de Page, Drawer, Dialog e Surface compartilham
+ações `default`/`icon` e linha mínima de 2,25rem. O fechamento nativo dos modais usa
+a mesma escala; `closeSize` mantém as opções menores para composições explícitas.
+
+### Experimento de abas no cabeçalho
+
+Para manter a navegação entre painéis visível enquanto o corpo rola, os headers de
+Page, Drawer, Dialog e Surface aceitam `tabs`, contendo um `TabsList` do Tabs existente.
+A região entra abaixo da linha de título e ações, com o mesmo alinhamento lateral.
+O divisor inferior pertence ao header; a lista de abas não acrescenta outra linha.
+O estado, as relações ARIA e o teclado continuam no Tabs que envolve a superfície.
+
+Manter as abas no body exigiria repetir posicionamento e recuos em cada consumidor.
+Criar outro controlador duplicaria o contrato de Tabs. A região opcional no header
+é reversível e mantém a composição sem abas inalterada. Alertas e legendas de fieldset
+não aceitam essa navegação. O piloto é E-mails; testes verificam troca de painel,
+semântica, ausência de divisor duplicado e preservação da composição sem abas.
+
+O piloto separa ações gerais de ações da aba: `tabsActions` ocupa o extremo oposto
+a `tabs` na mesma faixa, sem participar do tablist. A região exige `tabs` e mantém
+os botões no fluxo normal de foco, com a mesma escala dos demais headers.
+
+### Ações das coleções
+
+Ações que afetam a coleção pertencem à toolbar do ActionList, inclusive criação,
+mesmo quando não dependem do recorte atual. Cabeçalhos preservam as ações gerais
+da superfície. Presentation ganha o placement explícito `toolbar`, válido apenas
+quando seu body declara uma action list; `header` continua significando o header.
+O comando pode declarar `label` para a apresentação contextual, sem renomear o
+contrato nem o formulário de destino. A criação pode assim exibir “Criar”. A validação
+rejeita toolbar em bodies sem lista, e o renderer deve manter header e toolbar distintos.
+
+## Consolidação de 18/10/2026 — anatomia única
+
+A validação da aplicação substitui a escolha entre composição compacta e intro por um
+cabeçalho único em Page, Dialog, Drawer e Surface. Título, descrição opcional, metadados e
+operações gerais pertencem ao Header; o Body contém o conteúdo. As exportações Intro e
+IntroActions dos modais são removidas, assim como `SurfaceLayout`, `surfaceLayout` da Page
+e `layout` visual de Surface, DialogContent e DrawerContent. Não há alias de compatibilidade.
+`Page.layout="flow" | "fill"` permanece: governa rolagem, não aparência.
+
+As regiões derivam seus divisores da vizinhança. Superfícies delimitadas usam recuo de 1rem
+em header, body e footer; a Surface sem moldura mantém alinhamento com o hospedeiro e ritmo
+de 1rem entre as regiões. A linha de cabeçalho reserva 2,25rem e ações usam tamanho normal.
+A semântica de alerta do Dialog continua própria: exige uma resposta e não é uma opção de
+densidade visual. Fieldset mantém legend nativa, em faixa quando delimitado.
+
+As abas pertencem ao header e os comandos de coleção à barra da lista. `tabsActions`, criado
+no experimento, é removido. Comandos de linha e seleção preservam seus slots. Exemplos,
+metadata, regras do checker e consumidores migram juntos; testes verificam API removida,
+regiões, foco, rolagem e criação contextual. Manter modos antigos foi descartado porque
+permitiria reintroduzir a divergência que motivou a revisão.
+
+A Surface sem moldura não acrescenta padding nem divisor entre regiões: o intervalo é
+1rem, alinhado ao hospedeiro. Fieldset sem moldura mantém legend sem sublinhado. Abas
+integradas conservam sua própria linha de seleção, encostada na base do Header.
+Surface nível 1 continua disponível fora da Page; dentro dela, seções são subordinadas
+e o título principal pertence ao PageHeader, ou ao PageState integral ativo.
+
+
+## Piloto: composição de documento
+
+A avaliação visual em Segurança reabre a escolha de composição sem reintroduzir Intro.
+`Page composition="document"` reúne Header, Body e Footer em uma coluna central de até
+56rem, com recuo externo de 1rem nas laterais e 2,5rem na vertical. A Page inteira rola
+na borda disponível; título e conteúdo seguem juntos, sem divisor entre as regiões.
+`composition="standard"` preserva o cabeçalho fixo e o corpo em toda a largura.
+A opção visual é independente de `layout`, que continua indicando ocupação; documento
+aceita somente `flow`, pois não delega rolagem a uma lista ou canvas interno.
+
+A Presentation encaminha `pageComposition` à Page que possui ou à Page do conteúdo.
+O piloto na aplicação fica restrito a Segurança, sem publicação nem propagação antes da
+avaliação visual. A escolha geral de divisores (`sectioned`) permanece em reavaliação;
+este piloto não restaura essa API nem altera Drawer e Dialog.
+
+## Experimento: largura independente da composição — 2026-10-18
+
+Preferências curtas precisam de uma coluna menor, enquanto tabelas precisam aproveitar a área
+central. A Page aceita `width="narrow" | "default" | "wide"`: limites de 42rem, 58rem ou toda a
+largura disponível. O limite envolve header, body e footer juntos, preservando seu alinhamento e
+padding. Sem largura explícita, documento conserva default e a composição standard conserva wide.
+A declaração serializável usa `page.width`; a prop width externa da Presentation continua exclusiva
+do dimensionamento de diálogos. A contribuição do shell repassa a largura à Page do consumidor.
+A alternativa de classes particulares por tela foi descartada para manter três escolhas revisáveis.
+Segurança e Conversas exercitam os extremos; E-mails conserva a largura intermediária.
+
+Na avaliação seguinte, a composição document passa a usar padding uniforme de 2,5rem.
+O limite da coluna continua incluindo esse padding. A composição standard preserva 1rem,
+assim como Drawer e Dialog; o recuo depende da composição, não da largura escolhida.
+
+## Correção: documento também pode preencher a altura — 2026-10-18
+
+Conversas revelou que a composição document não deve obrigar uma listagem a crescer na página.
+Ela passa a aceitar `layout="fill"`: mantém título, ausência de divisor e padding aberto, mas
+limita a coluna à altura disponível e entrega a rolagem aos resultados da ActionList. O padrão
+flow continua rolando título e conteúdo juntos. Isso substitui a restrição inicial do piloto;
+composição visual e ocupação de altura são escolhas independentes.
+
+## Consolidação: uma aparência de Page — 2026-10-18
+
+A avaliação concluiu que standard e document eram duas aparências para a mesma anatomia,
+sem usos distintos que justificassem a escolha em cada tela. A Page adota o visual aberto:
+padding de 2,5rem, título de 1,875rem, intervalo de 1,5rem após o cabeçalho e
+1rem entre as demais regiões, sem divisores. Removem-se composition,
+pageComposition e page.composition, sem aliases. Header, Body e Footer permanecem.
+
+Largura e ocupação continuam independentes: width narrow/default/wide e layout flow/fill.
+A largura omitida é wide, preservando o espaço das listagens existentes; os antigos documentos
+intermediários passam a declarar width default. Flow rola o conjunto; fill reserva altura para
+a região interna. Drawer e Dialog continuam delimitados, com seu padding de 1rem.
+A migração cobre consumidores e projeções; testes verificam herança da largura, fill e a anatomia
+única. Essa decisão substitui os dois tratamentos visuais dos experimentos anteriores.
+
+## Seções e cabeçalhos declarados em Configurações — 2026-10-18
+
+A adoção em toda a área de Configurações exige manter widgets com comportamento específico sem
+transferir a página inteira para body.component. Seções de conteúdo referenciam slots nomeados;
+seções de lista podem apresentar tabela ou itens por um adaptador tipado do contrato. Cabeçalho
+aceita referências a título dinâmico, metadados e ações, mantendo os slots nativos de cada superfície.
+Page.layout pode ser declarado junto de width. O runtime contém callbacks e dados, nunca código
+serializado. Referências ausentes falham antes da montagem; o JSON não aceita funções ou HTML.

package/docs/adr/0062-listas-contidas-e-texto-flexivel.md

@@ -0,0 +1,68 @@
+# ADR 0062 — Listas contidas e texto flexível
+
+Data: 2026-10-15
+Status: Aceita
+
+## Contexto
+
+Descrições sem quebra faziam uma tabela de Habilidades ocupar 92,21rem dentro de
+63,13rem disponíveis. A coluna implícita do grid de resultados do ActionList
+crescia pelo conteúdo; o contêiner da tabela crescia junto e não oferecia sua
+rolagem horizontal. A largura mínima da página não limita a largura dos filhos.
+
+## Decisão
+
+Table contém sua largura e quebra texto entre palavras por padrão. `overflow-wrap:
+break-word` preserva a largura intrínseca das palavras, evitando que uma descrição
+comprida faça uma coluna como “Inativo” quebrar no meio. Identificadores sem espaços
+podem exigir rolagem interna; `wrap-anywhere` fica disponível como opção explícita.
+Classes explícitas continuam permitindo
+células sem quebra. ActionList limita sua coluna de resultados ao espaço
+recebido e permite encolhimento ao longo da cadeia de flex/grid.
+
+`fit` preserva valores compactos sem quebra, como números e datas. O cabeçalho
+de uma coluna declarada pode quebrar entre palavras. Textos flexíveis recebem o
+restante do espaço. Não há redução de tipografia nem ocultação automática de colunas.
+
+A barra de filtros pode ocupar mais de uma linha, mantendo a ordem dos controles.
+Uma tabela que ainda exceda a largura disponível rola dentro da lista: em flow,
+no contêiner da tabela; em fill, na região de resultados que também ancora o
+cabeçalho fixo. O rodapé e a toolbar não acompanham essa rolagem.
+
+## Alternativas e consequências
+
+Largura fixa e repartição igual sacrificariam espaço das colunas textuais mesmo
+quando controles curtos não precisam dele. Ocultar o excesso perderia dados e
+ações. Regras CSS no aplicativo duplicariam o comportamento do pacote.
+
+A quebra pode aumentar a altura das linhas. Consumidores com células compostas
+continuam responsáveis por permitir encolhimento dos filhos flex e por declarar
+larguras mínimas somente quando necessárias. Comparativos com colunas mínimas
+explícitas continuam usando rolagem horizontal.
+
+## Verificação
+
+Testes em Chromium medem contenção, textos longos, filtros, valores compactos e
+rolagem nos modos flow e fill, incluindo a posição do cabeçalho após rolar.
+Os testes estão em `tests/browser/action-list-width.test.tsx` e cobrem também
+palavras curtas ao lado de descrições longas e tokens sem espaços.
+
+## Revisão da distribuição entre colunas — 2026-10-15
+
+Na validação de Consumo, quatro colunas `fit` ficavam comprimidas enquanto a coluna
+textual recebia cerca de 70% da largura. A largura mínima forçada fazia o navegador
+quebrar títulos mesmo com espaço disponível. Retirar essa restrição reduziu a coluna
+textual para cerca de 38% e acomodou os cabeçalhos numa linha, no mesmo contêiner.
+
+Colunas de dados passam a participar da distribuição automática da tabela, considerando
+cabeçalhos e valores. `fit` continua preservando valores sem quebra, mas não impõe
+largura mínima artificial. Cabeçalhos podem quebrar quando o espaço realmente faltar.
+Seleção, ações de linha e células contendo apenas um switch continuam compactas.
+O switch pode ser filho direto ou estar envolvido pelo TooltipTrigger. A regra usa a
+estrutura do controle, sem depender do nome da coluna; células com conteúdo misto
+continuam participando da distribuição natural.
+
+Não se distribui largura igualmente nem se mede texto em JavaScript. O algoritmo
+nativo considera o conteúdo e o espaço recebido; a contenção e a rolagem descritas
+acima permanecem. Os testes de navegador cobrem várias colunas numéricas ao lado de
+texto, tanto com espaço suficiente quanto em contêiner estreito, em flow e fill.

package/docs/adr/0063-metadados-das-superficies.md

@@ -0,0 +1,44 @@
+# ADR 0063 — Metadados das superfícies em região própria
+
+- **Status:** aceita.
+- **Data:** 2026-10-15.
+- **Complementa:** ADR 0060.
+- **Substitui parcialmente:** ADR 0045 quanto à posição e função de SurfaceMeta.
+
+## Contexto
+
+Badges, autoria e datas disputam espaço com o título ou usam o subheading como container.
+A descrição é orientação textual próxima ao heading; metadados precisam de espaçamento
+próprio e quebra de linha sem alterar o tamanho ou o significado do título.
+
+## Decisão
+
+PageMeta, DrawerMeta, DialogMeta e SurfaceMeta compõem uma faixa opcional após a linha
+que contém título, descrição e ações. Não são headings nem descrições acessíveis dos modais.
+As três primeiras famílias aceitam Meta em Intro ou Header compacto; Surface mantém
+Meta em SurfaceHeader, pois não possui Intro. Meta exige título na mesma composição.
+Dialog em modo de alerta não aceita Meta; informações necessárias à resposta pertencem ao corpo.
+
+O intervalo superior é de 0,75rem; itens usam 0,75rem na horizontal e 0,5rem entre linhas.
+A faixa permite quebra, conserva a tipografia dos badges e não insere separadores nem
+busca dados. Sem Meta não há espaço reservado. Uma composição aceita no máximo um Meta.
+As formas curtas de Page e Surface aceitam a prop meta. Fieldset preserva a legend
+restrita a título e mídia decorativa; seus metadados pertencem ao corpo.
+
+SurfaceCount preserva o contador ao lado do título e recebe count na forma curta.
+SurfaceMeta deixa de ocupar essa posição: consumidores de contadores explícitos migram
+para SurfaceCount. Consumidores de contexto editorial permanecem em SurfaceMeta.
+
+## Alternativas
+
+Usar Description conservaria a mistura de prosa e metadados. Colocar wrappers livres no
+Body repetiria espaçamento nos consumidores e afastaria o contexto da identidade. Manter
+SurfaceMeta como contador faria o mesmo nome expressar funções diferentes entre famílias.
+
+## Verificação
+
+Testes renderizados e checker cobrem posição, unicidade, pai permitido e título obrigatório.
+Contadores permanecem ao lado do título. Testes no navegador conferem intervalo e quebra
+nas famílias, incluindo headers compactos com ações. As evidências pertencem aos arquivos
+`tests/ui/surface-meta.test.tsx`, `tests/browser/surface-meta.test.tsx` e
+`tests/check/check.test.ts`. Publicação e adoção dependem de autorização de entrega.

package/docs/adr/0064-action-list-com-itens-e-fontes-externas.md

@@ -0,0 +1,47 @@
+# ADR 0064 — ActionList apresenta itens e conecta fontes externas
+
+- **Status:** experimental, piloto local em Segurança.
+- **Data:** 2026-10-18.
+
+## Contexto
+
+Coleções pequenas em Configurações usam ItemGroup com título, descrição e ações por item.
+ActionList já governa consulta, erro, vazio e paginação, mas exige uma função React para
+esse visual. Sessões pertencem ao IdP e não devem ganhar endpoint ou contrato de negócio
+paralelo apenas para reutilizar a lista.
+
+## Decisão
+
+ActionList recebe `item: { title, description? }`, cujos valores são nomes de campos do
+resultado. O objeto é serializável; a renderização usa ItemGroup, Item e separadores do
+catálogo. `rowActions` também atende itens. `title` nomeia a coleção e suas
+`toolbarActions` ficam junto dele; filtros continuam em sua própria barra quando existem.
+As ações podem receber contexto de resultados e refetch, sem uma consulta duplicada.
+Uma lista em itens esconde o rodapé quando há somente uma página, mas mantém o paginador
+quando há mais resultados. Tabelas e composições existentes conservam seu comportamento.
+
+A origem continua sendo uma action por padrão. A alternativa explícita `source` recebe
+uma chave de cache com escopo e um loader que retorna o envelope paginado. É um adaptador
+runtime de fonte externa, não uma action nem um endpoint. A consulta usa o mesmo mecanismo
+de cache e estados do driver. Fontes externas não mantêm cache após desmontar a lista e
+não herdam o transporte Opus. O adapter declara paginação real sobre o conjunto recebido;
+a UI nunca esconde registros para simular uma única página.
+
+No piloto, a fonte chama o cliente Better Auth existente e projeta somente identificador,
+nome do dispositivo e data formatada para a lista. Tokens ficam na closure do adapter para
+revogação, fora dos itens, do DOM, do cache da lista e de declarações JSON. Operações e
+permissões continuam no IdP. A fonte e callbacks não são serializáveis: a futura composição
+JSON deverá referenciá-los por registro, sem embutir funções ou credenciais.
+
+## Alternativas
+
+- Uma função children resolve o visual hoje, mas repete anatomia e impede declarar os campos.
+- Uma action de sessões paralela duplicaria a fronteira de autenticação.
+- Uma coleção inteiramente nova repetiria estados, paginação e invalidação do ActionList.
+
+## Verificação
+
+Testar consulta por action e fonte externa, estado inicial, erro e recuperação, vazio,
+ações por item, atualização, paginação e remoção na última página. No piloto, testar
+revogação com o cliente do IdP simulado e inspecionar o visual na rota real sem encerrar
+sessões de outras pessoas. O modo de tabela mantém suas regressões existentes.