69. Auditoria transversal de CONSUMIDOR — regras transversais

O que esta seção resolve, para quem a lê sem ter visto a conversa que a gerou. Este sistema tem blocos canônicos — o artefato que DEFINE um componente — e consumidores — o artefato que o USA. Até 2026-08-17, nenhuma guarda do acervo comparava consumidor com canônico: as suítes medem um artefato contra um contrato; nenhuma media um artefato contra outro. A consequência tem data, nome e número: o bloco de assinatura corporativa (sub-bloco EA de seed-email.md) foi corrigido em 2026-08-14 — o cargo passou de "Diretor" para "CEO", o telefone sintético virou o real e nasceu um campo de endereço. O consumidor en-comercial-amostra.html guardou a versão anterior até 2026-08-17, quando o olho do Rafael pegou. Nem a suite-email (que valida marcação) nem o contraste-email (que valida cor) sabem qual é a versão corrente do bloco EA. Isso virou a pendência EA-P1. As pendências SI-P4 (telas desenham entidade sem consumir o §65) e IL-P2 (a grade do §48 tem editor próprio em vez do §67) são a mesma classe entrando por outro lado. Esta seção nasce para as três, e o instrumento é validacao/auditoria-consumidor.mjs.

---

69.1 O RITO de três rodadas — a régua não era óbvia, e a intuição estava errada#

R1 · CANON (W3C / WAI). A WCAG 2.2, requisito de conformidade 5.2.2 "Full pages", diz literalmente: "Conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded." E o argumento de Hidde de Vries, em "Can components conform to WCAG?", fecha o raciocínio: um componente não conforma isoladamente, porque customização, combinação e contexto transcendem o componente — a responsabilidade é da página entregue. Consequência direta: o objeto de medida é o CONSUMIDOR, não o bloco canônico. Canônico consertado com consumidor velho não é "quase conforme": é uma página que reprova. Daí o alvo ser de PASTA e a varredura partir do consumidor.

R2 · MERCADO / STACK. Existem duas famílias de prática, e nenhuma resolve o caso desta casa:

Fronteira declarada: o mercado não tem instrumento para "cópia colada de bloco canônico dentro de artefato HTML". Este é próprio, e dizer o contrário seria emprestar autoridade que não existe.

R3 · NORMAS. EN 301 549 V3.2.1, cláusula 9.0: "Requirements in clause 9 apply to web pages (as defined in clause 3.1)", e web page é "non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering". Mesma conclusão da R1 por outro caminho: a unidade de obrigação é o recurso entregue. E a Nota 3 da mesma cláusula dá o respaldo normativo ao veredito [n/a]: se o recurso não existe na página, o requisito não se aplica. Consumidor que legitimamente não tem o bloco declara [n/a] — não reprova, e não desaparece do placar.

---

69.2 A decisão de desenho, com as alternativas descartadas#

ALTERNATIVA A — diff textual do bloco. DESCARTADA. Ela condena artefato correto por construção: por regra deste projeto o molde carrega sentinela de campo e a amostra carrega o valor real, porque a amostra é a referência visual do gate. Um diff textual acusaria 100% das amostras. É a forma mais caseira de cometer "guarda que condena artefato correto força conserto errado".

ALTERNATIVA B — diff visual. DESCARTADA como instrumento primário, pelo motivo da R2: devolve lista, não veredito. Não é inútil — é complementar, e quem a executa é a folha de captura no gate.

ALTERNATIVA C — comparação ESTRUTURAL por CAMPO DECLARADO, com REGIME POR CAMPO. ESCOLHIDA. Cada bloco canônico declara seus campos, e cada campo declara como se compara:

O regime muda por tipo de arquivo (molde vs. amostra), e é essa peça que faz a alternativa C funcionar onde a A falha. A normalização resolve entidades HTML (· = ·), colapsa espaço em branco e compara style por declaração ordenada, nunca por string — ordem de declaração de CSS não é desvio, e comparar string produziria FAIL por formatação.

E a segunda decisão: TRÊS CLASSES DE CONSUMO, porque são TRÊS PERGUNTAS.

