72. SH1 — COLISÃO, COBERTURA, CORTE e VAZAMENTO

Escrito em 2026-08-19. Fecha a pendência SH-P3, aberta havia quatro partes, que dizia: "nenhum instrumento mede COLISÃO — sobreposição de elementos irmãos dentro de uma barra que não estoura o documento. O SH-P2 foi achado por captura e olho, não por guarda."

72.1 Por que a guarda de reflow não bastava#

A suite-reflow.mjs (contrato BT7) mede se o documento estoura na largura. Mas conteúdo pode encavalar sem estourar largura nenhuma: a barra continua com 1440px, o documento não tem rolagem horizontal, e dois irmãos dentro dela estão um em cima do outro. Guarda que mede o continente não mede o conteúdo.

72.2 A base normativa — e aqui, ao contrário do HV1, ela é direta#

Consequência de alcance: colisão não é questão de gosto nem de conveniência de layout. É perda de conteúdo, e perda de conteúdo é falha normativa. Por isso SH1 reprova, não "acha".

72.3 O contrato#

Por que a SH1-d precisou nascer, e por que ela não é uma variação da SH1-c: o Rafael anexou um recorte a 390px com duas setas vermelhas sobre os botões "Anterior" e "Próximo" do tela-gantt e escreveu — "o nome dentro do botão estoura para fora, isso tem solução?" Nenhuma das três cláusulas anteriores pegava aquilo: não é colisão entre irmãos, não é texto coberto, e não é texto cortado, porque o overflow é visible e o texto fica perfeitamente legível — só está do lado de fora da caixa que deveria contê-lo. A SH1-c mede o que o recorte ESCONDE; a SH1-d mede o que a caixa NÃO SEGURA. São defeitos opostos com a mesma causa — conteúdo maior que a caixa — e um instrumento que só olhasse overflow:hidden seria estruturalmente cego para metade do problema. A fronteira visível é o corte que dá sentido à cláusula: texto que passa da caixa de um div transparente é layout normal e ninguém vê; texto que atravessa a borda de um botão salta aos olhos.

72.3-a A causa do defeito fundador: duas regras boas que, juntas, produzem uma ruim#

Medido no tela-gantt a 390px: caixa de conteúdo 50×42, texto 56×14 → vaza 6px. E a 1440px sob o espaçamento da SC 1.4.12: caixa 49×42, texto 67×14 → vaza 6px à esquerda e 12px à direita. O defeito existia nas duas larguras — ele viu na estreita.

A causa é uma armadilha clássica de flexbox, e vale escrita porque vai reaparecer:

1. display:flex dá ao item flex-shrink: 1 por padrão — o item pode encolher;
2. o min-width: auto, que normalmente protege o item de encolher abaixo do próprio conteúdo, foi substituído por min-width: 44px, que é o piso de ALVO da SC 2.5.8;
3. com 44px valendo como mínimo e o encolhimento ligado, a caixa fica menor que o texto; e como overflow é visible e "Anterior" é palavra única sem ponto de quebra, o texto sai por fora.

A lição: o piso de alvo, escrito como min-width, desligou sem querer a proteção que o flexbox dava de graça. Duas regras corretas, cada uma defensável, produziram um defeito na interseção. Nenhuma revisão de uma regra por vez encontraria isso — só a medição do resultado.

O conserto, em duas linhas: flex-wrap: wrap no pai (se a linha não couber, os botões descem) e flex: 0 0 auto nos botões (nunca encolhem abaixo do conteúdo). O alvo de 44×44 segue garantido por min-width/min-height.

Dois espaçamentos, e o placar separa os dois: padrao (o artefato como é) e 1412 (o override da SC 1.4.12: line-height: 1.5, letter-spacing: .12em, word-spacing: .16em, 2em depois de parágrafo, todos !important porque o usuário os aplica por folha de usuário). Antes desta guarda, nenhum instrumento do acervo media essa dimensão.

