Changelog — seed-componentes.md

Data: 2026-10-31 · v2.00 — a leva 50 (MANIFESTO §327). (1) §46.7 SH22, tempos da prévia (SH-P70 b): a prévia do rail abre depois de 150 ms de intenção e fecha 500 ms depois de o ponteiro sair (eram 300/500); veredito dele, folha 17, Q1 = b, 2026-10-30 23:28 UTC (MANIFESTO §326.8; a opção b da folha: «150/500 ms: abre em ≈ 156 ms, fecha em 500 ms»). O sobrevoo que EXPANDE o rail (SH19) NÃO mudou: tem constantes próprias, 300/500 ms (decisão da sessão: a pergunta foi só sobre a prévia). Medido no Chrome (sonda render-shell.mjs R17-02): a prévia abriu em 152 e 157 ms; R19-13: 158 a 173 ms depois de o rail abrir. (2) §46.9 SH24, tooltip do rótulo curto (SH-P74 d): na Encurtada, o item de rótulo curto mostra o nome completo num tooltip no sobrevoo e no foco (veredito dele, folha 17, Q3 = d; a opção d da folha: «Vc: rótulo curto + tooltip com o nome completo»); mecanismo position: fixed posicionado por script (alcança 16 de 16 destinos a 1440 × 500 px, contra 5 de 16 com overflow: visible); opt-in rail(..., tooltip=True); vale também na gaveta de 800 px. (3) §83 AU-43, o anúncio do envio da vista Entrar (AU-P16 a; tela v0.14): com o e-mail em erro, o envio anuncia o texto do erro do campo em vez de «Envio simulado», move o foco ao campo e NÃO recusa o envio (veredito dele, folha 17, Q5 = a; a opção a da folha: «anunciar o erro em vez de «Envio simulado» quando o campo acusa, mover o foco ao campo, sem recusar o envio»); suíte 161 PASS · 0 FAIL · 2 [n/a]. (4) §31.4, o Esc fecha UMA camada (SH-P78): a regra vale também para o menu de envio e a lista de pessoa do detalhe com o painel aberto (4 casos novos, PASS de primeira: não havia defeito); a mensageria passa a ignorar o Esc durante a composição de IME (método de entrada; isComposing), como o módulo do painel. (5) §83 e §96 TE8, produto que usa o DS sem a marca SEED (LC-66): no lugar da logo vertical vai o nome do produto em texto (regra inteira em marca-seed.md §5.7); decisão DELEGADA a ele e exposta a veto (resposta «pode fazer», MANIFESTO §327.1, 2026-10-31).

Data: 2026-10-30 · v1.99 — a leva 49 (MANIFESTO §326). (1) AU-43 estendida (AU-P15; tela v0.13): a exceção do ponteiro vale na vista Entrar e em todo campo que valida no blur. Se o gesto termina sem clique (mouse solto fora do botão de envio, gesto cancelado, toque solto fora), a validação que o blur suprimiu é refeita na hora e o campo mostra o erro; solto dentro do botão, a validação é a do envio. Só o botão principal do ponteiro arma a exceção (o botão direito e o do meio não geram clique e acusam o erro). Ir da senha ao botão de revelar senha (e voltar) nunca acusa a senha em digitação, em nenhum formulário; sair do conjunto campo + botão para fora acusa, como manda o B4. O envio da vista Entrar mostra o erro do campo de e-mail de formato ruim, sem recusar o envio (o gabarito não sabe de credencial, CD13; o anúncio desse caso era a pendência AU-P16, decisão dele — resolvida na v2.00: o envio anuncia o erro do campo e move o foco a ele, ver o bloco acima e o AU-43 do §83). (2) Painel lateral e rail (SH-P76, SH-P67 parte): o Esc com o foco dentro do painel aberto fecha o painel e devolve o foco ao gatilho, no chat, no detalhe e na mensageria; um Esc fecha UMA camada (o Esc do menu de conta chama preventDefault e o painel respeita defaultPrevented; a composição de IME não fecha). O rail tem scrollbar-width: none (a barra horizontal de 15 px aparecia em 4 de 26 quadros na troca 80 → 160 px) e a prévia do painel do rail acompanha o rail quadro a quadro durante os 150 ms e na troca de data-rail/data-sidebar (o desvio de 80 px passa a 0 px). (3) Documentos de escritório (PR-P208): o cabeçalho C / NC / NA do checklist usa coluna de resultado de 20 mm com os rótulos centrados nas caixas (vão NC–NA de 0,60 para 1,86 mm); o título do caderno as-built cabe em uma linha (7,70 mm) com o número do placeholder e cede a uma segunda linha com número longo, sem sair da área útil. O subscrito do memorial fica no tamanho do corpo (8,16 pt): veredito dele, folha 16, Q2 = a. (4) Vitrine (PR-P207): a página /redes/ lista os glifos de redes sociais de TERCEIROS (uso nominativo; NÃO são assets da marca SEED); veredito dele, folha 16, Q1 = a.

Data: 2026-10-28 · v1.98 — a leva 48 (MANIFESTO §325). (1) AU-43 estendida (AU-P12, AU-P13, AU-P14; tela v0.12): o aria-describedby de um campo cita o erro só enquanto ele está visível e ANTES da ajuda (§2.9; veredito dele, folha 15, Q4 = a); o envio recusado move o foco ao resumo; o ponteiro até o botão de envio não valida no blur (a exceção, que era só da senha do "Criar conta", vale para qualquer campo que valida no blur nos três formulários: decisão da sessão, exposta a veto). (2) §46.10 SH29, D14 SUPERSEDIDA (SH-P71, SH-P75): a coluna de contexto, a troca de formato do rail e o empurrão do painel lateral animam a largura em 150 ms (--seed-dur-productive; movimento reduzido: de uma vez); veredito dele, folha 14, Q5 = c, 2026-10-28, verbatim: "aplicar 150 ms direto.", contra a recomendação "a" da folha; SH19 e §31.4 PL10 ganham a frase, e o Q3, o piso de 640 px e a cessão do rail leem o estado FINAL, nunca o meio da animação. (3) Campo em erro (CT-P28, tokens v1.40): a borda de erro passa a ser a MESMA cor do texto de erro (7,18:1 no claro, 7,56:1 no escuro; antes 5,19:1 e 5,52:1); veredito dele, folha 13, P4 = a, 2026-10-28; §2.5 (estado error, linhas dos tokens e a tabela de contraste).

Data: 2026-10-25 · v1.97 — a leva 47 (MANIFESTO §324). (1) AU-43 refeita (AU-P11): a senha do "Criar conta" valida no blur (B4), com exceção estreita para o clique no botão de envio por ponteiro, e o resumo role="alert" diz a regra e recebe o foco; a frase da leva 46 "no envio, não no blur" saiu; tela v0.11 (AU-P8, AU-P9, AU-P10). (2) Toggle .itgl (HV-P53, HV-P54): o aria-label é nome estável nos dois estados e o title é tooltip da ação; guarda permanente de nome acessível. (3) SH19 e §31.4 PL10 (SH-P69, SH-P73): com um painel aberto a coluna larga do rail cede de 160 para 80 px quando o conteúdo ficaria abaixo de 640 px (decisão da sessão, opção (a) da folha 13, exposta a veto), sem depender do caminho da janela.

Data: 2026-10-25 · v1.96 — a leva 46 (MANIFESTO §322). (1) §46.4 VT-P18: as telas do parceiro indicador entram na vitrine, tela-portal-parceiro (A30, governada pelo §48) e tela-cadastro-indicado (A31, governada pelo §2), 25 telas e 20 gabaritos (eram 23 e 18); numeração, governança e nomes são decisão da sessão, expostos a veto. (2) §83 A19 v0.10 — AU-43 (AU-P7): o "Criar conta" RECUSA no envio senha com menos de 12 caracteres ou vazia, com erro de campo anunciado; a frase "a tela não impede enviar senha curta" da AU-39..42 (texto da sessão da leva 45, apoiado no CD14) sai, porque o CD14 trata da FORÇA e o piso de 12 é FORMATO (CD4, CD13); nova nota ao CD14 (divergência com o canon anterior, exposta a veto). (3) §66.2 CD14, nota de emenda e o aria-describedby do campo senha só cita o erro enquanto ele existe (achado médio da revisão independente, consertado). Nada mais mudou.

Data: 2026-10-24 · v1.95 — a leva 45 (MANIFESTO §320). (1) §31.4 PAINEL LATERAL À DIREITA (SH-P62, folha 11, SH62a..e): uma regra só para chat, detalhe e mensageria — o painel EMPURRA o conteúdo até o piso de 640 px e, passado o piso, SOBREPÕE; três tokens (420 / 320 / 640 px, tokens v1.39); arraste pela borda com teclado; a conversa NÃO fica inerte (SH62c = b; custo do Tab sob o painel medido no PL7); o módulo único painel_lateral_bloco.py emite a camada. (2) §49.9 fecha a SH-P63 (o painel do detalhe não esmaga mais a lista); a CH3 e o §55.5 do chat e a MS5 da mensageria são substituídas (SH62d = b) e a gaveta da mensageria nasce abaixo do cabeçalho (SH-P60, SH60 = a); o limite antigo de 1560 px fica como histórico no §94.11. (3) Campo em erro (CT-P25, folha 9, M7 = a): a borda usa a cor do texto de erro; AU-39..42 no §83 (CPF em toda conta, senha de 12 no Criar conta). (4) O ⓘ ligado da mensageria segue o par do botão secundário (decisão da sessão, exposta a veto). · v1.94 — a leva 43 (MANIFESTO §316), as respostas da folha 11. (1) §46.10 SH29 coluna de contexto FIXA ou SOLTA (G1 = "a" com a observação dele). (2) §93 MA9 emendada, MA13 vidro sobre imagem e MA14 topo mais espesso (MA1 = MA2 = "a"; piso do claro 82 %, decisão da sessão exposta a veto). (3) §96 telas de estado de sistema TE1–TE11 (VI2 = "a"). (4) §47.8 MK30 aviso de cookies com o risco escrito (TQ4 = "b"). (5) §66.2 nota ao CD7: olho riscado (AU6 = "b").

