70. CT1 — o CENTRO DO DESENHO dentro do alvo

Escrito em 2026-08-19. Esta seção existe porque o Rafael viu um defeito que nenhuma das 60+ guardas do projeto via — e o viu num anexo de imagem, a olho nu, num botão de 44px.

70.1 O achado, e quem o achou#

No gate v13.3 o Rafael anexou dois recortes da barra superior do tela-shell com setas vermelhas sobre o botão de menu (☰) e sobre o sino, e escreveu:

"no anexo 1, acredito que o icone nao esteja centralizado dentro da caixa, pode ver nos que apontei com a seta."

Estava certo. Medido: o desenho estava acima e à esquerda do centro geométrico do botão.

A causa era de CSS, e é banal: o botão declarava display:flex sem align-items e justify-content, ou herdava uma line-height de texto que empurrava o svg para cima dentro da caixa de linha. Cada um desses controles passava em TODAS as guardas existentes: tinha tamanho de alvo ≥44px (SC 2.5.8), tinha nome acessível (SC 4.1.2), tinha contraste (SC 1.4.11), tinha foco visível. Nenhuma delas mede onde o desenho está DENTRO da caixa.

A lição, e ela é sobre o método, não sobre CSS: um acervo com 60 guardas verdes não é um acervo medido — é um acervo medido NAQUILO QUE AS GUARDAS OLHAM. O olho do Rafael cobriu uma dimensão que a bateria inteira não cobria. Toda vez que ele apontar algo com o dedo, a resposta certa não é consertar o item: é perguntar qual RÉGUA estava faltando.

70.2 O contrato CT1#

⚠ DIVERGÊNCIA DE NOMENCLATURA, achada em 2026-08-19 (sexta parte) e declarada aqui em vez de consertada em silêncio. Esta tabela usa CT1-a/b/c para (centro nos dois eixos · dois viewports · rótulo fora), e a guarda usa CT1-a/b/c para (centro horizontal · centro vertical · o desenho cabe na caixa). São dois esquemas de nome para o mesmo contrato, e as mensagens de erro que o operador lê vêm da guarda. Canônico, a partir de agora, é o esquema DA GUARDA — porque é o que aparece no placar. Renomear a tabela exigiria reescrever as citações do §96 do MANIFESTO, e renomeação sem supersede formal é pior que divergência declarada: fica como pendência CT-P6 no §70.7.

70.3 A guarda, e os três cortes que ela precisou aprender#

validacao/guarda-centro-alvo.mjs varre a pasta (nunca uma lista), mede 189 controles de ícone em 51 arquivos e imprime 522 controles com rótulo descartados — o descarte sai no placar, porque limite que não aparece no placar é truncagem silenciosa.

A PRIMEIRA EXECUÇÃO CONDENOU 37 CONTROLES, E A MAIORIA ESTAVA CERTA. Isso não foi acidente de percurso: foi a guarda medindo a coisa errada. Os três cortes abaixo nasceram antes de qualquer artefato ser tocado — porque guarda que condena artefato correto força conserto errado, e um conserto errado num artefato estável é muito mais caro do que uma guarda que demora um dia a mais.

Depois dos cortes: 15 de 16 casos reais sobraram, e todos eram defeito de verdade.

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

Bloco CT1 acrescentado a seis moldes e um artefato feito à mão:

PLACAR: 23 PASS · 0 FAIL · 28 [n/a], a 1440px e a 390px, 189 controles medidos, 0 fora do centro, tolerância 1,00px declarada. Os 28 [n/a] são arquivos sem controle de ícone, nomeados um a um no placar.

Recorte antes/depois nos dois temas, ampliado 8×: blocos E1, E2 e E3 da folha render-audit/gate-v134/fechamento.html.

70.5 SUPERSEDE de 2026-08-19 (sexta parte) — CT-P1 e CT-P2 fechadas: nascem CT1-d e CT1-e#

O que este supersede revoga: a redação anterior do §70.5, que listava CT-P1 e CT-P2 como pendências abertas, e a afirmação implícita de que o placar 23 · 0 · 28 cobria o contrato CT1. Ele cobria um oitavo dele — uma das duas metades de tema, num dos quatro estados. A régua não mudou. O número de vezes que ela é aplicada, sim.

70.5.1 As duas cláusulas novas#

Cada estado é ASSERTADO antes de valer. A guarda pergunta ao elemento el.matches(':hover'), el.matches(':active') e document.activeElement === el. Se o estado não pegou, a medição não vira PASS nem FAIL: sai [n/a] com o motivo. Isso não é zelo — é a diferença entre medir e supor: alvo coberto por elemento opaco não recebe ponteiro, e <div role="button"> sem tabindex não recebe foco. Nos dois casos um PASS seria mentira, e um FAIL seria pior.

[n/a] de tema tem régua própria, e ela é COMPORTAMENTAL. Tema que o artefato não promete não se mede. Antes de medir escuro, a guarda calcula uma assinatura de cor — color, background-color, border-top-color e outline-color de todos os elementos, reduzidos a um hash na própria página — sob tema claro e sob tema escuro. Assinatura idêntica = o artefato não promete tema escuro → [n/a] nomeado, nunca PASS. Alternativa descartada, com o motivo: grep por [data-theme="dark"] no arquivo. Descartada porque comentário e texto de bancada casam com o regex (e há lei nesta casa contra comentário que o próprio instrumento procura), e porque um artefato pode prometer tema só por prefers-color-scheme, sem nenhum data-theme escrito. Guarda que pergunta "tem este atributo?" mede IMPLEMENTAÇÃO; esta pergunta "muda de cor?", que é o contrato.