72.4 SETE defeitos de instrumento numerados (mais dois sem número), todos de FALSO POSITIVO, todos com fixture#

A primeira execução acusou 398 colisões, 122 textos cobertos e 304 textos cortados. Depois de sete consertos de régua — nenhum de artefato — o acervo saiu com 0 · 0 · 0 · 0 a 1440px. Falso positivo de guarda nova quase nunca é bug de código: é a régua medindo uma COISA DIFERENTE da que o contrato nomeia.

O 40º ensina uma coisa que os outros seis não ensinavam, e ela é sobre COMO se mede duas vezes. Ele só apareceu porque a segunda medição do acervo a 390px foi rodada com altura 844 em vez das 900 que todos os instrumentos desta casa usam. Rodar o mesmo comando duas vezes não é medir duas vezes — é obter o mesmo número duas vezes. Medir duas vezes é variar uma dimensão e ver se a conclusão sobrevive. A divergência bruta foi 8 FAIL a 390×844 contra 6 FAIL a 390×900, e a explicação da diferença era defeito de instrumento, não diferença de artefato. Depois do conserto as duas alturas concordam em 198 PASS · 6 FAIL, e a 844 sai com 2 [achado] a mais — o toast invisível, agora classificado pelo que ele é.

72.5 DECLARAÇÃO COM SAÍDA VERIFICADA — o mecanismo que distingue defeito de desenho#

Duas situações do acervo são legítimas e, para uma guarda que só olha pixel, idênticas a defeito:

1. o painel de chat do tela-chat SOBREPÕE a tabela de propósito. O contrato CH3 do §55 diz, com estas palavras: "o painel é PEÇA e SOBREPÕE: ele não empurra o miolo, a tela de trabalho não pode refluir toda vez que alguém pergunta alguma coisa" — e há um botão que o recolhe.
2. a régua do tela-gantt é RECORTADA por overflow:hidden e acompanha, por sincronização, a área de plotagem, que o usuário rola.

A saída não foi afrouxar a régua nem escrever uma lista de exceções à mão — lista escrita à mão mede a lista, não o acervo. Foi exigir que o artefato declare, e que a declaração nomeie a saída:

Declaração sem saída verificável NÃO isenta: reprova, com esse motivo. É o oposto de aceitar um comentário no código — comentário não tem como ser medido, e um id tem. É o mesmo princípio que a CT1 usa com justify-content: space-* e a SH1-a usa com margem negativa: guarda não discute decisão declarada — mas a decisão tem de estar declarada em algo que a máquina leia.

72.6 O que a execução tocou, e o placar#

| 6 | tela-gantt-template.html | .gt-nav ganha flex-wrap: wrap e os botões flex: 0 0 auto | SH1-d: os rótulos "Anterior" e "Próximo" vazavam 6px da borda a 390px e até 12px a 1440px sob o espaçamento da norma |

PLACAR a 1440px, com as QUATRO cláusulas: 204 PASS · 0 FAIL · 0 [n/a] — 51 arquivos × 2 temas × 2 espaçamentos · 96.000 pares de irmãos comparados · 9.826 nós de texto testados por hit-test · 9.456 caixas com fronteira visível · 0 colisões · 0 textos cobertos · 0 textos cortados · 0 textos vazando · 40 [achado], todos nomeados. A 390px: 198 PASS · 6 FAIL — os 6 são a pendência SH-P8, e SH1-d sai ZERO nas duas larguras. Este placar de 390px foi confirmado em duas alturas de janela, 900 e 844, e as duas dão o mesmo número depois do conserto do 40º defeito: 198 · 6. Os 6 são 2 de SH1-b no banco-navegacao (só no espaçamento padrao: o botão de rolagem da faixa de abas cobre a aba "Equipamentos") e 4 de SH1-c no tela-tabela (nos dois espaçamentos: main.conteudo tem caixa de 366px e conteúdo de 810px, e o rótulo "Responsável" passa 6px do recorte no espaçamento padrão e 35px sob o da norma).

