48. Painel — grade, lentes, frescor, edição direta e mapa

⚠ FRONTEIRA DA PROMOÇÃO, e ela é dura. O que este estável cobre são os contratos PN1–PN54: grade, lentes, frescor, blocos de dado, edição direta, mapa. A camada visual (§48.3) é PROPOSTA, não canônico.

A ressalva se pagou em menos de 24 horas, e o registro disso é útil. A promoção foi escrita em 2026-08-13 excluindo três decisões de marca; na mesma noite o Rafael retirou o azul ("eu tinha aceitado para podermos parar com os testes") e a âncora escura virou turquesa vivo. Duas das três decisões mudaram de valor ou saíram — e nada do estável precisou ser tocado. Se o azul tivesse entrado no canônico no dia anterior, isto seria errata em marca-seed.md, nos três gêmeos de token, no sistema de e-mail (estável) e nos 40 HTML do repositório.

Estado atual das decisões de marca: S3 revisto — a âncora é turquesa-400 #11B0A0, não mais azul-800. S4 RETIRADO — a ação volta à família da marca, e o conflito com o §3.5 de marca-seed.md deixa de existir: nada a superseder na marca. S6 (tinta da família) segue PROPOSTA, como camada alternável pelo botão "Tinta". Ver §48.8 e a pendência PN-P1 do §48.9, que encolheu na mesma proporção. Quem consumir este §48 hoje para escrever código usa a régua de ação do marca-seed.md §3.5 — que é, desde esta rodada, a MESMA do preview.

Natureza: pattern de COMPOSIÇÃO do F6, como o §33, o §46 e o §47 — nenhum componente novo nasce aqui. Consome o shell (§46), tabela (§40), lista de dados (§43), toolbar (§42), tabs (§34), os gráficos da Fase 5 e os estados de espera do Bloco 3.

Este bloco cumpre uma fronteira declarada há duas fases. O DF6 do seed-dataviz.md (Fase 5, estável desde 2026-08-09) escreveu: "dashboard/layout de painel = F6 — a F5 entrega a peça, não o painel". É esta seção.

O QUE ESTE BLOCO ENTREGA, EM TRÊS RODADAS. O 6C foi produzido em três rodadas, e o registro da ordem importa porque cada uma nasceu de um gate do Rafael sobre a anterior. Rodada 1 (2026-08-12): a grade, o comutador de visualização com pré-requisitos de dado, a gramática do frescor, a variante equipe × cliente, o consumo do movimento (PN1–PN12) e os quatro blocos de dado que não são gráfico (PN13–PN20). Rodada 2 (2026-08-13, manhã): o supersede do PN3 para oito lentes e a camada visual PN21. Rodada 3 (2026-08-13, tarde e noite): a edição direta (PN22–PN41), os contratos que o gate produziu (PN46–PN50) e a lente mapa em dois modos (PN51–PN54). Preview e gate visual são únicos, no fim.

Escopo do produto, decidido em briefing antes da pesquisa (2026-08-12): o ERP atende quatro setores — Admin, Engenharia, Comercial e Qualidade — com áreas dentro deles; a estrutura de setores e áreas e o desenho do workflow são do PROJETO DO ERP, declarados fora deste bloco pelo Rafael. O painel serve dois públicos: a equipe (prioritário) e o cliente, que terá área própria com produtos e serviços contratados, arquivos e contratos, monitoramento de usina e um sistema de indicação de leads com acompanhamento de status. O painel é fixo — o que varia é a forma de exibir a mesma informação, no padrão do ClickUp. O painel precisa poder mostrar informação em tempo real. Referências visuais: ClickUp (comutador) e a plataforma do estudo-viver-de-ia.md (KPI, ranking, progresso, camada visual) — ambas já estudadas e ancoradas; nenhuma referência externa nova.

A DISTINÇÃO QUE DEFINE O TAMANHO DO BLOCO, e ela não estava clara no briefing. O que o Rafael descreveu não é painel configurável — é comutador de visualização. Configurável é o usuário arrastar blocos e escolher o que aparece: caro, e explicitamente descartado. Comutador é a mesma informação em formatos diferentes, com a tela permanecendo fixa. Separar as duas coisas cortou o custo do bloco pela metade e é a razão de o PN1 e o PN3 coexistirem sem conflito.

