@softize/opus 10.0.0 → 11.1.0

package/src/ui/docs/content/auth.md

@@ -21,8 +21,9 @@ interface AuthAdapter {
 }
 ```
 
-`req` é o request cru do `ServerAdapter`. O `user` sai dos claims/sessão; o `can` é a régua
-de autorização — o Opus só chama, não decide.
+`req` é o request cru do `ServerAdapter`. O `user` vem dos claims ou da sessão, e o driver
+fornece a função `can` que decide cada autorização. O Opus chama essa função sem definir a
+política usada por ela.
 
 ## Drivers
 

package/src/ui/docs/content/cli.md

@@ -9,7 +9,8 @@ valida as convenções e expõe o estado vivo pros agentes via MCP.
 
 ## Gates
 
-> A régua de entrega: 0 violação antes de qualquer handoff. Rode no CI e antes de commitar.
+> Use o check no CI e antes de entregar uma mudança. Ele informa quais contratos precisam de
+> ajuste e encerra com sucesso quando não encontra violações.
 
 ```bash
 opus check src    # valida as convenções das actions (exit ≠ 0 se violar)

package/src/ui/docs/content/confirm.md

@@ -75,11 +75,11 @@ render(<Demo />)
 Monte **um** `<DialogHost />` no shell do app, ao lado do `<Toaster />`:
 
 ```tsx
-<AppShell sidebar={…}>
+<>
   {rotas}
   <Toaster />
   <DialogHost />
-</AppShell>
+</>
 ```
 
 Sem ele, os três **lançam** — em vez de devolver uma promise que nunca resolve. Promise pendurada viraria clique sem efeito, o pior desfecho pra uma interrupção que exige resposta: a pessoa acha que respondeu, ou clica de novo. (`<ConfirmHost />` segue valendo como alias de `<DialogHost />`.)

package/src/ui/docs/content/data.md

@@ -88,7 +88,7 @@ const { rows } = await bi.query(sqlDoLlm, { role: roleFor(ctx) })
 
 1. **Pool com teto** (`max` do pool e/ou `maxConcurrent`) — query de LLM não esgota as
    conexões do app;
-2. **`BEGIN TRANSACTION READ ONLY`** — escrita morre no servidor;
+2. **`BEGIN TRANSACTION READ ONLY`** — o servidor rejeita tentativas de escrita;
 3. **`SET LOCAL ROLE` por transação** — o alcance é do CONTEXTO (crie os roles com grants
    default-fechado nas suas migrações: sem isso, `sales_read` leria `hr_employees`);
 4. **Protocolo estendido** — o SQL roda sempre com array de valores; multi-sentença

package/src/ui/docs/content/getting-started.md

@@ -4,42 +4,34 @@ title: Getting started
 
 # Getting started
 
-O Opus é um SDK/protocolo spec-driven: o domínio **É** a aplicação (contratos +
-actions); front e back são cascas. Um projeto Opus-based pina o Opus, herda o runtime e segue os gates.
+O Opus ajuda cliente e servidor a preservar as mesmas regras à medida que uma aplicação
+evolui. Entidades e contratos de action ficam em uma camada compartilhada; o runtime, a UI e
+as ferramentas usam essas definições sem exigir schemas e tipos paralelos.
 
 ## O modelo
 
-> Antes de qualquer arquivo: por que o Opus existe e o que ele assume.
+> Comece pelo problema que o modelo compartilhado resolve antes de conhecer seus arquivos.
 
-A aplicação é o **domínio** — entidades, dicts e contratos de action. A API e a web são cascas
-que consomem esse domínio: zero shape duplicado. O Opus entrega o núcleo (runtime, adapters, UI,
-CLI) e os gates que mantêm o padrão. O que cada projeto adiciona é o seu domínio; o resto vem pinado.
+As regras de uma aplicação costumam aparecer em vários lugares: validação, transporte, API,
+formulários e documentação. No Opus, entidades, dicts e contratos de action descrevem essas
+regras uma vez. A API e a web consomem a mesma definição, enquanto runtime, adapters, UI, CLI
+e verificações ajudam a mantê-la consistente. Cada projeto acrescenta seu domínio sobre essa
+base versionada.
 
 ## Começar do zero
 
 > Projeto novo não se monta à mão: o esqueleto canônico sai do `opus create`, com os
 > pré-requisitos do protocolo, da UI e do preview já plugados — e os gates verdes.
 
