@softize/opus 18.0.1 → 18.1.1

package/CHANGELOG.md

@@ -7,6 +7,109 @@ Depois de qualquer bump, rode os gates (`typecheck` · `test` · `opus check` ·
 `opus copy --check` · `base copy check` · `manifest:check`) — eles apontam o que a
 mudança cobra do seu código.
 
+## 18.1.1 — 2026-09-16
+
+**Correção de segurança.** Quem executa tools de IA só roda o que `aiTools()` anunciou. Até aqui, o
+servidor MCP executava em `CallTool` qualquer action registrada, e o agente co-locado executava
+qualquer nome de tool que o modelo emitisse. Um cliente MCP, um modelo ou um prompt injetado podia
+rodar uma action sem `ai.enabled` — inclusive destrutiva — dentro da autorização do contexto
+resolvido. Os dois caminhos agora recusam o nome fora do conjunto exposto, com a mesma resposta
+para action inexistente e para action registrada mas não exposta, sem revelar quais existem.
+Nenhuma mudança é necessária em quem já marcava com `ai.enabled` as actions que expõe; quem
+dependia de chamar pelo MCP uma action não marcada precisa marcá-la.
+
+Uma action que não é `public` passa a exigir usuário ANTES de rodar os loaders. Antes, os
+`loads` consultavam dados para um chamador anônimo, que recebia o erro do loader — um
+`not_found`, por exemplo — e podia usar essa diferença para descobrir se um registro existe. O
+`authorize` continua depois dos loaders, porque depende do que eles carregam.
+
+`RadioGroupItem` passa a ter a classe `peer`, como `Checkbox` e `Switch`: o `Label` associado
+esmaece quando o item está desabilitado, como a documentação já descrevia. Em `DetailGroup` com
+moldura e orientação horizontal, a largura padrão da coluna de rótulos passa a ser uma classe, e
+uma classe do consumidor (`[--detail-label-width:9rem]`) volta a substituí-la; antes, só `style`
+conseguia.
+
+A documentação publicada foi revisada por inteiro, e as 92 páginas foram abertas num navegador
+headless sem erro de console nem de preview. O exemplo principal de Presentation voltou a
+renderizar: ele usava funções que não estavam no escopo dos previews e lançava `ReferenceError`.
+Um exemplo do `IconPicker` declarava `Icon`, nome que o escopo já fornece, e mostrava um erro de
+sintaxe no lugar do preview. Um gate novo compila cada preview com o escopo da sua página, do jeito
+que o site o executa, e reprova nome ausente ou redeclarado; o anterior só conferia tags JSX. Sessenta e quatro páginas foram
+corrigidas contra o código: props, defaults e tipos que não batiam, exemplos que não compilavam ou ensinavam padrões
+substituídos pelas versões 16 a 18, e afirmações que o código não sustenta. Entre elas, `auth.md`
+deixa de sugerir que o runtime aplica um campo `auth` inexistente, e `upgrading.md` passa a incluir
+`pnpm run setup` e os gates de copy, sem os quais o fluxo de upgrade falhava no primeiro gate.
+
+`opus check --help` lista as regras de Produto de Dados. As ADRs que dividiam número foram
+renumeradas: a do cabeçalho modal passa a 0018 e a da densidade compacta, a 0019; um gate impede
+nova colisão. O guia de release passa a dizer que a documentação é publicada à parte, com
+`pnpm deploy:docs`. A skill `build-opus-ui` passa a ensinar `placement` nos filtros e o
+`ButtonGroup` nos footers modais.
+
+### Correções do histórico
+
+Estas entradas publicadas descrevem algo diferente do que o código daquela versão fez. Elas não
+foram reescritas; a correção fica registrada aqui.
+
+- **17.2.1 nunca foi publicada.** O conteúdo daquela entrada — `renderMessageActions` nas mensagens
+  enviadas, `activity=""` e o `title` das tools MCP — saiu na 18.0.0.
+- **17.0.0 e 17.2.0 mudaram a composição explícita dentro de `PageShell` sem aviso de quebra.** A
+  17.0.0 passou a exigir `PageHeader` onde a 16.x exigia `PageIntro`, e a 17.2.0 voltou a exigir
+  `PageIntro`. Desde a 18.0.0, ambos são opcionais e a página exige um único heading principal.
+- **18.1.0:** `Item size="sm"` reduz também o espaço entre regiões, para `0.625rem`, e não somente o
+  padding vertical. A mesma versão trocou o fechamento de Dialog e Drawer, que na 18.0.1 era um
+  `Button` `icon`, pelo `CloseButton` (`neutral`, `subtle`, forma de pílula e `icon-sm`), com
+  a nova prop `closeSize`; nenhum dos dois foi anunciado. Ela também removeu breakpoints responsivos
+  e mudou o footer padrão do `ActionFormDialog`; quem tinha testes visuais ou telas abaixo de
+  `64rem` precisa revisá-los.
+
+## 18.1.0 — 2026-09-15
+
+A UI passa a assumir layout desktop fixo com largura mínima suportada de `64rem`. Breakpoints de
+viewport e container queries isoladas saem dos componentes; grids, dialogs, drawers e campos
+preservam o estado correspondente a essa largura. Consultas de acessibilidade e capacidade, limites
+contra a viewport e overflow continuam ativos. `ActionFormDialog` e Presentations modais passam a
+dimensionar o footer pelo conteúdo, com `Cancelar` em `ghost`; `footerDistribution="equal"`
+permanece disponível como escolha explícita e usa cancelamento `outline`.
+
+Filtros de list actions passam a declarar `placement: 'inline' | 'advanced' | 'external'`.
+Filtros `external` continuam no estado navegável e no input, mas deixam a apresentação para o
+consumidor; filtros avançados podem ser agrupados por `section`, distribuídos em até três colunas
+com `advancedFilters.columns` e usam calendário nos campos de data. A propriedade `advanced`
+continua aceita durante a migração e equivale a `placement: 'advanced'`.
+
+Tools de IA e MCP passam a projetar também as labels dos Produtos de Dados relacionados, mantendo
+os identificadores técnicos existentes. Hosts podem apresentar nomes legíveis sem perder a
+rastreabilidade usada na execução e na auditoria.
+
+Alert, Toast e Item passam a compartilhar a densidade compacta das superfícies horizontais:
+`0.75rem` de padding no tamanho padrão e corpo produtivo de `0.875rem`. Cada componente declara o
+corpo produtivo na própria raiz, sem alterar a tipografia de `html` ou `body`; folhas internas de
+Alert e Item deixam de repetir a classe já estabelecida pela raiz do componente. `Item size="sm"`
+reduz somente o padding vertical para `0.5rem`. Rótulos de formulário também usam explicitamente
+o corpo produtivo; `text-xs` permanece reservado a metadados compactos, como rótulos de detalhes.
+
+`ToggleGroupItem` preserva seu estado selecionado quando compõe um `TooltipTrigger` com `asChild`.
+O tooltip continua disponível sem substituir os atributos que identificam e marcam visualmente o
+item ativo.
+
+`TabsList variant="line"` passa a desenhar uma linha-base por toda a largura disponível na
+orientação horizontal, mantendo as abas compactas e o indicador ativo sobre a borda. Dentro de
+`DrawerBody` ou `DialogBody`, a linha atravessa os gutters até as bordas sem deslocar os rótulos. Os itens usam
+padding horizontal zero, padding vertical de `0.75rem` e gap de `1.25rem`.
+A altura do `line` horizontal passa a acompanhar o conteúdo, permitindo que esse padding defina
+a área interativa em vez de ficar contido pela altura da escala de controles. A orientação vertical
+preserva seu padding anterior. `Field orientation="responsive"` continua aceito como alias do layout
+desktop horizontal, sem reintroduzir breakpoints.
+
+Campos de entrada passam a usar `bg-muted/30` no tema claro, preservando no escuro o contraste de
+`bg-input/30`. O cabeçalho da `Table framed` compartilha essa superfície. O footer de `Dialog`
+usa uma versão mais suave desse mesmo fundo. A moldura do modal fica transparente no light e sutil
+no dark; o backdrop volta a escurecer a página sem aplicar blur.
+
+`Button variant="outline"` passa a ter fundo transparente em repouso nos contextos neutral,
+primary e danger. A borda, o texto semântico e o preenchimento de hover permanecem inalterados.
+
 ## 18.0.1 — 2026-09-13
 
 Controles somente com ícone que pertencem ao chrome da superfície, como voltar e fechar, usam o