A classe AC-VERSÃO nasceu do §81.3 do MANIFESTO, onde sete lugares em dois documentos declaravam versão de bancada que nenhum artefato tinha — invisível a todas as guardas do acervo, porque nenhuma delas lê o documento. Ela cobra o documento e nunca o artefato: o artefato é a coisa; o documento é o registro da coisa.

Fronteira da v0.1, declarada: mede estrutura e texto, em jsdom. Não mede pixel — pixel é trabalho de contraste-composicao.mjs e render-promocao.mjs. E não mede a correção do próprio canônico: ela mede concordância entre consumidor e canônico. Canônico errado com consumidor fiel passa — e é por isso que esta guarda soma às suítes em vez de substituí-las.

---

69.3 Os contratos AC1–AC4, e o que cada um MEDIU#

Placar de 2026-08-17: 7 PASS · 0 FAIL · 5 [achado] · 12 [n/a].

AC2 — a premissa da SI-P4 estava PARCIALMENTE errada, e a medição corrigiu duas coisas#

Primeira correção: o culpado tem nome, e são QUATRO telas, não três. A SI-P4 dizia "tela-shell, tela-lista e tela-detalhe desenham entidade sem consumir este §65". Medido: o componente que reimplementa o §65 é o .sigla — 24×24px, raio 6px, com svg de 14×14px dentro —, e ele existe em tela-shell, tela-lista, tela-detalhe E tela-tabela. É a mesma correção que a SG-P1 fez ao §60 quando achou "seis controles em quatro arquivos, não três em três": a lista escrita antes da medição erra na contagem e no endereço.

Segunda correção, e ela salva um artefato correto de conserto errado: o .ent das telas — 12×12px, raio --seed-radius-1, aria-hidden, SEM glifo — não é o quadrado do §65. É um ponto de cor decorativo em item de filtro. Uma guarda que dissesse "todo consumidor de --seed-entity-N deve ser um .quad" condenaria 14 elementos corretos em três telas e forçaria pôr glifo onde ninguém pediu. O §65 é cor + glifo; o ponto é só cor. São dois componentes, não um bem-feito e um mal-feito.

ACHADO NOVO, que não estava em nenhuma pendência — vira PS-P5. O .mini-avatar de tela-lista e tela-tabela é círculo de 26px com as iniciais da pessoa (medido: MA, FB, HS, CA, AV, PB) e se pinta com --seed-entity-N / -ink, isto é, com as seis posições de ENTIDADE do CP23. Mas o §62 (PS-P3) fechou a cor de iniciais de pessoa numa paleta própria e enumerada de oito pares de primitivas de rampa (turquesa-100/900, turquesa-200/900, amarelo-100/900, amarelo-200/900, azul-100/900, azul-200/900, cinza-100/900, cinza-200/900), medida nos dois temas, pior par 9,33 contra piso 4,50. Círculo é PESSOA e quadrado é ENTIDADE — a lei de forma do §62/§65 —, então pintar pessoa com token de entidade é usar token fora do seu semântico: se a paleta de entidade mudar, os avatares de pessoa mudam com ela, e ninguém pediu isso. [achado] de fronteira, não veredito — a decisão é de desenho. Achado menor de higiene, registrado no mesmo lugar: em tela-lista a regra .mini-avatar[data-ident] existe com 0 elementos no DOM — CSS sem consumidor.

AC3 — as três divergências entre a grade do §48 e o §67, medidas#

O canônico do §67 entrega o valor editável como <button class="gatilho"> com nome acessível na forma "Editar <rótulo>: <valor>", contendo o valor em elemento próprio e a affordance de lápis aria-hidden, com canal de anúncio na linha. Os cinco itens do contrato foram lidos do próprio artefato, não transcritos daqui — instrumento que copia contrato de documento mede o documento.

A grade do §48 (tela-painel.html, PN37) divergiu em três:

E um agravante medido, que a IL-P2 não conhecia: o consumidor não tem role="grid" — medido, zero ocorrências. Sem role de grade, tabindex="-1" na célula não é o padrão ARIA de grid (roving tabindex dentro de role="grid"): é foco por script sem semântica. Isso remove a única defesa plausível do <td> focável, e é dado novo para a decisão.

