Cabeçalho — seed-componentes.md

Arquivo canônico de componentes do design system SEED v2. Cumulativo: cresce por blocos ao longo da Fase 3 (7 blocos — estrutura completa no rodapé e no seed-ds-roadmap.md). Cada componente traz: papel, anatomia rotulada, variantes, tamanhos, estados completos, tokens de componente (camada 3), microcopy no tom SEED, acessibilidade e código duplo (HTML/CSS + React/TypeScript). Quando o site DS no Lovable existir, este conteúdo migra pra lá e este arquivo vira fonte de sincronização.

Dependências: tokens v1.2 (seed-tokens.css/.json/.md) — componentes consomem SEMANTICOS, nunca hex. Identidade: marca-seed.md v5.0. Previews validáveis: seed-componentes-preview.html (botão) · seed-formfield-preview.html · seed-feedback-preview.html (Bloco 3) · seed-superficies-preview.html (Bloco 4) · seed-cn-preview.html (§33 — pattern CN) · seed-navegacao-preview.html (Bloco 5).

Supersede: a seção "components" do seed-design-system.html v1.0 (botões com 4 variantes sem estados) fica obsoleta para botões a partir deste arquivo; o HTML segue fonte para os componentes ainda não migrados.

Data: 2026-08-18 · v1.08: o GATE VISUAL reverteu a MR-P1, e a reversão melhorou o número. O Rafael vetou a tinta escura sobre a marca — "ter o turquesa com o texto Branco dentro no tema claro é algo visualmente bonito" — e com o branco fixado a pergunta passou a ser a SUPERFÍCIE: branco sobre turquesa-400 mede 2,71, sobre turquesa-600 mede 4,60. Nascem surface-brand-strong e text-on-brand-strong (gêmeos v1.17); a marca chapada #11B0A0 fica reservada para área SEM texto. A referência de mercado foi MEDIDA e reprova: o botão primário do ClickUp mede 3,07. Fecharam também a LS-P6 (a barra de massa cobria conteúdo em 17 de 17 larguras, 177 sobreposições → 0) e a TK-P1 (seis degraus, não quatro — o placar estava cortado em 8 de 12 e me pegou mesmo declarado). Seis pendências NOVAS de artefatos nunca medidos. Detalhe no §64.16.

Data: 2026-08-18 · v1.07: a AD-P1 FECHA por pesquisa e sem gate, a isenção de componente INATIVO entra nas guardas, e a forma de PERGUNTAR muda. Instrução do Rafael: pergunta de gate vai com exemplo visual antes/depois, e escolha de solução não se pergunta — pesquisa-se e aplica-se. A AD-P1 (branco sobre o destrutivo no escuro, 2,76) fecha com token novo text-on-action-destructive — branca no claro (5,19) e vermelho-900 no escuro (5,26) —, escolhido pelo RITO: o Material Design 3 inverte a tinta de erro com o tema, o IBM Carbon não clareia o fundo de perigo; adotado o M3 por coerência com o que esta casa já faz no botão primário. Guarda MR2 com prova de reprovação pelo caso fundador. CC-P3 fechada: a SC 1.4.3 isenta componente INATIVO, e as guardas passaram a honrar a isenção imprimindo a contagem. A pergunta sobre a regeneração das nove bancadas virou medida: 0 pixels de diferença em 163.800. Detalhe completo no §64.15.

Data: 2026-08-17 · v1.06: a MR-P1 EXECUTA e o conserto é no GÊMEO outra vez, nasce e fecha a MR-P2 no tema oposto, o ANEL vaza em elemento pequeno e arredondado (25º defeito), e o acervo tem 34 artefatos, não 29. Medido: um único token de tinta servia TRÊS fundos de marca com necessidades opostas — o gêmeo de JSON descrevia esse token como "texto sobre action.primary", e ele estava sendo consumido também sobre a marca chapada e sobre a marca profunda. Branco sobre a chapada media 2,71 no CLARO (MR-P1) e tinta escura sobre a profunda media 1,45 no ESCURO (MR-P2, nova): dois defeitos simétricos, um em cada tema, da mesma causa. Conserto: três tintas, uma por fundo (gêmeos v1.15), com o botão primário mantendo exatamente a aparência de antes. Censo por pixel em 48 artefatos × 2 temas, por guarda nova de alvo de pasta: 49 textos assentam sobre a marca chapada e ZERO violam. Também nasceram e fecharam a BT-P7 (token fantasma na barra de provas de seis bancadas: o estado ligado do alternador não pintava, e nenhuma guarda tinha visto porque esse estado só existe depois do clique) e a BC-P1 (nove bancadas estavam atrás do base-bancada.css, inclusive no conserto do .vh que o §64.6 registra como feito). Detalhe completo no §64.14.

Data: 2026-08-17 · v1.05: a BT-P6 FECHA na CAUSA, a CD-P7 FECHA por DECISÃO, e nasce a MR-P1 — um número de FUNDAÇÃO que nunca existiu. A BT-P6 não era descuido do artefato: não havia semântico para "superfície de marca sutil" e o tela-chat era o ÚNICO consumo daquela primitiva em 29 artefatos — nasce --seed-surface-brand-subtle nos três gêmeos (12,79 claro · 10,40 escuro · piso 4,50) e os TRÊS FAIL do tema escuro somem. CD-P7 fechada por decisão do Rafael: os 93 não são defeito, porque o Understanding da SC 1.4.11 diz verbatim que borda não é obrigatória em controle com conteúdo visível, e consertar destruiria a escala terciário↔fantasma. MR-P1: o seed-tokens.md declarava que branco sobre --seed-surface-brand dá 3,22 e construía a regra "só ≥24px" nisso; medido por dois métodos independentes, é 2,71 — reprova até AA-large, logo branco ali não é permitido em nenhum tamanho. Decisão acatada: tinta escura. Execução pendente porque os casos no acervo não foram contados (o instrumento cobria 6 dos 29 artefatos). SI-P4, IL-P2, PS-P5 e a spec do ponto de cor decorativo: DECIDIDAS, execução pendente. Detalhe completo no §64.13.

Data: 2026-08-17 · v1.04: A CD-P7 GANHA RITO COMPLETO E VEREDITO PROPOSTO — e a rodada de NORMAS inverteu a pergunta. R1: o Understanding da SC 1.4.11 diz verbatim que "if a control has visible content (such as text or a sufficiently contrasting icon) … a border or other indication of the overall boundary of the hit area is not required" — logo botão com rótulo legível não precisa de borda a 3:1. R2: o Carbon (IBM) pratica exatamente essa fronteira — o ghost não declara borda em nenhum estado, o tertiary tem borda com token próprio porque nele a borda é o identificador. R3: em forced-colors o navegador descarta background-color, então o risco real não é "borda abaixo de 3,00" e sim "nenhuma borda nem outline declarada" — e aí está o número novo: 28 de 29 artefatos do acervo não têm nenhuma regra de botão para forced-colors (nasce CD-P9). Veredito proposto: os 93 achados não são defeito de 1.4.11, com a exceção estreita do botão cujo ÚNICO identificador é a borda (quantos são disso não foi medido — nasce CD-P10). A decisão é de gate e está acumulada no fechamento. Detalhe completo no §64.12.

Data: 2026-08-17 · v1.03: A GI2 forma 4 vira GUARDA TRANSVERSAL de alvo de PASTA — a BT-P3 FECHA na forma superseder (um instrumento, não quatro cópias) e a pasta ganha UM DEFEITO MEDIDO EM ABERTO. validacao/guarda-gi2.mjs mede 29 artefatos: 15 PASS · 1 FAIL · 35 [n/a], os [n/a] em três categorias declaradas. O FAIL é a BT-P6: tela-chat.html, .msg--propria .msg__balao, fundo primitivo --seed-turquesa-50 com texto semântico --seed-text-primary = 1,14 no tema escuro contra piso 3,00, reprodutível 3/3 — mesma forma dos defeitos que o gate achou em 2026-08-16 (1,02 e 1,00). A frase "o acervo está sem defeito medido em aberto" deixa de valer, e isso está dito. Levada crua à pasta, a guarda deu 7 FAIL e seis eram falso positivo: quatro consertos (A contentor sem texto próprio · B primitiva com override de tema INVERTE · C fundo é o ANEL · D sem anel não há veredito) estão registrados no §64.11.4. O 24º defeito de instrumento: número que varia entre execuções do mesmo alvo — 1,84 / 2,56 / 2,95 no mesmo .tagok — não é medida, e só foi visto porque a medição foi repetida três vezes. Detalhe completo no §64.11.

Data: 2026-08-17 · v1.02: NASCE A AUDITORIA TRANSVERSAL DE CONSUMIDOR (§69, contratos AC1–AC4) — a EA-P1 FECHA e a auditoria da SI-P4 e da IL-P2 ACABA. Primeira guarda do acervo que compara um artefato com OUTRO artefato, e não com um contrato. Alvo de PASTA, três classes de consumo (CÓPIA reprova · REIMPL emite [achado] porque a pergunta é de desenho · VERSÃO confere documento contra artefato) e cinco regimes de comparação por campo, escolhidos depois de RITO de 3 rodadas que descartou o diff textual (condenaria 100% das amostras) e o diff visual (devolve lista, não veredito). Placar: 7 PASS · 0 FAIL · 5 [achado] · 12 [n/a]. Correções que a medição impôs à SI-P4: o culpado é o .sigla (24px · raio 6px · glifo) e são QUATRO telas, não três — tela-tabela faltava; e o .ent de 12px sem glifo NÃO é o §65, então condená-lo forçaria conserto errado em 14 elementos corretos. Achado novo, vira PS-P5: o .mini-avatar, círculo de iniciais de PESSOA, pinta-se com a paleta de ENTIDADE, quando o §62 fechou paleta própria de 8 pares. E a lição de instrumento mais cara da rodada: na primeira versão a guarda não pegava o defeito que a gerou — o cargo "Diretor" passava. Guarda que não é testada contra o caso fundador não está provada (§69.4). Detalhe completo no §69.

Data: 2026-08-17 · v1.01: O GATE DAS QUATRO BANCADAS É OBSERVADO — BT-P1, PS-P4 e DH-P6 FECHAM. O Rafael aprovou escolhendo, entre três opções explícitas, a que diz "Aprovo — gate OBSERVADO" sobre as folhas de captura de banco-escolha v0.4, banco-data v0.4, banco-prioridade v0.2 e banco-pessoa v0.1 (render-audit/folha-banco-*.html). O rito inteiro foi REEXECUTADO antes de promover e coincidiu integralmente com o §80 do MANIFESTO: suite-escolha 238 · 0 · 29 · suite-data 31 · 0 · 1 · suite-prioridade 18 · 0 · 0 · suite-pessoa 44 · 0 · 1 · render-promocao 168 · 0 · BT7 5/5/5/3 · 0 · contraste-composicao 8 · 0 · auditoria-borda-campo 2 · 0 por artefato. Achado do caminho: ERRATA DE VERSÃO em três cabeçalhos — §61 dizia banco-data v0.5, §62 dizia banco-pessoa v0.2, §63 dizia banco-prioridade v0.3, e nenhuma dessas versões existe em artefato, gerador, MANIFESTO ou mapa de cobertura; corrigido o DOCUMENTO, não o artefato, com as quatro fontes registradas (§64.10.3). Detalhe completo no §64.10.