@@ -60,6 +163,8 @@ a API imperativa, usam `outline`; a decisão principal continua `solid`.
 
 ## 17.2.1 — 2026-09-12
 
+> Esta versão nunca foi publicada no npm; o conteúdo abaixo saiu na 18.0.0.
+
 O `Chat` passa a renderizar `renderMessageActions` também nas mensagens enviadas. Data, cópia e
 outras ações contextuais podem usar a mesma extensão discreta nos dois lados da conversa.
 `activity=""` oferece o indicador compacto, com somente os pontos centralizados e “Pensando…”

package/PROMOTED.md

@@ -1,11 +1,10 @@
 # Enhancements promovidas ao Opus
 
 O registro CURADO da régua "o Opus cresce por reincidência". O fluxo vivo NÃO passa por
-edição manual deste arquivo: o agente no projeto aponta em `.opus/issues.jsonl` do repo
-dele (instrução na skill `implement-opus-change`; `type` **enhancement** ou **bug**) →
-o Maestro colhe no boot da sessão e abre a **Issue no repo do Opus**
-(`github.com/softize-dev/opus`, dedup por hash + ledger), onde a triagem e a decisão
-acontecem (aberta = pendente, fechada = decidida). Enhancement aceita com **n ≥ 2**
+edição manual deste arquivo: cada apontamento vira uma **Issue no repo do Opus**
+(`github.com/softize-dev/opus`), `type` **enhancement** ou **bug**, onde a triagem e a
+decisão acontecem (aberta = pendente, fechada = decidida). O pacote não coleta nada do
+projeto consumidor por conta própria. Enhancement aceita com **n ≥ 2**
 ocorrências reais — comportamento se paga na reincidência; estilo e conveniência não.
 Bug (defeito NO Opus) aciona com n=1: vira fix + CHANGELOG, **não** entra neste ledger.
 