Escopo desta medida, declarado no próprio relatório: a grade é montada por script, então a célula não existe no DOM estático (medido: 0 células estáticas). A medida é sobre o texto do gerador. Medir o DOM aqui devolveria zero, e zero seria número plausível sobre coisa que não foi medida — o defeito de escopo que este projeto já cometeu cinco vezes.

---

69.4 A PROVA DE REPROVAÇÃO — quatro injeções, quatro quedas de placar, quatro reversões#

Regra do projeto: guarda tem de ser PROVADA capaz de reprovar. Injeta o defeito, vê o placar cair, reverte. Foram quatro, e uma delas achou um buraco na própria guarda antes de ela ser commitada.

Todas as quatro foram revertidas, e a reversão foi conferida por MD5 contra o arquivo da pasta: en-comercial-amostra.html, tela-detalhe.html e seed-componentes.md voltaram idênticos.

O que a PROVA 1 achou na primeira tentativa, e é o registro mais importante desta seção. Na primeira versão do instrumento, o campo cargo da amostra usava o regime sufixo — cobrava só que o texto terminasse em "· SEED engenharia". Com esse regime, "Diretor · SEED engenharia" PASSAVA. Ou seja: a guarda construída para a EA-P1 não pegava a EA-P1. Ela pegou o endereço ausente e deixou passar o cargo errado — exatamente metade do defeito original. Conserto de causa: para consumidor em regime amostra, os cinco campos de pessoa (nome, cargo, telefone, e-mail, endereço) passam a regime idêntico contra ea-assinatura-amostra.html. A justificativa não é gosto, está escrita no próprio artefato consertado em 2026-08-17: "o bloco abaixo agora é cópia VERBATIM de ea-assinatura-amostra.html v0.2". Se o contrato é cópia verbatim, o regime é idêntico; sufixo era um regime frouxo escolhido por medo de condenar dado variável, e o medo mediu menos do que devia. Lição de instrumento, nova nesta pasta: guarda que não é testada CONTRA O DEFEITO QUE A GEROU não está provada. Provar com um defeito qualquer não basta — o caso fundador é o teste obrigatório.

---

69.5 Dois defeitos de instrumento consertados antes de qualquer veredito#

1 · A suíte MORREU na primeira execução. O regex que lê as regras de <style> apanhava também o comentário de CSS, e o comentário do bloco de tokens — que tem chaves dentro — entrou como se fosse seletor. O querySelector recebeu isso e estourou com DOMException. Suíte que morre é pior que suíte que reprova: morte é ausência de medida disfarçada de silêncio. Conserto de causa: comentário sai antes de qualquer parse; at-rules (@media, @supports) são descartadas; e seletor inválido passa por um achaSeguro que declara que não pôde resolver, em vez de derrubar a corrida.

2 · ESCOPO por REGRA CSS — a QUINTA reincidência da mesma família neste projeto. A primeira versão tratava cada regra .sigla[data-ident="N"] como um consumidor separado e resolvia o elemento com um querySelector que devolvia o primeiro casamento. Resultado medido: o .sigla saiu classificado como "ponto decorativo" nas posições 1, 2, 3, 5 e como "REIMPLEMENTAÇÃO" na posição 4 — seis vereditos diferentes para UM componente, porque a geometria (24px, raio 6px, svg de 14px) vive na regra base .sigla { } e as regras por posição só trocam a cor. Conserto de causa: o consumidor é o COMPONENTE, não a regra. O instrumento agrupa por seletor base, funde as declarações de todas as regras daquele base (inclusive a de descendente, que é onde o glifo aparece) e classifica uma vez, olhando todos os elementos que casam.

Escopo continua sendo a variável que mais produz erro neste projeto: por posição no arquivo (8º, 14º), por texto (17º), por seletor (18º, 19º, 20º), por coordenada (22º), por região amostrada (23º) e agora por regra CSS.

---

69.6 Pendências#