@softize/opus 21.0.1 → 22.0.0

package/docs/adr/0030-framed-content-can-use-sectioned-anatomy.md

@@ -0,0 +1,89 @@
+# ADR 0030 — Content com moldura pode usar anatomia seccionada
+
+- **Status:** aceita.
+- **Data:** 2026-09-28.
+- **Substitui parcialmente:** ADR 0023, nas afirmações de que `Content` não expõe `layout` e é
+  sempre contínuo.
+- **Complementa:** ADR 0025.
+
+## Contexto
+
+`Content` já representa uma região nomeada como `section` ou `fieldset`, com header, body e moldura
+opcional. Quando o body é uma estrutura que possui o próprio recuo — como `DetailGroup` com
+divisores, uma lista ou uma tabela — o acabamento contínuo acrescenta padding ao redor dessa
+estrutura e impede que suas linhas alcancem a moldura.
+
+O protótipo do detalhe de Veículo no Evento de Pós-vendas confirmou uma composição útil: header com
+mídia, título, recuo de `0.75rem` e divisor; body sem recuo; conteúdo interno responsável por suas
+células. Produzir esse desenho exigiu classes no consumidor para remover o padding da raiz, recortar
+os cantos e reconstruir o header.
+
+As forças em tensão são:
+
+- reutilizar o vocabulário `continuous | sectioned` de Card, Dialog, Drawer e Pane;
+- preservar `Content` como região semântica interna, sem transformá-lo em Card;
+- manter `frameVariant="legend"` como acabamento da borda, sem misturá-lo à anatomia;
+- impedir combinações em que o body encosta nas bordas sem existir uma moldura para recortá-lo.
+
+## Decisão
+
+`Content` passa a aceitar `layout="continuous" | "sectioned"`, com `continuous` como default.
+
+O layout `sectioned` exige `framed` e forma um pacote indivisível:
+
+- A raiz desenha a moldura, recorta os cantos e não aplica padding geral.
+- `ContentHeader` aplica `p-3` e o divisor inferior.
+- `ContentBody` não aplica padding; seu filho direto responde pelo recuo interno.
+- Shorthand e composição explícita produzem a mesma anatomia.
+- `ContentMedia`, título, descrição, contador e ações preservam seus contratos atuais.
+
+`frameVariant` continua escolhendo somente o acabamento da moldura contínua. A combinação
+`layout="sectioned"` com `frameVariant="legend"` é inválida: o primeiro coloca o header dentro da
+moldura, enquanto o segundo o integra ao traço externo.
+
+O layout não altera a semântica. `as="section"` continua emitindo section com heading e
+`as="fieldset"` continua emitindo fieldset com legend nativa.
+
+### Emenda de 2026-09-28 — a moldura usa o raio das superfícies estruturais
+
+Quando `framed` está ativo, `Content` desenha uma moldura estrutural completa e usa `rounded-xl`,
+o mesmo degrau de `Card`. A semântica das duas famílias continua diferente, mas essa diferença não
+produz uma geometria externa menor. Em composições aninhadas, evitar a moldura dupla em vez de
+reduzir globalmente o raio de `Content`.
+
+## Consequências
+
+- DetailGroup, listas e tabelas podem ocupar o body de ponta a ponta sem classes estruturais no
+  consumidor.
+- Conteúdo livre que precisa de recuo continua usando o layout `continuous`, ou declara sua própria
+  região interna quando o body de ponta a ponta for deliberado.
+- `Content` passa a compartilhar o vocabulário de anatomia das demais superfícies, mas continua sem
+  footer e sem assumir o papel de uma superfície autônoma.
+- A API rejeita `sectioned` sem `framed` e rejeita a combinação com `legend`.
+
+## Alternativas consideradas
+
+### Adicionar `frameVariant="sectioned"`
+
+Foi descartado porque misturaria anatomia de regiões com o acabamento da linha externa. Card,
+Dialog, Drawer e Pane já usam `layout` para essa decisão.
+
+### Criar propriedades de borda e padding
+
+Propriedades como `headerDivider` e `bodyInset` permitiriam combinações arbitrárias e devolveriam a
+anatomia ao consumidor. O resultado validado é um pacote, não dois controles independentes.
+
+### Criar DetailCard
+
+Foi descartado porque duplicaria a semântica e os slots de `Content` para um único tipo de filho.
+A anatomia também é válida para listas e tabelas.
+
+## Verificação
+
+- Testes de UI cobrem shorthand, composição explícita, section e fieldset.
+- Testes confirmam header com divisor e `p-3`, body sem padding e raiz com recorte.
+- Testes confirmam `rounded-xl` nas molduras `default`, `legend` e `sectioned`.
+- Testes reprovam `sectioned` sem moldura e a combinação com `frameVariant="legend"`.
+- A documentação demonstra o caso com `DetailGroup` e diferencia anatomia de acabamento.
+- O consumidor de Pós-vendas usa somente props públicas do Opus, sem classes que reconstruam a
+  anatomia.

