49. Detalhe de registro — painel e modal

O que esta seção resolve, e por que ela demorou. A PN-P3 está aberta desde a Fase 5: todo ERP é lista → detalhe, e o nosso caminho morria na lista. A seção não foi escrita antes por um motivo declarado — não havia LEITURA VISUAL do arquétipo, só extração de valores, e a F7.2 provou caro o que isso produz (números certos, composição errada). A leitura chegou em 2026-08-15, na §13.4 do estudo-clickup-completo.md, com sete dispositivos observados: C50 modal que navega entre irmãos sem fechar, com posição no conjunto em cabeçalho fixo · C51 propriedades em grade de duas colunas · C52 campos customizados em lista com ícone de tipo e rótulo truncado · C53 ações do campo reveladas no hover · C54 corpo truncado com "Expandir" · C55 rail de seções DENTRO do modal · C56 contadores de metadado como ícone+número.

Base (3 rodadas encadeadas + rodada zero, 2026-08-15). Rodada zero — leitura visual: confirmada na §13.4 antes de qualquer spec. Regra da fase. R1 canon: Carbon dá a régua por VOLUME, não por gosto — modal quando um subconjunto pequeno é editável; se há campos suficientes para exigir rolagem, painel lateral ou página inteira; e o side panel existe para manter o usuário em contexto com a página. Fiori dá o object page (seções e subseções com navegação por âncora ou aba) e duas réguas operacionais que entraram inteiras: a paginação entre irmãos só aparece quando a lista de origem tem ao menos dois itens, e ao excluir o item corrente seleciona-se o anterior — se não sobra nada, fecha. Fiori também manda usar o mesmo layout em exibição e edição: o conteúdo não muda de lugar. R2 mercado/stack: Radix Dialog entrega os dois regimes (modal e não-modal) com controle fino de foco, o que barateia a decisão PD1 — é o mesmo primitivo. Nota de fronteira registrada: o Radix foi adquirido pela WorkOS e a cadência caiu em alguns componentes; o Base UI é hoje a camada de primitivos mais ativa, e o shadcn/ui é o consumo dominante. Não muda decisão aqui; muda o que vigiamos. R3 normas / fora do circuito: o cabeçalho fixo do C50 é risco de norma, não detalhe estético — a falha F110 do WCAG 2.2 descreve exatamente o sticky que cobre o elemento focado, e o SC 2.4.11 é AA; o conserto canônico é scroll-padding. O hover do C53 é a armadilha maior: o Spectrum corrigiu este caso em novembro de 2025 trocando visibility:hidden por opacity:0, porque visibility:hidden e display:none removem da árvore de acessibilidade e o botão deixa de ser alcançável por Tab. O "Expandir" do C54 precisa de aria-expanded + aria-controls e de rótulo que nomeie o quê.

A LACUNA QUE A PESQUISA REVELOU, e é o achado da rodada: não existe canon para troca de conteúdo DENTRO de um diálogo já aberto. Todo o corpus trata abertura e fechamento. O anúncio do nome do diálogo acontece quando o foco entra nele; trocar o texto do título com o foco parado não produz anúncio nenhum. Sem instrumento próprio, navegar entre irmãos é silencioso para leitor de tela. O PD3 é decisão nossa, declarada como tal.

Gate de 2026-08-15 (Rafael, sobre amostra A/B navegável): "modal A por padrão, e opção do modelo B caso o usuário prefira, então vamos ter as duas opções. no modelo A, deixa opção de expandir a janela depois que ela for aberta." Daí saem o PD1 (dois regimes, modal como padrão), o PD17 (dois degraus da janela) e o PD18 (alternância a partir do próprio detalhe).

49.1 Os contratos#

49.2 Anatomia#

┌─ cabeçalho FIXO (PD5) ──────────────────────────────────────────────┐
│ [↑][↓]  9/10  «chip de status»  Título do registro …   [⤢][×]       │
├──────────────────────────────────────────────────┬──────────────────┤
│ contadores de metadado (PD12)                    │  rail de seções  │
│ grade de propriedades — 1 · 2 · 3 col (PD7)      │  (PD11, âncora)  │
│ DESCRIÇÃO + [Expandir descrição] (PD10)          │   ▤              │
│ CAMPOS DO DOMÍNIO — lista, ícone de tipo,        │   ✉ ②            │
│   rótulo truncável, ações no hover/foco (PD8/PD9)│   ∿              │
│ COMENTÁRIOS                                       │                  │
└──────────────────────────────────────────────────┴──────────────────┘

Os dois hospedeiros, com a mesma anatomia:

49.3 Acessibilidade#

• O diálogo é nomeado pelo título do registro (aria-labelledby apontando para o <h2> que exibe o nome). O nome muda a cada irmão; o anúncio não vem daí, vem da live region do PD3.
• Foco entra no detalhe ao abrir, volta ao gatilho ao fechar (PD13).
• Nenhuma ação depende de hover (PD9): tudo que o mouse revela, o teclado revela por :focus-within, e o alvo tem 44px no eixo curto também — regra que este projeto já reprovou quatro vezes por medir só um dos eixos.
• Cabeçalho fixo × foco: scroll-padding-top maior que o cabeçalho (PD5, SC 2.4.11).
• Contraste: 28 pares medidos nos dois temas, 56 · 0 (contraste-f73.py). Nenhum par novo: tudo é consumo de token canônico. Um achado real da medição: a primeira versão usava border-default na fronteira dos botões, que mede 1,49 sobre branco e 2,32 no escuro — reprova o SC 1.4.11 nos dois temas. Trocado por border-interactive (3,38 e 4,50), que nasceu na v6.9 exatamente para este papel.

49.4 Estados#

49.5 Números MEDIDOS na produção do gabarito#

A spec nasce com relações; os números são medidos no artefato — método do §55.

49.6 Validação#

Escopo declarado da suite-container.mjs: ela foi escrita para os gabaritos de dado A2/A3 e cobra árvore com role=tree (ARV-01…03), que é estrutura do A2 e não do A8 — o escopo do detalhe é lista plana, e dar hierarquia à sidebar só para satisfazer um teste seria inventar estrutura para agradar instrumento. Os blocos que se aplicam (CQ container query, RF reflow) rodam com o A8 passado como alvo explícito. Isto é decisão registrada, não placar vermelho tolerado.

49.7 Pendências desta seção#

---