49. Detalhe de registro — painel e modal

Em uma frase: Três regimes por VOLUME — modal (padrão), painel lateral e página inteira —, cabeçalho fixo, ausência de valor sempre em travessão, e URL própria.

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.

(decisão registrada — ver Histórico da seção)

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  │
│ AÇÕES DO REGISTRO — 1 primário (PD20)            │  (PD11, âncora)  │
│ grade de propriedades — 1 · 2 · 3 col (PD7)      │                  │
│ 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#

49.8 Decisões da folha de 2026-10-10 (PD20–PD24) — o que cada uma fechou#

A folha de perguntas de 2026-10-10 (P12, "a, a, a" = "aplicar a recomendação da sessão nas três folhas v3") trouxe cinco perguntas do detalhe, todas respondidas pela opção recomendada. Fecham: PD-P5 (PD20) · PD-P6 (PD21) · PD-P7 (PD22, a forma; as medidas seguem a medir) · PD-P8 (PD23) · PD-P9 (PD24). O gabarito tela-detalhe v0.6 exerce o PD20, o PD21, o PD23 e o PD24 (gerador gen-tela-detalhe.py; seletores .acoes-reg, .prop .acoes, .marca-estado, .secao-ajuda, .rot--trunca + .balao); o PD22 fica só no canon.

49.9 O regime painel segue o §31.4 — SH-P62 e SH-P63 (leva 45, folha 11)#

O painel lateral do PD1 deixa de ter largura fixa (460 px; 400 px com contêiner ≤ 1100 — os números da §49.5 e do PD9 ficam como registro da época) e deixa de empurrar sem piso: segue a regra do painel lateral à direita do §31.4 (PL1–PL9). Medido em 2026-10-24 (Chrome, dois temas): a 1440 px a lista ia de 1062 a 590 px e agora vai a 640 (painel de 410, empurrando); a 1100 px ia a 310 e agora fica com 722 (o painel de 420 sobrepõe de cara); a 390 px o painel substitui a lista, como antes. O painel ganha a borda de arraste (PL5) e o botão Ampliar (PL6), que só aparece no regime painel — no modal seguem os dois degraus do PD17. Fecha a SH-P63.