Derivada dos changelogs de cada canônico — nunca escrita à mão. Em ordem de data; o resumo é a primeira frase em negrito da própria entrada, e o texto inteiro está dobrado logo abaixo. Assine o feed Atom.
Entradas por canônico: Marca SEED 43 · Roadmap 25 · Componentes 23 · Dataviz 22 · Tokens 16 · E-mail 12 · Sobre a SEED 4 · Boas práticas 1 · Inventário de peças 1 · Plano de produção 1 · Composição 1 · Mapa de cobertura 1. Quatro formatos de origem: tabela Versão/Data (6 arquivos), "Registro do documento" (2), a linha de título do seed-componentes (23 versões) e o cabeçalho (2).
§13 deixa de apontar para as skills seed-ds-* (substituídas pela skill única seed-ds, F9.5, MANIFESTO §168) e passa a apontar para o §12, os templates de 07-pecas/ e o canônico novo seed-praticas.md (boas práticas de mercado, com regra de precedência). Nenhuma regra visual muda.
A REGRA DA EMENDA do grafismo (§7.6) — veredito dele sobre a vitrine (F9.3, MANIFESTO §165):
texto inteiro da versão
A REGRA DA EMENDA do grafismo (§7.6) — veredito dele sobre a vitrine (F9.3, MANIFESTO §165): os SVGs de referência de 03-assets/grafismos/ nunca se repetem (CSS repeat, cópias lado a lado, recorte); para outra largura se gera pelo gen-detalhe.py, que é o único dono da emenda (§7.3). Nasce a guarda transversal guarda-grafismo.py. Nenhum desenho muda.
F9.5 CONSTRUÍDA (MANIFESTO §168 vereditos, §169 construção). Vereditos dele de abertura, verbatim no §168: pedido de cobertura na skill (V-D), boas práticas numa casa viva do DS (V-Q1 → nasce o seed-praticas.md v0.1, 12º canônico), fichas de soluções para gate do sobreaseed.md (V-Q2 → SK-P1), as sete podem ser apagadas depois do substituto (V-Q3). Construído: gen-skill.py → 10-publicacao/skill/seed-ds/ + zip determinístico; guarda-skill.py SK-1…SK-10 (produção 10 PASS; VT 12, CI 9, RG 7); preservação em 09-pesquisa/skills-v1-2026-05/ (47 arquivos); marca v5.37 (§13); nginx lista a pasta da skill. Quatro testes de uso em sessão nova cumpriram os três critérios e abriram a fila LC (LC-01…LC-09). Aguarda V-F1/V-F2 dele.
F9.5 ABERTA pelo Reconhecimento, antes da F9.4 (ordem dele: "abra a F9.5 antes da F9.4, pelo Reconhecimento"; MANIFESTO §167).
texto inteiro da versão
F9.5 ABERTA pelo Reconhecimento, antes da F9.4 (ordem dele: "abra a F9.5 antes da F9.4, pelo Reconhecimento"; MANIFESTO §167). Medido: as sete skills de maio carregam 5 assets aposentados (Indie Flower, ondas v1), 3 referências já divergentes entre as cópias, 0 tokens --seed-* e 8 hex fora do canon; 14 arquivos de prática de mercado (41 mil tokens) e 7 fichas de soluções (306 linhas, 0 no sobreaseed.md) não têm fonte no canon — vão ao gate. Desenho: uma skill seed-ds gerada (referências byte a byte, um pacote de assets, guarda SK, instalação pessoal, zip determinístico para o claude.ai). Correção de passagem: o título da F3 ganha o ✅ (a vitrine mostrava "prevista").
F9.3 FECHADA — veredito dele no gate visual do site publicado (MANIFESTO §166, verbatim): "A — aprovada; a F9.3 fecha", sem ajustes e sem vetos.
texto inteiro da versão
F9.3 FECHADA — veredito dele no gate visual do site publicado (MANIFESTO §166, verbatim): "A — aprovada; a F9.3 fecha", sem ajustes e sem vetos. A rodada anterior do mesmo gate (§165) tinha achado a emenda errada do grafismo na vitrine — corrigida em três camadas (vitrine gera pelo gen-detalhe.py; marca v5.36 §7.6 "regra da emenda"; guarda-grafismo.py transversal) — mais abas com raio 6 (§34.2), /tokens/paleta/ e a explicação para leigo no início; VT-P4 (publicação incremental, 31 s contra 16 min) fechada. Próxima: F9.4, com remedição do que o site já fez.
F9.3 CONSTRUÍDA e publicada — a vitrine está em https://ds.seed.eng.br (MANIFESTO §162–§163).
texto inteiro da versão
F9.3 CONSTRUÍDA e publicada — a vitrine está em https://ds.seed.eng.br (MANIFESTO §162–§163). Vereditos dele: V-D = A com a exigência "fiel e criativo" (verbatim no §162) → toda página termina com "Esta página usa" (a lista, por §, do que da casca aplica o DS; a guarda VT-8 prova que todo § existe); V-Q1 = A → 07-pecas/ inteiro publicado (menos gate-*), com X-Robots-Tag: noindex e fora do sitemap. gen-vitrine.py → 550 arquivos (324 páginas, miniaturas, busca, Atom, sitemap de 601 URLs), regeneração byte-idêntica; guarda-vitrine.py VT-1…VT-11 (10 PASS local; VT-11 em produção no fechamento). Lista de publicação vai a 1.244 arquivos (03-assets, bancadas, telas, peças). O gate visual dele sobre o site publicado é o que fecha o brick.
Nasce o canônico (F9.5, MANIFESTO §168 — V-Q1 dele: "crie essa parte para a skill utilizar sobre essas boas práticas").
texto inteiro da versão
Nasce o canônico (F9.5, MANIFESTO §168 — V-Q1 dele: "crie essa parte para a skill utilizar sobre essas boas práticas"). Importação ÚNICA, sem edição, das 14 referências de prática de mercado das skills seed-ds-* de 2026-05-13 (163504 bytes ao todo), uma seção por arquivo, com procedência (MD5) e as contradições com o DS v2 medidas por 09-pesquisa/skills-v1-2026-05/importa-praticas.py: 4 das 14 seções têm ao menos uma. Regra de precedência no cabeçalho. A partir daqui, manutenção manual.
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…
texto inteiro da versão
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.mjs33 · 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.
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…
texto inteiro da versão
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).**
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",…
texto inteiro da versão
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.
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.
texto inteiro da versão
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.**
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.
texto inteiro da versão
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.**
O veto dele sobre os glifos ("muito grosseiros"; "subestação pode ser uma torre de alta tensão") virou medição e três decisões (MANIFESTO §149–§151):
texto inteiro da versão
O veto dele sobre os glifos ("muito grosseiros"; "subestação pode ser uma torre de alta tensão") virou medição e três decisões (MANIFESTO §149–§151): traço óptico 1,25 nos destaques (o traço 2 do set ampliado 15× dava 4,2 % do diâmetro contra 1,3–2,0 % no segmento — medido em 9 perfis) · transmission-tower NOVO no set, desenhado a partir do modelo em imagem que ele mandou, na densidade máxima que lê a 24 px reais · generator REDESENHADO a partir da foto dele · set a 31 glifos e o seletor §65 com a régua da última linha incompleta (decisão dele). §12.31 atualizada. IC-P2 corrigida no inventário e na bancada.
O fechamento das pendências (MANIFESTO §147–§148):
texto inteiro da versão
O fechamento das pendências (MANIFESTO §147–§148): ele aprovou a remoção dos 48 estudos das capas (saíram), não vetou nada, autorizou o upload do kit de favicon para o espelho público — FV-P2 fecha de vez (subpasta Logos/Símbolo/favicon/, 10 FILE_IDs na §5.4 lidos pela API, prova de download por MD5) — e mandou criar os glifos: FV-P5 fechada com hard-hat e solar-panel-plus no set §45 (v1.39, 30 glifos); §12.31 atualizada (os oito destaques com ícone). A fila do item 9 do §17 zera. Achado registrado para a fila do seed-componentes.md: IC-P2 (o inventário §45.3 diz que o Lucide não tem solar-panel; tem).
AS PENDÊNCIAS ANTES DA F9 — ele mandou resolver a fila antes de abrir a fase (MANIFESTO §144–§146).
texto inteiro da versão
AS PENDÊNCIAS ANTES DA F9 — ele mandou resolver a fila antes de abrir a fase (MANIFESTO §144–§146).PI-P1 fechada por veredito (a placa da distribuidora é fabricada pela norma dela) · SN-P10 fechada por CONFIRMAÇÃO do veredito de 25/08, agora com os renders que faltavam (opções A/C/B na mesma escala) · FV-P2 executada (kit rasterizado pelo próprio gerador, 17/17 determinístico; §12.26, tabela nova no espelho §5.4 aguardando o upload dele) · §12.30 capas de rede social nasce (FV-P1 + FV-P3: LinkedIn A · Facebook C · YouTube A+ · X A não publicada · WhatsApp A; formatos com fonte, avatar medido em captura, pesquisa de mercado) · §12.31 destaques do Instagram nasce (FV-P4: 8 destaques com o set de ícones §45, composição C escuro por delegação, medida no tamanho real) · nasce FV-P5 (glifos para Obras e SEED Plus). Instrumento: render-peca.mjs e guarda-peca-fresca.mjs aceitam alvo-tela para peça de tela com tamanho fixo em px. Resíduo para o gate seguinte: tabela de remoção dos 48 estudos das capas.
Linha de versão no cabeçalho (decisão dele, F91-P3) e reconciliação desta tabela:
texto inteiro da versão
Linha de versão no cabeçalho (decisão dele, F91-P3) e reconciliação desta tabela: o cabeçalho dizia "Atualizado em 2026-07-17", mas o arquivo foi editado em 2026-08-24 (correção dele: a MATRIZ é Governador Valadares, Baixo Guandu é a cidade de fundação — nota no §1) e em 2026-08-25 (planos do SEED Plus com origem registrada, MR-P14 e MR-P15 resolvidas, regra da validade da proposta por tipo de serviço) sem que esta tabela registrasse. Nenhum dado institucional muda nesta linha.
F9.2 FECHADA — o registry shadcn próprio está em https://ds.seed.eng.br/r/
texto inteiro da versão
F9.2 FECHADA — o registry shadcn próprio está em https://ds.seed.eng.br/r/ (MANIFESTO §159–§160): @seed/tokens (o gêmeo CSS, uma linha alterada para o seletor .dark), @seed/theme (32 apelidos de cor + radius → var(--seed-*), GI1; raio exato) e @seed/fontes (Montserrat e JetBrains Mono self-hosted, GI5); guarda RG 7 PASS em produção; quem aplica no ERP é a sessão do ERP, por PR (decisão dele). Próximo: F9.3 vitrine.
F9.1 sem pendência (gate de fechamento aplicado, §157: seed-email v0.13, sobreaseed versionado, IndexNow + Search Console + Bing) e F9.2 ABERTA pelo Reconhecimento (§158).
texto inteiro da versão
F9.1 sem pendência (gate de fechamento aplicado, §157: seed-email v0.13, sobreaseed versionado, IndexNow + Search Console + Bing) e F9.2 ABERTA pelo Reconhecimento (§158). Medido no ERP: Tailwind 4.2.1, shadcn new-york com 46 componentes, 34 apelidos em slate/OKLCH, escuro por .dark sem código que o ligue. Desenho do registry: @seed/tokens (gêmeo instalado byte a byte), @seed/theme (apelidos → var(--seed-*), raio exato com radius-xl), @seed/fontes; gate G7 na paridade. Perguntas: seletor do escuro, accent, sidebar, quem aplica no ERP, escopo.
F9.1 FECHADA — a camada de IA está no ar em https://ds.seed.eng.br
texto inteiro da versão
F9.1 FECHADA — a camada de IA está no ar em https://ds.seed.eng.br (MANIFESTO §155–§156): 11 canônicos inteiros + 259 fatias por § com procedência + tokens.md + índices + robots (todos os robôs de IA liberados) + sitemap; provado por HTTPS: 283/283 arquivos com MD5 igual ao disco, 274/274 .md como text/markdown. Receita em deploy/; sequência de fechamento de brick ganha o gen-camada-ia.py e a guarda (CLAUDE.md). Próximo: F9.2 registry shadcn.
F9: desenho DECIDIDO por ele no gate de abertura (MANIFESTO §154) — sete respostas, seis bricks.
texto inteiro da versão
F9: desenho DECIDIDO por ele no gate de abertura (MANIFESTO §154) — sete respostas, seis bricks. Superfície = VM ao lado do site, ds.seed.eng.br, robôs de IA todos liberados, casca da vitrine por gerador da casa (contra a recomendação Starlight; custo aceito), ordem IA → registry → vitrine → GEO → skills → mapa, GEO entregue como pacote ao projeto do site, skills substituídas por um pacote único (leitura a confirmar). Supersede formal dos itens "Lovable" desta fase. F9.1 aberta.
F9 ABERTA pelo Reconhecimento (MANIFESTO §153). Medido antes de desenhar: o llms.txt existe mas o repositório é privado (nenhum agente de fora alcança); o seed-componentes.md tem ≈ 313 mil tokens (não cabe em agente — a camada de IA precisa fatiar por §); o site institucional não é mais Lovable (Next.js na VM, projeto próprio) e não tem JSON-LD nem robots para IA; o ERP tem 0 tokens --seed-* (tema shadcn padrão); as 7 skills seed-ds-* são de 2026-05-13 (18 tokens contra 293). Desenho proposto em seis bricks (F9.1 camada de IA · F9.2 registry shadcn · F9.3 vitrine · F9.4 pacote GEO do site · F9.5 skills · F9.6 mapa de propagação) e sete perguntas com custo no gate. Os itens "Lovable" deste § ficam como estavam até o veredito dele — supersede candidato registrado no §153.2.
Entre a F8 e a F9: a fila de pendências resolvida por ordem dele antes de abrir a fase
texto inteiro da versão
Entre a F8 e a F9: a fila de pendências resolvida por ordem dele antes de abrir a fase (marca-seed.md v5.33, MANIFESTO §144–§146): PI-P1 e SN-P10 fechadas por veredito, FV-P2 executada, FV-P1/FV-P3 (capas de rede, §12.30) e FV-P4 (destaques do Instagram, §12.31) produzidas e decididas; nasce FV-P5 (glifos). F9 continua PRÓXIMA — e agora com a camada de rede social pronta para publicar.
F9.3 ABERTA pelo Reconhecimento (MANIFESTO §161). Medido antes de desenhar: nenhuma biblioteca de Markdown instalada → markdown-it-py 3.0.0 (CommonMark + tabela + tachado) provada nas 259 fatias (532 de 532 tabelas, 4 s); 40 bancadas/telas autossuficientes (fontes por caminho relativo já publicado; 7 ainda chamam o Google Fonts → VT-P1); 68 de 69 seções de componente citadas por alguma bancada; 07-pecas com 187 MB (168 templates HTML = 150,8 MB; 165 PNG = 44,7 MB), VM com 87 GB livres e subida de ≈ 8 MB/s; changelogs em quatro formatos; 21 critérios WCAG citados no canon. Desenho: gen-vitrine.py → 10-publicacao/vitrine/ servido na raiz por try_files, páginas de canon a partir das fatias (o .md da F9.1 não muda de endereço), camada de máquina MK2–MK5/MK10, guarda VT-1…VT-10; custo 5,5–7 sessões. Gate de abertura com duas perguntas: V-D (o desenho, rascunho renderizado com os tokens reais a 1280 e 390 px) e V-Q1 (publicar as peças originais, 185 MB, ou só miniaturas). Pendências VT-P1–VT-P3 registradas.
Só endereço de seção, nenhuma decisão muda (F91-P2, MANIFESTO §157):
texto inteiro da versão
Só endereço de seção, nenhuma decisão muda (F91-P2, MANIFESTO §157): o bloco da errata v0.12 repetia o título "## 4. EM1 — camada de tokens resolvidos" — o arquivo tinha dois §4, e um agente que citasse "§4 do seed-email" não sabia qual. O bloco da errata passa a §4-a; o §4 original fica único. Achado pela camada de IA (F9.1), que fatia os canônicos por seção. (O registro pulou a 0.12 aqui porque a errata de 2026-08-14 já usava esse número no próprio título.)
A ONDA 3 FECHA E ENTRA NO CANÔNICO — nove specs novas (§12.22–§12.29 + §12.2-b), e com ela a F8 inteira.
texto inteiro da versão
A ONDA 3 FECHA E ENTRA NO CANÔNICO — nove specs novas (§12.22–§12.29 + §12.2-b), e com ela a F8 inteira. Última decisão aberta respondida em 2026-09-04 (MANIFESTO §142: R6-U1 "Linha 2 — cor da marca" · R6-U3 "20 mm" · R6-REM "aprovo a remoção (…) deve ficar salvo e registrado o desenho aprovado de todos os lados do carro" · R6-VETO "todos ficam"). ⭐⭐⭐ §12.22 FROTA — a peça que ele apontou como faltante nasceu do zero, foi REPROVADA por erro de categoria ("pensar na adesivagem dos carros como peças de papelaria é errado") e voltou como arte final DITADA por ele: 4 veículos × 3 vistas, cordilheira em escala de lataria (F 353–419 mm, traço ≥ 9 mm), traseira pelo modelo da FOTO REAL da Strada e sem ondas, EEny pose 07, 5 áreas de foto a 150 DPI, contato a 45/45 mm; nasce a tipografia do contato (§138.1) — o bicromatismo da logomarca espelhado em 0800/site, com ícones e a segunda fonte na lista; a regra do formato veículo (9 itens) decidida e promovida. §12.23 UNIFORME/EPI — a E1 refina a MR-P11 ("podemos usar o amarelo, mas atendendo essas condições do padrao da propria logo"); 4 cores de escritório; a regra geral do bolso (com bolso → vertical no bolso; sem → horizontal); campo cinza com logo branca direto; boné = símbolo, chapéu/capacete = vertical; gola interna turquesa nas 4 decidida com estudo de mercado; colete refeito com prova de interseção no DOM (0 de 10) depois de o gate ver o número sobre a faixa — guarda que mede com a constante do gerador confirma o gerador. §12.24 ONE-PAGERS — dor→solução, coluna de foto, radar com fonte, 2 números ("+10 anos de mercado"), estatística redundante não se cria. §12.25 ROLL-UP + TOTEM — institucional clean + comercial A/B ("a da BV financeira…"), ondas canto a canto SÓ nas comerciais ("mas nao é regra"), zona de sacrifício 250 mm, toque de 0,00 mm no amarelo consertado. §12.26 FAVICON/AVATARES — as 5 decisões (® sempre · margem 0% · escuro colorido · 2 fundos oficiais · maskable 40% W3C); raster e capas de rede fora, por decisão. §12.27 PLACA DE INSTALAÇÃO CONCLUÍDA — voluntária pelo texto da lei, 2 tamanhos sub-múltiplos da chapa, sem amarelo ("nesse caso da placa sim"), QR real wa.me em 4-Q com segno 1.6.6 (leitura por celular é etapa do gate). §12.28 PORTFÓLIO — template com fotos em branco, sem RT ("a empresa é o foco"), rol de fotos. §12.29 AGENDA — o brinde mudou de veredito ("não precisa ter" → "gere um layout para agenda"): 3 capas, 2 contracapas, sem ano, Cidade/UF. §12.2-b MARCA D'ÁGUA — E1 explodida aplicada nas 12 peças, P3 cantos opostos oficial, símbolo medido pelo CORPO (a caixa do viewBox fazia 58 mm virarem 40), ® fora por recorte, tinta 700 nos números (o furo dos 4,60:1 contra o branco puro). §17: fecham os itens 4 (redesenho executivo — F8) e 7 (kit de favicon; capas de rede ficam como FV-P1); o item 2 ganha matéria (quatro listas de fotos); nascem PI-P1, FV-P1/P2 (as demais divergências da auditoria de fechamento — gola no gerador, capôs de Saveiro/Strada, rename da folha da regra, PNG das institucionais, docstrings defasadas — foram resolvidas ANTES desta promoção, não nomeadas). Roadmap v2.3: F8 FECHADA, três ondas; próximo = F9. Nenhum hex muda, nenhum vetor muda.
F8 FECHADA — a Onda 3 fecha 7 de 7 em seis rodadas de gate (MANIFESTO §136–§142), e o §12 do marca-seed.md vai a 30 specs (v5.32: §12.22–§12.29 + §12.2-b).
texto inteiro da versão
F8 FECHADA — a Onda 3 fecha 7 de 7 em seis rodadas de gate (MANIFESTO §136–§142), e o §12 do marca-seed.md vai a 30 specs (v5.32: §12.22–§12.29 + §12.2-b). O que a onda deixou de regra além das peças: tipografia do contato (§138.1), regra do formato veículo, regra geral do bolso, moldura ampla (v5.30), marca d'água de contorno (E1 aplicada, P3 oficial). Corrigido: "8 itens ≈ 16 peças" → 7 itens (3.4 saiu em 27/08). Próximo: F9 — publicação e camada de IA/GEO. Regra que fica reafirmada: este arquivo se atualiza NO FECHAMENTO da onda — esta edição é o próprio fechamento.
O diário de obra perde o furo (R5-M3, §140) — "nao se usa mais furo": corpo a 7 mm como o rodapé, colunas proporcionais em 196 mm; §12.15 anotado. Na mesma rodada, sem mudança de canon: a repetitiva oficial da marca d'água é a P3 (cantos opostos), a E1 segue aplicada; o colete foi refeito com prova de interseção contra as faixas refletivas (a folga declarada antes media uma constante errada do gerador — §141.1); a gola interna ganhou estudo de mercado antes da decisão (§141.2).
A MOLDURA AMPLA promovida ao §12.2 (R4-M2, MANIFESTO §139)
texto inteiro da versão
A MOLDURA AMPLA promovida ao §12.2 (R4-M2, MANIFESTO §139) — margem 7 mm (o limite é a zona de exclusão X da logo, 6,72 mm medidos no asset), cabeçalho 29, rodapés 33/22/8, área útil 196×227/241/256 a partir de (7,29); +24,6% de área no orçamento. Propagada à família inteira (~45 peças regeneradas, colisão medida no DOM em todas: laudo e checklist tinham tabelas presas em 170 mm e foram realargadas com conta declarada). Nasce junto: a marca d'água de contorno do símbolo EXPLODIDO (360 mm, sangrando as 4 bordas, ® fora por conta) na família orçamento/proposta/portfólio, e a tinta dos números de seção sobe de turquesa-600 para 700 — o furo achado na re-medição: 600 mede 4,60:1 sobre o branco PURO, e qualquer véu o derruba (régua nova: contraste se confere contra o pior fundo que a peça admite).
A ONDA 3 ABRE, por ordem dele ("Vamos abrir a 3 onda, tudo em paralelo") — e três vereditos moldam o escopo ANTES da produção.
texto inteiro da versão
A ONDA 3 ABRE, por ordem dele ("Vamos abrir a 3 onda, tudo em paralelo") — e três vereditos moldam o escopo ANTES da produção. ⭐ (a) o conteúdo dos one-pagers é produzido por mim ("vc deve produzilos, nao eu"), com fonte única no sobreaseed.md — nada fora dele entra na peça (§14.1); ⭐⭐ (b) o item 3.4 (material próprio do Diagnóstico 360°) SAI da onda e do DS — veredito dele: é serviço que a SEED vende, não marca com identidade própria ("diagnostico 360 nao consigo ver ele tendo material de DS (...) é um serviço que vendemos"); ele vive como conteúdo dentro do one-pager de Consultorias; ⭐ (c) o portfólio nasce como TEMPLATE com área de foto em branco ("deixe em branco o local da foto") + lista das fotos necessárias entregue no fechamento — foto real é insumo de produção, não de DS. Escopo final da onda: 7 itens ≈ 15 peças (3.1 frota · 3.2 uniforme/EPI · 3.3 one-pagers ×5 · 3.5 banner/roll-up + totem · 3.6 kit favicon + avatares · 3.7 placa de instalação concluída · 3.8 portfólio + brinde). Registro operacional no plano-producao-pecas.md §6.
OS MARCADORES DE ESTADO MENTIAM, E UMA PENDÊNCIA ESTAVA ÓRFÃ HÁ TRÊS DIAS — achado ao responder "quanto falta pra finalizarmos o DS?".
texto inteiro da versão
OS MARCADORES DE ESTADO MENTIAM, E UMA PENDÊNCIA ESTAVA ÓRFÃ HÁ TRÊS DIAS — achado ao responder "quanto falta pra finalizarmos o DS?". ⭐⭐⭐ A pergunta dele é respondida LENDO ESTA LISTA e o seed-ds-roadmap.md, e os dois estavam defasados:(a)CT-P8, PF-P2, FT-P1 e GT-P1 foram fechadas na v5.27 e o fechamento foi escrito só no changelog — as quatro entradas continuaram marcadas ⏳, ou seja, quem lesse a fila veria como aberto o que fechou ontem (mesma classe da defasagem que o roadmap pagou em 2026-08-22, quando uma sessão quase reabriu trabalho concluído 11 dias antes); marcador corrigido para ✅ sem reescrever o texto do achado, que é registro datado (regra CP31). (b) ⭐ A SN-P10 nunca existiu como entrada: nasceu em 2026-08-24 dentro do PARÁGRAFO do §17.6 (perda de reconhecimento a distância da placa A3 NR-10 ao sair a tarja turquesa: logo 60 mm → legível a 1,75 m numa peça de 4,0 m) e três rodadas de "resolver tudo em aberto" passaram por cima dela, porque "em aberto" se lê NA LISTA. Agora tem entrada própria, classificada como decisão dele com custo em mm — sai com as duas opções renderizadas (§14.13). RÉGUA: pendência citada em prosa não existe; só existe o que tem entrada na fila, e ela entra no mesmo movimento em que é nomeada.
A FILA ZERADA — dez pendências fechadas numa rodada, a mando dele ("resolva as pendencias em aberto, assim que acabar eu autorizo a onda 3").
texto inteiro da versão
A FILA ZERADA — dez pendências fechadas numa rodada, a mando dele ("resolva as pendencias em aberto, assim que acabar eu autorizo a onda 3"). ✅ CT-P8 — CT1 no acervo: 168 PASS · 0 FAIL (era 32 FAIL). Dois consertos: a peneira aprendeu que texto alfanumérico é rótulo (botões "1"/"2" da paginação saíam como ícone e tinta de dígito nunca centra na caixa — é tipografia, não desalinhamento), e os três glifos tipográficos usados como ícone (⋯ ‹ ›) viraram SVG de viewBox simétrico — ⭐ glifo de texto como ícone mede a tinta fora do centro porque a em-box posiciona pela linha de base. ✅ PF-P2 — nasce a guarda-preview-contraste.mjs (contrato PF2): piso 4,5 texto normal / 3,0 grande — mais duro que o 3,0 das bancadas, porque folha de decisão é texto de leitura. Cobaia dupla provada, e na estreia achou 7 defeitos reais na folha (os .ok verdes a 4,23 sobre fundos tingidos); consertados com os pares DO SISTEMA (feedback-success-text, text-muted): 122 medidos · 0 FAIL. ✅ IC-P1 — encerrada como FALSO REGISTRO: o par real mede 5,62 nos dois temas, a gi2 dá 22·0 em duas rodadas, o arquivo não muda desde a fundação — e a rodada que a registrou usava a gi2 pré-conserto do contrato de alvo, com a sonda de placar do §130.10. ⭐ Pendência nascida de rodada com instrumento depois consertado se re-mede antes de se trabalhar. ✅ GN-P1 — cinco instrumentos ancorados (o remendo sai do .gitignore junto com o defeito), e os 4 captura-*.mjs tinham defeito MAIOR escondido: apontavam para o Chrome do container do Cowork — instrumentos mortos com aparência de vivos. Leitura na fixture viva de 07-pecas/, escrita na área ignorada — ⭐ evidência não se regenera, se preserva. ✅ SN-P14 — a MM1-e ganhou alcance declarado (%/calc/transform saem nomeados — 7 blocos no acervo que eram silêncio) e o regex de px aprendeu decimal (o antigo lia "5px" de "10.5px": número errado com cara de medido). ⚠ E o conserto quebrou a guarda no caminho — âncora de edição sem a indentação completa des-indentou um try e a MM1 passou a medir NADA (0·0·0, exit 0); a §14.9 pegou. ⭐⭐ Âncora de edição em python COMEÇA no início da linha, com a indentação inteira. Placar final: 185·0, idêntico, mais a cobaia reprovando como deve. ✅ FT-P1 — nascem os subsets woff2 da SEED (subset-seed/, fontTools instalado): 25–34 KB/peso, cobertura provada por cmap (JetBrains 50/50 técnico + 86/86 vivos; Montserrat sem ✓✗ porque o original não os tem). A GL1 aprendeu woff2 via fontTools OPCIONAL (sem a lib, volta ao [n/a] honesto) — e de brinde passou a MEDIR as 18 históricas. As 4 peças migraram: ~3,1 MB → ~290 KB (10×), GL1/MM1/render/fonte-efetiva todos verdes. ✅ RL-P1 — a §5–§6 da ISO 3864-2 lida por inteiro (texto extraído do PDF dele): só a etiqueta de impedimento está no escopo, e CONFERE (combination label §6.5: texto abaixo do sinal, painel retangular, severidade opcional ausente). As outras três eram classificação errada da rodada anterior — ⭐ "é etiqueta" não faz de uma peça um safety label: a norma agrupa por FUNÇÃO (comunicar perigo), não por formato. ✅ RD-P1 — medida com o interruptor CHROMIUM_DETERMINISTA=1: quatro placares idênticos → não estender (placar de tela é invariante; instrumento de tela consome placar, não PNG). ✅ RD-P2 — não reproduz: 12 capturas em 12 processos separados, 12 MD5 idênticos. O fenômeno sumiu antes do isolamento, e encerrar assim é mais honesto que atribuir causa sem reprodução. ✅ AD-P5 — a convenção de MOCK DE TELA em 07-pecas/ vira texto (§12.15): superficie=tela + alvo-tela + estatuto + papel-irmao — a solução já existia de fato no exemplar. ⏳ PT-P2 e AD-P7 RECLASSIFICADAS: produção nova e decisão de escopo — fila da onda de aplicações, não de conserto. Chamar produção nova de pendência faria a lista nunca zerar, e lista que nunca zera deixa de informar.
O MAPA MESTRE VOLTOU A FICAR PARA TRÁS — 5 dias desta vez, achado ao ele perguntar "quanto falta pra finalizarmos o DS?".
texto inteiro da versão
O MAPA MESTRE VOLTOU A FICAR PARA TRÁS — 5 dias desta vez, achado ao ele perguntar "quanto falta pra finalizarmos o DS?". ⭐⭐ Essa pergunta se responde LENDO ESTE ARQUIVO, e ele ainda dizia "Próximo: Onda 2" com a Onda 2 aprovada em 2026-08-26 ("1. todos aprovados", dez peças, marca-seed.md §12.11–§12.21). É a segunda ocorrência da mesma defasagem — a v2.1 nasceu justamente de o arquivo estar 12 dias atrás. A diferença: em 2026-08-22 a defasagem foi descoberta quando quase custou trabalho refeito; agora foi descoberta ao tentar RESPONDER com ela. Esta edição registra: F8 com a Onda 2 fechada 9/9 (10 peças, duas fora do plano, nascidas de defeito achado na própria onda) + §12.9/§12.10 fora das ondas = 21 specs de peça aprovadas; e a Onda 3 destravada, 8 itens ≈ 16 peças, aguardando só a palavra dele. RÉGUA QUE FICA: o estado do projeto se responde do arquivo, e por isso o arquivo se atualiza no fechamento de cada onda — não quando alguém pergunta.
PV-P1 RESOLVIDA — a paridade das bancadas ZERA pela primeira vez (513 PASS · 0 FAIL) — e a fonte canônica consertou metade da CT-P8 de brinde.
texto inteiro da versão
PV-P1 RESOLVIDA — a paridade das bancadas ZERA pela primeira vez (513 PASS · 0 FAIL) — e a fonte canônica consertou metade da CT-P8 de brinde.(a) o .selo do base-bancada.css consome os dois feedback-info e o gen-banco-dominio era o único dos 9 gerados sem eles na lista NOMES — ⭐ quem consome CSS compartilhado herda a lista de tokens do compartilhado. (b) o banco-identidade consumia --seed-surface-default, que não existe; a intenção estava escrita no próprio template ("superfície neutra com fio de 1px") e o consumo passou ao --seed-surface-raised, que já estava na lista — nada criado (§14.1). ⭐⭐ E um efeito colateral medido que ninguém previu: a CT1 caiu de 32 para 16 FAIL.banco-data e tela-shell passaram a centrar os ícones depois de receber a fonte canônica — metade da CT-P8 era a métrica da fonte errada, não geometria. Restam banco-navegacao e tela-tabela (8 FAIL cada), que continuam na fila.
A FONTE CANÔNICA PASSA A SER FORÇADA NO ACERVO INTEIRO — PP-P1-b resolvida, e o achado era maior que o enunciado.
texto inteiro da versão
A FONTE CANÔNICA PASSA A SER FORÇADA NO ACERVO INTEIRO — PP-P1-b resolvida, e o achado era maior que o enunciado. Veredito dele: "podemos deixar o plano B, mas temos que forçar sempre a fonte canônica, nem que seja dando opção de instalá-la ou avisando que precisa instalar e dando o link". ⭐⭐ O achado que mudou o escopo: ZERO dos 42 arquivos de 05-html-de-referencia/ tinha @font-face — até a Montserrat dependia da fonte instalada no sistema, e funcionava nesta máquina por sorte. O mono rasterizava Consolas em 26 de 42. A solução por camada: peça impressa EMBUTE (comprovante e pasta A4, TP1, ~1,07 MB/peça declarado; assinatura de e-mail fora — cliente de e-mail não carrega @font-face) · bancada/tela ganha @font-face por URL RELATIVA para os TTF versionados (⭐ base64 nas 42 custaria ~45 MB para arquivos que nunca saem do repo; URL relativa dá o mesmo por ~1 KB) · nasce 03-assets/fontes/LEIA-ME.md com o aviso e o link que ele pediu. Aplicação pela §14.4:base-bancada.css cobre as 9 bancadas geradas; os 11 templates de tela regenerados; artefato direto só nos sem gerador (o banco-dataviz-dm com a nota da GN-P1). ⚠ Dois defeitos pegos no caminho: sete templates usam str.format() e as chaves {} do CSS viraram placeholder — ⭐ bloco inserido em template herda o mecanismo de escape do template; e o mede-fonte-efetiva.mjs chamava nó sem pixel de "recebeu outra" — nasce o veredito [sem-pixel], ⭐ não-mensurável é veredito próprio, nunca FAIL nem PASS. MEDIDO NO FIM (132 arquivos): 55 aplicam mono → 53 RECEBEM · 1 [sem-pixel] · 1 TROCOU: a assinatura de e-mail, a exceção declarada. Guardas nas 4 peças regeneradas: MM1 12·0 · GL1 4·0 · render 4·0 · PT 0 FAIL; paridade-previews mantém os MESMOS 2 FAIL pré-existentes da PV-P1 (não aumentou). A §4.5 ganha a nota: a pilha de reserva deixa de ser o mecanismo primário e vira plano B de verdade.
AS CINCO COISAS QUE ELE LEVANTOU — quatro resolvidas, e o defeito que ele achou OLHANDO era meu.
texto inteiro da versão
AS CINCO COISAS QUE ELE LEVANTOU — quatro resolvidas, e o defeito que ele achou OLHANDO era meu. ⭐⭐⭐ SN-P8 CONSERTADA SEM COMPRAR, e a chave estava nos números da véspera. Ele decidiu "nao vamos comprar, use a melhor opcao conforme sua recomendacao". A medição já havia separado dois erros que eu tratava como um: a razão da caixa batia em ~1,7% — a silhueta estava certa — e só a espessura errava, em −12,1%. ⭐ Se o defeito é só espessura, o conserto não é redesenhar: é ENGROSSAR. Um stroke da própria cor não move nenhum dos 11 vértices — e é por isso que passou onde reconstruir vértices havia sido reprovado. Medido: espessura −12,1% → −2,3%, tinta −16,2% → −5,2%, forma 29,51% → 27,17% (W012) e 16,39% → 16,16% (W042). ⚠ A razão da caixa PIOROU (1,7% → 3,8%) e fica na tabela — conserto que melhora quatro colunas e piora uma não é gratuito, e omitir a quinta seria escolher a régua depois de ver o resultado. ⚠⚠ E eu quase publiquei duas réguas na mesma tabela: o instrumento do teste normaliza pelo preto (26,45%) e o do canônico pelo amarelo (29,51%). ⭐⭐ Comparação só vale DENTRO do mesmo instrumento — número de régua diferente na mesma coluna é comparação falsa, porque quem lê supõe a mesma unidade. ⚠ O resíduo está declarado NA PEÇA: 27,17% segue acima do piso de ruído de ~10%; os dois textos públicos foram reescritos no MESMO commit que mudou o número. ⭐⭐ A PERGUNTA DELE SOBRE A FONTE EXPÔS O DEFEITO MELHOR QUE EU:"porque estamos olhando Consolas x JetBrains Mono, isso é outra fonte sem ser as canônicas?". A JetBrains Mono é canônica desde 2026-07-30 (§4.2), com papel escrito — dados de medição, identificadores, código. Quem não é do sistema é a Consolas, que é o terceiro item da pilha de reserva da §4.5. ⭐ Não estamos escolhendo entre duas fontes: estamos vendo a fonte que o canônico manda perder para o plano B de emergência. Isso reduz a PP-P1-b de "decisão de gosto" a "quando eu conserto". ⚠⚠⚠ PF-P2 — ELE ACHOU UM DEFEITO DE LEGIBILIDADE OLHANDO, e o número dá 1,01 de contraste contra o piso 3,00: cinco <code>brancos sobre branco na folha que pedia decisão dele. Causa de classe: o code declarava background e nãocolor, então dentro do bloco escuro herdava tinta clara e mantinha fundo claro. ⭐⭐ Régua: fundo e tinta se declaram JUNTOS, sempre. Consertado e medido: 274 elementos, mínimo 4,23, zero abaixo do piso. ⚠ E a lacuna estrutural fica aberta: preview/ é isento das guardas de contraste — ⭐ rascunho que serve de base para o decisor decidir não é rascunho. ✅ GR-P10 RESOLVIDA com UMA LINHA, e o quase-erro vale mais que o conserto. Eu ia copiar 14 arquivos da pasta do Drive antes de ele deletar — até conferir por MD5 e descobrir que 12 de 12 já estavam no repositório. ⭐⭐⭐ Antes de resgatar um arquivo, conferir se ele já está salvo em outro lugar: o resgate errado teria plantado aqui dentro a doença que estávamos tirando de lá — duas cópias graváveis do mesmo material. Placar GR1 21 · 0 · 7 de 7 alvos — a guarda roda pela primeira vez neste repositório. ✅ GT-P1 — DELEÇÃO LIBERADA, e por MEDIÇÃO. Conferido por MD5 (135 idênticos · 172 canônicos antigos · 629 de evidência) e por EXECUÇÃO (33 instrumentos rodados; 6 morrem por falta de arquivo e nenhum pela pasta do Drive). ⭐⭐⭐ E o caminho ensina: minha primeira análise disse 75 dependências e a segunda disse zero — as duas erradas. Foi a linha de conferência contra a prova empírica que salvou. Quando duas análises estáticas seguidas erram, o problema não é o regex — é o método: dependência em runtime se mede EXECUTANDO. ✅ GT-P2 — a subpasta assistente de email não tem relação com o projeto: é pasta de 2026-05-04 de outro projeto, e o DS nasceu dentro dela em 2026-08-22. Renomear é seguro — nenhum arquivo versionado cita o nome e nenhum código depende do caminho.
AS TRÊS DECISÕES DELE, APRESENTADAS COM O VISUAL E O NÚMERO — e uma correção de afirmação falsa que eu escrevi ontem neste arquivo.
texto inteiro da versão
AS TRÊS DECISÕES DELE, APRESENTADAS COM O VISUAL E O NÚMERO — e uma correção de afirmação falsa que eu escrevi ontem neste arquivo. ⭐⭐⭐ A cobrança que gerou esta versão nomeia um erro de leitura da §14.13 que eu vinha repetindo. Ele disse: "porque nao me apresentou as peças pra eu ver a diferença, vc disse que muda as peças, mas nao fez nenhum comentário sobre" e "eu pedi para ser mais claro no contexto da pergunta, vc precisa me explicar o que precisa e até recomendar algo para eu decidir". A §14.13 manda que toda pergunta ao decisor saia com o custo medido de cada saída — e eu lia custo como preço. ⭐ O custo de uma saída inclui o que ela muda no que já está aprovado, e isso não se enuncia: se olha. É a terceira vez que ele cobra a mesma classe de falha (antes na GD-P1, "eu nao entendi se aqui é pra eu resolver algo ou só vc"). ⚠⚠⚠ A CORREÇÃO: a PP-P1 da v5.22 afirmava que "número em peça impressa continua em Montserrat com tabular-nums", e é FALSO. O gen-comprovante-ponto.py:190 pede var(--seed-font-mono) e o Chrome rasteriza Consolas — fonte da Microsoft que a peça não embute. A regra estava sendo desobedecida em silêncio, e o erro não foi de redação: eu deduzi de "a regra manda Montserrat" que "as peças estão em Montserrat". ⭐⭐ Régua: afirmação sobre o estado de uma peça tem de ser MEDIDA na peça, nunca deduzida da regra — mesma classe do defeito da §12.19, a placa que afirmava uma conferência que não aconteceu. ⏳ PP-P1-b apresentada com visual: nasce ferramentas/mede-fonte-efetiva.mjs, que mede pelo CDP a família que o navegador de fato rasterizou — não a que o CSS pediu. Das 90 peças, 22 aplicam mono a texto: 17 recebem a JetBrains (todas da era anterior, que a embute) e 5 recebem Consolas (as vivas). Custo medido: +9,12% de largura, zero transbordos, ~357 KB por peça. ⭐ Medir o CSS mede a intenção; medir o pixel mede o resultado — getComputedStyle devolveria 'JetBrains Mono' nas 22, inclusive nas 5 que desenham Consolas. ⚠ E um erro meu de instrumento pego antes de virar número: a medição acusou um nó 88,94% mais estreito, impossível numa monoespaçada; era o getBoundingClientRect de Range colapsando na última linha em texto que quebra. ⭐ Número fora do padrão dos irmãos acusa o instrumento antes do objeto — 56 nós entre +9,01% e +9,13% denunciaram o outlier. ⏳ GT-P1 apresentada, e a premissa dele estava invertida: o Drive não perdeu papel — ele é o disco onde o repositório mora (G: é File Stream; 399 MB e 1.309 arquivos de .git sincronizando). E a pasta de origem da migração continua gravável com 172 canônicos DIVERGENTES, entre eles marca-seed.mdv5.11 — onze versões de atraso num arquivo com o nome certo, numa casa cuja regra fundadora é que metade das pesquisas é feita por IA. Medido: Drive de 1,8× a 2,6× mais lento; fsck passa nos dois. ⏳ FT-P1 REFORMULADA, e a reformulação inverte o pedido: o .woff2 leve já estava no repositório, escondido num data-URI de peça de gate — 12,6× menor — mas é recorte latin e não tem ≤ ≥ √ Ω Δ ≠ ■ ✓ ✗ ∅ ∞. ⭐⭐ Cobertura contra o acervo de hoje responde "quebra agora?"; contra o repertório da DISCIPLINA responde "vai quebrar?" — o empate em 86/86 me faria adotar o arquivo leve e plantar um defeito na primeira peça com um ohm. Ω e Δ são caracteres de trabalho em engenharia elétrica. E é o segundo achado da revisão da era Cowork: as 18 peças de gate dela embutem esse recorte incompleto. ⭐⭐ SN-P8 ganha a leitura que muda a conta: o W042 e o W012 compartilham o MESMO objeto de raio (RAIO_5036, constante única), então o "+0,5%" do W042 mede o conjunto e mascara o raio fino, e comprar só o W012 conserta os dois. Recomendação: CHF 60 (W012 + W042), não CHF 90 — os CHF 30 do P031 pagariam para confirmar o que já bate em +0,6%. O que justifica os CHF 60 é a linha de picos do W042, que está numa placa de arco elétrico e vem de desenho que a própria fonte não afirma ser oficial.
AS CINCO PONTAS SOLTAS, e a maior delas inverteu uma pendência de meses.
texto inteiro da versão
AS CINCO PONTAS SOLTAS, e a maior delas inverteu uma pendência de meses. Ele mandou fechar antes da Onda 3: "é melhor voltarmos corrigindo pontas soltas do que ficar costurando coisas erradas o tempo todo". ⭐⭐⭐ SN-P8 — o pictograma que o projeto tratava como sólido é o que está 12% errado. A SN-P12 perguntava se a linha de picos do W042 (fonte única) estava certa; medido contra a arte oficial da ISO, o W042 confere (espessura +0,5%, discordância de forma 16,4%), o P031 confere (anel +0,6%, 9,65%) e o W012 DIVERGE: 12,1% mais fino, com 29,51% de discordância — três vezes o piso de ruído que o P031 estabelece. ⭐ A causa é erro de raciocínio, não de execução: o raio foi desenhado da IEC 60417-5036, e reaproveitado não é idêntico — a ficha do W042 diz "Relâmpago (da ISO 7010-W012)" e o W012, adotado da IEC, não preservou a proporção de traço. A razão da caixa bate em 1,4%: a silhueta é a mesma família, o que difere é a espessura dos membros. ⭐⭐ E o caminho que destravou isso era gratuito o tempo todo: a ISO 3864-3:2024, na NOTE 2 da Introdução, diz que todos os sinais estão no OBP da própria ISO. Uma tentativa anterior tomou HTTP 403 e o projeto registrou "o catálogo responde 403 a acesso automatizado" — frase certa, conclusão falsa: não era paywall, era user-agent. ⭐ 403 não é "não tenho acesso": é "não me identifiquei como quem tem". ⚠ O conserto do W012 NÃO foi feito, e o motivo é medido: reconstruir os vértices do PNG de 200 px foi tentado e reprovado — melhora a espessura (9,7% contra 12,1%) e destrói a forma (Jaccard cai de 0,74 para 0,56), porque o Douglas-Peucker só fecha em 11 vértices com 5,7% de tolerância. Trocar erro conhecido de espessura por erro maior de forma é piorar com aparência de conserto.Fecha com o vetor oficial: CHF 30,00 por símbolo no OBP — decisão de gasto dele, e a peça imprime o número. ⭐ Achado de brinde, e é shall: as fichas oficiais do W042 e do P031 exigem sinal de texto suplementar por falta de dado de teste ISO 9186-1. As duas peças já cumprem — mas cumpriam por acidente de composição. Agora o requisito tem nome, e regra com nome sobrevive ao próximo redesenho que "limpa" o texto. ✅ PQ-P2 FEITA: nasce a §12.21, a cartela de identificação de dispositivo DENTRO do quadro (IEC 61439-1 §6.3), 120+40 tiras por A4 no passo de 17,5 mm do trilho DIN. Três defeitos nela pegos pelo gate visual, e o primeiro vale régua: display:flex num container de texto corrido quebra o parágrafo em cada tag inline — o rodapé saiu com "deve", "devem", "devem" em linhas sozinhas e transbordando a margem. ✅ PP-P1 RESOLVIDA: JetBrains Mono v2.304 versionada (400/500/700, OFL), com cobertura de glifo medida antes de declarar — 1363 glifos, todo o repertório técnico presente, e exatamente um ausente (U+2011, com zero ocorrências no acervo). ⚠ Isso resolve disponibilidade, não uso: passar as peças a consumir --seed-font-mono muda a aparência de dez peças aprovadas e é decisão dele. ⭐ Destravar um recurso não autoriza gastá-lo. ✅ GD-P1 RESOLVIDA, e ela era 100% minha — ele teve de pedir clareza: "seja mais claro no que disser, eu nao entendi se aqui é pra eu resolver algo ou só vc". Nasce alvosHtml() no ambiente.mjs e 12 instrumentos passam a usá-lo. O defeito tinha classe própria: onze guardas descartavam em silêncio todo argumento que não terminasse em .html e caíam na varredura do acervo. ⭐ Não é quebrar nem dar veredito falso: é medir outra coisa e não avisar — o placar sai verdadeiro e a leitura de quem pediu sai falsa. ✅ A REVISÃO DA ERA ANTERIOR, que ele pediu antes da Onda 3, tem número — e é boa notícia. Nasce o censo-era-cowork.py: 18 de 88 peças físicas (20%) são invisíveis para a guarda de token e para o render, e todas as 18 são evidência de gate histórica — nenhuma peça viva está na lista. ⚠ E o censo reprovou em bloco duas vezes antes de acertar: primeiro cobrando de bancada o que só peça deve ter (43 falsos positivos em 54), depois acusando a assinatura de e-mail, cuja isenção já estava escrita na §12.8. ⭐⭐ Caminho não é classificador de tipo: 07-pecas/ guarda peça física, fragmento de e-mail e evidência histórica — três naturezas na mesma pasta. E o render-peca.mjs deixa de reportar 4 FAIL crônicos e passa a dar-lhes veredito [hist], como a PF-01 já fazia.
O GATE DA ONDA 2: as dez peças entram no canônico (§12.11–§12.20), e a décima não estava no plano.
texto inteiro da versão
O GATE DA ONDA 2: as dez peças entram no canônico (§12.11–§12.20), e a décima não estava no plano. O veredito dele, verbatim: "1. todos aprovados". Para quem lê sem ter visto a conversa: a Onda 2 produziu nove peças em 2026-08-25 — laudo, memorial, checklist, selo de prancha, ART/diário, as-built, crachá, etiqueta e sinalização —, e elas ficaram em 07-pecas/sem seção canônica, porque a regra §0-b não deixa regra de marca nascer sem veredito dele. Esta versão promove as dez. ⭐⭐ A DÉCIMA nasceu de uma pendência que ele REFORMULOU em vez de responder. A SN-P13 perguntava se quadro elétrico isolado precisa de placa de advertência própria (medido: exigiria A2 — em A4 paisagem estoura 138 mm, em A3, 59 mm). Ele respondeu outra coisa: "os quadros eletricos possuem placas de fabricação e identificação, que pode ser um placa da seed, ela motra a tensao do quadro e pode ter mais alguma informação." Nasce a §12.20 — placa de identificação do quadro, 100 × 70 mm, com a SEED na condição de fabricante do conjunto. A pergunta certa não era "que sinalização falta?", era "que placa a norma já exige de nós e nós não estávamos fazendo?". ⭐ E a lacuna estava anotada no acervo desde a Onda 2: o gen-etiqueta.py já dizia por escrito que "esta etiqueta não substitui a placa de dados do fabricante" — a peça que ela dizia não substituir simplesmente não existia. ⚠⚠ E o achado normativo da §12.20 contraria o que o mercado repete. Lida a IEC 61439-1 Ed. 2.0 (2011-08), cláusula 6.1, a etiqueta do conjunto exige quatro informações e só quatro: nome/marca do fabricante · designação de tipo ou nº · meio de identificar a data de fabricação · IEC 61439-X. Tensão, corrente, frequência, Icc e IP não estão nela — a cláusula 6.2.1 manda esses dados para a documentação técnica. Três páginas brasileiras afirmam o contrário e nenhuma cita cláusula. A norma foi lida; as páginas, não. A peça traz os dados elétricos assim mesmo, por decisão dele e pela NBR 14039 4.2.5.3, e imprime na própria placa qual metade é obrigação e qual é escolha — peça que mistura o obrigatório com o escolhido, sem dizer qual é qual, transforma decisão nossa em norma alheia. ⚠⚠⚠ A CORREÇÃO MAIS SÉRIA DESTA VERSÃO, e ela é na §12.19: a placa de sinalização AFIRMAVA uma conferência que não aconteceu. O SVG do W042 saía com data-conferido-visualmente="sim, contra a arte oficial (…) p.405, em 2026-08-25". Duas vias independentes desmentem: (a) o extrato da leitura da norma tem a seção "O que foi conferido" com duas entradas, W012 e P031, e cita o W042 na seção de ações; (b) a data é anterior ao desenho — o W042 nasceu no commit de 2026-08-26. ⭐ Não se confere visualmente um desenho que ainda não existe, e a data que estava ali para dar credibilidade é o que derruba a afirmação. ⭐⭐ A classe importa mais que o caso: o W042 foi acrescentado a três listas que já diziam "FEITA e CONFERE" (o texto impresso, o metadado e o stdout) e herdou o verbo de graça — acrescentar item a uma lista de coisas verificadas propaga o veredito sem propagar a verificação, e o custo de conferir some no meio da vírgula. Custo máximo aqui, porque isso sai impresso numa placa de segurança que alguém pode mostrar a um órgão. SN-P12 fechada com decisão, não com fonte: a busca por uma segunda digitalização da linha de picos achou algo pior — a única fonte que existe se declara"similar to recommendation issued in ISO 7010:2019", obra própria de terceiro. ⭐ "Fonte única" quer dizer que ninguém confirmou; isto quer dizer que a própria fonte não afirma ser a oficial. O W042 fica, porque sem ele a placa cita o item 10.7.7.1 b) da NR-10 (choque e arco) e cumpre metade — pictograma aproximado que comunica "arco elétrico" protege mais que a ausência de pictograma. Fecha com ~5 min de leitura da p. 405, numa assinatura paga por tempo, e não foi feito porque ele perguntou em 2026-08-25 se ainda precisava dela e a resposta foi não.
A CAMADA 3 FECHA (SG1 a ZERO FAIL) e a COLISÃO DE ALTURA, aberta em 2026-08-15, é RECONCILIADA.
texto inteiro da versão
A CAMADA 3 FECHA (SG1 a ZERO FAIL) e a COLISÃO DE ALTURA, aberta em 2026-08-15, é RECONCILIADA.Para quem lê sem ter visto a conversa: a entrada v1.22 desta mesma tabela terminava com uma lista chamada "o que fica para a sessão principal" — decidir o par dark do divider-strong, marcar switch-off-bg/slider-track como medição pendente, fixar a curva do ease-out, isentar o input-affix e abrir a pendência do estado OFF no tema claro. Esta versão fecha a lista inteira, e vale dizer por quê: lista de pendência que ninguém fecha vira lista de desculpa, e a única prova de que ela servia é ela acabar. Todas as seis decisões vieram do Rafael em 2026-08-26, no gate das nove peças da Onda 2. ① O SWITCH — e a medição achou três coisas, não uma. Ele decidiu: "acredito que tem que conseguir um tom que atenda o piso. analise e decida". (a) O tom é cinza-500 #788F9D = 3,38:1, primeiro degrau da escala acima do piso — o cinza-400 ainda reprova, com 2,53. Zero cor nova (§14.1). (b) ⭐ Medir "3:1 sobre a página" era medir METADE do componente: o thumb é BRANCO, e branco sobre cinza-300 dá os mesmos 1,91 — o thumb sumia dentro do trilho, e a posição do thumb é o único canal que separa ON de OFF (K3: nunca "ON/OFF" escrito no trilho). Cinza-500 conserta os dois pares de uma vez. (c) ⭐⭐ No tema ESCURO quem reprovava era o estado LIGADO, não o desligado — thumb cinza-100 sobre o trilho ligado dá 2,25 — e ninguém tinha visto porque a cláusula só mandava medir o OFF. A saída não precisou de cor nova: "o que vai sobre a superfície de ação" já é par medido e canonizado (--seed-text-on-action-primary), e o thumb de um switch ligado é exatamente isso — 7,39:1. Nasce --seed-switch-thumb-on; no claro ele coincide com o thumb desligado, e isso é a regra colapsando, não duplicação. (d) Dois erros de NOME na mesma linha da spec, consertados junto: ela apontava para --seed-action-primary-bg, o token fantasma da FF-P2/FF-P3, e dizia "turquesa-400 sobre dark" quando action-primary escuro é #66D1C2 = turquesa-300. ⭐ Spec que aponta para nome morto passa em toda guarda de valor, porque não há valor nenhum para conferir.② O SLIDER tinha a mesma doença, e ela só apareceu porque o switch foi medido — cinza-300, os mesmos 1,91. Passa a cinza-500. ⚠ Mas aqui a saída é diferente, e a diferença importa: nenhum degrau atende os dois pares, porque o vazio precisa ficar longe do branco da página e longe do turquesa do preenchido, e o turquesa-600 mora no meio da escala (cinza-300 dá 2,40 contra o preenchido, cinza-500 dá 1,36). A decisão não foi escolher o menos pior; foi ver o que cada par carrega: o valor tem canal textual garantido pela própria spec ("valor corrente visível SEMPRE") e canal de forma no thumb de 24px com borda, então a divisão preenchido/vazio é o terceiro canal e fica decorativa declarada, com o número escrito (1,36 claro / 2,59 escuro) — mesmo tratamento de card-border e divider-color. Exigir 3:1 ali seria criar cláusula que o canon nunca teve, e cláusula nova é decisão dele.③ E OS DOIS TINHAM O MESMO DEFEITO ESTRUTURAL, que era o que ele já havia apontado:--seed-switch-off-bg e --seed-slider-track eram declarados só no tema escuro e com escopo de elemento ([data-theme="dark"] .seed-switch{…}) — e como não existiam no gêmeo, no tema CLARO o var() não resolvia e o controle ficava sem fundo nenhum. Com o token no gêmeo, as duas regras de escopo somem e o defeito morre pela raiz. ⭐ Token declarado só num tema não é "tema faltando" — é um estado que não existe na metade do sistema.④ A CURVA: ele mandou "teste os 2 e decida", e o teste devolveu uma resposta melhor que "escolha um". Resolvendo o bézier em 21 instantes de um movimento de 120 ms e convertendo para tempo — porque milissegundo é o que o olho pode ou não perceber, e "parecem diferentes no papel" não é medida de nada: .2,.8,.4,1 e .2,.7,.3,1 diferem no máximo 1,5% do percurso e 0,3 ms. A 60 Hz um quadro dura 16,7 ms, então a diferença é 1/56 de quadro e não existe em nenhum monitor — eram dois nomes para a mesma curva. Escolhida a de maior uso (3 artefatos contra 2), que também faz o conserto ser de 2 arquivos e não 3. ⭐⭐ E o mesmo teste respondeu a pergunta que ninguém tinha feito:--seed-ease-out deve existir, ou era apelido de --seed-ease-productive? Contra o productive a diferença é 36,8% e 24,9 ms — 83 vezes maior que a diferença entre as candidatas. São curvas diferentes de verdade, então o token merece existir. Sem o número, isso se responderia por gosto. ⑤ O DIVISOR FORTE: a v1.22 recusou emiti-lo, com um argumento bom — e o que mudou não foi a opinião, foi a medição. A recusa se apoiava no "1,91 light" da spec. ⚠⚠ Esse número não existe: medidas as cinco superfícies do tema claro contra o border-default, nenhuma dá 1,91 (page/raised/overlay = 1,49; subtle 1,37; sunken 1,23). O número foi transplantado — 1,91 é o que o border-subtleescuro dá sobre a página escura. ⭐ O número estava certo em algum lugar do arquivo; só estava grudado no token errado. E o irmão só batia porque foi medido contra outro fundo: o "1,75 dark" do divider-color não sai da surface-page (1,91) — sai da surface-subtle. ⭐⭐ Régua: contraste sem fundo declarado não é um número, é uma família de números — e foi variando o fundo, uma condição por vez (§14.5), que os três valores se explicaram. Sem o 1,91, o cinza-600 do consumidor vivo se revela dialeto local e vale a regra simétrica do irmão: border-default nos dois temas (1,49 / 2,84, decorativo declarado). ⑥ O --seed-input-w-md NÃO foi emitido, e a saída certa não era nenhuma das duas que a SG1 oferece. O nome aparecia uma vez, num exemplo de HTML da §2.5: style="max-width:var(--seed-input-w-md,320px)" — um var() apontando para um token que nunca existiu, que é o mesmo defeito do switch. ⭐ Exemplo de código num canônico é código que alguém copia; citar nele um var() que não resolve não é citação, é ensinar o defeito. O exemplo passou a escrever 320px direto e o nome saiu do canônico. ⚠ E aí nasceu a 6ª classe de falso positivo da SG1: o comentário que EXPLICA a remoção cita o nome, e a guarda reprovou de novo — com razão, porque para ela nome no arquivo é nome no arquivo. Reescrever o comentário sem o nome faria a guarda passar e apagaria a lição, trapaça que a isenção do --seed-tq-300 já proíbe. Isentado com o motivo escrito. As seis classes hoje: curinga · placeholder maiúsculo · classe BEM · contraexemplo documentado · nome de exemplo em diagrama · nome citado no registro da própria remoção. Todas dizem citar não é pedir. ⑦ A ALTURA DE CONTROLE — ele mandou "reconcilie para todos seguirem o padrão". De 2026-08-15 a 2026-08-26 o DS teve três réguas com dois números: 32/40/48 em --seed-control-* (v1.14, genérica, herdada do Fluent) contra 32/44/52 em --seed-button-height-* e --seed-field-height-* (fixados por escrito na §1.6 e na §2.5, com a decisão explícita "md = 44px (não 40px)"). O sm já coincidia. ⚠ O desempate não foi por gosto: medido, NENHUM artefato do acervo consome --seed-control-* — os três consumidores são a spec, a guarda de paridade e o gêmeo. A régua genérica era a de papel; vence quem tem spec. ⚠ E o argumento certo para o 44 não é o SC 2.5.8, que pede 24×24 (AA) e que 40 também cumpriria: o 44 é fundamento próprio do DS, mais generoso que a norma — e é por ser decisão nossa que ele precisava ser reconciliado em vez de deduzido de fora. O preset compacto (28/32/40) não muda: é densidade para tela de dado com mouse, e fica abaixo do alvo de toque de propósito. PLACARES.SG1: 140 PASS · 7 FAIL · 6 [isento] → 147 PASS · 0 FAIL · 7 [isento] — a camada 3 não tem mais nenhum nome que o canon cite e o gêmeo não defina. paridade-tokens.py: 103 → 110 PASS · 0 FAIL. ⚠ E esta é a primeira leva que NÃO é adição pura — as v1.21 e v1.22 podiam se gabar disso; esta muda dois valores, e o G1 acusou, exigindo supersede declarado (SUPERSEDES_V123_ROOT). Declarar é o preço de mudar valor, e o preço é barato.:root 323 → 330 (+7), dark 129 → 135 (+6). ⭐ E a linha info: do G6, que desde a v1.22 imprimia "COLISÃO DECLARADA de altura" a cada execução, passa a imprimir "RÉGUA ÚNICA desde a v1.23: md=44px · lg=52px nos três grupos" — e continua imprimindo os três pares, de modo que, se algum dia um deles derivar, a divergência aparece na mesma linha que hoje diz que não há nenhuma. O oposto de declarar um problema não é silêncio: é declarar que ele fechou.CONSUMIDORES. As duas bancadas que carregavam a curva divergente (banco-feedback, banco-superficies) foram atualizadas pelo reinjeta-tokens.py — ⭐ o build de quem não tem gerador fez sozinho o trabalho, e sem chance de errar um hex —, e o mesmo build apagou o dialeto do divisor (cinza-600 → #4D606C). ⚠ O que ele NÃO faz, por regra declarada, quase me custou as duas bancadas: ele não acrescenta token que o preview não consumia. Ao apagar as regras de escopo local do switch e do slider eu deixei banco-formfield.html consumindo var() de tokens que não estavam escritos nele — e o arquivo carrega cópia embutida, não lê o gêmeo. Os dez tokens foram acrescentados aos blocos :root e dark, e o reinjetor, rodado em seguida, confirmou 0 divergências contra o gêmeo. ⭐ Apagar dialeto local só é seguro depois de o canônico chegar ao arquivo — e num preview de cópia embutida, "chegar" quer dizer estar escrito nele.
AS DECISÕES DELE SOBRE A ONDA 2, e três delas mudam REGRA e não peça.
texto inteiro da versão
AS DECISÕES DELE SOBRE A ONDA 2, e três delas mudam REGRA e não peça. ⭐ NASCE A TERCEIRA VARIANTE DE RODAPÉ, compacto (8 mm, uma linha de contato, sem grafismo, área útil de 241 mm), e com ela a regra de uso das três como [LEI]: ofício só para carta e correspondência formal; orçamento para documento técnico e comercial; compacto onde área útil é o recurso escasso. Verbatim dele: "o foco é otimizar a area útil para caber mais informação com o foco em diminuir o numero de paginas sempre". Quatro peças da Onda 2 estavam na variante errada, todas com o mesmo argumento plausível — argumento plausível não vence prioridade declarada. ⭐ E a variante nasceu de uma PEÇA, não de uma proposta: o rodapé de uma linha existia local no diário de obra e ele o reconheceu como padrão ("é um modelo de rodapé"). Ganho medido numa pasta real: 1 folha em 6, 16,7% menos papel. ⭐⭐ A MR-P12 DEIXA DE SER BLOQUEIO, e o que a substitui é uma FRONTEIRA que ele pediu: "o DS nao seria um template que depois onde fosse ser produzido seria visto as regras do local?". A fronteira NÃO é "produção × design" — é "MUDA O DESENHO × NÃO MUDA": a sangria de 3 mm e o piso de 0,25 mm são restrições de produção e mudam o desenho, então ficam; tolerância de faca, posição de furo e margem de vinco saem. O DS entrega o template e a lista declarada de restrições, nunca um "arquivo de produção". Cinco peças deixam de esperar. ⭐⭐ A §17.6 ganha a fronteira da peça que NÃO compartilha o campo visual, mas É o campo visual (veredito dele: "normal de segurança deve seguir as cores da norma de segurança, nao podemos impor nosso DS sobre isso"): em peça de segurança, quando a norma colide com a identidade, a NORMA GANHA. Na família NR-10 a assinatura é monocromática, pela NR-26 26.1.4. ⚠ E o que NÃO sai está declarado: tinta de texto fica — reduzir cor não é apagar tinta. Custo medido: contraste MELHORA (9,37:1 → 21,00:1) e o reconhecimento a distância piora só na placa A3 (1,75 m contra 4,0 m de premissa).
AS DUAS PENDÊNCIAS DE DADO FECHARAM, e as duas confirmaram o canônico.
texto inteiro da versão
AS DUAS PENDÊNCIAS DE DADO FECHARAM, e as duas confirmaram o canônico. ✅ MR-P15: "o contrato está correto" — três itens separam o Essencial do Premium, não um; a peça já estava assim, então o veredito não mudou artefato, mudou o ESTADO da regra, de divergente para confirmada (divergência aberta convida a próxima sessão a "consertar" o que está certo). Fica registrado o que o Essencial NÃO tem — nem suporte por WhatsApp/telefone, nem apoio junto à concessionária —, porque é contraintuitivo: não se pode presumir que "todo plano tem um canal de suporte". ✅ MR-P14: o endereço de Governador Valadares é Rua Duarte Coelho, 205, e o canônico estava certo nas DUAS vezes em que foi questionado — primeiro contra o orçamento, depois contra o CONTRATO. Nenhuma peça alterada; a ação virou correção do material em circulação e do contrato que o cliente assina. ⭐ Régua: decisão tomada com uma evidência merece ser reapresentada quando aparece outra — e foi por NÃO ter sido alterado "para casar com o material" que o canônico seguiu servindo de referência.
O CONTRATO-MODELO FECHA AS CINCO LACUNAS DO SEED PLUS
texto inteiro da versão
O CONTRATO-MODELO FECHA AS CINCO LACUNAS DO SEED PLUS e a §12.10 passa a poder afirmar o que antes era proibido: o escopo da manutenção preventiva (reaperto de conexões e estruturas · medição de grandezas · limpeza de inversores, disjuntores e DPS · limpeza dos painéis), os prazos de execução (90 dias para a primeira, 30 para data fora da programação, 15 para verificar corretiva), renovação automática, reajuste, e que é VENDA ANUAL parcelada em 12×, não mensalidade. As obrigações do contratante entram nas observações — proposta que esconde a obrigação do cliente cria surpresa na execução, e surpresa chega como reclamação, não como aditivo. ⭐ A VALIDADE É POR TIPO DE SERVIÇO, não constante da empresa: função da volatilidade do custo — SEED Plus 10 dias, energia solar 5, porque o preço do material muda. Pesa mais na §12.7, que serve material E serviço. ⚠ MR-P15 aberta: ele afirmou que só a preventiva separa Essencial de Premium, mas o orçamento E o contrato trazem matriz idêntica com três itens de diferença — a peça segue os documentos, porque é o contrato que obriga. §12.9: as três peças antigas do cartão foram removidas com o ponteiro da §7.4-d repontado ANTES, e as evidências de gate ganharam veredito próprio [hist] na PF-01.
§12.10 A PROPOSTA DO SEED PLUS — a peça em que o cliente ESCOLHE.
texto inteiro da versão
§12.10 A PROPOSTA DO SEED PLUS — a peça em que o cliente ESCOLHE. Três folhas, itens 1 a 10 contínuos, matriz comparativa dos três planos (2 · 4 · 7 itens, do sobreaseed.md §6) e um campo que a §12.7 não tem: PLANO CONTRATADO, destacado na folha que se assina — sem ele, o que foi contratado depende de memória. Preço por USINA, não por cliente. ⚠ A marca de "inclui" é Unicode explícito com aria-label, nunca fonte simbólica: o orçamento de origem usava Webdings (a = ✔, x = 🚫), e lidos como letras os dois não dizem nada — marca em fonte simbólica morre em extração de texto e em leitor de tela. ⚠ table-layout:fixed é obrigatório na matriz: no layout automático o width de célula é SUGESTÃO, e o navegador deu à coluna de descrição menos espaço que às de marca (48/41/41/41 mm), levando cada linha a 29 mm. §12.4 ganha a trava 7: nenhuma marcação aparece como texto na peça (guarda-escape.py, ES-01/ES-02) — três ocorrências num dia, todas por o contrato de escape não estar declarado, e uma delas estourou uma folha em 167,7 mm; ⭐ isinstance(str) NÃO é teste de "precisa escapar".
A RODADA DE CORREÇÕES DELE SOBRE A ONDA 1 — e ela rendeu uma LEI NOVA.
texto inteiro da versão
A RODADA DE CORREÇÕES DELE SOBRE A ONDA 1 — e ela rendeu uma LEI NOVA. ⭐ §7.4-f: o grafismo de linha exige span ≥ 125 mm para cumprir o piso de 0,25 mm, medido em nove spans (78 mm → 0,157 · 124 mm → 0,249 · 125 mm → 0,251 · 170 mm → 0,342). Altura do divisor e espessura do traço são a MESMA grandeza, então não há como encolher um sem o outro — peça menor que 125 mm SANGRA o grafismo ou não o usa. §12.9 CARTÃO 90×50 refeito do zero por veredito dele ("nada é definitivo. se podemos melhorar, vamos melhorar"), e o erro que o fundou vale a lei: medi 0,250 mm nos arquivos antigos e concluí escala 1:1, mas eles usam OUTRA cena do grafismo — ⭐ medir o artefato antigo não substitui medir o INSTRUMENTO que vai gerar o novo. §12.7 a proposta virou UM documento numerado de ponta a ponta (itens 1 a 15 atravessando as duas partes, folhas 1 a 4 "de [N]", total como placeholder porque depende do preenchimento), sem duplicação entre as capas, com o RESUMO DO INVESTIMENTO e os OPCIONAIS subindo para a capa comercial e o PRAZO vindo da técnica para lá (art. 40 do CDC exige datas no ORÇAMENTO), e sem campo de assinatura na técnica — assinar duas vezes o mesmo negócio cria a dúvida de qual das duas obriga. §12.5 a grade de soluções da pasta refeita: cinco filetes curtos liam como cabeçalho de tabela; entram rótulo, UM fio contínuo e numeração 01–05. ⚠ E a régua do <br> pegou o próprio autor — o comentário que eu escrevi ao lado dela afirmava uma largura que eu NÃO tinha medido.
SEGUNDA LEVA DA CAMADA 3 — 19 tokens em seis grupos, e a classe da AD-P6 passa a ter INSTRUMENTO.
texto inteiro da versão
SEGUNDA LEVA DA CAMADA 3 — 19 tokens em seis grupos, e a classe da AD-P6 passa a ter INSTRUMENTO.Para quem lê sem ter visto a conversa: a v1.21 (mesmo dia) emitiu o primeiro grupo de componente dos gêmeos, o form-field, porque o seed-componentes.md descrevia 21 tokens --seed-field-* que nenhum artefato podia consumir — a spec citava, o gêmeo não definia. Esta entrada fecha a mesma classe para os grupos seguintes. O que mudou no método, e é o mais importante desta versão: a pergunta "quais grupos ainda faltam?" era respondida por grep e memória, e errou por quatro caminhos diferentes numa única tentativa — família escrita com * (--seed-field-* não é um token), família com posição genérica (-N), classe CSS em BEM lida como token (o -- duplo de .seed-btn--primary) e contraexemplo documentado lido como pedido. Nasce então a guarda 06-validacao/guardas/guarda-spec-gemeo.py (contrato SG1), que varre os 01-canonicos/*.md e reprova todo custom property que o canon nomeia e o gêmeo seed-tokens.cssnão define, imprimindo nome, quem cita, quantas vezes e a linha de contexto. Placar SG1: 121 PASS · 29 FAIL · 3 [isento] antes desta edição → 140 PASS · 10 FAIL · 3 [isento] depois (cobertura: 153 nomes distintos em 10 canônicos, conferidos contra 323 definidos no gêmeo). OS 19 EMITIDOS, cada um com valor e origem.Botão (12), seed-componentes.md §1.6 l.126-148 — a spec escreve o bloco CSS inteiro, com o par dark explícito e a regra que o gerou verbatim ("token de componente que referencia primitivo DEVE declarar o par dark — primitivo não troca de modo sozinho", correção v0.5): button-radius 8px (= radius-md) · button-font-weight 600 (= fw-semibold) · button-height-sm/md/lg 32/44/52px (fixados) · button-gap 8px (= sp-2) · button-secondary-border turquesa-600 #098475 / turquesa-300 #66D1C2 · button-secondary-text turquesa-800 #005048 / turquesa-100 #CDF3EC · button-outline-border cinza-600 #617683 / cinza-400 #90A6B3 · button-ghost-text turquesa-700 #006C62 / turquesa-300 #66D1C2 · button-toggle-on-bg turquesa-800 #005048 / turquesa-300 #66D1C2 · button-toggle-on-fg#FFFFFF (único valor de cor da leva que a spec fixa em hex, não em alias) / turquesa-900 #00352F. Cartão (3), §26 l.1954: card-bg = surface-raised · card-border = border-subtle (borda decorativa declarada: 1,21 claro / 1,75 escuro, abaixo do piso 3,00 da SC 1.4.11 de propósito, porque a separação é carregada por espaço + raio + superfície + tipografia) · card-radius 12px (= radius-lg → radius-6). Divisor (1), §26-F l.1976: divider-color = border-subtle. Lista (1), §26-F l.2000: list-hover = surface-subtle no claro e o hex #273137 no escuro — a assimetria é da spec e foi preservada, porque #273137 é o surface-overlay do escuro, não o surface-subtle (#141D23), e é o que os quatro consumidores vivos renderizam. Item destrutivo de menu (1), §27 l.2181: danger-item = vermelho-700 #A5272A / vermelho-200 #FFC2BD. Espera (1), §17 R3-c l.1687: wait-delay1000ms, número que a própria linha fixa por escrito ("default 1000ms"), fundamentado no limite de 1s de Nielsen, com revisão por telemetria real do ERP na F4 declarada ali como "pendência declarada, não decisão aberta". OS 10 QUE NÃO SE EMITE, com o motivo — e eles são a lição desta versão, porque nem todo nome citado é um pedido. ⓐ Três contraexemplos documentados (documentação de um defeito CITA o defeito, e citar não é pedir): --seed-button-primary-bg aparece só no diagrama de arquitetura do §1 deste arquivo e do seed-email.md ("3. COMPONENTE — exceção local"), como ilustração do conceito de camada 3 — e a §1.6, que é a spec real do botão, deliberadamente não o cria, porque o botão primário consome --seed-action-primary sem divergir (a regra do §1 daqui: "a camada 3 só nasce quando um componente precisa divergir do semântico"); --seed-input-affix está na coluna Descartado da tabela de decisões do §3.10 ("duplicaria help-text sem caso de uso divergente"), com a §3.6 dizendo em texto "Tokens novos: nenhum de cor"; --seed-danger-solid é nomeado no mapa-cobertura-ds.md §21 dentro da tabela da "cegueira de nome" — a mesma superfície vermelha sólida vive no acervo sob três nomes, e este é justamente o que carrega o valor divergente (#D94545 contra #C6393B), já registrado como pendência AC-P5 e MR-P3; emiti-lo canonizaria o defeito. ⓑ Quatro lacunas reais da spec (nome sem origem de valor declarada — §14.1: valor que não existe no canônico não se cria): --seed-input-w-md aparece uma vez, dentro de um exemplo HTML de style embutido, como var(--seed-input-w-md,320px); o 320px é fallback de CSS, não declaração, não existe escala de largura (-w-sm/-w-lg) e não há medição nem racional — emitir inventaria uma escala de um membro só. --seed-divider-strong: a §26-F fixa o alias (border-default) e mede 1,91 apenas no claro, sem declarar o par dark, e o único consumidor vivo (banco-superficies.html) usa cinza-600 #617683 no escuro, que não é o border-default dark (#4D606C) — emitir qualquer um dos dois lados criaria contradição com o consumidor ou invenção de valor. --seed-switch-thumb: a spec diz "branco / cinza-100", mas a bancada banco-formfield.htmlfixa #fff nos dois temas e não consome o token; divergência sem decisão registrada. --seed-ease-out: a spec o usa quatro vezes e nunca fixa a curva, e o acervo tem dois valores diferentes rodando — cubic-bezier(.2,.8,.4,1) em três artefatos e cubic-bezier(.2,.7,.3,1) em dois (medido por varredura nas bancadas); o gêmeo não tem ease-out, só ease-productive/ease-expressive. ⓒ Três de dependência circular com o fantasma:--seed-switch-off-bg e --seed-slider-track têm o alias condicionado a uma medição que nunca foi feita (a própria spec escreve "3:1 sobre a página: medir na produção do preview") — e o valor que ela propõe não passaria: cinza-300 #ACBECA sobre a página clara mede 1,91, medido aqui, contra o piso de 3,00 que a linha exige; o único consumidor declara só a metade escura, e com escopo de elemento ([data-theme="dark"] .seed-switch{…}), o que deixa o estado OFF do tema claro com background inválido — defeito real, medível, e que merece pendência própria. --seed-switch-on-bg tem como origem declarada o --seed-action-primary-bg, que é token fantasma isento na SG1 (FF-P2/FF-P3), e o valor dark que a spec lhe dá (turquesa-400) contradiz o --seed-action-primary vivo do tema escuro (turquesa-300 #66D1C2), que é o que a bancada de fato renderiza — além de o componente não divergir do semântico, o que pela regra do §1 proíbe criar a camada 3. VERIFICAÇÃO DE SUPERSEDE, feita antes de emitir cada valor (a régua que a v1.21 pagou caro: spec desatualizada que ninguém anota vira token errado). Três decisões posteriores foram achadas e nenhuma muda valor dos 19: CD-P7 (2026-08-17, fechada) decidiu que os 93 botões com borda abaixo de 3:1 não são defeito de SC 1.4.11, porque rótulo legível já identifica o controle — é veredito sobre conformidade, não sobre valor; MR-P1/MR-P2 (2026-08-17) reescreveram a tinta sobre fundo de marca, mas na família text-on-*, e o registro diz explicitamente que "o botão primário não muda de aparência"; CP-P4 (2026-08-15) supersedeu a forma de aplicar a borda do cartão (de border para o par anel-de-1px + sombra), sem tocar no valor do token. Os consumidores vivos foram conferidos um a um e concordam com a spec em todos os 19 — banco-componentes.html (l.406-411) já declarava os seis tokens de cor do botão com os mesmos aliases, banco-superficies.html os três do cartão e o divisor, quatro bancadas o list-hover e duas o danger-item. PLACARES, antes e depois.paridade-tokens.py: 85 → 104 PASS · 0 FAIL, com o gate novo G6 (irmão do G5: presença nos dois gêmeos, fidelidade alias→valor e espelho prefers-color-scheme idêntico ao [data-theme="dark"]); o G6 imprime a cada execução uma linha de INFORMAÇÃO com a colisão de altura, para que ninguém a descubra por acidente. G1 estrito contra o CSS v1.21 real: 0 sumidos, 0 alterados, :root 304 → 323 (+19), dark 118 → 129 (+11) — adição pura provada, não afirmada. paridade-previews.py: 505 PASS · 0 FAIL, inalterado. guarda-valor-gemeo.mjs (contrato AC5, artefato × gêmeo no Chrome real): 40 PASS · 0 FAIL nos dois lados, com a medição feita duas vezes variando UMA condição (o gêmeo) — contra o v1.21: 11 [achado], 5.556 valores comparados, 76 declarações de dialeto local; contra o v1.22: 10 [achado], 5.588 valores comparados (+32), 60 declarações de dialeto local (−16). Ou seja: 16 redeclarações que eram "dialeto local, ninguém confere" viraram valor conferido contra o gêmeo, nos dois temas, e todas passaram. PROVA DE CONSUMO (cobaia mínima no scratchpad, fora do repositório, ligada ao gêmeo real por file:// e sem repetir nenhum valor literal; Chrome real pelo contrato ambiente.mjs, medição por getComputedStyle): 38 PASS · 0 FAIL — 19 tokens × 2 temas. E a contraprova, que é o que dá sentido ao número: a mesma cobaia apontada para o gêmeo v1.21 devolve 0 PASS · 38 FAIL, com as cores caindo em rgba(0,0,0,0) e o delay em 0s — a camada é medida de verdade, e reprova quando não existe. COLISÃO DECLARADA E NÃO RESOLVIDA, com os três números lado a lado, para decisão do Rafael:--seed-button-height-md/lg = 44/52px (§1.6) e --seed-field-height-md/lg = 44/52px (§2.5, decisão explícita "md = 44px (não 40px)", alvo de toque WCAG) contra --seed-control-md/lg = 40/48px (v1.14, régua genérica de altura de controle). Dois números para o mesmo degrau da escala, agora em três grupos. Emitido como cada spec fixa; reconciliar é decisão de canônico, não dos gêmeos. O QUE FICA PARA A SESSÃO PRINCIPAL, porque é promoção de texto canônico e não emissão de token: anotar no seed-componentes.md que a §3.6/§3.10 já resolveram o input-affix (para a SG1 poder isentá-lo em vez de reprová-lo), decidir o par dark do divider-strong, marcar o switch-off-bg/slider-track como medição pendente, fixar a curva do ease-out num dos dois valores que já rodam, e abrir a pendência do estado OFF do switch no tema claro.
A CAMADA 3 (componente) COMEÇA A EXISTIR NOS GÊMEOS — form-field, fecha a AD-P6.
texto inteiro da versão
A CAMADA 3 (componente) COMEÇA A EXISTIR NOS GÊMEOS — form-field, fecha a AD-P6. O defeito, medido: seed-componentes.md §2.5 (validada pelo Rafael em 2026-08-02, v0.6/v0.7) especifica 21 tokens --seed-field-* com contraste medido par a par; seed-field- aparecia 116 vezes na spec e ZERO nos gêmeos — a camada era perfeitamente descrita e inconsumível, e o ERP (resultado nº 1 do projeto) consome exatamente ela. A emissão: adição pura (nenhum valor anterior muda), cada token gravado como o hex RESOLVIDO do alias que a §2.5 declara (ex.: field-label = cinza-900 #242E34), nos três blocos do CSS (:root, [data-theme="dark"] e o espelho prefers-color-scheme) e no grupo semantic.field do JSON — com UMA exceção obrigatória, achada pela verificação de colisão com decisão posterior: field-border NÃO segue a §2.5 l.400 (cinza-600), porque a CD-P2 (2026-08-17, fechada) a supersedeu — o alias vigente é --seed-border-interactive (cinza-500 #788F9D nos dois temas; medido 3,13 claro / 5,05 escuro, o local degradava na inversão 4,74→3,21), e a bancada banco-formfield.html já renderiza assim desde CD-P2; as variantes de estado (-hover/-error/-success/-warning) não migraram, por decisão da própria CD-P2. A colisão foi flagrada pela guarda-valor-gemeo.mjs, que comparou a emissão com o consumidor vivo — a primeira emissão seguia a §2.5 verbatim e reprovou. Estrutura fixada pela spec: alturas 32/44/52px — o md=44 é decisão explícita do canônico ("md = 44px (não 40px)", alvo de toque WCAG) e coexiste declaradamente com a régua genérica --seed-control-md 40px da v1.14; reconciliar é decisão de canônico, apontada ao decisor. Guarda nova: gate G5 na paridade-tokens.py — presença nos dois gêmeos, fidelidade alias→valor (se o token-base mudar e o field não seguir, reprova — mata a fossilização da classe "defasado e invisível" do reinjeta-tokens) e, pela primeira vez, o espelho prefers-color-scheme é lido por um gate (antes um token esquecido lá era invisível). Placar: 85 PASS · 0 FAIL (64 anteriores + 21 do G5); G1 estrito contra o CSS v1.20 real: 0 sumidos, 0 alterados, +21 :root / +15 dark. Prova de consumo no Chrome real (contrato ambiente.mjs): 6 tokens consumidos por uma cobaia de scratchpad (altura, raio, fundo, borda, ajuda, erro) e medidos no render por getComputedStyle — 9 medições · 9 PASS nos dois temas. Divergências INTERNAS da §2.5 achadas na emissão (spec escrita antes da implementação, registradas para o gate, não corrigidas aqui): (a) o comentário do readonly-bg claro diz "sobre cinza-50" e o surface-sunken vigente é cinza-100 #E3EBF0 (o alias vence, o número 12,75:1 está defasado); (b) as medições dark citam "dark-default #141D23", que hoje é o surface-subtle (a página dark é #0B1419) — e a bancada banco-formfield.html carrega --seed-field-readonly-bg: #141D23 LITERAL no bloco dark (resolução da era da spec), divergindo do alias vigente surface-sunken = #0B1419; (c) a §2.5 l.400 (field-border = cinza-600) está SUPERSEDIDA pela CD-P2 e a tabela da §2.5 nunca recebeu a anotação — promover a nota no seed-componentes.md é da sessão principal. Nota de lacuna desta tabela: as linhas v1.13–v1.20 nunca foram escritas aqui (mesma classe da errata que a v1.11 registrou e restaurou para v1.7–v1.10); lacuna apontada ao decisor em 2026-08-25 — não restaurada nesta edição porque reconstrução histórica não é emissão de token.
§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.
texto inteiro da versão
§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.**
§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.
texto inteiro da versão
§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.
§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…
texto inteiro da versão
§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.
A ONDA 1 DA F8 FECHA COM SETE PEÇAS — §12.5 a §12.8, todas estável.
texto inteiro da versão
A ONDA 1 DA F8 FECHA COM SETE PEÇAS — §12.5 a §12.8, todas estável.§12.5 PASTA A4: capa de uma face, duas variantes que exercitam a matriz §5.1 (branco → logo principal; brand-deep → mono-negativo), logo ao centro pela §5.3; ⚠ NÃO é o arquivo de produção, porque a MR-P12 (margem de vinco) está aberta, e ⚠ NÃO é o F6-pasta-A4.html, que é evidência do gate do GRAFISMO em razão A4. §12.6 ENVELOPE (ofício 229×114 pela ABNT NBR 13314, saco A4 240×340 de mercado e declarado [não conferido]): ⭐ a regra que manda na peça não é da marca, é dos CORREIOS — 20 mm na base da frente são da máquina de triagem (guia CEPNet, ÁREA 4), e a serra para a 23 mm; três faces por formato, porque guia impressa em envelope é defeito de produção. §12.7 PROPOSTA: modelo PADRÃO e FLEXÍVEL fixado por ele (só material · só serviço · ambos; fotovoltaico e SEED Plus fora), DOIS documentos (técnica sem preço, comercial que não vale isolada), PRAZO como bloco próprio pelo art. 40 do CDC, e a moldura IMPORTADA do gen-timbrado.py em vez de copiada — o que se provou no mesmo dia, quando a correção PP-P2 propagou sozinha. §12.8 ASSINATURA DE E-MAIL, que NÃO é peça física e por isso não declara alvo-fisico: ela DERIVA do ea-assinatura.html com prova de derivação byte a byte, e a folha de gate mostra os quatro estados reais (com Montserrat, na pilha de reserva, com imagem bloqueada, a 320 px). ⚠ §12.4 ganha a regra 7: a evidência tem de ser FRESCA e isso se prova — quatro peças ficaram com o PNG de um commit anterior ao do próprio HTML, e nenhum instrumento olhava para essa relação.
A CAMADA FÍSICA GANHA AS TRÊS PRIMEIRAS PEÇAS DA F8 — §12.1, §12.2 e §12.3, todas estável, com gerador, mock renderizado e regeneração byte-idêntica.
texto inteiro da versão
A CAMADA FÍSICA GANHA AS TRÊS PRIMEIRAS PEÇAS DA F8 — §12.1, §12.2 e §12.3, todas estável, com gerador, mock renderizado e regeneração byte-idêntica.§12.1 PLACA DE OBRA [LEI] (Lei 5.194/66 art. 16 + Res. CONFEA 407/1996 — a lei fixa o CONTEÚDO e não a FORMA, e é isso que faz dela peça do DS): dois tamanhos, campos como placeholder, e ⚠ a MR-P11 morde aqui de um jeito não óbvio — o simbolo-principal.svg CARREGA o amarelo, então placa de canteiro usa o MONO-NEGATIVO; a violação estaria dentro do asset oficial. §12.2 TIMBRADO A4, cujo entregável é a ÁREA ÚTIL: 170 × 205 mm a partir de (20, 44), impressa no próprio arquivo para a proposta e o laudo LEREM em vez de redescobrir — o plano fixa que os três nascem dele. §12.3 COMPROVANTE DE PONTO (fecha a PT-P1): Portaria MTP 671/2021, REP-P, NSR, PAdES; a peça mais sensível do acervo em LGPD, porque a norma exige nome e PIS. §12.4 fixa o que passa a valer para toda peça física — incluindo a régua nova: ⭐ peça prova que consome token MEDINDO no navegador, nunca conferindo que a string está no arquivo (a guarda-peca-token.mjs nasce de um :root aninhado que fez uma peça inteira renderizar SEM NENHUM token, parecendo certa).
A DP-P7 FECHA no mesmo dia em que nasceu, por veredito ("opção B é melhor"): o coropleto passa a desenhar a fronteira que o DP4 obriga.
texto inteiro da versão
A DP-P7 FECHA no mesmo dia em que nasceu, por veredito ("opção B é melhor"): o coropleto passa a desenhar a fronteira que o DP4 obriga. O gen-dp.py deixou de tratar a variante coropleto no ramo dos municípios com obra (que no coropleto é vazio) e passou a desenhar em todos, como a completa. Medido depois: 1.348 fronteiras em #788F9D a 0,5 de espessura. A E19-b é o que permitiu o conserto sem FAIL. Nenhum hex muda, nenhuma decisão de cor muda — muda o que É DESENHADO.
Nasce a E19-b — exceção declarada por veredito na fronteira geográfica sobre o sem-medição.
texto inteiro da versão
Nasce a E19-b — exceção declarada por veredito na fronteira geográfica sobre o sem-medição. O porte da camada de validação (F7.7-P1) mediu o que a E19 não tinha medido: no claro a tinta adotada rende 2,80 sobre chart-no-data/surface-sunken (o par canonizado, sobre o contexto, segue 3,11 PASS). Veredito do Rafael, saída (a): aceitar como exceção declarada — a hachura é o segundo separador (1.4.11 cobra o par só quando ele é o ÚNICO identificador); mesmo veredito para cat-2-stroke × sunken (2,89), cujo segundo portador é a FORMA (E20). Candidatas medidas e descartadas: ci-600 (colide em valor com a hachura — estrutura E3) e ci-700 (dobra o peso do traço). NENHUM hex muda; a exceção vira categoria própria [exceção] no contraste-dp.py, com número impresso. Placar: 27 PASS · 0 FAIL · 3 exceções. A prova visual da decisão (mapa real, lupa 12× por captura) achou de carona a pendência DP-P7: a demo do coropleto não desenha fronteira nenhuma, contra o DP4 — e a E19-b é o que permite consertá-la sem criar FAIL.
§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.
§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.
§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.
§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).
§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.mjs14 · 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.
§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).
§82 CRESCE para 5 cláusulas (2026-08-22, VIGÉSIMA parte): nascem
texto inteiro da versão
§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.
§82 NOVA (2026-08-22, DÉCIMA OITAVA parte): nasce o
texto inteiro da versão
§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.
§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.mdv5.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.
§80 PASSA A estável (2026-08-22, DÉCIMA SEXTA parte): o
texto inteiro da versão
§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.mdv5.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].
§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.
A §12 ganha o INVENTÁRIO AMPLIADO e a §17 ganha a pendência MR-P11.
texto inteiro da versão
A §12 ganha o INVENTÁRIO AMPLIADO e a §17 ganha a pendência MR-P11. O inventário de peças físicas da §12 era o do Manual 2018 e não continha uma única peça específica de engenharia elétrica — faltava a classe regulada por lei e por norma. O levantamento completo (36 peças em 5 famílias, com fonte por peça regulada) passa a viver em inventario-pecas-ds.md v1.0, estado proposta. Peças reguladas identificadas: placa de obra (Lei nº 5.194/1966, Art. 16 + Resolução CONFEA nº 407/1996 — conteúdo obrigatório, forma livre, logo é peça legítima de DS) e sinalização de segurança elétrica (NR-10 item 10.10.1, sete situações; cores pela NR-26 → ABNT NBR 7195). Nasce a pendência MR-P11: o amarelo de marca #FAD61D colide em SIGNIFICADO com o amarelo normativo de advertência da NBR 7195 em ambiente industrial. Nenhum hex muda, nenhuma regra é revogada — o que entra é o registro do conflito e o apontamento do inventário.
Esclarecimento normativo na §7.4-c: o piso de 0,25 mm não pode ser violado pelo ARREDONDAMENTO.
texto inteiro da versão
Esclarecimento normativo na §7.4-c: o piso de 0,25 mm não pode ser violado pelo ARREDONDAMENTO. Ao aplicar o fator de escala, o menor peso arredonda para CIMA. Motivo medido: na pasta A4 (11,80952 px/mm) o arredondamento normal devolvia 0,24980 mm — 0,0002 mm abaixo do canon, e a guarda nova pegou. A §7.4-c passa a nomear DOIS instrumentos com papéis distintos: a guarda guarda-piso-mm.py (contrato MM1, alvo de pasta), que julga contra o piso do canon, e o diagnóstico mede-traco-mm.py, que compara com pisos de mercado. E fica escrito como uma peça declara que é impressa: <meta name="alvo-fisico"> no próprio artefato — nunca por nome de arquivo; peça sem a declaração sai [n/a] nomeado. Nenhum hex muda, nenhum vetor muda, nenhum teto muda.
Nasce a §7.4-d: a medida física do cartão é 90×50 mm, o padrão BRASILEIRO.
texto inteiro da versão
Nasce a §7.4-d: a medida física do cartão é 90×50 mm, o padrão BRASILEIRO. Veredito do Rafael, verbatim: "escolho B / qualquer ajuste é minimo se precisar fazer, e o desenho se ajusta hoje proporcionalmente". SUPERSEDE os 89×51 mm, que eram 3,5×2 polegadas — medida de EUA/Canadá que entrou como default de ferramenta, nunca como decisão de marca (não há registro de escolha). A §7.4 ganha o teto do novo formato (84px de 590 = 14,2%) e a linha antiga fica marcada como HERDADA, mantida só porque o acervo dos 7 formatos ainda está na razão 1,745. Medido: o piso de 0,25 mm da §7.4-c atravessa a troca de formato (0,250 mm nos três formatos testados), o verso reverso segue PASS, GR1 nas peças largas 15·0·0 e o acervo dos 7 formatos 21·0·0 — nenhuma regressão. Nenhum hex muda, nenhum vetor muda. Pendência nova MR-P10: SANGRIA — o verso é fundo cheio e nenhuma peça do projeto tem área além do corte.
Nasce a §7.4-c: PISO DE TRAÇO EM MILÍMETROS para peça impressa.
texto inteiro da versão
Nasce a §7.4-c: PISO DE TRAÇO EM MILÍMETROS para peça impressa. Veredito do Rafael, verbatim: "saída B — piso de 0,25 mm por ESCALA, e só para peça IMPRESSA". Piso 0,25 mm, aplicado por ESCALA (fator único em todos os planos), só em peça com alvo físico declarado. Motivo medido: a lei do traço da §7.4 é em px, logo o traço físico dependia da resolução de exportação; o verso do cartão passava o piso digital reverso por 0,004 mm (2% de margem) e agora tem 42%. Escala e não grampo porque grampo achata 4 pesos em 2 e a hierarquia de peso é uma das três condições do §7.1. Escopo declarado: peça de TELA fica de fora, e o marcador de seção (risco amarelo, 0,170 mm) fica intocado até veredito próprio. Nenhum hex muda; nenhuma regra da v5.0 é revogada.
A MR-P11 RESOLVE — saída (a) aprovada por veredito
texto inteiro da versão
A MR-P11 RESOLVE — saída (a) aprovada por veredito ("essa está aprovada, pode propagar"): o amarelo de marca não entra em peça instalada em ambiente com sinalização de segurança; nessas peças a assinatura é turquesa e branco; papelaria, escritório e digital mantêm o acento único sem restrição. Uma regra, uma fronteira. Propagação feita com verificação de conformidade contra o que foi construído depois da recomendação (ordem dele na mesma data): único amarelo novo desde então é o marcador da v5.12, elemento de papelaria/digital, fora do escopo — sem conflito. Desbloqueia as peças 2.9 (sinalização) e 3.2 (uniforme/EPI) do plano-producao-pecas.md; a placa de obra (1.1) já era desenhada sem amarelo e fica correta. Nenhum hex muda.
Os três usos INTERNOS do grafismo ganham geometria canônica e a pendência §17.3 FECHA.
texto inteiro da versão
Os três usos INTERNOS do grafismo ganham geometria canônica e a pendência §17.3 FECHA. Nasce 06-validacao/geradores/gen-detalhe.py (traçado extraído do gen-zero-formatos.pypor AST, nunca redigitado) e os 5 assets de referência em 03-assets/grafismos/. TEXTURA = a cena Z3 inteira a ≤10% — supersede as "2–4 linhas paralelas" da §7.6, por veredito: "vc tem que criar essas linhas igual as do rodapé que já estão aprovadas" (paralelismo é ritmo; serra é profundidade, §7.1); reclassificada como uso interno do SERRA-CENA. DIVISOR = a imagem do rodapé repetida emendada com corte no limite direito (verbatim: "a quantidade de cópias que precisar em sequência emendadas, e o que passar do limite do lado direito vc corta"); altura natural = largura/12,7; piso de leitura = §7.2 (regra já feita, escolhida por ele sobre um piso novo em px); sem teto; escala proporcional (§7.4). A EMENDA é a §7.3 aplicada: toque exato natural (a máscara de oclusão aprovada corta a ponta do FUNDO na crista da cópia seguinte) + mergulho da ponta esquerda abaixo da faixa, na zona que a moldura já cortava. MARCADOR = o risco aprovado fica intocado, inclusive o amarelo: quando o "apenas o turquesa" da Fase 2 colidiu com o §78.3-6, o veredito foi "prevalece o veredito que vc achou já estabelecido". Sangria por tipo de arquivo (§7.4-e): o transbordo natural de 6% cobre os 36px em todo formato impresso (cartão 63,78px · A4 148,80px) — nenhum desenho novo. Alternativas descartadas, cada uma com o número que a matou: 4 políticas paramétricas de amplitude (todas trocavam n=7 por 3 — redesenhavam a curva; a lei do §76.4 já respondia), duas linhas contínuas defasadas (só 17,5% de oclusão real — fita trançada), cadeia de arcos (fatiava o desenho), cena reduzida (o piso de traço da serra exige F≥58,64 — "profundidade custa altura"), cópias com profundidade alternada (linha listrada; §7.2 exclui oclusão do regime), descida-A construída (a natural já existia; construída abria talho ou nó). Lição de instrumento: a composição roda PURA sobre o desenho intocado — modificar fundo_v antes de compoe() desloca os retângulos de supressão de fragmento e o corte cai no meio do ar. Nenhum hex muda; nenhum traçado aprovado muda.
A §7.4-e ganha a regra do ARQUIVO SOB DEMANDA, por veredito dele: "sobre a producao, apenas o mock, quando for ter a producao de alguma peça especifica, ai sim trabalhamos o arquivo de producao para aquela demanda". O entregável padrão de toda peça passa a ser o MOCK; o arquivo com sangria (e a faca, quando houver dobra) só é feito quando existe a compra. Motivo: arquivo de produção feito antes da demanda envelhece — a gráfica escolhida pode pedir 5 mm em vez de 3, ou faca diferente, e o arquivo pronto vira arquivo errado com aparência de pronto. Nenhum valor muda; o que muda é quando o arquivo nasce.
Nasce a §7.4-e: SANGRIA de 3 mm e MARGEM DE SEGURANÇA de 3 mm em peça impressa
texto inteiro da versão
Nasce a §7.4-e: SANGRIA de 3 mm e MARGEM DE SEGURANÇA de 3 mm em peça impressa, por veredito dele: "a sangria vc tem que usar o que o mercado indica nas suas pesquisas. acredito que 3+3". E o MÉTODO entra como regra, também dele: "vc tem que deixar o desenho dentro da area real, e a parte da sangria vc cresce o desenho" — a composição é definida para a área de corte e não se mexe; a sangria é crescimento para fora. Consequência formal: passam a existir dois tipos de arquivo — GATE (tamanho do corte, é o que a GR1 mede e o que ele aprova) e PRODUÇÃO (corte + 3 mm) —, cada um declarando o próprio papel no artefato (<meta name="papel">, corte-px, sangria). Medido: a serra toca 3 bordas, logo sangria é obrigatória; e o conteúdo do cartão está a 4,24 mm do corte, folga de 1,24 mm contra a margem de 3 mm — o layout aprovado cabe sem mexer. Sangria em px arredonda para cima (36 px = 3,05 mm), mesma regra do piso de traço. A guarda MM1 ganha as cláusulas MM1-d e MM1-e. Fica aberta a MR-P12: peça com dobra/vinco tem margem própria e a pasta A4 com aba não existe como arquivo de produção. Nenhum hex muda, nenhum vetor muda, nenhuma composição muda.
RECONCILIAÇÃO DE ESTADO — o mapa mestre estava 12 dias e duas fases atrás do projeto, e o custo apareceu: uma sessão quase reabriu como "próximo brick" a formalização da F5, concluída 11 dias antes.
texto inteiro da versão
RECONCILIAÇÃO DE ESTADO — o mapa mestre estava 12 dias e duas fases atrás do projeto, e o custo apareceu: uma sessão quase reabriu como "próximo brick" a formalização da F5, concluída 11 dias antes. O que esta edição corrige, tudo ancorado em documento existente (nenhuma decisão nova): (a) errata de cabeçalho — dizia v1.9 · 2026-08-09 com o log já em v2.0; (b)F5 → FECHADA 6/6 (2026-08-11; seed-dataviz.md v0.20; marcos v1.8/v1.9 do ESTADO_ATUAL; a "pendência crítica" da v2.0 foi resolvida NO DIA SEGUINTE a ser escrita — §3c v1.5/v1.6 + gêmeos + spec DM1–DM11 + suite do DM — e este arquivo nunca registrou); (c)F6 → FECHADA 3/3 (marco v2.0, 2026-08-13/14: âncora vira turquesa; marco v2.1, 2026-08-15: shell consolidado, "tudo 100%"); (d)renumeração de fases de 2026-08-15 aplicada: F7 = COBERTURA (F7.1–F7.7 do mapa-cobertura-ds.md, com F7.1–F7.5 entregues), aplicações = F8, publicação/IA-GEO = F9 — supersede formal no §12 do marca-seed.md, que até hoje apontava para uma errata deste arquivo que ficou superada; (e) tabela de canônicos reescrita com as versões vigentes (tokens v1.20 · marca v5.13 · componentes v1.29 · composicao v2.1 · email v0.12 · dataviz v0.20 · mapa-cobertura v2.22), incluindo os canônicos que nasceram depois da v2.0 e nunca entraram nela; (f) estado da F8 registrado (grafismo ✅ 2026-08-22 · cartão ✅ · MR-P11 resolvida v5.13 · insumos da Onda 1 respondidos). Regra que a reconciliação deixa no cabeçalho: se este arquivo contradisser o ESTADO_ATUAL ou o changelog de um canônico, o mais recente vence e a reconciliação precede o uso. A causa raiz é a mesma classe do defeito do marco v1.4 (afirmado, nunca lido de volta): os fechamentos de fase atualizaram checkpoint, ESTADO_ATUAL e canônicos, mas nenhum rito exigia voltar AQUI — e o arquivo que o CLAUDE.md manda ler primeiro era o único que ninguém mantinha.
§79 NOVA (2026-08-21, DÉCIMA QUARTA parte): o teto do grafismo no
texto inteiro da versão
§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.mdv5.5 §7.4-b.
§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
texto inteiro da versão
§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.
§77 NOVA (2026-08-21, DÉCIMA SEGUNDA parte): o contrato
texto inteiro da versão
§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.
Nasce a §7.4-b: o teto do grafismo no TOPO é de LARGURA, não de altura.
texto inteiro da versão
Nasce a §7.4-b: o teto do grafismo no TOPO é de LARGURA, não de altura. Veredito do Rafael, verbatim: "o ponto é medir a aplicação na largura se atende ao desenho selecionado para o topo, a altura nao importa". Teto: F ≤ w / 6,5625, razão derivada da própria peça aprovada (w=420, F=64). SUPERSEDE a leitura de que o topo respondia a 15,24% da altura e só na razão 1:1 — aquele número passa a ser descrição da peça, não o teto, e peça larga deixa de precisar de veredito novo. Escopo declarado: só o topo; o rodapé segue com os tetos por formato da §7.4. Nenhum hex muda, nenhum vetor muda, nenhuma regra da v5.0 é revogada.
A §7 (Grafismo v2) é reescrita: nascem os DOIS REGIMES — DETALHE DE LINHA (o uso original, teto de 8%) e SERRA-CENA (3–4 planos com cruzamento, oclusão e hierarquia de peso, com tetos POR FORMATO).
texto inteiro da versão
A §7 (Grafismo v2) é reescrita: nascem os DOIS REGIMES — DETALHE DE LINHA (o uso original, teto de ~8%) e SERRA-CENA (3–4 planos com cruzamento, oclusão e hierarquia de peso, com tetos POR FORMATO). Nenhum hex muda, nenhum vetor muda, nenhuma regra da v5.0 é revogada — o teto de ~8% continua valendo para o regime de detalhe e o teto de área ≤10% continua valendo para os dois. Novidades: §7.1 a ORIGEM do desenho (as ondas são montanhas — dita pelo Rafael em 2026-08-20 e que não estava escrita em documento nenhum) mais as três condições de leitura de plano e o critério do MOVIMENTO · §7.2 os dois regimes, com o número que os separa (a serra precisa de ~15% da altura para LER como serra; abaixo disso ela não fica discreta, desaparece) · §7.3 os DOIS MODELOS de serra-cena com regras INDEPENDENTES — arcos no RODAPÉ (PADRÃO, toque exato) e montanha no TOPO (OPÇÃO, oclusão com folga), por veredito dele: "considere que o topo segue uma regra e o rodapé outra regra" · §7.4 a LEI DA ESCALA (forma constante em unidades de faixa, razão natural w/F = 12,7) e os tetos aprovados por formato (cartão 13,8% · banner 11,8% · capa 15,7% · topo 15,24%) · §7.5 a cor do grafismo só em stops da rampa canônica, com o precedente registrado do hex inventado que foi retirado por ordem dele (#0A6B60 → #006C62, ΔE76 = 1,03) e a REGRA §0-b · §7.6 tabela consolidada de usos · §7.7 os vetores da serra-cena existem como GERADORES, o que muda o estado da pendência §17.3. Especificação completa e medições em seed-componentes.md §76; registro da rodada em validacao/MANIFESTO.md §103.
§76 NOVA (2026-08-20/21, DECIMA PRIMEIRA parte): o GRAFISMO DA MARCA entra como componente — a
texto inteiro da versão
§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
v2.0 — A FUNDAÇÃO · 2026-08-15. Primeira edição que amplia o sistema em vez de refinar: CP2 vai de 6 a 7 tipos (SUP-7), nasce a camada de primitivos (SUP-8, CP25), o responsivo passa a ter duas camadas com fronteira normativa (SUP-9, CP26–CP28), arraste vira lei do sistema (SUP-10, CP30), relações de composição ganham contrato (CP29) e bancada×tela viram classes nomeadas (SUP-11, CP31). A tabela do §3 vai de 11 para 23 gabaritos. Origem: consolidado da F7.1 aprovado pelo Rafael em 2026-08-15 ("aprovo"), após 3 rodadas de pesquisa e o mapa-cobertura-ds.md v0.3. Histórico: v1.6 fechou a CP-P2 e a errata de cabeçalho; v1.5 fechou a CP-P1; v1.4 mudou o rail para peça; v1.0–v1.3 nasceram e consolidaram a Fase 2.
v1.1 · 2026-08-15 (v0.1 consolidado; v0.2 registra D1–D5; v0.3 fecha a D6; v0.4 corrige a errata da contagem de gabaritos e registra o estado da F7.1; v0.5 registra a ENTREGA da F7.2 e reclassifica os oito itens do eixo…
texto inteiro da versão
v1.1 · 2026-08-15 (v0.1 consolidado; v0.2 registra D1–D5; v0.3 fecha a D6; v0.4 corrige a errata da contagem de gabaritos e registra o estado da F7.1; v0.5 registra a ENTREGA da F7.2 e reclassifica os oito itens do eixo C que ela fecha; v0.6 acrescenta a §11 — sessão de 2026-08-17 tarde: E-P1, CD-P2 e CD-P3 fechadas, BT-P1/PS-P4 prontas para gate; v0.7 acrescenta a §12 — o gate das quatro bancadas é OBSERVADO, BT-P1/PS-P4/DH-P6 FECHAM, e seis linhas do eixo C são reclassificadas ou corrigidas por errata de versão medida; v0.8 acrescenta a §13 — nasce a auditoria transversal de consumidor (§69 do seed-componentes.md), a EA-P1 fecha, e a auditoria da SI-P4 e da IL-P2 acaba; v0.9 acrescenta a §14 — a GI2 vira guarda transversal, a BT-P3 fecha na forma supersedida, e o acervo deixa de estar sem defeito medido em aberto; v1.0 acrescenta a §15 — a CD-P7 ganha rito completo e veredito proposto, e a rodada de normas achou CD-P9; v1.1 acrescenta a §16 — BT-P6 fecha na causa, CD-P7 fecha por decisão, SI-P4/IL-P2/PS-P5 decididas, e nasce a MR-P1: o número 3,22 que sustenta a regra de branco sobre a marca nunca existiu)
A §3.6-b é promovida a estável pelo gate visual do Rafael sobre o seed-composicao-preview.html v0.1 (veredito G3: as seis posições da paleta de entidade aprovadas; veredito G4, na mesma sessão: marcador de "agora" em turquesa-600 fixo nos dois temas — registrado no CP24 do seed-composicao.md v1.1, terceiro membro da classe invariante de tema). Nenhum hex muda.
Nasce a §3.6-b — REGRA DE ADMISSÃO DE COR DE ENTIDADE (rascunho, gate visual pendente; SUP-5 do confronto de referências).
texto inteiro da versão
Nasce a §3.6-b — REGRA DE ADMISSÃO DE COR DE ENTIDADE (rascunho, gate visual pendente; SUP-5 do confronto de referências). Nenhum hex muda, nenhum vetor muda. Cor de entidade sai de paleta FECHADA (decisão Q1) e só é admitida passando 4,5:1 com uma de duas tintas declaradas (entity-ink-dark = cinza-900 · entity-ink-light = branco) — verificação estática na definição da paleta, nunca em render. Medição de 120 pares (6 famílias × 10 stops × 2 tintas): stops 50–400 admitem a tinta escura (pior 5,03) · stop 500 de QUALQUER família é inadmissível (zona de cruzamento, pior 4,30) · stops 600–900 admitem branco (pior 4,60). A paleta de 6 posições proposta e o consumo em composição vivem no seed-composicao.md §7 (novo 12º canônico da Fase 2). Precedente interno: a regra do amarelo do §3.6 já era tinta-por-cor.
(entrada retroativa, escrita na v1.11)Sub-bloco DP (mapas): adição de chart-geo-base (território de contexto) e chart-geo-boundary (fronteira de município, piso 3:1). Nenhum valor anterior muda. Nota na §3c; errata E19 relacionada (chart-grid tem o mesmo hex de no-data).
border-interactive — FECHA A SH-P1/PN-P5 (aberta desde o bloco 6A, 2026-08-11). Fronteira de componente interativo (SC 1.4.11): promoção do empréstimo declarado do cinza-500#788F9D a semântico, mesmo hex nos dois temas por medição (seis superfícies, 3,11–5,51, todas ≥3,0), slot dark declarado de propósito (coincidência medida, não invariância). Alternativa cinza-600 descartada com número (passa, mas mudaria cor renderizada aprovada em gate sem motivo). Gatilho: regra GI2 — a camada 2 foi editada pela CP-P3 (v1.11) e o Rafael mandou fechar na mesma janela. Gêmeos na MESMA edição; paridade-tokens.py52 · 0. O campo de busca do shell passa a consumir o semântico (preview v0.3). Racional completo na nota do §3.
Semânticos de COMPOSIÇÃO E CHROME (CP-P3 · SUP-6 em escopo mínimo) — nova subseção no §3.
texto inteiro da versão
Semânticos de COMPOSIÇÃO E CHROME (CP-P3 · SUP-6 em escopo mínimo) — nova subseção no §3. Entram, todos INVARIANTES de tema (sem redeclaração no bloco dark, de propósito): rail-background (gradiente turquesa-700 → turquesa-800 do CP20, adotado no gate G2; extremos medidos 6,32/9,37) · chrome-overlay-hover/-active (véu branco .12/.14 sobre a rampa da marca — alphas fixados depois de medição em COMPOSIÇÃO: rótulo branco sobre overlay composto em cada extremo = 4,88/6,82 e 4,68/6,50, todos ≥4,5) · entity-1…6 com tinta por posiçãoentity-N-ink (paleta fechada do CP23, gate G3; admissão CP22 medida: 5,11/5,30/5,63/9,37/6,43/6,68) · marker-now (turquesa-600 fixo, CP24/G4, ≥3,0 contra as cinco superfícies canônicas). Gêmeos JSON+CSS na MESMA edição (v1.11), paridade-tokens.py52 PASS · 0 FAIL (G1 sem regressão: nenhum valor anterior muda — é ADIÇÃO). Motivação: pendência CP-P3 do seed-composicao.md (regeneração do shell, que também fecha a errata E-CP-01 — o C1 deixava de consumir a categórica). Errata desta edição, fechada pela regra GI2: a tabela deste §9 estava parada na v1.6 — as entradas v1.7–v1.10 nunca foram escritas aqui (mesma classe da E-6C-01 do seed-componentes.md: quem bumpa o título escreve a entrada na mesma edição); restauradas abaixo a partir das notas inline deste arquivo e do MANIFESTO, marcadas como retroativas.
(entrada retroativa, escrita na v1.11)Normalização do focus-ring — o tema claro deixa de consumir o primitivo --seed-branco e passa ao semântico --seed-surface-page (o que o escuro já fazia); cor renderizada idêntica, muda a EXPRESSÃO. Achado veio de fora: paridade-previews.py acusou os previews, e eles estavam mais corretos que o canônico. Racional completo na nota do §3.
Registro da rodada do §48 Painel, sem mudança de paleta nem de logo — os 8 hex canônicos e os vetores seguem intocados.
texto inteiro da versão
Registro da rodada do §48 Painel, sem mudança de paleta nem de logo — os 8 hex canônicos e os vetores seguem intocados. Três seções novas: §3.5-b — a régua de ação foi CONFIRMADA; uma proposta de ação em azul-800 viveu num preview, conflitava com o §3.5 e foi retirada no mesmo dia, sem nunca chegar ao canônico (a camada de tokens sempre teve action-primary = #098475). §3.5-c — nasce a ÂNCORA DE ÊNFASE: uma por página, cromática e não escura, base turquesa-400 com tinta única turquesa-900, anel turquesa-600 e véu de luz a 35%; com as três alternativas reprovadas e seus números. §3.5-d — a TINTA DE TEXTO passa à família da marca, só o texto: bordas e superfícies ficam neutras e a página branca, como faz a referência medida, e porque esverdear a superfície roubaria o contraste de saturação da âncora (medido: 2,71 → 2,21). Valores e medições no seed-tokens.md v1.9.
(entrada retroativa, escrita na v1.11)SUPERSEDE DA TINTA DE TEXTO — text-primary/secondary/muted migram da família cinza para a família turquesa da marca nos dois temas (#0B3330/#2F5A54/#40706A no claro), com supersede formal da restrição "nenhum hex novo" (valores entram como SEMÂNTICOS). Fecha na mesma edição a errata do text-muted, que REPROVAVA (2,80–3,38 no claro). Racional, tabela e alternativas descartadas na nota do §3. Fecha o PN-P1.
(entrada retroativa, escrita na v1.11)chart-no-data-hatch: a tinta das linhas da hachura ganha token próprio (a E3 provou que papel de desenho sem token toma emprestado o de outro papel — era cat-5-stroke e virou violeta na v1.5). Medido contra o preenchimento: 3,93/3,84.
Promoção da categórica ESTENDIDA da §3c a estável, por "aprovo" explícito do Rafael sobre o lote de formalização da Fase 5 (o gate visual havia acontecido em 2026-08-10; o lote formalizou o que estava só nos previews). Nenhum valor de token muda nesta versão — é mudança de estado. Os gêmeos seed-tokens.json e seed-tokens.css acompanham para v1.6 para preservar a unidade md+json+css declarada no cabeçalho, seguindo o precedente da v1.4 (que também foi uma promoção de estado). Alternativa descartada: declarar o estado sem bump de versão, deixando os três em v1.5 — economizaria uma edição, mas criaria um arquivo cujo rótulo de versão não distingue "proposto" de "aprovado", que é exatamente a informação que o gate produz. Achado colateral registrado no seed-dataviz.md v0.6 §5 (errata E3): o supersede da categórica teve uma consequência não intencional — o cat-5, que na v1.0 era cinza-400 e servia de referência neutra no gráfico do alerta ET5, virou violeta na v1.5; referência de comparação não pode carregar cor de categoria viva, e o ET5 passa a consumir tinta neutra. É a classe de risco que qualquer troca de paleta cria: quem usava uma posição categórica como "neutro" perde o neutro em silêncio.
Categórica ESTENDIDA (§3c) — supersede formal da categórica v1.0 e da restrição "nenhum hex novo" do DT.
texto inteiro da versão
Categórica ESTENDIDA (§3c) — supersede formal da categórica v1.0 e da restrição "nenhum hex novo" do DT. Racional medido: a marca tem só 3 matizes livres para dado (turquesa ~170°, dourado/amarelo ~36–50° — mesma família —, azul ~192–197°; vermelho e cinza são reservados), então nascem 2 matizes exclusivos de dataviz que nunca aparecem em UI (padrão IBM Carbon/GitLab): magenta 332° (#CD518B/#E8A1C2) e violeta 268° (#966AC8/#BD9CE2), 6 hex novos no total, sem rampa no §2.1 de propósito. Sequência: turquesa → dourado → magenta → azul → violeta → azul-800 — 5 famílias, nenhuma repete antes da 6ª posição; ordem 2↔3 decidida no gate (dourado separa por peso os dois tons médios saturados). cat-1 light muda de turquesa-400 para turquesa-500 #00A192 (3.22 vs branco — o DG14 removeu o contorno e o fill passou a ter de passar 3:1 sozinho). Regra do dourado: permitido em área grande com rótulo direto; vetado como fill solitário sem rótulo (1.85 é insolúvel sem matar a cor da marca). O cinza sai da categórica (conflitava com a reserva de "sem dado"). Supersede DM3 no gauge: bandas viram intensidades de cinza (medido: as faixas coloridas distavam 1 ponto de claridade no light e 0 no dark); a barra de valor carrega a severidade; nenhum hex muda. Emenda GI2 cumprida: registrado que a rampa categórica ESCURA colapsa em claridade (75/75/71/71/67) por construção — é o que obriga o DG13. Achado da formalização: os previews aprovados embutiam 5 hex com deriva do canônico; a seção ancora nos stops reais do §2.1, com remedição provando veredito idêntico. Aprovação: gate visual do Rafael em 2026-08-10 ("tudo ok" sobre os previews v1.2/v0.7); leis de consumo no seed-dataviz.md v0.5. Gêmeos atualizados NA MESMA edição (v1.5), paridade-tokens.py com allowlist de supersede declarada.
Sub-bloco DI escrito — §4c, DI1–DI19 — em duas partes: DI-a estável e DI-b aberto.
texto inteiro da versão
Sub-bloco DI escrito — §4c, DI1–DI19 — em duas partes: DI-a estável e DI-b aberto. Consolidado aprovado pelo Rafael após 4 rodadas encadeadas (a 4ª disparada por regra: impresso é domínio novo para o projeto). O achado central não estava no roteiro: ao remedir a premissa represada no §5 ("o claro tem 7 pontos de espalhamento"), descobriu-se que o número era da categórica v1.0 com três séries; com as seis posições da v1.5 o pior par no modo claro mede 1 ponto (cat-1 × cat-4 e cat-3 × cat-5; claridades 56/75/49/55/50/27). O modo claro é seguro até três séries e colapsa a partir da quarta — fato de tela, anterior a qualquer discussão sobre papel. Daí o DI2, supersede formal do gatilho do DG13, que passa de "escuro ∩ grayscale" para grayscale ∩ (escuro OU ≥4 séries), e a errata E7 contra a redação anterior do §5. Por que o defeito sobreviveu dois sub-blocos: o contraste-dg.py percorre apenas cat1/cat2/cat3 — o detector estava recortado no lugar onde o defeito não mora; a pendência P8 do MANIFESTO.md deixa de ser higiene e passa a ser guarda ausente (reescrita especificada no DI18). Decisões de impresso: DI1 separa os dois destinos (laser de escritório = escopo; offset da gráfica, que exige PDF/X-1a em CMYK e declara variação de ±10% na cor dentro do mesmo lote = Fase 7) · DI4 proíbe informação de gráfico em background-color de CSS, porque print-color-adjust: exact é dica e a preferência do usuário no diálogo de impressão vence — com a inferência complementar (o fill de SVG sobrevive por ser conteúdo) declarada como não medida e transformada em teste da folha de prova · DI5 break-inside: avoid no <figure> inteiro · DI6 piso de traço a calibrar no papel · DI7 o DS não converte para CMYK (evita um segundo lugar onde a cor mora, contra o DF7) · DI8 PDF/A não adotado: nada no arcabouço CONFEA/CREA exige formato, o PDF/A é recomendação do CONARQ para o setor público, e o PDF/A-1 admite apenas assinatura simples — colidiria com o PAdES da ICP-Brasil, que é o que dá validade jurídica ao laudo assinado · DI9 fotocópia sem regra própria, com gatilho · DI10 fronteira com a F7. Guia da stack (DI11–DI17): a cadeia tem quatro saltos, não três — o fill do Recharts consome var(--color-CHAVE) gerado pelo ChartContainer, nunca --chart-N direto; sintaxe v3 sem hsl(); tema por [data-theme] e não pelo objeto theme do chartConfig; accessibilityLayer obrigatório e insuficiente (não cobre 1.1.1 nem 1.3.1 — o invólucro DG1 permanece por cima). DI19 decide o caminho do PNG do ET5: /email/v1/, porque a imutabilidade daquele caminho proíbe substituir arte, não acrescentar — e fecha a P4-b junto. DI-b (DI3) fica ABERTO por método: o veredito do gatilho da textura no papel só sai de prova impressa real, com protocolo de 7 itens fechado no §4c.3. Erratas novas: E7 (acima) e E8 (a §3c do seed-tokens.md cita o fundo dark #1C252B; o token real é #1D272D — remedido, deltas ≤0,24, nenhum veredito muda). Pendente deste lote: preview do DI, suíte, contraste-dg.py reescrito, PNG do ET5 e a folha de prova impressa.
Gate visual aprovado nos previews corrigidos — as v1.3/v0.8 passam a artefatos VIGENTES do DG e do DM. Mudança de estado apenas; nenhuma decisão de conteúdo. Fecha a janela de 2026-08-11, na qual a Fase 5 ganhou: a categórica ESTENDIDA estável (tokens v1.6), o redesenho DG14–DG17 formalizado, o sub-bloco DM escrito e promovido, a P6 aberta e fechada no mesmo dia, e as seis erratas achadas e corrigidas. Próximo sub-bloco: DI (impresso/PDF + integração da stack), com o contraste-dg.py a atualizar antes ou durante — ele ainda mede o DG11 e a paleta anterior à v1.5.
As seis erratas E1–E6 corrigidas nos previews, que passam a seed-dataviz-graficos-preview.htmlv1.3 e seed-dataviz-monitoramento-preview.htmlv0.8 — na entrega, ambos aguardando gate visual (aprovado no mesmo dia, v0.8), porque correção de artefato aprovado não se auto-aprova e três das mudanças são visíveis (E1 medidores com role="meter", E3 troca de cor do "esperado" e da hachura, E5 rótulo da pizza sai da fatia). Nenhuma decisão de spec muda nesta versão: as erratas eram divergências do PREVIEW em relação à spec, e a correção fez o artefato alcançar a regra que já existia. Sétimo ponto achado durante a correção, tratado dentro da E3: a hachura do chart-no-data desenhava as linhas em cat-5-stroke — mesma armadilha do ET5, no lugar mais sensível possível, já que "sem medição" é exatamente o que não pode parecer categoria; passou a chart-axis. Regra nova, generalizada a partir daí: posição categórica nunca serve de neutro — referência, contexto e ausência consomem token com papel declarado (chart-no-data, chart-grid, chart-axis, cinza de contexto do DG17), porque cat-N pode trocar de cor em qualquer supersede de paleta, como trocou na v1.5. Validação: DG 163 PASS · 0 FAIL; DM 105 PASS · 0 FAIL · 0 FAIL DOCUMENTADO (a suite ganhou v2.1 com dois falsos negativos corrigidos: exigia aria-valuenow do medidor SEM leitura, que legitimamente não o tem, e não resolvia o alias novo do "esperado").
PROMOÇÃO: o sub-bloco DM passa de spec escrita a estável
texto inteiro da versão
PROMOÇÃO: o sub-bloco DM passa de spec escrita a estável, por "aprovo" explícito do Rafael sobre o lote de formalização. A Fase 5 fica com DF, DT, DG e DM concluídos; restam DP e DI. Nenhuma decisão de conteúdo mudou nesta versão — é mudança de ESTADO mais os registros que a promoção obriga. Pendência P6 FECHADA no mesmo dia em que nasceu: os dois previews aprovados foram reanexados e conferidos por MD5 2/2 (gráficos v1.2 8d1930…0fbf · monitoramento v0.7 f146c8…334c), e as suites passaram de placar reproduzido a placar executado contra os artefatos reais — suite-dataviz-dg.mjs163 PASS · 0 FAIL e suite-dataviz-dm.mjsv2: 85 PASS · 0 FAIL · 6 FAIL DOCUMENTADO. Seis erratas E1–E6 medidas (§5), todas nascidas de rodar a automação contra o artefato depois do gate humano: role="meter" ausente no preview do DM (E1 — o DM4 não chegou a ser exercido no gate), sparkline a 1,6px contra os 2px que o próprio arquivo declara (E2), ET5 "esperado" em cat-5 que a v1.5 transformou em violeta (E3 — primeira consequência colateral medida de um supersede de paleta), deriva de 4 primitivos nos dois previews (E4 — nenhum veredito muda, deltas ≤1 ponto, mas prova que o bloco de tokens foi digitado e não copiado), rótulo interno da pizza a 4,30 (E5) e os dois arquivos declarando "v0.1" no próprio título (E6 — a identificação positiva por leitura do MANIFESTO §3.1 não funciona neles). Lição de método registrada na suite: a v1 da suite-dataviz-dm.mjs, escrita contra uma reconstrução enquanto o artefato estava ausente, produziu 26 FAIL no artefato real — 23 eram premissa da suite (ela codificava os NOMES da reconstrução como se fossem spec) e só 3 eram desvio genuíno. Suite escrita contra reconstrução testa a reconstrução; a v2 testa a mesma spec pelo COMPORTAMENTO (o alias resolve para cinza? o gatilho exige as duas condições?), não pelo seletor.
Lote de formalização da F5 — o material aprovado nos gates de 2026-08-10 sai da conversa e entra no canônico.
texto inteiro da versão
Lote de formalização da F5 — o material aprovado nos gates de 2026-08-10 sai da conversa e entra no canônico. (1) Redesenho DG14–DG17 (§4.6, "gráfico de produto"): DG14 supersede o DG11 (zero contorno; vão de 2px como espaço negativo; possível porque a categórica v1.5 passa 3:1 sozinha); DG15 geometria orgânica (rx=3 universal, pílula em ranking, curva monótona Fritsch–Carlson 2px, gradiente 22%→0) + guarda DG15b (raio consistente — defeito achado pelo olho do Rafael, não pela regex); DG16 palco mínimo (≤3 gridlines, sem linha de eixo, número protagonista, badge-pílula, ponto de status com rótulo); DG17 destaque×contexto. Duas leis transversais: hierarquia de traço (2/1/0,5px + meta 1,5px como exceção + vector-effect: non-scaling-stroke obrigatório — viewBox escalam 0,66×–12,4× medidos) e consumo da categórica estendida (5 famílias distintas até 5 séries; 6ª posição única exceção; teto 6; regra do dourado; ordem 2↔3 decidida no gate pelo peso do dourado). (2) Sub-bloco DM escrito por extenso (§4b, DM1–DM11): bullet graph canônico (Few/Cleveland–McGill), anatomia de 6 partes, DM3 papéis invertidos (supersede na §3c), role="meter"+aria-valuetext via useMeter (descartados <meter> nativo e progressbar), sparkline de Tufte com contrato decorativo DM6, DM7 rótulo de estado sempre visível, DM8 fecha o slot ET5 (PNG @2x 560px no R2), DM9 no-data nunca vira zero, DM11 textura de banda no gatilho do DG13 — com o registro de que o piso de 6 pontos não transfere de contexto (bandas a 9/8/17 seguiam indistintas; emenda no DG13). 4 defeitos de produção viraram guarda (variáveis órfãs, DM7 ausente, overflow de viewBox detectável só por getBBox em navegador real, acentos). Estado do DM: aguardando aprovo do lote. (3) Emendas: DG5-b remedido para a paleta v1.5 (interno só em cat-2/cat-6; errata do "45%" latente no preview), DG10-b com racional supersedido e teto mantido, DG12 restrito ao rótulo + exceção do DM. (4) Achados da formalização: previews aprovados AUSENTES do Drive (alvos MD5 registrados; pendência P6) · deriva de 5 hex nos previews vs canônico (ancoragem nos stops reais, veredito idêntico) · GI2 do colapso dark CUMPRIDA na §3c v1.5. Suite do DG na versão final: 163 verificações.
GATE VISUAL DO PREVIEW v0.4 APROVADO — o sub-bloco DP fica SEM NENHUMA PENDÊNCIA ABERTA, e com isso a Fase 5 fecha sem ponta solta.
texto inteiro da versão
GATE VISUAL DO PREVIEW v0.4 APROVADO — o sub-bloco DP fica SEM NENHUMA PENDÊNCIA ABERTA, e com isso a Fase 5 fecha sem ponta solta. Nenhuma decisão de conteúdo muda: é mudança de estado mais o registro que a aprovação obriga. As seis pendências nominais do DP, todas fechadas no mesmo dia em que o sub-bloco nasceu: DP-P1 (token do território e da fronteira — fechou com dois tokens novos e as erratas E19/E20) · DP-P2 (largura mínima da variante malha completa — medida agora: ≥ 640px) · DP-P3 (piso de claridade do polígono — fecha como decisão, com o piso declarado NÃO herdável e transferido ao DP14) · DP-P4 (paralelos da projeção) · DP-P5 (tolerância de simplificação, que superseiu o DP9) · DP-P6 (edição da Malha Municipal Digital). Placar final das quatro camadas com a geografia real: jsdom 82 PASS · 0 FAIL · render em Chrome real 22 PASS · 0 FAIL · contraste 27 PASS com 23 candidatas reprovadas de propósito · gate visual aprovado. Nota de fronteira sobre a DP-P3, para que ninguém a leia como resolvida por decreto: o piso de claridade para polígono de município não foi calibrado — foi declarado como não herdável e adiado até existir um coropleto com dado real, porque calibrar contra exemplo inventado produz o verde que impede a procura. A pendência fecha como decisão, não como medição, e isso está escrito no §4d.6.
A MALHA REAL DO IBGE ENTRA E FECHA TRÊS PENDÊNCIAS (DP-P4, DP-P5, DP-P6). O preview deixa de usar malha sintética.
texto inteiro da versão
A MALHA REAL DO IBGE ENTRA E FECHA TRÊS PENDÊNCIAS (DP-P4, DP-P5, DP-P6). O preview deixa de usar malha sintética. Fonte: Malha Municipal Digital do IBGE, edição 2025, baixada do portal oficial pelo Rafael em três pacotes Shapefile (MG, ES, BA), SIRGAS 2000, UTF-8 — 1.348 municípios, 4.251.625 vértices, 135,9 MB de GeoJSON bruto. Registro de fonte descartada: antes disso a malha veio do espelho tbrugz/geodata-br (GitHub, CC0), porque o domínio do IBGE não é acessível da máquina de execução; as contagens batiam, mas os vértices não — 143.319 contra 4.251.625. O espelho já era ~30× simplificado e não declarava. DP15 (novo, §4d.14b): as ilhas oceânicas de Vitória saem do desenho, não do dado — a extensão de longitude cai de 22,20° para 13,70°, evitando 40% de figura em oceano vazio. DP-P4 fechada: paralelos -20,52° / -10,93° calculados da extensão real. DP-P5 fechada, e o resultado SUPERSEDIU o DP9: um único asset a 2%, no lugar de dois níveis — a diferença medida entre os níveis era de 192 KB, e duas fontes da mesma geometria por isso viola o DF7. Piso declarado: erro de área p99 ≤ 2% (medido 1,78%). DP-P6 fechada: edição 2025, no nome do asset. Instrumento novo: erro de área por município medido na projeção real, contra a malha bruta — é a métrica certa porque num coropleto a área desenhada é o que compara os dados. Caso-limite achado sozinho: Santa Cruz de Minas (MG), 3,565 km², erra 4,2% a 2% e 20,5% a 1%. Preview a v0.4, com a malha oficial renderizada pela cadeia REAL do DP2 (d3-geo + topojson-client). Suíte a 82 PASS · 0 FAIL (era 77) e render 22 PASS · 0 FAIL. Três defeitos achados na inspeção das capturas, nenhum visto pela automação: (1) a tabela do fallback transbordava 8px a 360px — corrigida com o contêiner rolável nomeado e focável do Bloco 6; (2) a descrição do DP1 ainda dizia "malha sintética" depois da troca — artefato mentindo sobre si mesmo, a classe da errata E6; (3) dois códigos IBGE digitados de memória apontavam para municípios errados (Vitória virou Cariacica, Cachoeiro virou São Mateus): o preview ficava correto e dizendo outra coisa. Regra que sai daqui:identificador digitado de cabeça é a mesma classe de defeito que a regra "geometria é calculada, nunca digitada" já cobria — a seleção passou a ser resolvida por nome contra a própria malha, com asserção.
PROMOÇÃO: o sub-bloco DP passa a estável e A FASE 5 ESTÁ FECHADA.
texto inteiro da versão
PROMOÇÃO: o sub-bloco DP passa a estável e A FASE 5 ESTÁ FECHADA. Os seis sub-blocos — DF, DT, DG, DM, DI e DP — são todos estável, e o marco v1.6 é disparado. Nenhuma decisão de conteúdo muda nesta versão: é mudança de ESTADO mais o registro que a promoção obriga. Placar final das quatro camadas de validação do DP: jsdom 77 PASS · 0 FAIL · render em Chrome real 22 PASS · 0 FAIL · contraste 27 PASS com 23 candidatas reprovadas de propósito (é a evidência que fundamenta os dois tokens novos) · gate visual aprovado. Fronteira do que o gate cobriu: o Rafael inspecionou o preview v0.2 e respondeu os cinco pontos do protocolo; a v0.3 difere em um único ponto (a tinta da contagem, corrigida pelo DG12) e foi aprovada sobre relato de medição e de inspeção de captura. Registrado porque fato e inferência se declaram separados. Pendências que o DP leva consigo para a Fase 6, todas declaradas: DP-P2 (largura mínima da variante malha completa) · DP-P3 (piso de claridade do polígono de município, que só fecha com coropleto de dado real) · DP-P4 (paralelos da projeção para o recorte MG-ES-BA) · DP-P5 (tolerância de simplificação) · DP-P6 (ano da Malha Municipal Digital do IBGE). O preview usa malha SINTÉTICA declarada enquanto a DP-P6 não fecha. Item obrigatório do marco, executado: a AUDITORIA DE IMPACTO DAS LACUNAS do §6 do estudo-viver-de-ia.md, agora na §6b daquele arquivo (v1.3). Veredito: nenhuma lacuna exige supersede em algo estável; e uma das cinco lacunas vermelhas não existia — a "camada de movimento" está nos gêmeos desde a camada de primitivos (errata E-EST1).
A camada de RENDER do sub-bloco DP foi executada — e ela havia sido PULADA em silêncio nos lotes anteriores.
texto inteiro da versão
A camada de RENDER do sub-bloco DP foi executada — e ela havia sido PULADA em silêncio nos lotes anteriores. Cobrança do Rafael, correta: "você precisa rodar o teste e enxergar essas coisas antes de eu testar". Fato registrado sem atenuante: nos lotes das v0.14–v0.16 eu verifiquei que não havia navegador headless na máquina, não avisei, e segui — de modo que a régua de quatro camadas (jsdom · render · contraste · gate humano) rodou com três. O defeito das 360px morava exatamente na camada ausente. Ambiente resolvido com o binário de Chromium empacotado em npm (@sparticuz/chromium + puppeteer-core), já que o download normal do Chrome não passa pela rede desta máquina. Nasce a render-dp.mjs: 22 PASS · 0 FAIL, medindo o que jsdom não vê — colapso real da grade em cada largura (R1), equivalência entre o controle de largura e o redimensionamento real da janela (R2, a regra do §4d.15), estouro de viewBox por getBBox() em navegador real (R3), espessura RENDERIZADA das fronteiras com o viewBox escalando 0,82× (R4, prova do non-scaling-stroke) e ausência de transbordo horizontal (R5). O defeito que só a inspeção das capturas achou, e que é violação de regra existente: a contagem de agrupamento do DP11 estava pintada em branco fixo. O DG12 determina há dois sub-blocos que tinta sobre dado não segue o tema e consome cinza-900 nos dois modos, porque o fill categórico é claro nos dois modos. Medido: branco contra os fills do tema escuro dá 1,83 · 2,04 · 2,05; cinza-900 dá 7,57 · 6,80 · 6,77 no escuro e 4,30 · 3,40 · 4,17 no claro. Preview a v0.3, guardas DP11-02b/c/d na suíte (77 PASS · 0 FAIL, era 74); prova de que são reais: contra o preview v0.2, reprovam em 2. Classe do defeito:regra do sistema não aplicada em consumidor novo — o DG12 nasceu para rótulo interno de barra e fatia, e o marcador de mapa é rótulo interno também; ninguém fez a ligação. Parente direto da E19, que herdou de outro consumidor sem remedir. Lição de método, e é a mais cara deste sub-bloco:camada de validação indisponível não é camada dispensável — é pendência a declarar. Pular em silêncio produz o mesmo verde de quando tudo passou. Nenhuma decisão de spec mudou nesta versão.
O gate visual do Rafael achou um defeito que 68 verificações automatizadas não viam — e o defeito era no INSTRUMENTO, não no desenho.
texto inteiro da versão
O gate visual do Rafael achou um defeito que 68 verificações automatizadas não viam — e o defeito era no INSTRUMENTO, não no desenho. Ele testou os cinco pontos do gate no preview v0.1 e mandou uma captura da tela a 360px: as duas figuras do DP5 apareciam lado a lado, com cerca de 170px cada, em vez de empilhadas. Causa medida: o controle de largura da barra mudava o max-width do contêiner, enquanto a regra que empilha a grade era uma @media ancorada na largura da janela — que continuava larga. Consequência dura: a dimensão "largura" da matriz de render nunca foi exercida de verdade; o que aparecia na tela ao escolher "360" era uma célula que não existe na matriz. Regra nova, registrada no §4d.15 e mais geral que o sub-bloco:simular uma dimensão da matriz só vale se a simulação dirigir as MESMAS regras que a realidade dirige.Correção: preview a v0.2, com o contêiner virando container de consulta (container-type: inline-size) e as regras de layout passando a @container — assim o controle e a janela real disparam o mesmo conjunto de regras. Guardas novas LARG-01…LARG-05 na suíte; prova de que são reais: contra o preview v0.1, reprovam em 3. Segunda correção de âncora no mesmo lote: a verificação HIG-03 procurava a string literal preview v0.1 no título — guarda que quebra a cada revisão e que, pior, convida a mentir de volta, que é exatamente a errata E6. Passou a exigir que o título declare alguma versão e que ela seja a mesma do <h1>. Placar da suíte: 74 PASS · 0 FAIL (era 68). O que o episódio prova, e é o motivo de o gate visual ser estruturalmente não-opcional: nenhuma das verificações automatizadas via o defeito, porque jsdom não resolve layout e a suíte conferia a presença da regra, não quem a dispara. Nenhuma decisão de spec do DP mudou nesta versão.
A medição do DP mudou DUAS decisões que já haviam sido aprovadas no gate — e fechou a pendência DP-P1 no mesmo dia em que ela nasceu.
texto inteiro da versão
A medição do DP mudou DUAS decisões que já haviam sido aprovadas no gate — e fechou a pendência DP-P1 no mesmo dia em que ela nasceu. Nasce o contraste-dp.py v1, instrumento do sub-bloco DP, que extrai os hex do seed-tokens.css em vez de digitá-los (lição das erratas E4/E16) e mede seis famílias de pares nos dois temas: colisões de valor entre papéis, território × fronteira, território × sem-medição, hachura, marcador × território e marcadores entre si em escala de cinza. Achado 1, que é um fato do sistema e não do mapa:chart-grid e chart-no-datatêm o mesmo hex nos dois temas (#E3EBF0 light, #38464F dark) — o que torna a condição (b) da §3c ("fronteira sustentada por chart-grid") impossível de cumprir sobre uma célula sem medição, com razão 1,00. O defeito é antigo e nunca apareceu porque no heatmap a célula no-data é hachurada e as vizinhas são sequenciais saturadas: a fronteira nunca precisava separar dois cinzas. Num mapa, separar dois cinzas é o caso normal. Errata E19 e supersede no §6. Achado 2: no tema escuro chart-axis é o mesmo hex do chart-no-data-hatch (#90A6B3) — logo emprestar chart-axis para a fronteira repetiria a estrutura da E3. Daí dois tokens novos na v1.8 dos três gêmeos: chart-geo-base (território de contexto) e chart-geo-boundary (fronteira), ambos com valor idêntico a tokens existentes de propósito — o que muda não é a cor, é a responsabilidade de mantê-la. Achado 3, o mais incômodo: o DP10 dizia "cor até 3 categorias, forma acima disso", e descartava por raciocínio a redundância cor+forma desde a primeira. A medição inverte: no dark os três pares de marcador medem 3,6 · 3,7 · 0,2 pontos de claridade e no light o par cat-1 × cat-4 mede 0,9, todos abaixo do piso de 6. A forma passa a ser o portador permanente da categoria e a cor vira redundância (errata E20). O dourado sai da paleta de marcador por aplicação da regra do dourado que já existia (fill pequeno e solitário), e o marcador ganha contorno em cat-N-stroke, cuja própria descrição nos gêmeos nomeia o caso: "marcador pequeno — o pior caso do 1.4.11". Lição de método, terceira ocorrência registrada:não diagnostique por raciocínio, meça — aqui o raciocínio não errou um diagnóstico, errou uma decisão de design aprovada, e o que a pegou foi a pendência ter sido declarada em vez de resolvida por escolha. Gêmeos a v1.8 (adição pura: nenhum valor anterior muda) e a guarda paridade-tokens.py estendida para os dois tokens novos — 52 PASS · 0 FAIL, e prova de que a guarda nova é real: rodada contra o CSS v1.7, reprova em 4. Errata E8 CORRIGIDA de passagem na mesma edição, pela regra GI2: a §3c citava o fundo dark #1C252B, e o token é #1D272D. Pendente deste lote: preview do DP construído sobre a spec corrigida, suíte, gate visual e a edição do MANIFESTO.md.
Spec do sub-bloco DP — mapas de atuação MG-ES-BA — em §4d, DP1–DP14. Com ela, os SEIS sub-blocos da Fase 5 existem; falta o gate visual do DP para fechar a fase.
texto inteiro da versão
Spec do sub-bloco DP — mapas de atuação MG-ES-BA — em §4d, DP1–DP14. Com ela, os SEIS sub-blocos da Fase 5 existem; falta o gate visual do DP para fechar a fase. Consolidado aprovado pelo Rafael após 3 rodadas encadeadas de pesquisa (R1 canon interno · R2 mercado/stack de mapa em React · R3 normas: IBGE, projeção cartográfica, acessibilidade de mapa). Escopo decidido em briefing ANTES da pesquisa — pontos e não coropleto, três destinos (impresso, ERP, site), figura fixa, três níveis geográficos, sem identificação de cliente em peça externa, sem fonte de malha preexistente na empresa. Registro de método: a primeira formulação da pergunta (d) foi respondida com uma correção do Rafael — a proposta de dois níveis (estado + ponto) foi recusada com "eu tenho que ter todos os municípios", e a redação da proposta induzia a leitura errada de que municípios sem obra sumiriam do mapa; a decisão final (DP5) mantém o território sempre inteiro e torna seletiva apenas a linha de fronteira. Três achados da R1 mudaram o desenho: (1) a §3c do seed-tokens.mdjá nomeia "mapa coroplético" como consumidor da escala sequencial e já traz as três condições obrigatórias da isenção do WCAG 1.4.11 — entre elas fronteira por chart-grid, o que dispensa o supersede do DG14 que eu previa e o reduz a precisão de escopo (DP4); (2) o traço de 0,5px seguia sem consumidor e a fronteira municipal da variante malha completa é o primeiro (DP5); (3) o DF2 tem uma lacuna: declara shadcn Chart sobre Recharts como consumidor canônico web, e Recharts não desenha mapa — emenda formal no §6. Achado da R2/R3: projeção equivalente (Albers) é obrigatória e Mercator é vetado, porque nosso recorte vai de ~-8° a ~-22° de latitude e a deformação de área seria sistemática e direcional, inflando a Bahia contra Minas — mentira visual da empresa sobre si mesma. Achado que inventa vocabulário, o único do sub-bloco: o DI2 manda texturizar, mas textura não cabe num marcador de 8–12px; em mapa a distinção em escala de cinza passa a ser por forma (círculo/quadrado/triângulo), com teto de 3 categorias — menor que o teto de 6 da categórica, e portanto um mapa da SEED não consegue mostrar os cinco pilares como cinco marcadores legíveis em mono. Advertências do IBGE que entram no canônico (DP8): os limites da Malha Municipal Digital são aproximados, o IBGE não tem atribuição legal de demarcação, e a malha é republicada anualmente — logo o mapa da SEED não serve como peça de definição de limite territorial, e o asset declara o ano. Matriz de render ganha dimensão nova: largura de renderização (360 · 768 · 1200), cruzada com tema × grayscale × impressão. Seis pendências nominais nascem declaradas (DP-P1…DP-P6, §4d.16), nenhuma bloqueando a spec e todas bloqueando a promoção a estável. Pendente deste lote: preview do DP, suíte, gate visual do Rafael e a edição do MANIFESTO.md que ancora este arquivo e os artefatos do DP.
SUPERSEDE do DM8: o e-mail de alerta de geração não leva gráfico.
texto inteiro da versão
SUPERSEDE do DM8: o e-mail de alerta de geração não leva gráfico. Decisão do Rafael no gate de produção do asset, contra o desenho que eu havia especificado e produzido. Racional, que é mais forte que o original: o PNG hospedado no R2 é arquivo único servido a todos os disparos, logo os números nele são ilustrativos — o cliente cujo desvio real é de 6% receberia um e-mail com imagem mostrando 18%, contradizendo o texto ao lado. Quem vê isso não conclui "a imagem é genérica", conclui que o sistema erra; e um alerta existe precisamente para ser confiável. Regra vigente: o e-mail avisa, o sistema mostra — dado real vive onde o cliente entra para ver. O slot ET5 sai da dataviz e volta ao seed-email.md SEM REGRA NOVA: o EC5 já determina ícone raster sob demanda, rasterizado do SVG normalizado quando um template o pede, em /email/v1/icones/; um template de alerta pedindo glifo de alerta é o caso previsto, e o DM8 havia contornado essa lei ao especificar um PNG de conteúdo. Descartado: gráfico gerado por usina no envio — não por mérito, mas por domínio, já que o DM10 pôs comportamento dependente de dado vivo no produto. Registro material: o PNG seed-email-et5-grafico@2x.png (1120×520 @2x, 28.441 B, MD5 f2ad29b3a8075da85c67f157399711fd) chegou a ser produzido, com fonte SVG e gerador, e foi descartado sem subir ao R2 — fica anotado que existiu para que ninguém o ache num diretório de trabalho e o suba supondo propagação pendente. O DI19 permanece válido quanto ao caminho e muda de objeto. Lição de método: a spec do DM8 foi escrita sem perguntar de quem é o dado que a peça mostra — a pergunta que o gate fez em dez segundos e que teria evitado a produção inteira.
DI-b FECHADO por prova impressa física. O sub-bloco DI está completo e a Fase 5 fica a um sub-bloco do marco.
texto inteiro da versão
DI-b FECHADO por prova impressa física. O sub-bloco DI está completo e a Fase 5 fica a um sub-bloco do marco. (1) Produzida a folha de prova de 7 itens (seed-dataviz-di-prova-impressa.pdf, A4 retrato com orientação declarada em CSS, 3 páginas, questionário de 6 perguntas na última) e impressa pelo Rafael duas vezes na mesma impressora física, em cor e em escala de cinza pelo driver. (2) Veredito do DI3: o modo de impressão NÃO entra no gatilho da textura, porque não precisa. Em cor as 6 séries se distinguem — textura ali seria o ruído que derrubou o DG11. Em mono, que é grayscale por definição, o gatilho do DI2 já dispara com 6 séries. Descartado: acrescentar "impresso" como terceira condição — redundante e pior, porque regra duplicada é o que deriva quando uma das duas é editada e a outra não, a classe de defeito das erratas E12/E14/E16. O item 1 da folha era controle, não caso de uso: 6 séries sem textura em cinza é situação que a regra vigente já proíbe, e falhou como previsto. A prova validou a regra existente no meio em que ela nunca havia sido testada, em vez de pedir regra nova. (3) Os dois pares que colapsaram a olho são exatamente os dois previstos: "Fora de ponta" ≈ "Bombeamento" (cat-1 × cat-4, 56% × 55%) e "Reservado" ≈ "Iluminação" (cat-3 × cat-5, 49% × 50%), ambos a 1 ponto — zero falso positivo e zero falso negativo em 15 pares. (4) SUPERSEDE da regra do piso, e é o achado mais valioso do sub-bloco: ela dizia que o piso decide só no contexto em que foi calibrado, e foi lida como meio novo exige calibração nova — foi por isso que o DI3 nasceu prevendo piso próprio para papel. A variável nunca foi o meio, foi a FORMA. No DM11 eram bandas finas de medidor a 9/8/17 pontos, indistinguíveis na tela; aqui são barras altas adjacentes, a forma em que o piso foi calibrado, e o instrumento acertou no papel. Forma diferente + mesmo meio → erra; mesma forma + meio diferente → acerta. Regra vigente: o piso é calibrado por forma e vale para aquela forma em qualquer meio; forma nova (banda, fatia fina, célula de heatmap) exige recalibração por gate mesmo no meio de sempre. (5) As 6 texturas se distinguem no papel em escala de cinza — o vocabulário estendido a 6 posições da v0.10 sobrevive ao impresso. (6) DI6 fechado sem piso próprio: as quatro espessuras (2 · 1,5 · 1 · 0,5px) saíram distintas na impressão física, nenhuma sumiu nem engordou; a hierarquia de traço vale igual no papel. (7) Fronteira do instrumento, por crítica do Rafael: a régua mede sobrevivência, não adequação — espessura isolada com rótulo abstrato responde "a impressora deposita?" e não "é adequada aqui?"; a segunda pergunta exigiria as espessuras aplicadas no gráfico. Achado colateral: o piso de 0,5px não tem consumidor — a grade do preview do DG está toda em 1px, e valor que existe na lei sem ser exercido deriva; a verificar na Fase 6. Pendente do lote: PNG @2x do ET5 e a edição do MANIFESTO que ancora a folha de prova, o preview do DI v0.3, a suíte do DI e este arquivo.
O DI4 sai de inferência para fato medido, e nasce a suíte do sub-bloco DI.
texto inteiro da versão
O DI4 sai de inferência para fato medido, e nasce a suíte do sub-bloco DI. (1) Gate de impressão do Rafael (Chrome, "Salvar como PDF", A4): a matriz de quatro células do preview do DI devolveu C sumiu · D sobreviveu com "Gráficos de segundo plano" desmarcado — background-color de CSS desaparece quando nada o protege, fill de SVG sobrevive por ser conteúdo desenhado. Regra do DI4 provada como escrita (§4c.4). Segundo achado não previsto: a célula A sobreviveu, ou seja, o Chrome honra print-color-adjust: exact mesmo contra a preferência desmarcada — há duas camadas de proteção e elas não valem o mesmo; a regra dura do DS continua sendo a estrutural, porque a de CSS é documentadamente uma dica. Fronteira declarada: um navegador, um destino; Firefox e driver físico não medidos. (2) Erro de método registrado: a v0.1 do preview tinha duas células e não isolava a variável, porque a folha de impressão declara exact num seletor universal e protegia os dois braços do próprio teste — a primeira rodada devolveu um resultado verdadeiro que respondia outra pergunta. (3) Preview do DI chega à v0.3 e a suite-dataviz-di.mjs nasce com 32 verificações, cobrindo DI4, DI5, DI6, o modo de impressão forçado ao claro, as cinco partes do DG1 no exemplo, o guia de integração e a higiene de tokens; rodada contra a v0.1, reprova em 4 — as guardas são reais. (4) Errata E17:vector-effect não é herdada (SVG 2 a define como Inherited: no), então declará-la num <g> é inócuo; o preview do DG sempre aplicou por seletor universal e o do DI copiou o conceito da lei do §4.6 sem copiar a implementação que a torna verdadeira. (5) Dois defeitos de papel achados pelo gate e que nenhuma automação veria: uma .nota partindo entre páginas (o break-inside: avoid cobria só os blocos longos) e as células do teste com áreas diferentes (o SVG preservava a proporção do viewBox). Padrão que se repetiu três vezes neste lote e vale como regra: quando um teste e o comportamento discordam, quase sempre é o teste que está olhando para o lugar errado — aconteceu no DG7-03, no contraste-dg.py e no DI6-02. Pendente: PNG @2x do ET5 e a folha de prova do DI-b (o gatilho da textura no papel, que segue ABERTO — o gate de impressão desta versão mediu o DI4, não o DI3).
Lote de produção do DI-a. Nenhum gráfico novo e nenhum tipo novo: o DI não cria gráfico, cria comportamento. (1) Vocabulário de textura do DG13 ESTENDIDO de 4 para 6 posições (linhas verticais na 5, diagonal a 135° na 6 — nunca 45°, que é exclusiva do chart-no-data), aprovado no gate de 2026-08-11. A lacuna existia desde sempre e era invisível porque o gatilho antigo nunca foi exercido contra um gráfico de 5 ou 6 séries. (2) seed-tokens.md vai a v1.7 com o token novo chart-no-data-hatch (cinza-600 / cinza-400), fechando a errata E13; os três gêmeos foram editados na mesma edição e o paridade-tokens.py fecha em 50 PASS · 0 FAIL. (3) contraste-dg.py reescrito (v2, DI18): mede o DG14 em vez do DG11 morto, as seis séries da v1.5 em vez de três, e opera o portão do DI2 varrendo todos os pares para 2…6 séries nos dois modos — 38 PASS · 0 FAIL · 20 MITIGADO · 4 ISENTO. Fecha a pendência P8. (4) Preview do DG a v1.4 com a E11 corrigida (a pizza de 5 séries passa a texturizar), o gatilho DI2 implementado por atributo data-series no <figure> — para a condição ficar auditável no DOM e não escondida em JS —, os patterns tex-s5/tex-s6 e a hachura no token novo. (5) A suíte ganha a seção que o §6 dizia existir e não existia (errata E12): 11 verificações TEX-* + 2 NEU-*, levando o placar de 163 a 176 PASS · 0 FAIL. Prova de que a guarda é real: rodada contra o preview v1.3 antigo, ela reprova em 4. Oito erratas E9–E16 (§5), três delas de uma classe nova — correção declarada que não foi inteiramente aplicada: a E14 mostra que a E3 trocou a tinta da hachura só no swatch da legenda, deixando os dois <pattern> SVG em violeta desde a v1.5; a E15 acha a terceira ocorrência da mesma armadilha na série "Esperada"; a E16 mede 19 tokens semânticos derivados no bloco embutido do preview e os corrige por script a partir do canônico — a guarda que a E4 havia pedido — e de quebra explica a E8, porque a §3c copiou o fundo de referência dark do preview em vez de copiar do token. Regra de método que sai do lote: correção de errata se verifica pela medição do que ela prometia consertar, não pelo fato de o arquivo ter mudado.Percalço de produção registrado: a primeira edição do CSS dos tokens usou replace de texto e a linha indentada a 2 espaços casou dentro da indentada a 4, dentro do @media (prefers-color-scheme: dark), duplicando uma declaração fora de qualquer seletor; pego na leitura de volta e refeito por regex de linha inteira. Guarda que fica: edição cirúrgica de CSS por replace de texto é insegura quando o mesmo token existe em blocos de indentação diferente — o casamento tem de ser ancorado na linha. Pendente: gate visual do preview v1.4, preview do DI, PNG do ET5 e a edição do MANIFESTO (que fecha E9, E10, P8 e P4-b).
MARCO v1.7 — o sub-bloco DG (gráficos core) fecha estável com 13 decisões, e o sistema ganha uma PALETA CATEGÓRICA ESTENDIDA e um redesenho visual inteiro (DG14–DG17).
texto inteiro da versão
MARCO v1.7 — o sub-bloco DG (gráficos core) fecha estável com 13 decisões, e o sistema ganha uma PALETA CATEGÓRICA ESTENDIDA e um redesenho visual inteiro (DG14–DG17). O DG cobre sete tipos — barra, empilhada, agrupada, linha, área, pizza, dispersão — mais os três estados herdados do Bloco 3. Duas emendas aconteceram durante a produção: a barra empilhada foi puxada para dentro do escopo a pedido do Rafael (caso real: consumo por posto tarifário), trazendo junto a agrupada como saída obrigatória; e o DG13 (textura) nasceu do gate. Âncoras da spec: DG1 — todo gráfico é um invólucro de 5 partes com fallback textual sempre presente, porque a auditoria pública de 2024 do shadcn Charts reprovou a biblioteca em 1.1.1 (sem alternativa textual) e 1.3.1 (legenda sem relação codificada): acessibilidade de gráfico não se delega à lib · DG2 — um tab-stop + setas, com o gap do VoiceOver declarado e não resolvido (o Recharts contorna com role="application", que o VO não suporta), logo o teclado é enriquecimento e quem garante o acesso é a tabela · DG4 — eixo zero é regra dura assimétrica: barra e área sempre do zero porque comprimento e área codificam valor por geometria; linha pode truncar sob três condições, e a SEED precisa disso (PR de usina e tensão de rede variam pouco e importam muito) · DG5 — pizza com 8 travas, incluindo a regra dos 5 p.p. e o corte do dado ordinal · DG10 — empilhada com teto de 4 segmentos (aperto deliberado sobre os 5 do mercado, por motivo interno: acima disso a paleta pareia matizes da mesma família, e segmento preenchido não carrega tracejado para desambiguar). O MARCO TEM QUATRO FATOS DE MÉTODO, TODOS NASCIDOS NO GATE VISUAL E NENHUM ANTECIPÁVEL PELA PESQUISA.(1) Instrumento errado, medição certa. O portão de grayscale media razão de contraste WCAG entre séries convertidas para cinza e reprovava o modo claro (cat-1 × cat-3 = 1,22) — exatamente onde o gate humano lia bem. A razão de contraste foi calibrada para texto sobre fundo, não para faixas grandes adjacentes separadas por contorno; a métrica correta é o espalhamento de claridade (claro espalha 20 pontos; escuro comprime em 4, com duas séries idênticas). O piso de 6 pontos ficou declarado no código como calibrado pelo gate, não derivado de norma — e quando tentei generalizá-lo para as bandas finas do DM, o gate reprovou de novo: um piso vale só no contexto em que foi medido.(2) A paleta da marca tem teto físico. Medindo o matiz de todos os primitivos: para dado existem 3 matizes livres (turquesa ~170°, dourado/amarelo ~36–50° — mesma família —, azul ~197°), porque vermelho e cinza são reservados. A restrição "nenhum hex novo" que eu mesmo propus no DT provou-se apertada demais e vai a supersede. Seguindo o padrão IBM Carbon/GitLab (paleta de dataviz separada da marca), nasceram 2 matizes exclusivos de dado, que nunca aparecem em UI: magenta 332° e violeta 268°, calibrados na claridade das âncoras SEED. Sequência final: turquesa → dourado → magenta → azul → violeta → azul-800, cobrindo 5 famílias, com a regra de que nenhuma família repete antes da 6ª posição e nenhum gráfico multi-série pareia tons da mesma família — esta última nasceu do Rafael apontar que a linha dupla e o gráfico do ET5 tinham ficado turquesa × turquesa. (3) Vida não vem de cor, vem de renderização. O Rafael trouxe 7 telas de um produto de referência e pediu análise antes de qualquer execução. O achado contrariou minha própria hipótese: os gráficos da referência são quase monocromáticos e mesmo assim parecem vivos. O que separava era a renderização — daí DG14 (zero contorno; separação de segmentos por vão de 2px, geometria em vez de contraste; cat-1 claro → turquesa-500 para passar 3:1 sozinho), DG15 (canto arredondado em todo retângulo de dado; curva monótona, nunca spline genérica, que inventa picos inexistentes; gradiente 22%→0), DG16 (palco mínimo: ≤3 gridlines hairline, sem linha de eixo, número protagonista com micro-caps mono e variação em pílula) e DG17 (destaque×contexto). O DG11 — contorno cinza-900, que eu havia criado por medição poucos dias antes — foi superado por completo: era ele que dava o ar de relatório antigo. A acessibilidade foi preservada por outros mecanismos, todos medidos, e o DG13 permanece: a paleta estendida melhora o colorido, não revoga a textura. (4) A matriz de render se CRUZA, não se amostra. Havia 4 cenários cobrindo claro+grayscale e escuro, mas nunca a combinaçãoescuro+grayscale — e era ali que morava o defeito que o Rafael achou (todas as séries colapsando no mesmo cinza). Amostrar combinações dá sensação de cobertura. A matriz passou a cruzar tema × grayscale × largura, e o render mede propriedades resolvidas pelo navegador — o fill efetivo após a cascata, e o getBBox de todo texto SVG contra os limites do viewBox (um rótulo terminava em x=509 num viewBox de 500 e era cortado em silêncio). Sub-bloco DM (monitoramento) — preview aprovado, spec ainda NÃO escrita:DM1 o medidor canônico é o bullet graph, com gauge circular só por exceção declarada (a literatura é unânime: ângulo é pior que comprimento para comparar, e o ERP compara muitas usinas) · DM3inversão de papéis — as bandas de faixa viram intensidades de cinza e quem carrega a severidade é a barra de valor; motivo medido: as três faixas coloridas ficavam a 1 ponto de claridade entre si no claro e 0 no escuro, diferindo quase só por matiz, exatamente o que Few previu ao mandar codificar faixas em intensidades e não em matizes · DM4role="meter" com o rótulo fora do elemento, porque descendente de meter é apresentacional · DM5/DM6 sparkline sem eixo, aria-hidden, com a célula vizinha carregando o número · DM8 o gráfico do alerta fecha o slot ET5 aberto na F4. Hierarquia de traço (3 níveis: dado 2px · estrutura 1px · apoio 0,5px) com vector-effect: non-scaling-stroke obrigatório — medido, as escalas dos SVG iam de 0,66× a 12,4×, então o mesmo stroke-width="1" renderizava entre meio pixel e doze: espessura era subproduto do contêiner, não decisão de design. Validação do marco: jsdom do DG 163 PASS · 0 FAIL · contraste-dg.py 32 PASS · 0 FAIL · 14 MITIGADO · 4 ISENTO (com a distinção explícita entre "falha" e "falha prevista e resolvida por outro mecanismo", porque misturar as duas apaga o sinal) · render puppeteer 6 cenários cruzados por preview. PENDÊNCIA CRÍTICA: DG14–DG17, a paleta estendida e a spec do DM existem apenas nos previews do Drive — o lote de formalização (§3c v1.5 + gêmeos + seed-dataviz.md + suite do DM) é o próximo trabalho, antes de DP e DI. Esta versão NÃO fecha fase e NÃO gera CHECKPOINT.
MARCO v1.6 — A FASE 5 (DATA VISUALIZATION) ABRE, e seus dois primeiros sub-blocos já são estável: DF (fundamento) e DT (tokens de dado).
texto inteiro da versão
MARCO v1.6 — A FASE 5 (DATA VISUALIZATION) ABRE, e seus dois primeiros sub-blocos já são estável: DF (fundamento) e DT (tokens de dado). Nasce o 9º arquivo canônico, seed-dataviz.md v0.3, pela mesma classe de conflito que criou o seed-email.md na F4: cor de dado não é cor de UI. O semântico de UI carrega intenção de interface — a série 2 de um gráfico não é "ação" nem "erro", é a segunda categoria de um dado, e obedece a leis que a UI não tem (ordem fixa, diferenciação perceptual entre vizinhas, comportamento sob grayscale, e uma isenção normativa que nenhum componente de UI possui: o WCAG 1.4.11 isenta explicitamente heatmap). Hospedar isso no seed-componentes.md — que já tem 341 KB — contaminaria a regra-mãe do arquivo. O que o DF fixou em 7 decisões: o canônico é agnóstico de biblioteca, mas o consumidor canônico web é o Chart do shadcn/ui sobre Recharts v3 (a stack real do Lovable), com o detalhe técnico de que no v3 a referência é var(--chart-N) direto, sem o wrapper hsl() antigo · régua de 4 pisos, todos medidos por script: 1.4.1 (cor nunca é o único portador), 1.4.11 (3:1, com isenção declarada e condicionada para a escala sequencial), 1.4.3 (rótulo/eixo/legenda ≥4.5:1) e 1.1.1 (todo gráfico tem fallback textual) · grayscale vira gate ESTRUTURAL, não teste opcional — todo preview da fase carrega modo P&B acionável, o que serve de uma vez o "aperto de olhos" do método e o impresso da F7 (laudo e O&M saem em P&B), evitando uma fase inteira de gráficos que não degradam. O FATO DE MÉTODO DO MARCO SÃO DOIS, E OS DOIS SÃO SOBRE DETECTORES.(1) O gate humano achou de novo o que a automação não podia achar. O DT foi ao gate com três camadas automatizadas verdes; o Rafael olhou o preview e perguntou se a escala inicial "era pra ser toda em cinza mesmo". Os stops 50/100 da rampa turquesa têm chroma tão baixo que perdem o matiz em tela — e cinza, em dataviz, significa "sem dado": valor baixo e ausência de medição eram ambíguos. As três camadas mediam razões de contraste, não percepção de matiz; nenhuma delas poderia ter visto. Correção estrutural aprovada sobre preview comparativo: a rampa desloca um stop (100→900 light / 800→100 dark) e nasce o token chart-no-data — cinza exclusivo de "sem medição", sempre hachurado, de modo que a distinção "gerou pouco × não reportou" nunca dependa de cor (1.4.1, grayscale e impresso de graça). Alternativa descartada: manter 50→800 e resolver só pela regra do no-data — rejeitada porque a leitura-cinza permaneceria na tela. (2) Uma regra sem detector não é uma regra. A promoção obrigou a abrir os arquivos gêmeos de token e a medição mostrou que seed-tokens.json e seed-tokens.css declaravam v1.1 e não continham nenhum token do pacote mobile v1.2 — zero ocorrências de breakpoint, safe-area, fs-field-touch e clamp. A defasagem era de duas versões, e a própria pendência §7.0 do seed-tokens.md a descrevia como sendo de uma. Causa raiz: a regra "os três arquivos formam uma unidade" existia desde a v1.0 sem nenhum detector — ler o .md não revela nada sobre o conteúdo dos gêmeos, e o .md é justamente onde a versão dos três é declarada; a fonte da afirmação e o objeto da afirmação nunca se encontravam. Mesma classe do defeito de propagação do marco v1.4. Correção estrutural: nasce validacao/paridade-tokens.py (G1 não-regressão · G2 paridade json↔css · G3 cobertura nominal em light e dark), 43 PASS · 0 FAIL — e ela reprovou a primeira tentativa de regeneração, que reescrevia o CSS a partir do JSON e no caminho renomeou --seed-sp-* para --seed-space-*, perdeu o composto --seed-focus-ring (que só existe no CSS) e serializou sombras, famílias e beziers como estrutura DTCG. A entrega passou a ser por edição cirúrgica do arquivo anterior. Lição transferível: regeneração total a partir de um modelo incompleto perde token em silêncio; preservar bytes é mais seguro do que reconstruir e conferir.Terceiro fato, de propagação: o Rafael anexou o repositório inteiro em zip, o que permitiu a primeira leitura de volta COMPLETA contra a âncora do MANIFESTO — 27 de 27 artefatos batem byte a byte, e permitiu fechar a pendência P4 (os artefatos de e-mail do marco v1.5 nunca tinham sido ancorados). O MANIFESTO.md vai a v1.2 com 21 linhas novas. Aprendizado de ferramenta da fase: a camada de render da F5 usa puppeteer (viewport + fullPage), nunca o CLI --screenshot do Chrome — medido: o CLI truncou a renderização à direita e simulou um overflow inexistente (scrollWidth real 360, zero elementos estourando). Erratas encerradas neste marco: a do seed-tokens.md §5 (par info), aberta desde 2026-08-04 — pela regra GI2, a F5 editou o arquivo por outro motivo e a errata foi fechada junto, com correção mais completa que a prevista (o par semântico real é azul-800 = 8.57 AAA, não uma simples troca de rótulo). Validação do marco:contraste-dataviz.py29 PASS · 3 FAIL (os 3 são documentados e esperados — o fill cat-1/cat-2/cat-5 em traço fino, que é a razão de existir da variante cat-N-stroke) · paridade-tokens.py43/0 · jsdom do DT 14/14 · 4 renders puppeteer inspecionados · cruzamento §3c × gêmeos 26/26. Esta versão NÃO fecha fase e por isso NÃO gera CHECKPOINT — o padrão delta reserva o checkpoint imutável para fechamento de bloco/fase, e a F5 tem 4 sub-blocos ainda não escritos; o vigente está no ESTADO_ATUAL_SeedDS.md v1.6. Próximo: sub-bloco DG (gráficos core) — barra, linha, área, pizza-com-regras, dispersão + skeleton/empty/erro, no rito de 3 rodadas encadeadas → consolidado → aprovo → lote autônomo.
Promoção da §3c a estável (gate visual do DT aprovado pelo Rafael sobre o preview v0.2 completo) e fechamento do débito do §7.0: os gêmeos seed-tokens.json e seed-tokens.css foram regenerados e passam a v1.4. Nenhum valor de token foi alterado nesta versão — é mudança de estado + restabelecimento da unidade md+json+css. Achado da execução: o débito era de DUAS versões, não uma — os gêmeos declaravam v1.1 e não continham nenhum token do pacote mobile v1.2 (breakpoints, tipografia fluida clamp(), --seed-fs-field-touch, safe-area); a redação anterior da pendência 7.0 é superada com racional completo. Guarda nova:validacao/paridade-tokens.py (G1 não-regressão · G2 paridade json↔css · G3 cobertura nominal), 43 PASS · 0 FAIL — ela reprovou a primeira tentativa de regeneração (renome de --seed-sp-*, perda de --seed-focus-ring, sombras serializadas como DTCG), o que levou a entrega a ser feita por edição cirúrgica. Cruzamento §3c × gêmeos: 26/26 hex batem. contraste-dataviz.py reproduzido na janela: 29 PASS · 3 FAIL (os 3 documentados do fill em traço fino).
Escalas de dado da Fase 5 (sub-bloco DT), nova §3c
texto inteiro da versão
Escalas de dado da Fase 5 (sub-bloco DT), nova §3c — a entrega prometida desde a v1.0. Sequencial chart-seq-1…7 (rampa turquesa; escala final 100→900 light / 800→100 dark, decidida no gate visual: o Rafael reprovou a proposta original 50→800 porque os dois primeiros stops liam como cinza — ambíguos com "sem dado" — e aprovou a opção A sobre preview comparativo; nasce junto o token chart-no-data, cinza exclusivo de "sem medição", SEMPRE hachurado; isenção 1.4.11 declarada com condições de acompanhamento e gatilho de revisão) · divergente chart-div-neg-3…pos-3 (vermelho↔cinza↔turquesa, alinhada por construção ao par positive/negative da v1.0; posições plenas passam 3:1 medido nos dois modos; regra da zona-zero declarada) · gauge gauge-track/value/range-* (faixas referenciam a taxonomia de feedback — nenhuma severidade paralela) · variante cat-N-stroke light+dark para traço fino, nascida de remedição que reprovou cat-1/2/5 a ≤3px (fill intocado; os pares dark vieram do achado V2 do render). Dois achados do script corrigiram a proposta antes da spec: warning light dourado-500→600 (2.35→3.25 vs trilha) e critical dark vermelho-400→300 (2.38→3.26). Nenhum hex novo — tudo stop existente do §2.1. Errata §5 fechada nesta edição (regra GI2 — aberta desde o roadmap v1.3, 2026-08-04): a linha do par info dizia "azul-700 · 5.79 · AA"; medição de 2026-08-09 provou que 5.79 é de fato o azul-700, mas o par semântico usado pelo sistema (feedback-info-text, consumido inclusive pelo e-mail §4.2) é o azul-800, que mede 8.57 · AAA — a linha passa a documentar o par real, e a errata original (que previa só troca de rótulo) é superada pela correção completa rótulo+número+veredicto. Consumidor primário desta seção: seed-dataviz.md (9º canônico, DF7: uma fonte, referência sem duplicação).
Sub-bloco DG (gráficos core) estável — 13 decisões, §4 nova. Sete tipos (barra, empilhada, agrupada, linha, área, pizza, dispersão) mais os três estados herdados do Bloco 3. Consolidado aprovado após 3 rodadas encadeadas de pesquisa, com duas emendas durante a produção: a barra empilhada foi puxada para dentro do escopo a pedido do Rafael (caso real: consumo por posto tarifário), trazendo junto a agrupada como saída obrigatória; e o DG13 (textura) nasceu do gate. Três regras nasceram da medição, não do consolidado: DG11 (contorno cinza-900 — o fill categórico reprova sozinho contra o fundo claro), DG12 (tinta sobre dado não segue o tema — o fill é claro nos dois modos) e DG13 (textura na interseção escuro+grayscale). O gate levou o preview da v0.1 à v0.5, e os dois achados decisivos foram do olho do Rafael: o colapso das séries em cinza no modo escuro, e o escopo exato do gatilho da textura. Correção de instrumento registrada: o portão de grayscale media razão de contraste WCAG e reprovava o modo claro, onde o gate humano lia bem — foi trocado por espalhamento de claridade, com piso declarado como calibrado pelo gate e não derivado de norma. Validação: jsdom 147/0 · contraste 32 PASS · 0 FAIL · 14 MITIGADO · 4 ISENTO · render puppeteer 6 cenários (matriz tema × grayscale × largura, agora cruzada e não amostrada — a versão anterior não gerava escuro+grayscale, que era exatamente onde o defeito morava).
PROMOÇÃO: DF e DT passam de rascunho a estável, após "aprovo" explícito do Rafael no gate visual do preview seed-dataviz-tokens-preview.html v0.2 completo (2ª rodada do gate; a 1ª aprovara só a escala A sobre o preview comparativo). Nenhuma decisão de conteúdo mudou nesta versão — a v0.3 é mudança de ESTADO mais os registros que a promoção obriga. Junto: validação reproduzida na janela (29 PASS · 3 FAIL, os 3 documentados do fill em traço fino) e cruzamento §3c×gêmeos (26/26 hex batem). Débito dos gêmeos ENCERRADO — seed-tokens.json/.css regenerados para v1.4, e a execução revelou que a defasagem era de duas versões (faltava todo o pacote mobile v1.2), não uma; nasceu daí a guarda paridade-tokens.py. MANIFESTO.md v1.2 ancora os artefatos da F5.
Achado do gate visual do Rafael na escala sequencial:
texto inteiro da versão
Achado do gate visual do Rafael na escala sequencial: os stops 50/100 da proposta original liam como cinza — ambíguos com "sem dado". Correção aprovada (opção A sobre preview comparativo): escala desloca para 100→900 (light) / 800→100 (dark), e nasce o token chart-no-data (cinza exclusivo de "sem medição", sempre hachurado). Alternativa B descartada (manter 50→800 e resolver só por regra — a leitura-cinza permaneceria). Valores e supersede na §3c do seed-tokens.md v1.3. Bug de regressão corrigido no contraste-dataviz.py (seção do gauge media os stops rejeitados, não os canônicos).
Correção de estado congelado — nenhuma decisão, supersede ou artefato muda
texto inteiro da versão
Correção de estado congelado — nenhuma decisão, supersede ou artefato muda (mesma classe da errata de cabeçalho corrigida no seed-ds-roadmap.md v1.8). Três pontos estavam parados no escopo da v0.2 enquanto o corpo já continha os 6 sub-blocos estável: (a) o cabeçalho declarava "EM+EL estáveis, base v0.3, GV1–GV4" e "EC/ET/EN/EA ainda não escritos" — reescrito para refletir a Fase 4 completa, com a lista de artefatos vigentes e GV1–GV8; (b) a tabela de fases do §0 marcava a F4 como "🔄 em produção" — corrigida para ✅ concluída; (c) a pendência "EC/ET/EN/EA não escritos" do §8 — marcada RESOLVIDA com referência às §§8-B–8-E, linha riscada mantida para rastreabilidade. As demais pendências do §8 permanecem intactas: ou seguem realmente abertas (rodapé com dado real, trilha EN5, clientes fora da matriz mínima), ou não têm comprovação de resolução dentro deste arquivo (Cache Rule) — não se corrige por memória. Divergência detectada na verificação de retomada pós-marco v1.5 (2026-08-09); correção imediata por decisão do Rafael de não deixar a pendência para trás.
Primeira entrega da Fase 5. Nasce o 9º canônico com o fundamento DF1–DF7 (consolidado aprovado pelo Rafael em 2026-08-09 após 3 rodadas: R1 canon interno · R2 mercado/stack shadcn Chart+Recharts v3 · R3 normas WCAG…
texto inteiro da versão
Primeira entrega da Fase 5. Nasce o 9º canônico com o fundamento DF1–DF7 (consolidado aprovado pelo Rafael em 2026-08-09 após 3 rodadas: R1 canon interno · R2 mercado/stack shadcn Chart+Recharts v3 · R3 normas WCAG 1.4.1/1.4.11/1.4.3) e o registro do sub-bloco DT, cujos valores vivem no seed-tokens.md v1.3 §3c (DF7: uma fonte). Medição prévia corrigiu 2 propostas de gauge e originou a variante cat-N-stroke. Estado: rascunho, aguardando gate visual do preview de tokens.
MARCO v1.5 — A FASE 4 (SISTEMA DE E-MAIL) FECHA COMPLETA, 6/6 SUB-BLOCOS estável, EM 36 HORAS DE ABERTURA A FECHAMENTO.
texto inteiro da versão
MARCO v1.5 — A FASE 4 (SISTEMA DE E-MAIL) FECHA COMPLETA, 6/6 SUB-BLOCOS estável, EM ~36 HORAS DE ABERTURA A FECHAMENTO. Nasce o 8º arquivo canônico, seed-email.md v0.10, porque e-mail é OUTRO RUNTIME: consome hex literal (var() é morto em Gmail/Outlook), layout por tabela, PNG com cor assada — hospedar isso no seed-componentes.md contaminaria a regra-mãe "componente consome semântico". Infraestrutura REAL montada e verificada na própria fase: Cloudflare R2 servindo assets.seed.eng.br/email/v1/ (caminho imutável) e Resend verificado em envio.seed.eng.br (São Paulo) com DKIM/SPF/MX + DMARC. Entregues: template-base v0.4 · preview de componentes v0.3 · 3 transacionais do ERP (proposta · fatura · alerta esperado×medido×desvio) com inventário de placeholders mustache como contrato formal com o ERP · newsletter modular v3.2 (4 módulos removíveis) · comercial texto-quase-puro · assinatura corporativa v0.2 instalada e provada no Gmail real do diretor. O FATO DE MÉTODO DO MARCO: 11 defeitos reais encontrados pelo gate visual do Rafael, 11 corrigidos, 8 famílias de teste-guarda permanentes (GV1–GV8) — e NENHUM dos 11 era visível às verificações automatizadas. A previsão da abertura (em e-mail o gate humano é a camada determinante) confirmou-se com números: a suíte estática é o piso, o olho é o juiz. Destaques do ciclo: o defeito 9 (faixas cinza no Outlook) levou TRÊS hipóteses até o veredito — qualquer row-spacer com fantasmagoriza em zoom ≠100% no motor Word; espaçamento vertical canônico passa a ser padding/margin — com direito a uma reclassificação prematura de Claude derrubada pelo print seguinte do Rafael (registrada, não apagada); o defeito 10 foi erro de ferramenta do próprio produtor (uma linha "no-op" destruiu 9 </p> e a suíte passou verde — nasceu o GV7 de balanceamento); o defeito 11 fundou a classe "artefato composto desatualizado" (o comercial embutia a assinatura antiga após o supersede do logo — nasceu o GV8 com a lista viva de assets aposentados). Decisão de fechamento do Rafael ("aprovo b"): row-spacers do acervo promovido ficam como tolerância monitorada (retrofit só quando um template for editado por outro motivo). Protocolos permanentes novos: print de e-mail encaminhado não é evidência de gate (encaminhar descarta head e VML) · API key de teste é descartável (Read-Host + revogação) · matriz de gate mínima = Gmail web + Gmail Android dark forçado + Outlook 2024 clássico. Placar: 312 PASS / 0 FAIL em 14 arquivos · contraste 14 pares/0 reprovações · 9+ evidências de recebimento direto. Backlog que a fase deixa: rodapé com endereço real antes do 1º envio a cliente · trilha de campanha (EN5, aguarda lista) · DKIM Workspace/DMARC raiz (TI da SEED) · EM14 provisória. Delta no CHECKPOINT_v1_5_fase4_email.md; vigente no ESTADO_ATUAL_SeedDS.md v1.5. Próximo: escolha de fase do Rafael (F5 dataviz — recomendada; o alerta de geração já reservou o slot de gráfico · F6 patterns · F8).
Gate EN: defeitos 8 (chaves órfãs — erro de geração com asserção fraca, GV6a) e 9 (spacer sem fundo no Outlook, GV6b). Correção retroativa em todo o acervo (base v0.4, componentes v0.3, ET v0.2). 284 PASS / 0 FAIL em 14 arquivos.
Sub-blocos EA (assinatura: canônico + amostra + guia + PNG novo logo-seed-assinatura@2x.png MD5 15f8f4821677cfddb81a868681ea9a1d) e EN (newsletter modular de 4 módulos + comercial texto-puro, com amostras) em rascunho.…
texto inteiro da versão
Sub-blocos EA (assinatura: canônico + amostra + guia + PNG novo logo-seed-assinatura@2x.png MD5 15f8f4821677cfddb81a868681ea9a1d) e EN (newsletter modular de 4 módulos + comercial texto-puro, com amostras) em rascunho. 3 refinamentos de suíte documentados (URL-placeholder, modo fragmento, GV3 na assinatura). 110 PASS / 0 FAIL nos 6 arquivos novos; regressão 60/0.
Sub-bloco ET em rascunho: 3 transacionais (proposta · fatura · alerta) compostos sobre o base v0.3, inventário de placeholders mustache como contrato com o ERP, supersede ET7 do From (notificacoes@) registrado na EM14.…
texto inteiro da versão
Sub-bloco ET em rascunho: 3 transacionais (proposta · fatura · alerta) compostos sobre o base v0.3, inventário de placeholders mustache como contrato com o ERP, supersede ET7 do From (notificacoes@) registrado na EM14. 120 PASS / 0 FAIL nos 6 arquivos.
Promoção do EC a estável pelo gate do Rafael: EC1–EC8, preview v0.2, GV5. Confirmação da correção dos achados 6 e 7 nos três clientes da matriz. Nota cosmética número/unidade registrada sem bloqueio.
Gate visual do EC: achados 6 (nowrap em valores) e 7 (barra de severidade → border-left, supersede da anatomia EC2, guarda GV5). Preview v0.2, suíte com 20 verificações.
texto inteiro da versão
Gate visual do EC: achados 6 (nowrap em valores) e 7 (barra de severidade → border-left, supersede da anatomia EC2, guarda GV5). Preview v0.2, suíte com 20 verificações.
Promoção a estável dos sub-blocos EM+EL e do template-base v0.3, pelo gate do Rafael. Nova §7.2 com o ciclo completo de gate (5 defeitos reais em 3 clientes, todos corrigidos e virados guarda GV1–GV4), §7.3 com o registro da promoção, decisões novas EL9 (corpo 16px) e EL10 (espaçador em vez de margin), regra unificada NADA IMPLÍCITO, protocolo de gate sem encaminhamento, e atualização das pendências (placeholders do rodapé, política de chave descartável, clientes pendentes).
PROMOÇÃO FINAL — EA e EN a estável; os 6 sub-blocos da F4 fechados.
texto inteiro da versão
PROMOÇÃO FINAL — EA e EN a estável; os 6 sub-blocos da F4 fechados. Veredito final do defeito 9 (row-spacer × zoom; padding como técnica canônica), defeitos 10 (GV7) e 11 (GV8), decisão "aprovo b" da tolerância monitorada para o acervo. Newsletter consolidada em v3.2 (zero row-spacers, tags balanceadas), comercial v2 com assinatura vertical embutida, assinatura EA v0.2 instalada e provada em produção real. Balanço da fase: 11 defeitos do gate, 11 corrigidos, GV1–GV8.
MARCO v1.4 — A FASE 3 FECHA: 7 DE 7 BLOCOS. Com a promoção do §45 Iconografia (seed-componentes.md v0.47), a camada de componentes do SEED Design System v2 está completa: 44 componentes + 2 patterns (§33 Central de Notificações e §39 command palette ⌘K), todos estável.O arco dos 7 blocos, para quem lê isto sem ter visto nada:(1) Botões fundou o vocabulário e, junto com a primeira crítica visual do Rafael, fundou o método de qualidade que governou tudo o que veio depois. (2) Formulários entregou 13 itens e as regras transversais que nenhum bloco seguinte precisou reabrir — protocolo de live region (§1.13), registry de máscaras BR, aria-invalid explícito, paridade mobile como premissa estrutural. (3) Feedback e status trouxe a taxonomia de severidade em PT-BR e a Régua de Espera com seus 3 regimes compostos, e foi onde nasceu a lição que se provou permanente: a suite valida comportamento; geometria e percepção são território do gate humano.(4) Superfícies fechou a régua de 3 degraus (tooltip → popover → modal) e formalizou a escala de sobreposição 60<65<70<75<80 depois de um bug real de empilhamento pego no gate. (5) Navegação foi o bloco de virada: nasceu a camada de render em Chrome headless, foi autorizado o modo lote autônomo, e as duas erratas do gate viraram régua permanente (o wizard sempre termina em ação terminal nomeada; token consumido sem definição é bug de build), cada uma com detector nas duas camadas. (6) Dados — tabela, seleção, toolbar, degradação responsiva e o guia de integração — encerrou as 3 pendências herdadas do Bloco 2 e foi o primeiro bloco cujos dois gates humanos passaram sem errata, porque os detectores criados no Bloco 5 pegaram as reincidências sozinhos. (7) Iconografia fecha o arco pelo começo: normalizou o acervo herdado do HTML v1 numa régua única (28 glifos ativos), fechou por desenho os gaps dos pilares Subestações MT e SPDA (transformer, lightning-rod) e amarrou o set ao consumo real da stack via NM4 (SEED × Lucide). MAS O FATO DE MÉTODO DESTE MARCO NÃO É A ICONOGRAFIA — É UM DEFEITO DE PROPAGAÇÃO NO BLOCO 5. Em 2026-08-06 22:54 o seed-navegacao-preview.htmlv0.40 foi sobrescrito no repositório do Drive por uma cópia de trabalho defasada, a v0.37. 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-renderabortou no bloco R8 com TypeError procurando #cp-dialog. Uma conferência por tamanho de arquivo aprovou 21 de 21 arquivos enquanto um era a versão errada. O v0.40 sobreviveu por acaso, na pasta de downloads dos cards de entrega, e foi resgatado de lá. Dois artefatos de validação foram perdidos em definitivo e RECONSTRUÍDOS a partir da spec (suite-navegacao.mjs de 90 testes e contraste-navegacao.py) — e o placar que eles produzem é declarado em todos os documentos como evidência NOVA de 2026-08-07, não como o "90/90" histórico do marco v1.2, que não é reproduzível. Mudanças estruturais que ficam: (a) nasce validacao/MANIFESTO.md — âncora por MD5 de todo artefato canônico (nome · versão · bytes · hash · consumidor · placar) e a REGRA DE PROPAGAÇÃO: todo artefato salvo é verificado por LEITURA DE VOLTA, nunca por afirmação de que foi salvo; (b) o conector do Google Drive deixa de ser transporte de artefato de regressão — base64 reemitido corrompeu silenciosamente 3 vezes num único arquivo (um byte extra, duas trocas de caractere Unicode); anexo em zip vira o padrão; (c) ERRATA-NAV-01 — os guardas TB-24/MN-25 ("nenhum botão morto") desconheciam os 12 botões de 5C/5D/5E; a lista de exclusão foi estendida sem enfraquecer o guarda, porque cada um dos 12 ganhou teste de liveness dedicado; (d) correção de documentação: a suite-render.mjs consome cinco previews, não quatro. Validação do marco, ancorada por MD5 e não por tamanho: 445 verdes jsdom + 43 verificações render / 0 achados + 4 scripts de contraste no gate WCAG. Gate visual do Rafael aprovado em 2026-08-07. Delta no CHECKPOINT_v1_4_bloco7_iconografia.md; vigente no ESTADO_ATUAL_SeedDS.md v1.4. Próximo: a F3 está fechada — a fase seguinte é escolha do Rafael (F4 e-mail · F5 dataviz · F6 patterns · F8 publicação/GEO).
Primeira entrega da Fase 4. Sub-blocos EM (fundamento técnico, EM0–EM15) e EL (layout, EL1–EL8). Paleta resolvida com 14 pares medidos e 0 reprovações. Infraestrutura montada e verificada: Cloudflare R2 +…
texto inteiro da versão
Primeira entrega da Fase 4. Sub-blocos EM (fundamento técnico, EM0–EM15) e EL (layout, EL1–EL8). Paleta resolvida com 14 pares medidos e 0 reprovações. Infraestrutura montada e verificada: Cloudflare R2 + assets.seed.eng.br ativo; Resend + envio.seed.eng.br verificado com DKIM/SPF/MX/DMARC. Cinco supersedes formais registrados, incluindo duas correções de erro do próprio autor (racional do EM13-b e classificação de contraste decorativo). Estado: rascunho, aguardando gate visual.
Marco v1.3 fechado — Bloco 6 (Dados) completo 5/5 (seed-componentes.md v0.45; 43 componentes + patterns CN/⌘K). Produzido em 2 lotes do modo autônomo (6A+6B · 6C+6D+6E). Fato novo do marco: os dois gates humanos passaram SEM errata — primeira vez na F3 — a camada render pegou os 2 bugs reais do bloco (sticky×border-collapse, guarda DT-13; piso da densidade compacta) ANTES do gate, e os detectores do v1.2 (token fantasma NV, whitelists) pegaram as reincidências sozinhos. Pendências históricas encerradas: indeterminate (B2→SL2) · busca composta EUI (B2→TD1) · densidade ERP→mobile (B2→DT2/LD2). Coerência org: skill seed-ds-ui lida no GI — cadeia de tokens formalizada (GI1) + pendência de alinhamento da skill registrada (GI2). Validação: 420 jsdom + 38 render. Delta no CHECKPOINT_v1_3_bloco6.md; vigente no ESTADO_ATUAL_SeedDS.md v1.3. Próximo: Bloco 7 (Iconografia) fecha a Fase 3.
Marco v1.2 fechado — DUPLO: CN §33 + Bloco 5 (Navegação) completo 6/6 (seed-componentes.md v0.41; 38 componentes + pattern CN estáveis). Trajetória v0.33→v0.41 num único dia. Mudanças estruturais do marco: (a) modo lote autônomo autorizado — produção contínua de sub-blocos com parada só em ponto de decisão genuíno; interação do Rafael comprimida a 3 momentos por lote; piloto 5C+5D+5E validado (2 erratas de gate, ambas com detector permanente); (b) camada de validação NOVA: suite-render.mjs (Chrome headless real no ambiente) — geometria, recorte de foco, alvos de toque, overflow 360, empilhamento por pixel, tokens fantasma e screenshots automáticos; auditoria retroativa dos 4 previews gerou os canônicos v0.23b/v0.32b (2 erratas reais de implementação, classe da v0.13); (c) réguas permanentes novas: menu aberto nunca sobrevive à saída do foco · anel de foco interno em container com overflow · wizard termina em ação terminal nomeada · token consumido sem definição = bug de build (detectores nas 2 camadas). Pendências encerradas: AC5, fronteira do §20, promessa do §4.11, DW1. Validação acumulada: 381 verdes jsdom + 32 verificações render. Delta no CHECKPOINT_v1_2_cn_bloco5.md; vigente no ESTADO_ATUAL_SeedDS.md v1.2. Próximo: Bloco 6 (Dados — tabela, marco próprio).
Marco v1.1 fechado — Bloco 4 (Superfícies) completo 7/7
texto inteiro da versão
Marco v1.1 fechado — Bloco 4 (Superfícies) completo 7/7 (seed-componentes.md v0.32; preview v0.32; suite F 80 testes; 246 verdes acumulados). Régua de 3 degraus fechada (§23.1→§30); escala de sobreposição formalizada; drawer §31 destrava a spec da CN (F6) — backlog promovido a alta. 2 ciclos de crítica no gate visual (empilhamento H; +N/light-dismiss I) com emendas formais e testes-guarda. Delta completo no CHECKPOINT_v1_1_bloco4_superficies.md (Drive/marcos); vigente no ESTADO_ATUAL_SeedDS.md v1.1. Próximo (v1.2 duplo, escolha do Rafael): spec da CN primeiro, Bloco 5 na sequência.
Bloco 3 (Feedback e status) fechado: 11/11 estáveis
texto inteiro da versão
Bloco 3 (Feedback e status) fechado: 11/11 estáveis em seed-componentes.md v0.24 (trajetória v0.15→v0.24 num único dia; 5 sub-blocos com 3 rodadas encadeadas cada + verificações primárias GOV.UK/Material; 166 testes de suite + ~40 pares medidos; 4 ciclos de crítica visual → emendas R3-b/R3-c/X6-b/botão-morto; nota 1.13-b). Adotado o padrão delta de fechamento: marco v1.0 (CHECKPOINT_v1_0 + ESTADO_ATUAL_SeedDS criados). Central de notificações decidida (CN1–CN4) e registrada no F6 com dependência do drawer (B4). Suites de validação viram artefato em /validacao. Pendência nova: errata de rótulo no seed-tokens.md §5 (azul-700→azul-800 no par 5.79) a corrigir quando o arquivo for editado. Pontas encaminhadas: stepper→B5 (nota na linha), skeleton/empty de dataviz→F5, telemetria do delay de 1s→F4. (Correção de sincronização em 2026-08-04: cabeçalho e tabela de canônicos desta versão haviam ficado com os valores da v1.2 — data/versão, linha do seed-componentes.md e linha deste arquivo atualizados; nenhuma mudança de conteúdo.)
Bloco 2 (Formulários) fechado: 13/13 estáveis em seed-componentes.md v0.24. Trajetória: v0.6–v0.12 (specs dos 13 itens em 3+ rodadas encadeadas cada, decisões B1–B6, C1–C5, D1–D9, E1–E9, F1–F6, G1–G7, H1–H8, I1–I6, J1–J6, K1–K6, L1–L6, M1–M6, N1–N7) → v0.13 (errata da validação executada: 5 bugs de implementação corrigidos + emenda D4-b + regra do aria-invalid explícito + nota L1-b) → v0.14 (promoção dos §8–§14 após validação do Rafael em 2026-08-03). Registrados: paridade mobile como premissa estrutural, ⌘K/command palette como pattern do Bloco 5/6, pendências do Bloco 6 (densidade ERP→mobile, busca composta EUI, indeterminate), rich-text como componente futuro (F6), 7º teste (polegar) e a prática de validação executada no método. Tokens: F1 atualizada para v1.2 entregue (pacote mobile) e escalas de dataviz renumeradas para v1.3. Errata aberta nova: referência morta no sobreaseed.md.
Camada mobile/app (pacote M1–M3 aprovado pelo Rafael).
texto inteiro da versão
Camada mobile/app (pacote M1–M3 aprovado pelo Rafael). Breakpoints oficiais = escala Tailwind (sm 640…2xl 1536), canônicos no JSON + theme do Tailwind, com supersede do corte 960 do HTML v1; escala tipográfica fluida com clamp() rem+vw nos 4 topos (regra WCAG 1.4.4 embutida); --seed-fs-field-touch 16px via pointer: coarse (anti-zoom iOS); tokens de safe-area para PWA/app. Nenhum valor de cor alterado. Contexto: diretriz de paridade mobile/app declarada pelo Rafael em 2026-08-02 — apps serão produzidos e o uso mobile supera o desktop.
Bloco 1 (Botão) aprovado em v0.5 após 5 iterações dirigidas por crítica: escada de mecanismos medida (containers 1.07→≥3:1), estado selected com sinais visuais M3, correção do dark (pares de componente), método dos 6…
texto inteiro da versão
Bloco 1 (Botão) aprovado em v0.5 após 5 iterações dirigidas por crítica: escada de mecanismos medida (containers 1.07→≥3:1), estado selected com sinais visuais M3, correção do dark (pares de componente), método dos 6 testes formalizado.
Criação, após auditoria de inventário (checklists da indústria + colateral corporativo) que expandiu o escopo de 55 para 95 itens: F3 de 4→7 blocos, adições em F4–F8, exclusões deliberadas formalizadas.
texto inteiro da versão
Criação, após auditoria de inventário (checklists da indústria + colateral corporativo) que expandiu o escopo de ~55 para ~95 itens: F3 de 4→7 blocos, adições em F4–F8, exclusões deliberadas formalizadas.
Rebranding de aplicação (Fase 2 do DS v2). Hex e vetores intactos. Novidades: fundamento com 3 princípios (§2), Pantone/CMYK resgatados + errata azul-claro (§3.1), integração com tokens v1.1 (§3.2, §11), lei 70/20/10 (§3.3), hierarquia dos amarelos (§3.4), papel do azul (§3.5), contraste medido (§3.6), tipografia 2 famílias com JetBrains Mono e aposentadoria de Indie Flower/Neo Tech (§4), logo responsivo + matriz de posição (§5.2–5.3), EEny desacoplado com parcimônia (§6), Grafismo v2 de linhas (§7), fotografia real (§8), ilustração linha-primeiro (§9), linguagem editorial (§10), camada física (§12), aplicações atualizadas (§13), supersedes consolidados (§16). Morte do erp-seed-design.md. Base: auditoria do Manual 2018 + pesquisa de referência (Carbon, Polaris, Atlassian, WGSN) + decisões aprovadas pelo Rafael na conversa do rebranding. Revisão por pesquisa aplicada pré-publicação (2026-07-30): kit de favicon padrão 2026 (§5.2), esclarecimentos de aplicação da lei 70/20/10 (§3.3), papel social do EEny recalibrado — de restritivo demais para ativo estratégico com regras (§6), legibilidade quantitativa de frota (§12), clear space como razão (§5.5), pendências 5 (§17). Decisões de 2026-07-31: camada expressiva Montserrat 800/900 para display de marketing e Caveat como fonte celebratória oficial (§4.3), escolhida em comparativo real vs. Shantell Sans e Kalam — fora dos tokens por decisão (garante a fronteira de UI).
Hierarquia de uso da paleta (§3b): proporção 70/20/10 (supersede os 45% de 2018), amarelo=acento oficial vs dourado=trabalho, papel formal do azul (livre na UI/info, contido na marca, nunca ação primária). Novo grupo…
texto inteiro da versão
Hierarquia de uso da paleta (§3b): proporção 70/20/10 (supersede os 45% de 2018), amarelo=acento oficial vs dourado=trabalho, papel formal do azul (livre na UI/info, contido na marca, nunca ação primária). Novo grupo semântico accent (highlight/highlight-subtle/on-highlight). Nenhum valor de cor alterado.
Entrega inicial da Fase 1 do rebranding do DS. Rampas tonais das 6 famílias (8 cores de marca + vermelho funcional), semânticos light/dark, elevação, motion, tipografia (Montserrat+JetBrains Mono; Indie Flower e Neo…
texto inteiro da versão
Entrega inicial da Fase 1 do rebranding do DS. Rampas tonais das 6 famílias (8 cores de marca + vermelho funcional), semânticos light/dark, elevação, motion, tipografia (Montserrat+JetBrains Mono; Indie Flower e Neo Tech aposentadas), spacing/radius, dataviz. Supersedes declarados: #0d8f82 → surface-brand-deep; #2a3942 → cinza-900; hex dark ad-hoc → superfícies dark oficiais; #c63838 → vermelho-600; regra de contraste do turquesa reformulada com medição.
Reescopagem: arquivo exclusivamente visual; institucional movido ao sobreaseed.md; correção de endereço; fronteiras formais; regra das 8 cores; registro do #0d8f82.
texto inteiro da versão
Reescopagem: arquivo exclusivamente visual; institucional movido ao sobreaseed.md; correção de endereço; fronteiras formais; regra das 8 cores; registro do #0d8f82.
Ariana registrada como Líder Comercial e de Qualidade (informação declarada pelo Rafael em 17/07; corrige omissão — a liderança de Qualidade não constava). Ajustado o texto institucional longo.
Consolidação da revisão de arquivos de empresa/marca. Confirmado endereço de Governador Valadares como Rua Duarte Coelho, 205 (supersede "Rua Albânia, 81" do marca-seed.md v3.2). Absorvidos do marca-seed.md v3.2 os…
texto inteiro da versão
Consolidação da revisão de arquivos de empresa/marca. Confirmado endereço de Governador Valadares como Rua Duarte Coelho, 205 (supersede "Rua Albânia, 81" do marca-seed.md v3.2). Absorvidos do marca-seed.md v3.2 os blocos institucionais "Pilares de marca" e "Governança em 4 frentes". Adicionado exemplo de tom de voz de mensagens de sistema. Declarada formalmente a fronteira com marca-seed.md (visual), seed-design-system.html (componentes) e erp-seed-design.md (produto ERP).
Versão original consolidando identidade, cultura, portfólio, momento atual e equipe a partir da documentação interna SEED (marca, design system, site institucional).
texto inteiro da versão
Versão original consolidando identidade, cultura, portfólio, momento atual e equipe a partir da documentação interna SEED (marca, design system, site institucional).