Base (3 rodadas encadeadas, 2026-08-12): R1 canon interno — DF6 (esta fronteira) e DM10 (tempo real é produto); a Régua de Espera do Bloco 3 em três regimes compostos (ação · carga inicial · refresh sobre conteúdo, com delay de 1s e permanência mínima); os dois regimes de live region do §1.13 (discreto × contínuo, uma por componente); o §46 inteiro (SH2 landmarks nomeados, SH5 ativo que sobrevive ao grayscale); o DP12 (destino externo × interno); o §40 (densidade compacta medida em 33px); e a §6b do estudo-viver-de-ia.md — a auditoria que mostrou que a "camada de movimento" não era lacuna de token (existem 4 durações + 4 easings + prefers-reduced-motion desde os primitivos) e sim de consumo. R2 mercado — comutador de visualização no ClickUp, Notion e Linear: as lentes mostram os mesmos itens com filtro e layout próprios sobre a mesma fonte; trocar de lente não altera os itens; e a adequação da lente depende do dado. R3 normas — WCAG 2.2.2 (nível A): informação que se atualiza sozinha, começa automaticamente e é apresentada em paralelo com outro conteúdo exige mecanismo para pausar, parar, esconder ou controlar a frequência; painel com intervalo escolhível (30s / 5min / manual) satisfaz pelo controle de frequência. Base adicional da rodada 3 (edição direta): WCAG 2.2, SC 2.5.7 Dragging Movements (AA) — toda funcionalidade que usa arrasto tem de ter caminho de ponteiro único alternativo; e a documentação do ClickUp sobre gantt × timeline (ver PN3c). Consolidados aprovados pelo Rafael em 2026-08-12 e 2026-08-13.

48.1 Decisões estruturais · PN1–PN12#

48.2 Blocos de dado que não são gráfico · PN13–PN20#

Escrito em 2026-08-12. Estes quatro blocos — KPI, ranking, progresso e timeline — são os buracos vermelhos que o censo de lacunas do estudo-viver-de-ia.md (§6) encontrou e que a auditoria de impacto do marco da Fase 5 (§6b daquele arquivo) classificou como aditivos: nenhum exige supersede em algo estável. O achado estrutural do censo foi que os buracos não eram gráficos — eram componentes de dado que não são gráficos, uma classe intermediária sem dono entre o Bloco 6 (dados) e o DG (gráficos core). É esta seção.

Três dos quatro são INVÓLUCRO, não desenho — e isso está medido, não suposto: o DG16 já especifica a gramática do cartão-KPI, e o DG15 mais o DG17 já especificam a barra de ranking e o caso de uso dela. O DS promove o que já existe; inventa só onde havia vazio de verdade (timeline).

Base adicional deste lote (R2/R3, 2026-08-12): APG do W3C sobre propriedades de faixa (aria-valuenow, aria-valuemin, aria-valuemax, aria-valuetext); documentação do MDN sobre o papel progressbar e o efeito dele sobre os descendentes; a distinção normativa entre progress (conclusão de tarefa) e meter (quantidade escalar em faixa conhecida); e a orientação de anunciar progresso em marcos, não a cada ponto percentual.

Registro de honestidade: o KPI, o ranking e o progresso já tinham gramática escrita no DG15, DG16 e DG17 — esta seção entrega o invólucro. Só a timeline é desenho novo. Dizer isso importa porque a impressão de que um bloco "criou quatro componentes" é falsa, e quem ler daqui a um ano precisa saber onde procurar a regra de origem.

48.3 Camada visual · PN21a–PN21h#

Origem: pedido explícito do Rafael em 2026-08-13 — as técnicas do estudo-viver-de-ia.md estavam entendidas e não estavam refletidas no resultado. Todos os valores abaixo são os medidos na §9.4 e na §2 daquele estudo ou medidos no gate desta rodada, nunca impressão de olho. A adaptação preserva as leis SEED: paleta 2018 intocada (a monocromia navy do estudo, catalogada lá como D1, segue rejeitada), gráfico com anatomia acessível (D2), regra do dourado e variante -stroke continuam valendo por cima.

Fronteira desta camada: a camada visual inteira vale no preview e não é canônica. Depois da inversão do hero (abaixo), restou uma decisão de marca em aberto — a tinta da família (S6), que vive como camada alternável pelo botão "Tinta". O tom da âncora (S3) e a régua de ação (S4 retirado) deixaram de ser conflito: a ação voltou para a família turquesa, que é onde o marca-seed.md §3.5 sempre a colocou. Ver PN-P1 em §48.9.