package/README.md

@@ -1,6 +1,6 @@
 # Opus
 
-> **Status:** v0 — pacote único `@softize/opus` com subpath exports (core + adapters). Uma versão, sem semver por módulo.
+> Pacote único `@softize/opus` com subpath exports (core + adapters). Uma versão, sem semver por módulo.
 
 Protocolo de actions de ponta a ponta para TypeScript. Declare uma vez — input, autorização, execução, auditoria, feedback — e deixe os adapters materializarem a action na interface, no cliente, no servidor e no log.
 
@@ -43,6 +43,7 @@ Um pacote (`@softize/opus`), uma versão. Cada categoria abaixo é um **subpath
 | `@softize/opus/testing` | — | Harness de teste de actions pela fronteira do contrato (experimental) |
 | `@softize/opus/dsl` | — | Expressões declarativas avaliadas em `load` e em consultas |
 | `@softize/opus/seed` | — | Declaração e binding de datasets verificáveis operados pela CLI |
+| `@softize/opus/presentation` | — | Presentations portáteis: `definePresentation`, invocação e rotas |
 | `@softize/opus/vite` | — | Plugins Vite: runtime em modo design e auth de sessão fixa |
 
 Os drivers são resolvidos por subpath ESM (no estilo do Drizzle): `@softize/opus/server/fastify`, `@softize/opus/data/kysely`.
@@ -90,7 +91,7 @@ await app.listen({ port: 3000 })
 src/
   core/      schema/    server/    client/    ui/      data/    auth/    audit/
   log/       queue/     events/    scheduler/ storage/ cache/   ai/      mcp/
-  observability/        testing/   dsl/       seed/    vite/
+  observability/        testing/   dsl/       seed/    vite/    presentation/
 registry/    # scaffolds + skills Opus — geração e conhecimento do SDK, não runtime
 bin/         # CLI (opus create/setup/gen/copy/check/db/seed/pre-push/introspect/mcp) + libs
 docs/
@@ -117,8 +118,8 @@ O contrato não oferece reset/truncate, e `apply` precisa convergir quando repet
 
 ## Status
 
-- **v0**: 21 superfícies, suíte vitest com cobertura medida por `pnpm test:cov`. O threshold de 100% em `vitest.config.ts` é aspiracional e não faz parte do gate de release (ver [docs/releasing.md](docs/releasing.md)).
-- **v1+**: drivers adicionais (Hono, Drizzle, ArkType, Vue, Inngest, Redis events), camada de entidades (`defineEntity`), Conversya migration plan.
+- **Hoje**: 22 superfícies, suíte vitest com cobertura medida por `pnpm test:cov`. O threshold de 100% em `vitest.config.ts` é aspiracional e não faz parte do gate de release (ver [docs/releasing.md](docs/releasing.md)).
+- **Próximos**: drivers adicionais (Hono, Drizzle, ArkType, Vue, Inngest, Redis events) e o plano de migração da Conversya.
 
 ## Desenvolvimento
 

package/bin/cli.mjs

@@ -426,6 +426,10 @@ Regras da UI (@softize/opus/ui):
   unpaired-ui-surface     — superfície sem o foreground do par (bg-card sem
                             text-card-foreground, bg-popover sem text-popover-foreground)
 