package/docs/adr/0031-detail-dividers-own-the-tabular-label-treatment.md

@@ -0,0 +1,61 @@
+# ADR 0031 — Divisórias de DetailGroup definem o tratamento tabular dos rótulos
+
+- **Status:** aceita.
+- **Data:** 2026-09-28.
+
+## Contexto
+
+`DetailGroup` separa três decisões: orientação dos pares, divisórias internas e moldura externa.
+Apesar disso, o fundo sutil dos rótulos horizontais era ativado por `variant="framed"`. Assim, a
+mesma grade com divisórias mudava de aparência ao ser hospedada por um `Content` seccionado, onde a
+moldura pertence ao `Content`, e um grupo independente, onde a moldura pertence ao próprio
+`DetailGroup`.
+
+O fundo do rótulo é um acabamento da grade tabular: ele ajuda a distinguir chave e valor quando os
+campos formam células conectadas. Não comunica que o grupo possui uma borda externa.
+
+## Decisão
+
+Na orientação horizontal, `dividers` ativa a composição tabular completa de cada campo:
+
+- rótulo e valor recebem padding próprio;
+- a coluna de rótulos usa fundo sutil;
+- a largura padrão dos rótulos passa a `8.5rem`;
+- as divisórias continuam delimitando as células.
+
+`variant="framed"` controla somente a moldura externa do grupo. Sem `dividers`, um grupo horizontal
+emoldurado mantém rótulo e valor sobre o mesmo fundo. Na orientação vertical, `dividers` continua
+adicionando somente as separações entre campos, sem pintar o rótulo.
+
+## Consequências
+
+- Grades horizontais com divisórias têm a mesma aparência dentro de `Content layout="sectioned"`
+  e como bloco principal independente.
+- Moldura externa, orientação e acabamento tabular permanecem decisões combináveis.
+- Não é necessária uma nova prop apenas para reproduzir um enfeite que já acompanha a grade.
+- Consumidores que usavam `framed + horizontal` sem divisórias deixam de receber fundo no rótulo.
+
+## Alternativas consideradas
+
+### Manter o fundo associado a `framed`
+
+Preservaria o comportamento atual, mas continuaria fazendo a moldura externa alterar o interior da
+grade e manteria inconsistentes os grupos hospedados por outra superfície.
+
+### Criar `labelVariant="muted"`
+
+Tornaria o acabamento explícito, mas adicionaria uma decisão a todos os consumidores sem haver um
+caso de produto que precise variar o fundo independentemente das divisórias.
+
+### Aplicar o fundo a toda orientação horizontal
+
+Uniformizaria os rótulos, mas daria aparência tabular também a grupos simples, sem células ou
+divisórias que sustentem essa leitura.
+
+## Verificação
+
+- Testes de UI confirmam fundo e padding separados em `horizontal + dividers`, com e sem moldura.
+- Testes de UI confirmam ausência de fundo em `horizontal + framed` sem divisórias.
+- Testes de UI confirmam que divisórias verticais não pintam o rótulo.
+- A documentação de `DetailGroup` descreve `framed`, `dividers` e `orientation` como eixos
+  independentes.

package/docs/adr/0032-tab-baseline-respects-the-container-inset.md