Isenção de componente INATIVO, contada e separada de defeito. <button disabled> não recebe foco por contrato — é a mesma isenção que a SC 1.4.3 e a SC 1.4.11 dão ao componente inativo — e sai como [n/a] ISENTO. Já <div role="button"> sem tabindex que não recebe foco é defeito de teclado (SC 2.1.1) e sai com esse nome. Somar os dois na mesma linha do censo esconderia um defeito atrás de uma isenção legítima: motivo agregado esconde causa.

70.5.2 O placar, separado por tema e por estado#

Placar que não separa o que tem regra diferente mente pela média. Duas execuções idênticas em cada largura — medida que não é repetida não está verificada.

AGREGADO: 180 PASS · 0 FAIL · 228 [n/a] em cada largura · 1.484 candidatos e 1.480 medições efetivas a 1440px · 1.476 e 1.472 a 390px · 4.080 controles com rótulo descartados a 1440px e 3.896 a 390px · 367 medições casaram :focus-visible a 1440px, 365 a 390px · 0 controles fora do centro · tolerância 1,00px declarada.

Nenhum artefato foi alterado. Não havia o que consertar: o bloco CT1 escrito na quinta parte já estava certo também no tema escuro e nos três estados de interação. Isso é FATO medido, e é diferente de "provavelmente estava certo", que era o que a CT-P1 dizia.

Onde estão os [n/a], um por um — limite que não aparece no placar é truncagem silenciosa:

70.5.3 O 33º defeito de instrumento do catálogo — scroll-behavior: smooth#

Na primeira execução da guarda estendida sobre o acervo, 14 medições saíram [n/a] com o motivo "o ponteiro não alcança": os 7 button.page-btn do seed-design-system.html apareciam com centro em y = 27108 numa janela de 900px, em dois passes (claro/hover e claro/ativo).

A causa não era o artefato: era o medidor. Três arquivos do acervo declaram scroll-behavior: smooth — banco-navegacao.html, seed-design-system.html e tela-shell.html. Com rolagem suave, scrollIntoView() anima, e o retângulo lido no instante seguinte ainda é o de antes da rolagem.

A lição, e ela é geral: animation:none e transition:none NÃO cobrem scroll-behavior. Ela é uma terceira forma de animar, e tem de ser desligada por nome. Depois do conserto (html{scroll-behavior:auto!important} junto com as outras duas), as 14 medições voltaram e os passes de claro/hover e claro/ativo subiram de 182 para 189 — o mesmo número do repouso. 14 medições perdidas por defeito do medidor teriam ido para o placar como [n/a] justificado.

70.5.4 A prova de que a régua morde — render-audit/prova-ct1/#

Guarda que não encontra nada tem de ser provada capaz de encontrar alguma coisa, e guarda reescrita tem de ser provada capaz de reprovar — uma prova por cláusula. Nasceram 8 artefatos de prova, com dado sintético (um <button> de 44×44 com um quadrado turquesa de 18×18: nenhum dado de cliente, nenhum dado pessoal), cada um com um defeito plantado ou um caminho de [n/a] a disparar:

Placar de referência da pasta de prova: 40 PASS · 12 FAIL · 12 [n/a], idêntico em duas execuções, com os 4 caminhos de [n/a] disparando (2× ponteiro não produz :hover · 2× botão pressionado não produz :active · 2× isento por inativo · 2× defeito de teclado).

Ali, FAIL é o resultado desejado — é um teste de teste. Se essa pasta algum dia voltar 0 FAIL, quem quebrou foi a guarda, não o acervo. O número que importa é 12. O LEIA-ME.md da pasta é autossuficiente e explica cada artefato.

70.5.5 Decisões tomadas sem consultar o Rafael, declaradas e separadas#

Fato dele e inferência minha não se misturam no mesmo parágrafo. As duas foram para o gate visual numa seção "vete se discordar" da folha render-audit/gate-v135/fechamento.html.

70.6 Prova de INÉRCIA — a dimensão antiga tem de dar o mesmo número#

A guarda foi reescrita, e a régua (a função classifica, com os três cortes de candidatura, a caixa de conteúdo, o descarte de satélite e o recorte de 1px de leitor de tela) foi copiada sem tocar em uma vírgula. Motivo: guarda reescrita que muda de resultado na dimensão antiga não estendeu nada — trocou de assunto.

TEMA=claro ESTADO=repouso node validacao/guarda-centro-alvo.mjs
→ 23 PASS · 0 FAIL · 28 [n/a] · 189 controles de ícone · 522 com rótulo descartados

Reproduziu na primeira execução, exatamente, os mesmos números do §70.3 e do §70.4. A guarda aceita TEMA= e ESTADO= justamente para que essa prova seja repetível por quem vier depois, e não uma afirmação num registro.

Bônus da reescrita, e ele conserta um continue mudo: a versão anterior descartava em silêncio três classes de controle — invisível, minúsculo (lado < 8px) e sem conteúdo visível. Elas agora saem nomeadas e contadas no censo de descarte: a 1440px, 4.080 com rótulo · 592 invisíveis · 560 minúsculos · 48 sem conteúdo visível. continue mudo é a forma mais barata de mentir num placar — e o conserto não mexeu em PASS nem em FAIL, só fechou a conta.

70.7 Pendências que ficam#

---