+Regras dos Produtos de Dados (defineDataProduct):
+  data-product-*          — declaração exportada, id e versão válidos, sem duplicata,
+                            interfaces e entidades que existem no domínio
+
 Exit ≠ 0 se houver violação. Sem nenhuma action: projeto marcado (opus.json) passa
 vacuamente; sem marcador, falha — gate vazio não é aprovação. Default dir: cwd.
 `)

package/docs/adr/0004-page-content-state-is-composed.md

@@ -1,5 +1,8 @@
 # ADR 0004 — O estado integral do conteúdo é composto dentro de Page
 
+- **Status:** aceita, com adendo.
+- **Data:** 2026-09-04.
+
 > **Atualização (2026-09-09).** A decisão original preservava o cabeçalho da página em todos os
 > estados. Ela foi invertida: `PageState` passa a ocultá-lo em `loading`, `error` e `empty`, e a
 > restaurá-lo em `ready`. A lista de responsabilidades abaixo já descreve o comportamento novo; o

package/docs/adr/0005-structural-surfaces-share-an-explicit-anatomy.md

@@ -5,10 +5,14 @@
 
 > **Atualização (2026-09-09).** Parcialmente substituída pela ADR 0009 quanto a `PageMeta` e ao
 > `count` de `Page`, e complementada pela ADR 0010, que acrescenta as apresentações `default` e
-> `bar` ao mesmo header. O corpo abaixo já traz a anatomia vigente.
+> `bar` ao mesmo header.
 >
-> **Atualização (2026-09-11).** As ADRs 0012 e 0014 removem Description dos headers de Page,
+> **Atualização (2026-09-11).** As ADRs 0018 e 0014 removem Description dos headers de Page,
 > Dialog e Drawer. Contexto relevante começa no body.
+>
+> **Atualização (2026-09-16).** O corpo abaixo descreve a anatomia da época em que foi escrito, não a
+> vigente: a apresentação `bar` da ADR 0010 saiu com a ADR 0011, e nenhum header estrutural carrega
+> mais descrição (ADRs 0018 e 0014). A anatomia atual está na documentação de cada família.
 
 ## Contexto
 

package/docs/adr/0011-page-shell-coordinates-persistent-page-chrome.md

@@ -2,11 +2,16 @@
 
 - **Status:** aceita.
 - **Data:** 2026-09-10.
-- **Revisa:** ADR 0010.
+- **Substitui:** ADR 0010.
 
 > **Atualização (2026-09-13).** A ADR 0016 separa o chrome persistente da introdução e do
 > cabeçalho de uma coleção. `PageHeader` passa a declarar navegação e ações globais para a barra;
 > `PageIntro` permanece opcional no conteúdo e `Content` nomeia coleções.
+>
+> **Atualização (2026-09-16).** Desde a 18.0.0, a composição explícita dentro do shell aceita
+> `PageHeader`, `PageIntro` e `PageFooter` como opcionais e exige exatamente um heading principal —
+> `PageTitle`, `Content level={1}` ou um `PageState` ativo. As frases abaixo que pedem `PageIntro`
+> "sem `PageHeader`" descrevem a regra da 17.2 e não valem mais.
 
 ## Contexto
 

package/docs/adr/0014-structural-headers-do-not-carry-description.md

@@ -2,7 +2,7 @@
 
 - **Status:** aceita.
 - **Data:** 2026-09-11.
-- **Complementa:** ADRs 0005, 0011 e 0012.
+- **Complementa:** ADRs 0005, 0011 e 0018.
 
 ## Contexto
 
@@ -13,7 +13,7 @@ superfície e misturava o nome do recurso com instruções e consequências da t
 ## Decisão
 
 Headers estruturais contêm navegação opcional, título e actions. Page não oferece a propriedade
-`description` nem `PageDescription`; Dialog e Drawer seguem a mesma regra conforme a ADR 0012.
+`description` nem `PageDescription`; Dialog e Drawer seguem a mesma regra conforme a ADR 0018.
 
 Contexto que altera compreensão ou decisão aparece no início do body. Ele pode ser texto, `Alert`,
 `Content` ou outra composição adequada. `PageState`, `Alert`, `Empty`, campos, métricas e seções

package/docs/adr/0015-action-size-follows-interaction-density.md

@@ -21,10 +21,11 @@ risco.
 
 - ações textuais que decidem a superfície usam `default`: header de Page e footer de Page, Dialog
   ou Drawer;
-- ações operacionais em toolbar, header de seção ou coleção densa usam `sm`;
+- ações operacionais em toolbar, header de seção ou coleção densa usam `sm`; a criação no header
+  de uma coleção é a exceção e usa `default` (ADR 0016);
 - ações internas de linha, célula ou campo usam `xs` ou `icon-xs`;
-- ações somente com ícone que pertencem ao chrome da superfície, como voltar e fechar, usam
-  `icon`;
+- ações somente com ícone que pertencem ao chrome da superfície, como voltar, usam `icon`; desde a
+  18.1.0 o fechamento de Dialog e Drawer é o `CloseButton`, em `icon-sm` por padrão (`closeSize`);
 - `lg` fica reservado a chamadas que deliberadamente precisam de uma área de toque maior, não a
   uma ação primária comum.
 

package/docs/adr/0017-ui-assumes-a-fixed-desktop-layout.md

@@ -0,0 +1,54 @@
+# ADR 0017 — A UI assume layout desktop fixo
+
+- **Status:** aceita.
+- **Data:** 2026-09-15.
+
+## Contexto
+
+A UI acumulou adaptações isoladas por viewport em dialogs, drawers, campos, detalhes, paginação e
+grids. O shell, as sidebars e os splits continuaram desktop-only. Essa combinação não formava um
+contrato responsivo: abaixo da largura de trabalho, algumas partes mudavam de forma enquanto a
+estrutura principal permanecia fixa.
+
+## Decisão
+
+O Opus assume uma largura mínima suportada de `64rem`. Componentes usam um layout fixo equivalente
+ao estado que os breakpoints `sm`, `md` e `lg` produziam nessa largura. Estados exclusivos de
+`xl` e `2xl` não alteram mais a composição.
+
+A UI viva não usa media queries de largura, variantes responsivas do Tailwind nem container queries.
+Uma futura responsividade baseada no espaço do container exige uma decisão própria e uma aplicação
+sistêmica; não permanece ativa de forma incidental em componentes isolados.
+
+Consultas de preferência ou capacidade, como `prefers-reduced-motion`, `forced-colors` e
+`hover`, continuam válidas. Overflow, limites de altura e posicionamento contra a viewport também
+continuam protegendo conteúdo; essas medidas não prometem uma composição alternativa.
+
+Footers de formulário modal dimensionam as ações pelo conteúdo e usam `Cancelar` em `ghost`.
+`distribution="equal"` permanece uma escolha explícita para decisões de peso equivalente e,
+nesse caso, o cancelamento usa `outline`.
+
+## Consequências
+
+- O mesmo componente preserva a composição a partir de `64rem`, inclusive dentro de panes,
+  drawers e splits.
+- Abaixo da largura suportada, compressão ou rolagem não constitui regressão do contrato atual.
+- Dialogs mantêm limites fixos de largura; tabelas preservam rolagem horizontal.
+- A remoção de breakpoints não remove adaptações de acessibilidade nem contenção contra overflow.
+- Uma iniciativa responsiva futura começa pelo shell e define containers, navegação, tabelas e
+  testes de largura antes de adaptar componentes.
+
+## Alternativas descartadas
+
+- **Manter adaptações pontuais:** conserva algum conforto em telas estreitas, mas continua sugerindo
+  um suporte que o shell não oferece.
+- **Completar responsividade por viewport agora:** amplia a mudança para navegação, splits, tabelas
+  e fluxos que ainda não possuem requisitos de produto.
+- **Preservar container queries isoladas:** usa uma técnica adequada para o futuro, mas mantém hoje
+  um contrato parcial sem cobertura sistêmica.
+
+## Verificação
+
+- Um teste de inventário reprova variantes de largura e container queries na UI viva.
+- Testes estruturais fixam layouts, larguras de modal e distribuição dos footers.
+- Documentação pública declara a largura mínima, o default por conteúdo e a exceção `equal`.

package/docs/adr/{0012-modal-header-only-names-the-surface.md → 0018-modal-header-only-names-the-surface.md}

@@ -1,4 +1,7 @@
-# ADR 0012 — O cabeçalho modal apenas nomeia a superfície
+# ADR 0018 — O cabeçalho modal apenas nomeia a superfície
+
+> Publicada originalmente com o número 0012, que colidia com a ADR de Produtos de Dados do mesmo
+> dia. Renumerada em 2026-09-16; o conteúdo não mudou.
 
 - **Status:** aceita.
 - **Data:** 2026-09-11.

package/docs/adr/0019-productive-surfaces-use-compact-density.md

@@ -0,0 +1,65 @@
+# ADR 0019 — Superfícies produtivas usam densidade compacta
+
+> Publicada originalmente com o número 0016, que colidia com a ADR do cabeçalho da coleção.
+> Renumerada em 2026-09-16; o conteúdo não mudou.
+
+- **Status:** aceita.
+- **Data:** 2026-09-14.
+
+## Contexto
+
+Alert, Toast e Item compartilham uma composição horizontal de mídia, texto e ações, mas nasceram
+com medidas internas diferentes ou herdadas de dependências. Alert e Item usavam `1rem` de padding;
+o Toast preservava `1rem` e corpo de `0.8125rem` do Sonner. Consumidores já reconstruíam mensagens
+parecidas com `0.75rem`, sinal de que a densidade da família não estava definida pela biblioteca.
+
+A tipografia também repetia `text-sm` em raiz e folhas do mesmo componente. Essa repetição não
+distinguia uma fronteira tipográfica de um detalhe interno e tornava difícil saber quando uma classe
+era contrato ou apenas redundância.
+
+## Decisão
+
+O tema não redefine a tipografia de `html`, `:root` ou `body`. Componentes que constituem uma
+fronteira reutilizável declaram `text-sm`; folhas internas herdam essa medida, salvo quando
+restauram o corpo produtivo dentro de um contexto tipográfico diferente.
+
+Superfícies horizontais produtivas usam `0.75rem` de padding no tamanho padrão:
+
+- Alert usa `p-3` e mantém mídia, texto e ações na mesma anatomia;
+- Toast sobrescreve o padding e o corpo nativos do Sonner para repetir a medida do Alert;
+- Item usa `p-3` e `gap-3`; `size="sm"` conserva `0.75rem` na horizontal e reduz a vertical para
+  `0.5rem`.
+
+Mais espaço permanece deliberado quando o componente representa outra tarefa: Empty cria uma
+pausa de estado na região disponível; Dialog e Drawer estruturam faixas e corpo; Card deixa o
+padding sob responsabilidade dos seus slots ou do consumidor; conteúdo editorial usa `text-base`
+para leitura prolongada.
+
+## Consequências
+
+- Alert, Toast e Item passam a parecer membros da mesma família sem virar o mesmo componente.
+- Texto solto preserva o tamanho do documento; uma fronteira reutilizável não depende
+  acidentalmente do tamanho escolhido pelo consumidor.
+- `p-4` deixa de ser o default de mensagens e linhas, mas continua válido em contêineres
+  estruturais cujo papel exige mais respiro.
+- A integração com Sonner precisa de teste de contrato porque seus defaults deixam de governar a
+  tipografia e o padding do Toast.
+
+## Alternativas descartadas
+
+- **Reduzir a fonte raiz:** compactaria também espaços, dimensões, radius e elevação, misturando
+  densidade global com o papel do texto.
+- **Criar aliases como `text-body` ou `surface-padding`:** esconderia os mesmos degraus sem
+  esclarecer onde a decisão pertence.
+- **Remover toda ocorrência de `text-sm`:** faria componentes reutilizáveis dependerem do contexto
+  externo e impediria a restauração explícita do corpo produtivo.
+- **Aplicar `p-3` a toda superfície:** reduziria modais, estados vazios e conteúdo editorial sem
+  relação com a composição horizontal que motivou a decisão.
+
+## Verificação
+
+- testes estruturais conferem padding e herança em Alert e Item;
+- o teste da integração com Sonner fixa padding, corpo e entrelinha do Toast;
+- o contrato de unidades relativas confirma a ausência de tipografia global em `html`, `:root`
+  e `body`;
+- documentação de Alert, Toast, Item e tokens classifica os defaults e as exceções.

package/docs/code-style.md

@@ -98,8 +98,8 @@ Base instalada é dona do catálogo, dos kinds aceitos e do fundamento de cada r
 | `Select.options[].hint/triggerLabel/group`                                                                                                                                                 | `label`, `label`, `heading`                              |
 | `ActionTrigger.confirm.*`                                                                                                                                                                  | papel correspondente do diálogo                          |
 | `t.dict` — `label`, `description`, `doc` das entradas e `doc` do dicionário                                                                                                                | `label`, `description`                                   |
-| `DataState`/`PageState`/`ActionList`/`ActionListDialog` — `emptyMessage`, `errorMessage`, `retryLabel`; `PageState`/`ActionListDialog` — `title`, `description`; `ActionView.emptyMessage` | `empty-state`, `error`, `button`, `title`, `description` |
-| `dialog.alert/confirm/prompt/choose()` — `title`, `description`, `body`, `action`, `cancel`, `placeholder`, `actions[].label`                                                              | papel correspondente do diálogo                          |
+| `DataState`/`PageState`/`ActionList`/`ActionListDialog` — `emptyMessage`, `errorMessage`, `retryLabel`; `PageState` — `title`, `description`; `ActionListDialog` — `title`, `intro`; `ActionView.emptyMessage` | `empty-state`, `error`, `button`, `title`, `description` |
+| `dialog.alert/confirm/prompt/choose()` — `title`, `body`, `action`, `cancel`, `placeholder`, `actions[].label`                                                                             | papel correspondente do diálogo                          |
 | `TooltipContent` (children), `LabelHelp.help`                                                                                                                                              | `label`, `helper-text`                                   |
 
 ## Cobertura e significado do gate verde

package/docs/consumer-upgrade-propagation.md

@@ -52,6 +52,6 @@ Há três sinais diferentes e eles não devem ser confundidos:
 
 ## Verificação
 
-- o status do Maestro deve distinguir versão instalada, aplicada e adotada;
+- o status do Maestro deve distinguir versão disponível, adotada e aplicada;
 - fixtures com tokens removidos devem reprovar no detector de migração, enquanto texto de
   documentação e dependências geradas são ignorados.

package/docs/data-products.md

@@ -58,9 +58,11 @@ consumidores usam o nome qualificado; o alias só poderá ser removido numa vers
 ## Projeções
 
 `opus gen` publica os produtos no `.opus/manifest.json`. Actions expostas como tools carregam os
-IDs em `metadata.dataProducts`; no MCP, a chave é
-`_meta['com.softize.opus/data-products']`. Consumidores devem registrar apenas produtos associados
-a chamadas concluídas com sucesso.
+IDs em `metadata.dataProducts` e os rótulos legíveis em `metadata.dataProductLabels`, um mapa de ID
+para `label`. No MCP, as chaves são `_meta['com.softize.opus/data-products']` e
+`_meta['com.softize.opus/data-product-labels']`. Hosts mostram o rótulo às pessoas e usam o ID na
+execução e na auditoria. Consumidores devem registrar apenas produtos associados a chamadas
+concluídas com sucesso.
 
 O Opus Lens usa o manifest para mostrar a linhagem declarada entre Fontes, entities, produtos e
 Actions. Nenhuma dessas projeções é fonte autoritativa: corrija a declaração e gere novamente.

package/docs/protocol.md

@@ -604,7 +604,7 @@ Não vai ter `compose(authA, authB)` no core. Se sentir falta, é regra de negó
 
 O Opus **não autentica** — não valida token, não emite sessão. O adapter (server) recebe a request, valida o token via auth provider externo (Better Auth, Clerk, próprio), monta `ctx.user`, e entrega pro Opus. A partir daí, `authorize` decide.
 
-Se `ctx.user` é `null` e `public !== true`, runtime rejeita com `{ code: 'auth.unauthenticated', category: 'authentication' }` **antes** de chamar `authorize`.
+Se `ctx.user` é `null` e `public !== true`, runtime rejeita com `{ code: 'auth.unauthenticated', category: 'authentication' }` **antes** dos loaders e de `authorize`. Assim um chamador anônimo não dispara consultas nem descobre, pelo erro de um loader, se um registro existe.
 
 ---
 
@@ -1186,9 +1186,9 @@ ctx = { user, tenantId, can, db, emit, meta, ... }
    ↓
 Runtime.execute(action, input, ctx)
    ↓ (1) validate input contra schema
-   ↓ (2) load (se action declara `loads`)
-   ↓ (3) check public OR authenticate (ctx.user != null)
-   ↓ (4) authorize (chama action.authorize)
+   ↓ (2) check public OR authenticate (ctx.user != null)
+   ↓ (3) load (se action declara `loads`)
+   ↓ (4) authorize (chama action.authorize, que pode usar o que foi carregado)
    ↓ (5) handler executa
             (durante: handler pode chamar ctx.emit(event, data)
              → runtime publica via EventBusAdapter)
@@ -1426,14 +1426,14 @@ type BackgroundResult<T> =
 ```
 HTTP request → Server adapter
   ↓ (1) validate input