72.7 Pendências#

---

---

---

---

---

*Estrutura da Fase 3 (7 blocos, reescopada em 2026-07-31 — ver seed-ds-roadmap.md): 1 — Botões ✅ v0.5 (+full-width v0.7) · 2 — Formulários ✅ 13/13 (v0.14) · 3 — Feedback e status ✅ 11/11 (v0.24) · 4 — Superfícies ✅ 7/7 (v0.32: §26–§32) · 5 — Navegação (+ ⌘K) · 6 — Dados (+ pendências: densidade ERP→mobile; barra composta EUI; selecionar-tudo indeterminate §10) · 7 — Iconografia ✅ 1/1 (§45 estável v0.47 — set canônico de 28 glifos). Pattern F6: §33 Central de Notificações ✅ estável (v0.34). Bloco 5 — Navegação ✅ FECHADO 6/6 (v0.41). Bloco 6 — Dados ✅ FECHADO 5/5 (v0.45): §40 tabela · §41 seleção · §42 toolbar · §43 lista de dados · §44 guia de integração. Componente futuro fora dos blocos: editor rich-text (F6). Fase 6 (patterns de produto e marketing), aberta em 2026-08-11: bloco 6A — §46 Shell de aplicação ✅ estável (FECHADO) → bloco 6B — §47 Página institucional ✅ estável (FECHADO 2026-08-12, MK1–MK22 em dois lotes, preview e gate únicos) → bloco 6C — §48 Painel: grade, lentes, frescor, edição direta e mapa ✅ estável (FECHADO 2026-08-13 — FASE 6 a 3/3), com PN1–PN54; oito lentes, camada visual PN21a–h, edição direta PN22–PN41 sob o SC 2.5.7, contratos do gate PN46–PN50, mapa em dois modos PN51–PN54; PN42–PN45 reservados ao 6D; dez supersedes formais em §48.8 e sete pendências em §48.9; preview v0.8 com cinco camadas verdes: 139 · 37 · 142 · 6 · 78 + gate visual do Rafael; INVERSÃO DO HERO em 2026-08-13: a âncora passa de azul-800 a turquesa-400 #11B0A0, a ação volta à família da marca e o S4 é RETIRADO — o conflito com o §3.5 de marca-seed.md deixa de existir. Segue proposta apenas a tinta da família (S6): pendência PN-P1). O preview e o gate visual do 6C são únicos, no fim. Patterns F6 já estável: §33 Central de Notificações. Fase 7 (cobertura, aberta em 2026-08-15 a partir do mapa-cobertura-ds.md): F7.1 fundação ✅ (seed-composicao.md v2.0: sete tipos de bloco, CP25–CP31, 23 gabaritos, renomeação bancada×tela) → F7.2 TELAS DE DADO — §50 agrupamento de linhas · §51 personalização de colunas · §52 árvore · §53 filtro composto, mais as extensões DT9–DT12, SL6–SL8, TD6 e LD6, todas em rascunho até o gate visual; gabaritos tela-tabela.html (A3) e tela-lista.html (A2). F7.3 REGISTRO — §49 Detalhe de registro (PD1–PD18, gabarito A8 tela-detalhe.html, fecha a PN-P3) e §55 Chat (CH1–CH14, arquétipo A23) — primeira spec do projeto escrita a partir de LEITURA VISUAL do produto de referência (§13 do estudo-clickup-completo.md, dispositivos C41–C49) em vez de extração de valores. As sete fases e o inventário de cobertura vivem no mapa-cobertura-ds.md. F7.5 COBERTURA DE CONTROLES: §59 valor de domínio · §60 escolha segmentada e múltipla (estável) · §61 data, intervalo e hora · §62 seletor de pessoa (bancada banco-pessoa.html, 44 · 0 · 1) · §63 prioridade e escalas ordinais · §64 bancada e tema — BT1–BT6, transversais.

---