@@ -0,0 +1,59 @@
+# ADR 0032 — A linha-base das abas respeita o recuo do contêiner
+
+- **Status:** aceita.
+- **Data:** 2026-09-28.
+- **Relacionada:** ADR 0023, quanto ao alinhamento horizontal dentro de superfícies.
+
+## Contexto
+
+A variante horizontal `line` de `TabsList` estendia a linha-base para fora da própria lista usando
+o recuo de `DrawerBody` e `DialogBody`. Os rótulos permaneciam alinhados ao conteúdo, mas a linha
+alcançava as laterais da superfície e rompia o contorno visual formado pelo corpo.
+
+A tela de detalhes do Evento tornou a divergência evidente: cards, detalhes e conteúdo respeitam o
+mesmo recuo lateral, enquanto apenas a navegação por abas terminava nas bordas do drawer.
+
+## Decisão
+
+A linha-base horizontal ocupa somente a largura de `TabsList`. Ela respeita o recuo aplicado pelo
+contêiner e acompanha o alinhamento do corpo em qualquer superfície.
+
+`DrawerBody` e `DialogBody` deixam de publicar uma variável de gutter exclusiva para Tabs. O recuo
+continua pertencendo à anatomia da superfície, e Tabs apenas ocupa a largura que recebe no fluxo.
+
+### Emenda de 2026-09-28 — a aba combina uma área de botão e o indicador
+
+Na variante horizontal `line`, o gatilho mantém duas camadas: uma área interna com os estados
+interativos e a mesma altura de um Button do tamanho correspondente, e o indicador ancorado na
+linha-base da lista. A área interna permanece transparente e recebe fundo apenas no hover; a aba
+ativa se distingue pelo indicador primário. Um respiro de `0.375rem` separa as duas camadas no uso
+comum; dentro de `Tabs framed`, ele aumenta para `0.5rem` e acompanha o padding superior da moldura.
+
+Essa apresentação pertence ao Opus: consumidores escolhem `variant="line"` e não repetem classes
+de fundo, raio, padding ou interação para obter o estado selecionado.
+
+## Consequências
+
+- A linha e os rótulos das abas compartilham os limites horizontais do corpo.
+- A seleção permanece indicada pela linha inferior, sem manter um segundo fundo persistente.
+- Drawer e Dialog não mantêm uma integração implícita com Tabs.
+- Um consumidor que realmente precise de uma linha até as bordas deve compor essa apresentação de
+  forma explícita, pois ela não é mais o comportamento padrão da variante `line`.
+
+## Alternativas descartadas
+
+### Manter a linha até as bordas
+
+Preservaria o comportamento anterior, mas manteria uma exceção visual exclusiva das abas e uma
+dependência oculta entre as primitivas de corpo e Tabs.
+
+### Adicionar uma propriedade de full bleed
+
+Permitiria escolher os dois comportamentos, mas aumentaria a API para preservar uma apresentação
+sem consumidor conhecido. A composição explícita é suficiente caso essa necessidade apareça.
+
+## Verificação
+
+O teste da variante `line` verifica que a linha usa `inset-inline: 0`, inclusive quando Tabs está
+dentro de `DrawerBody`. O mesmo teste verifica a separação estrutural entre a superfície interna e
+o indicador da aba ativa. A documentação viva demonstra a variante com os limites do contêiner.

package/docs/adr/0033-drawer-uses-an-inset-structural-frame.md

