Ir ao conteúdo
SEED engenhariaDesign System

Roadmap

s14. Log

seed-ds-roadmap.md v2.14 · §s14seção 15 de 15s14-log.md · MD5 083998b2
Versão Data Mudança
2.14 2026-09-06 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.py10-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.
2.13 2026-09-06 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").
2.12 2026-09-06 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.
2.11 2026-09-06 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.
2.10 2026-09-05 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.py10-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-P1VT-P3 registradas.
2.9 2026-09-05 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.
2.8 2026-09-05 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.
2.7 2026-09-05 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.
2.6 2026-09-05 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.
2.5 2026-09-05 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.
2.4 2026-09-05 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.
2.3 2026-09-04 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.
2.2 2026-08-27 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.
2.1 2026-08-22 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.
2.0 2026-08-10 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ção escuro+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) · DM3 inversã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 · DM4 role="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.
1.9 2026-08-09 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.py 29 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.py 43/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.
1.8 2026-08-08 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 &nbsp; 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).
1.7 2026-08-07 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.html v0.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-render abortou 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).
1.6 2026-08-06 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.
1.5 2026-08-06 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).
1.4 2026-08-05 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.
1.3 2026-08-04 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.)
1.2 2026-08-03 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.
1.1 2026-07-31 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.
1.0 2026-07-31 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.
Esc