-O Opus mora no registry da Softize (não no npm público) — uma vez por máquina, ensine
-o escopo ao pnpm; dentro do projeto criado o `.npmrc` já cuida disso:
-
 ```bash
-pnpm config set @softize:registry https://registry.softize.com.br/ --global  # 1x por máquina
-
 pnpm dlx @softize/opus create meu-app
 cd meu-app && git init && pnpm install && pnpm test
 ```
 
-Máquina nova: se o pnpm reclamar que o diretório global de binários não está no PATH
-(o `dlx` exige), rode `pnpm setup` e reabra o terminal — também é 1x por máquina. Se o
-setup acusar seção pnpm antiga no shell rc (`ERR_PNPM_BAD_SHELL_SECTION`), é resquício
-de versão anterior: `pnpm setup --force` substitui só o bloco dele.
-
-Release recém-saída (menos de 24h): a quarentena do pnpm resolve o `dlx` pra versão
-ANTIGA em silêncio ("Comando desconhecido" = sintoma clássico). Fure com a versão
-explícita — `pnpm dlx @softize/opus@<versão> create meu-app` — ou com a flag
-`pnpm --config.minimum-release-age=0 dlx …`. Dentro de projeto o pnpm se resolve
-sozinho (auto-exclui o Opus da quarentena no install).
+O comando cria a estrutura inicial e instala a versão estável disponível. Para experimentar
+uma versão específica, acrescente-a ao pacote: `pnpm dlx @softize/opus@<versão> create meu-app`.
+Se o pnpm informar que o diretório global de binários não está no `PATH`, execute `pnpm setup`
+e abra uma nova sessão do terminal antes de tentar novamente.
 
 Nasce com: `opus.config.ts` + domínio-exemplo canônico (0 violações, spec documentada),
 vite + react + tema do Opus (Tailwind v4 CSS-first), dev server na porta que o Maestro
@@ -59,8 +51,8 @@ pnpm dlx @softize/opus create apps/portal              # o app (modo detectado)
 
 ## Carregar o Opus num projeto existente
 
-> O pin vive no `opus.json`; o setup grava o esqueleto local. Ausência de `opus.json` = projeto
-> não inicializado — não improvise, rode o setup.
+> O `opus.json` registra a versão usada pelo projeto. Se o arquivo ainda não existe, o setup
+> cria a estrutura necessária antes das demais etapas.
 
 A versão do Opus fica pinada em `opus.json`. O `opus setup` é per-app: grava o `opus.json`,
 mantém o bloco gerenciado do `CLAUDE.md` (fora dele o arquivo é seu) e semeia o dia zero

package/src/ui/docs/content/microcopy.md

@@ -1,83 +1,130 @@
 ---
-title: Microcopy
+title: Comunicação
 ---
 
-# Microcopy
+# Comunicação
 
-Código em inglês; o que humano lê (UI, comentário, doc) em pt-BR. Frases começam com
-maiúscula e terminam com ponto; labels curtos em sentence case, sem ponto. **Esta página
-é a fonte** — `build-opus-ui` aplica esta convenção (regra duplicada em vez de apontada é
-defeito).
+Toda comunicação do produto deve ajudar alguém a compreender o que está acontecendo e a
+seguir adiante com confiança. Esta orientação vale para documentação, interfaces, mensagens
+de erro, CLI, onboarding, textos explicativos, comentários e respostas produzidas por agentes.
 
-## Língua por camada
+Clareza não significa apenas escrever frases curtas. Um texto claro parte da situação do
+leitor, apresenta o que ele precisa saber e oferece contexto suficiente para que a próxima
+decisão não dependa de adivinhação.
 
-> Regra dura — não tem caso a caso.
+## Antes de escrever
 