@@ -0,0 +1,72 @@
+# ADR 0033 — Drawer usa uma moldura estrutural recuada
+
+- **Status:** aceita.
+- **Data:** 2026-09-28.
+- **Substitui:** a decisão da ADR 0005 que prendia a moldura externa do Drawer à borda da viewport.
+
+## Contexto
+
+O `Drawer` ocupava toda a altura ou largura da viewport e desenhava somente a borda voltada para o
+conteúdo. No consumidor, o shell principal já delimita as superfícies de trabalho com recuo de
+`0.5rem`, borda completa, fundo base e raio `xl`. Ao abrir um Drawer sobre esse shell, o painel
+voltava à geometria antiga de uma lâmina presa à janela: perdia os cantos, encostava em três bordas
+e não parecia pertencer ao mesmo sistema de molduras.
+
+O painel continua precisando comunicar de qual lado entra, preservar sua animação e aproveitar a
+altura disponível. Ao mesmo tempo, a moldura não pode ser reconstruída por cada consumidor, porque
+posição, recorte e animação pertencem à primitive.
+
+## Decisão
+
+`DrawerContent` passa a ser uma superfície recuada da viewport em todos os lados:
+
+- usa `0.25rem` de distância das bordas aplicáveis;
+- usa borda completa, fundo base, `rounded-xl` e `overflow-hidden`;
+- calcula a dimensão que antes ocupava `100%` descontando o recuo dos dois lados;
+- mantém `side` responsável pela direção, dimensão principal e animação de entrada e saída;
+- mantém largura e altura extensíveis por `className`, como antes.
+
+O princípio durável é que uma superfície modal lateral possui moldura própria e não se confunde
+com a viewport. O valor do recuo e o degrau de raio continuam materializações substituíveis da
+escala visual vigente.
+
+## Consequências
+
+- Drawer e shell passam a compartilhar a mesma leitura de moldura estrutural.
+- Header, body e footer full-bleed são recortados pelos cantos do painel.
+- A área útil do Drawer perde `0.5rem` no eixo que antes preenchia a viewport.
+- Consumidores deixam de precisar adicionar borda, raio ou margem para obter essa composição.
+- A mudança visual alcança `top`, `right`, `bottom` e `left`, evitando quatro geometrias distintas
+  para a mesma primitive.
+
+## Alternativas descartadas
+
+### Manter o Drawer preso à viewport
+
+Preservaria a geometria histórica, mas manteria a divergência mais visível justamente quando o
+painel aparece sobre um shell emoldurado.
+
+### Ajustar somente o Drawer do consumidor
+
+Validaria a tela atual com menor alcance, mas espalharia posição e recorte por `className` e
+deixaria outros Drawers fora do mesmo contrato visual.
+
+### Arredondar apenas os cantos expostos
+
+Manteria o painel preso à borda de entrada, mas produziria uma moldura incompleta e continuaria sem
+o respiro que distingue a superfície da viewport.
+
+### Alterar somente o lado direito
+
+Resolveria o caso mais frequente, mas faria `side` trocar também o contrato visual da superfície,
+sem uma razão de produto para essa diferença.
+
+## Verificação
+
+- Testes de `DrawerContent` verificam borda completa, raio, recorte e recuo para os quatro valores
+  de `side`.
+- Os testes existentes continuam cobrindo anatomia interna, fechamento e animação.
+- A documentação do Drawer descreve a moldura recuada e continua demonstrando a extensão de
+  largura por `className`.
+- Um teste do consumidor confirma que o Drawer de Evento usa o default do Opus, sem reconstruir a
+  moldura localmente.

package/docs/adr/0034-tabs-can-own-a-frame-without-owning-a-surface.md

@@ -0,0 +1,60 @@
+# ADR 0034 — Tabs pode ter moldura sem criar uma superfície
+
+- **Status:** aceita.
+- **Data:** 2026-09-28.
+- **Relacionadas:** ADR 0023, quanto à anatomia das superfícies; ADR 0032, quanto à linha-base das abas.
+
+## Contexto
+
+Uma composição em que a navegação por abas e seus painéis formam um único bloco precisa de borda,
+raio e recorte compartilhados. Até aqui, consumidores obtinham essa forma envolvendo `Tabs` em um
+`Card`.
+
+O `Card`, porém, não é apenas uma moldura: ele aplica `bg-card text-card-foreground` e cria uma
+superfície semântica própria. Em um `Drawer`, essa superfície pode se distinguir do
+`bg-background`, especialmente no tema escuro, embora a intenção seja somente delimitar as abas
+dentro da superfície já existente.
+
+## Decisão
+
+`Tabs` aceita a propriedade booleana `framed`, desativada por padrão.
+
+Quando ativa, `framed` aplica ao root a moldura estrutural canônica para esse bloco: borda, raio
+`rounded-xl` e recorte do conteúdo. Ela não aplica token de fundo nem de foreground. O conjunto
+herda a superfície do contêiner em que foi composto.
+
+Essa propriedade não altera a apresentação de `TabsList`, a seleção, o tamanho nem a orientação. O
+consumidor continua escolhendo esses comportamentos nas APIs existentes, inclusive
+`TabsList variant="line"`.
+
+## Consequências
+
+- Abas podem formar um bloco único sem serem promovidas a `Card`.
+- Em Drawer, Dialog ou Pane, a moldura acompanha o fundo da superfície externa nos temas claro e
+  escuro.
+- `Card` continua correto quando as abas realmente precisarem de uma superfície semântica própria.
+- `framed` permanece independente de `TabsList variant`, que descreve apenas a apresentação da
+  lista.
+
+## Alternativas descartadas
+
+### Manter Card como wrapper obrigatório
+
+Preservaria a API atual, mas continuaria acoplando uma necessidade estrutural ao token de superfície
+do Card.
+
+### Aplicar classes no consumidor
+
+Resolveria uma tela, mas repetiria borda, raio e clipping sem registrar o contrato visual da
+composição.
+
+### Fazer toda Tabs ser emoldurada
+
+Removeria a escolha, mas quebraria usos em que Tabs participa do fluxo de uma página ou toolbar sem
+formar um bloco autônomo.
+
+## Verificação
+
+Testes da primitiva verificam que o padrão permanece sem moldura e que `framed` aplica borda, raio e
+recorte sem qualquer classe de fundo. O teste da view de Evento verifica que a composição usa o
+root emoldurado diretamente, sem um `Card` intermediário.