SUPERSEDE DA ÂNCORA — o azul sai, entra o turquesa vivo (2026-08-13, noite)#

Origem, nas palavras do Rafael: "a questão do azul eu tinha aceitado para podermos parar com os testes, pois não estava acertando. Retome as cores da SEED. Aquela caixa no topo que está azul quero que use um turquesa com cor viva, não pode ser escura nem cinza, senão fica muito escuro e parece velório." E a instrução de método que destravou a solução: "veja como o estudo do Viver de IA soluciona isso."

A RESPOSTA ESTAVA NO ESTUDO, e eu não a tinha lido assim. estudo-viver-de-ia.md §9.2 (medição do código da plataforma): --primary: 173 100% 46% = #00EBCF. A primária deles não é o navy dos prints — é um turquesa vivo, a 1,1° de matiz do nosso turquesa-300 e a 0,9° do turquesa-600. O navy é superfície de tema escuro; o acento é turquesa. A §9.2 diz textualmente: "o sistema é superfície quase-preta + acento turquesa — que é, essencialmente, o território do nosso dark mode."

O erro de leitura que isso expôs: nas duas rodadas anteriores eu copiei a superfície deles (escuro) e deixei o nosso turquesa como enfeite. Para uma marca cujo primitivo é turquesa, é o inverso do certo. A inversão: o turquesa é a SUPERFÍCIE de ênfase, e a tinta é escura da própria família. E o "vivo" que o Rafael pedia não depende de escuro — vem de três mecanismos que o próprio §8 do estudo nomeia: P1 (varredura de 4–6 pontos de luminância dentro do próprio matiz), P2 (sombra em rampa + anel) e P4 (uma âncora por página contra branco). Os três funcionam sobre superfície clara.

O diagnóstico era luminância, não matiz — e é isso que explica o "velório":

	azul-800 (antes)	turquesa-400 (agora)
Luminância	6,03%	33,71% — 5,6× mais claro
Croma	0,380	0,624 — +64%
Tinta que carrega	branco 9,52	turquesa-900 4,99

Um hero a 6% de luminância é quase preto, e nenhuma quantidade de croma corrige isso.

Três consequências que a medição obrigou, e nenhuma era previsível de olho:

(a) A luz inverteu de canto. Com tinta branca, a luz apagava o texto e tinha sido empurrada para a metade vazia do hero. Com tinta escura a luz ajuda — 5,75 no ponto de luz contra 4,99 na base —, então ela volta para o canto onde o texto vive. E não existe poço: descer um degrau para turquesa-500 derrubaria a tinta a 4,20 e reprovaria. O turquesa-400 é o piso da varredura, não o meio dela. Véu de turquesa-300 a .35 → ΔL 5,84 pontos, dentro da faixa de 4–6 que o P1 mede, com croma preservado em 0,553.

(b) O anel virou obrigatório. A base contra a página branca mede 2,71 e reprova o piso de fronteira de 3,0. Anel turquesa-600 na mesma declaração da sombra (padrão PN21a) = 4,60.

(c) A tinta é ÚNICA, e a hierarquia deixa de usar cor. Baixar a tinta escura por opacidade reprova: 3,91 a .85 e 2,99 a .70. Dentro do hero há uma tinta só, e a hierarquia vem de corpo e peso — que é literalmente o que o estudo §2.1 diz: "o contraste vem de forma e peso, não de matiz". Por consequência, o itálico do sujeito perdeu a cor: sobre o turquesa vivo nenhuma cor da paleta passa AA (branco 2,71 · amarelo-200 1,90 · turquesa-100 3,36), e a marcação passa a itálico + peso 800 na mesma tinta — mecanismo que, ao contrário da cor, sobrevive ao grayscale. O amarelo sai do hero.

Ganho de estrutura que não estava no pedido: o hero passou a ter UMA face. turquesa-400 mede 6,86 contra a página escura e 5,61 contra o cartão escuro; a tinta segue em 4,99 nos dois temas. Antes, azul-800 media 1,41 contra a página escura e obrigava a subir para azul-700 — duas composições para manter em sincronia. A classe de defeito "camada sem variante de tema" ficou impossível aqui, por construção, e não por disciplina.