-| Camada | Língua |
-|---|---|
-| Identificadores de código (vars, funções, tipos, arquivos, dirs, domínios) | Inglês |
-| Nomes de action / rota | Inglês (`resource.verb`) |
-| Colunas e tabelas de banco | Inglês (snake_case) |
-| Valores de código (enums, status, chaves de dict) | Inglês — mesmo em exemplos e fixtures (`active`, não `ativo`); a UI mostra o label pt |
-| Texto de UI visível (labels, headings, botões, placeholders, mensagens) | pt-BR |
-| Comentários e docs (`.md`) | pt-BR |
+Identifique quem lerá o texto, o que essa pessoa está tentando fazer e qual decisão ou ação
+deve ser possível depois da leitura. Quando essas respostas não estiverem claras, investigue o
+fluxo antes de escolher as palavras.
 
-## Frase vs label
+Organize a explicação nesta ordem sempre que ela ajudar:
 
-> Frase (mensagem, descrição, tooltip, help): maiúscula no início, ponto no fim. Label
-> (botão, heading, item de menu, chip): sentence case, sem ponto.
+1. apresente a situação ou o problema reconhecível pelo leitor;
+2. explique o benefício ou o efeito esperado;
+3. descreva o mecanismo somente no nível necessário;
+4. indique a próxima ação quando houver uma.
 
-| Tipo | Assim | Assim não |
+Não comece pela arquitetura interna quando a necessidade do leitor oferece uma introdução
+mais natural. Termos técnicos são bem-vindos quando acrescentam precisão, mas devem ser
+apresentados antes de serem usados como parte da explicação.
+
+## Voz
+
+Escreva de maneira calma, próxima e segura. A comunicação pode ser firme sem parecer uma
+ordem interna ou um manifesto.
+
+- Prefira explicações completas a slogans, máximas e frases de efeito.
+- Evite absolutos como “sempre”, “nunca”, “zero” e “é” quando houver contexto, condição ou
+  exceção relevante.
+- Não use caixa-alta, negrito ou pontuação para fabricar autoridade.
+- Evite sequências telegráficas, equações e símbolos usados como conectores em prosa.
+- Não presuma que o leitor já concorda com a arquitetura ou conhece o vocabulário da equipe.
+- Explique decisões pelo valor que oferecem às pessoas, não apenas pela disciplina que impõem.
+- Mantenha o mesmo termo para o mesmo conceito em todas as superfícies.
+
+Em vez de “O domínio é a aplicação. Front e back são cascas”, explique a relação:
+
+> O Opus mantém as regras e os contratos do domínio em uma camada compartilhada. Assim,
+> cliente e servidor trabalham com as mesmas definições, sem duplicar schemas, validações ou
+> tipos de transporte.
+
+## Documentação
+
+Uma documentação deve formar o modelo mental do leitor antes de cobrar decisões baseadas
+nele. Apresente primeiro o problema, depois a ideia, um exemplo concreto e os próximos passos.
+Detalhes operacionais e situações excepcionais devem ficar próximos da etapa em que se tornam
+úteis, sem interromper a introdução principal.
+
+Ao registrar uma norma, deixe claro o peso da afirmação:
+
+- **Princípio:** explica a intenção que orienta as decisões.
+- **Regra:** descreve um requisito obrigatório e seu escopo.
+- **Recomendação:** apresenta o caminho preferido quando outras opções continuam válidas.
+- **Comportamento:** informa o que o produto faz automaticamente.
+- **Verificação:** mostra como confirmar que a regra foi atendida.
+- **Exceção:** delimita quando a orientação não se aplica.
+
+Uma regra normativa deve informar a condição em que se aplica, a razão que a sustenta e como
+ela é verificada. Por exemplo:
+
+> Cada action deve ser declarada em um arquivo próprio. Essa separação permite que o registro e
+> os geradores identifiquem cada action de forma determinística. O `opus check` informa quais
+> arquivos precisam ser separados quando encontra mais de uma declaração.
+
+Evite substituir essa explicação por “Uma por arquivo. O gate reprova”. A versão curta omite o
+motivo, não delimita o escopo e transforma uma ajuda em uma advertência.
+
+## Mensagens de erro
+
+Uma mensagem de erro deve responder, nessa ordem, ao que aconteceu, como isso afeta a tarefa e
+o que a pessoa pode fazer. Não culpe o usuário e não exponha endpoint, stack trace, status HTTP
+ou detalhes do runtime na interface; esses dados pertencem ao log ou à área de diagnóstico.
+
+| Situação | Prefira | Evite |
+|---|---|---|
+| Serviço indisponível | O Multica não respondeu. Tente novamente em alguns instantes. | ERRO: request failed (500) |
+| Recurso ausente | Este workspace não existe mais. Volte à lista para escolher outro. | Workspace inválido. |
+| Permissão | Você não tem acesso a este workspace. Peça acesso a um administrador. | Acesso negado. |
+| Validação | Informe um endereço de e-mail válido. | Campo inválido. |
+
+Quando não houver uma ação possível, diga isso com honestidade e preserve o trabalho já feito.
+Não ofereça “tente novamente” como resposta automática para falhas que uma nova tentativa não
+pode resolver.
+
+## Textos de interface
+
+Código e valores internos permanecem em inglês. O que uma pessoa lê na interface usa pt-BR,
+salvo quando o produto declarar outro idioma.
+
+- Frases começam com maiúscula e terminam com ponto.
+- Labels, títulos, itens de menu e botões usam sentence case e não levam ponto.
+- Placeholders de seleção usam `Selecione <artigo> <coisa>…`.
+- Placeholders ajudam a responder, mas não substituem o label do campo.
+- Botões descrevem a ação que executarão, como `Publicar` ou `Salvar alterações`.
+- Textos de ajuda explicam o efeito percebido, não a implementação interna.
+- Abreviações são usadas somente quando o espaço ou o vocabulário do domínio as justificam.
+
+| Tipo | Prefira | Evite |
 |---|---|---|