package/docs/adr/0035-button-group-separates-frame-relationship-and-distribution.md

@@ -0,0 +1,63 @@
+# ADR 0035 — ButtonGroup separa moldura, relação e distribuição
+
+- **Status:** aceita.
+- **Data:** 2026-09-28.
+- **Relacionadas:** ADR 0015, quanto à escala dos controles; ADR 0017, quanto à distribuição igual explícita.
+
+## Contexto
+
+Um conjunto de ações do Evento foi composto com `Card`, `ButtonGroup mode="spaced"`, separadores
+manuais e `flex-1` repetido em cada botão. O resultado visual é um único grupo emoldurado, com
+ações de mesma largura e divisores entre elas, mas o consumidor precisa reconstruir essas três
+decisões em componentes e classes diferentes.
+
+`ButtonGroup` já distingue a relação entre controles com `mode` e a ocupação da largura com
+`distribution`. Tratar os divisores como uma propriedade booleana criaria combinações sem sentido,
+como controles conectados e divididos ao mesmo tempo. Usar `Card` apenas como borda também cria uma
+superfície semântica e um fundo que não pertencem ao grupo de ações.
+
+## Decisão
+
+`ButtonGroup` passa a aceitar:
+
+- `framed`, booleano independente que aplica borda, raio estrutural e padding sem definir fundo;
+- `mode="divided"`, além de `connected` e `spaced`, para preservar a forma individual dos
+  controles e inserir automaticamente um divisor com respiro entre filhos adjacentes;
+- `distribution="equal"`, já existente, para dividir o espaço disponível somente entre os
+  controles, sem incluir os divisores no cálculo.
+
+O modo `divided` deriva a orientação dos separadores da orientação do grupo. Em grupos horizontais,
+os divisores são verticais; em grupos verticais, são horizontais. `ButtonGroupSeparator` continua
+público para composições conectadas ou divisões seletivas.
+
+## Consequências
+
+- Consumidores expressam o conjunto em uma única raiz: `<ButtonGroup framed mode="divided"
+distribution="equal">`.
+- A moldura herda a superfície externa e não substitui `Card` quando uma superfície semântica for
+  realmente necessária.
+- Os botões não repetem classes de largura, e separadores uniformes não são montados manualmente.
+- `mode` continua sendo o único eixo que descreve a relação visual entre controles.
+
+## Alternativas descartadas
+
+### Manter Card e separadores explícitos
+
+Preservaria a API, mas manteria no consumidor uma composição repetitiva que representa uma única
+decisão visual.
+
+### Adicionar `dividers` como booleano
+
+Permitiria ativar os traços, mas faria dois mecanismos independentes disputarem a relação entre os
+controles e aceitaria combinações contraditórias.
+
+### Criar uma variante visual única
+
+Uma variante como `variant="framed-divided-equal"` reduziria a chamada, mas acoplaria três eixos
+que têm usos independentes e impediria novas combinações legítimas.
+
+## Verificação
+
+Testes da primitiva verificam moldura sem fundo, divisores automáticos nas duas orientações e
+distribuição igual restrita aos controles. O teste da view de Evento verifica que o grupo usa a API
+canônica sem `Card`, `ButtonGroupSeparator` ou classes de distribuição nos filhos.

package/docs/adr/0036-tabs-declares-trigger-distribution.md