Data: 2026-10-13 · v1.93 — a leva 41 (MANIFESTO §314). (1) §1 MH1 → MH2: todo :hover de TELA vive sob @media (hover: hover) (24 telas, 548 regras; guarda guarda-sobrevoo-telas.mjs). (2) §46 SH3/SH19: o alvo de 44 × 44 do avatar do RAIL é declarado na casca (AV2). (3) §49 PD17: o ícone dos botões de tamanho e de regime da tela-detalhe passa a acompanhar o estado (antes nunca trocava, defeito de script). (4) §94 MS5: o painel de informações da mensageria obedece ao teclado (foco entra ao abrir, Esc fecha e devolve o foco; CN6/DW3/Y3). (5) Caixas de seleção: accent-color: var(--seed-action-primary) nas caixas de linha da lista e da tabela e no painel (no escuro o anel do painel vai de #098475 a #66D1C2). Nenhum token novo.

Data: 2026-10-13 · v1.92 — a leva 40 (MANIFESTO §313). (1) §46.4: parágrafo "Endereço dos links públicos" — host https://siga.seed.eng.br, token de 22 caracteres base64url no CAMINHO, /i/<token> para o link de indicação, /f/<token> para o fornecedor (proposta a veto), noindex e no-referrer, meta seed-proibidas com o identificador da lista de palavras (PR-P159, PR-P158). (2) Telas: o avatar da topbar deixa a declaração morta de 32 px nos moldes (a casca dá o 44; SH-P56); a tela-detalhe e o shell levam o sobrevoo para @media (hover: hover) (HV-P31). Nenhum token novo.

Data: 2026-10-12 · v1.91 — a leva 39 (MANIFESTO §312). (1) §46 SH3/SH19 + SH-P54 (folha 8, L7 = b): na Encurtada, o rótulo que só cabe na Expandida vira abreviação ("Docs." dele; "Finanças" e "Indic." da sessão, a veto) com o nome completo no aria-label; AREAS aceita o curto e ganha pasta, balão, Indicações, Indicar e Comissões (SH-P53); a guarda do rótulo cobra RL-5/RL-6. (2) SH-P52: o avatar da topbar tem alvo de 44 × 44 em todas as telas (12 de 14 mediam 32). (3) §83 A19 v0.8: cadastro do parceiro indicador (CPF obrigatório com máscara e dígitos verificadores, telefone opcional, senha de 12), "Confirme seu e-mail", "E-mail confirmado", CPF já cadastrado; revelar-senha 44 × 44 (HV-P25); suíte 57 de 57. (4) Telas novas fora da vitrine (a gate na folha 9): tela-portal-parceiro (área do parceiro, folha 8) e tela-cadastro-indicado (página pública do link). (5) §46.4: a área do cliente (A27) e o envio do fornecedor (A28) entram na vitrine; o número de telas citado passa a ser medido por guarda (VT-P15/VT-P16). (6) tela-detalhe: o filtro ligado ganha sobrevoo e pressionado pela gramática de marca chapada do §71.6 (HV-P21).

Data: 2026-10-12 · v1.90 — a leva 38, parte 2 (MANIFESTO §311). (1) §46 SH3/SH19: a tela que nasce no formato Expandida (data-rail="largo") mede o rótulo contra 100 px (RL-4 da guarda-rotulo-rail.py), e a gaveta do SH12 mostra a Expandida nessas telas; a área do cliente usa a Expandida com "Financeiro" e "Documentos" (K2 dele). (2) §86 A18 v0.5: nasce a vista Pessoas (convidar, alterar papel/unidade, reenviar, revogar, variante sem permissão; suíte 42 de 42).

Data: 2026-10-12 · v1.89 — a leva 38, parte 1: o acesso ao SIGA (MANIFESTO §310). (1) §83 A19 v0.7: o aceite de convite — convite válido (regra de 12 caracteres antes do erro, e-mail fixo, aceite com links), expirado ou usado (alerta genérico), senha vazada, conta já existe; AU-18 a AU-24, suíte 33 de 33. (2) Tela nova tela-portal-cliente (o PN10 e o DP12 numa tela: a área do cliente com Início, Finanças, Arquivos e Chamados), fora da vitrine até o gate (PR-P156).

Data: 2026-10-12 · v1.88 — a leva 37, respostas da folha 6 (MANIFESTO §309). (1) §95 AB11: a folha "Mais" é Perfil · Trocar de conta · Tema · Sair (SH-P47, J2 = b; a forma do Tema, percorrer, exposta a veto em SH-P50). (2) §95 AB8: o selo cita o par text-on-action-destructive × feedback-danger-solid, 5,19/5,26 (SH-P48, J3 = a). (3) §95 AB12 (nova) e §46.7 SH22: o destino balao na barra de abas abre folha modal igual à do "Mais"; no rail segue ao lado (LC-41, J5 = b); §95.4 respondido; a guarda passa a 33 cláusulas. (4) O título do §95 deixa de dizer "sem tela de referência e sem instrumento".

Data: 2026-10-11 · v1.87 — a leva 36, primeiro loop orquestrado (MANIFESTO §308). (1) §95 e §1.14: a barra de abas, a folha "Mais" e o botão flutuante saem emitidos pelo shell_bloco.py; tela de referência tela-shell-abas.html (terceiro regime do A1) e guarda guarda-barra-abas.mjs no rito, 22 cláusulas (os 7 testes do §95.3, F1–F7, M1–M8) — os textos "sem tela de referência e sem instrumento" deixam de valer (LC-39, LC-40); o ativo responde ao ponteiro na família do botão secundário. (2) §94: nasce a forma TELA da mensageria, tela-mensageria.html (segunda tela do A23), com a suite-mensageria.mjs (94.12 com instrumento, 29 de 29); 94.13 item 3 cumprido; 94.14 registra o composição editado (LC-38, LC-37). (3) §46.4: 20 telas, 15 gabaritos (o texto dizia 17). (4) Régua do ponteiro: HV1 nos papéis de lista, menu, aba, rádio, árvore e interruptor (PR-P154), no modal do A8 (HV-P20) e a 390 px. Decisões da sessão expostas a veto na folha 6 (SH-P47, SH-P48, SH-P49, TK-P11, PR-P155).

Data: 2026-10-11 · v1.86 — a leva 35, fila da sessão (MANIFESTO §307). (1) §2.4: o erro vence o sobrevoo também no seletor, na busca, na hora do calendário, no filtro e nos select do painel; em controle com invólucro o erro pode estar no controle interno, e a exclusão é :not([aria-invalid="true"]):not(:has([aria-invalid="true"])) (PR-P148). (2) §57 QD22: o quadro de funil tem a variante sem permissão de gerir funil — "Editar funil" e "Novo funil" não existem no DOM e uma nota diz como pedir (QD-P20). (3) §62.4: a lista aberta do seletor de pessoa ganha cobaia medida nos dois temas e o caso da lista que sobe (PD-P11). (4) §46 SH3: todo rótulo de rail das telas é medido no rito pela tabela de avanços (PR-P147, guarda guarda-rotulo-rail.py).

Data: 2026-10-11 · v1.85 — a leva 34, fila da sessão (MANIFESTO §306). (1) §22: as telas de notas fiscais e de propostas ganham as classes da paleta de entidade do chip de status, do módulo único (QD-P19). (2) §46 SH3: o rótulo do rail se mede por tabela de avanços da Montserrat Bold 700 com kerning, não por contagem de letras (PR-P146; desvio máximo 0,014 px contra o Chrome). (3) §62.4 / PD22: a lista aberta do seletor de pessoa medida no gabarito A8 — 320 px de largura, 264 px de altura máxima, 4 px do campo, --seed-z-popover (PD-P10). (4) §57 QD22: exercido no gabarito novo tela-quadro-funil (mesmo A7, modo funil comercial; QD-P14); linha nova na tabela do §46.4. (5) §68.2: a proposta é a peça do modo peça da skill seed-ds (as skills antigas não existem; SK-P12).

Data: 2026-10-11 · v1.84 — as levas 32 e 33: as folhas 3 e 4 sobre o STATUS (MANIFESTO §303–§304). (1) §22: nasce o tom st-erro (vermelho de perigo existente; "Perdido", G1 = a); W9 e §22.4 — a cor do status é CAMPO EDITÁVEL numa paleta fechada de 11 cores (os 5 tons + 6 de entidade, todas ≥ 4,5 nos dois temas; observação dele no G2 e H4 = a), com a sugestão de fábrica marcada (Pendente cinza, H1 = a); W10 — cada TIPO de registro tem o seu conjunto (H3 = a); 22.4.5 — "Atrasada" deixa de ser status e vira marca de PRAZO ao lado dele (H2 = a). (2) §57: QD23 emendado, QD24 novo, §57.7 (G2, G3). (3) §86.4: a tela Configurações → Status no gabarito tela-configuracoes v0.4 (H5 = b), com o controle de cor num módulo único (cor_status_bloco.py). Telas: detalhe v0.7, tabela v0.6, chat v0.5, quadro v0.6; bancada banco-escolha v0.5. Aplicado pelos agentes das levas 32 e 33, consolidado pela sessão.

Data: 2026-10-10 · v1.83 — a leva 31: as respostas dele às folhas 2, QD-P16 e 3 (MANIFESTO §302). (1) §94 estável (Q10 sem veto) e o tique "lida" em AZUL feedback-info-text na MS14 (Q5, observação dele; azul confirmado na folha 3, G5 = ok). (2) §95 AB11: a última aba do celular é "Mais", com a conta dentro (F4c = a), e "Mais" abre folha modal de baixo (G4 = a). (3) Select com estado de erro igual ao campo (§2.4, §7.3, §7.6; PR-P149, F5 = a). (4) §47.7 MK29 revisada: a barra de acessibilidade da vitrine fica sem accesskey e sem número (F1a = b, PB-P12). (5) §57 QD23: o status da etapa é o chip do §22 no cabeçalho da coluna, N etapas : 1 status, o cartão não repete (F7 a e QD-P16 = c, verbatim no QD23); QD2 reaberto, QD13 emendado. (6) Token --seed-toast-bg/--seed-toast-text (tokens v1.36, PR-P152 = b). Aplicado pelos agentes a–d da leva 31, consolidado pela sessão.

Data: 2026-10-10 · v1.82 — a leva 30: as folhas v3 pela recomendação da sessão (resposta dele "a, a, a", MANIFESTO §301). §57 ganha QD15–QD22 (pílula neutra da etapa, aviso da etapa sem criação, setas do degrau estreito, selos da tarefa e ação compacta, pele do alerta no cartão fora do prazo, ações do funil) e §49 ganha PD20–PD24 (barra de ações do registro, PD9 na grade, seletor de pessoa em sobreposição, ajuda do exigido, rótulo truncado com foco e balão); gabaritos A7 v0.5 e A8 v0.6 regenerados. CH7 do §55 ganha a exceção nomeada do motivo permanente de falha e a MS14 do §94 os dois rótulos ("Não enviada" × "Não entregue"). estável no título de 10 seções transversais (REV-P12 6a) e no §95 (marcador da sessão, exposto a veto).

Data: 2026-10-10 · v1.81 — as respostas dele à folha de 2026-10-10 entram no canon (MANIFESTO §300). (1) Chat de atendimento (pranchas LC-15/LC-16/LC-19): nasce o §94 Mensageria de atendimento (MS1–MS40) com as escolhas dele, verbatim "Q1 a, Q2 c, Q3 b, Q4 a, Q5 a, Q6 a, Q7 a, Q8 a, Q9 a" — a Q10 (veto geral) ficou sem resposta e segue a decidir; supersede parcial do CH14 do §55. (2) Barra de abas de aplicativo (§95, AB1–AB10, "V-AB1 a, V-AB2 b") e botão flutuante (§1.14, FB1–FB8, "V-FB1 c, V-FB2 b", veto nenhum); exceção ao SH12 do §46. (3) Campo: o vermelho do erro VENCE o sobrevoo (PR-P133, resposta "A" depois da folha visual) e o stepper segue a mesma regra do campo, E10 do §5.2 (PR-P134, "a"). (4) Rail: a SH3 passa de "≤ 9 letras" para "cabe em 68 px medidos" (SH-P31, "a"; "Qualidade", 9 letras, mede 68,55 px no ativo e não cabe — a letra não prevê a largura) e o anel duplo de foco do rail sobe ao canon como SH15-c (SH-P38, "a", exposto a veto). Aplicado pelos agentes a e b da leva 29, consolidado pela sessão.

Data: 2026-10-08 · v1.80 — o rail ganha o TERCEIRO formato e o sobrevoo que expande (SH-P46, o §46 sobe a v0.52). Pedido dele, verbatim: "preciso que crie um novo formato para o Rail. hoje temos 2, minimizado e encurtado, crie o formato expandido. o usuário poderá optar pelo formato que quiser. o formato padrao continua o mesmo, ele pode expandir e encurtar pelo botao ou alterar suas preferencias. no formato encurtado quero que nas preferencias vc coloque opçãp de expandir para o formato expandido se passar o mouse em cima". Veredito sobre a folha do estudo, verbatim: "pode seguir / folha nao abriu" — aprova as 8 saídas marcadas "← leitura da sessão" (Q1 a Q8). O SH19 é reescrito (três formatos: Minimizada recolhido 56 · Encurtada expandido 80, o padrão · Expandida largo 160 = sp-16 + sp-24; o botão alterna Encurtada ↔ Expandida; o limiar do Q3; o sobrevoo data-rail-sobrevoo), e as duas linhas de "Descartado" de setembro (o expandido de 220 px e o sobrevoo que expande) passam a "superadas pelo veredito de 2026-10-08", com o texto antigo preservado. O SH3 diz que os 80 px são do formato padrão; o SH21 ganha o grupo "Barra lateral" e o item "Expandir ao passar o mouse"; o SH22 registra que a prévia cede ao sobrevoo; a porta do SIGA passa a 3 valores + 1 booleano. Régua nova: render-rail.mjs (R18 limiar, R19 sobrevoo, R20 botão e menu) com a prova de cobaias provas/rail-formatos/.

Data: 2026-10-05 · v1.79 — o sistema de gestão da SEED passa a se chamar SIGA no DS (SH-P43, nasce a SH23 no §46.8, o §46 sobe a v0.51). Veredito dele, dado no seed-erp (MANIFESTO §285): "o nome é "SIGA" – Sistema Integrado de Gestão Assistida. com a tagline "Gestão inteligente""; confirmado ao ser perguntado se o nome entra no DS: "sim, está correto, definimos SIGA como nome". A SH23 registra o nome, a tagline e a forma do <title> (entrada "SIGA · Gestão inteligente"; internas "<Tela> · SIGA"). No corpo deste arquivo as menções ao produto da SEED trocaram de "ERP" para "SIGA"; ficam como estavam o changelog, o verbatim, as datas passadas e o uso de "ERP" como categoria de software ("sistemas ERP", Fiori, SAP).

Data: 2026-09-27 · v1.78 — o comando de produção do §82.8 deixa de mandar gravar numa pasta producao/ que o repositório não tem (REV-P29 (d)). O gen-z3-largos.py grava onde a variável DEST_LARGOS mandar, relativo à pasta de onde roda; o padrão do código é render-audit/gate-z3/largos (a pasta do GATE), e /render-audit/ está no .gitignore desde a REV-P14. A pasta de produção migrou na fundação do repositório para 07-pecas/producao-cartao-90x50/ e foi removida de propósito em 2026-08-25 (commit 82bf6a9f: as peças de produção do cartão da era anterior); rodado da raiz, o comando antigo criaria producao/ fora do .gitignore. O destino passa a render-audit/producao/cartao-90x50: fora do git e fora da pasta do gate, a separação que o próprio §82.8 exige. Não é 07-pecas/cartao-90x50/: aquela pasta é a peça de gate do gen-cartao.py, e o gen-z3-largos.py APAGA a pasta de destino antes de escrever (medido em 2026-09-27 numa pasta descartável). O ### Histórico da seção não se toca.

Data: 2026-09-27 · v1.77 — os três comandos que ainda chamavam a pasta da era anterior (REV-P27 (b), MANIFESTO §269.4): o §70, o §77 e o §82 passam a mandar rodar o instrumento no caminho de hoje. A v1.76 trocou as 57 ocorrências de `validacao/…` entre crases; sobraram 8 sem crase à esquerda, dentro de comandos (node validacao/…, python3 validacao/…), que a busca daquela leva não alcançava. Três estão no corpo e passam ao caminho vivo, conferido por git ls-files em 2026-09-27: §70 06-validacao/guardas/guarda-centro-alvo.mjs, §77 06-validacao/suites/prova-47o-defeito.mjs, §82 06-validacao/geradores/gen-z3-largos.py. O resultado impresso abaixo do comando do §70 (23 PASS · 0 FAIL · 28 [n/a]) é a medição daquela data e fica como está. As outras 5 estão no ### Histórico da seção do §77 (os comandos e placares da GR1 de 2026-08-21) e não se tocam: são registro.

Data: 2026-09-27 · v1.76 — as pontes que a régua passou a enxergar, os caminhos da era anterior e o grupo da âncora no endereço (REV-P23, REV-P24 e SH-P40, MANIFESTO §268.4): quatro seções passam a citar a seção com que têm relação real, 57 caminhos validacao/… do corpo apontam para o arquivo de hoje, o segundo aviso do §76.7 ganha nota de supersede, e o §46.7 diz como o grupo do subitem atravessa uma navegação. (1) REV-P23: quando a régua CI-11 da guarda-camada-ia.py passou a ler de qual documento é cada "§N" (PR-P43), apareceram pontes recíprocas que um "§N" de outro documento escondia. Cada uma foi lida pelo conteúdo, e as seis deste arquivo são reais; nenhuma declaração de conceito estava errada. O §0 cita o form-field (§2.9: nome acessível e ordem de anúncio de erro e ajuda); o §46 cita a busca-filtro do §4 (no SH9: filtrar o dado da tela é outra busca) e o contrato por arquétipo do seed-composicao.md §3 (no §46.4); o §64 cita a marca §11 (o escuro como cidadão de primeira classe); o §65 cita a admissão de cor de entidade da marca-seed.md §3.6-b e os tokens --seed-entity-* do seed-tokens.md §3. (2) REV-P24: das 83 ocorrências de `validacao/…` (74 linhas), 62 estavam no corpo das seções: 57 passam ao caminho vivo (todas existem hoje, conferidas por git ls-files), 1 ganha "(a pasta de então; hoje 06-validacao/)" porque é uma contagem daquela data (§70), e 4 ficam como estão porque falam do caminho antigo de propósito (a mudança de pasta do §48, o aviso de 2026-08-21 do §76.7, a nota de remedição do §77.6). As 10 do changelog deste cabeçalho e as 11 dos ### Histórico da seção não se tocam: são registro. O §76.7 ganha a nota de supersede do segundo aviso ("A GR1-c REPROVA QUATRO PEÇAS APROVADAS"): o §78 mudou o teto no canon, e as peças largas medem 15 · 0 · 0 (remedido em 2026-09-27, 17:34Z). A nota do §77.6 de que a folha, o monta-folha-gr1.py e o LEIA-ME.md da GR1 não estão no repositório já existia desde a v1.75. (3) SH-P40 (§46.7, contrato do tipo painel): quando ancorar num subitem exige navegar para outra tela, o produto leva o grupo no endereço e a tela de destino abre a coluna só com aquele submenu e o "voltar à área"; dentro da mesma tela, o evento seed-rail-ancora basta. É decisão da sessão, exposta a veto dele; o resto do SH22 não muda.

Data: 2026-09-27 · v1.75 — as notas de canon da revisão (REV-P17 a REV-P22, MANIFESTO §267.4): o verbatim que é FONTE de regra volta ao corpo, perto da regra; duas contradições ganham nota de supersede datada, sem apagar a história; e os placares de referência do corpo são remedidos. (1) REV-P18: cinco verbatins que a F12.4 (2026-09-19) tinha levado ao Histórico e que são a fonte de uma regra ou de um estado voltam ao lugar de onde saíram, byte a byte como estavam antes dela — o do §79.1 ("acho que deixar 1:1 nao seria o ideial…"), o "aprovo" que é a fonte do estável do §46, a confirmação da tabela SH17 (§46.4), o veredito V-LC11 do SH18 (§46.5) e o "troca a bolinha" da CC-P8 (§65.11). O critério é o do §267 (o F1-47d do §47): fala dele entre aspas, que é decisão (não queixa nem motivo), de que a regra do corpo deriva, e que o corpo não traz em outro lugar. Dos 113 ponteiros "(decisão registrada — ver Histórico da seção)" medidos, os outros 108 ficam: são pesquisa, contexto, motivo ou verbatim que o corpo já cita; os casos de dúvida foram à sessão. (2) REV-P17: o §72 passa a citar o §46 no corpo (a tela estreita é contrato do SH12), e a nota "Estrutura da Fase 3" vai ao Histórico do §72 (3.164 bytes). (3) REV-P19: nota de supersede no §85.2 — o véu por box-shadow inset cede ao §71.6, com a prova por git log -S. (4) REV-P20: nota de supersede no §76.7 — a guarda existe desde o §77. (5) REV-P21: remedidos em 2026-09-27 os placares do corpo do §66 (30), do §67 (23) e do §68 (25), que os títulos já diziam, e os do §77.6 com os caminhos de hoje; os números antigos foram ao Histórico de cada seção. (6) REV-P22: o título do §65.13 volta a uma linha só. (7) Sobre a entrada rotulada "v1.73" logo abaixo da v1.74: ela não é uma versão — é a portadora do título antigo, movida em 2026-09-26 pela REV-P7; a v1.73 é de 2026-09-25 (commit 2185e81f, SH-P24).

Data: 2026-09-26 · v1.74 — a REV-P7 aplicada (MANIFESTO §247 e seguintes, modo DENTRO): o título volta a ser só o título, e a história solta de cada seção vai para o ### Histórico da seção da PRÓPRIA seção; a regra SH22 (tipos de destino do rail) sobe ao §46. (1) Título curto: a linha de 63.499 bytes que o H1 carregava desde a v1.09 está inteira na entrada logo abaixo, byte a byte; a versão nova se registra como entrada deste changelog, a mais nova em cima. (2) Movimento DENTRO: 77 blocos de história (39.167 bytes) saíram do corpo e foram, sem mudar um byte, para o fim do Histórico da mesma seção — 5 no §45–§47, 33 no §48–§65 e 39 no §66–§93 (em 21 das 98 seções H2); nenhum título numerado muda, e onde uma subseção ficou sem corpo entra um ponteiro de uma linha. Ficaram no corpo, de propósito, o parágrafo que mistura regra e história, o verbatim que é fonte de regra ou de estado (o "aprovo" do estável do §47 incluído) e as 14 lições da rodada 3 do §48; a frase "no escuro, elevação é LUZ, não sombra" segue no texto vigente do §48 (4b, supersede do §250.2). (3) SH22 (§46.7): o destino do rail declara o tipo painel, balao ou direto — prévia no sobrevoo, coluna ancorada no clique, balão e destino direto; SH3, SH12, SH14 e SH19 ganham uma frase cada. Veredito dele, verbatim (MANIFESTO §264.1): "ficou otimo" e "Sim, tudo como aplicado (Recommended)" (V-SH34.1 a .6 = a). (4) Registro de medida, sem regra nova: §49.5 ganha o piso de 64 px do rótulo que cede (PD8) e o §49.1/PD7 diz onde a container query peca é declarada (agente DET, §264.4); o §35.2 registra o sobrevoo provisório do menu sobre surface-overlay (HV-P12, §262); o título do §46 ganha as contagens remedidas das suítes da casca.

Data: 2026-09-26 · v1.73 — o título deste arquivo até aqui, movido INTEIRO para o changelog (REV-P7, recomendação 3 da R6): desde a v1.09 cada versão nova era escrita DENTRO do H1, que chegou a 63.499 bytes numa linha só e era a primeira coisa da fatia _cabecalho.md — a que um agente abre primeiro. O título passa a dizer só a versão vigente, e a versão nova se registra como entrada deste changelog, a mais nova em cima. A linha antiga segue abaixo, byte a byte, a partir do "#": # SEED engenharia — Componentes v1.73 (SH-P24 (MANIFESTO §252, 2026-09-25) — a topbar passa a ocupar a largura inteira, ACIMA do rail: supersede da posição da SH3 do §46 ("altura total, à esquerda da topbar", gate de 2026-08-11), com o veredito dele verbatim "1 arranjo: sim". A casca vira grade 2 × 2 no módulo único shell_bloco.py; nos 12 moldes com topbar ela passa a ser o primeiro filho do .app. O resto do contrato do rail não muda. · v1.72 (Grupo 9 (MANIFESTO §245, 2026-09-24) — o BT2 do §64.1 passa a ser medido também no ARTEFATO, no Chrome, pelo rito (guarda-barra-gramatica.mjs, PR-P26), e o banco-dataviz-dp entra na gramática única da barra (BT-P8): 27 de 27 barras emitidas pelo módulo controles_bloco.py. O denominador verdadeiro é 39: 12 barras seguem fora (BT-P10). Nenhuma regra muda — é atualização de número e de instrumento, aplicação da sessão exposta a veto. · v1.71 (Pergunta 2 da §238.6 respondida (MANIFESTO §244, 2026-09-24) — o nome acessível da trilha passa a ser "Trilha" no §36 BC2, que cede ao §46 SH2. As duas seções eram estável e se contradiziam; a suite-shell já media o do §46. Veredito dele: "sigo sua recomendação". A única bancada com o nome longo (banco-navegacao.html, sem gerador) foi alinhada. Nenhuma outra decisão muda.** · v1.70 (V-PR15 (2026-09-21) — A BARRA DE PROVAS PASSA A TER UMA GRAMÁTICA SÓ, E O BT2 SAI DE "NÃO VERIFICADO" PARA "VERIFICADO POR INSTRUMENTO". O estudo PR-P15 (Grupo 7, 2026-09-20) mediu duas gramáticas perfeitamente separadas nos 26 artefatos com barra — 12 na de bancada (sem role="group", sem nome acessível, com type="button" e o <select> das cinco larguras do BT2) e 14 na de tela (com nome acessível, sem type="button", com três botões de largura que não são as do contrato, e em só 4 dos 14) — e o achado que reordenou tudo: 14 dos 26 não tinham controle de largura NENHUM, inclusive a bancada banco-dominio. Veredito dele no gate, verbatim: "não vejo que isso seja decisao minha, parto do principio de que é uma barra para simular situações para eu avaliar, logo, voce deve colocar o maximo de informações nessa barra e padroniza-la para todas as telas. Identifique o que precisa e pode aplicar sua recomendaçao. veto: nenhum". Aplicada a recomendação medida (a gramática ÚNICA): nome acessível de grupo, type="button" e o <select> das cinco larguras do BT2 em 26 de 26 (antes: 14, 35 de 95 botões e 8, respectivamente), tudo emitido pelo módulo único controles_bloco.py, que cresce da MOLDURA (PR-P11) para a barra inteira — HTML do núcleo, aparência dos botões e script da largura —, e cujo conferir() passa a PROVAR sete cláusulas no ato de gerar, entre elas o BT2 e o token fantasma (NV-01). Placares medidos: BT1 39·0·15 igual ao baseline · BP1 26·0·15 igual · HV1 74 PASS · 6 FAIL · 2 [n/a] igual em veredito (denominador 1476 → 1452, exatamente os 12 botões que saíram × 2 temas) · contraste rasterizado 0 FAIL em 39 de 39 a 1440 e a 390 nos dois temas · regeneração byte-idêntica 25 de 25 · MH1 (sobrevoo da barra dentro de @media (hover: hover), pendência HV-P10) 6 PASS · 20 FAIL → 26 PASS · 0 FAIL, baseline regravado. Fecha a BT-P3 do §74.9 (supersede no §64.1 e na tabela do §74.9, com a colisão de código registrada: há duas BT-P3 no arquivo, e a do §64.11.1 é outra pendência, fechada em 2026-08-17). Três achados de conserto que a medição pegou e que ficam registrados: seis geradores consumiam token que o bloco embutido não definia (NV-01, a geração abortou até os nomes entrarem em NOMES), quatro moldes ficaram com identificador JavaScript inválido no rename (var b-tema) e a BT1 caiu de 39 para 35 até o conserto, e o corte do CSS do shell levou junto a regra GLOBAL button {…} do PRODUTO e a HV1 mediu 1,23 no escuro até ela voltar. Fronteira declarada: o script de tema e o de escala de cinza continuam por molde (não mudam pixel); os controles PRÓPRIOS de cada artefato continuam no molde, por dentro da barra.** · v1.69 (Veredito do estudo SH-P20 (MANIFESTO §241/§242, 2026-09-21) — o §36 BC4 muda de "antes do <main>" para "primeiro filho DENTRO do <main>", supersede formal. A redação antiga nunca se cumpria nos quatro moldes do shell (a trilha sempre esteve dentro do <main>) e a tentativa de aplicá-la de verdade derrubou a régua de contraste de 10·0 para 5·5 (o <main> é a peça branca do CP1; fora dele a trilha herda o canvas com material do §93). Veredito dele, verbatim: "Saída A — fica onde está; o BC4 muda. se depois do sistema funcionando acharmos que será melhor mudar o local, reanalisamos no futuro." Nenhum molde muda (a posição real já era essa); nenhum placar muda.** · v1.68 (Grupo 6 (MANIFESTO §238, 2026-09-20) — SH-P17: nasce a tela-shell-sem-topbar.html, o segundo REGIME do shell (produto SEM topbar, avatar do menu de conta na BASE do rail, ☰ do SH12 como primeiro elemento do conteúdo), emitida do mesmo molde pelo mesmo gen-shell.py; o §46.6 deixa de dizer que "não existe tela de referência SEM topbar"; o §46.2 diz onde vive o ☰ sem topbar; a coluna "referência traz a casca" do §46.4 passa a ser medida pelo RAIL e a tabela do SH17 ganha a linha nova; errata de contagem: são 15 gabaritos para 17 telas (o A2 sempre teve duas), não "16 gabaritos". Achado do olho, medido: o avatar no rail não ficava na base (151 px do botão de recolher) — faltava o margin-top:auto; R14/R15 do render-shell.mjs passam a medir geometria. Nenhuma outra decisão muda. · v1.67 (F12.9 (MANIFESTO §235.2 e §236, 2026-09-19) — nasce o SH21, conta e tema no shell: UM menu de conta por tela, aberto pelo avatar (Perfil · Tema com claro, escuro e seguir o sistema · Sair); avatar na zona direita da topbar (SH10) e, em produto sem topbar, na base do rail acima do botão do SH19; o tema nasce pelo sistema e a primeira escolha da pessoa passa a valer por CONTA — decisão dele no gate SH-P16, verbatim: "V-SH16.1: b · V-SH16.2: (…) na parte inferior da rail · V-SH16.3: a · veto: nenhum"; aplicado no módulo único shell_bloco.py nas onze telas, suíte 84 → 97, render 54 → 63, régua rasterizada com o menu ABERTO nos dois temas 0 FAIL; a redação da 46.6 é a que o código implementou (Tab FECHA o menu, como manda o §35 — a proposta dizia "prende o foco" e estava errada). · v1.66 (F12.4 (MANIFESTO §234, 2026-09-19) — a fonte de verdade passa a dizer onde mora o acabamento, a REGRA vem antes da HISTÓRIA, e a história de cada seção migra para o fim dela. Três mudanças, nenhuma de valor. (1) D-1, o ponteiro que faltava: o §46 (shell de aplicação) citava o §93 (material) ZERO vezes — medido na fatia publicada, 0 ocorrências de "§93" em 286 linhas — e por isso a IA que adequou os dois apps de chat da empresa em 2026-09-18 não achou que o rail é metálico, obrigando o decisor a corrigi-la ("voce nao aplicou da maneira correta a cor da rail que é metalizado tbm"). SH3 e SH15 ganham a oração "acabamento: metal escovado quando a tela declara data-material (§93 MA2, receita metal_rail → .rail)", e o bloco "Natureza" ganha a regra geral do sistema: toda seção vestida por uma camada transversal (material §93, composição CP1–CP32, tema/tokens) APONTA a camada. (2) D-7, a regra antes da história: a única afirmação do raio do rail vivia depois da oração "A exceção nomeada do rail foi SUPERSEDIDA" — quem lia o começo concluía o contrário. O §46.1 passa a abrir por "O rail é peça sobre o canvas como as demais — radius-lg, calha nos quatro lados, sem borda" e a supersede desce para uma "Nota de histórico"; o §74.5 recebe a mesma inversão. Nasce a regra de redação: nenhum enunciado normativo começa pela palavra que o revoga. A varredura de SUPERSEDID|REVOGAD|superad nos quatro canônicos achou 7 aberturas candidatas, 5 recusadas a olho com o motivo registrado. (3) V-SK1 = b, o ### Histórico da seção: 72 de 98 seções ganham, no FIM, um H3 ### Histórico da seção para onde migram 118 blocos em 109 grupos (pesquisa de origem, pendência fechada, placar de rodada, veredito narrado, alternativa descartada, gênese da regra), em ordem cronológica inversa, texto byte a byte, nada reescrito; no corpo fica uma linha *(decisão registrada — ver Histórico da seção)* por grupo. Prova: 0 linha não vazia perdida, 181 linhas novas (72 H3 + 109 ponteiros), LF puro 124 → 124 (o arquivo é misto e não foi normalizado), gen-camada-ia.py e gen-vitrine.py byte-idênticos em --checar, e as guardas CI, VT, BC, UC, SG e NB no mesmo placar de antes. Oito blocos foram VETADOS à mão, com o motivo escrito no relatório do brick — seis são pendência ABERTA ou ressalva viva, dois são avisos que anotam a tabela logo abaixo deles. Mudam o cabeçalho, o §46 e 71 outras seções.) · v1.65 (SH-P12 item 2 fechado, 2026-09-16 (MANIFESTO §233): veredito dele, verbatim, "V-SH12.2 (Escopo rail × acordeão): a (vira rail) · veto/observação: nenhum". Nasce a decisão SH20 no §46.1: o painel .escopo (a árvore de filtro de 250 px de tela-quadro.html, tela-detalhe.html e tela-gantt.html) vira uma EXTENSÃO do rail do shell — some do conteúdo no MESMO limiar do SH12 (860 px de contêiner app) e reaparece dentro do MESMO <dialog class="nav-drawer">, reaproveitando o mecanismo já testado (render-shell.mjs), em vez de ganhar um acordeão próprio com regra e cobertura de teste novas (a Alternativa B descartada). Resolve de quebra a lacuna de acessibilidade da SH-P15 (abaixo de 420 px o .escopo sumia sem nenhum jeito de reabrir) — agora ele está SEMPRE alcançável pelo botão ☰. Emitido pelo módulo único shell_bloco.py (2 linhas: o seletor CSS do colapso e o seletor JS que move os nós para o drawer) mais a remoção da regra própria .escopo{display:none} a 420 px nos 3 moldes que têm o painel; suite-shell 84 · 0, render-shell 54 · 0, contraste-shell 55 · 0, suite-composicao 33 · 0, suite-quadro 35 · 0, suite-detalhe 73 · 0, suite-gantt 43 · 0 — placares idênticos aos já declarados no canon, sem regressão. Mudam o cabeçalho, §46.1 e §46.2.) · v1.64 (TK-P2, 2026-09-16 (MANIFESTO §225.4-b): o §71.6 ganha uma nota de DADO, sem gate e sem conserto -- no tema escuro, surface-sunken e surface-page são o mesmo hex (#0B1419), e por isso o botão desabilitado (.seed-btn:disabled) e o campo em modo leitura (.seed-field__control[readonly]) ficam sem fronteira visível contra a página nesse tema (os dois zeram a borda por CSS e dependem só do fundo para se distinguir). O outro achado da mesma pendência -- duas verdades para a tinta do botão secundário -- é corrigido em 02-tokens/seed-tokens.json/.css (remove action-secondary-text, duplicata do button-secondary-text que este canon já define no §1.6) e não toca este arquivo. Mudam o cabeçalho e o §71.6.) · v1.63 (SH-P14 aplicada, Grupo 3, 2026-09-15 (MANIFESTO §229) — o rail ganha o estado RECOLHIDO só ícone (nova decisão SH19 no §46.1): veredito dele, verbatim, "V-SH14.1 modo recolhido: b · V-SH14.2 gatilho: a · V-SH14.3 posição do botão: a · V-SH14.4 quem lembra: a · veto: nenhum". Padrão 80 px com rótulo (SH3, agora "no estado padrão" — supersede parcial com as duas fontes do NN/g datadas) · recolhido 56 px = sp-12 + 2·sp-1, item 48 × 48, ícone 24, rótulo no DOM com clip de 1 px que vira tooltip em :hover/:focus-visible (§23 X1/X3/X6; o do 1.º destino desce para não cobrir o seletor de contexto) · gatilho: botão .alterna-rail na base do rail, último focável, aria-expanded · quem lembra é o PRODUTO (preferência do usuário, global, nasce expandido; as telas de referência não persistem nada) · o recolhido não existe abaixo do limiar do SH12 nem no toque. Tudo emitido pelo módulo único shell_bloco.py nas onze telas; suite-shell 84 · 0, render-shell 54 · 0, contraste-shell 55 · 0, CP-13 11 de 11 (aceita 80 ou 56 pelo data-rail), RC 22 de 22. Mudam o cabeçalho, §23.2, §46 (título), §46.1, §46.2, §46.3 e §46.5.) · v1.62 (Grupo 3, onda 2, 2026-09-15 (MANIFESTO §228) — SH-P13: o §46.2 fixa por escrito o limiar do SH12 (860 px de CONTÊINER app, nunca de janela) e o módulo shell_bloco.py passa a emitir a casca inteira do colapso (botão ☰, dialog.nav-drawer, regra e script) — as onze telas com casca respondem igual (88 de 88 cenas a 390/768/1024/1366); HV-P4 G-B aplicado nas dez telas, no shell e no site (o item ATIVO do rail ganha sobrevoo/pressionado na rampa da pílula: turquesa-200/300, tinta 9,35/7,39) — §71.8 registra o recenso: HV1-a 552 → 94 · HV1-b 1.224 → 240 · HV1-c 0. Mudam o cabeçalho, §46.2 e §71.8.) · v1.61 (Grupo 3, onda 1 — aplicação do veredito do gate do Grupo 2, 2026-09-15 (MANIFESTO §226–§227): §71.6 ganha as duas linhas que os vereditos V-HV4.1 = a e V-HV4.2 = a decidem (par action-neutral-on-subtle-hover/-active para controle transparente sobre a casca; regra D3(a): ghost/outline dentro de cartão consome o par neutro) e o parágrafo do veredito, §1.5 a linha active (primário escuro monotônico, tokens v1.29), §73.5 a ponte para o negrito por cor, §75.8 nova (V-FT2.1 = b e V-FT2.2 = c: negrito dentro de texto já 700 marca por text-brand-strong, rótulo em JetBrains Mono declara 700), §47.7 nova — MK29 (V-PB9.1 = b: barra de acessibilidade no topo de toda página pública, atalhos accesskey 1–4, o alvo se declara; não substitui o skip link SH8). Mudam o cabeçalho, §1.5, §47.7, §71.6, §71.8, §73.5 e §75.8.) · v1.60 (Grupo 2, segunda leva, 2026-09-15 (MANIFESTO §225.5–§225.8) — SH-P11: a tabela SH17 (§46.4) ganha a coluna "rail funcional (medido)" — as dez telas de aplicação passam a compor a casca REAL do shell pelo módulo único shell_bloco.py (CP-13 11 de 11 PASS; antes só a tela-shell tinha rail funcional), e o §46.5 diz que casca ilustrativa é o que o SH18 chama de bancada. HV-P4 relida: erratas no §71.5 (censo de 2026-09-15 ao lado do de agosto: 552 HV1-a · 1.224 HV1-b · 0 HV1-c em 39 arquivos), §71.6 (a frase "nenhum consumidor de action-ghost-hover sobre elevada" envelheceu — são 5; action-neutral-hover é surface-subtle, logo controle transparente sobre a casca tem sobrevoo invisível por construção — decisão em gate; o metal do §93.3 é a terceira forma aceita de pressionado) e §71.8 (estado e plano). Mudam o cabeçalho, §46.4, §46.5, §71.5, §71.6 e §71.8.) · v1.59 (Grupo 2, primeira leva, 2026-09-15 (MANIFESTO §225.2) — LC-05 FECHADA: o pressionado é fundo por TOKEN nas cinco variantes do botão (o destructive também não tinha :active: eram quatro sem par, não três). Nascem nos gêmeos (tokens v1.28), sem hex novo, action-secondary-bg-hover/-active, action-ghost-active e action-destructive-active; §1.5 ganha a regra "pressionado é SEMPRE fundo por token, um passo além do sobrevoo, na mesma direção — nunca véu/filter" (o canon já decidia amplitude, mecanismo e direção em §1.5/§71.2/§71.6; faltavam os tokens); §1.6, §1.9, §1.10 e §1.11 acompanham; o §18.3 deixa de citar o token fantasma --seed-action-primary-bg (o certo é --seed-action-primary, 3,81/5,31 sobre o trilho). Nasce a suite-botao.mjs (47 de 47). Aplicação da sessão, exposta a veto com os renders na folha do Grupo 2.) · v1.58 (Veredito do gate do Grupo 1, 2026-09-15 (MANIFESTO §224.1), verbatim: "V-CT9 regra: a · V-LC11 data-arquetipo: sim · V-STASH: a · veto: nenhum". CT-P9 FECHA: a tinta de marca sobre superfície suave EM REPOUSO (surface-subtle, surface-brand-subtle: 4,23 e 4,28) é text-brand-strong (5,82 e 5,89) em qualquer estado — linha nova na gramática do §73.5, notas de consumo nos §22.2, §32.2 e §46.5; nenhum token muda. Nasce o SH18 (§46.5): toda tela publicada declara no <html> o data-arquetipo (aplicacao · autenticacao · pagina · bancada · documento) — os 16 moldes declaram, o CP-13 mede sem --arquetipo. Os sete itens do §223.7 (SH-P9 = b no acervo inteiro, entre eles) passam de aplicação exposta a veto a decisão dele. Mudam o cabeçalho, §22.2, §32.2, §46.5 e §73.5.) · v1.57 (Grupo 1 em paralelo, 2026-09-14/15 (MANIFESTO §223) — SH-P9 FECHADA por aplicação: o "peso 800" do shell, do painel, de 24 moldes de bancada/tela e do papel titulo-tela NUNCA foi sintetizado — o Chrome só engrossa por síntese quando a face casada pesa menos de 600, e com a face 700 carregada o 800 rendia a própria 700; provado por captura pixel-idêntica (0 px em 4 telas × 2 temas pelo agente e, de novo, 0 px pela sessão principal forçando TODO peso ≥ 800 a 700). Os 800 viram 700 no acervo inteiro (tokens v1.27), sem mudança visível; a nota do §46, o PN13 e o BU-02 dizem 700; a guarda TP1 ganha a cláusula TP1-d "peso pedido tem face" (achado contado). CT-P9 medida: censo RC em 208 de 208 HTML — ZERO ocorrências do par em bancadas e telas; a regra vai ao gate (V-CT9). LC-11 FECHADA: o conferir-peca.py ganha o CP-13 (shell §46 medido no DOM). Nada mais muda neste canônico.) · v1.56 (MA-P2 FECHADA, 2026-09-14 — veredito dele, verbatim (MANIFESTO §221.1): "V-MA2.1 MA-P2: fechar · V-MA2.2 site: a · veto: nenhum". O MA12 do §93 deixa de esperar a medição: vidro fora do chrome e dos cartões do painel está LIBERADO com o piso de campo medido em 2026-09-14 (MANIFESTO §220.2): 4 núcleos · 8 GB · monitor de 60 Hz · janela 2560 px — as duas cenas seguram a taxa do monitor (16,7–17 ms por quadro com e sem a camada) e o único custo é UM quadro isolado de 50–67 ms por rolagem de 3 s, [inferência] no primeiro desenho; nenhum custo contínuo em cinco portes de máquina — sempre sob a régua obrigatória (MA7). E o site (§47) recebe a camada: tela-site.html v0.3 com casca com luz, cabeçalho em vidro e ação primária em metal (a variante que ele viu nas folhas F10.5 e MA-P2), tinta de marca em text-brand-strong (§5-g: text-link caiu a 3,83 e 4,29 sobre a luz e o vidro; linha de base sem a camada 84/84), régua RC 84/84 nos dois temas, suite-site 66/66, render-site 23/23, cabeçalho fixo medido em y = 0 a 1440 e 390 px. Mudam o cabeçalho, o MA12, o §93.6 e a linha do §47.) · v1.55 (Gate F11.1 APROVADO, 2026-09-14 — veredito dele, verbatim (MANIFESTO §220.1): "V-F11.1 tabela SH17: confirmo · V-F11.2 login: aprovo · veto: nenhum". A tabela do SH17 (§46.4) deixa de ser "aplicado sem pergunta — exposto a veto" e vira decisão dele; o login v0.5 com a logo vertical (§83) está aprovado e a MA-P3 fecha. Só o §46.4 e este cabeçalho mudam.) · v1.54 (F11.1 + MR-P18, 2026-09-14 — nasce o SH17 no §46.4: NO PRODUTO, TODA TELA DE APLICAÇÃO VIVE DENTRO DO SHELL — o shell é a casca e o gabarito A1–A20 é o conteúdo; a referência de um gabarito publicada sem casca (raiz tela, CP28) é decisão de bancada, nunca de produto. Tabela dos 16 gabaritos com "referência traz a casca" (medido no disco) × "no produto" (decisão) — A4 painel, A13 documento e A18 configurações ficam DENTRO; A19 login e A5 site, FORA. Motivo: em 2026-09-14 a sessão do ERP construiu "Configurar funil" pelo A18 e a tela saiu sem rail — ele reprovou ("tem certeza que as telas sao assim? o quadro aprovado do ERP tem uma rail a esquerda"); o §86 não citava o §46 e nada no canon dizia a frase. Notas de casca nos §48/§83/§86/§88. E a MR-P18 (gate MA-P3, observação dele no login): a §83 passa a registrar a tela v0.5 — logo VERTICAL oficial por tema no lugar de símbolo + nome escrito, classes dos <style> de SVG prefixadas (o <style> de SVG embutido é global e o fill branco do escuro apagava o turquesa do claro) — suíte 24 PASS (AU-12 reescrito, AU-16 e AU-17 novos). Registro: MANIFESTO §218 e §219.) · v1.53 (F10.6, 2026-09-13 — a camada de material (§93) chega a quem consome o DS por três caminhos gerados da mesma fonte: o registry ganha o item @seed/material (classes .seed-mat-* emitidas pelo material_bloco.py, a mesma receita das nove telas), a vitrine ganha a página /material/ (a regra byte a byte, a amostra viva montada só com o registry, controles que mexem nos tokens ao vivo, as telas que carregam a camada medidas no disco e a bancada de custo da MA-P2) e a skill seed-ds herda o passo do material no modo código. A bancada mediu nesta máquina de desenvolvimento (8 núcleos, 16 GB, Chrome 153): custo do vidro indistinguível até 240 cartões — 8,3 a 8,9 ms por quadro com e sem a camada; a medição em máquina de CAMPO continua sendo o que libera vidro fora do chrome (MA12). §93.6 atualizado. Registro: MANIFESTO §213.) · v1.52 (Gate F10.5 APROVADO, 2026-09-13 — veredito dele, verbatim (MANIFESTO §212): "V-M5 chat: aprovo · V-M5 detalhe: aprovo · V-M5 gantt: aprovo · V-M5 lista: aprovo · V-M5 quadro: aprovo · V-M5 referencia: aprovo · V-M5 tabela: aprovo · V-M6 luz do topo do rail: 8 · V-M7 site: a · veto: nenhum". As sete telas de aplicação saem de "em gate"; a luz do topo do metal do rail fica em 8 % (tokens v1.26, agora decisão dele); o site (§47) fica SEM a camada até a medição de GPU (MA-P2), por veredito. Nove telas com material, todas na régua RC do rito. Nenhuma mudança de gerador nesta edição.) · v1.51 (F10.5, 2026-09-13 — a camada de MATERIAL (§93) entra nas sete telas de referência com gerador que faltavam: chat §55, detalhe §49, gantt §58, lista §92, quadro §57, referência e tabela §40 — pelo mesmo módulo único da F10.4 (material_bloco.py), com as peças que o decisor marcou em V-3 e que existem em cada tela (casca com luz, barra superior e sidebar em vidro, rail em metal, avatar e botão de enviar em metal, número das faixas de estatística com brilho; conteúdo opaco por MA3). A régua de contraste rasterizado (RC) achou o que a primeira aplicação não podia ver: 12 rótulos brancos do alto do rail abaixo do piso (3,25–4,27) sob a luz do topo do metal — o shell passara na F10.4 porque o item ATIVO, com pílula clara, ocupa a primeira posição do rail; o próprio shell sem a pílula reprova igual (3,62). Correção medida nos tokens v1.26 (a luz do topo do metal-sheen cai de 30 % para 8 %; 18/18 medições passam, pior 4,69), aplicando a regra MA2 que já existia. Três instrumentos aprenderam a camada com o sinal certo (RAIL-02 da suite-composicao, SH1-c da guarda-colisao, rota 1 do contraste-composicao); §93.3–93.7 atualizados. Nove telas com material; a tela do site (§47) foi renderizada como variante e aguarda o veredito dele (V-M7). Estado: entregue em gate (F10.5). Registro: MANIFESTO §211.) · v1.50 (SH-P10 FECHADA, 2026-09-13 — veredito dele, verbatim: "SH-P10: b-tirar-do-rail". O SH5 do §46 ganha a redação por região: no RAIL a marca do item ativo que sobrevive ao cinza é a pílula clara (turquesa-100 sobre o gradiente escuro — luminância, 5,31/7,87) mais o peso; a barra lateral de 3 px é da SIDEBAR, onde o ativo é só um fundo quase igual ao papel. A regra ::before saiu dos 8 moldes com rail (shell + chat, detalhe, gantt, lista, quadro, referência, tabela), as 8 telas foram regeradas byte-idênticas, a suite-shell (SH5-04) e a suite-composicao (PX-01/PX-02) passaram a provar a AUSÊNCIA da barra e a presença da pílula. Registro: MANIFESTO §209.) · v1.49 (§93 estável, 2026-09-13 — veredito dele no gate F10.4 (MANIFESTO §207, verbatim: "V-M1 shell: aprovo", "V-M2 painel: aprovo", "V-M3 metal do rail: 1", "V-M4 sidebar: vidro", "veto: nenhum"). A sidebar entra na receita de vidro (MA1; fecha a MA-P4), o rail fica no valor do token (§93.5) e a §93 sai de emitido · em gate para estável. Do mesmo gate nasce a SH-P10 no §46: ele apontou a barra vertical branca ao lado do item ativo do rail ("essa barra nao deveria estar ali") — é a marca de ativo do SH5, decisão registrada, medida e levada a ele com as duas saídas renderizadas; não foi mexida.) · v1.48 (§93 NOVA, 2026-09-12 — F10.2: MATERIAL, vidro e metal, entra no canon como camada transversal de acabamento (MA1–MA12), no mesmo dia em que a F10.4 a aplica pelos geradores nas duas primeiras telas (shell §46 e painel §48) e a régua de contraste rasterizado (contrato RC) as mede nos dois temas — zero texto abaixo do piso. A seção diz onde vai vidro, onde vai metal, o que fica opaco, como se emite (módulo único material_bloco.py, nunca CSS copiado), a regra de contraste do metal, a tinta de marca dentro do vidro (text-brand-strong, §5-g), a calibração por peça e as medições da primeira aplicação. Origem: veredito dele V-1 = B em 2026-09-12 (MANIFESTO §204), tokens seed-tokens.md §3d v1.24/v1.25. Na mesma edição: errata E-CF-06 no §46 (a conta de "9 caracteres em 68 px" do SH3 foi medida a 9 px em agosto e o papel micro passou a 11 px na v1.14 — o rótulo ativo a 800 media 71,5 px e vazava 1 px da pílula, MA-P6; conserto no gerador: o rótulo consome o tracking do papel) e nasce a SH-P9 (o shell e o painel pedem peso 800 sem declarar face 800 — negrito sintético do 700).) · v1.47 (2026-09-10: três correções medidas — o alvo de toque de 44×44px é regra da SEED, NÃO da WCAG (o piso AA do SC 2.5.8 é 24×24; os 44 são o SC 2.5.5 AAA), e o canon passa a citar a ABNT NBR 17225:2025 ao lado da WCAG 2.2 (PB-P8 fechada); e o exemplo do MK28 sobre o domínio vira história datada, porque o principal passou a servir o site novo.) · v1.46 (§47.6, 2026-09-09: nasce o PACOTE GEO do site institucional — MK24 a MK28.** O DS especifica e o projeto do site aplica. MK24: a política de robôs é ESCRITA, nomeando cada robô em dois grupos (treino · busca e ação de pessoa), com a lista lida nas páginas oficiais em 2026-09-09 — apareceu o OAI-AdsBot, ausente da lista de quatro dias antes, e as duas páginas mudaram de endereço. MK25: JSON-LD por TIPO de página, e nenhuma página do sitemap fica sem. MK26: o llms.txt do site é gerado do que o site publica. MK27: descoberta ativa — Bing Webmaster, Search Console e IndexNow, cuja chave tem o nome dela própria. MK28: a régua mede o site SERVIDO, com denominador, e a primeira coisa que confere é o DOMÍNIO — a medição de 2026-09-09 feita em seed.eng.br deu um retrato falso porque naquele dia o domínio principal ainda servia o site ANTIGO. Entregável da F9.4 do roadmap; linha de base medida no §47.6.** · anterior v1.45 (MK23, 2026-09-06: a camada de máquina do §47 ganha o contrato do CONSUMIDOR — toda página, instrução de uso, pacote ou índice publicado para IA serve a QUALQUER agente: audiência escrita "qualquer IA" (nunca "para o Claude"), primeiro caminho por endereço público sem instalar nada, caminhos por arquivo depois, um por tipo de IA; e a checagem de fechamento passa a ter QUATRO verbos — achar, ler, citar e USAR. Origem: a página /skill/ da vitrine nasceu em 2026-09-06 "para quem produz com o Claude" com a camada de máquina certa (MK1–MK12 passavam na guarda) e o consumidor errado; o decisor teve de pedir, e ordenou (MANIFESTO §176, verbatim): "tudo que fazemos deve ser rastreável e lido por IA (…) se está faltando colocar isso explicitamente em algum lugar, providencie para esse tipo de erro não acontecer novamente." Guarda transversal VT-13/SK-11 (consumidor_unico.py) acusa a forma errada em toda a vitrine, no llms.txt e na skill; exposto a veto) · anterior v1.44 (LC-06, 2026-09-06: a TINTA DO BOTÃO PRIMÁRIO no §1 e no §54 passa de text-on-brand a text-on-action-primary — a tinta que os tokens v1.15 criaram para action-primary (MR-P1, §64.14: "três tintas, uma por fundo"); text-on-brand é a tinta sobre a marca chapada e vale #00352F nos dois temas — sobre action-primary mede 2,95:1 no claro (piso 4,5), enquanto text-on-action-primary mede 4,60 · 7,39. Corrigidos a tabela de variantes (§1.3), o CSS (§1.9), o exemplo React (§1.10) e o repouso do botão dividido (§54) — a forma era pré-existente e se corrige em todos os lugares. Achado pelo teste de uso da skill seed-ds (MANIFESTO §169.3), autorizado por ele no §170; nenhuma aparência muda onde o registry @seed/theme já apontava --primary-foreground para o token certo) · anterior v1.43 (SI-31, 2026-09-05: o seletor de identidade do §65 ACOMPANHA a GL-R2 — 31 glifos, grade de 6 colunas com 5 linhas cheias + 1 célula, bancada banco-identidade.html v0.4; a régua SI5 passa de "linhas inteiras" a "linhas inteiras EXCETO a última", por decisão dele (MANIFESTO §150, verbatim: "T-SET: glifo novo + régua da grade aceita última linha incompleta (recomendado)"). Por quê: 31 é primo — nenhuma grade de 2 a 30 colunas fecha em linhas inteiras; a régua da v1.40 era consequência de 28 e de 30, não princípio. Na última linha incompleta, célula sem vizinha abaixo: ↓ deixa o foco onde está — padrão WAI-ARIA APG para grid (consultado em 2026-09-05: "If focus is on the bottom cell in the column, focus does not move"); até a v0.3 o script mandava o foco à última célula, trocando de coluna sem avisar (o mesmo valia para ↑ na primeira linha — corrigido junto, exposto a veto). gen-banco-identidade.py v0.4 (TOTAL_GLIFOS = 31; tinha ABORTADO em 30, como devia), suite-identidade.mjs 33 · 0 · 0 · 1 (nasce a SI-OP3c, que mede a última linha; eram 32), MD5 da bancada 26023b0632d65e7e21b974e839e2617c idêntico em duas gerações. Registro completo no §65.13.) · v1.42 (GL-R2, 2026-09-05: dois glifos pelos modelos em imagem dele (MANIFESTO §150) — nasce transmission-tower (torre de transmissão; destaque Subestações; 30 → 31 glifos ativos) e o generator é REDESENHADO (mesmo nome, mesma célula; supersede em §45.4). Vereditos verbatim: "T-TORRE: segue anexo imagem de uma torre para utilizar. use como modelo" · "T-GMG: redesenhar agora — segue foto anexa de exemplo para usar" · "T-TRACO: 1,25 (recomendado)". Os anexos não estão em disco; a descrição deles registrada no §150 foi o modelo. Densidades desenhadas no grid 24 / traço 2 / round-round e renderizadas a 24 px REAIS (captura do <svg> no Chrome, DPR 1, posição inteira, ampliação 6× sem suavização) em preview/gate-apoio-glifos-r2/glifos-r2.html: torre D1 (uma travessa + X — a T1 do estudo §149), D2 (duas + X), D3 (três travessas decrescentes + X + chão — o modelo completo); gerador G1 (contêiner + chaminé + porta + raio), G2 (tudo como na foto, indicadores no alto), G2b (raio grande + indicadores no painel da porta + pés). Régua decisiva, MEDIDA na captura de 24 px: pelo menos 1 px de fundo entre elementos vizinhos (cobertura de tinta abaixo de 50 %). Aplicados D3 — perfil da coluna central x = 12: topo, três travessas, cruzamento do X e chão separados por 1 / 1 / 1 / 2 / 2 px; só coube com as travessas em y 6 / 9 / 12 (coordenada INTEIRA: com traço 2 a linha ocupa exatamente 2 linhas de pixel; a T1 em 8,5 esparramava em 3) e o X começando 2 unidades abaixo da última travessa (14 → 21) — a 1ª tentativa, com o X partindo da travessa, fundiu os dois numa corrida de 5 px; e G2b — indicadores r 0,5 preenchidos medem 3 px e ficam a 1 px da parede e da porta; o desenho antigo tinha dois pontos r 1 a 3,5 de distância, que com traço 2 se sobrepunham (o "blob" da filmadora). Escolhas EXPOSTAS A VETO com as demais densidades renderizadas ao lado; D2 (vãos 1 / 2 / 4 px) é a reserva declarada se ele achar os vãos de 1 px da D3 finos demais. getBBox medido no Chrome: torre 2,5…21,5 × 3…21, gerador 3…21 × 2…22 (piso IC2 1…23); pontas todas em .0/.5. Aliases da torre: torre, alta-tensao, transmissao, linha, lt — subestacao continua da substation, que permanece no set (a cabine ainda é objeto legítimo do domínio; só o destaque troca de glifo). Lucide main sem transmission-tower (404 em 2026-09-05). Denominadores no MESMO movimento: bancada banco-icones.html 31 (três strings), suite-icones.mjs IC-01 = 31, gen-destaques-instagram.py guarda 31 e subestacoes → transmission-tower, mais o traço óptico do destaque TRACO_DESTAQUE = 1,25 (T-TRACO; o set segue traço 2 a 24 px — o parâmetro vive só na extração para a peça). Placares MEDIDOS: suite-icones.mjs 25 verdes · 0 vermelhos (IC-01 = 31) · render-icones.mjs 5 · 0 (R-01 getBBox 31/31 dentro de 1…23). O seletor de identidade §65 acompanha em movimento próprio (T-SET: última linha incompleta aceita).) · v1.41 (IC-P2, 2026-09-05: a coluna "Lucide" do solar-panel no inventário §45.3 dizia —; o Lucide TEM solar-panel (conferido no main em 2026-09-05 pela frente FV-P5). Corrigida a linha por ordem dele ("IC-P@: corrija", MANIFESTO §149). Só a coluna de referência muda — o desenho do set não.) · v1.40 (SI-30, 2026-09-05: o seletor de identidade do §65 ACOMPANHA o set do §45 — 30 glifos, grade 6 × 5 (era 7 × 4 = 28), bancada banco-identidade.html v0.3. Executa a consequência que a v1.39 deixou registrada como não executada ("30 não fecha em 7 colunas (6 × 5 fecha)") — consequência óbvia, aplicada pela sessão e EXPOSTA A VETO dele. O achado que vale mais que o número: o INVENTARIO do gen-banco-identidade.py era lista de 28 nomes copiada à mão do §45.3 (só desenhos, categorias e aliases vinham da bancada) e envelheceu em silêncio quando o set mudou; agora o inventário INTEIRO é DERIVADO de banco-icones.html (a fonte que a IC-01 valida e que o gen-destaques-instagram.py já lê) e reordenado na ordem do §45.3 — os 28 antigos saem na mesma sequência, hard-hat na 6ª e solar-panel-plus na 13ª; fica declarado só o denominador TOTAL_GLIFOS = 30, com abort se a bancada divergir. A régua do SI5 é linhas inteiras, não 7 colunas: 30 = 2·3·5, e 6 × 5 é o vizinho do 7 × 4 aprovado em 2026-08-17. suite-identidade.mjs 32 · 0 · 0 · 1 antes e depois (9 asserts mudam o valor medido; limiar da SI-OP3b passa a ser lido do DOM); suite-icones 25 · 0; guarda-barra-provas 9 · 0 · 15 · 24; paridade-previews 825 · 0 (209 · 15); regeneração dupla MD5 a2f5a8591e070c69069c8e2d84839c74; medido no Chrome: 30 células 44 × 44 em 5 linhas de 6, nenhuma vazia, nenhum glifo cortado. Detalhe e alternativas descartadas no §65.12; SI-P1 segue aberta.) · v1.39 (FV-P5, 2026-09-05: o set do §45 ganha dois glifos de domínio — hard-hat (destaque Obras) e solar-panel-plus (destaque SEED Plus); 28 → 30 glifos ativos. Veredito dele, verbatim (MANIFESTO §147): "FV-P%: pode criar". Origem: as capas de destaque do Instagram (marca-seed.md §12.31, MANIFESTO §146) usam o set §45 e Obras e SEED Plus saíam só com rótulo. Criados pela árvore NM4 ③ na régua IC1/IC3/IC5/IC6 — grid 24 × 24, traço 2, round/round, currentColor, coordenadas com 1 decimal; getBBox medido no Chrome: hard-hat 2,5…21,5 × 5…19 e solar-panel-plus 2,5…21,5 × 3…19 (piso IC2 é 1…23). Desenho PRÓPRIO; o vocabulário de mercado entrou só como referência de leitura (Lucide hard-hat, tags helmet/construction/safety, conferido em 2026-09-05; badges -plus do Lucide como file-plus/shield-plus). Sentido, pelo sobreaseed.md: Obras = execução em campo (§11, "+1.000 obras entregues"); SEED Plus = plano de manutenção para usinas solares (§6) — daí o painel (o objeto do plano) com o sinal de mais (o sufixo da marca), e não o sol, que é o glifo do pilar Energia Solar exibido AO LADO no perfil. Alternativas renderizadas e descartadas (folha preview/gate-apoio-fv-p5/): crane (guindaste — a 24 px lê como "T" com argola antes de guindaste) e wrench-plus (chave — lê "conserto/corretiva", e chave é vocabulário utilitário do Lucide, NM4 ②). Denominadores atualizados no mesmo movimento: suite-icones.mjs IC-01 28 → 30 (25/25 ✓), render-icones.mjs 30/30 em 1…23 (5/0), gen-destaques-instagram.py (guarda 28 → 30; obras → hard-hat, seed-plus → solar-panel-plus). ⚠ Consequência NÃO executada, decisão dele: o seletor de identidade do §65 (banco-identidade, grade 7 × 4 = 28, asserção SI5 28 % 7 == 0) segue com os 28 glifos de agosto — 30 não fecha em 7 colunas (6 × 5 fecha). Desenhos EXPOSTOS A VETO dele.) · v1.38 (§90 e §91 EMENDADAS no mesmo dia (2026-08-24, tarde), por informação nova dele: o app de campo com cadastro OFFLINE e sincronização — OS e ponto — é decisão tomada, não hipótese.** Isso NÃO contradiz a decisão (c) do gate, que guardou exatamente a peça comum aos dois mundos, mas revela o que faltava: nascem OF10 (quatro estados por item — enviado · não enviado · sincronizando · falhou; a sincronização é evento COM RESULTADO que não some sozinho; o pendente é alcançável antes de sair do local; e nunca "sincronizado" otimista) e OF11/§90.11 — a OF-P1 deixa de ser hipótese e ⚠ o PONTO tem regra própria acima da LGPD: a Portaria MTP 671/2021 admite marcação offline com sincronização posterior, mas exige criptografia de 128 bits em trânsito E em repouso, comprovante ao trabalhador por marcação em PDF com assinatura PAdES (peça que não existe no inventário — PT-P1) e registro que não se altera. ⭐ E a emenda resolve uma COLISÃO REAL entre duas cláusulas aprovadas no mesmo gate: a CE4 manda travar o objeto que gera documento com ART, e não se adquire trava sem rede — a CE4-f separa COLETA (offline-first, sem trava) de EMISSÃO (online, com trava), e isso não afrouxa nada, porque dado que chega por sincronização não se mescla em silêncio: entra com autoria e horário, e quem assina decide. Nasce ainda a CE9, o conflito detectado na SINCRONIZAÇÃO — chega em lote, tarde e sem ação em curso, então é aviso assíncrono e nunca alertdialog, nunca resolve sozinho, nunca descarta, e não vira trinta diálogos em sequência.) · anterior v1.37 (§90, §91 e §92 NOVAS (2026-08-24, F7.7-P5): os TRÊS ESTADOS que o §6.1 do mapa marcava ❌ AUSENTE desde a F7.1 passam a estável por cinco decisões dele no gate. §90 OFFLINE (OF1–OF9): offline NUNCA se declara por flag — navigator.onLine devolvendo true não garante nada e desabilitar por ela travaria quem usa VPN, que é a nossa gente de campo — e são DOIS estados, "você está sem conexão" × "não foi possível alcançar o sistema", continuação direta da MC3 que ele decidiu na §89. A fila de ações fica como OF-P1 com a obrigação de LGPD escrita ANTES de alguém implementá-la, porque fila grava dado pessoal no dispositivo. §91 CONFLITO DE EDIÇÃO (CE1–CE8): detectar é obrigatório e é do servidor (ETag/If-Match/412 da RFC 9110 — aviso na interface não impede perda, informa); regime padrão OTIMISTA com aviso de presença que não bloqueia, e ⭐ exceção de TRAVA EXCLUSIVA para objeto que gera documento com ART, porque quem assina responde pelo que está lá e conteúdo mesclado em silêncio é risco que a interface não pode criar; três saídas no conflito, com as destrutivas sob MC4 e MC5. §92 LISTA LONGA (LL1–LL6), que FECHA A BU-P1: a regra nasceu de COBAIA porque a lista mais longa do acervo tem 38 itens e não exercita o problema; limiar MEDIDO em 2.000 linhas (um layout forçado custa 222–395 ms contra orçamento de 200 ms de INP); paginação é o padrão da lista de trabalho por ACHABILIDADE, não por desempenho; e ⭐ contenção nativa rende 5,87×–25,47× em blocos e NADA em tabela — mas getComputedStyle devolve auto nas duas, logo esta regra não tem conferência por declaração, só por tempo (LL-P1), terceira vez que a régua óbvia mente nesta casa.) · anterior v1.36 (§89 NOVA (2026-08-24, F7.7-P4): a MICROCÓPIA DE INTERFACE é estável por CINCO decisões dele no gate — MC1 rótulo = verbo + substantivo · MC2 sentence case · MC3 voz do erro IMPESSOAL (com "nós" só quando a falha é da SEED, porque o produto emite documento com ART) · MC4 confirmação com verbo específico (ele preferiu (a) à minha recomendação, e o custo enunciado no gate ficou escrito) · MC5 o corpo do diálogo declara a CONSEQUÊNCIA, não faz pergunta retórica. Mais 13 regras que a evidência ou o nosso canon já fechavam — a §10 da marca já proibia emoji e exclamação, então a §89 só propaga. A rodada de pesquisa (12 fontes, incluindo o guia de localização pt-BR da Microsoft e o guia do GNOME Brasil) mostrou que três "consensos" extraídos do produto medido eram DIVERGÊNCIA entre guias maduros: copiar o vizinho teria importado escolha alheia como lei. A §89.3 é a parte que só fonte brasileira resolvia: o registro verbal por elemento (infinitivo em botão, 3ª pessoa em tooltip, imperativo em instrução) e a distinção "não é possível" × "não foi possível". Sem guarda automatizada ainda — MC-P2 lista o que é mecanicamente verificável.) · anterior v1.35 (§88 NOVA (2026-08-23, VIGÉSIMA SEXTA parte): a TELA A13 — DOCUMENTO/LEITURA é estável por gate dele ("aprovo") e A F7.6 FECHA — 6 TELAS DE 6, produzidas em DOIS DIAS de gates encadeados sobre o consolidado de 2026-08-22: A19 §83 · A20 §84 · A17 §85 · A18 §86 · A14 §87 · A13 §88 — seis suítes, 101 PASS · 0 FAIL somados. A A13: canvas chapado C25 (o canvas É a tela), coluna de leitura 660px no registro da marca §4.1 (16px Light 1.65, "aproveitar a tela" recusado), figura com tokens de dado + fallback DG1, e o PAPEL como contrato: @media print no padrão DI com a TINTA VIGENTE — a errata do banco-dataviz-di virou LEI (a suíte reprova hex aposentado; o PDF real medido nos bytes: zero). RT/CREA/ART como placeholders de template (Lei 5.194). Divergência declarada: rota, não overlay. Da F7 resta a F7.7.) · anterior v1.34 (§87 NOVA (2026-08-23, VIGÉSIMA QUINTA parte): a TELA A14 — FEED/ATIVIDADE é estável por gate dele ("aprovado"), suíte 16 · 0 · 0. A INVERSÃO C33 — exceção escrita do CP2 desde a F7.1 — aplicada pela primeira vez em tela, com a condição de admissão MEDIDA (agrupador sunken sem sombra e não-acionável; objetos = peças claras acionáveis); os DOIS PESOS do §56 em composição real (evento = linha com de→para inline; comentário = BLOCO não-cartão); e o C27 timeline ganha a primeira spec (fio + marcador; o do comentário distinto), fechando a lacuna "existe no painel sem spec". Escopo = P3 do consolidado: atividade GLOBAL (histórico de projeto/manutenção), não a central §33. Divergência declarada: rota, não overlay.) · anterior v1.33 (§86 NOVA (2026-08-23, VIGÉSIMA QUARTA parte): a TELA A18 — CONFIGURAÇÕES é estável por gate dele ("aprovo"). Era um dos DOIS arquétipos SEM leitura — fechado pela volta dirigida de 2026-08-22. A decisão que o consolidado deixou em aberto foi tomada e gateada: DOIS REGIMES DE GRAVAÇÃO — formulário salva EXPLÍCITO (barra de dirty; o botão confirma "Salvo." no lugar; salvar NUNCA desabilitado) e switch aplica IMEDIATO com anúncio (o §8 já dizia "configuração é Switch"). Mais: "Sair" isolado no rodapé da navegação · chip de estado que ESPELHA o grupo · preset Padrão/Personalizado com engrenagem condicional · indisponível com correção inline · lateral vira ABAS <600px (provado em navegador real). Contratos CF-01…CF-11 na suite-configuracoes.mjs (18 · 0 · 1 [n/a] provado) — incluindo CF-11, o primeiro check de LGPD em suíte (reprova se dado pessoal real entrar na demo). Primeira tela da F7.6 que NASCE conforme à HV1. Registro: a régua CF-09a saiu com &&…|| traiçoeiro e foi reescrita antes da promoção — régua que passa por acaso é régua que mente.) · anterior v1.32 (§85 NOVA (2026-08-23, VIGÉSIMA TERCEIRA parte): a TELA A17 — BUSCA/RESULTADOS é estável por gate dele ("fora isso está aprovado"), com a correção do "fora isso" aplicada ANTES da promoção: ele pegou a HV1 de novo, a olho nu — a paginação sem resposta ao sobrevoo ("pelo que definimos era pra ter um efeito sobre o botao?" — TINHA: §71, nascido de gate DELE em 2026-08-19) — e o conserto foi RETROATIVO às três telas da F7.6 (hover neutro = degrau sunken · hover de fundo de marca = véu 8% · pressionado = véu 12%, monotônico, sob a receita do §71.2; hover só em @media (hover:hover), :active fora — toque pressiona). Contratos BU-01…BU-12 na suite-busca.mjs (15 · 0 · 1 [n/a] provado em navegador real): query ecoada + contagem sempre visível (D4-b) · realce por SUBLINHADO+peso 800 medido no pixel · chips que desmarcam a origem e voltam à página 1 (TD2/TD3/PG4) · zero-resultado D9 · debounce do espelho falado MEDIDO por espera real · gaveta mobile. ⚠ 49º defeito de instrumento: o check CSSOM reprovou as 3 telas CORRETAS — style rule também tem .cssRules (CSS Nesting), vazia mas truthy, e o flatMap ingênuo a trocava por lista vazia, engolindo os :active de topo. Suítes das irmãs cresceram junto: A19 22·0·0 · A20 15·0·1. Pendência nova BU-P1 (virtualização de lista longa — regra ausente no acervo).) · anterior v1.31 (§84 NOVA (2026-08-23, VIGÉSIMA SEGUNDA parte): a TELA A20 — ONBOARDING/PRIMEIRO USO é estável por gate dele ("a imagem da onboarding está ok. aprovo"). A taxonomia Z1 do §25 posta VIVA em composição, no hospedeiro painel §48: TRÊS estados não intercambiáveis (primeiro-uso educativo com EEny + critério dito · esvaziado · sem-permissão SEM EEny — Z5 provado por suíte), contratos ON-01…ON-09, suite-onboarding.mjs 14 · 0 · 1 [n/a] declarado (o [n/a] é container query = render, PROVADA em navegador real a 390px). Régua nova de mascote: medir o bounding box do pose por PIXEL antes de embutir (o pose-05, escolhido por peso, era o EEny DE COSTAS ocupando ~35% do canvas) e crop de APRESENTAÇÃO no viewBox do embed, desenho intocado. Esclarecimento de termo no gate: "byte-idêntico" = fidelidade embed↔asset, nunca igualdade entre poses — 8 poses, 8 MD5 distintos, medidos a pedido dele.) · anterior v1.30 (§83 NOVA (2026-08-23, VIGÉSIMA PRIMEIRA parte): a TELA A19 — AUTENTICAÇÃO existe e é estável — fecha a CD-P5 (aberta desde o §66). Primeira entrega da F7.6, na ordem aprovada no consolidado de 2026-08-22 (P1–P5, "aprovo"). A tela compõe o §66/§2/§1/gabarito F7.1 SEM componente novo; 14 contratos AU-01…AU-14 medidos por COMPORTAMENTO na suite-autenticacao.mjs (21 · 0 · 0). Gate visual dele em 2026-08-23 com uma correção, verbatim: "a tela de login deve ter o icone da seed no lugar do botao turquesa. fazendo essa correção, está aprovado" — o símbolo OFICIAL entrou por INJEÇÃO DE SCRIPT byte-idêntica (claro=principal · escuro=mono-negativo, tabela §5.1 da marca), e a AU-12 passou a conferir o path contra o asset. Sustenta a spec a LEITURA DIRIGIDA de 2026-08-22 (09-pesquisa/leitura-f76-bordas.md): os vizinhos REPROVAM nas normas que o §66 já absorveu (CU: autocomplete ausente, submit desabilitado, zero h1/main, placeholder-como-rótulo). Achados de produção: container query não estiliza o próprio container (pego por medição em navegador real; o container subiu ao body) · o Chrome CLI inventou um overflow a 390px que o navegador real desmente (reincidência da armadilha do marco v1.9) · o G: rejeita junction e o jsdom passou a viver fora do stream (env JSDOM_DIR; pendência AU-P1 para as suítes antigas). Pendências novas: AU-P1 (ambiente das suítes), AU-P2 (variante com faixa CP19), AU-P3 (multi-empresa pós-login).) · anterior v1.29 (§82 CRESCE para 5 cláusulas (2026-08-22, VIGÉSIMA parte): nascem MM1-d (arquivo de produção declara sangria ≥ 3 mm) e MM1-e (conteúdo a ≥ 3 mm do corte), com o veredito da sangria — "acredito que 3+3" — e o MÉTODO dele: "deixar o desenho dentro da area real, e a parte da sangria vc cresce o desenho". Consequência: passam a existir DOIS TIPOS DE ARQUIVO, gate e produção, cada um declarando o próprio papel no artefato. Pasta de prova de 7 para 11 fixtures; produção 15 PASS · 0 FAIL · 0 [n/a]. Canon v5.10 §7.4-e.) · anterior v1.28 (§82 NOVA (2026-08-22, DÉCIMA OITAVA parte): nasce o CONTRATO MM1 — a guarda do piso de traço em milímetros, de ALVO DE PASTA, com 3 cláusulas (piso ≥ 0,25 mm · alvo físico coerente com a razão em px · ≥ 3 pesos distintos) e pasta de prova de 7 fixtures escrita ANTES (13 PASS · 3 FAIL · 5 [n/a], batendo com o previsto). Decisão de arquitetura: quem é peça impressa é decidido pelo que o ARTEFATO DECLARA (<meta name="alvo-fisico">), nunca por nome de arquivo. E a MR-P8 fechou: pasta A4 de 105,7 para 300 DPI exatos, com o piso aplicado. Na estreia a guarda achou um defeito real do gerador: o piso estava sendo violado pelo ARREDONDAMENTO (0,24980 mm) — virou esclarecimento normativo no canon v5.8.) · anterior v1.27 (§81 NOVA (2026-08-22, DÉCIMA SÉTIMA parte): a MEDIDA FÍSICA DO CARTÃO é 90×50 mm, o padrão BRASILEIRO — veredito dele, verbatim: "escolho B". Canon marca-seed.md v5.7 §7.4-d. O achado: os 89×51 mm eram 3,5×2 polegadas, medida de EUA/Canadá que entrou como default de ferramenta, nunca como decisão de marca. Custo medido: uma linha nova no teto da §7.4 (84px de 590 = 14,2%), porque a tabela é indexada pela RAZÃO da peça. Custo zero em impressão: o piso de 0,25 mm sai em 0,250 mm nos três formatos testados. GR1 15·0·0; acervo dos 7 formatos 21·0·0, intacto. Pendência nova MR-P10: SANGRIA.) · anterior v1.26 (§80 PASSA A estável (2026-08-22, DÉCIMA SEXTA parte): o PISO DE TRAÇO EM MILÍMETROS existe. Veredito dele, verbatim: "saída B — piso de 0,25 mm por ESCALA, e só para peça IMPRESSA" → canon marca-seed.md v5.6 §7.4-c. Aplicado: o plano mais fino do cartão sai de 0,180 mm (2% de folga sobre o piso digital reverso) para 0,250 mm (42%), com os 4 pesos preservados — escala, não grampo, porque grampo achataria a hierarquia de peso, que é uma das três condições do §7.1. Peça de TELA fica fora, e isso está no código: ppmm só é passado nas chamadas de cartão. GR1 na pasta: 15 PASS · 0 FAIL · 0 [n/a].) · anterior v1.25 (§80 NOVA (2026-08-22, DÉCIMA QUINTA parte): o TRAÇO DO GRAFISMO EM MILÍMETROS — a lei do traço é em PIXEL, logo o traço físico de peça impressa é função da resolução de exportação. Medido: o verso do cartão APROVADO passa o piso digital reverso por 0,004 mm (2%), e a variante do verso nos 7 formatos REPROVA nos quatro planos. Três saídas com imagem, recomendação de piso de 0,25 mm por ESCALA — nada entrou no canon: piso é valor de marca e espera veredito.) · anterior v1.24 (§79 NOVA (2026-08-21, DÉCIMA QUARTA parte): o teto do grafismo no TOPO é de LARGURA, não de altura — F ≤ w / 6,5625, por veredito dele: "o ponto é medir a aplicação na largura se atende ao desenho selecionado para o topo, a altura nao importa". A altura da peça não entra e a razão de aspecto não gateia nada; a % da altura passa a ser DIAGNÓSTICO. Canon marca-seed.md v5.5 §7.4-b.) · anterior v1.23 (§78 NOVA (2026-08-21, DÉCIMA TERCEIRA parte): o decisor APROVOU a emenda de canon MR-P4 e o marca-seed.md passou a v5.4 — o grafismo agora tem DOIS REGIMES (DETALHE DE LINHA ≤~8% e SERRA-CENA com tetos POR FORMATO), e a guarda GR1 passou a ler o canon novo no mesmo dia: 5 fixtures novas escritas ANTES, inércia 7 de 7 nas antigas, e as peças largas de 11·4·0 para 15·0·0 — fechamento POR CANON, sem afrouxar limite nenhum.) · anterior v1.22 (§77 NOVA (2026-08-21, DÉCIMA SEGUNDA parte): o contrato GR1 do grafismo GANHA INSTRUMENTO — validacao/guarda-grafismo.mjs reescrita do zero (a original nunca foi propagada), alvo de pasta sem filtro de nome, medição por renderização diferencial julgada no pixel, pasta de prova render-audit/prova-gr1/ escrita ANTES com 7 fixtures e referência 10 PASS · 3 FAIL · 8 [n/a], e placar em 18 peças reais. Os 4 FAILs de L2/L3/L4/L5 são SANCIONADOS pelo decisor e esperam a emenda MR-P4. Nasce o 47º defeito de instrumento.) · anterior v1.21 (§76 NOVA (2026-08-20/21, DECIMA PRIMEIRA parte): o GRAFISMO DA MARCA entra como componente — a SERRA EM ARCOS no rodape (PADRAO, 4 planos, TOQUE EXATO, 12 pecas medidas) e a MONTANHA no topo (OPCAO do criador, 3 planos, oclusao com folga). ⚠ DOIS REGIMES DE REGRA INDEPENDENTES, por veredito do decisor: "considere que o topo segue uma regra e o rodape outra regra" — o toque exato e regra do RODAPE, nao lei da casa. Escada E1-nevoa aprovada no tema escuro; supersede formal do #0A6B60, cor de marca criada sem autorizacao e retirada por ordem dele (ΔE76 = 1,03 contra o token #006C62). Contrato GR1 escrito com as tres clausulas (area ≤10% · glifo velado 0px · faixa de rodape ≤~8%) mas HOJE SEM INSTRUMENTO: a guarda nunca foi propagada e todo placar GR1 antigo e historico e irreproduzivel (GR-P3). Registro completo no MANIFESTO §103; dimensoes novas no mapa §22.15.** · **§75 (2026-08-20, DECIMA parte, SEGUNDA rodada) (2026-08-20, DECIMA parte, SEGUNDA rodada): nasce o contrato TP1 — a tipografia e os recursos que o artefato declara REALMENTE CARREGAM, validacao/guarda-tipografia-viva.mjs, alvo de pasta: 30 PASS · 21 FAIL · 0 [n/a] no acervo (0 TP1-a · 21 TP1-b · 14 TP1-c) mais 85 achados de PORTABILIDADE e 56 de PRIMEIRA ESCOLHA. Ele nasceu de o Rafael perguntar se "uma imagem que nao carregou" mudava a avaliacao: NAO mudava (cor, tamanho, peso, retangulo dentro do cartao e pixel do fundo IDENTICOS com e sem imagem), mas a investigacao achou que o seed-design-system.html depende de 47 recursos de REDE e que 0 de 45 imagens e 0 de 2 familias tipograficas carregam — logo TODO recorte daquele artefato ja mostrado ao decisor saiu com a tipografia de RESERVA. ⚠ A regua obvia MENTE: document.fonts.check() devolve true com a fonte FALHANDO; as honestas sao [...document.fonts].length (0 antes, 7 depois) e a LARGURA EM CANVAS (348 = 348). ⚠⚠ Esta guarda esteve errada CINCO vezes (48, 46, 22 com 3 falsos, 6 de 6, e finalmente correta) e o numero de passes E o achado: quando uma regua nova reprova EM BLOCO, a primeira hipotese nao e "o acervo esta ruim", e "a regua esta medindo outra coisa". Nasce a pasta prova-tp1 (3 · 3 · 0). §75.6 registra as DUAS DECISOES DE COR que esperam gate e NAO foram aplicadas: (i) no amarelo, o pedido dele (manter o amarelo em 18px) nao era entregue por nenhuma das cinco opcoes porque a ONDA decorativa cruza a segunda linha — a saida e (E+), cartao #005048 + onda #00352F, 6,56 e 8,54, zero hex novo; e o kicker com opacity:.9 ja reprovava em 4,01 real contra 4,60 declarado. (ii) no dourado, a recomendacao (D) da folha v14.1 CONTRARIAVA o seed-tokens.md v1.5 de 2026-08-11, aprovado por gate dele — regua nova: antes de propor mudanca de VALOR de cor de marca, leia a linha do canon sobre aquela cor. A saida preserva o hex: #F9B11C intocado mede 7,48 sobre #242E34 ou como AREA com rotulo escuro. Pendencias novas: RD-P1, CC-P11, CC-P12, TP-P1. Anterior: v1.19 — **§74 NOVA (2026-08-20, DECIMA parte): o contrato BT1 (barra de provas travada no topo, §64.1, de 2026-08-16) FECHA POR INSTRUMENTO — nasce validacao/guarda-barra-fixa.mjs, de ALVO DE PASTA, com quatro clausulas das quais TRES sao COMPORTAMENTAIS (a pagina e rolada de verdade). O motivo de existir: a BT-P2 foi declarada FECHADA em 2026-08-17 sobre uma LISTA ESCRITA A MAO de dez artefatos, e o acervo tem trinta e quatro — o Rafael achou o resto a olho nu ("acredito ter outros"). Placar: 22 PASS · 11 FAIL · 18 [n/a] -> 33 · 0 · 18, medido a 1440x900 E a 320x900 (9 BT1-a · 10 BT1-b · 0 BT1-c · 2 BT1-d). LICAO: pendencia de contrato TRANSVERSAL nao fecha por lista — fecha por instrumento de ALVO DE PASTA. A primeira tentativa de conserto foi REVOGADA pelo print (a barra travou ABAIXO do titulo; o no foi MOVIDO para primeiro filho de <body>), e duas suites reprovaram o conserto com razao (tokens fantasma em seis arquivos: 38·1 -> 39·0 e 92·1 -> 93·0). Nasce a pasta de prova prova-bt1 (1 PASS · 4 FAIL · 2 [n/a]), que pegou DOIS defeitos do proprio instrumento antes do acervo. Nasce tambem a regra de forma de entrega DEMONSTRACAO VIVA E EXTRAIDA, NUNCA REDIGITADA (validacao/extrai-vivo.mjs), com o 44o defeito: a v1 lia CSS por REGEX e chave dentro de COMENTARIO desalinhou o parser — 3 de 5 quadros sairam sem tokens; reescrita por CSSOM, 5 de 5. Pendencias novas: BT-P3 (o BT2, seletor de LARGURA, nunca foi medido) e IN-P2 (nenhum censo diz quais .mjs leem CSS por texto em vez de CSSOM). Anterior: v1.18 — **§73 NOVA (2026-08-20, NONA parte): a HV-P5 FECHA — nasce --seed-text-brand-strong (gemeos v1.19, claro #006C62 / escuro #66D1C2, ZERO hex novo) e o contrato HV1-e: tinta cujo piso foi verificado num UNICO fundo nao serve a estado. O numero que fecha a decisao: para #098475 alcancar 4,5 o fundo precisa de luminancia >= 0,978 — o cinza mais escuro que serve e #FDFDFD — logo NAO EXISTE superficie de interacao possivel para a tinta de marca atual. Os 90 casos eram 100 depois de consertada a regua (41o defeito: a HV1-c lia a tinta DO CONTROLE, nao a de quem PINTA a letra — 1 artefato correto condenado e 12 defeitos reais invisiveis), e nao estavam em 7 classes: estavam em 5 arquivos, 64 num so. Consertar o pior obrigou a abrir o seed-design-system.html, onde o 42o defeito (a varredura de contraste escolhia alvo por PREFIXO DE NOME e deixava 17 dos 51 HTMLs de fora) escondia 862 folhas de texto reprovadas em repouso: 862 -> 46. Nasce ainda o 43o defeito (a ferramenta de recorte nao desligava rolagem suave — era o 33o, num terceiro instrumento). Pendencias novas: HV-P6, SE-P1, CC-P9, CC-P10, ES-P1, TK-P1. Anterior: v1.17 — **§72 REVISTA (2026-08-20, oitava parte): nasce a clausula SH1-d — O CONTEUDO NAO VAZA DA PROPRIA CAIXA, de o Rafael apontar num anexo a 390px o rotulo saindo POR FORA DA BORDA de dois botoes do tela-gantt que as tres clausulas anteriores davam como limpos. Causa medida: display:flex da flex-shrink:1 por padrao e o min-width:44px do piso de ALVO da SC 2.5.8 SUBSTITUIU a protecao min-width:auto do flexbox — duas regras boas que juntas produzem uma ruim; conserto flex-wrap:wrap + flex:0 0 auto, com quatro alternativas descartadas registradas no proprio molde. Dois defeitos de instrumento morreram no caminho: o 39o (clientWidth de inline nao-substituido vale ZERO — 168 falsos vazamentos, 124 deles em code) e o 40o (opacity:0 NAO tira o elemento do hit-test — 2 falsos FAIL que so apareciam a 390x844). Placares: acervo 204 PASS · 0 FAIL a 1440px e 198 PASS · 6 FAIL a 390px, este confirmado em DUAS alturas de janela; pasta de prova a 42 PASS · 22 FAIL em 16 fixtures. A SH-P8 foi reescrita: dizia "18 FAIL em 4 arquivos" e o numero medido e 6 FAIL em 2 arquivos. Anterior: v1.16 — §71 e §72 (2026-08-19, sétima parte): nasce HV1 — RESPOSTA AO PONTEIRO e PRESSIONADO DISTINTO — de o Rafael RECUSAR uma pergunta que eu não devia ter feito; medido, 619 de 1.410 controles ativos não davam NENHUMA resposta ao mouse, 1.350 tinham o pressionado igual ao sobrevoo e 90 violam a norma de contraste HOJE, com 0 PASS em 51 arquivos. E nasce SH1 — COLISÃO, COBERTURA E CORTE —, que FECHA a SH-P3: 204 PASS · 0 FAIL a 1440px, com o espaçamento da SC 1.4.12 medido pela primeira vez e CINCO defeitos de instrumento mortos no caminho. Gêmeos de token a v1.18. Anterior: v1.15 — ** §70 reescrito (2026-08-19, sexta parte): as duas confissões do CT1 FECHAM — CT-P1 (media só o tema claro) e CT-P2 (media só o repouso). Nascem CT1-d e CT1-e: 2 temas × 4 estados × 2 larguras, 1.480 medições, 0 fora do centro, NENHUM artefato alterado. Tema escuro só é medido em quem PROMETE tema escuro, e a promessa é medida por assinatura de cor, não por grep. §70.5 supersede · §70.6 prova de inércia (a dimensão antiga reproduz 23·0·28) · §70.7 pendências CT-P3 a CT-P7. Anterior: v1.14 — ** §65.9, §65.10, §65.11 e §70 (2026-08-19, gate v13.3 respondido pelo Rafael): a SI-P5 FECHA e a resposta não foi nenhuma das três alternativas — aquele quadrado é a EMPRESA LOGADA e o ERP é MULTI-EMPRESA (SI17-e: cor por empresa, glifo constante; SEED energia na posição 3, escolhida por distância de luminância 3,80); a PS-P6 FECHA com os contratos SI19 (pessoa é círculo, empresa é quadrado) e SI20 (foto e logo SUBSTITUEM o fundo, nunca se deitam sobre a cor de entidade), e a matriz dos QUATRO estados nasce em banco-identidade.html; a PN-P6 FECHA — a linha da planilha sobe de 40 para 44px, alvo medido 234×44; a CC-P8 FECHA — o ponto da legenda deixa de ser o CARACTERE ● e vira forma, trocando o critério de SC 1.4.3 para SC 1.4.11 sem mexer em uma cor sequer; e nasce o §70 com o contrato CT1 e a guarda guarda-centro-alvo.mjs (189 controles, 0 fora do centro) a partir de um defeito que o RAFAEL viu a olho nu e que NENHUMA das 60+ guardas via. §65.8 e §62.8 (2026-08-19): nasce o contrato SI18 (2026-08-19): nasce o contrato SI18 para o ponto de cor .ent — spec PRÓPRIA, porque ele NÃO é o §65.7 mal-feito — e a PS-P5 é REVOGADA pela medição: o .mini-avatar carrega um CLIENTE, não uma pessoa. §67.7 (2026-08-19): a IL-P2 EXECUTA — a grade do §48 passa a cumprir o padrão grid da ARIA e o §67; nasce o contrato IL15 e a guarda que TECLA para medir; o defeito principal era TECLADO e não estava escrito na pendência. §65.7 (2026-08-19): a SI-P4 EXECUTA — o .sigla ganha bloco ÚNICO nas OITO telas que o carregam (o censo dizia quatro), nascem os contratos SI17-a/b/c/d e a guarda-si17.mjs que os mede por COMPORTAMENTO; nasce a SI-P5, de produto. Fase 3 FECHADA 7/7 ✅ · FASE 6 — 6A, 6B e 6C FECHADOS: §48 Painel estável desde 2026-08-13, PN1–PN54. INVERSÃO DO HERO na mesma data: o azul sai, a âncora passa a TURQUESA VIVO turquesa-400, a ação volta à família da marca e o conflito com o §3.5 de marca-seed.md DESAPARECE — S4 retirado, S3 revisto, S11 novo. Preview v0.8, cinco camadas verdes (139 · 37 · 142 · 6 · 78). Segue proposta apenas a tinta da família (S6) — pendência PN-P1, agora menor)

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).

---