-| Frase | Opus não inicializado. | ~~opus nao inicializado~~ |
-| Frase | O Multica não respondeu — tente de novo. | ~~ERRO: request failed (500)~~ |
-| Label | Publicar | ~~PUBLICAR~~ |
-| Label | Nova sessão | ~~Nova sessão.~~ |
-| Placeholder | Selecione um cliente… | ~~Selecionar~~ · ~~digite o nome…~~ |
-
-## As regras que mais pegam
-
-> Erros recorrentes de revisão — atenção redobrada nestes.
-
-- **Maiúscula é ortografia, não estilo.** Toda frase começa com maiúscula — em UI,
-  hint/help **e comentário de código** — e nome próprio idem (Engineer, Multica, GitHub).
-  Vale com interpolação: mensagem que começaria com valor ganha um artigo na frente
-  (`O workspace '${slug}' não existe…`).
-- **Frase fluida, não telegrama.** Símbolo não é conector: nada de `—`/`+`/`≈` amarrando
-  ideias em label ou help. `Staff — acesso ao back-office + todos os workspaces` vira
-  label `Staff` + help `Tem acesso ao back-office e a todos os workspaces.`.
-- **"Opus" e "Softize" são nomes próprios.** Em prosa, maiúscula (`o Opus`, `a Softize`);
-  os tokens técnicos ficam minúsculos: `opus check`, `@softize/opus`, `opus.json`,
-  `softize.com.br`. É o nome → maiúscula; é código → minúscula.
-- **Abreviação é último caso.** Por extenso: `mínimo`, `máximo`, `configuração`.
-  `Config indisponível.` é duplamente errado (seco E abreviado): `A configuração não
-  carregou.`. `Ex.:` em placeholder é tolerado (com `E` maiúsculo).
-- **Placeholder de seleção segue UM padrão** (select simples, buscável, múltiplo):
-  `Selecione <artigo> <coisa>…` — com `…` (o caractere único), nunca o genérico
-  `Selecionar`. Declare no contrato (`fields.<campo>.placeholder`) — o default do
-  componente é rede de segurança, não estilo; dois pickers na mesma tela com padrões
-  diferentes é defeito.
-- **Nada de maiúsculo deliberado.** Sem ALL-CAPS — nem a classe `uppercase` — em labels,
-  headers ou badges.
-- **Exemplos são neutros e duráveis.** Nada de cliente real ou com cara de real: use
-  Empresa X / Empresa Y (`contato@empresa-x.com.br`). Exemplo "de verdade" envelhece,
-  vaza contexto e vira dívida.
-
-## Tom
-
-> Fale com o usuário, não com o log.
-
-- **Calmo e informativo, não alarmista.** "Indisponível" em vez de "ERRO"/"FALHOU".
-  Não culpe o usuário.
-- **Orientado à ação.** Quando dá, diga o próximo passo: `Inicie o ambiente`,
-  `Crie a primeira acima`.
-- **Conciso, mas natural — não telegráfico.** Prefira a forma completa do verbo a um
-  corte abrupto. O meio-termo é a régua: nem seco demais (`rode no projeto`) nem manual
-  técnico (jargão de arquitetura num help).
-- **Explique pelo efeito, não pelo mecanismo.** Se precisou citar sistema interno pra
-  explicar (`o push sobrescreve o runtime`), reescreva pelo que acontece pro usuário
-  (`os agentes deste workspace passam a usar esta skill`). Mecanismo é doc/comentário,
-  não tooltip.
-- **Nada de endpoint, status ou stack na tela** — detalhe técnico vai pro console/log.
-- **Termos do produto** (sessão, ambiente, cliente, agente), não do código. E o mesmo
-  termo sempre: se a UI fala "cliente", nenhum label diz "client".
+| Frase | A configuração não carregou. | Config indisponível. |
+| Label | Nova sessão | Nova sessão. |
+| Botão | Publicar | PUBLICAR |
+| Placeholder | Selecione um cliente… | Selecionar |
+| Ajuda | Os agentes deste workspace passam a usar esta skill. | O push sobrescreve o runtime. |
+
+## Revisão
+
+Antes de entregar, releia o texto fora do contexto da implementação e confirme:
+
+- o leitor consegue reconhecer a situação sem conhecer o código;
+- conceitos novos são explicados antes de orientar decisões;
+- regras obrigatórias estão separadas de recomendações;
+- a razão da orientação aparece quando ajuda a compreendê-la;
+- mensagens de erro preservam a calma e oferecem uma saída real;
+- a frase soa como uma conversa profissional, não como log, slogan ou ordem interna;
+- detalhes técnicos permanecem disponíveis no lugar adequado sem dominar a comunicação.
+
+Leia o fluxo completo, não apenas strings isoladas. Um conjunto de frases corretas ainda pode
+produzir uma experiência confusa quando repete informações, muda de vocabulário ou apresenta
+ações fora da ordem em que a pessoa precisa delas.