-  ↓ (2) load + authenticate + authorize
+  ↓ (2) authenticate + load + authorize
   ↓ (3) enqueue job via QueueAdapter + audit do enqueue
   ↓
 Server retorna JobHandle síncrono → client polla ou subscribe
   ↓
 Worker (processo separado) consome job:
   ↓ (a) reidrata auth/can e chama runtime.executeJob(spec, ctx, progress)
-  ↓ (b) revalida input + load + authenticate + authorize
+  ↓ (b) revalida input + authenticate + load + authorize
   ↓ (c) handler (recebe ProgressReporter se config.progress)
   ↓ (d) validate output + audit com provenance background
   ↓ (e) processor retorna/lança; BullMQ atualiza status done/failed

package/docs/relative-unit-scale.md

@@ -15,12 +15,17 @@ compacto deixavam de acompanhar a raiz mesmo quando a aplicação assumia essa r
 
 ## Decisão
 
-- O tema do Opus não declara `font-size` em `html` nem em `:root`. O navegador e a aplicação
-  definem a fonte raiz.
+- O tema do Opus não declara `font-size` em `html`, `:root` nem `body`. O navegador e a aplicação
+  definem a fonte raiz e o texto geral do documento.
 - Medidas que pertencem à identidade e à escala da interface usam `rem`, diretamente ou pela
   escala do Tailwind, que também é relativa à raiz.
 - Aplicações ajustam a densidade no próprio CSS. Para conservar a proporção que antes resultava
   de uma raiz de 15 sobre a base usual de 16, podem usar `html { font-size: 93.75%; }`.