A ação dentro do hero desceu um degrau, por decisão do Rafael no gate seguinte ("baixa pra 800"): pílula turquesa-800 #005048 — texto branco 9,37, fronteira 3,45 contra a base e 3,98 contra o ponto de luz. É troca de margem por matiz: o 900 dava 4,99 de fronteira (66% de folga sobre o piso) e o 800 dá 3,45 (15%), e em troca a pílula lê turquesa em vez de quase-preta. O 800 é o piso: turquesa-700 mede 2,33 e reprova. A pílula branca nunca foi opção — 2,71.

48.4 Edição direta · PN22–PN41#

Escrita em 2026-08-13, rodada 3. Esta seção existe porque o painel do ERP não é só leitura: o gestor reagenda uma OS arrastando a barra, reatribui puxando o cartão para outra faixa, muda o estado soltando na coluna. Sem contrato, cada tela implementaria o arrasto de um jeito e o teclado de nenhum.

A regra que unifica cinco lentes é uma só (PN33): ONDE O ITEM CAI É O VALOR DO CAMPO. Coluna do kanban = estado · faixa do tempo e da carga = responsável · dia do calendário = data · posição no gantt = datas. O que é derivado nunca se arrasta (PN22) e o mapa é leitura (PN39).

Norma que governa a seção: WCAG 2.2, SC 2.5.7 Dragging Movements (AA) — toda funcionalidade que use movimento de arrasto tem de oferecer caminho de ponteiro único alternativo. É por isso que o PN23 não é conveniência: é conformidade.

48.5 Gantt profissional · PN42–PN45 — RESERVADO, produção no bloco 6D#

Estes quatro códigos estão reservados e deliberadamente vazios. Não são omissão: são o escopo do bloco 6D, separado deste por decisão de tamanho — o 6C entrega o gantt que reagenda e encadeia; o 6D entrega o gantt que planeja.

Por que reservar em vez de renumerar: as cinco camadas de validação e o preview v0.6 já citam PN46…PN54 nos comentários e nas guardas. Renumerar para fechar o vão exigiria reescrever os quatro artefatos executáveis e invalidaria as âncoras MD5 recém-calculadas, trocando um vão documentado por um risco de deriva. O vão é intencional e está declarado aqui.

48.6 Contratos que o gate de 2026-08-13 produziu · PN46–PN50#

Estas cinco decisões não estavam previstas: nasceram do gate visual do Rafael sobre o preview em uso real. Cada uma tem o relato de origem registrado, porque o relato é a evidência.

48.7 Lente mapa · PN51–PN54#

A lente mapa tem duas perguntas diferentes por trás, e é isso que produz os dois modos: "onde estão as ordens?" (leitura, laudo, impresso) e "como eu chego lá?" (navegação em campo). Guia de ligação para o produto em mapa-base-lovable.md (a âncora deste guia MUDOU DE CAMINHO em 2026-08-13 — era validacao/, passou à raiz: a pasta validacao/ é declarada no LEIA-ME.md dela como a dos artefatos EXECUTÁVEIS, e este é documentação de entrega ao produto; ver §19-b do MANIFESTO v4.0). Recomendação aprovada pelo Rafael: MapLibre GL + provedor de tiles; Google apenas para geocodificação, se necessário.

48.8 Supersedes formais desta rodada#

Regra do projeto: todo contrato substituído recebe supersede formal, com o número que o motivou — nunca nota solta. Estes dez são os desta rodada.

48.9 Fronteiras declaradas e pendências#

Fora deste bloco, e a maior parte por decisão explícita do Rafael: quais blocos existem em cada tela e como o workflow se organiza (projeto do ERP) · a estrutura de setores e áreas — Admin, Engenharia, Comercial, Qualidade — declarada pelo Rafael como desenho do ERP · qual perfil vê o quê (regra de negócio) · quais KPIs cada tela mostra, o que entra na timeline e como o progresso é calculado (projeto do ERP) · cálculo e agregação de indicador (produto) · transporte de tempo real, websocket, persistência e resolução de conflito de edição concorrente (produto — Lovable/Supabase, fronteira do DM10) · BI exploratório ad-hoc (fora de escopo desde o DF6, revisável) · geocodificação de endereço e contratação de provedor de tiles (produto).

Ainda sem dono declarado, e não entram por decisão: os itens 🟡 do censo do estudo-viver-de-ia.md — comparação com referência fora de gráfico (semântica órfã desde o supersede do DM8), agenda/sessão/vaga, hero de identidade + stats e documento-cerimônia. Entrar sem consumidor real repetiria o erro que o §7 daquele estudo mandou evitar.

