@softize/opus 25.0.0 → 25.2.0

package/docs/adr/0052-floating-layer-coexists-with-modal-surfaces.md

@@ -0,0 +1,668 @@
+# ADR 0052 — Uma camada flutuante convive com Dialog e Drawer modais
+
+- **Status:** aceita.
+- **Data:** 2026-10-03.
+- **Complementa:** ADR 0023, quanto a Dialog e Drawer como superfícies modais, e ADR 0017, quanto à
+  largura mínima suportada.
+- **Relacionadas:** ADR 0007, porque o Toast já convive com o modal, mas só em parte; na plataforma
+  Grand Brasil, ADR 0087, que define o FAB e o painel do Copilot global.
+
+## Contexto
+
+### O pedido
+
+Na plataforma Grand Brasil, o Copilot global aparece como um botão flutuante (FAB) no canto inferior
+direito. Aberto, ele vira um painel de `28rem` de largura sobreposto no mesmo canto. Quem está
+preenchendo um formulário num Dialog ou num Drawer quer perguntar ao Copilot sobre o que está vendo
+sem perder o que já digitou.
+
+A decisão de produto já foi tomada: o FAB e o painel ficam visíveis e utilizáveis por cima de
+qualquer Dialog ou Drawer, e o modal continua aberto e intacto atrás. A outra saída, fechar o modal
+quando a pessoa aciona o FAB, foi descartada porque jogaria fora o preenchimento.
+
+Hoje isso não funciona, e a causa não está na Grand Brasil. Está no modo modal que o Opus usa.
+
+### O que o modo modal faz hoje
+
+O `Dialog` e o `Drawer` do Opus são o `Dialog` do Radix no modo modal, que é o padrão. O Drawer não
+usa vaul: é o mesmo `Dialog` do Radix, importado de `radix-ui`, com outra moldura. Enquanto um deles
+está aberto, o Radix faz cinco coisas:
+
+1. **Prende o foco.** Um `FocusScope` com trava devolve ao último elemento focado dentro do modal
+   qualquer foco que vá para fora dele, e o Tab dá a volta dentro do modal.
+2. **Bloqueia o ponteiro fora.** O `DismissableLayer` do modal grava `pointer-events: none` no
+   `body`; só o modal e os `DismissableLayer` abertos depois dele voltam a receber clique. O véu
+   (`z-50`, ocupando a tela inteira) fica por cima do resto.
+3. **Trata clique fora e Esc como pedido de fechar.** Apertar o botão principal fora do modal fecha
+   quando o clique se completa; o botão direito não fecha. O Esc é ouvido no documento inteiro, e
+   quem responde é o `DismissableLayer` aberto mais recentemente, onde quer que o foco esteja. Foco
+   que sai do modal nunca o fecha: o próprio Radix cancela esse caso.
+4. **Trava a rolagem fora.** O `react-remove-scroll` cancela roda do mouse e arrasto de toque que
+   não nasçam dentro do modal.
+5. **Esconde o resto do leitor de tela.** O `hideOthers`, do pacote `aria-hidden`, percorre o `body`
+   e marca com `aria-hidden="true"` todo elemento fora do caminho até o modal. Um filho do `body`
+   que não contém o modal é marcado inteiro. Há uma exceção embutida: elementos com `aria-live`
+   presentes naquele momento também ficam visíveis, e o caminho até eles é preservado; nos
+   ancestrais desse caminho, só os irmãos que estão fora dele são marcados. O conteúdo do modal não
+   recebe `aria-modal`.
+
+O `hideOthers` não é exclusivo do `Dialog`. O `Menu` do Opus é o `DropdownMenu` do Radix, que é modal
+por padrão e também chama `hideOthers` ao abrir, assim como as confirmações do `DialogHost`.
+
+Na Grand Brasil, o FAB e o painel ficam dentro do `#root`. Com um modal aberto, os dois ficam
+escondidos do leitor de tela, sem ponteiro e abaixo do véu. Mesmo que a pessoa alcançasse a caixa
+de mensagem, a trava devolveria o foco ao modal, e a caixa não receberia digitação.
+
+### As exceções que existem
+
+Antes de escolher um caminho, convém saber exatamente o que o Radix já permite. Cada item abaixo
+foi conferido no código instalado (seção “Premissas verificadas”).
+
+- **Exceções públicas, só para o fechamento.** `onEscapeKeyDown`, `onPointerDownOutside`,
+  `onFocusOutside` e `onInteractOutside` aceitam `preventDefault` e impedem que o modal feche. O
+  `DialogContent` e o `DrawerContent` do Opus repassam esses handlers e compõem `closeDisabled` sobre
+  o Esc e o clique fora. Eles não liberam foco, ponteiro, rolagem nem leitor de tela. E nenhum
+  pattern construído sobre esses componentes os repassa: `ActionFormDialog`, `ActionListDialog`,
+  `Presentation`, `ActionTrigger`, os diálogos de `ActionList`, as confirmações do `DialogHost` e o
+  `CommandDialog` não expõem esses handlers.
+- **Peças internas do Radix.** `FocusScope` e `DismissableLayer` (com o `Branch`) saem em
+  `radix-ui/internal` e como pacotes próprios no npm, mas ficam fora da documentação pública do
+  Radix. O `Branch` faz com que clique e foco num elemento deixem de contar como “fora”; não muda
+  ponteiro, rolagem, leitor de tela nem a trava de foco. Um `FocusScope` montado depois do modal
+  pausa a trava do modal, mas a pilha de escopos do Radix só a retoma quando esse escopo desmonta.
+  Uma camada sempre montada, como o FAB, deixaria o modal sem trava e sem a volta do Tab durante
+  toda a vida dela: o Tab sairia do modal para a página escondida.
+- **`modal={false}`.** Desliga de uma vez a trava, o bloqueio de ponteiro, o véu (o Radix deixa de
+  renderizar o `Overlay`), a trava de rolagem e o `aria-hidden`. A volta do Tab continua, e o
+  diálogo passa a fechar também quando o foco sai dele. O `mode="alert"` usa o `AlertDialog` do
+  Radix, que força o modo modal e ignora essa opção.
+- **As bibliotecas por baixo aceitam exceções; o Radix não as repassa.** O `hideOthers` aceita uma
+  lista de elementos a manter visíveis, e o `react-remove-scroll` aceita áreas extras (`shards`),
+  mas o `Dialog` do Radix passa só o próprio conteúdo nos dois casos.
+
+### O precedente do Toaster
+
+O Toaster (Sonner) já aparece por cima de um modal: tem `z-index` altíssimo, e sua região tem
+`aria-live`, então o `hideOthers` não o esconde e os avisos continuam sendo anunciados. Mas ele não
+declara `pointer-events: auto` e herda o `none` do `body`. Pela leitura do código, as ações de um
+aviso (ADR 0007) não respondem a clique enquanto um modal está aberto; isso ainda precisa ser
+confirmado no navegador. Por teclado, a trava não deixa o foco chegar a ele. O Toaster convive com
+o modal para ser lido, não para ser usado. É um precedente parcial, e o mesmo problema desta ADR.
+
+### Forças em tensão
+
+- **A acessibilidade do modal.** Quem usa teclado ou leitor de tela depende da trava de foco, do Esc
+  e do resto da página escondido para saber onde está e não se perder atrás do véu. Essa garantia
+  não pode piorar para quem nunca usa a camada.
+- **Uma camada de assistência utilizável.** O painel precisa receber clique, foco, digitação, rolagem
+  e Esc sem fechar o modal nem ser puxado de volta por ele, e precisa continuar audível para o
+  leitor de tela.
+- **A regra precisa valer em todo lugar.** Se a convivência depender de cada consumidor repassar
+  handlers, os patterns, que não os repassam, ficam de fora, e cada tela nova pode esquecer.
+- **A dependência do Radix.** Quanto mais a solução depender de detalhes não documentados do Radix e
+  das bibliotecas por baixo, mais uma atualização pode quebrá-la sem aviso.
+- **Reversibilidade.** A API pública deve sobreviver a uma troca de implementação, porque a parte
+  mais arriscada, o foco, ainda precisa ser provada no navegador.
+
+## Decisão
+
+### 1. O que é a camada flutuante
+
+Uma **camada flutuante** é uma região da aplicação que fica acima do conteúdo e dos modais de
+trabalho (Dialog e Drawer) e continua utilizável enquanto eles estão abertos. O FAB e o painel do
+Copilot são o primeiro caso.
+
+Ela não é um popover, um menu nem um tooltip, que são transitórios e presos a um gatilho. Também não
+é o `Dock`, que flutua sobre uma única superfície, fica dentro dela e some com ela. E não é um modal:
+não bloqueia nada. O nome repete o termo do pedido da Grand Brasil (TODO, seção 18). O comentário de
+`src/ui/lib/dismiss-on-iframe.ts` usa “camada flutuante” no sentido solto de popover e menu, e deve
+ser reescrito junto com a implementação para não confundir os dois conceitos.
+
+O princípio durável é este: **o Opus é dono da convivência.** Um modal do Opus trata a camada como
+parte de dentro quanto a foco, clique, Esc, rolagem e leitor de tela. Quem usa Dialog, Drawer ou
+qualquer pattern construído sobre eles não repassa nada. O consumidor só declara a camada.
+
+### 2. A API pública
+
+```tsx
+import { FloatingLayer } from '@softize/opus/ui/react'
+
+<FloatingLayer onEscapeKeyDown={handleEscape}>
+  {copilotOpen ? <CopilotPanel /> : <CopilotFab />}
+</FloatingLayer>
+```
+
+```ts
+interface FloatingLayerProps {
+  children: React.ReactNode
+  /** Classes do hospedeiro. A posição de cada filho continua sendo do consumidor. */
+  className?: string
+  /**
+   * Esc enquanto a pessoa está na camada (seção 5), com ou sem modal aberto. É chamado uma vez por
+   * tecla. Nenhum modal fecha nesse caso, e o Opus não fecha a camada sozinho, porque o estado de
+   * aberto pertence ao consumidor.
+   */
+  onEscapeKeyDown?: (event: KeyboardEvent) => void
+}
+```
+
+- `FloatingLayer` porta seus filhos para um hospedeiro estável no `body`:
+  `div[data-slot="floating-layer"]`, fixo, ocupando a tela inteira, com `pointer-events: none` no
+  hospedeiro e `auto` nos filhos diretos. O consumidor posiciona cada filho com `absolute` contra a
+  viewport.
+- O hospedeiro publica qual modal de trabalho está no topo da pilha: `data-modal` vale `none`,
+  `dialog` ou `drawer`, e `data-modal-side` traz o lado do Drawer (`left`, `right`, `top` ou
+  `bottom`). É o sinal público para o consumidor adaptar a posição dos filhos (seção 7). Com um
+  modal de resposta obrigatória ou um modal interno à camada no topo, o sinal continua descrevendo
+  o modal de trabalho mais alto da pilha, ou `none` se não houver nenhum; a camada está coberta
+  nesse intervalo, e mudar sua posição só para ele faria o painel pular duas vezes.
+- O hospedeiro não tem papel ARIA. A semântica vem dos filhos: na Grand Brasil, `aside` com
+  `aria-label="Copilot"` e o botão “Abrir o Copilot”.
+- Podem existir várias camadas ao mesmo tempo. A ordem de montagem desempata o empilhamento entre
+  elas.
+- O componente mora em `src/ui/components/primitives/floating-layer.tsx`. O registro das camadas e a
+  pilha dos modais do Opus moram em `src/ui/lib/modal-layers.ts`, consumido por `dialog.tsx`,
+  `drawer.tsx` e pelos primitives que usam portal. A exportação sai por `src/ui/react.tsx`.
+- Não há provider novo. O registro tem um valor padrão global, como o próprio Radix faz com o
+  contexto do `DismissableLayer`, para funcionar com o `DialogHost`, fora do `OpusProvider` e nos
+  exemplos da documentação.
+
+### 3. Portais dentro da camada
+
+Popover, Menu, Tooltip, o que é construído sobre eles (como Select) e Dialog ou Drawer abertos de
+dentro da camada passam a portar para o hospedeiro da camada em vez do `body`. Os primitives que usam
+portal leem o contêiner de um contexto que a `FloatingLayer` fornece; fora dela, nada muda.
+
+Sem isso, o menu de “nova conversa” ou a explicação de uma resposta do Copilot abririam no `body`,
+na faixa dos modais, e ficariam por baixo do próprio painel que os abriu. Portados para o
+hospedeiro, eles ficam acima do painel e contam como parte da camada para foco, rolagem e leitor de
+tela.
+
+Um modal aberto de dentro da camada é modal para tudo, inclusive para a própria camada. Ele entra na
+pilha marcado como **não isento**: enquanto estiver no topo, nenhuma exceção desta ADR fica ativa
+(seção 6), e a subárvore dele nunca conta como “dentro da camada”.
+
+### 4. Empilhamento
+
+Do fundo para a frente, a ordem passa a ser:
+
+1. conteúdo da página;
+2. faixa modal: Dialog, Drawer, seus véus e os popovers abertos fora da camada, todos em `z-50`,
+   desempatados pela ordem no DOM, como hoje;
+3. faixa da camada flutuante;
+4. faixa de resposta obrigatória: `mode="alert"` e o `DialogHost` (decisão 4 da seção 9);
+5. Toaster, com o `z-index` do Sonner.
+
+Os valores de `z-index` de cada faixa são detalhe de implementação. Eles ficam documentados numa
+escala própria em `packages/opus/docs`, ao lado de `elevation-scale.md`.
+
+### 5. O comportamento enquanto um modal convive com a camada
+
+| Aspecto | Hoje | Com a camada |
+| --- | --- | --- |
+| Ponteiro | Só o modal recebe clique. | A camada também recebe. A página atrás continua coberta pelo véu. |
+| Clique na camada | Fecha o modal. | Não fecha nenhum modal, mesmo que o elemento clicado suma no próprio clique. |
+| Clique no modal | — | O Opus não impõe nada à camada; fechá-la é decisão do consumidor. |
+| Clique no véu | Fecha o modal. | Fecha o modal, como hoje, respeitando `closeDisabled`. |
+| Esc | Fecha o `DismissableLayer` mais recente. | Age onde a pessoa está (abaixo). |
+| Foco | Preso no modal. | Modal e camada formam a região permitida (abaixo). |
+| Rolagem | Só dentro do modal. | Dentro do modal e dentro da camada. A página continua travada. |
+| Leitor de tela | Só o modal fica visível. | O modal e a camada ficam visíveis; o resto continua escondido. |
+
+Sem nenhum modal aberto, a camada é DOM comum: nenhuma das exceções acima fica ativa, e só o
+`onEscapeKeyDown` da camada continua valendo.
+
+**Onde a pessoa está.** O foco decide primeiro: com o foco num elemento do modal, a pessoa está no
+modal; com o foco num elemento da camada, está na camada; com o foco em qualquer outro elemento da
+página, não está na camada. O ponteiro decide só quando o foco está no `body`: o último aperto
+dentro do hospedeiro põe a pessoa na camada, e o último aperto fora dele a tira. Assim, clicar
+numa área sem foco do painel, como o texto de uma resposta, conta como estar na camada. E clicar num botão do painel que não recebe foco (barras de ferramentas e listas do `cmdk`
+impedem o foco no aperto) deixa o foco no campo do modal: se a pessoa volta a digitar ali e aperta
+Esc, o modal fecha, como esperado.
+
+**Esc age onde a pessoa está.** Na camada, nenhum modal fecha e o Opus chama o `onEscapeKeyDown` da
+camada uma vez. No modal, o Esc fecha o modal, como hoje. A alternativa de fechar primeiro o que
+está visualmente por cima foi descartada: quem preenche o modal e aperta Esc quer sair do modal, não
+do painel que nem está usando.
+
+Antes dessa regra vale a do Radix: um `DismissableLayer` aberto depois do modal consome o Esc, onde
+quer que a pessoa esteja. Isso dá três exceções conhecidas e aceitas:
+
+- um popover ou menu aberto dentro da camada fecha primeiro, e só o Esc seguinte chega à camada;
+- um popover aberto dentro do modal continua no topo e consome o Esc mesmo com a pessoa na camada;
+- o tooltip do FAB, aberto por passagem do mouse, consome o Esc mesmo com a pessoa no modal.
+
+Para impedir o Radix de fechar o modal, o Opus precisa chamar `preventDefault` no evento de teclado.
+Por isso o evento nativo chega aos elementos da camada já com `defaultPrevented`. A camada trata o
+Esc só pelo `onEscapeKeyDown`; um `onKeyDown` próprio para Esc no painel trataria a tecla duas vezes.
+
+**Foco.** O foco pode ir para a camada por clique ou por chamada de código (o Copilot focando a
+caixa de mensagem ao abrir) sem ser puxado de volta. Foco que vai para qualquer outro lugar volta ao
+último elemento focado no modal, como hoje. `onBlur` e `onFocus` dos campos do modal e da camada
+continuam disparando normalmente. Dentro da camada, o Tab segue a ordem dela. Como o teclado chega à
+camada e para onde o foco volta quando a camada some estão nas decisões 2 e 3 da seção 9.
+
+**Leitor de tela.** O Opus não adiciona `aria-modal` ao conteúdo dos modais, que hoje não o tem.
+Leitores que respeitam `aria-modal` passariam a ignorar a camada. A camada continua visível também
+quando um menu modal abre e fecha sobre o modal, e quando o painel contém uma região `aria-live`
+própria, como a do `Ask` ou do `StateSurface`.
+
+### 6. Quando as exceções ficam ativas
+
+Cada modal do Opus se registra numa pilha ao abrir, com uma de três marcas:
+
+- **de trabalho:** Dialog e Drawer portados fora de qualquer hospedeiro de camada;
+- **de resposta obrigatória:** `mode="alert"` e as confirmações do `DialogHost`;
+- **interno à camada:** qualquer modal portado para um hospedeiro (seção 3).
+
+As exceções desta ADR (clique, Esc, foco, rolagem e leitor de tela) ficam ativas **somente quando o
+topo da pilha é um modal de trabalho**. Com um modal de resposta obrigatória ou um modal interno à
+camada no topo, todas ficam suspensas: a trava, o véu, o Esc e o `aria-hidden` desse modal agem
+sobre a camada como sobre o resto da página. Isso evita dois defeitos:
+
+- um modal aberto de dentro da camada teria a trava cega, o véu sem efeito e o Esc desviado para a
+  camada, porque estaria dentro do hospedeiro isento;
+- com um alerta no topo, um foco programático do Copilot escaparia da trava do alerta.
+
+Mesmo com as exceções ativas, a subárvore de um modal interno à camada nunca conta como dentro da
+camada.
+
+Com modais de trabalho empilhados (Dialog sobre Drawer, Drawer sobre Drawer), a isenção vale para
+todos; a trava de foco e o Esc continuam agindo só no modal do topo, como hoje. Fechar o modal do
+topo devolve o controle ao de baixo, e a camada continua isenta.
+
+### 7. Telas pequenas e sobreposição
+
+A ADR 0017 suporta a interface a partir de `64rem`. O painel de `28rem`, ancorado à direita e com até
+`44rem` de altura, cobre áreas que a pessoa precisa ver:
+
+- **Drawer à direita, o caso mais comum.** O `DrawerContent` padrão tem `side="right"` e até `24rem`
+  de largura; na Grand Brasil há Drawers de `24rem`, `28rem` e `56rem`. O painel cobre os dois
+  primeiros na largura inteira e quase toda a altura, e metade do de `56rem`. Com o painel aberto,
+  perguntar sobre o que está no Drawer fica, na prática, impossível.
+- **Drawer com assistência contextual aberta.** A `Presentation` em Drawer e o Drawer de Clientes da
+  Grand Brasil passam a `min(80rem, 100% - 2rem)` de largura quando o painel de assistência do
+  recurso está aberto. Nessa largura não sobra lado livre para o painel do Copilot, e nenhuma das
+  opções da decisão 5 da seção 9 evita a sobreposição; a pessoa já tem, ali, uma conversa sobre o
+  recurso.
+- **Drawer à direita com o painel fechado.** O FAB fica sobre o canto do rodapé, onde ficam as ações
+  principais, alinhadas à direita.
+- **Dialog centralizado.** A `64rem`, o painel cobre cerca de `12rem` de um Dialog de `32rem`. Numa
+  tela de `90rem`, os dois cabem lado a lado.
+
+O Opus não desloca nem redimensiona modais por causa da camada nesta versão. Ele publica
+`data-modal` e `data-modal-side` no hospedeiro para que o consumidor reposicione o que precisar. A
+resposta da Grand Brasil está na decisão 5 da seção 9.
+
+### 8. A materialização escolhida
+
+Esta seção pode ser trocada sem mudar a API pública. A decisão é **manter o modo modal do Radix e
+abrir exceções nas bordas**, com a reserva descrita no fim desta seção se o protótipo reprovar,
+todas ligadas e desligadas pela regra da seção 6:
+
+- **Pertença decidida no aperto do ponteiro.** O Dialog fecha só quando o clique se completa: no
+  aperto, o Radix guarda o evento e registra um ouvinte de `click` no documento; o handler
+  `onPointerDownOutside` recebe o evento do aperto. Até lá, o elemento apertado pode ter sumido. O
+  FAB some no próprio clique, assim como o botão de fechar o painel e os itens de um popover, e o
+  React 19 aplica essas mudanças numa microtarefa que roda antes do ouvinte do Radix. Perguntar ao
+  DOM, no fim do clique, se o alvo está dentro do hospedeiro daria “não”, e o modal fecharia. Por
+  isso o hospedeiro registra, em fase de captura, cada aperto que começa nele (num `WeakSet` de
+  eventos), e o `DialogContent` e o `DrawerContent` compõem `onPointerDownOutside` e
+  `onInteractOutside` consultando esse registro pelo `detail.originalEvent`. A isenção da camada
+  vem primeiro na composição e interrompe a cadeia, como o `DismissableLayer.Branch` do Radix: um
+  evento nascido na camada é de dentro do modal e não chega ao handler do consumidor. Para os
+  demais eventos, a ordem é handler do consumidor e, por fim, `closeDisabled`. O mesmo vale para o
+  `onEscapeKeyDown`, para que um `preventDefault` do consumidor não engula o Esc que pertence à
+  camada. Como a composição mora nesses dois componentes, os patterns ganham a isenção sem mudança.
+- **Esc.** O `onEscapeKeyDown` composto consulta onde a pessoa está (seção 5). Na camada, chama
+  `preventDefault` e o `onEscapeKeyDown` da camada. Sem modal, a própria `FloatingLayer` ouve o Esc
+  no documento, em borbulha, e usa o mesmo rastreador de onde a pessoa está. Ouvir só no
+  hospedeiro não bastaria: depois de um clique no texto de uma resposta, o foco fica no `body`, e o
+  evento de teclado nunca passa pelo hospedeiro. Esse ouvinte ignora eventos já marcados com
+  `defaultPrevented`, que um `DismissableLayer` de dentro da camada ou a composição do modal já
+  trataram. Assim, o `onEscapeKeyDown` é chamado uma única vez por tecla, com ou sem modal.
+- **Ponteiro e empilhamento:** o hospedeiro declara seus próprios `pointer-events` e fica na faixa
+  da camada.
+- **Foco e rolagem, num único ouvinte no `body`.** A trava do Radix ouve `focusin` e `focusout`, e o
+  `react-remove-scroll` ouve `wheel` e `touchmove`, todos no documento, em fase de borbulha. O
+  registro mantém um ouvinte nativo no `body`, também em borbulha, que impede que chegue ao
+  documento: o `focusin` cujo alvo está no hospedeiro; o `focusout` cujo alvo ou destino está no
+  hospedeiro; e o `wheel` e o `touchmove` cujo alvo está no hospedeiro. A trava não vê a passagem e
+  não puxa o foco de volta; todo o resto da trava continua sendo do Radix. O ouvinte fica no `body`,
+  e não no conteúdo do modal, porque o React escuta eventos no contêiner de cada portal, que para os
+  modais é o próprio `body`. Parar a propagação antes dele engoliria o `onBlur` e o `onFocus` dos
+  campos do modal. No mesmo nó, o ouvinte do React continua rodando.
+- **Rolagem encadeada no toque.** Com o `touchmove` liberado, um arrasto que chegue ao fim da área
+  rolável do painel pode passar a rolar a página. As áreas roláveis da camada, como o histórico da
+  conversa dentro do painel, usam `overscroll-behavior: contain`; a propriedade só age no contêiner
+  que rola, então aplicá-la é responsabilidade do consumidor, e a documentação da camada diz isso. A
+  ADR 0017 trata a interface como desktop, mas a regra é barata.
+- **Leitor de tela.** O hospedeiro carrega `aria-live="off"` o tempo todo, exceto enquanto um modal
+  de resposta obrigatória ou interno à camada está no topo. É o valor padrão do atributo: não
+  transforma a camada numa região que anuncia mudanças, e regiões `aria-live` de dentro dela mantêm
+  o próprio comportamento. Mas o `hideOthers` preserva todo elemento com `aria-live`, a cada
+  chamada, e não desce para dentro dele. A camada fica visível diante do `Dialog`, do `Drawer` e de
+  um menu modal aberto sobre eles, e as regiões `aria-live` do painel não fazem o `hideOthers`
+  esconder partes dele. Quando um modal que suspende as exceções entra no topo, o registro retira o
+  atributo num efeito de layout, que roda antes do `hideOthers` desse modal. Ele devolve o atributo,
+  também num efeito de layout, quando esse modal **sai do topo**, isto é, quando fecha, e não quando
+  desmonta. A diferença importa: o `Presence` do Radix mantém o modal montado durante a animação de
+  saída. Se uma confirmação do `DialogHost` abre um Dialog na resposta, o `hideOthers` do Dialog
+  roda com a confirmação ainda montada; com o atributo devolvido só na desmontagem, o hospedeiro
+  seria contado de novo e ficaria escondido durante todo o Dialog. Limite conhecido: enquanto esse
+  modal está aberto, as regiões `aria-live` de dentro do painel continuam audíveis, como os avisos do
+  Toaster.
+
+Efeitos colaterais aceitos:
+
+- Enquanto as exceções estão ativas, ouvintes de foco no documento não veem o foco entrar na camada
+  nem andar dentro dela. Um popover aberto dentro do modal não fecha quando o foco vai para a
+  camada. Um popover aberto dentro da camada não fecha quando o foco passa para outro ponto da
+  camada; sem modal aberto, ele fecha. O comportamento desses popovers muda, portanto, conforme haja
+  ou não um modal de trabalho aberto.
+- Modais que não entram na pilha do Opus, como um `Dialog` do Radix usado diretamente ou o de uma
+  biblioteca de terceiros, não escondem mais a camada do leitor de tela, porque o `aria-live` do
+  hospedeiro a protege de qualquer `hideOthers`. A trava e o véu deles continuam valendo.
+
+Essas exceções dependem de detalhes de implementação do Radix, do React, do `react-remove-scroll` e
+do `aria-hidden`: a fase dos ouvintes, o contêiner onde o React escuta, o momento do fechamento por
+clique e a preservação de `[aria-live]`. Testes de premissa (seção “Verificação”) falham se uma
+atualização mudar algum desses detalhes. Se a preservação de `[aria-live]` deixar de valer, a reserva
+para o leitor de tela é um `MutationObserver` que reaplica a visibilidade do hospedeiro enquanto o
+topo da pilha for um modal de trabalho.
+
+**Alternativa de reserva para o conjunto:** usar o `Dialog` do Radix no modo não modal e fazer o Opus
+refazer a trava, o véu, a trava de rolagem, o `aria-hidden` e a pilha de modais, com `aria-hidden` e
+`react-remove-scroll` como dependências diretas. A API pública é a mesma.
+
+A escolha entre as duas se fecha num protótipo em navegador real, com os critérios de teclado da
+seção “Verificação”, antes de o código entrar no pacote (decisão 1 da seção 9).
+
+**Nota de implementação (2026-10-03).** O protótipo da blindagem passou nos critérios de teclado em
+Chromium (`tests/browser/floating-layer-focus.test.tsx`), e a reserva não foi usada. A implementação
+fechou cinco pontos que esta seção deixava em aberto, sem mudar a API pública:
+
+- **Ciclo do Tab (decisão 2).** O `DialogContent` e o `DrawerContent` compõem um `onKeyDown` que,
+  com as exceções ativas e o foco no último elemento do modal do topo, leva o Tab ao primeiro
+  elemento da camada; o Shift+Tab no primeiro elemento faz o caminho inverso. O hospedeiro ouve o
+  `keydown` e faz o mesmo nas bordas da camada. Com várias camadas, o ciclo segue a ordem de
+  montagem. O laço do Radix continua valendo quando a camada não tem onde parar.
+- **Volta do foco (decisão 3).** Um `MutationObserver` em cada hospedeiro percebe quando o último
+  elemento focado da camada sai do DOM com o foco no `body`. Uma tarefa depois, se o foco continuar
+  no `body`, o registro o devolve ao último elemento focado fora das camadas, quando ele ainda está
+  no modal do topo, ou ao primeiro elemento focável do modal. A espera de uma tarefa deixa o
+  consumidor levar o foco a outro elemento da camada, como a caixa de mensagem que substitui o FAB.
+- **Estado de aberto.** `Dialog` e `Drawer` passam a controlar o estado de aberto e o entregam ao
+  Radix sempre como controlado, porque a pilha precisa saber quando o modal fecha, e não quando o
+  `Presence` o desmonta. Um modal com `modal={false}` não entra na pilha.
+- **Faixa da resposta obrigatória.** Popover, Menu e Tooltip abertos de dentro de um alerta herdam a
+  faixa dele, pelo mesmo contexto que leva os portais ao hospedeiro; sem isso, ficariam abaixo do
+  véu do próprio alerta. A escala está em `docs/stacking-scale.md`.
+- **Alerta aberto de dentro da camada.** Vai para o hospedeiro, como qualquer modal aberto de lá, e
+  entra na pilha como resposta obrigatória. As duas marcas suspendem as exceções; a subárvore dele
+  é marcada como modal e nunca conta como camada.
+
+**Nota de revisão (2026-10-03).** Duas revisões independentes da implementação apontaram bordas que
+a seção 6 e as decisões 3 e 4 não cobriam por completo. A correção refina a regra sem mudar a API:
+
+- **Suspensão em qualquer posição da pilha.** A seção 6 diz que as exceções valem só com um modal de
+  trabalho no topo. Um Dialog aberto de dentro de um alerta fica no topo como modal de trabalho,
+  mas o alerta continua aberto e cobrindo a camada. As exceções passam a exigir também que nenhum
+  modal de resposta obrigatória ou interno à camada esteja aberto, em qualquer posição da pilha; o
+  `aria-live` do hospedeiro segue a mesma regra.
+- **Modal que fecha com a pessoa na camada.** O Radix leva o foco ao gatilho do modal que fecha.
+  Com o foco numa camada, o Dialog e o Drawer cancelam essa volta, e o foco fica onde a pessoa está
+  digitando. É comportamento novo, simétrico à decisão 3.
+- **Camada que sai com o foco dentro.** Desmontar a `FloatingLayer` com o foco nela e um modal de
+  trabalho aberto devolve o foco ao modal, pela mesma regra da decisão 3.
+- **Aperto num painel que some.** O último aperto deixa de pôr a pessoa na camada quando o filho
+  direto do hospedeiro que o recebeu sai da camada, como um painel fechado por código e trocado
+  pelo FAB. A âncora é esse filho, e não o elemento apertado: o `Markdown` do `Chat` troca todos os
+  nós da resposta a cada pedaço do streaming, e a pessoa que clicou no texto continua no painel.
+- **Portais de dentro de um modal interno à camada.** Popover, Menu e Tooltip abertos de dentro dele
+  vão para o hospedeiro como irmãos do modal e recebem a mesma marca, para nunca contar como camada.
+- **Tab nas bordas da camada.** O hospedeiro passou a decidir o Tab ouvindo o documento, em
+  borbulha, depois dos `onKeyDown` do React de dentro da camada, e respeita um `preventDefault`
+  deles.
+
+### 9. As questões que ficaram para decisão
+
+A proposta deixou sete questões para decidir antes da implementação. Em 2026-10-03, todas foram
+decididas como a proposta recomendava; cada item registra a questão, a decisão e o motivo.
+
+1. **Como materializar o foco: blindar a trava do Radix ou refazê-la.** A alternativa de empilhar
+   escopos com um `FocusScope` aninhado foi descartada (seção “As exceções que existem”).
+   *Decisão:* blindar (seção 8), porque preserva o comportamento de foco do Radix para quem não
+   usa a camada e muda pouco código. Refazer fica como reserva se o protótipo mostrar que a
+   blindagem é frágil.
+2. **Como o teclado chega à camada com um modal aberto.** Hoje o Tab dá a volta dentro do modal, e
+   nenhuma tecla leva à camada. *Decisão:* incluir a camada no ciclo do Tab: depois do último
+   elemento do modal vem a camada, e depois da camada, o primeiro elemento do modal (Shift+Tab
+   percorre o caminho inverso). Fica descobrível sem decorar atalho. Com o painel fechado, custa uma
+   parada a mais (o FAB). Um atalho como F6 foi considerado, mas os navegadores usam F6 para a barra
+   de endereço, e ainda não foi testado se a página consegue interceptá-lo.
+3. **Para onde volta o foco quando a camada some com um modal aberto**, por exemplo quando a pessoa
+   fecha o painel. *Decisão:* para o elemento do modal que tinha o foco antes de a pessoa
+   entrar na camada; se ele não existir mais, para o primeiro elemento focável do modal. Assim a
+   pessoa continua o preenchimento de onde parou. Voltar para o FAB segue o padrão de “devolver ao
+   gatilho”, mas obriga mais um Tab para retomar o formulário.
+4. **A camada convive com diálogos de resposta obrigatória?** `mode="alert"` e as confirmações do
+   `DialogHost`, como “Excluir?”, exigem uma resposta antes de qualquer outra coisa.
+   *Decisão:* não. Esses diálogos ficam acima da camada e a bloqueiam, com o véu cobrindo o
+   FAB e o painel (seção 6). O estado fica visualmente honesto (nada parece clicável sem ser) e o
+   `alert` continua no `AlertDialog` do Radix, sem migração. O custo é não poder perguntar ao
+   Copilot no meio de uma confirmação; a pessoa cancela, pergunta e repete.
+5. **O que fazer com a sobreposição** (seção 7). As opções reais são:
+   - (a) a Grand Brasil leva o painel e o FAB para o lado oposto ao do Drawer, lendo
+     `data-modal-side`;
+   - (b) a Grand Brasil encolhe o painel enquanto houver modal aberto;
+   - (c) o Opus reserva a área da camada e desloca ou estreita o modal para desviar dela;
+   - (d) aceitar a sobreposição, e a pessoa fecha o painel quando precisar ver.
+
+   *Decisão:* (a) para Drawers, porque resolve o caso mais comum sem tocar no Opus além do
+   sinal publicado. Numa tela de `64rem` com um Drawer de `56rem`, ainda sobra sobreposição; aí o
+   painel encolhe, combinando com (b). Para Dialogs centralizados, (d), porque a sobreposição só
+   aparece em telas estreitas. A opção (c) fica para quando houver um segundo consumidor.
+6. **Teste de foco em navegador real dentro do pacote.** Os testes de UI do Opus rodam em
+   `happy-dom` 15.11.7, que não reproduz foco e Tab com fidelidade, e o pacote não tem harness de
+   navegador. *Decisão:* adicionar o modo navegador do Vitest com Playwright (Chromium) só para
+   os testes de foco desta camada, rodando no gate de release. É uma dependência de desenvolvimento
+   nova e um navegador baixado na máquina. A alternativa é um roteiro manual a cada mudança, que é
+   mais barato e mais fácil de esquecer.
+   *Nota de implementação (2026-10-03):* o harness é `vitest.browser.config.ts`, executado por
+   `pnpm test:browser` e pelo gate do `release.sh`, fora do `pnpm test`. O `playwright` é fixado
+   numa versão exata, porque cada versão aponta para uma revisão do Chromium. O harness também
+   compila o tema com `tailwindcss` e `@tailwindcss/vite`, devDependencies novas: o véu, o
+   hospedeiro e os `pointer-events` dos filhos só se comportam como num app com o CSS real.
+7. **O Toaster adota a camada?** As ações dos avisos parecem não responder a clique com um modal
+   aberto. *Decisão:* sim, numa entrega separada, depois de confirmar o defeito no navegador e
+   de a camada estar publicada.
+
+## Consequências
+
+- Os patterns que usam `DialogContent` e `DrawerContent` passam a conviver com a camada sem mudança,
+  porque a regra mora nesses dois componentes.
+- Sem nenhuma `FloatingLayer` montada, o comportamento dos modais é o mesmo de hoje. A mudança é
+  aditiva e sai numa versão menor.
+- O custo está concentrado no foco e na pertença decidida no aperto do ponteiro. As exceções de
+  ponteiro e empilhamento são pequenas; rolagem e leitor de tela dependem de premissas que os testes
+  travam.
+- A API é reversível no sentido que importa: a materialização da seção 8 pode ser trocada pela de
+  reserva sem que o consumidor perceba. Remover a `FloatingLayer` depois seria uma mudança major.
+- A Grand Brasil, único consumidor hoje, adota assim:
+  - envolve o FAB e o painel do Copilot em `FloatingLayer` e passa a posicioná-los contra a
+    viewport, porque deixam de ficar dentro da moldura do shell;
+  - revisa `useDismissOnOutsidePointer`, que decide “fora” pelo `#root`; o painel sai do `#root`,
+    e o clique no véu ou no modal continua sem fechar o painel;
+  - move para o `onEscapeKeyDown` da camada qualquer tratamento de Esc do painel, por exemplo
+    fechar quando não houver texto digitado;
+  - reposiciona o painel e o FAB conforme `data-modal` e `data-modal-side` (decisão 5 da seção 9).
+- Perguntar “sobre o que está na tela” também depende de o contexto enviado ao Copilot incluir o
+  modal aberto. Hoje o contexto vem da rota. Isso é da Grand Brasil e não bloqueia esta ADR.
+- O Toaster tem o mesmo problema e pode adotar o mesmo mecanismo depois (decisão 7 da seção 9).
+- A documentação ganha `floating-layer.md`, com o caso do Copilot, e as páginas de Dialog e Drawer
+  passam a mencionar a convivência.
+
+## Alternativas consideradas
+
+### Manter o estado atual
+
+Não exige trabalho, mas contraria a decisão de produto: o Copilot fica inalcançável sempre que um
+modal está aberto.
+
+### Fechar o modal ao acionar o FAB
+
+Simples e sem risco de acessibilidade, mas descartada pelo produto: perde o que a pessoa preencheu.
+
+### Levar o Copilot para dentro do modal
+
+O Opus oferece `SurfaceAssistant`, que divide a própria superfície entre conteúdo e assistência,
+e a `Presentation` o usa quando declara assistência. A ADR 0087 da Grand Brasil usa esse mecanismo
+para as conversas sobre um recurso e mantém o Copilot global separado delas, de propósito. Levar o
+Copilot global para dentro de cada modal exigiria espaço em todo Dialog e Drawer, inclusive
+confirmações e formulários estreitos, e desfaria essa separação.
+
+### `modal={false}` em cada consumidor, com reimplementação local
+
+Cada tela ou pattern desligaria o modo modal e refaria trava, véu, rolagem e `aria-hidden`. A
+técnica é a mesma da materialização de reserva, mas espalhada: cada cópia poderia divergir, e os
+patterns precisariam de uma opção nova. Descartada em favor de concentrar a regra no Opus.
+
+### Peças internas do Radix atrás de uma API do Opus
+
+`DismissableLayer.Branch` e `FocusScope` aninhado, importados de `radix-ui/internal`. O `Branch`
+resolve só o clique e o foco “fora”, que os handlers públicos já resolvem. O `FocusScope` aninhado
+deixaria o modal sem trava e sem a volta do Tab enquanto a camada estivesse montada. Ponteiro,
+rolagem e leitor de tela continuariam sem solução, e o pacote passaria a depender de um módulo que o
+Radix não documenta.
+
+### A top layer do navegador
+
+Com `popover="manual"`, o navegador põe a camada acima de qualquer `z-index`. Isso resolve só o
+empilhamento: foco, ponteiro, rolagem e leitor de tela continuam bloqueados pelo modal. Além disso,
+nada do Opus conseguiria ficar acima da camada, o que impede a decisão 4 da seção 9.
+
+### Remover à mão o `aria-hidden` do hospedeiro
+
+Depois que o Radix esconde o resto, o Opus tiraria o atributo do hospedeiro. Não resiste ao contador
+do `hideOthers`: um menu modal aberto sobre o Dialog grava o atributo de novo e, ao fechar, não o
+remove, porque o Dialog ainda conta; a camada fica escondida até o Dialog fechar. Também não cobre
+as regiões `aria-live` de dentro do painel, que fazem o `hideOthers` esconder partes dele.
+
+### Isentar cada evento consultando o DOM no fim do clique
+
+É o uso direto de `onInteractOutside`. Falha quando o elemento clicado some no próprio clique, como
+o FAB (seção 8).
+
+## Premissas verificadas
+
+Conferidas em `@radix-ui/react-dialog` 1.1.19 e 1.1.23, `@radix-ui/react-dismissable-layer` 1.1.15
+e 1.1.19, `@radix-ui/react-focus-scope` 1.1.12 e 1.1.16, `@radix-ui/react-menu` 2.1.20, `radix-ui`
+1.6.2 e 1.6.7, `aria-hidden` 1.2.6, `react-remove-scroll` 2.7.2, `react-dom` 19.2.7 e `sonner`
+1.7.4. Onde há duas versões, a menor é a do lockfile do Opus e a maior, a da Grand Brasil; o
+comportamento descrito é o mesmo nas duas. Cada pacote do Radix tem uma única cópia instalada em
+cada repositório, o que mantém uma só pilha de escopos e um só contexto de `DismissableLayer`.
+
+- `Dialog` modal: `hideOthers(content)`; `trapFocus` e `disableOutsidePointerEvents` ligados
+  enquanto aberto; `onFocusOutside` sempre cancelado; clique com botão direito não fecha;
+  `deferPointerDownOutside` ligado; o `Overlay` envolve o `RemoveScroll` com `shards` igual ao
+  conteúdo; nenhum `aria-modal`. No modo não modal, o `Overlay` não é renderizado.
+- `AlertDialog`: força `modal: true` e cancela clique fora.
+- `DropdownMenu` e `Menu`: `modal` é `true` por padrão, e o conteúdo chama `hideOthers`.
+- `DismissableLayer`: grava `pointer-events: none` no `body`; o Esc é ouvido no documento, em
+  captura, só pelo `DismissableLayer` mais recente; com `deferPointerDownOutside`, o fechamento por
+  clique fora roda num ouvinte `click` de uso único no documento e recebe o evento do aperto;
+  clique e foco dentro de um `Branch` não contam como fora. O `Tooltip` também é um
+  `DismissableLayer`.
+- `FocusScope`: a trava ouve `focusin` e `focusout` no documento, em borbulha; montar um escopo
+  pausa o anterior, e só a desmontagem o retoma; com o escopo pausado, a volta do Tab também para.
+- `hideOthers`: aceita uma lista de elementos a manter; a cada chamada, junta a ela todo
+  `[aria-live]` e `script` do `body`, preserva o caminho até eles e não desce para dentro deles;
+  controla o atributo por contador e só o remove quando o contador volta a zero.
+- `react-remove-scroll`: ouve `wheel` e `touchmove` no documento, em borbulha; só a trava mais
+  recente age.
+- `react-dom` 19: registra os ouvintes de eventos no contêiner de cada portal; atualizações de
+  eventos discretos são aplicadas numa microtarefa.
+- `Toaster`: `section` com `aria-live="polite"` e `z-index: 999999999`; nenhuma regra de
+  `pointer-events: auto`.
+
+## Verificação
+
+- **Testes do pacote (`happy-dom`):**
+  - com Dialog, Drawer, `ActionFormDialog`, `ActionListDialog`, `Presentation` e `CommandDialog`
+    abertos, clicar na camada não fecha o modal, e clicar no véu fecha;
+  - clicar no FAB que se desmonta no próprio clique não fecha o modal;
+  - fechar o painel pelo botão de fechar dele não fecha o modal;
+  - escolher um item de um popover da camada, que fecha no clique, não fecha o modal;
+
+    Nesses três testes, o fixture desmonta o elemento clicado de forma síncrona, dentro do próprio
+    handler (`flushSync(() => setOpen(true))` no `onClick` do FAB fictício). Num evento despachado
+    por script, como o do `fireEvent` ou do `user-event`, não há microtarefa entre os ouvintes, e
+    com `act` o React só aplica a mudança no fim. Sem o `flushSync`, uma implementação que consulta
+    o DOM no fim do clique passaria no teste. Os três cenários se repetem no navegador real;
+  - Esc com o foco na camada, ou depois de clicar numa área sem foco do painel, não fecha o modal e
+    chama `onEscapeKeyDown` uma única vez; com o foco num campo do modal, fecha;
+  - sem modal aberto, clicar no texto de uma resposta e apertar Esc chama `onEscapeKeyDown` uma
+    única vez;
+
+    Nos testes de clique em área sem foco, o clique é simulado com `user-event`, que leva o foco ao
+    `body`, ou o fixture tira o foco explicitamente. Um `fireEvent` de ponteiro não move o foco no
+    `happy-dom`, e o foco ficaria no campo do modal;
+  - o `onBlur` de um campo do modal dispara quando o foco vai para a camada;
+  - o hospedeiro não tem `aria-hidden` com um modal de trabalho aberto, e o resto da página tem;
+  - o hospedeiro continua visível ao leitor de tela depois que um `Menu` abre e fecha sobre um
+    Dialog;
+  - com um `Ask` aberto no painel no momento em que o modal abre, nenhuma parte do painel recebe
+    `aria-hidden`;
+  - com `mode="alert"` ou uma confirmação do `DialogHost` aberta e depois fechada sobre um Dialog,
+    a camada fica escondida e abaixo do véu durante o alerta e volta a ficar visível depois
+    (decisão 4 da seção 9);
+  - uma confirmação do `DialogHost` cuja resposta abre um Dialog em seguida: com o Dialog aberto, a
+    camada volta a ficar visível ao leitor de tela;
+  - um Dialog aberto de dentro da camada prende o foco, fecha pelo véu e pelo Esc, e não chama o
+    `onEscapeKeyDown` da camada;
+  - com um alerta no topo, um foco programático na camada é devolvido ao alerta;
+  - roda do mouse dentro da camada não é cancelada; fora dela, continua cancelada;
+  - Popover e Tooltip abertos dentro da camada são portados para o hospedeiro;
+  - `data-modal` e `data-modal-side` acompanham abertura e fechamento, inclusive com modais
+    empilhados;
+  - sem `FloatingLayer`, os testes atuais de Dialog, Drawer e patterns continuam passando sem
+    alteração.
+- **Testes de premissa**, comportamentais, no próprio `happy-dom`: um por premissa que a
+  materialização usa. A trava do Radix devolve o foco quando o `focusin` chega ao documento e não
+  o devolve quando ele é parado no `body`; o `react-remove-scroll` cancela a roda que chega ao
+  documento; o `hideOthers` preserva `[aria-live]` em chamadas repetidas; o fechamento por clique
+  fora recebe o evento do aperto; o conteúdo do modal não tem `aria-modal`; há uma cópia única dos
+  pacotes do Radix. Se uma atualização mudar alguma delas, o teste aponta qual, antes de a
+  convivência quebrar em silêncio.
+- **Navegador real** (no harness da decisão 6 da seção 9, ou num roteiro manual executado por quem
+  implementa, com o resultado registrado na descrição da entrega), em Chrome, Safari e Firefox:
+  - abrir um `ActionFormDialog`, digitar, abrir o Copilot, perguntar, fechar o painel e encontrar o
+    texto intacto, com o foco de volta no campo;
+  - clicar na caixa de mensagem com o modal aberto e digitar sem o foco voltar ao modal;
+  - clicar no FAB, no botão de fechar o painel e num item de popover do painel sem que o modal
+    feche;
+  - Tab e Shift+Tab percorrendo o modal e a camada conforme a decisão 2 da seção 9, sem nunca parar
+    na página escondida;
+  - Esc nos dois lados, com e sem popover aberto, e depois de clicar no texto de uma resposta;
+  - VoiceOver no macOS anunciando o modal e a camada, e não a página atrás; as regiões vivas do
+    painel, como a resposta em streaming e o `Ask`, continuam anunciadas, e a camada não anuncia
+    mudanças por conta própria;
+  - Drawer sobre Drawer, Dialog sobre Drawer e confirmação do `DialogHost` sobre Drawer.
+
+  Leitores de tela do Windows, como o NVDA com o Chrome, ficam fora desta verificação por falta de
+  ambiente. É um limite declarado, não uma garantia.
+
+  *Nota (2026-10-03):* a implementação no pacote cobre Chrome pelo harness da decisão 6. Safari,
+  Firefox e VoiceOver não foram verificados: a estação onde o pacote foi construído não tem esses
+  navegadores. O roteiro manual acima fica para a adoção na Grand Brasil, executado no Mac do João
+  (Safari com VoiceOver) e no Firefox antes de a adoção chegar à `main` da Grand Brasil, com o
+  resultado registrado na entrega da adoção.
+- **Arquitetura:**
+  - todo uso de portal em `src/ui` lê o contêiner da camada;
+  - só `modal-layers.ts`, `dialog.tsx`, `drawer.tsx` e `floating-layer.tsx` aplicam as exceções;
+    nenhum pattern repassa handlers para contornar a regra;
+  - o teste de API pública passa a exigir `FloatingLayer`;
+  - o teste de numeração de ADRs continua passando.
+- **Na Grand Brasil:** um teste do shell confirma que o FAB e o painel ficam dentro de
+  `[data-slot="floating-layer"]`, e o roteiro de navegador acima roda na pilha de desenvolvimento.