@@ -0,0 +1,58 @@
+# ADR 0036 — Tabs declara a distribuição dos gatilhos
+
+- **Status:** aceita.
+- **Data:** 2026-09-28.
+- **Relacionadas:** ADR 0032, quanto à composição da variante `line`; ADR 0034, quanto à moldura de Tabs; ADR 0035, quanto ao eixo de distribuição em grupos de controles.
+
+## Contexto
+
+Uma lista de abas pode abraçar a largura dos rótulos ou repartir a largura disponível igualmente
+entre os gatilhos. A view de Evento usa quatro abas no cabeçalho de um bloco emoldurado; larguras
+derivadas do texto deixam esse cabeçalho visualmente desequilibrado, embora todas as seções tenham o
+mesmo nível.
+
+Hoje, a variante horizontal `line` força cada gatilho a usar a largura do próprio conteúdo. Um
+consumidor que precise de larguras iguais teria de sobrescrever o `flex` interno ou reconstruir a
+lista com grid, duplicando uma decisão que já existe em `ButtonGroup` como
+`distribution="content" | "equal"`.
+
+## Decisão
+
+`Tabs` aceita `distribution="content" | "equal"`, com `content` como padrão. A propriedade fica no
+root porque descreve o conjunto de abas e, como `size` e `orientation`, flui por contexto até a
+lista e os gatilhos.
+
+Na orientação horizontal, `equal` faz a lista ocupar a largura disponível e atribui a cada gatilho
+a mesma fração flexível, com largura mínima zero. A área interativa interna ocupa toda essa fração,
+incluindo o fundo de hover. `content` preserva o comportamento atual. A distribuição não altera a
+largura nem o layout dos painéis de conteúdo.
+
+## Consequências
+
+- Consumidores escolhem a mesma linguagem de distribuição usada por `ButtonGroup`.
+- `TabsList variant="line"` continua responsável pela linha e pelos estados visuais; não recebe
+  classes de layout no consumidor.
+- A view de Evento declara `distribution="equal"` no `Tabs` sem alterar cada `TabsTrigger`.
+- Usos existentes preservam a distribuição pelo conteúdo.
+
+## Alternativas descartadas
+
+### Declarar a propriedade em TabsList
+
+É a parte que organiza os gatilhos, mas faria a distribuição escapar do mesmo contrato de conjunto
+em que `Tabs` já declara tamanho e orientação.
+
+### Usar grid e número de colunas no consumidor
+
+Exigiria conhecer a quantidade de abas e repetiria classes de layout em cada tela.
+
+### Tornar larguras iguais o padrão
+
+Atenderia a view de Evento, mas esticaria navegações curtas e barras que deliberadamente abraçam os
+rótulos.
+
+## Verificação
+
+Testes da primitiva verificam o default `content`, a largura total da lista e a fração igual dos
+gatilhos quando `equal` está ativo. O teste da view de Evento verifica a propriedade no root e a
+distribuição dos quatro gatilhos sem classes locais equivalentes.

package/docs/radius-scale.md

@@ -2,6 +2,9 @@
 
 > **Status: decidido (ago/2026).** A forma usa uma escala contínua do Tailwind; o nome do
 > componente não cria um segundo conjunto de tokens.
+>
+> **Atualização (2026-09-28).** A ADR 0033 conclui a validação que este documento deixou pendente e
+> aplica `rounded-xl` ao Drawer junto da sua nova moldura recuada.
 
 ## Contexto
 
@@ -42,8 +45,8 @@ voltaria a acoplar forma e tipo de componente, problema removido na versão 10.0
   `--radius` alcançar também os extremos usados pelo Opus. `rounded-3xl` continua nativo do
   Tailwind; aplicações que usam esse degrau precisam revisar a fronteira ao alterar a base.
 - Novos componentes podem escolher uma utility da escala sem inventar vocabulário próprio.
-- Drawer e outras superfícies presas à viewport não mudam neste entregável. Arredondar somente os
-  cantos expostos exige validar clipping, scroll e conteúdo full-bleed em uma mudança própria.
+- Naquele entregável, Drawer e outras superfícies presas à viewport não mudaram. A ADR 0033 fez a
+  validação própria de clipping, scroll e conteúdo full-bleed e passou o Drawer para `rounded-xl`.
 
 ## Alternativas descartadas
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@softize/opus",
-  "version": "21.0.1",
+  "version": "22.0.0",
   "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/SKILL.md

@@ -43,18 +43,21 @@ existentes, mantendo navegação observável e componentes reutilizáveis sem la
 7. Tratar página, filtro, seleção e modal importante como estado navegável por URL quando
    o produto precisa de deep link, back/forward ou refresh. Em `Presentation`, declarar `route`
    no artefato e deixar o adaptador apenas conectar a spec ao router da aplicação.