Data: 2026-08-17 · v0.99: A VARREDURA BT7 FECHA — 34 artefatos medidos, 120 PASS · 0 FAIL, nenhum defeito aberto no acervo; a BT-P4 FECHA. Os SEIS artefatos que ainda reprovavam foram consertados na CAUSA: tela-quadro e tela-gantt pelo MESMO conserto do .vh (texto visualmente oculto em position:absolute sem ancestral posicionado ancora no body, toma a coordenada ROLADA dentro de uma faixa que rola e estende o scrollWidth do documento — medido right=479 num viewport de 390; virou position:fixed); tela-referencia (84px · .busca com flex:1 e sem min-width:0, piso de conteúdo de 187px); tela-painel (35px · .escala-ctrl inline-flex sem flex-wrap, 307px num pai de 224px); banco-tokens (27px/97px · .type-row sem quebra e 1fr, que É minmax(auto,1fr), impedindo a célula da rampa de encolher); e banco-dataviz-di (61px · tabela de 4 colunas num .nota de 302px, mais quatro <pre> que rolavam SEM caminho de teclado). Nascem o 19º e o 20º defeitos de instrumento — região rolável procurada pela CLASSE .rolavel (e o #quadro do Kanban é região rolável sem essa classe), e nome/foco lidos por RECEITA de atributo (aria-label só, ignorando aria-labelledby; role="region"+tabindex="0" exigidos ao pé da letra, reprovando um tablist operável por roving tabindex) em vez de por COMPORTAMENTO. A render-painel.mjs é achada MORRENDO, não reprovando, por procurar aria-current="page" depois do supersede das lentes para radiogroup — três blocos inteiros (R5b, R6, R7) nunca tinham sido medidos; consertada, 37·0. O teto de 3 MB da varredura era ESTIMATIVA: medido, o banco-dataviz-dp (7,5 MB) leva 2,05 s e passa — teto a 9 MB, e a varredura vai de 33 para 34 artefatos. A suite-escala-figura roda pela 1ª vez e acha o .gt-conectoras do gantt com teto de largura por ACASO (sem max-width) — corrigido, 78·0. Nova subseção §64.8; BT-P4 FECHA; nasce E-P1 (os 8 artefatos de e-mail não foram medidos e não há decisão sobre se o BT7 se aplica a eles — ausência de medição, não aprovação). Bateria completa reexecutada: nenhum FAIL aberto em nenhuma camada. As nove telas + banco-dominio são promovidas a estável por gate DECLARADO, com a nota de rastreabilidade que a distinção exige. Registro integral no validacao/MANIFESTO.md §79 (v11.7). · v0.98: A VARREDURA BT7 EM TODA A PASTA — 33 artefatos medidos, 11 reprovaram, 5 consertados. Nasce a suite-reflow.mjs, primeira guarda do projeto cujo alvo é a pasta e não um artefato: contrato transversal copiado em N suítes é N cópias para desatualizar, e as bancadas antigas — sem suíte em playwright — ficariam de fora para sempre. Consertados: tela-site (a barra de provas era position:static, top=-900 depois de rolar — fecha a pendência nomeada desde 2026-08-16 — e a topbar estourava 44px a 320) · tela-chat (a barra é sticky z-index 60 e o painel de chat é absolute com o mesmo z-index: empate de camada, e a 320px o chat cobre a barra inteira; a barra de provas é instrumento e não disputa camada com a tela — z-index 9000) · banco-data (178px de excesso a 390: o calendário empilha os atalhos abaixo de 470px, com exceção declarada e geométrica ao piso de 44px — 7 colunas × 44 = 308 não cabe em 288) · banco-escolha, banco-pessoa e banco-prioridade. E o gen-site.py não compilava neste contêiner — f-string com aspas escapadas, sintaxe de Python 3.12 (PEP 701), o mesmo defeito de ambiente já registrado para o gen-shell.py no §74: defeito de ambiente que reaparece num segundo gerador é classe, não acidente. PROMOÇÃO: §59, §61, §62 e §63 vão a estável pelo gate declarado ("aprovo. siga"), com nota de rastreabilidade honesta no §78 do MANIFESTO. As telas NÃO foram promovidas — quatro delas (painel, quadro, gantt, referencia) têm defeito de reflow medido e aberto, e artefato com defeito aberto não promove. · v0.97: PROMOÇÃO — §65, §66, §67 e §68 vão a estável pelo gate visual do Rafael (verbatim: "aprovado"), fechando SI-P2, CD-P1, IL-P1 e ET-P2. E o rito de promoção — que é reexecutar todas as camadas contra o artefato real — achou o que o gate não tinha como ver: as quatro bancadas rolavam na horizontal a 320px, e a banco-identidade já a 390. Ninguém tinha medido abaixo de 1200. Nasce o BT7 no §64: nenhuma bancada rola na horizontal a 320px, e o que exige duas dimensões (tabela de dados, grade de glifos) vive em região rolável FOCÁVEL e ROTULADA — porque a exceção do SC 1.4.10 autoriza a rolagem, não a inacessibilidade dela. Guarda BT7 nas quatro suítes, medindo em duas larguras. E o conserto corrigiu um contrato: o SI5 lia o número de colunas de um atributo fixo, que mentia no reflow e já mentia com o filtro ativo — as colunas passam a ser medidas pelo layout, e o nome acessível do grupo diz o número real (SI-OP3b). 18º defeito de instrumento: o seletor da auditoria de sobreposição casava .cx como cartão numa bancada e caixinha de dígito na outra, e comparava pai com filho — seis achados falsos. Escopo segue sendo a variável que mais produz erro de medição: por posição, por texto, por tipo de nó e agora por seletor. Placar de promoção: 32 · 30 · 23 · 25 nas quatro suítes · 25 · 0 e 5 · 0 nos ícones · 40 combinações de render com 0 achados. · v0.96: O PRIMEIRO GATE DAS QUATRO BANCADAS NOVAS — e ele achou quatro coisas que nenhuma das camadas automatizadas via. (1) Dois glifos do set canônico do §45 estavam mal desenhados — “recycle” e “growth”, verbatim do Rafael: “parecem errados, infantilizados”. O recycle eram dois galos soltos que não fechavam triângulo; o growth era o trending-up do acervo 40×40 normalizado por 0,6, com ziguezague raso. Os dois passavam na suite-icones (25·0) e na render-icones (5·0) — legibilidade de forma não é medível pelas guardas que existem, e é essa a razão de o gate visual ser camada e não formalidade. Redesenhados pela régua IC1/IC3, com supersede formal no §45.4 e getBBox remedido. (2) O contraexemplo das seis caixinhas do §66 era um ESPANTALHO: só avançava o foco, sem voltar apagando no Backspace. Corrigido para a melhor forma de mercado — e o argumento ficou mais forte, porque a tese nunca foi “caixinhas não funcionam” e sim quanto custa fazê-las funcionar: quatro remendos de JS contra zero, e o quarto (colar) ninguém escreve. (3) Comentário também é conteúdo: a higienização do §68 varria só elementos, e o <!--StartFragment--> do clipboard do Windows atravessava — o Word emite folhas de estilo inteiras dentro de comentário condicional. (4) A decisão da borda de campo mudou ao ler o gêmeo inteiro: o --seed-border-interactive já existe desde a v1.12 como fronteira de componente interativo, criado com os mesmos números que remedi — o --seed-field-border local do §13 fica supersedido por ele, e não promovido ao gêmeo. O token local é melhor no claro (4,74 × 3,38) e pior no escuro (3,21 × 4,50). Duas guardas novas, CD10-c e ET8-b, ambas provadas capazes de reprovar antes de serem aceitas. · v0.95: A FILA DA F7.5 FECHA NO ALCANÇÁVEL — nascem o §65 (identidade de entidade, SI1–SI16), o §66 (credenciais, CD1–CD16), o §67 (edição em linha, IL1–IL14) e o §68 (editor de texto rico, ET1–ET14), fechando C6, C7, C13, C14 e C15. Quatro bancadas, quatro suítes, 94 PASS · 0 FAIL. As três decisões que carregam a rodada: (1) a paleta de identidade é FECHADA em seis (CP23) — no produto de referência, com paleta livre e tinta branca fixa, 6 dos 13 pares medidos reprovam (3,03–5,83); classe fechada transforma “todas as cores passam?” em seis medições, a mesma saída que fechou a PS-P3. (2) O código de uso único é UM campo, nunca seis caixinhas — o SC 3.3.8 exige que dê para colar, e a bancada exerce o contraexemplo em vez de citá-lo: colado o mesmo código nos dois desenhos, o campo único retém 6 de 6 dígitos e as caixinhas 1 de 6. (3) Na edição em linha, clicar fora CONFIRMA — entre um erro reversível (gravou, e o desfazer do PN28 volta) e um irreversível (sumiu o que se digitou), o sistema escolhe o reversível. E dois defeitos de instrumento, ambos achados antes de qualquer artefato ser tocado: o 16º — o parser de cor não entendia hexadecimal e a guarda emitiu PASS com razão 232,67, fisicamente impossível (regra nova: número fora de [1,00…21,00] é MEDIDOR QUEBRADO, não veredito) — e o 17º, em que a guarda varreu o <body> inteiro e reprovou o artefato lendo a tabela de contratos que EXPLICA o contrato (regra nova: guarda mede o CONTROLE, nunca o texto que descreve o controle). Achado de fundação: o --seed-field-border do §13 (4,74:1) não existe no gêmeo seed-tokens.css — vive só no bloco local da banco-formfield.html; os campos novos consomem --seed-border-interactive (3,38 / 4,50), medido, e a promoção do token ao gêmeo fica na CD-P2. · v0.92: A PR-P2 É RESPONDIDA (e a resposta é NEGATIVA), nasce a banco-prioridade.html — e o botão de tema estava MORTO nas TRÊS bancadas desta sessão. A PR-P2 perguntava se o set canônico de 28 glifos do §45 daria as quatro formas da escala ordinal. Não dá — ele não tem nenhuma: os 28 são de domínio elétrico ou de UI básica. Mas a decisão já existia: a árvore do NM4 manda usar o Lucide quando o glifo é utilitário e não está no set SEED. O set não precisou crescer e a escala não precisou mudar — a pendência se resolveu pela regra que o §45 já tinha escrito. A escala vira uma escada de formas (duplo-acima › acima › plano › abaixo › círculo tracejado): a direção É o dado, então a ordem sobrevive ao cinza e ao daltonismo sem depender da cor — contra as quatro bandeiras em quatro cores do produto de referência (C131), que em cinza viram a mesma bandeira. Placar 17 · 0 · 0. E o achado que atinge três artefatos: o botão “Escuro” das bancadas setava data-tema="escuro" — o atributo traduzido. O gêmeo de tokens escuta [data-theme="dark"]. Botão morto vestido de PROVA, em banco-escolha, banco-data e banco-prioridade — e a guarda de contraste no tema escuro passava medindo o tema claro duas vezes. Consertado nos três; depois do conserto os números do escuro finalmente diferem dos do claro (6,20 contra 4,77). Atributo de contrato não se traduz. · v0.91: NASCEM O §62 (seletor de pessoa, PS1–PS16) E O §63 (prioridade, PR1–PR12), fechando C4 e C11 — e a sexta volta acha o MESMO defeito num segundo componente. Navegação em modo somente leitura, nove dispositivos (C125–C133). O achado que vira expectativa: na lista de pessoas do produto de referência, cada item é generic — sem listbox, sem option, sem aria-selected — e o campo de busca é textbox simples, sem combobox, sem aria-expanded, sem aria-controls. É o C122 outra vez, noutro componente: dois de dois seletores auditados repetem o padrão. A regra da quinta volta deixou de ser precaução e virou expectativa: neste produto a semântica de escolha é sistematicamente ausente. Dois achados de fronteira: a busca do seletor de pessoa também convida quem não está no espaço (C126), e o menu de prioridade mistura a prioridade do OBJETO com a prioridade PESSOAL de cada um, separadas só por um título (C132). E um achado negativo que vira contrato: o menu de prioridade não sabe desatribuir (C133) — o campo mostra “Vazio”, e voltar a vazio não é oferecido. O PatternFly confirma que “none” é estado, não ausência de estado. C5 e C8 ficam com bloqueio nomeado: os dois só se alcançam escrevendo. · v0.90: O GATE ACHOU UM CALENDÁRIO INOPERÁVEL COM PLACAR VERDE — e a guarda que devia pegá-lo tinha sido escrita para NÃO OLHAR ali. Verbatim do Rafael: "não consegui ter ação no calendário. não consegui fazer seleção de intervalo de data com o mouse, nem clicar em nenhuma data, quanto mais fazer o teste com tab". A v0.1 tinha 25 PASS · 0 FAIL e a grade era estática: o clique só movia o foco e escrevia numa live region invisível. Uma grade estática não é um seletor de data — é a FOTO de um. E o pior: a guarda BTN ("nenhum botão morto") excluía explicitamente table[role="grid"], .cal__nav, .cal__hoje e .cd__gatilho — os quatro lugares onde o defeito estava. Guarda escrita para não olhar onde o defeito mora é pior que guarda nenhuma: ela produz um verde que impede a pergunta. Nascem cinco guardas de OPERABILIDADE (DH-OP1…DH-OP5) que medem AGINDO — clicam, passam o mouse, navegam — e comparam estado antes e depois. A grade passa a ser renderizada por JS a partir de constantes fixas; o "hoje" continua fixo, o que passou a existir é a interação. Mais dois defeitos de instrumento (nono e décimo) e um de artefato achado pelo próprio teste: o mouseenter redesenhava o DOM e destruía o elemento sob o cursor, entrando em laço. Placar: 30 · 0 · 1 [n/a], e desta vez o verde quer dizer alguma coisa. · v0.89: A DH-P1 FECHA — nasce a banco-data.html, e a bancada acha DOIS alvos abaixo do piso e DOIS defeitos no próprio instrumento. Placar 25 · 0 · 1 [n/a]. Decisão de método: o "hoje" da bancada é FIXADO em 2026-08-16, declarado no gerador — um calendário que consulta o relógio muda de bytes todo dia, e isso quebraria a âncora que este projeto usa para provar que um arquivo é o que se pensa que ele é. Defeitos reais do artefato: o gatilho do calendário media 40px porque o min-height:44px estava na CAIXA, e caixa não é alvo — alvo se mede no retângulo do controle, não no contêiner; e a célula de dia media 42px. Sétimo defeito de instrumento, e é o mais sutil da série: a suíte rodava em UTC. O DH14 existe porque new Date("2026-08-16") é lido como UTC e devolve o dia ANTERIOR a oeste de Greenwich — e num contêiner em UTC a armadilha não dispara: a guarda passava sem provar nada. Rodando em America/Sao_Paulo, ela mostra o que tem de mostrar: new Date(string) daria 15. Guarda que roda em UTC não pega defeito de fuso. Oitavo: a guarda do DH17 procurava a palavra "recorrência" na página inteira e a achava na própria tabela de contratos, na linha que documenta que recorrência NÃO pertence ao componente — ela reprovava o artefato por dizer a coisa certa. · v0.88: NASCE O §61 — DATA, INTERVALO E HORA (DH1–DH18), fechando C1 e C2. E a rodada zero produziu a PRIMEIRA leitura em que a árvore de acessibilidade CONTRADIZ a tela. A navegação (quinta volta do estudo, C117–C124) abriu o seletor de data do produto de referência em modo somente leitura. Na captura, o calendário é impecável. Na árvore, cada dia é um button cujo nome acessível é SÓ O NÚMERO — sem grid, sem gridcell, sem aria-selected no dia escolhido: o leitor de tela anuncia "botão 2". Copiar a forma teria copiado o defeito, porque o defeito não aparece na captura. Regra nova: onde o dispositivo é de ESCOLHA, leia a ÁRVORE junto com a TELA. E o canon diverge outra vez, agora em três: o APG especifica calendário em role=grid com teclado completo; o GOV.UK/NHS manda não usar calendário quando o usuário já sabe a data, e sim campos de texto; o USWDS faz os dois, e monta intervalo como dois seletores independentes. A régua sai do PROBLEMA: pergunte se o usuário JÁ SABE a data — sabe, o texto basta; não sabe, o calendário é que responde; e os dois existem sempre. O intervalo fica como um controle com dois campos e um calendário compartilhado (DH10), contra os dois seletores do USWDS, porque separados ninguém valida a relação — e o próprio USWDS admite que não valida coerência entre início e fim. Um contrato nasce declaradamente sem leitura (DH12): o vão entre início e fim não pôde ser observado, porque preenchê-lo seria escrita. · v0.87: A SG-P10 FECHA e o §60 encerra SEM PENDÊNCIA — dez fechadas numa sessão. Decisão do gate: B, fronteira por GRUPO. O painel e a lista adotam a anatomia da bancada — contêiner com borda, fundo surface-subtle e 3px de respiro; segmentos sem borda e sem fundo; inline-flex, para o grupo encolher para o conteúdo e a fronteira delimitar o CONTROLE em vez da linha. O operador do §53 tinha uma terceira anatomia (overflow:hidden, gap:0, rótulos colados) e também converge: ter algum contêiner não é convergir; convergir é adotar A MESMA anatomia. Três defeitos achados aplicando a decisão, e todos pelas guardas: (1) AC-08 pegou 8px e 6px digitados onde existem tokens (radius-md, radius-3) — a higiene é de CLASSE, não interessa que o número esteja certto; (2) regressão de ESPECIFICIDADE — a regra nova .lentes [role=radio] tem o mesmo peso 0,2,0 de [role=radio][aria-checked=true], e por ser posterior apagou o fundo do selecionado em silêncio; o placar acusou separação 1,00 contra piso 3,00; (3) sexto defeito do instrumento — com o segmento em background: transparent, o getComputedStyle devolve rgba(0,0,0,0) e a guarda lia preto, reprovando artefato correto. Agora ela compõe o fundo EFETIVO subindo pelos ancestrais, que é o que o olho faz. Placares finais: escolha 233 · 0 · 29 [n/a] · painel 146 · 0 · contraste 78 · 0 · contêiner 66 · 0. · v0.86: O GATE ESCOLHE O RETO — e a aplicação da decisão expõe uma divergência MAIOR que a que acabou de fechar. SG-P9 decidida ("pilula contra reto, escolho reto"): o segmento passa a 6px, o valor que já vinha do §53, e a família fica com uma geometria — altura 44px desde a SG-P7, raio 6px desde agora. A regra é específica (.lentes [role=radio] e irmãs), não uma troca no button genérico do preview: o gate decidiu sobre o SEGMENTADO, não sobre todos os botões — alargar a decisão além do que foi decidido é a forma silenciosa de decidir sozinho. Mas aplicar o raio revelou o que o raio escondia: o painel desenha oito botões com fronteira própria e vão entre eles; a bancada desenha um GRUPO com fronteira única e segmentos sem borda. Mesmo raio, mesma altura, anatomias diferentes — e é a mesma família de divergência que esta sessão inteira passou fechando, só que uma camada acima. Divergência de valor esconde divergência de estrutura: igualar o número não iguala a coisa. Vira SG-P10, com amostra comparativa, porque decidir por mim seria alargar de novo. Placares: escolha 233 · 0 · 29 [n/a] em cinco alvos · painel 146 · 0 · contraste 78 · 0. · v0.85: A SG-P2 FECHA — nasce a banco-escolha.html, e ela existe para provar exatamente DUAS coisas. A bancada chega por último de propósito: a SG-P1 já tinha provado onze contratos com consumidor real em produção, então o trabalho que sobrava era estreito e declarado — provar o SG7 (contagem por segmento) e o SG14 (multi-select que não fecha), os dois sem instância no acervo, e fechar a última divergência de geometria. Placar da bancada: 137 · 0 · 0 — ela exerce TODOS os catorze contratos, e é o único artefato do acervo em que nenhum sai [n/a]. A altura já tinha convergido em 44px; o raio não, e ele vira a SG-P9: pílula (§48) contra reto (§53), lado a lado, mesmo conteúdo — e com uma terceira fileira estreita de propósito, porque é na QUEBRA de linha que os dois divergem de verdade. Mostrar a diferença é medição que o olho faz; afirmar qual é melhor seria opinião. Mais dois defeitos de instrumento, o quarto e o quinto da série: a guarda do SG7 testava /\b\d+\b/ no texto do segmento e nunca casava — em "Em campo"+"7" o texto concatenado vira "Em campo7" e não há fronteira de palavra entre o e 7; ela devolvia [n/a] sobre uma bancada que TINHA a instância. E, mesmo funcionando, media a FORMA ("tem número?") em vez do CONTRATO ("o número muda ao filtrar?") — agora ela TROCA a escolha e mede. A sonda do SG14 deixava a lista ABERTA sobre a fileira de chips e derrubava a guarda seguinte: quem mexe, arruma. Agregado das cinco alvos: 215 · 0 · 29 [n/a]. · v0.84: O GATE APROVA e o §60 vira estável — mas a auditoria de promoção acha um contrato que NUNCA tinha sido testado, e ele estava violado. Gate visual do Rafael em 2026-08-16 ("verificado, tudo ok") sobre tela-painel v0.11, tela-tabela v0.2 e tela-lista v0.2: a SG-P8 fecha. Antes de promover, perguntei quais dos catorze contratos tinham prova e não só texto — e quatro não tinham guarda nenhuma: SG3 (proibição sem instrumento é só uma frase), SG7 e SG14 (sem consumidor no acervo) e SG8. Ao escrever a guarda do SG8 ela achou a violação: o botão ✋ Mover levava o glifo dentro do nome acessível — o leitor de tela anunciava "mão levantada Mover". Contrato sem guarda é contrato sem prova, mesmo quando existe consumidor. E a guarda nasceu errada pela terceira vez na série: usava textContent, que não é nome acessível (inclui a subárvore aria-hidden), e por isso continuou reprovando o conserto certo. Promoção parcial e declarada: SG1–SG6b e SG9–SG13 vão a estável porque têm consumidor medido; SG7 e SG14 continuam rascunho — não existe instância deles no acervo, e é isso que a SG-P2 passa a significar. Placares: escolha 96 · 0 · 29 [n/a] · painel 146 · 0 · contraste 78 · 0 · contêiner 66 · 0. Selo do painel a v0.12 — mudança de um atributo, invisível na tela, mas bytes que mudam com selo parado foi o defeito da v8.9. · v0.83: AS QUATRO PENDÊNCIAS DE GATE FECHAM — e a medição derruba a revisão que eu ia propor. SG-P4/SG-P5: os quatro grupos de escolha exclusiva do §48 (lentes · escala de tempo · gesto no vazio · modo do mapa) passam a radiogroup + role="radio" + aria-checked, com um mecanismo de roving só para os quatro — antes eram três mecanismos diferentes. SG-P7: alvo do X do chip sai de 24×24 para 44px reais, alvo do X da condição de 32 para 44, "+N" com teto declarado, anúncio com contagem, "Limpar" com piso de dois. SG-P6 é o achado da edição: eu ia relaxar o SG6 ("fundo E peso") porque o fundo sozinho media 4,60 e 4,57 contra piso 3,00 — e a medição em forced-colors: active mostrou a separação caindo para 1,00, com o selecionado ficando indistinguível do repouso. O SG6 estava certo pelo motivo errado: dizia "não só cor" pensando em daltonismo, e quem cobra a fatura é o alto contraste. Não relaxa: vira SG6-b, medido nos TRÊS modos, com cor de sistema — depois do conserto mede 19,04. O SG5 esse sim cede, com número: as oito lentes cabem em 390/768/1180/1440px em 4/2/1/1 linhas, alvo mínimo 62×44px, sem vazar nem cortar — o teto é de aperto medido, não de contagem. E a SG5 revista achou defeito que a antiga não alcançava: o segmento do operador do §53 media 62×32px. Duas guardas afirmavam a forma errada: a PN6-01 exigia aria-current (por isso cinco camadas atravessaram o defeito — a guarda não estava cega, estava apontada para o lado errado), e o meu próprio instrumento casava as passadas extra por posição em vez de por identidade. Placares: escolha 88 · 0 · 21 [n/a] (4 arquétipos) · painel 146 · 0 · contraste 78 · 0 · contêiner 66 · 0. · v0.82: A SG-P1 FECHA — e a auditoria acha SEIS controles em QUATRO arquivos, não três em três. Instrumento novo: validacao/suite-escolha.mjs, 52 PASS · 22 FAIL · 21 [n/a]. O achado que justifica a ordem "auditar antes de produzir": o acervo já resolvia a mesma pergunta de TRÊS jeitos incompatíveis — tela-painel.html com role="group" + 8 <button> + aria-current="page" (a saída do eBay, explicitamente descartada no §60.1), tela-lista.html com radiogroup nativo (conforme SG1), e ainda uma terceira no MESMO arquivo do painel: a "Escala de tempo" é escolha exclusiva de 1 entre 4 feita com quatro aria-pressed — a exclusividade mora no script e nunca chega à tecnologia assistiva, que anuncia quatro interruptores independentes. Produzir a bancada primeiro teria criado a QUARTA variação. Três defeitos da própria spec, medidos: o SG5 (teto de 5) é violado pelo seu primeiro consumidor, que tem oito lentes estável e aprovadas em gate; o SG6 ("fundo E peso") é violado por 2 de 2 dos segmentados, e a medição mostra que o fundo sozinho entrega 4,60 e 4,57 de separação de valor contra piso 3,00 — a letra é mais estrita que o próprio motivo; e a tabela de consumidores apontava o §53 para o arquivo errado (o construtor FC1–FC6 vive em tela-lista.html, não em tela-tabela.html). O pior defeito é o que parecia resolvido: o X do chip declara alvo de 44px por ::before absoluto, mas o botão é position:static — o alvo ancora em <html> e o alvo real mede 24×24px. Supersede em §60.6; três decisões de gate abertas. · v0.81: NASCE O §60 — ESCOLHA SEGMENTADA E MÚLTIPLA (SG1–SG14), fechando C3 e C12. A R1 achou uma DIVERGÊNCIA DE CANON: cinco fontes de peso dão quatro semânticas diferentes para o mesmo componente — o Primer proíbe radiogroup (ele requer botão de salvar), o useUI o exige, o Workday usa aria-pressed, o eBay usa aria-current. A seção resolve com três saídas e uma régua: pergunte o que MUDA — a forma de ver o mesmo dado é segmentado, quanto do dado aparece é interruptor, o dado é aba. E ela chega depois dos consumidores: o §48, o §53 e o §56 já usam esses controles sem spec, então o primeiro trabalho não é produzir — é auditar se os três resolvem o mesmo problema do mesmo jeito (SG-P1). É o inverso do §54, que existia como artefato sem seção. · v0.80: A BANCADA DO §59 NASCE e a seção ganha seus NÚMEROS. banco-dominio.html com sete estados, formatação por Intl.NumberFormat em pt-BR e parser derivado do formatador. Achado real de contraste que QUASE virou conveniência: o separador entre adorno e campo media 1,11 e a saída fácil seria declará-lo decorativo — não cabia, porque a diferença entre as duas superfícies é de apenas 1,08 e a linha é o ÚNICO sinal. Quarto achado seguido da mesma família, e a régua ganha teste: antes de declarar decorativo, meça se existe OUTRO sinal. A guarda FMT-02 prova o VD5 com o caso que separa um ERP correto de um perigoso: em pt-BR 1240.5 é doze mil quatrocentos e cinco. Placares: domínio 28 · 0 · contraste 152 · 0 (76 pares). · v0.79: ABRE A F7.5 — NASCE O §59, CAMPOS DE VALOR DO DOMÍNIO (VD1–VD16), fechando C9 e C10. A rodada zero produziu um veredito de TIPO NOVO: para estes campos a leitura visual não se aplica — o produto de referência não tem campo de potência em kWp —, e a base é canon + norma + domínio. "Não tem leitura" significa três coisas diferentes — não foi visitado, não existe instância, ou não se aplica — e tratá-las como a mesma leva a "vamos navegar" para um problema que a navegação não resolve. Contratos que estruturam a seção: VD1 (o usuário digita só dígitos; a unidade é adorno, régua literal do USWDS), VD6 (nunca type=number, pelo comportamento inconsistente entre navegadores), VD7 (o navegador só FORMATA — não há API de parsing, e ler de volta exige parser derivado do formatador) e VD12 (autocomplete não se aplica, e inventar token seria a falha F107 — a orientação do W3C é que campo fora da lista de propósitos passa por não-aplicabilidade). A seção nasce só com relações; a bancada é o próximo movimento. · v0.78: §57 E §58 VÃO A estável. Veredito do Rafael depois do conserto dos dois defeitos do A5: "tudo ok, pode prosseguir". A F7.4 fica com dois dos três arquétipos entregues e promovidos; o terceiro, A15 carga de trabalho, está BLOQUEADO por ausência de instância — o workspace de referência não tem visualização de carga criada, e criar uma seria ação de escrita. Dois arquétipos, dois bloqueios de ambiente (o A6 não carrega, o A15 não existe), ambos registrados com o motivo na §14 do estudo. A quarta volta de navegação rendeu cinco dispositivos (C112–C116), e um deles — C113, navegação temporal por setas mais rótulo do período — CONFIRMA o GT17, escrito no mesmo dia a partir de um defeito do gate: a leitura que eu não tinha convertido em contrato estava a uma volta de distância. · v0.77: DOIS DEFEITOS DO GATE VIRAM GUARDA, e nasce o GT17. (a) O menu do divisor abria estourado: usava a classe .menu-mover, que existe no gabarito A7 e nunca foi copiada para o molde do A5 — classe reaproveitada entre gabaritos é dependência, e dependência não copiada é referência órfã. (b) O gráfico parecia travado; as barras clicavam e a região rolava, mas rolagem horizontal com roda de mouse exige Shift, e sem controle explícito o usuário conclui que a tela está morta. Nasce o GT17: eixo que rola precisa de CONTROLE, não só de overflow — overflow é mecanismo, controle é affordance. Oito guardas novas (POP e EIX); a suíte do gantt vai de 35 para 43 · 0. · v0.76: O GABARITO A5 NASCE e o §58 ganha seus NÚMEROS. A spec tinha sido escrita só com relações; o tela-gantt.html mediu tudo — escala de 6px por dia declarada sob o CP32, barra de 20px, base de 5px, losango de 14px, três larguras de painel. Três achados reais de contraste, e os três mudaram o artefato: a barra nasceu com surface-brand e o rótulo branco media 2,71 (turquesa de MARCA não é turquesa de AÇÃO); o marco nasceu com entity-2 a 2,61, e entity-5 resolvia o claro mas reprovava o escuro a 2,37 — cor fixa precisa passar nos dois temas; e o contorno do caminho crítico é fronteira externa, medido contra a plotagem. A guarda que vale mais é o bloco ESC: mede a barra em duas larguras de janela e exige que não mude — o CP32 aplicado a figura montada em HTML. Placares: gantt 35 · 0 · composição 27 · 0 · contraste 128 · 0 (64 pares). · v0.75: NASCE O §58 GANTT E LINHA DO TEMPO (GT1–GT16) e a PN-P2 FECHA — aberta desde a Fase 6 como "bloco 6D" (PN42–PN45: dependências com lag, caminho crítico, linha de base, marco). A fronteira com o §48 está declarada: a lente temporal (PN47, PN48, PN49) fica onde está e não é reescrita; o §58 acrescenta a camada de RELAÇÃO entre itens. Dois contratos merecem nota: o GT11 manda a alternativa textual ser TABELA COMPLETA e não resumo, porque o estado da arte reconhece que dependência complexa não expõe relação programática completa — um fornecedor declara isso em VPAT —, e a tabela É a relação escrita; e o GT8 obriga o lag a ser declarado no rótulo da conectora, seguindo o alerta do canon de que lag que vira hábito esconde duração de base errada. A seção nasce só com relações: os números vêm na produção do gabarito A5, pelo método do §55 — nenhuma medida é afirmada antes de medida. · v0.74: ABRE A F7.4 — NASCE O §57 QUADRO/KANBAN (QD1–QD14) e o gabarito A7. Decisão de fronteira que CONTRARIA o produto de referência: o C57 observou coluna com fundo tingido, e mantemos a trilha TRANSPARENTE do CP2 — seis colunas tingidas criariam seis superfícies cromáticas competindo com os cartões, contra o CP19 (o croma vem das peças); a identidade fica no cabeçalho. O contrato que estrutura a seção é o QD6: mover sem arrastar é o caminho PRINCIPAL, porque o SC 2.5.7 exige alternativa por PONTEIRO ÚNICO e é explícito em que isso não é teclado (SC 2.1.1, separado) — a técnica G219 do W3C foi escrita com este exemplo literal. Terceiro achado seguido de border-default reprovando o SC 1.4.11 (1,37 e 2,61 na borda do convite). Placares: quadro 35 · 0 · composição 32 · 0 · contraste 108 · 0 (54 pares). · v0.73: O §56 VAI A estável e a F7.3 fecha o que era possível fechar. Segunda rodada de gate (a primeira foi sobre o arquivo errado — mesmo selo em duas versões diferentes do gabarito, defeito registrado na v8.9 do MANIFESTO). Veredito do Rafael: "tudo ok, continue". Com isso todas as seções da F7.3 estão estável: §49 detalhe, §54 botão dividido, §55 chat e §56 atividade. Segue fora A6 formulário, bloqueado por defeito do ambiente de referência e não por falta de trabalho. · v0.72: NASCE O §56 — ATIVIDADE E COMENTÁRIOS (CM1–CM12), e a fronteira do CP2 se dissolve. A F7.3 abriu com a dúvida de que o comentário fosse cartão dentro do cartão do objeto — peça em peça, proibida pelo CP2 — e com a saída pronta de escrever uma exceção CP2-c. A navegação real de 2026-08-16 (autorizada, somente leitura) desfez a premissa: o comentário é BLOCO, não cartão (medido no gabarito: borda 0, sombra none, raio 0), e a exceção fica DESCARTADA. A leitura rendeu o achado que estrutura a seção: dois pesos no mesmo fluxo — comentário com avatar e ações, evento de sistema como LINHA sem ações. Mais o CM5, dispositivo novo: no hover o cabeçalho TROCA o metadado pela ação, em vez de revelá-la ao lado (distinto do PD9). O §54 ganha seu primeiro uso em tela, no composer, com o teclado do menu button inteiro. Placares: detalhe 73 · 0 · composição 33 · 0 · contraste 84 · 0 (42 pares × 2 temas). ACHADO DE CONTRASTE: o marcador do evento nasceu com border-default (1,49 e 2,32, reprova o SC 1.4.11 nos dois temas) — daria para declarar decorativo, mas seria conveniência, e ele recebeu a tinta do texto que marca. · v0.71: PROMOÇÃO EM BLOCO E FECHAMENTO DE DÍVIDA. O Rafael aprovou em 2026-08-16 ("aprovo") a promoção de §49 a §55 a estável, após gate visual sobre as SEIS telas do projeto — e o gate achou dois defeitos que as cinco camadas automatizadas atravessaram, ambos consertados e virados guarda ANTES da promoção (nasce o PD19). Nasce também o §54 BOTÃO DIVIDIDO (BD1–BD9 + MN9), que existia como artefato desde 2026-08-15 e não existia como seção canônica — a dívida A-P1, medida na leitura de volta da v8.4 do MANIFESTO, fecha aqui pelo rito completo de três rodadas, e não por transcrição do comentário do CSS. Três contratos NOVOS vieram da pesquisa e não estavam no artefato: BD7 (o gatilho nunca executa ação), BD8 (sem variante destrutiva; destrutiva só uma vez e por último) e BD9 (no toque e no degrau estreito o botão dividido COLAPSA em botão de menu — o padrão não é recomendado para toque, pelo problema do dedo grosso). · v0.70: NASCE O §49 — DETALHE DE REGISTRO (PD1–PD18), e com ele a pendência PN-P3 FECHA depois de aberta desde a Fase 5. Primeira seção do projeto escrita já sob a RODADA ZERO (conferir leitura visual antes de especificar): os sete dispositivos vêm da §13.4 do estudo-clickup-completo.md (C50–C56). Gate do Rafael de 2026-08-15 sobre amostra A/B navegável: "modal A por padrão, e opção do modelo B caso o usuário prefira… no modelo A, deixa opção de expandir a janela depois que ela for aberta" — daí saem PD1 (dois regimes, modal padrão), PD17 (dois degraus da janela por BOTÃO, não por arraste: arraste cai sob o SC 2.5.7, mesmo raciocínio que virou slider no §51) e PD18 (a alternância vive DENTRO do detalhe, porque com o modal aberto o fundo é inerte e um controle fora dele seria inalcançável). A pesquisa achou uma LACUNA DE CANON: não há padrão publicado para troca de conteúdo dentro de um diálogo já aberto — trocar o título com o foco parado é silencioso para leitor de tela —, e o PD3 é decisão nossa, declarada. Nasce o gabarito A8 tela-detalhe.html com gerador, molde e a suíte própria suite-detalhe.mjs (47 · 0), mais contraste-f73.py (28 pares × 2 temas, 56 · 0). Achado real da medição de contraste: a fronteira dos botões usava border-default, que mede 1,49 sobre branco e 2,32 no escuro e reprova o SC 1.4.11 nos dois temas — trocada por border-interactive (3,38 · 4,50). O §49 nasce em rascunho: o gate visual do Rafael é o ato que promove. · v0.69: SUPERSEDE PARCIAL DO CD1 (decisão do Rafael no pacote PN-P7/CP-P2, verbatim: "o que vai prevalecer é o que construímos agora… acredito ser a opção A") — quando o card é PEÇA sobre canvas, a separação é o PAR SOMBRA+ANEL do CP17; o outlined literal permanece legítimo só em contexto interno a outra peça (well do CD5). O conflito era latente desde 2026-08-14 (CP17 nasceu sem emendar o CD1) e foi ACHADO pelo inventário medido do retroativo PN-P7/CP-P2 — a razão de os previews de componente terem ficado FORA daquele lote (migrar artefato de spec sem supersede escrito inverteria a ordem decisão→artefato). Consequência: nasce a pendência CP-P4 (retrofit dos previews de componente sob este supersede), registrada no MANIFESTO v7.7. Na mesma edição, o fecho do §47 registra o FECHAMENTO do retroativo: seed-site-preview v0.2 consome border-interactive com 0,00% de diferença medida em pixel (promoção de expressão, não de cor). Nenhum par de cor novo; nenhum preview alterado POR ESTE ARQUIVO (os artefatos migraram no pacote v7.6, pela via molde/gerador). · v0.68: SUPERSEDE DA EXCEÇÃO DO RAIL (gate visual de 2026-08-15 sobre o preview v0.3). Veredito do Rafael: o rail se apresenta "de forma descolada, como uma barra flutuante, um bloco montado como os outros — todos independentes, igual o ClickUp usa". A exceção nomeada do CP1 (rail encostado na borda, de topo a base, sem raio) morre; o rail vira PEÇA sobre o canvas: radius-lg, calha sp-3 nos quatro lados, SEM borda com o porquê medido (peças brancas precisam do 1px porque medem 1,21 contra o canvas; o gradiente do rail mede 5,82/8,62 claro · 2,70/1,82 escuro — a cor é a fronteira). A mudança expôs e corrigiu um DEFEITO LATENTE: a barra branca do item ativo (SH5) desenhava FORA do box do rail desde o SH15-b (left:-8px com overflow clipando; probe de pixel: x=-3 com o box em x=0) — invisível em render, invisível para a suíte (SH5-04 só checa presença de regra). Corrigida para a borda interna e provada em cor renderizada (rgb 255,255,255 no pixel). Nota do §46.1 atualizada; supersede formal no CP1 do seed-composicao.md v1.4; shell no preview v0.4 (suíte 72·0 · render 18·0 · contraste 51·0); MANIFESTO v7.1. · v0.67: a PENDÊNCIA SH-P1/PN-P5 FECHA — nasce --seed-border-interactive nos gêmeos v1.12. Gatilho: a regra GI2 da própria pendência ("fecha quando a camada 2 for editada por outro motivo") disparou com a CP-P3, e o Rafael decidiu fechar na mesma janela (2026-08-14: "vamos resolver logo, não tem tempo pra depois"). O token: fronteira de componente interativo (SC 1.4.11), cinza-500 #788F9D promovido de empréstimo declarado a semântico — MESMO valor renderizado (promoção de expressão, não de cor), medido contra as seis superfícies dos dois temas (3,11–5,51, todos ≥3,0), slot dark declarado de propósito. Alternativa descartada com número: cinza-600 passa (3,21–4,74) mas mudaria cor aprovada em gate sem motivo. Quatro trechos deste arquivo atualizados: a pendência do §46.2 (fechamento anexado ao registro histórico), o fecho do §46, o fecho do §47 (o campo de formulário ganha o semântico à disposição; migração do artefato é retroativo classe PN-P7) e a linha PN-P5 do §48.9. O shell consome desde o preview v0.3 (suíte 68·0 · render 18·0 · contraste 47·0). Racional completo: seed-tokens.md v1.12 §3 e MANIFESTO v6.9. · v0.66: fechamento documental da CP-P3 — duas correções de redação no §46, nenhuma decisão de componente muda. (1) Errata E-CF-05 fechada (regra GI2): a linha SH15 da tabela do §46.1 ainda descrevia o rail da era cinza-900 ("e o item ativo usa #006C62 fixo") — DUAS gerações atrás do artefato: a E-CF-04 (v0.65) consolidou o parágrafo "Rail" do §46.2 e esqueceu a linha da tabela, exatamente a classe "duas redações do mesmo fato no mesmo arquivo" que a E-6C-01 ensinou a caçar. A linha passa a declarar o estado atual (gradiente --seed-rail-background + pílula clara SH15-b) preservando a REGRA original do SH15, que nunca mudou — só o valor mudou, duas vezes. (2) O parágrafo "Rail" do §46.2 é atualizado: a redação "gradiente admitido pelo CP20 — adoção pendente de gate visual" ficou FALSA após o gate de 2026-08-14 (veredito G2 adotou) e a regeneração da CP-P3 (executou): o rail consome --seed-rail-background (gêmeos v1.11) e os overlays de chrome do SUP-6, medidos em composição (4,88/6,82 · 4,68/6,50). Placares da regeneração no MANIFESTO v6.8; a errata E-CP-01 (C1 consumindo a categórica) fecha lá e no seed-composicao.md v1.2 §9. · v0.65: a Fase 2 da composição de tela toca este arquivo em quatro pontos, nenhum deles mudando decisão de componente. (1) SUP-1: o contrato de montagem (ex-SH16) vira lei no canônico novo seed-composicao.md §1 (CP1); o §46.1 ganha a nota de referência e o cabeçalho corrigido de "SH1–SH14" para "SH1–SH15" (errata E-CF-03 fechada — mesma classe da E-6C-01: título divergindo do conteúdo). (2) Errata E-CF-04 fechada: o parágrafo "Rail" do §46.2 dizia 64px, surface-inverse e implicava cinza-900 — três divergências contra o SH3 (80px medidos), o SH15 (superfície fixa) e a decisão cromática do MANIFESTO v6.3 (turquesa-700); parágrafo consolidado, pela regra "quem edita o arquivo fecha as erratas dele" (GI2). (3) SUP-2 aplicado no §32: presença/status online entra no DS — correção de registro de uma fronteira estável cruzada por artefato (C2, MANIFESTO v6.4) sem supersede escrito. (4) SUP-3 aplicado no §25: a taxonomia Z1 passa de cinco a SEIS tipos (entra a Bifurcação, dispositivo C36), com emenda declarada à Z2 (na bifurcação, 2 ações é obrigação e ambas primárias). Nenhum preview foi alterado; nenhum par de cor novo NESTE arquivo (as medições da fase vivem no seed-composicao.md §7 e em marca-seed.md v5.2 §3.6-b). · v0.64: duas correções de rastreabilidade, nenhuma decisão do §48 muda. (1) CITAÇÃO ÓRFÃ no §48.7: o guia de ligação do mapa era citado como validacao/mapa-base-lovable.md, caminho que deixou de existir quando a duplicata byte-idêntica de validacao/ foi apagada e a âncora passou à raiz (MANIFESTO v4.0, §19-b). Motivo da mudança de caminho: o LEIA-ME.md da pasta a declara como a das suítes e scripts executáveis, e este arquivo é documentação de entrega ao produto — como ligar MapLibre e a chave de geocodificação no Lovable —, não artefato de validação; nenhum script o lê, as citações eram textuais. Citação órfã é a mesma classe da referência órfã que a guarda REF-01 pega no código: aponta para algo que não existe e ninguém percebe até tentar abrir. (2) ENTRADA DE HISTÓRICO AUSENTE, e o defeito é meu: a v0.63 bumpou o TÍTULO do arquivo e não escreveu a própria entrada nesta linha de histórico — título dizia v0.63, histórico terminava na v0.62. É a irmã exata da errata E-6C-01 (título × selo divergindo dentro do mesmo artefato), agora num .md. A entrada da v0.63 está restaurada abaixo, e a lição vale para qualquer canônico: quem bumpa o título escreve a entrada na mesma edição. · v0.63: registro da INVERSÃO DO HERO — o azul sai, a âncora passa a TURQUESA VIVO turquesa-400 #11B0A0 (L 33,71% contra 6,03% do azul-800, croma +64%), com tinta única turquesa-900 (4,99), anel turquesa-600 (4,60) e véu de luz turquesa-300 a 35% no canto do texto (ΔL 5,84). A solução veio da §9.2 do estudo-viver-de-ia.md: --primary: #00EBCF — a primária da plataforma é um turquesa vivo a 1,1° de matiz do nosso turquesa-300; o navy dos prints é superfície de tema escuro, e nas duas rodadas anteriores eu havia copiado a superfície deles deixando o nosso turquesa como enfeite. S3 revisto · S4 RETIRADO (a ação volta à família da marca e o conflito com o §3.5 de marca-seed.md deixa de existir; a régua vigente é turquesa-600 #098475 + branco = 4,60, o hex que o §3.5 nomeia) · S11, S11-b e S12 novos (âncora cromática; a palavra "escuro" sai do contrato do PN21c porque era descrição de implementação, não invariante; e a fronteira de 3,0 passa a distinguir COMPONENTE de CONTEÚDO — a pílula interativa deve 3,0 pelo SC 1.4.11, o chip de status é isento porque a norma exige dele o texto pelo 1.4.3, medido em 6,58). Ação dentro da âncora desceu a turquesa-800 por decisão do Rafael (texto 9,37 · fronteira 3,45; o 700 reprovaria a 2,33). Defeito da rodada, pego pela quinta camada: token fantasma — o molde passou a consumir turquesa-400/600/700 e a lista PRIMITIVOS do gerador ainda era a da era do azul; variável CSS indefinida é valor inválido, e 15 textos foram medidos com razão 1,0–1,26, incluindo branco sobre branco. Detector NV-01 criado nesta suíte (existia na de navegação e faltava aqui). Preview v0.8, cinco camadas verdes 139 · 37 · 142 · 6 · 78. PN-P1 encolheu de três decisões para uma e meia. · v0.62: PROMOÇÃO DO §48 PAINEL A estável — BLOCO 6C FECHADO, e com ele a FASE 6 chega a 3/3 (6A Shell · 6B Página institucional · 6C Painel). Gate visual do Rafael aprovado em 2026-08-13 sobre o preview v0.6, depois das quatro camadas automatizadas: suite-painel.mjs 133/133 · render-painel.mjs 37/37 · render-edicao.mjs 142/142 · render-contraste.mjs 6/6 · contraste-painel.py 70/70 — primeiro bloco do projeto validado em CINCO camadas, e a quinta nasceu de um defeito que as outras quatro não podiam ver (contraste de token verde com composição renderizada reprovando a 1,48). RESSALVA FORMAL DA PROMOÇÃO, escrita no cabeçalho do §48 para não se perder: o estável cobre os contratos PN1–PN54; não cobre as três decisões de MARCA da camada visual — S3 (escuro estrutural azul-800 #004C61, croma 0,380), S4 (a ação usa o escuro estrutural: primária sobre claro azul-800+branco 9,52, pílula branca dentro do escuro 13,70, azul-400 no tema escuro — em conflito declarado com o §3.5 de marca-seed.md, que manda ação sempre em turquesa/verde) e S6 (tinta da família, text-primary #0B3330 × branco 13,72). As três seguem PROPOSTA, vivem no preview (a tinta como camada alternável) e são a pendência PN-P1, que bloqueia o resto do DS — ERP, e-mail, documentos e site — até ser registrada em marca-seed.md e refletida nos gêmeos de token v1.8 → v1.9. Próximo bloco, nesta ordem: as decisões de marca (PN-P1), porque nada mais avança sem elas. Demais pendências herdadas e nomeadas em §48.9: PN-P2 (bloco 6D — dependências FS/SS/FF/SF com lag, caminho crítico, linha de base, marco) · PN-P3 (§49 painel de detalhe) · PN-P4 (malha nacional: a canônica cobre só MG/ES/BA, 1.348 municípios) · PN-P5 (SH-P1, aberta desde o 6A) · PN-P6 (três medidas de composição sem guarda automatizada) · PN-P7 (retroativos nos outros 40 HTML). Nenhum artefato executável foi alterado nesta promoção — os cinco placares acima são os da rodada 3, re-executados contra o preview v0.6 final e conferidos por leitura de volta a partir do pacote entregue. · v0.61: o §48 (Painel) é escrito por inteiro — PN1–PN54 — e o bloco 6C fica pronto para o gate visual único.** Entram nesta edição: a edição direta (PN22–PN41, mais PN34b, PN35b e PN41b–e) sob a norma WCAG 2.2 SC 2.5.7 Dragging Movements (AA), governada por uma regra só — onde o item cai é o valor do campo (PN33); os cinco contratos que o gate do Rafael produziu (PN46 política de trava é do domínio · PN47 pré-requisito de lente passa de "todos" para "alguém" + gaveta de não agendados · PN48 régua de tempo em dois níveis · PN49 criar arrastando na faixa vazia · PN50 menu de contexto e cartão de edição); a lente mapa em dois modos (PN51–PN54, cobertura padrão × operação, com fallback declarado e alternativa textual como conteúdo); a camada visual reorganizada em PN21a–h; e a seção 48.8 com dez supersedes formais, cada um com o número que o motivou. PN42–PN45 ficam RESERVADOS e vazios — são o bloco 6D (dependências FS/SS/FF/SF com lag, caminho crítico, linha de base, marco) —, e o vão de numeração é intencional: os cinco artefatos executáveis já citam PN46–PN54, e renumerar invalidaria âncoras MD5 recém calculadas. Subseções reordenadas com autorização do Rafael (a ordem era 48.1 → 48.2 → 48.4 → 48.5 → 48.3, com "Os 7 testes" depois do lote 2 e o PN21 como linha de tabela órfã sem cabeçalho). Cinco camadas de validação verdes contra o preview v0.6: suite-painel.mjs 133 PASS · 0 FAIL · render-painel.mjs 37 · 0 · render-edicao.mjs 142 · 0 · render-contraste.mjs 6 · 0 · contraste-painel.py 70 · 0. Camada nova: render-contraste.mjs, nascida de uma lição medida — contraste de TOKEN não substitui contraste de COMPOSIÇÃO: todos os pares do script Python estavam verdes enquanto, no tema escuro, a ação primária em azul-800 media 1,48 de superfície contra o cartão e a secundária tinha texto azul-800 sobre cartão escuro (1,48, ilegível); nenhum par estava errado, a combinação estava. Errata E-6C-01: o <title> do preview declarava preview v0.3 enquanto o selo na tela declarava v0.5 — duas versões no mesmo arquivo, e a guarda HIG-03 passava porque media apenas presença. Grave porque o título da aba é o primeiro sinal de arquivo fresco (três relatos de "não funciona" nesta sessão foram cache). Conserto estrutural: fonte única VERSAO_PREVIEW no gen-painel.py, consumida por @@VERSAO_TITULO@@ e @@VERSAO@@ — divergir deixa de ser possível; preview a v0.6 porque o arquivo corrigido tem de ser distinguível na tela. Guarda de regressão permanente creditada ao Rafael: HIG-06 (título e selo declaram a mesma versão), provada contra artefato com defeito plantado — reprova em exatamente 1. Pendência que bloqueia o resto (PN-P1): as decisões de MARCA S3 (escuro estrutural azul-800 #004C61, croma 0,380), S4 (a ação usa o escuro estrutural, em conflito declarado com o §3.5 de marca-seed.md) e S6 (tinta da família, text-primary #0B3330 × branco 13,72) vivem hoje no preview — a tinta como camada alternável — e precisam de registro em marca-seed.md mais gêmeos de token v1.8 → v1.9. Demais pendências nomeadas em §48.9: PN-P2 (6D) · PN-P3 (§49 painel de detalhe) · PN-P4 (malha nacional: a canônica cobre só MG/ES/BA, 1.348 municípios) · PN-P5 (SH-P1, aberta desde o 6A) · PN-P6 (três medidas de composição sem guarda automatizada: massa escura ≤32% da primeira dobra, hero ≤35% da altura, página ≥248 de luminância média) · PN-P7 (retroativos nos outros 40 HTML). Nota de determinismo: o selo carimba data e hora, então regenerar o preview muda o MD5 sem mudar comportamento — conferido, a cadeia de geração 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. · v0.47: promoção do §45 Iconografia a estável — BLOCO 7 FECHADO 1/1 e, com ele, a FASE 3 INTEIRA: 7/7 BLOCOS. Gates cumpridos, nomeados um a um: (a) suite jsdom suite-icones.mjs 25/25 ✓; (b) render render-icones.mjs 5 verificações / 0 achados (getBBox IC2 de 28/28 dentro de 1…23 · currentColor resolvido em cor renderizada · célula ≥44px · faixa 360px sem overflow · dark re-renderiza o glifo); (c) contraste — 6 pares non-text ≥3:1 medidos por script ANTES da spec; (d) regressão total ancorada por MD5, e não mais por tamanho de arquivo: 445 verdes jsdom (feedback 55 · espera 44 · rotulagem 28 · sobreposição 25 · empty 14 · superfícies 80 · CN 45 · navegação 90 · dados 39 · ícones 25) + 43 verificações render / 0 achados (38 suite-render sobre CINCO previews + 5 render-icones) + 4 scripts de contraste, todos os pares no gate WCAG; (e) gate visual do Rafael APROVADO em 2026-08-07. O fato de método central deste marco NÃO é a iconografia — é o DEFEITO DE PROPAGAÇÃO DO BLOCO 5, corrigido aqui: o seed-navegacao-preview.html v0.40 havia sido sobrescrito no repositório do Drive pelo v0.37 defasado em 2026-08-06 22:54, e o defeito passou despercebido porque a propagação era afirmada e nunca lida de volta — consequências medidas: a suite de navegação rodou 58/58 em vez de 90 (verde e errada) e a suite-render ABORTOU no bloco R8 com TypeError procurando #cp-dialog. O v0.40 sobreviveu por acaso, na pasta de downloads dos cards de entrega, e foi resgatado de lá. Dois artefatos de validação do Bloco 5 foram PERDIDOS e RECONSTRUÍDOS a partir desta spec (§36–§39, íntegra e estável): a suite-navegacao.mjs de 90 testes (58 originais 5A/5B preservados + 32 novos BC-01…04 · PG-01…08 · ST-01…09 · CP-01…10 · NV-01) e o contraste-navegacao.py (5 pares — os 5 medidos batem com o registrado no marco v1.2). Declaração de proveniência obrigatória: o 90/90 e o resultado de contraste do Bloco 5 são EVIDÊNCIA NOVA de 2026-08-07, não a evidência histórica do marco v1.2 — aquele placar foi executado contra artefatos que nunca chegaram ao repositório e hoje não é reproduzível. Emenda ERRATA-NAV-01 (falso-positivo de suite, não bug de componente): os guardas TB-24/MN-25 ("nenhum botão morto") foram escritos na v0.37 e desconheciam os 12 botões que 5C/5D/5E trouxeram no v0.40 — a lista de exclusão foi estendida SEM enfraquecer o guarda, porque cada um dos 12 passou a ter teste de liveness dedicado (BC-03 · PG-05 · PG-06 · ST-04 · ST-05 · ST-08 · ST-09 · CP-02 · CP-07). Nasce a âncora por hash: validacao/MANIFESTO.md — tabela de nome · versão · bytes · MD5 · consumidor · placar de todo artefato canônico, mais a REGRA DE PROPAGAÇÃO vigente: todo artefato salvo é verificado por LEITURA DE VOLTA (título/versão + MD5 conferidos contra a tabela), nunca por afirmação de que foi salvo. Racional: sem hash publicado, "regressão byte-perfeita" não tem referente — foi por isso que 21 de 21 arquivos passaram verde por tamanho enquanto um era a versão errada. Regra de transporte nova: o conector do Google Drive não serve para transportar artefato de regressão (base64 reemitido corrompeu silenciosamente 3 vezes num único arquivo — um byte extra e duas trocas de caractere Unicode); anexo em zip vira o padrão. Correção de documentação: a suite-render.mjs consome CINCO previews, não quatro (4 no laço + dados nos blocos R9/R10; aritmética 7×4 + R7 2 + R8 2 + R9 4 + R10 2 = 38). Pendências novas: alinhar a skill seed-ds-ui com a árvore de decisão NM4 (quando usar glifo do set SEED × quando usar Lucide) + o mapa de equivalências SEED↔Lucide (mesmo padrão da GI2 do marco v1.3) · normalizar o esquema de caminho das suites (hoje 4 pastas, misturando import.meta.url e caminho absoluto embutido) — adiada de propósito, porque editá-las agora mudaria o MD5 recém-ancorado. Próximo: marco v1.4 (padrão delta) e abertura da fase seguinte. · v0.46: abre o Bloco 7 (Iconografia) — §45 em rascunho: guidelines IC/NM + inventário do set canônico (lotes 7A+7B em modo autônomo). Consolidado IC1–IC7 + NM1–NM6 aprovado pelo Rafael em 2026-08-07 ("aprovo") após 3 rodadas encadeadas (R1 canon: Lucide design rules/Material icon grid+keylines/Carbon sizes → R2 mercado/stack: shadcn+lucide-react (o consumo real do GI4), Heroicons, Phosphor → R3 normas/fora-do-circuito: WAI decorative images, contraste non-text 3:1, prática CFPB/Carbon de aliases de busca). Nota de continuidade: o chat do lote estourou o contexto antes de persistir os artefatos; nada do trabalho autônomo havia sido gravado no Drive — o lote foi RE-EXECUTADO nesta sessão sob o mesmo consolidado aprovado (as decisões são o artefato gateado; inventário/vereditos eram produção autônoma ainda sem gate, re-produção legítima). Base medida do acervo (script sobre o HTML v1.0): 54 <svg>; grid nominal de 24 ícones nomeados em 40×40 stroke 1.8 (= 1.08px equivalente a 24px — abaixo do peso da UI) + 5 glifos de pilares + 3 de valores em 24×24. Set canônico resultante: 28 glifos ativos = 23 do acervo normalizados (40→24, fator 0.6, stroke 2, round/round) + substation (pilar aproveitado) + bolt/generator REDESENHADOS na régua (fill→stroke; motor idx14 simplificado) + transformer/lightning-rod NOVOS (gaps dos pilares Subestações MT e SPDA fechados). 7 vereditos de governança: renome add→circle-plus (NM1 conceito-variante, supersede) + 6 aposentadorias por duplicata (pilares/valores → glifos do set). Contraste non-text medido por script ANTES da spec: 6 pares consumidos ≥3:1 ✅ (text-primary×surfaces 13.35–15.59 · text-secondary 5.06 · feedback-success 4.60). Preview NOVO seed-icones-preview.html v0.46 (grid com metadados data-, busca por aliases PT/EN — consumo da ⌘K §39 —, escala IC4, provas antes/depois de peso e SEED×Lucide, dark/grayscale/360px, zero elemento morto) + suite nova suite-icones.mjs 25/25 ✓ (1 correção de escopo de teste na 1ª execução: alias subestacao é legítimo em substation E transformer — falso-positivo de suite, não bug) + render render-icones.mjs 5 verificações/0 achados (getBBox IC2 de 28/28 dentro de 1…23 · currentColor resolvido · célula ≥44px · 360px sem overflow · dark re-renderiza). Pendente: regressão total + gate visual do Rafael → promoção FECHA A FASE 3 → marco v1.4. · v0.45: promoção do lote 2 — §42 toolbar, §43 lista de dados e §44 guia de integração a estável: BLOCO 6 (DADOS) FECHADO 5/5 (§40 tabela · §41 seleção · §42 toolbar · §43 lista de dados/degradação · §44 guia). Gates: suite 39/39 + render 38/0 + regressão total 519 verdes + gate visual do Rafael aprovado em 2026-08-06 ("ok"). Nota do marco: os DOIS gates humanos do bloco passaram SEM errata — primeira vez na F3; a camada render absorveu as classes mecânicas (2 bugs reais pegos por ela no lote 1) e os detectores herdados pegaram as reincidências sozinhos. Pendências encerradas no bloco: indeterminate (§10/B2, via SL2) · busca composta EUI (B2, via TD1) · densidade ERP→mobile (B2, via DT2+LD2). Pendências novas registradas: alinhar a skill seed-ds-ui à camada semântica (GI2) · "Show Details" dos low ocultos (LD5, com demanda) · variante de paginação com total desconhecido (PG5/DT8, com demanda). Próximo: marco v1.3 (padrão delta) → Bloco 7 (Iconografia) fecha a Fase 3. · v0.44: lote 2 do Bloco 6 — §42 toolbar de dados (TD) + §43 lista de dados/degradação (LD) + §44 guia de integração (GI) em rascunho. Pesquisa: EUI SearchBar/FilterGroup + Innovaccer/shadcn-blocks (chips de filtro aplicado com contagem viva) + Dynamics (toolbar inline×stacked) para o TD; MDN/eBay evo/Ben Myers/Fedotov (dl com grupos em div; dl×table para pares rótulo-valor) + Fiori pop-in/importância de coluna (fonte já desta sessão) + Setproduct (régua tabela×cards×lista) para o LD; leitura obrigatória da skill seed-ds-ui para o GI — 1 ponto de coerência real achado e documentado (a skill consome primitivos+aliases shadcn; o DS entrega semânticos --seed-* → cadeia de 3 camadas formalizada no GI2 + pendência de alinhamento da skill registrada, não é conflito bloqueante). Nenhum par novo (tudo herdado, incl. o chip do §22). Preview v0.44 + suite 6C/6D (39/39 ✓; os detectores do marco v1.2 pegaram sozinhos o mesmo token fantasma e a whitelist desatualizada na 1ª execução — as lições 9.3/9.4 agora são automáticas) + render R10 (chips pintados; degradação cards renderizada no 360: linha=bloco, coluna low oculta, zero overflow) — 38 verificações, 0 achados. Teste de integração TD-04 prova a SL5 (filtro limpa seleção). Pendente: gate do Rafael → promoção fecha o BLOCO 6. · v0.43: promoção do lote 1 — §40 tabela e §41 seleção a estável. Gates: suite 27/27 + render R9 (2 bugs reais pegos pela camada: sticky×border-collapse, guarda DT-13; piso da compacta) + regressão total verde + gate visual do Rafael aprovado em 2026-08-06 ("correto"). Pendência do indeterminate (§10, aberta desde o B2) formalmente encerrada pela SL2. · v0.42: Bloco 6 (Dados) aberto — LOTE 6A+6B: §40 tabela base (DT1–DT8) + §41 seleção/ações em massa (SL1–SL5) em rascunho. Estrutura do bloco aprovada pelo Rafael (5 sub-blocos 6A–6E em 2 lotes; códigos DT/SL/TD/LD/GI). Pesquisa 3 rodadas por sub-bloco (~18 fontes: corpus Roselli de tabelas — sortable/aria-sort/responsivo/"Don't Turn a Table into an ARIA Grid", 2023 — · Carbon data table/batch actions · Fiori responsive×grid table com importância de coluna e pop-in (a fonte da degradação mobile, que fica para o 6D) · TanStack row selection (a stack do Lovable: indeterminate, ids estáveis, shift-range) · Polaris/Gmail). 7 pares novos MEDIDOS antes da spec (contraste-dados.py ✅): seleção 12.92/11.23 · header 6.03/8.92 · seta ativa 4.23 · borda 4.28. Preview NOVO seed-dados-preview.html + suite-dados.mjs 27/27 ✓ (5 correções de teste na 1ª execução: dispatch nativo de checkbox alterna o checked; nó morto pós-render — falso-positivos de suite, lição 9.4 confirmada) + render R9: a camada pegou 2 BUGS REAIS antes do gate humano — border-collapse:collapse quebrando o sticky do th (correção canônica: separate; guarda DT-13) e a densidade compacta rendendo 37px porque o controle de 36px segurava o piso (controles reduzidos na compacta; 33px medido) — mais 1 asserção do próprio auditor refinada (o deslocamento inicial do sticky é o caption rolando, legítimo). Render total: 36 verificações, 0 achados. Pendente: gate do Rafael no lote → promoção → lote 2 (6C+6D+6E). · v0.41: promoção em lote dos §36–§39 a estável — BLOCO 5 (NAVEGAÇÃO) FECHADO 6/6 (§34 tabs · §35 menu · §36 breadcrumb · §37 paginação · §38 stepper · §39 ⌘K). Fecha a 2ª metade do marco v1.2 e valida o 1º lote do modo autônomo: 4 itens produzidos sem paradas, 2 erratas do gate visual do Rafael (ação terminal do wizard; token fantasma da palette), ambas com teste-guarda + detectores permanentes nas duas camadas. Gates: consolidados BC/PG/ST/CP aprovados → specs + preview v0.40 + suite jsdom 90/90 ✓ + suite-render 32 verificações/0 achados (Ctrl+K real em :modal, 360px em pixels, fundo opaco, tokens fantasma) → regressão total 381 verdes (A–E 166 + F 80 + CN 45 + Bloco 5 90, sobre os canônicos v0.23b/v0.32b) → gate visual do Rafael aprovado em 2026-08-06. Pendências encerradas neste bloco: AC5 (TB1) · fronteira do §20 (ST1) · promessa do §4.11 (CP2) · ponto DW1 (CN6, na 1ª metade). Próximo: marco v1.2 (padrão delta) → Bloco 6 (Dados). · v0.40: 1º LOTE DO MODO AUTÔNOMO — 5C+5D+5E completos: §36 breadcrumb (BC) · §37 paginação (PG) · §38 stepper (ST) · §39 command palette (CP), todos em rascunho. Produção contínua sem paradas (nenhum ponto de decisão genuíno surgiu; 1 quase-ponto resolvido com régua dupla documentada no ST — evidência GOV.UK/DWP contra indicadores em serviço público × wizard Fiori para ERP, precedente do B3). Pesquisa: 3 rodadas por sub-bloco (~20 fontes novas — detalhadas em cada §). Nenhum par de cor novo nos 4 itens (tudo herdado e declarado por seção). Preview v0.40 (4 demos novas) + suite jsdom 87/87 ✓ (3 correções de escopo de teste na 1ª execução: whitelists TB-24/MN-25 e independência de ordem do ST-06 — falso-positivos de suite) + suite-render estendida com cenários do lote: Ctrl+K REAL abrindo :modal nativo com foco no input e activedescendant conferido em pixels; 360px com stepper vertical, paginação compacta e zero overflow — 28 verificações render, 0 achados. Regressão jsdom completa verde na mesma execução (A–E 166 + F 80 + CN 45 sobre os canônicos v0.23b/v0.32b). Errata do gate visual do lote (2026-08-06, crítica do Rafael — "o item 4 não finaliza com check"): na última etapa o Avançar era botão morto — o wizard nunca CONCLUÍA, e a etapa final nunca ganhava o ✓; a própria ST4 já apontava o desenho certo (Fiori: a Revisão termina em SUBMISSÃO explícita). Corrigido: na última etapa o botão primário vira "Concluir proposta"; concluir fecha o processo (4/4 ✓, corrente removida, mensagem de envio, variante-texto vira "Concluído — 4 de 4"). Regra que fica na ST4: o wizard SEMPRE termina numa ação terminal nomeada — nunca num Avançar inerte. Testes-guarda ST-08/09. Errata 2 do lote (mesma data — screenshot do Rafael: "olha como o Ctrl+K abre"): a palette abria TRANSPARENTE — o CSS consumia var(--seed-surface-overlay) e o token não existia neste preview (token fantasma: variável indefinida = valor inválido = fundo transparente, conteúdo da página vazando através do modal). Corrigido: token definido nos dois temas (branco / #273137) e a regra dark unificada na mesma fonte. Classe nova de defeito ganhou detector genérico nas DUAS camadas: NV-01 na suite jsdom (todo var(--seed-) consumido tem definição — protege qualquer extensão futura) e R5b na suite-render (varre os 4 previews) + verificação de fundo OPACO renderizado da palette (rgb branco confirmado em pixels). Régua permanente: token consumido sem definição é bug de build, não de tema — as duas suites reprovam. Suite jsdom 90/90 ✓ · render 32 verificações, 0 achados. Pendente: leitura das decisões pelo Rafael + gate visual dirigido + promoção em lote (→ v0.41 + marco v1.2). · v0.39: camada nova de validação — GATE DE GEOMETRIA AUTOMATIZADO (suite-render.mjs) + auditoria retroativa dos 4 previews canônicos + MODO LOTE autorizado pelo Rafael. Contexto: descoberto Chrome real no ambiente de execução → nasce a suite-render (Chrome headless medindo o RENDERIZADO: recorte de anel de foco em overflow, alvos de toque reais, overflow horizontal 360px, links em estilo default de user-agent, erros de console, empilhamento por elementFromPoint, screenshots light/dark/grayscale/360 por preview). Auditoria retroativa (26 verificações × 4 previews): estrutura aprovada — zero recorte de foco (valida a errata TB-28), zero link default, zero overflow 360, empilhamento real confirmado (popover sobre drawer na CN; menu sobre a página). 2 erratas REAIS de implementação de preview (classe idêntica à errata v0.13 — specs já mandavam, previews divergiam): (a) feedback: gatilhos ⓘ/toggletip com style inline 28px SOBRESCREVENDO a classe de 44px sem hitbox → ::after inset -8px (alvo visual 28 mantido, alvo real ~44, padrão W4); (b) superfícies: +N do avatar 32px SEM a "hitbox herdada" que o §32/teste 7 declara textualmente → ::after inset -6px. Previews corrigidos viram os novos canônicos: seed-feedback-preview.html v0.23b e seed-superficies-preview.html v0.32b — regressões futuras apontam para eles; suites jsdom re-executadas TODAS verdes sobre os corrigidos (A–E 166 + F 80 + CN 45 + nav 58 = 349). Transparência do auditor: 2 falso-positivos do detector corrigidos (hitbox via ::after não era vista; 403 de fontes = proxy do ambiente de execução, não bug) e 2 tolerâncias documentadas com porquê (chip 28px = densidade spec'd §22 com X interno em hitbox 44; checkbox 20px dentro de linha §28 cujo alvo real é a linha 44px). MODO LOTE (autorizado 2026-08-06): produção autônoma de sub-blocos completos (pesquisa→consolidado→spec rascunho→preview→suite jsdom→suite render→regressão→auto-auditoria de percepção), com paradas APENAS em ponto de decisão genuíno; interação do Rafael comprimida a 3 momentos por lote (leitura das decisões · gate visual dirigido com screenshots · aprovação em lote); nada promove a estável sem ele. Piloto: 5C+5D+5E. · v0.38: promoção do §35 menu/dropdown a estável — 5B fechado (2/5 do Bloco 5). Gates: consolidado MN1–MN8 → spec v0.37 + preview + suite → 3 erratas/emendas do gate visual do Rafael, todas com teste-guarda (Tab-fecha/Esc-global/focusout · setas opcionais APG no disclosure · anel de foco interno em container com overflow — esta última emendando também o §34, padrão AV5) → regressão completa: A–F byte-perfeitas 246 + CN 45 + Bloco 5 58 = 349 verdes; contraste-navegacao.py ✅ → gate visual do Rafael aprovado em 2026-08-06. Réguas novas que ficam: "um menu aberto nunca sobrevive à saída do foco" e "anel de foco sempre interno dentro de overflow". Próximo: 5C — breadcrumb (BC) + paginação (PG). · v0.37: 5B — §35 menu/dropdown em rascunho. Consolidado MN1–MN8 aprovado após 3 rodadas (~24 fontes: R1 NN/g Menu-Design Checklist + NN/g Dropdowns (comando ≠ atributo; "gray out em vez de remover") + Carbon Menu/Overflow Menu + Polaris ActionList → R2 Radix DropdownMenu (menu button APG 1:1) + Wootonn (input dentro de role=menu = conflito estrutural) → R3 corpus Roselli 2017–2026 + APG Disclosure Navigation (navegação nunca usa roles de menu) + Terrill Thompson + Fiori Menu Button/Action Sheet). Decisão central MN1: fronteira semântica de 4 saídas (ação=menu · navegação=disclosure de links · valor=select/combobox B2 · conteúdo rico=popover §24) com PROIBIÇÃO de input dentro de role=menu. MN6 registra a exceção documentada da linha "sem disabled": item de menu indisponível fica visível, aria-disabled, navegável pelas setas e com motivo — critério: menu é inventário de comandos (NN/g), diferente da aba (TB8). Pares novos MEDIDOS antes da spec (contraste-navegacao.py, todos ✅): destrutivo ve-700/branco 7.18 · ve-700/ci-50 6.61 · ve-200/overlay 8.67 · atalho/indisponível ci-600/branco 4.74 · ci-300/overlay 6.94. Preview estendido para v0.37 (menu de ações, overflow ⋯ com alternáveis, disclosure de links) + suite seção 5B: 52/52 ✓ no total (2 correções de escopo de teste na 1ª execução: whitelist do TB-24 e dispatch de Esc — falso-positivos de suite, não bugs de componente). Errata do gate visual (2026-08-06, crítica do Rafael — "Tab pula pra fora e Esc não fecha"): dois sintomas, uma raiz. Esclarecimento de padrão: Tab SAIR do menu é o comportamento APG correto (setas navegam itens; Tab sai — Radix/Carbon/SO idem); o bug era o menu FICAR ABERTO ao sair — o APG manda "Tab closes the menu", e com o foco fora, o Esc (que morava dentro do menu) ficava surdo. Corrigido em 3 camadas: Tab fecha (APG literal) + Esc global fecha qualquer menu aberto com o foco onde estiver + focusout fecha ao perder o foco. Testes-guarda MN-26/27/28; régua na spec: um menu aberto nunca sobrevive à saída do foco. Emenda 2 do gate visual (mesma data — "no disclosure não consegui navegar com as setas"): não era bug — no disclosure os links navegam por Tab (são links comuns), o oposto do menu; mas o próprio APG Disclosure Navigation prevê o tropeço e traz suporte opcional a setas no exemplo oficial. Crítica do Rafael = evidência de campo com o perfil de usuário real → opcional adotado: ↓ no trigger abre focando o 1º link; ↓↑ movem entre links sem wrap (distinção deliberada do role=menu); Tab continua navegando (links permanecem no fluxo, sem roving). Testes-guarda MN-29/30. Errata 3 do gate visual (mesma data — screenshot do Rafael: anel de foco cortado nas abas): o tablist com overflow-x:auto (rolagem TB6) recorta o que desenha fora da caixa — o anel externo global (offset +2px) era decepado, pior na 1ª aba. Corrigido: anel INTERNO (outline-offset:-2px) nas abas, mesmo padrão das linhas de lista §28; régua que fica na spec: dentro de container com overflow, o anel de foco é sempre interno. Teste-guarda TB-28. Suite: 58/58 ✓. Pendente: regressão byte-perfeita e gate visual. · v0.36: promoção do §34 tabs a estável — 5A fechado (1/5 do Bloco 5). Gates cumpridos: consolidado TB1–TB8 aprovado → spec v0.35 + preview novo do bloco + suite 5A 27/27 ✓ (console limpo) → regressão completa na mesma execução: A 55 + B 44 + C 28 + D 25 + E 14 + F 80 (byte-perfeitas) + CN 45 + 5A 27 = 318 verdes; contrastes ✅ → gate visual do Rafael aprovado em 2026-08-06 (rolagem/fade/setas de overflow, indicador renderizado, grayscale, skeleton do lazy, deep-link no browser real). Pendência AC5 formalmente encerrada pela TB1. Próximo: 5B — menu/dropdown (MN). · v0.35: abre o Bloco 5 (Navegação) — 5A: §34 tabs em rascunho. Ordem do bloco aprovada pelo Rafael em 2026-08-06 (5 sub-blocos: 5A tabs TB · 5B menu/dropdown MN · 5C breadcrumb BC + paginação PG · 5D stepper/wizard ST · 5E command palette CP — fronteira: sidebar/topbar é shell do F6, consome este bloco). Consolidado TB1–TB8 aprovado após 3 rodadas encadeadas (~24 fontes: R1 GOV.UK Tabs íntegra + NN/g Tabs Used Right + NN/g tabs×accordions + ONS + Carbon usage/accessibility + Spectrum tabs-overflow → R2 Radix (activationMode) + React Aria (keyboardActivation) + issue de campo #2915 → R3 APG Tabs Pattern íntegra + AcceDe + a11y-collective + Fiori Icon Tab Bar 4 versões + Inclusive Components). TB1 resolve a pendência AC5 (régua tabs×accordion×mostrar-tudo×stepper×navegação). Preview novo do bloco seed-navegacao-preview.html v0.35 + suite-navegacao.mjs seção 5A: 27/27 ✓ (console limpo após guard de scrollIntoView ausente no jsdom — lição das APIs nativas). Nenhum par de cor novo (indicador tq-600/branco 4.60 e demais herdados §26/§28). Pendente: regressão A–F+CN byte-perfeita e gate visual (overflow/rolagem/indicador renderizado). · v0.34: promoção do §33 Central de Notificações a estável — 1ª metade do marco v1.2 CONCLUÍDA. Gates cumpridos na ordem: consolidado CN5–CN12 aprovado → spec v0.33 + preview novo + suite (45/45 ✓ após 3 erratas do gate visual antecipado do Rafael, todas com teste-guarda) → regressão A–F byte-perfeita sobre os arquivos originais anexados pelo Rafael: A 55 + B 44 + C 28 + D 25 + E 14 (feedback v0.23) + F 80 (superfícies v0.32) + CN 45 = 291 verdes; contraste.py e contraste-superficies.py todos os pares ✅; suite-cn.mjs do Drive confirmada byte-idêntica à canônica → validação visual formal do Rafael (2026-08-06): empilhamento renderizado, geometria do popover, show() nativo, tray 360px, dark e grayscale — APROVADO. A regressão intacta prova que a CN não tocou nada compartilhado dos previews canônicos. Próximo: abertura do Bloco 5 (Navegação), 2ª metade do marco v1.2. · v0.33: abre o §33 — Central de Notificações (pattern F6) em rascunho, 1ª metade do marco v1.2. É COMPOSIÇÃO pura: sino (§1) + badge dot (§21) + popover/tray (§24) + drawer standard (§31) + lista com os slots LS5 (§28) + empty esvaziado (§25) + toast (§17/CN2) — nenhum componente novo nasce. Base: 3 rodadas encadeadas (~26 fontes: R1 Carbon notifications pattern na íntegra (painel em conjunto com toasts; ordem cronológica; WCAG 2.2.3/2.2.4) + PatternFly notification badge/drawer v3–v6 (a spec de painel mais completa do canon) + NN/g + Smashing 2025 + UX Mag + evidência de campo Atlassian community (badge que zera ao abrir faz esquecer não-lidas; mark-all-read que não persiste quebra confiança) → R2 EUI Header (sino com prop notification; lista em EuiPopover OU EuiFlyout — as 2 superfícies) + EUI #4257 + Knock (modelo unseen/seen/read; badge default unseen p/ feed social) + Novu (#955 mark-all-read desabilitado sem itens; seen one-way) → R3 Fiori Notifications (cronológica "como inbox"; agrupamento é recurso de ALTO volume; dismiss ≠ processado; 2 linhas + Show More) + Sara Soueidan live regions 1–2 (região nomeada) + APG feed (proposta SEM consenso do TF — descartada) + APG alertdialog (aria-modal só quando bloqueia de fato)). Consolidado CN5–CN12 aprovado pelo Rafael em 2026-08-06 — inclui a resolução do ponto em aberto do DW1: o drawer da CN é regime STANDARD (CN6). Preview NOVO: seed-cn-preview.html v0.33 (justificativa: pattern F6 exige chrome simulado + simulador de background, e o preview separado preserva a regressão A–F byte-perfeita sobre os canônicos intactos); suite nova suite-cn.mjs executada: 40/40 ✓ na primeira execução (41/41 após a errata abaixo); nenhum par de cor novo (tudo herdado dos §17/§21/§24/§25/§26/§28/§30–§31, medidos). Errata do gate visual (2026-08-06, crítica do Rafael): na prova grayscale em dark, o link de teste da página sumia quando não-visitado — o <a> estava SEM estilo (cor default do browser, fora do sistema de tokens), violando "cor só via token" e o mecanismo-além-de-cor; corrigido com --seed-text-link (par já medido do §26: tq-600/branco 4.60 AA light · tq-300/dark-page 9.32 AAA dark) + sublinhado sempre (o sinal que sobrevive ao grayscale) + teste-guarda CN-41 na suite. Errata 2 do gate visual (mesma data, crítica do Rafael — "botão 2 e 3 era pra fazer alguma coisa?"): os simuladores de resolução e de erro só mudavam estado DENTRO do painel fechado — e, com o painel aberto, o próprio light-dismiss engolia a demonstração; ação sem resultado visível viola o ack imediato da Régua de Espera e o espírito do "nenhum botão morto". Corrigido: os simuladores abrem o painel para exibir o resultado (empty / slot de erro); testes-guarda CN-42/CN-43. Errata 3 do gate visual (mesma data, crítica do Rafael — "não acontece nada quando clico no link"): o link de teste da página apontava para #app-chrome (topo de página curta com topbar sticky = navegação sem efeito visível). Corrigido com a semântica certa: a PROVA de página-viva sob o drawer standard virou botão com contador visível (link navega, botão age) e o link ganhou alvo real no rodapé com destaque :target (borda no token + fundo, mecanismo além de cor) e tabindex="-1"; testes-guarda CN-44/CN-45, incluindo o contador incrementando COM o drawer standard aberto — prova executável do CN6. Na sequência, o CN-38 (botão morto) flagrou o botão novo fora da whitelist — falso-positivo de teste corrigido no escopo, não bug de componente (mesmo caso do accordion v0.27, registrado por transparência). Suite final: 45/45 ✓. Reconfirma a lição dos marcos: a suite valida comportamento — visibilidade percebida e cor default de user-agent são território do gate visual. Nota de nomenclatura acessível: as superfícies da CN chamam-se "Central de notificações" para não colidir com a landmark "Notificações" da região de toasts (§17). Pendente: regressão A–F byte-perfeita (anexar arquivos de /validacao + os 2 previews canônicos) e validação visual do Rafael antes da promoção. · v0.32: promoção do §32 avatar a estável — BLOCO 4 (SUPERFÍCIES) FECHADO 7/7: card §26 · divider §27 · lista §28 · accordion §29 · modal §30 · drawer §31 · avatar §32. Validação visual do Rafael em 2026-08-05, após 1 ciclo de crítica no avatar (2 defeitos reais pegos no gate visual: +N listava só os ocultos, quebrando a racional do AV5 — leitor de tela sem os 3 primeiros nomes — e popover sem light-dismiss do §24; emenda formal no AV5 + 3 testes-guarda). Validação executada final do bloco: suite F+G+H+I 80/80 ✓ + regressão A–E 166/166 ✓ = 246 verdes. Balanço do bloco: 2 ciclos de crítica (empilhamento H + avatar I), ambos geometria/comportamento nativo — a lição do marco v1.0 confirmada duas vezes. Próximo: marco v1.1 pelo padrão delta. · v0.31: abre o sub-bloco I — avatar (§32) em rascunho, último item do Bloco 4. Base: 3 rodadas encadeadas (~14 fontes: R1 Atlassian/AUI (pessoa E entidade; badge com descrição textual; decorativo quando agrupado com texto) + Polaris (tamanhos; formatos de alt) + Zuora (consistência de forma) → R2 Radix Avatar (imagem só renderiza carregada; fallback delayMs ~600) + shadcn (AvatarGroup/Count; parsing de iniciais) + Radix Themes → R3 W3C WAI decorative images (primária) + eBay evo (informativo role=img+aria-label × decorativo sem nada; img sempre alt=""; nunca focável) + EUI (iniciais máx. 2; type user×space)). Consolidado AV1–AV5 aprovado pelo Rafael em 2026-08-05. Preview v0.31; suite F+G+H+I 78/78 ✓ + regressão A–E 166/166 ✓ (total 244 verdes); 4 pares novos medidos: iniciais 5.43 AA light / 8.07 AAA dark; ícone 3.93/8.07 ✓. · v0.30: promoção do sub-bloco H a estável — §30 modal e §31 drawer aprovados na validação visual do Rafael em 2026-08-05, após 1 ciclo de crítica: o gate visual pegou bug real de empilhamento (drawer standard sem z-index atravessado pela página; X encoberto pelo chrome) → emenda formal da escala de sobreposição (60<65<70<75<80) + teste-guarda na suite. Validação executada final: F+G+H 64/64 ✓ + regressão A–E 166/166 ✓ = 230 verdes. Régua de 3 degraus fechada; drawer destrava a CN (F6). Resta o sub-bloco I (avatar) para fechar o Bloco 4. · v0.29: abre o sub-bloco H — modal (§30) + drawer (§31) em rascunho, fechando a régua de 3 degraus do §23.1. Base: 3 rodadas encadeadas (~24 fontes: R1 APG dialog pattern+exemplo + NN/g modal×nonmodal/popup problems + Smashing decision tree 2026 + notas GOV.UK/MoJ → R2 MDN showModal/::backdrop (Baseline mar/2022) + Radix Dialog/Sheet + Vaul + EUI flyout + top layer → R3 Scott O'Hara "Use the dialog element (reasonably)" (primária — a mesma fonte que vetava em 2019 liberou) + accessuse.eu + M3 side sheets + M2 bottom sheets). Consolidado MD1–MD5 + DW1–DW4 aprovado pelo Rafael em 2026-08-05. Preview v0.29; suite F+G+H 63/63 ✓ + regressão A–E 166/166 ✓ (total 229 verdes); backdrop declarado decorativo; nenhum par de texto novo (overlay reusa §17/§2.8). Nota de método: jsdom não implementa showModal — o preview usa dialog nativo no browser e shim de teste no jsdom (foco/estado testados; trap/backdrop nativos ficam no gate visual, mesma lógica da geometria). · v0.28: promoção do §29 accordion a estável — validação visual do Rafael aprovada em 2026-08-05, após validação executada completa (suite F+G 47/47 ✓ + regressão A–E 166/166 ✓ = 213 verdes). Bloco 4: restam H (modal+drawer) e I (avatar). · v0.27: abre o sub-bloco G — accordion (§29) em rascunho. Base: 3 rodadas encadeadas (~22 fontes: R1 APG/W3C + GOV.UK DS/blog de acessibilidade + ONS + Bristol + NN/g ×4 + AcceDe + Stanford → R2 Radix + shadcn + Base UI → R3 Scott O'Hara (primária, quirks de <details>) + regra ACT W3C do <summary> + MDN hidden="until-found"/beforematch + SAP Fiori panel/DDS accordion). Consolidado AC1–AC6 aprovado pelo Rafael em 2026-08-05. Preview v0.27 (accordion adicionado); suite F+G executada 47/47 ✓ + regressão A–E 166/166 ✓ (total 213 verdes); nenhum par de cor novo (chevron e hover reusam pares já medidos no F). Correção de escopo na suite: whitelist do teste de botão-morto passou a reconhecer os botões do accordion (falso-positivo de teste, não bug de componente — registrado por transparência). · v0.26: promoção do sub-bloco F a estável — card §26, divider §27 e lista §28 aprovados na validação visual do Rafael em 2026-08-05, após validação executada completa: suite F 32/32 ✓ + REGRESSÃO A–E re-executada sobre o preview v0.23 canônico byte-idêntico (55+44+28+25+14 = 166/166 ✓) + contraste (Bloco 3 ✅ + 9 pares novos ≥AA, decorativos declarados). Total acumulado 198 testes verdes. Próximo: sub-bloco G (accordion). · v0.25: abre o Bloco 4 (Superfícies) com o sub-bloco F — card (§26) · divider (§27) · lista (§28) em rascunho. Base: 3 rodadas encadeadas (~25 fontes: R1 M3 cards/divider/lists + Carbon tile/structured-list/contained-list + NN/g cards + Nathan Curtis + Berkeley DAP + M1 dividers → R2 shadcn card + EUI panel/card/list-group + React Aria GridList/ListBox/useSeparator + Angular Material + MUI divider → R3 Inclusive Components/cards como fonte primária + Adrian Roselli + Intopia + MDN/WAI-ARIA 1.2 separator + SAP Fiori list/object card + gov.br DS). Consolidado CD1–CD5 · DV1–DV3 · LS1–LS5 aprovado pelo Rafael em 2026-08-04 — códigos de decisão passam a 2 letras (alfabeto de letra única esgotado no Bloco 3). Preview NOVO: seed-superficies-preview.html v0.25; suite F executada (32/32 ✓); 9 pares de texto medidos (todos ≥AA) + 7 pares decorativos declarados com justificativa; regressão A–E pendente de re-execução (arquivos canônicos de /validacao a anexar) antes da validação visual. · v0.24: §25 empty state promovido a estável — BLOCO 3 COMPLETO: 11/11 em um único dia de trabalho (2026-08-04), com validação executada acumulada de 166 testes verdes (A 55 · B 44 · C 28 · D 25 · E 14) + ~40 pares de contraste medidos, 4 ciclos de crítica visual do Rafael absorvidos como emendas formais (R3-b/R3-c, X6-b + geometria, botão-morto de preview), 3 erratas estruturais descobertas pela suite (aria-invalid herdada consolidada, rótulo azul-700→800 do tokens, borda de chip) e 2 emendas de método permanentes (nota 1.13-b: dois regimes de anúncio; lição: suite valida comportamento, validação visual valida geometria). Sub-blocos: A severidade (alerta/banner/toast) · B espera (spinner/skeleton/progress + Régua) · C rotulagem (badge/chip) · D sobreposição (tooltip/popover) · E empty state. Próximo: fechamento de marco (roadmap v1.3 + checkpoint) antes do Bloco 4. · v0.23: empty state (§25) em rascunho — o último item do Bloco 3. Taxonomia de 5 tipos (primeiro-uso · esvaziado · zero-resultados herdando D8/D9 SEM CTA de criação · erro de carga recebendo o timeout do S5 · sem-permissão), régua de escala por container (Fiori), regra de marca nova: EEny permitido em primeiro-uso/esvaziado e PROIBIDO em erro/sem-permissão (Z5). Base: 3 rodadas (~12 fontes: NN/g com o caso ERP do painel de alertas, Polaris, GitLab Pajamas, Carbon pattern, Atlassian, Fiori empty states + illustrated message com 4 tamanhos, shadcn Empty, Mobbin, Setproduct) + heranças D8/D9, S5, §1, marca v5.0; consolidado Z aprovado pelo Rafael em 2026-08-04. Preview v0.23; validação executada aprovada: suite E 13/13 + regressões A 55/55, B 44/44, C 28/28, D 25/25 = 165 testes verdes no bloco; contraste do §25 integralmente herdado (texto primário/secundário e botão §1, já medidos). Ao promover o §25, o Bloco 3 fecha com 11/11. · v0.22: §23 tooltip · §24 popover promovidos a estável, validados pelo Rafael em 2026-08-04 (um ciclo de crítica visual: X6-b ícone SVG + correção do bug de geometria do posicionamento; re-teste aprovado). Sub-bloco D concluído — 10/11 do Bloco 3; resta o empty state para fechar o bloco. · v0.21: abre o sub-bloco D do Bloco 3 — tooltip (§23) · popover (§24) em rascunho, com a régua da sobreposição leve em 3 degraus (tooltip = não-interativo hover/focus · popover = interativo leve por clique, light-dismiss · modal = Bloco 4) e a DECISÃO TOUCH como coração: tooltip não é portador de informação no toque — todo uso declara equivalente touch (X2). Fecha a variante "+N" do chip (W7). Base: 3 rodadas (~18 fontes: NN/g, M2/M3, Carbon tooltip+toggletip, Heydon/Inclusive Components, WCAG 1.4.13+SCR39, Radix/DHIS2/W3C sobre touch, Popover API Chrome/MDN/OpenUI, React Aria usePopover, Floating UI, Hidde, Fiori ResponsivePopover, Spectrum tray); consolidado X/Y aprovado pelo Rafael em 2026-08-04. Errata da validação visual (2 achados do Rafael): (a) X6-b — gatilho ⓘ trocado de caractere unicode para o ícone SVG do T3; (b) bug de geometria — tooltips e popovers abriam sem posicionamento ancorado (renderizavam na origem do container, quase invisíveis); corrigido com ancoragem + flip, e registrada a lição de método permanente: a suite DOM valida comportamento, não geometria — a validação visual do Rafael é o gate complementar que cobre o que a suite não vê. Preview v0.21; validação executada aprovada: suite D 22/22 + regressões A 55/55, B 44/44, C 28/28 + pares do tooltip medidos (light 13.86 AAA · dark 11.49 AAA · borda dark 3.60) — primeira suite do Bloco 3 verde na primeira execução, sem errata. · v0.20: §21 badge · §22 chip promovidos a estável, validados pelo Rafael em 2026-08-04 sobre o preview v0.19 (validação visual aprovada sem ressalvas; suite C 28/28 + regressões A/B). Sub-bloco C concluído — 8/11 do Bloco 3; segue o sub-bloco D (sobreposição leve: tooltip · popover, com a decisão estrutural mobile). · v0.19: abre o sub-bloco C do Bloco 3 — badge (§21) · chip (§22) em rascunho, com a separação tripla como decisão-mãe (badge numérico × badge de status × chip interativo — badge NUNCA clica). Base: 3 rodadas (~15 fontes: Carbon tag/status-pattern/discussões a11y, Atlassian badge+lozenge+tag, Polaris badge, Smart Patterns, M3 chips a11y primária, Angular Material chips, React Aria TagGroup/grid pattern, WCAG 2.5.8, gov.br tag) + heranças T1–T5/§1.5.1 sem re-pesquisa; consolidado V/W aprovado pelo Rafael em 2026-08-04. Preview v0.19; validação executada aprovada: suite C 28/28 + regressões A 55/55 e B 44/44 + 8 pares de contraste novos — a medição pré-suite pegou a borda do chip em cinza-300 reprovando com 1.91 (corrigida para cinza-600: 4.74 light / 3.60 dark) antes de qualquer código. · v0.18: §18 spinner · §19 skeleton · §20 progress promovidos a estável, validados pelo Rafael em 2026-08-04 após dois ciclos de crítica visual (R3-b: três regimes de entrada; R3-c: composição obrigatória ack+delay no refresh por ação — "agora está ok") sobre o preview v0.17 com suite executada (44 testes B + regressão A 55/55 + 9 pares de contraste). Sub-bloco B concluído; segue o sub-bloco C (rotulagem: badge · chip/tag). · v0.17: abre o sub-bloco B do Bloco 3 — spinner (§18, com a Régua de Espera) · skeleton (§19) · progress (§20) em rascunho. Base: 3 rodadas encadeadas (~22 fontes: NN/g ×3, Carbon ×4, Smashing, React Aria/Spectrum, shadcn/Radix, MUI/Angular Material, W3C ARIA25 íntegra, MDN progressbar, aria-busy, SAP Fiori busy/placeholder, EC Europa, Material m1/m2 primários, Viget/Chung/estudo acadêmico de skeleton), consolidado R/S/U + Régua aprovado pelo Rafael em 2026-08-04. Resolve a ponta do §17.5 (toast de processo → U6). Preview estendido para v0.17 (simulador de espera); validação executada: suite B de 38 testes + suite A re-executada em regressão (55/55) + 9 pares de contraste novos (6 com gate, todos ✅; skeleton declarado decorativo com justificativa em §19.2). Nota de método da rodada: o único ✗ da primeira execução era bug DA SUITE, não do preview — asserções sobre live regions coalescem quando os sets são síncronos; o teste precisa de flush de microtask entre atualizações. Registrado como aprendizado permanente da validação executada (afeta como testamos §4, §6 e futuros consumidores do regime contínuo). Emenda R3-b na validação visual: a crítica do Rafael ('o delay de 1s vai parecer travado') foi medida contra a evidência e acatada — a régua ganhou 3 regimes de entrada (ação = ack imediato no controle; carga inicial = skeleton imediato; refresh = delay 1s), com supersede parcial do R3; preview e suite atualizados (3 testes novos). R3-c na sequência: 2ª crítica ('o refresh lento ainda demora') expôs que o demo rodava o regime 3 sem o ack do regime 1 — a régua agora obriga a composição (refresh por ação = ack imediato no controle + indicador de região com delay); demo corrigido, 2 testes novos, delay parametrizado em --seed-wait-delay com revisão por telemetria na F4. · v0.16: §15 alerta · §16 banner · §17 toast promovidos de rascunho a estável, validados pelo Rafael em 2026-08-04 sobre o preview v0.15 (validação visual sem ressalvas + suite executada de 55 testes e 24 pares de contraste, tudo aprovado). Sub-bloco A do Bloco 3 concluído; segue o sub-bloco B (espera: spinner · skeleton · progress). · v0.15: abre o Bloco 3 (Feedback e status) com o sub-bloco A — alerta (§15) · banner (§16) · toast (§17) em rascunho, mais as decisões transversais T1–T5 (§15.0: taxonomia de severidade com 4 níveis e vocabulário PT-BR "atenção" para warning) e a nota 1.13-b (emenda ao protocolo de live region: regime de mensagem discreta vs. atualização contínua). Base: 3 rodadas encadeadas + rodada de verificação primária (GOV.UK notification banner lido na íntegra, Material m1/m2 oficiais, Baymard, NN/g ×3, USWDS, Polaris, Atlassian, Spectrum/React Aria, APG, WCAG 4.1.3/2.2.1, SAP Fiori, gov.br DS — ~38 fontes), consolidado T/O/P/Q aprovado pelo Rafael em 2026-08-04. Preview novo: seed-feedback-preview.html v0.15 (dark toggle, grayscale, faixa 360px), aprovado na validação executada (suite de 55 testes DOM headless + 24 pares de contraste WCAG medidos, light e dark) antes de chegar ao Rafael. Errata da validação executada (3 achados): (a) bug Q5 corrigido no preview — a restauração de foco só funcionava chegando ao toast via F6; chegando por Tab, fechar o último toast derrubava o foco no body (React Aria restaura nos dois caminhos) — corrigido com rastreio de foco de origem em qualquer entrada na região; (b) errata para o seed-tokens.md v1.2, §5 — o par "azul-700 sobre azul-50 = 5.79" tem o NÚMERO certo e o STOP errado: 5.79 é azul-800/azul-50 (medido); azul-700/azul-50 dá 4.16 (reprova AA texto). Pendência de propagação: corrigir o rótulo na tabela do tokens quando o arquivo for editado; (c) token de componente ajustado — feedback-info-text light = azul-800 (5.79 AA) e feedback-info-solid light = azul-700 (4.16 sobre o fundo -50 e 4.61 sobre branco, ambos ≥3:1) — o desenho original (700/600) reprovava por 4.16<4.5 e 2.99<3.0. · v0.14: Bloco 2 completo — os 7 finais (§8 switch · §9 radio · §10 checkbox · §11 combobox · §12 slider · §13 date picker · §14 upload) promovidos de rascunho a estável, validados pelo Rafael em 2026-08-03 sobre o preview v0.13 (validação visual + suite executada de 63 testes: 62 aprovados, 1 falso-negativo de ambiente headless documentado). Com isso os 13 itens do Bloco 2 estão estáveis. · v0.13 (errata da validação executada): suite de 63 testes automatizados (DOM headless + contraste WCAG em script) rodada sobre o preview v0.12 flagrou 5 bugs de implementação e 2 imprecisões de documentação, todos corrigidos no preview v0.13 e refletidos aqui: (a) emenda D4-b no §4 — nó visível da contagem separado da live region (supersede do markup D4 original de nó único, que defasava o visual em 300ms — o padrão GOV.UK que o §1.13 proíbe); (b) regra nova no §2.6 — aria-invalid sempre com valor explícito "true" (nunca toggleAttribute, que grava valor vazio e não casa com [aria-invalid="true"] no CSS); (c) nota L1-b no §12 — o campo pareado consome o parser canônico do §5 (o preview chamava um helper inexistente e o caminho "digitar o valor exato" quebrava); (d) preview alinhado ao que o spec JÁ exigia em §8.4 (falha role="alert" + live region de sucesso) e N4 (role="alert" para falha de upload); (e) comentário de contraste do readonly dark corrigido (§2.5): o par real é cinza-100 #E3EBF0 sobre #141D23 = 14.16:1 (o 9.72:1 anterior media um par que não é o renderizado). Nenhuma decisão B/C/D/E/F/G/H/I/J/K/L/M/N muda; status dos §8–§14 permanece rascunho aguardando validação visual do Rafael. · v0.12: entram os 7 finais na ordem da régua — switch §8 · radio §9 · checkbox §10 · combobox §11 · slider §12 · date picker §13 · upload §14 — + protocolo de live region (§1.13) + fieldset/legend (§2.6b) + linha nova na régua (§7.1). v0.11: select (§7) com a régua unificada da família de escolha (emenda ao §3.1). v0.10: textarea (§6) + método no §1.12 + supersede do slot E. v0.9: número (§5). v0.8: busca (§4). v0.7: input de texto (§3), o pacote mobile M4–M7 (fundamento §0.8, teste do polegar no §1.12, botão full-width, form-field emendado) e o estado warning (C5). Histórico: v0.6 2026-08-02 (form-field) · Fase 3 do rebranding do DS. Histórico: v0.5 2026-07-31 (Botão estável + regra do par light/dark). Previews validáveis: seed-componentes-preview.html (botão) e seed-formfield-preview.html (form-field).

---