+- Ajustar a raiz é uma decisão de escala da interface inteira, não uma forma de renomear papéis
+  tipográficos. Na escala produtiva recomendada, `text-sm` (`0.875rem`) é o corpo comum da
+  interface e deve ser declarado na raiz controlada do componente ou da região. `text-base`
+  (`1rem`) fica reservado à leitura mais confortável; a documentação de tokens apresenta a regra
+  de composição e herança.
 - `px` fica restrito a encaixes técnicos que não devem crescer com a tipografia: espessura de
   hairline, compensação exata de uma borda, ajuste óptico preso a esse traço e o raio efetivamente
   infinito do scrollbar nativo. Cada ocorrência integra a allowlist do teste de contrato.
@@ -31,6 +36,8 @@ compacto deixavam de acompanhar a raiz mesmo quando a aplicação assumia essa r
 
 - Sem uma regra da aplicação, `1rem` segue a configuração do navegador. A UI pode ficar maior
   para consumidores que recebiam os antigos 15px; essa mudança é visual e intencional.
+- Texto solto, fora de uma raiz que declare seu papel tipográfico, permanece no tamanho geral do
+  documento; componentes produtivos não dependem de uma redução global para chegar a `0.875rem`.
 - Preferências de acessibilidade e identidades próprias deixam de disputar com um override da
   biblioteca.
 - Alterar a raiz na aplicação escala texto, espaçamento, radius, foco, elevação e limites