-8. Compor superfícies pela gramática estrutural do catálogo: `PageHeader` declara o chrome,
-   `PageIntro` a introdução opcional e `PageBody` o conteúdo. Na composição explícita, declare
-   exatamente um heading principal com `PageTitle` no header/intro, `Content level={1}` ou um
-   `PageState` ativo no body;
-   dentro de `PageShell`, os slots de
-   `PageHeader` são projetados na barra. `Content` contém `ContentHeader` e `ContentBody`; Card,
+8. Compor superfícies pela gramática estrutural do catálogo: `PageHeader` é a única introdução
+   estrutural e reúne navegação contextual opcional, título e ações; `PageBody` contém o conteúdo.
+   Na composição explícita, declare exatamente um heading principal com `PageTitle` no header,
+   `Content level={1}` ou um `PageState` ativo no body. `PageShell` pode fornecer navegação e ações
+   conhecidas pela aplicação, mas não cria uma barra visual. `Content` contém `ContentHeader` e `ContentBody`; Card,
    Drawer e Pane usam seus
    respectivos `*Body`. Para o caso direto, usar a sintaxe abreviada de `Page` (`title`,
    `actions`) ou de `Content` (`title`, `description`, `actions` e `count`); não misturá-la com o
    header explícito. O título da página não carrega contador. Ajustar o
    nível do heading pela hierarquia semântica, não pelo destaque visual. O `Page` mantém seu teto
    centralizado padrão de `80rem`.
+   Em `Content framed`, usar `layout="sectioned"` quando o filho direto já controlar o recuo do
+   body, como `DetailGroup` com divisores, lista ou tabela; não reconstruir divisor, padding ou
+   recorte por classes no consumidor. `frameVariant="legend"` continua sendo um acabamento da
+   borda contínua e não combina com o layout seccionado.
 9. Manter margem e posicionamento no consumidor; componente reutilizável controla apenas
    seu interior.
 10. Não definir a fonte raiz em uma biblioteca ou componente. O navegador e a aplicação são

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

@@ -4,8 +4,8 @@
 - Não dispara: “Ajuste o CSS de um e-mail estático.”
 - Execução: implementar uma lista com modal roteável e provar loading, erro, vazio e back.
 - Execução estrutural: montar uma página de relatório isolada com `Page > PageHeader + PageBody`,
-  outra em `PageShell` com `Page > PageHeader? + PageIntro? + PageBody`, garantindo exatamente um
-  `PageTitle` entre header/intro, e uma coleção nomeada com
+  outra em `PageShell` com navegação contextual acima de `Page > PageHeader + PageBody`, garantindo
+  exatamente um `PageTitle` no header, e uma coleção nomeada com
   `Content > ContentHeader + ContentBody > ActionList`. Provar que criação fica em
   `ContentActions`, no extremo oposto ao título, como botão textual `default` sem ícone e com
   `Criar recurso`, enquanto uma operação dependente do recorte usa `toolbarActions`; incluir
@@ -22,6 +22,9 @@
   rejeita a mistura entre props abreviadas e headers explícitos.
 - Execução de forma: compor uma tabela dentro de Card sem moldura duplicada, manter a moldura
   estrutural standalone em `rounded-lg` e os controles internos em `rounded-md`.
+- Execução de Content seccionado: compor `Content framed layout="sectioned"` com mídia e
+  `DetailGroup` com divisores; provar header com divisor, body sem recuo e ausência de classes no
+  consumidor que reconstruam essa anatomia. Reprovar a combinação com `frameVariant="legend"`.
 - Reprova: criar uma casca `bg-card` que herda o texto global ou introduzir `rounded-widget`
   quando a escala `rounded-*` atende ao papel.
 - Reprova: trocar automaticamente o radius de um controle quando apenas seu tamanho muda ou

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

@@ -8,25 +8,21 @@
   parâmetro podem declarar `route.record` para hidratar o item a partir de uma Presentation de
   lista; não reconstruir essa decisão com condicionais no componente da página.
 - `Page` fornece o `<main>` e o container centralizado com teto padrão de `80rem`. Sua forma
-  explícita exige `PageBody`, exatamente um heading principal e aceita `PageHeader`, `PageIntro` e
-  `PageFooter`. Declare esse heading com `PageTitle` em header/intro, `Content level={1}` ou um
-  `PageState` ativo no body. `PageHeader`
-  declara chrome; `PageIntro` declara uma introdução opcional no conteúdo. `title` e `actions` no
+  explícita exige `PageBody`, exatamente um heading principal e aceita `PageHeader` e `PageFooter`.
+  Declare esse heading com `PageTitle` no header, `Content level={1}` ou um `PageState` ativo no
+  body. `PageHeader` é a única introdução estrutural e reúne navegação, título e ações. `title` e `actions` no
   próprio `Page` são a abreviação para o caso direto.
   Não misturar as duas formas. Alterar `className` apenas quando a superfície tiver uma necessidade
   real de largura; não reconstruir esse container em cada rota.