PENDÊNCIAS ABERTAS, nomeadas para não se perderem:

48.10 Os testes#

1. Nenhum par de cor novo — o painel compõe peças já medidas; a medição do bloco confere os pares em uso, e a lição do §46 e do §47 vale: compor pares medidos separadamente não garante que a combinação passe.
2. Escada de mecanismos: lente ativa por aria-current + marca visual + peso, nunca só cor; variação de KPI por seta (sinal) + cor (juízo), nunca cor sozinha (PN14b).
3. Grayscale: lente ativa, estado de frescor e severidade permanecem legíveis (DF4).
4. Regra do um: uma lente ativa por bloco · uma pergunta por bloco · UMA live region no painel inteiro (PN9/§1.13) · um itálico por título-insight (PN21e) · um hero escuro por página (PN21c).
5. Landmarks e nomes: todo bloco é section nomeada; nenhum nome repetido no painel.
6. Frescor e norma: todo bloco que se atualiza declara última leitura e estado; existe controle de frequência com opção manual (PN8, WCAG 2.2.2 nível A); atualização não move foco nem anuncia sem pedido (PN9).
7. Escopo do cliente: no modo cliente, nenhum identificador de terceiro aparece — nem em agregado. Teste documental além de visual, como o de procedência do §47.
8. Blocos de dado: nenhum KPI sem período e base de comparação (PN14) · barra de ranking com base proporcional declarada e valor numérico à vista (PN15) · nada semântico dentro do progressbar e aria-valuenow omitido quando indeterminado (PN18) · toda entrada de timeline endereçável (PN20).
9. Edição direta: todo gesto de arrasto tem caminho de ponteiro único (PN23, SC 2.5.7) · contrato de teclado idêntico em toda lente (PN24) · nada derivado tem alça (PN22) · ímã na unidade da escala (PN25) · nenhum transform no redimensionamento (PN35) · desfazer de 8s cobrindo criação e exclusão (PN28) · o item mutado é realçado e trazido à vista (PN34b).
10. Contagem honesta: a contagem acompanha filtro e mutação — criar ou excluir muda o total exibido no mesmo instante (PN40).
11. Mapa: dois modos declarados, cobertura como padrão (PN51) · estilo por token e marcador do DS (PN52) · fallback que diz o que aconteceu e nenhuma chave no artefato (PN53) · alternativa textual como conteúdo nos dois modos (PN54).
12. Convite e gesto no mesmo lugar: toda zona que convida a um gesto executa aquele gesto, e a promessa da dica é a ação que acontece (PN49) · dois gestos nunca dividem o mesmo pixel (PN41e) · ação destrutiva não mora em alvo invisível que cruza a área (PN36).

48.11 Estado da validação#

(Estado: estável. Gate visual do Rafael APROVADO em 2026-08-13 sobre o preview v0.6 — o quarto e último gate do bloco, depois das quatro camadas automatizadas. Com ele o bloco 6C FECHA e a Fase 6 vai a 3/3 blocos concluídos (6A §46 Shell · 6B §47 Página institucional · 6C §48 Painel). A promoção é dos contratos PN1–PN54; as decisões de marca S3, S4 e S6 seguem proposta — ver a ressalva no cabeçalho do §48 e a pendência PN-P1 em §48.9. Este bloco é o primeiro do projeto validado em cinco camadas, e a quinta (render-contraste.mjs) nasceu de um defeito que as outras quatro não podiam ver.)

Rodada 1 — 2026-08-12, preview v0.1 → v0.2. suite-painel.mjs 67 PASS · 0 FAIL — prova de que as guardas são reais: contra um preview com 5 defeitos deliberados (lente desabilitada em vez de oculta, frequência sem opção manual, pílula pintada pelo sinal, aria-valuemin ausente, base proporcional não declarada) ela reprova em 6; render-painel.mjs 17 PASS · 0 FAIL; contraste-painel.py 44 PASS · 0 FAIL após as correções que a própria medição exigiu. O gate visual reprovou o v0.1 e produziu o PN3b — as lentes "linha do tempo" e "calendário" desenhavam listas. Preview a v0.2, suíte a 75, render a 25; contra a versão em que as duas lentes voltam a ser lista, a suíte reprova em 6.