package/docs/releasing.md

@@ -13,6 +13,13 @@ configuração de escopo ou token de leitura.
 
 ## Release pela estação (o caminho normal)
 
+Antes de rodar, escreva no `CHANGELOG.md` a entrada `## X.Y.Z` da versão que vai sair. O script
+confere essa entrada só DEPOIS do bump, então esquecê-la aborta a release com o `package.json` já
+alterado — e a tentativa seguinte para na guarda de árvore limpa. Para recuperar, desfaça o bump
+(`git checkout -- package.json`), escreva a entrada, commite e rode de novo.
+
+Os comandos rodam em `packages/opus`; o `package.json` da raiz não tem `release`.
+
 ```bash
 pnpm release            # patch bump + publica no npm público
 pnpm release minor      # minor
@@ -53,7 +60,7 @@ pra testar publicação seria a guarda atrapalhando quem está experimentando.
 
 **Gate de qualidade**: depois do bump e da materialização, mas antes de publicar, roda
 `pnpm typecheck` + `pnpm test` + `pnpm copy:check` + `base copy check` e **aborta a release
-se qualquer um falhar**. O Opus declara `@softize/base ^2.2.1` em `dependencies`, pois usa
+se qualquer um falhar**. O Opus declara `@softize/base ^2.3.0` em `dependencies`, pois usa
 suas APIs públicas de filesystem em runtime, e materializa os artefatos Base no próprio repo;
 a release não baixa uma política ad hoc. Como o
 Opus **ship source** (`.ts`, sem build), essa é a última barreira antes do tarball — sem ela,
@@ -67,7 +74,7 @@ não é bloqueada por cobertura abaixo de 100%; a cobertura é acompanhada com `
 **Smoke do esqueleto**: depois do bump e antes do publish, o `release.sh` gera um app com
 `opus create`, instala o **tarball exato** que vai ser publicado e roda os gates dele
 (typecheck · test · `opus check` · `opus copy --check` · `base copy check` · manifest ·
-build). O template exige `@softize/base ^2.2.1`; publique a Base compatível antes do Opus.
+build). O template exige `@softize/base ^2.3.0`; publique a Base compatível antes do Opus.
 O `minimumReleaseAgeExclude` do template inclui os dois pacotes, e o smoke executa os
 fragmentos de pre-push para provar que o layout pnpm instalado resolve ambos os CLIs.
 É o que pega o que typecheck+test não