-- `PageIntro` é a região estrutural de uma introdução no conteúdo. Pode coexistir com
-  `PageHeader`, porque as duas regiões têm papéis diferentes.
-- `PageHeader` declara navegação e ações globais; fora do shell também pode carregar o título. Em
-  uma subpágina simples, `PageBack` recebe o destino pai explícito e aparece
-  antes do título como controle somente com ícone. Para mais de um ancestral relevante, use
+- `PageHeader` declara navegação contextual, título e ações. Em uma subpágina simples, `PageBack`
+  recebe o destino pai explícito e aparece acima da linha do título como controle somente com
+  ícone. Para mais de um ancestral relevante, use
   `Breadcrumb` dentro de `PageNavigation`. Não combine retorno e breadcrumb nem crie um chrome
   paralelo para uma `Page`. `PageActionsTarget` fica reservado a workspaces imersivos que já
   possuam chrome próprio.
 - Quando shell e rota conhecem partes diferentes da mesma página, use `PageShell` ao redor da rota.
-  O shell é o único responsável pela barra e projeta os slots de `PageHeader`; `PageIntro` permanece
-  no conteúdo.
-  Ações com texto na barra usam o tamanho `default`, como as ações de footer de Dialog e Drawer;
+  O shell entrega navegação e ações ao `PageHeader` descendente sem criar uma barra visual.
+  Ações com texto no cabeçalho usam o tamanho `default`, como as ações de footer de Dialog e Drawer;
   ações somente com ícone de chrome usam `icon`. O tamanho `sm` fica para ações operacionais em
   toolbar, seção ou coleção densa, e `xs`/`icon-xs` para ações internas de linha ou célula. Contexto
   e variante resolvem a hierarquia visual sem alterar essa medida. Em uma coleção, a ação de
@@ -34,9 +30,8 @@
   `PaneHeader`, portal ou seletor global para reconstruir essa composição.
 - `PageState` substitui todo o conteúdo principal quando a página carrega, falha ou está vazia. Na
   forma curta ele pode ser escrito como filho direto de `Page`, que cria o `PageBody`; na forma
-  explícita, fica sozinho dentro de `PageBody`. Nos três estados ativos, o cabeçalho da Page isolada
-  some inteiro — incluindo o `PageBack`; dentro de `PageShell`, `PageIntro` some e a barra
-  permanece. O estado ocupa a área disponível e seu título assume o heading
+  explícita, fica sozinho dentro de `PageBody`. Nos três estados ativos, o cabeçalho da Page
+  some inteiro — incluindo navegação e ações recebidas de `PageShell`. O estado ocupa a área disponível e seu título assume o heading
   principal, inclusive quando um componente intermediário renderiza o estado. Uma subpágina que
   dependa do retorno ao pai oferece essa saída pelo `action` do próprio `PageState`. O erro mantém
   `role="alert"`, usa a mesma composição central e sem moldura dos demais estados e apresenta a
@@ -48,7 +43,10 @@ ContentDescription, ContentMeta, ContentActions) + ContentBody`. `ContentHeader`
   direto e não podem ser misturados ao header explícito. Na variante `page`, ações da coleção ficam
   no extremo oposto ao título; a criação usa botão textual `default`, sem ícone, com `Criar recurso`.
   O diálogo de criação usa `Criar recurso` e o de edição, `Editar recurso`. `level` preserva a
-  hierarquia semântica do heading.
+  hierarquia semântica do heading. `Content framed` aceita `layout="sectioned"` quando o filho
+  direto já possui recuo interno, como `DetailGroup` com divisores, lista ou tabela: o header recebe
+  divisor e o body fica sem padding. `frameVariant="legend"` trata a borda contínua e não combina
+  com esse layout.
 - Uma página centrada em coleção compõe `Content + ActionList`. O `ContentHeader` recebe título e
   criação; o `ActionList` mantém busca, filtros, atualização, resultados, estados e paginação.
   `toolbarActions` fica reservado a operações que dependem do recorte atual.