Rodada 2 — 2026-08-13, preview v0.3. Oito lentes (S1) e camada visual (PN21). suite-painel.mjs v2 107 PASS · 0 FAIL; prova: contra um preview com 4 defeitos plantados — gantt sem dependências, véu a 35%, dois heros, transition com duração solta — ela reprova exatamente nos 4. render-painel.mjs v2 37 PASS · 0 FAIL, medindo em Chrome real 3 conectores de dependência com extensão em pixels, 5 faixas de responsável com sub-linhas de sobreposição em tops distintos, marca de capacidade no mesmo x, excedente com largura real, contorno do mapa com bbox medido e 5 pontos dentro do viewBox. contraste-painel.py v2 70 PASS · 0 FAIL, incluindo os pares do hero escuro (branco × cinza-900 = 13,86; itálico turquesa-300 = 7,57; botão-solução = 5,11).

Rodada 3 — 2026-08-13, preview v0.5 → v0.6. Cinco camadas, todas verdes, todas re-executadas contra o artefato final:

Camada nova desta rodada, e a razão dela: o render-contraste.mjs nasceu de uma lição medida — contraste de TOKEN não substitui contraste de COMPOSIÇÃO. Os pares do contraste-painel.py estavam todos verdes enquanto, no tema escuro, a ação primária em azul-800 media 1,48 de superfície contra o cartão (sumia) e a secundária tinha texto azul-800 sobre cartão escuro (1,48 — ilegível). Nenhum par de token estava errado; a combinação estava. A camada varre todo texto sobre superfície opaca nos dois temas e reporta o pior caso: hoje 5,56 em button.

Rodada 4 — 2026-08-13 (noite), preview v0.6 → v0.7 → v0.8. A inversão do hero. Cinco camadas re-executadas contra o v0.8 final: suite-painel.mjs 139 PASS · 0 FAIL (era 133; entram NV-01, PN21-05c/05d/05e/05f/05g) · render-painel.mjs 37 · 0 · render-edicao.mjs 142 · 0 · render-contraste.mjs 6 · 0 · contraste-painel.py 78 · 0 (era 70; entram PC-H5b, PC-H6…PC-H11). Nenhum artefato canônico foi tocado — cinco arquivos de preview e validação, e nenhum dos 40 HTML do repositório.

DEFEITO REAL DA RODADA, e quem o pegou foi a quinta camada: TOKEN FANTASMA. Na primeira execução após a inversão, o render-contraste.mjs reprovou 15 textos com razão 1,0–1,26, incluindo branco sobre branco. Causa: o molde passou a consumir turquesa-400/600/700 e a lista PRIMITIVOS do gen-painel.py ainda era a da era do azul — e variável CSS indefinida é valor inválido, então o fundo simplesmente não pintou. É a classe NV-01 do §47 (nascida quando a command palette abriu transparente), que tinha detector na suíte de navegação e faltava nesta. Corrigido na causa e detector criado aqui: NV-01 — todo var(--seed-*) consumido tem definição no bloco de tokens. Pega na suíte jsdom, antes de qualquer render. Lição de método: guarda genérica criada num bloco não se propaga sozinha para os outros — quando uma classe de defeito ganha detector, o detector precisa ser levado para toda suíte que possa sofrer dela.

Errata E-6C-01 (2026-08-13, achado na conferência de ambiente): título e selo declaravam versões diferentes. O <title> do preview dizia "preview v0.3" e o selo na tela dizia "preview v0.5" — duas declarações de versão no mesmo arquivo, discordando. A guarda HIG-03 passava verde porque media apenas presença de versão no título. O defeito importa porque o título da aba é o primeiro sinal de arquivo fresco — três relatos de "não funciona" nesta sessão foram cache, e um título que mente cega justamente o instrumento usado para detectar cache. Correção estrutural, não sintomática: a versão passa a ter fonte única (constante VERSAO_PREVIEW no gen-painel.py), consumida por dois marcadores do molde (@@VERSAO_TITULO@@ no título, @@VERSAO@@ no selo, este com data e hora) — divergir deixa de ser possível por construção. Preview bumpado a v0.6 porque o artefato corrigido tem de ser distinguível do defeituoso na tela. Guarda de regressão permanente, creditada ao Rafael: HIG-06 — título e selo declaram a MESMA versão; contra um artefato com a versão do título plantada de volta em v0.3, a suíte reprova em exatamente 1, e a mensagem nomeia os dois valores.