@@ -80,7 +87,24 @@ O script bumpa, publica **e leva o bump pra `origin/main`** — não sobra passo
 `--local` ele não commita nada (Verdaccio é sandbox). `pnpm release none` não cria diff de
 versão, mas ainda commita qualquer derivado que a materialização legitimamente atualizar.
 `--dry-run` encerra depois das mesmas materializações/gates/smoke, sem publish, commit ou
-push; use `none` para validar a versão atual sem sujar o manifesto.
+push; use `none` para validar a versão atual sem sujar o manifesto. Sem `--local`, o
+`--dry-run` também exige a `main` limpa e igual a `origin/main`.
+
+## A documentação é publicada à parte
+
+A release publica o pacote, não o site. `opus.softize.com.br` só muda quando alguém roda, na raiz
+do repositório:
+
+```bash
+pnpm deploy:docs
+```
+
+O script aplica as mesmas guardas de procedência da release, roda `typecheck`, `test`,
+`copy:check` e o `opus check` de `apps/opus`, builda o site e envia o resultado. Ele não roda o
+`base copy check` nem o smoke do esqueleto, que ficam com a release. Rode-o depois de cada
+release; sem isso, o site continua mostrando a versão anterior.
+Em setembro de 2026, o site ficou onze dias preso numa versão anterior à 13.0.0 enquanto o
+pacote chegava à 18.1.0. `pnpm deploy:docs --dry-run` valida sem enviar.
 
 ## Verificar
 
@@ -111,7 +135,7 @@ pnpm add @softize/opus@8.7.0-rc.0 --registry http://127.0.0.1:6873/
 
 Valide o app normalmente. Ao encerrar a sessão, restaure o intervalo de versão do
 consumidor para o npm e rode `pnpm install`; a prerelease local nunca é enviada ao npm.
-Para publicar outra tentativa, incremente o sucesso (`8.6.0-rc.1`, por exemplo) e repita
+Para publicar outra tentativa, incremente o sufixo (`8.7.0-rc.1`, por exemplo) e repita
 o mesmo fluxo.
 
 ## Auth

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@softize/opus",
-  "version": "18.0.1",
+  "version": "18.1.1",
   "description": "End-to-end action protocol for TypeScript. Single package with subpath exports (core + adapters).",
   "license": "MIT",
   "type": "module",

package/registry/skills/build-opus-ui/references/evaluations.md

@@ -12,7 +12,9 @@
   `ActionFilterBar` separado do renderer, `ItemGroup` para
   uma coleção secundária e um `ActionFormDialog`; provar teto padrão de `80rem`, hierarquia por
   `level`, vazio estrutural sólido, `Empty` apenas para criação ou vínculo, números sem alinhamento
-  inferido e cancelamento `outline` no footer 50/50 do modal.
+  inferido e footer modal com largura natural, alinhado à direita e cancelamento `ghost`; incluir
+  separadamente um caso deliberadamente equivalente com distribuição 50/50 e cancelamento
+  `outline` explícitos.
 - Execução roteável: declarar Page, criação e edição com `Presentation.route`; provar deep link,
   hidratação do registro, fechamento para a lista e projeção integral no manifest.
 - Execução abreviada: montar outra página com `<Page title actions>` e uma seção com