package/src/ui/docs/content/sidebar.md

@@ -27,7 +27,7 @@ render(
 
 ## Colapso
 
-`collapsed` pertence à própria `Sidebar`; `SidebarItem` e `SidebarNav` adaptam-se automaticamente para botões `size-9` centralizados, ícones e tooltips. `PaneHeader`, `PaneContent` e `PaneFooter` são slots do pane: a aplicação mantém a identidade e ações que lhe pertencem sem atribuí-las artificialmente à sidebar. `SidebarHeader`, `SidebarContent` e `SidebarFooter` seguem como aliases deprecated durante a migração.
+`collapsed` pertence à própria `Sidebar`; `SidebarItem`, `SidebarNav` e `ShellNav` adaptam-se automaticamente para botões `size-9` centralizados, ícones e tooltips. `PaneHeader`, `PaneContent` e `PaneFooter` são os slots do pane: a aplicação mantém a identidade e ações que lhe pertencem sem atribuí-las artificialmente à sidebar.
 
 ```tsx
 <Sidebar collapsed={collapsed}>
@@ -36,3 +36,23 @@ render(
   <PaneFooter><UserMenu /></PaneFooter>
 </Sidebar>
 ```
+
+## Navegação contextual
+
+`SidebarNav` aceita grupos e subgrupos. Isso cobre tanto a navegação global quanto seções internas, como Configurações ou documentação, sem outro shell especializado.
+
+```tsx
+<SidebarNav
+  groups={[
+    {
+      label: 'Configurações',
+      subgroups: [
+        { label: 'Acesso', items: [{ id: 'users', label: 'Usuários' }] },
+        { label: 'Dados', items: [{ id: 'imports', label: 'Importações' }] },
+      ],
+    },
+  ]}
+  activeId={active}
+  onSelect={go}
+/>
+```

package/src/ui/docs/content/upgrading.md

@@ -6,7 +6,7 @@ title: Atualizar o Opus
 
 Projeto em produção fica meses sem tocar no Opus — e um dia precisa pular várias
 versões de uma vez. O ritual é o mesmo para humano e IA, e não depende de memória:
-cada peça do caminho está escrita ou é um gate que quebra alto.
+cada etapa está documentada ou é verificada por um gate que informa o que precisa ser corrigido.
 
 ## 1. Saber que está atrás
 

package/src/ui/docs/registry.tsx

@@ -80,7 +80,6 @@ import paginationMd from './content/pagination.md?raw'
 import popoverMd from './content/popover.md?raw'
 import progressMd from './content/progress.md?raw'
 import radioGroupMd from './content/radio-group.md?raw'
-import resizableMd from './content/resizable.md?raw'
 import scrollAreaMd from './content/scroll-area.md?raw'
 import selectMd from './content/select.md?raw'
 import separatorMd from './content/separator.md?raw'
@@ -114,8 +113,6 @@ import actionViewMd from './content/action-view.md?raw'
 import actionTriggerMd from './content/action-trigger.md?raw'
 import actionSearchDialogMd from './content/action-list-dialog.md?raw'
 import pageMd from './content/page.md?raw'
-import appShellMd from './content/app-shell.md?raw'
-import sectionShellMd from './content/section-shell.md?raw'
 import sidebarMd from './content/sidebar.md?raw'
 import splitMd from './content/split.md?raw'
 import routerMd from './content/router.md?raw'
@@ -270,7 +267,7 @@ export const UI_SECTIONS: DocSection[] = [
       {
         pages: [
           { slug: 'tokens', title: 'Tokens & Tema', render: doc(tokensMd) },
-          { slug: 'microcopy', title: 'Microcopy', render: doc(microcopyMd) },
+          { slug: 'microcopy', title: 'Comunicação', render: doc(microcopyMd) },
           { slug: 'customization', title: 'Customização', render: doc(customizationMd) },
         ],
       },
@@ -295,11 +292,8 @@ export const UI_SECTIONS: DocSection[] = [
           { slug: 'aspect-ratio', title: 'Aspect Ratio', render: comp('Aspect Ratio', 'aspect-ratio', aspectRatioMd) },
           { slug: 'card', title: 'Card', render: comp('Card', 'card', cardMd) },
           { slug: 'collapsible', title: 'Collapsible', render: comp('Collapsible', 'collapsible', collapsibleMd) },
-          { slug: 'resizable', title: 'Resizable', badge: componentMeta.resizable.deprecated ? 'deprecated' : undefined, render: comp('Resizable', 'resizable', resizableMd) },
           { slug: 'scroll-area', title: 'Scroll Area', render: comp('Scroll Area', 'scroll-area', scrollAreaMd) },
           { slug: 'separator', title: 'Separator', render: comp('Separator', 'separator', separatorMd) },
-          { slug: 'app-shell', title: 'App Shell', badge: componentMeta['app-shell'].deprecated ? 'deprecated' : undefined, render: pattern('App Shell', 'app-shell', appShellMd) },
-          { slug: 'section-shell', title: 'Section Shell', badge: componentMeta['section-shell'].deprecated ? 'deprecated' : undefined, render: pattern('Section Shell', 'section-shell', sectionShellMd) },
         ],
       },
       {

package/src/ui/meta.ts

@@ -283,24 +283,17 @@ export const componentMeta = {
     whenToUse:
       'Escolha única entre opções mutuamente exclusivas, todas visíveis ao mesmo tempo (Radix). Cada RadioGroupItem tem um `value`; o item escolhido vira o `value` do RadioGroup, controlado por `value`/`onValueChange` (ou `defaultValue` no modo não controlado). Pareie cada item com um Label. Pra poucas opções que cabem na tela; com muitas, prefira Select; pra ligar/desligar um único item, Checkbox ou Switch.',
   },
-  'resizable': {
-    name: 'resizable',
-    ancestry: 'shadcn',
-    whenToUse:
-      'Painéis redimensionáveis por arraste (react-resizable-panels). Compõe ResizablePanelGroup > ResizablePanel + ResizableHandle entre eles; `orientation` (horizontal/vertical) define a direção do arraste, `defaultSize`/`minSize`/`maxSize` (em %) limitam cada painel e `withHandle` desenha a pega na divisória. O grupo ocupa a altura do pai (h-full), então dê tamanho ao container. Pra alternar entre painéis sem dividir a vista, use Tabs.',
-    deprecated: { alternative: '`Split resizable` + `Pane`', since: 'próxima versão' },
-  },
   'split': {
     name: 'split',
     ancestry: 'opus',
     whenToUse:
-      'Divide uma área em panes em sequência horizontal ou vertical. Use `resizable` quando a pessoa deve ajustar a fronteira; o mesmo `<Split>` vira flex simples sem ele. Cada `<Pane>` declara tamanho inicial/mínimo e inset. É o mecanismo espacial para sidebar, conteúdo e rail — não use AppShell/SectionShell novos.',
+      'Divide uma área em panes em sequência horizontal ou vertical. Use `resizable` quando a pessoa deve ajustar a fronteira; o mesmo `<Split>` vira flex simples sem ele. Cada `<Pane>` declara tamanho inicial/mínimo e inset. É o mecanismo espacial para sidebar, conteúdo e rail.',
   },
   'sidebar': {
     name: 'sidebar',
     ancestry: 'opus',
     whenToUse:
-      'Chrome e navegação de uma coluna lateral, encaixada onde um Split decidir. `Sidebar` possui o colapso; `PaneHeader`, `PaneContent` e `PaneFooter` estruturam qualquer pane, e `SidebarNav`/`SidebarItem` apresentam a navegação. Serve tanto a barra global quanto uma nav contextual; em Split redimensionável passe `divider={false}` para não duplicar a divisória. `SidebarHeader`, `SidebarContent` e `SidebarFooter` são aliases deprecated.',
+      'Chrome e navegação de uma coluna lateral, encaixada onde um Split decidir. `Sidebar` possui o colapso; `PaneHeader`, `PaneContent` e `PaneFooter` estruturam qualquer pane, e `SidebarNav`/`SidebarItem` apresentam navegação com grupos e subgrupos. Serve tanto a barra global quanto uma nav contextual; em Split redimensionável passe `divider={false}` para não duplicar a divisória.',
   },
   'scroll-area': {
     name: 'scroll-area',
@@ -381,20 +374,6 @@ export const componentMeta = {
     whenToUse:
       'O esqueleto de página do back-office: <main> + container de largura cheia (className="max-w-5xl" estreita e centra) + header com título, descrição e ação à direita (em geral o criar). Presentacional (a página agrega N fontes); o action-driven mora dentro. Pra listagem em modal, ActionListDialog.',
   },
-  'app-shell': {
-    name: 'app-shell',
-    ancestry: 'opus',
-    whenToUse:
-      'O chrome da aplicação: sidebar de navegação (header + nav rolável + rodapé ancorado) + conteúdo, com rail opcional à direita (chat de agente, inspetor) em painéis redimensionáveis. É o quadro — o que vai em cada slot é do app. Pro esqueleto de UMA página (título, descrição, ação), Page. Chrome `flush` opcional (full-bleed, filete à esquerda) com <AppShellBar> — a faixa h-12 border-b usada na sidebar (marca) e no topo do conteúdo pra linha do header atravessar a tela. Sidebar recolhível com `collapsible` (opt-in): o shell controla a largura e publica `data-collapsed` no aside; o rótulo some por CSS (`group-data-[collapsed=true]/sidebar:hidden`) porque o nav é do app. O botão é o <AppShellTrigger />, posicionado pelo consumidor; `useAppShell()` dá o estado em JS.',
-    deprecated: { alternative: '`Split` + `Pane` + `Sidebar`', since: 'próxima versão' },
-  },
-  'section-shell': {
-    name: 'section-shell',
-    ancestry: 'opus',
-    whenToUse:
-      'Uma SEÇÃO com navegação própria — o nível entre AppShell (o app) e Page (uma tela): nav w-56 com filete + painel, pras telas irmãs de Configurações, Relatórios ou doc. Use quando a seção é visitada raro e navegada por dentro quando visitada (não vale queimar item na sidebar do app), ou quando a lista é dinâmica demais pra um nav estático. Pra facetas do MESMO objeto, Tabs. Controlado (activeId + onSelect): o roteamento é do app. Grupos aceitam `items` e/ou `subgroups` (o 3º nível, ex.: sub-pasta na doc). O painel remonta quando o `activeId` muda — é o que zera o scroll; `scrollResetKey` sobrescreve a chave nos dois sentidos: constante = nunca remonta (preserva o scroll), mais fina que o activeId = remonta também dentro da mesma tela.',
-    deprecated: { alternative: '`Split` + `Pane` + `Sidebar`', since: 'próxima versão' },
-  },
   'router': {
     name: 'router',
     ancestry: 'opus',

package/src/ui/react.tsx

@@ -164,7 +164,6 @@ export { Kbd, KbdGroup } from './components/primitives/kbd.tsx'
 export { Pagination, PaginationContent, PaginationEllipsis, PaginationItem, PaginationLink, PaginationNext, PaginationPrevious } from './components/primitives/pagination.tsx'
 export { Progress } from './components/primitives/progress.tsx'
 export { RadioGroup, RadioGroupItem } from './components/primitives/radio-group.tsx'
-export { ResizableHandle, ResizablePanel, ResizablePanelGroup } from './components/primitives/resizable.tsx'
 export { ScrollArea, ScrollBar } from './components/primitives/scroll-area.tsx'
 export { Slider } from './components/primitives/slider.tsx'
 export { Switch } from './components/primitives/switch.tsx'
@@ -206,29 +205,15 @@ export type { DataStateProps } from './components/patterns/data-state.tsx'
 export { Page } from './components/patterns/page.tsx'
 export type { PageProps } from './components/patterns/page.tsx'
 
-// Chrome da aplicação (sidebar + conteúdo + rail opcional redimensionável).
-export { AppShell, AppShellBar, AppShellTrigger, useAppShell, useSidebarSlot } from './components/patterns/app-shell.tsx'
-export type { AppShellProps } from './components/patterns/app-shell.tsx'
-
 // Layout composicional: Split decide a relação espacial; Pane carrega conteúdo com inset.
 export { Split, Pane } from './components/patterns/split.tsx'
 export type { SplitProps, PaneProps } from './components/patterns/split.tsx'
 
 // Barra lateral composicional: header/conteúdo/footer e navegação, sem possuir o layout.
-export { PaneHeader, PaneContent, PaneFooter, Sidebar, SidebarHeader, SidebarContent, SidebarFooter, SidebarItem, SidebarNav } from './components/patterns/sidebar.tsx'
-export type { SidebarProps, SidebarItemProps, SidebarNavGroup } from './components/patterns/sidebar.tsx'
-
-// Seção com navegação própria (nav w-56 + painel) — o nível entre o AppShell e a Page.
-export { SectionShell } from './components/patterns/section-shell.tsx'
-export type {
-  SectionShellProps,
-  SectionNavGroup,
-  SectionNavSubgroup,
-  SectionNavItem,
-} from './components/patterns/section-shell.tsx'
-
-// O menu como primitivo PIVOTÁVEL: mesmo nav na sidebar do AppShell ou dentro do conteúdo
-// (colapso por CSS via o grupo `sidebar`). Ver docs/shellnav.md.
+export { PaneHeader, PaneContent, PaneFooter, Sidebar, SidebarItem, SidebarNav } from './components/patterns/sidebar.tsx'
+export type { SidebarProps, SidebarItemProps, SidebarNavGroup, SidebarNavSubgroup, SidebarNavItem } from './components/patterns/sidebar.tsx'
+
+// O menu como primitivo pivotável: recolhe quando composto dentro de Sidebar.
 export { ShellNav, ShellNavHeading } from './components/patterns/shell-nav.tsx'
 export type { ShellNavProps, ShellNavGroup, ShellNavItem, ShellNavHeadingProps } from './components/patterns/shell-nav.tsx'