Nota de determinismo, para quem for reconferir hashes: o selo carimba data e hora de geração, então regenerar o preview produz um MD5 diferente sem nenhuma mudança de comportamento — conferido: a cadeia malha-projetada.json → gen-mapa-lente.py → mapa-lente.json → gen-painel.py + painel-template.html + seed-tokens.css → seed-painel-preview.html reproduz 209.288 bytes e 3.730 linhas idênticas, com um único diff: a linha do selo. Para o preview, a âncora é o arquivo entregue, não a receita.

Registro de defeitos e lições — rodada 2 (2026-08-13). Todos viraram guarda ou nota de método. (1) RDP em anel fechado come o fecho. A simplificação Ramer–Douglas–Peucker do contorno externo do mapa, aplicada ao anel inteiro, ancorava o primeiro e o último vértice no mesmo ponto e degenerava o fecho. Conserto no gen-mapa-lente.py v2.2: dividir o anel em duas metades, simplificar cada uma e recosturar. Classe: algoritmo de polilinha aplicado a polígono sem tratar a topologia. (2) Token fantasma evitado antes do build. O hero usou --seed-tq-300, que não existe — o primitivo é --seed-turquesa-300. Pego por conferência de nome contra o CSS canônico antes da geração (classe NV-01 do §47: nome de token digitado de memória). (3) Instrumento calibrado no dado quebra com o dado. O R4-02 do render v1 exigia a menor barra do ranking entre 30% e 50% — faixa que descrevia os dados ilustrativos antigos, não a propriedade. Com dados novos (58/486 = 11,9%) reprovou sem haver defeito. Recalibrado para a propriedade: largura renderizada ≈ razão do próprio dado. Mesma família da lição do 6A (instrumento errado invalida a medição), variante temporal. (4) Dado de exercício precisa conter o caso que a guarda mede. O R7-03 (sub-linhas de sobreposição) reprovava porque nenhuma pessoa tinha duas OS sobrepostas — o mecanismo existia e a suíte estrutural passava, mas a geometria não tinha o que mostrar. A OS-2301 foi movida para colidir com a OS-2296 do mesmo responsável. Regra: todo comportamento especificado precisa de pelo menos um exemplar no dado ilustrativo. (5) --single-process do pacote @sparticuz/chromium trava element-screenshot. Os args padrão do pacote (feitos para Lambda) deadlockam o Chrome em element.screenshot() sequencial. Args enxutos (--no-sandbox) resolvem. Nota de ambiente para qualquer captura futura.

Duas correções que a medição impôs, e as duas são reaproveitáveis fora deste bloco. (1) A regra do dourado vale fora do dataviz. O ponto de "dado antigo" do frescor usava feedback-warning-solid (#F9B11C) e media 1,85 contra o cartão no tema claro. A regra do dourado da §3c veta o dourado como fill solitário — e um ponto de 8px é exatamente isso. Passou a consumir feedback-warning-text: 9,84 no claro, 10,09 no escuro. A regra nasceu no dataviz e se aplica a qualquer preenchimento pequeno e isolado. (2) Barra fina de dado consome a variante -stroke. O preenchimento cheio chart-cat-1 media 2,97 contra o trilho no claro — reprovava 3:1 por 0,03. A variante chart-cat-1-stroke existe exatamente para "linha fina e marcador pequeno, o pior caso do 1.4.11" e mede 4,23. Vale para a barra do ranking (PN15) e para a de progresso (PN17).

A correção do PN3b expôs um segundo defeito, de raiz diferente. Ao desenhar o calendário de verdade, os eventos caíram um dia antes e a grade saiu com sete larguras diferentes. Causa: new Date("2026-08-12") interpreta a string como UTC e desloca no fuso do navegador. A primeira tentativa de conserto foi somar um dia — remendo sobre o sintoma, que teria quebrado em qualquer fuso diferente. O conserto real é decompor a data em números e fazer a aritmética em UTC puro; e as colunas exigem minmax(0, 1fr), senão o conteúdo do dia empurra a coluna. Classe de defeito: remendo sobre sintoma em vez de causa — sobrevive ao teste na máquina de quem escreveu e falha na de quem usa.

E um defeito de alvo de toque que só o render pegou: o link de cada evento da timeline — justamente o que torna a entrada endereçável (PN20) — media 14px de altura. Alvo de toque ≥44px vale para ele como para qualquer controle.

LIÇÕES MEDIDAS NA RODADA 3 (2026-08-13). Catorze, e nenhuma é sobre o componente — todas são sobre COMO se descobre que algo está errado. Registradas aqui porque valem para qualquer bloco futuro. (1) Instrumento calibrado no dado quebra com o dado — faixa fixa em vez de propriedade (reincidência da lição 3 da rodada 2; virou regra). (2) Feições que se tocam, simplificadas em separado, deixam de se tocar. No mapa, a simplificação independente de cada fronteira abria vão entre municípios vizinhos. Conserto: RDP com nós de junção preservados; vão medido 4,9px → 0,000px. (3) Filtro pela grandeza errada. Contar vértices não mede extensão: a divisa BA–ES tem 6 arestas e desaparecia num filtro de complexidade. (4) Classe CSS derivada de rótulo humano quebra em silêncio. "Em campo" virava .st-Emcampo, que nunca existiu no CSS. Detector permanente criado (PN21-04d/PN21-04e): toda chave de estado emitida pelo script tem regra CSS correspondente, e a classe não é derivada do rótulo. (5) Referência órfã mata o script inteiro. getElementById para id inexistente derruba tudo abaixo dele, e a tela fica parada sem erro visível. Detectores REF-01/REF-02: todo getElementById e todo querySelector de id fixo no script têm alvo existente no documento. (6) Camada de sobrescrita de token sem variante de tema é meia implementação. A camada de tinta (S6) nasceu só com a face clara; no escuro o painel inteiro ficou ilegível. (7) Contraste de TOKEN não substitui contraste de COMPOSIÇÃO — o render-contraste.mjs nasceu disso. (8) O que nasce fora do campo de visão é lido como "não funcionou" → PN34b (realce + rolagem até o item mutado). (9) Convite que aparece onde o gesto não age é pior que convite nenhum → PN49. (10) Ação destrutiva não pode morar em alvo invisível que cruza a área → PN36 (o fio de dependência apagava por acidente ao clique simples). (11) Dois gestos não podem dividir o mesmo pixel — nó de dependência × punho; criar × panorâmica → modo explícito (PN41e). (12) viewBox e área têm de medir o mesmo, senão a camada esticada desalinha tudo (o fim do conector não coincidia com a barra dependente; guarda I-20). (13) Todo comportamento especificado precisa de um exemplar no dado ilustrativo (a lição 4 da rodada 2, confirmada duas vezes: sub-linhas de sobreposição e ordem com duas predecessoras). (14) Defeitos do INSTRUMENTO têm o mesmo peso que defeitos do artefato. Quatro medidos: coordenada de viewport em vez de rect da área · medir durante transição CSS · escolher ponto de clique sem verificar o que está sob ele · medir no sentido em que o navegador já está no fim do curso. Uma suíte errada reprova artefato bom e aprova artefato ruim — a auditoria do instrumento é parte da validação, não etapa opcional.

Nota de método da rodada 3, registrada por ordem do Rafael: duas vezes nesta sessão um lote de edições imprimiu "OK" sem que o arquivo tivesse sido salvo — o write fica no fim do script e o abort intermediário deixava tudo no meio. Regra permanente: se um lote de edições abortar, RE-EXECUTAR O LOTE INTEIRO; "OK" impresso não significa arquivo salvo, e só a leitura de volta por MD5 significa.

---

PROMOÇÃO A estável — 2026-08-16. As seções §49 a §55 foram promovidas em bloco pelo Rafael ("aprovo") após o gate visual sobre as seis telas do projeto. O gate encontrou dois defeitos reais que as cinco camadas automatizadas atravessaram, e os dois viraram guarda permanente antes da promoção: (a) no regime MODAL a lista de fundo acompanhava a navegação entre irmãos — verbatim, "está mexendo as duas janelas… era pra mexer só a que abriu sobreposta" —, o que gerou o PD19; (b) a topbar não degradava por CONTÊINER, só por viewport, e no estreitamento o rótulo da marca quebrava em duas linhas e a busca empurrava o avatar. Guardas novas: SNC-01 a SNC-03, TOP-01 a TOP-04. Nenhuma seção é promovida sem que o defeito que o gate achou tenha virado teste — é a regra que o projeto pratica desde a Fase 6.