Roadmap
s15. Log
| Versão | Data | Mudança |
|---|---|---|
| 2.39 | 2026-09-08 | A régua refez as duas peças que a originaram — e achou três defeitos MEUS no caminho (MANIFESTO §195). Pedido dele: "refaça os 2 PDF (…) nao precisa refazer a pesquisa, apenas gere novamente o material com a skill atualizada". Conteúdo intacto (nenhum número mudou); mudou só a aplicação do DS — grafia, contraste, tamanho pelos pisos do §4.8 e tipografia. Resultado: 10 PASS · 0 FAIL · 1 AVISO em cada, contra 6 e 7 PASS com 3 e 2 FAIL nos originais. O que a régua pegou no meu trabalho: título de caixa a 4,20:1, a classe .mono a 7,4 pt (abaixo do piso que eu acabara de escrever) e a nota de capa colidindo com a serra — nenhum visível a olho, todos no placar. ⛔ Defeito do acervo achado pela produção: o subset seed da Montserrat não tem a seta → e a peça caía no Segoe UI do sistema em silêncio — regra nova na §4.5 (tela usa subset, impresso usa TTF completo) e pendência MR-P17. E, por pergunta dele ("deveria aparecer no topico conteudo e voz??"), a voz falada entra na página /conteudo-e-voz/ da vitrine: seção nova de canon que não entra na página temática nasce invisível. CP-P3 fecha do lado do DS. ⛔ E a ficha deu 10 de 10 numa peça com defeito grosseiro: ele abriu o PDF e viu que "de uma pagina para a outra nao tem margem superior" — da terceira página em diante o texto começava a 0,6 mm do topo, porque o padding estava no contêiner e não na página. Ficha não substitui olhar; e quando o olho acha o que a ficha não achou, conserta-se a ficha. Nasce o CP-11 — geometria de página: o miolo tem a mesma margem superior (o canon não publica valor, então a régua exige COERÊNCIA, não número) e não começa colado na borda; sangria total é isenta. Provado na própria peça defeituosa, que reprova com o diagnóstico exato. Peças refeitas: 11 PASS · 0 FAIL · 1 AVISO em cada. |
| 2.40 | 2026-09-09 | Segunda vez que a ficha passa limpa numa peça com defeito de página — nasce o CP-12 (MANIFESTO §196). Pedido dele depois de o computador reiniciar: "verifique se a skill está ativa, se sim, refaça os 2 PDF aplicando a skill". Skill ativa e igual à publicada (2026.09.08+09270cb6, medido contra o VERSAO.json de produção). ⛔ Com 11 PASS · 0 FAIL nos dois, a rasterização achou uma folha com 0,7 % de tinta e um subtítulo partido no meio da frase: break-inside: avoid num bloco mais alto que meia folha, que é empurrado inteiro e deixa o vazio atrás. Conserto na regra (o avoid sai do contêiner longo e vai para os blocos pequenos, com break-after: avoid no cabeçalho e no rótulo): o documento caiu de 17 para 14 folhas sem perder uma palavra. Nasce o CP-12 — folha aproveitada: piso de 5 % de tinta por folha de miolo (medido — a mais leve das corrigidas tem 5,7 %; capa e última folha isentas, com o motivo escrito) e nenhum rótulo órfão no pé. Provado em cobaia com placar declarado antes: a v3 defeituosa reprova apontando as folhas 4, 6 e 10, a v4 passa, e o outro documento passa nas duas versões (a régua não reprova em bloco). E o texto da skill ganhou o que faltava: a contagem "dez itens" saiu (contagem em prosa é denominador sem guarda) e entrou o passo olhe a peça, com o que procurar e a obrigação de declarar o que a ficha NÃO mede. Peças entregues: 12 PASS · 0 FAIL · 1 AVISO cada. |
| 2.41 | 2026-09-09 | O CP-12 errou no mesmo dia em que nasceu, e quem o pegou foi uma peça de OUTRO projeto (MANIFESTO §196.6–§196.7). Ao autorizar a mudança dos geradores dos relatórios para o repositório do seed-ads, a sessão mediu os PDF que já viviam lá — feitos por outra linhagem de scripts — e o item novo produziu dois defeitos próprios: acusou o valor R$ 13,81 de ser "rótulo órfão" (a definição era "texto curto sem minúscula", e dinheiro também não tem minúscula) e escreveu uma linha de resumo que contradizia o próprio veredito ("nenhum rótulo órfão" enquanto reprovava por um). Corrigidos: rótulo agora exige três letras e nenhum dígito, e o resumo conta as duas classes. Provado em cinco cobaias com placar declarado antes, todas batendo. A lição: régua nova só é régua depois de medir peça que ela não fez — a cobaia de dentro prova que o instrumento acha o que foi escrito para achar; a de fora mostra o que ele acusa por engano. E a medição revelou que existem duas famílias de geradores para os mesmos dois relatórios (9/3 e 8/4 contra 12 PASS · 0 FAIL da linhagem da skill): nada apagado, escolha registrada como ADS-016 na fila do seed-ads — primeira vez que o contrato CP arbitra entre duas implementações concorrentes. |
| 2.42 | 2026-09-09 | Dois marcadores de estado mentiam, e o achado veio de responder "o que temos agora?" — segunda vez que este projeto pega a mesma classe (a primeira foi a marca v5.28, em 2026-08-27, ao responder "quantas pendências temos?"). A F9.8 abria com 🔵 EM CURSO e o texto da própria célula, escrito no mesmo dia, dizia "✅ FECHADA em 2026-09-08" — o vivo é a prova (22 seções, guarda PB com cobertura 22 de 22, vencimento em 2027-03-08), marcador corrigido para ✅. A F9.10 continua 🔵 com razão, porque o fechamento do brick é veredito dele, mas a célula estava desatualizada em dois fatos MEDIDOS: falava em dez itens quando o contrato CP tem doze, e listava CP-P1 a CP-P4 como fila aberta quando as quatro fecharam por veredito dele em 2026-09-08. Lição que fica: marcador de estado é a primeira coisa que alguém lê numa tabela e a última que alguém lembra de mexer — ao fechar qualquer item, o marcador se corrige ANTES do texto. |
| 2.43 | 2026-09-09 | A F9.10 fecha e a F9.6 abre — ordem dele no chat, verbatim: "pode fechar a F9.10 e abrir a F9.6" (MANIFESTO §197). A F9.10 entrega o contrato CP com doze itens e a fila CP-P1 a CP-P4 zerada; o que ela fixa como método é maior que o instrumento — placar sai com a lista do que a régua não mede, o olho continua obrigatório, e quando o olho acha o que a régua não achou conserta-se a RÉGUA. A F9.6 abre com o reconhecimento todo medido: 29 seções (não 30), 22 absorvidas e 7 revogadas, 33 de 33 destinos conferidos, nenhum ativo morrendo (24 ícones do v1 contra 31 do v2, 23 nomes redesenhados na linguagem de linha), 404 medido em produção e um só instrumento medindo o arquivo. Achado incidental: um .pyc rastreado no repositório apesar do .gitignore, resíduo de import de gerador — entra na tabela de remoção. Lição de instrumento do dia: grep por substring precisa de fronteira de palavra — delegado casou com legado e inflou o levantamento de impacto. |
| 2.44 | 2026-09-09 | Nasce a página /marca/ — os ativos estavam públicos e invisíveis (MANIFESTO §198). Falta que ele sentiu, verbatim: "uma falta que tive no DS é o acesso as imagens da eeny, das logos, etc. nao deveria existir um menu com esses materiais navegavel?". Medido: os 27 vetores de 03-assets/ já eram servidos com HTTP 200 desde a F9.1 e nenhuma página os listava — só se chegava sabendo o nome do arquivo. Pior: o llms.txt afirmava que eles não estavam nesta superfície, falso desde a F9.1 — índice de máquina que declara ausente o que existe é a pior classe de erro do acervo, porque o agente que acredita resolve por conta própria, e "por conta própria" foi o que desenhou a logo à mão em 2026-09-08. A página é gerada, lista MEDIDA no disco, um cartão por ativo com download, a regra do canon por família e a ordem obrigatória no topo; o fundo do cartão não inverte com o tema (medido: a arte escura sumia no tema escuro) e é o único lugar da vitrine que consome um primitivo, com o motivo no CSS. ⛔ E o olho achou um defeito PRÉ-EXISTENTE que as 15 provas do contrato VT não viam: todo item do menu lateral terminava em # e um trazia entidade duplamente escapada — em /conteudo-e-voz/ e /acessibilidade/ também. Uma correção no ancora_h2 consertou 84 itens em 6 páginas. Lição paga de novo: o primeiro conserto não pegou porque o \b da expressão regular, escrito por heredoc, virou byte de controle 0x08 — placar idêntico depois de uma correção é investigação, e a resposta estava nos BYTES da linha, não no código relido. |
| 2.45 | 2026-09-09 | A revisão que ele pediu da /marca/ achou o pior defeito do dia (MANIFESTO §198.5). Ordem dele: "o menu tem nomes com numeros e outros sem (…) e revise a pagina." O menu era hierarquia, não nome: 26 itens onde há 6 seções — as outras 20 eram subseções do canon, filhas do último item, aparecendo como irmãs; a coluna passa a listar só os H2 da própria página. ⛔ E a revisão achou que o trecho do §5 exibido NA PRÓPRIA PÁGINA mandava pegar os vetores em 02_assets/, pasta que não existe desde a migração de agosto — mais o §5.4 e o §6 pelo mesmo caminho morto. A página nasceu para acabar com o "cada um se vira" e o canon dentro dela mandava procurar no lugar errado. marca-seed.md v5.44: o §5 lista onde pegar em ordem de preferência (a página, o repositório, e o espelho do Drive em terceiro com a medição RD-P1 ao lado), e a frase "duas fontes equivalentes" com três na lista perdeu o número — contagem em prosa, de novo. |
| 2.46 | 2026-09-09 | A F9.6 FECHA — o mapa de propagação final está completo. Os três itens do brick: o mapa das 29 seções do v1 para o v2 (22 absorvidas, 7 revogadas, 33 de 33 destinos conferidos), a remoção executada por veredito dele, e o LEIA-ME do v1 atualizado — que mandava procurar os canônicos numa pasta do Drive deletada há duas semanas e descrevia como "em serviço" um arquivo que acabara de sair. ⚠ Achado ao conferir o que aquele arquivo afirmava: duas pendências citadas em prosa não batiam com as filas vivas — a MR-P3 trata de outro assunto e já estava fechada; a GR-P1 não existe em fila nenhuma (a que existe é a GR-P10, resolvida). O defeito que elas nomeavam era real e está resolvido; os códigos é que eram fantasmas. |
| 2.47 | 2026-09-09 | A F9.4 FECHA — nasce o §47.6, o pacote GEO (MANIFESTO §199). O brick mandava "remedir antes de abrir", e a remedição mudou o tamanho do trabalho: o site novo já aplicou a maior parte, então o que faltava era a especificação, que não existia. O §47.6 traz MK24 (a política de robôs é escrita e nomeia cada robô, com a lista relida hoje nas páginas oficiais — apareceu o OAI-AdsBot e as duas páginas mudaram de endereço), MK25 (JSON-LD por tipo, nenhuma página do sitemap sem), MK26 (llms.txt gerado), MK27 (descoberta ativa) e MK28 (a régua mede o site servido, com denominador). ⚠ Achado grande da medição: seed.eng.br ainda serve o site ANTIGO — a camada de máquina do site novo, feita em 2026-09-05, está invisível para o mundo, porque o novo vive em novo.seed.eng.br. E a régua nasce com essa lição embutida: a primeira coisa que ela confere é o domínio, porque medir no endereço errado dá diagnóstico falso nas duas direções — foi o que aconteceu comigo hoje. |
| 2.48 | 2026-09-09 | A F9 INTEIRA fecha — 10 de 10 bricks. Com a F9.4 e a F9.6 fechadas, não sobrou brick aberto na fase: seis planejados no gate de abertura e quatro nascidos de pedido dele durante o caminho. O cabeçalho da fase ainda dizia 🔵 EM CURSO com tudo fechado — terceira vez no mesmo dia que um marcador de estado é pego mentindo (as outras duas na v2.42), o que já é padrão e não acaso: o marcador se corrige no movimento em que o último item fecha, não quando alguém pergunta. O que sobra do DS agora é fila, não fase: as pendências abertas (LC, MR, PB) e o que ele decidir priorizar. |
| 2.49 | 2026-09-10 | Bloco PB-P7·P8·P9·P10 (MANIFESTO §200) — a F9 está fechada, então isto é fila, não fase. ✅ PB-P7 FECHADA: 43 normas lidas na ficha oficial da ABNT (43 de 43 em fonte oficial) e cruzadas com o acervo: 12 mortas ainda citadas — quatro delas no selo de prancha, uma nos onze uniformes (morta há dez anos), e a NBR 5419:2015, cancelada em 10/03/2026 —, 2 com ano errado, 7 em revisão. Nasce a guarda guarda-normas.py (contrato NB, 6 itens, censo datado, tolera o registrado na PB-P11 e reprova o novo); placar de nascimento 0 FAIL · 21 AVISO · 1 NÃO MEDI, 14 FAIL em modo estrito. ✅ PB-P8 FECHADA por aplicação: seed-componentes.md v1.47 e /acessibilidade/ citam a NBR 17225:2025 ao lado da WCAG 2.2 — e o alvo de toque de 44×44 deixa de ser atribuído à WCAG (AA é 24×24; 44 é regra SEED). ⚠ PB-P9 MEDIDA: o símbolo de acessibilidade do art. 63 § 1º da LBI falta nos dois sites; a arte vai ao gate, o institucional vira pendência no projeto do site. ⏱ PB-P10 ganha o NB-5 (58 citações do 10.10.1 mapeadas; avisa a 90 dias de 01/06/2027, reprova depois). ⛔ Nasce PB-P11: corrigir as citações mortas com revisão do engenheiro responsável. Achado colateral: seed.eng.br passou a servir o site novo (MD5 idêntico a novo.); a virada não foi desta sessão; o MK28 vira história datada. Em paralelo, MR-P16: publicada a folha do gate de escuta da voz Clara (5 perguntas, referência embutida, amostras em 2 modelos e 2 escritas) — o conector não expõe parâmetro nenhum, então a recomendação é fixá-los NA VOZ, uma fonte só. Aguarda as respostas dele. Nascem também a guarda guarda-bytes-controle.py (contrato BC — o heredoc gravou bytes de controle três vezes em 48 h, e a régua achou um de duas semanas dentro do marca-seed.md) e a PR-P5: o rito de fechamento vira UM script com código de saída, porque a guarda-grafismo.py listada no rito não rodou no fechamento de 2026-09-09 e /marca/ foi publicada vermelha (§200.6, §200.8). |
| 2.50 | 2026-09-11 | MR-P16 FECHA por gate de escuta (MANIFESTO §203; marca v5.45; práticas v1.5). Modelo eleven_multilingual_v2; os cinco parâmetros fixados NA VOZ (50 % · 75 % · 0 · boost ativado · 1,0 — os padrões da API: a voz nunca tinha sido ajustada); escopo comunicação + ERP + telefonia/URA, com as fronteiras escritas; roteiro de locução escrito para ser falado; registro de modelo, parâmetros, semente e roteiro por locução. E a varredura da fila do mesmo dia (§202): LC-09, PB-P4, PB-P6, GT-P1 e PR-P5 fechadas — o rito é fechar.sh; MR-P17 e PB-P9 medidas para decisão dele; LC-05 vai a gate com renders. |
| 2.51 | 2026-09-12 | Nasce a F10 — Material: vidro e metal (MANIFESTO §204; pesquisa em 09-pesquisa/material-vidro-metal-2026-09-12/). Pedido dele: "Estou achando as telas criadas com o DS muito basicas (…) Faça uma pesquisa profunda sobre aplicação de liquid Glass metalizado em DS de grandes empresas (…) e gere 2 exemplos". Pesquisa em 13 fontes datadas (Apple Liquid Glass e os três recuos, NN/g 2024 e 2025, Fluent/Acrylic, Material 3 Expressive, Atlassian, Carbon, Fiori Horizon, SLDS 2, visionOS, One UI 8.5, tendência cromo) — 0 de 8 DS corporativos usam metal em controles; o par renderizado (shell §46 + painel §48, claro e escuro, vivo, com controles de calibração) foi ao gate como Artifact. Veredito: V-1 = B (adotar inteira), V-2 80 %/72 %/18 px, V-3 tudo menos a sidebar, e o achado dele no rail (listras = moiré do escovado de 1 px) consertado no mesmo dia. Seis bricks e cinco pendências MA-P1..P5; a régua de contraste rasterizado (F10.3) bloqueia a promoção a canon. |
| 2.53 | 2026-09-12 | F10.2 fecha e F10.4 é entregue em gate (MANIFESTO §206) — o material entra no canon e nas duas primeiras telas no mesmo dia. F10.2: seed-componentes.md v1.48 ganha a §93 "MATERIAL — vidro e metal" (MA1–MA12: onde vai vidro, onde vai metal, o que fica opaco, fundo com luz só na casca, movimento desligável, fallbacks no token, régua obrigatória, emissão pelo módulo único, tinta de marca -strong no vidro, nada de textura de período fixo, calibração por peça, alcance). F10.4: nasce material_bloco.py (uma implementação por peça; tokens medidos no gêmeo; fallbacks extraídos verbatim; aborta se faltar token — NV-01 mecanizado), gen-shell.py v0.9 e gen-painel.py v0.16 emitem a camada e declaram data-material; a régua RC roda nas duas telas no rito e devolve zero texto abaixo do piso nos dois temas. O que a régua mudou no caminho: MA-P6 fechada no gerador (errata E-CF-06 no §46: a conta de 9 caracteres do SH3 era de 9 px; a 11 px só cabe com o tracking do papel); a tinta de marca dentro do vidro vira text-brand-strong por escopo (§5-g; 9 textos em 4,42–4,49); tokens v1.25 — a luz do canvas escuro cai de 40/26 % para 26/18 % (o micro-rótulo text-secondary do primeiro KPI media 4,41; medido em quatro intensidades) e a nota de calibração do §3d ganha errata (sobrescrever --seed-mat-metal no escopo não calibra nada: o var() resolve onde é declarado — a régua devolveu os mesmos números em 1, 0,7 e 0,4; a calibração reemite os tokens no escopo). Dois instrumentos ajustados com o motivo escrito: a casca guarda surface-subtle declarado (o render-contraste media texto contra o body, 1,79 falso) e a guarda-colisao deixa de tratar fundo recortado por texto como fronteira. Nasce SH-P9 (peso 800 sem face). Aberto: o gate visual da F10.4 (duas telas × dois temas · calibração do rail 1/0,7/0,4 · sidebar), F10.5, F10.6, MA-P2, MA-P3, MA-P4. |
| 2.52 | 2026-09-12 | F10.1 e F10.3 fecham (MANIFESTO §205). F10.1: a camada de material vira 18 tokens --seed-mat-* (seed-tokens.md v1.24 §3d; grupo semantic.mat; paridade 110 PASS · 0 FAIL; fallbacks executáveis no gêmeo); o fundo com luz é derivado da rampa turquesa e o 20 % de metal do gate não virou valor. F10.3: nasce a régua de contraste rasterizado (contraste-raster.mjs, contrato RC — duas capturas, máscara de glifo por diferença, pior pixel) e a nona guarda do rito (guarda-material.py), com cobaia de placar escrito antes. A MA-P1 foi medida: sobre vidro e luz nenhum texto cai abaixo do piso; o custo está nos rótulos do rail sob o reflexo (7,47 → 4,79). Achado no canon: o rótulo ativo do rail vaza 1 px da pílula (2,08) — MA-P6, conserto no gen-shell.py na F10.4. Bloqueio da promoção a canon levantado. |
| 2.38 | 2026-09-08 | A voz FALADA da marca entra no canon — marca-seed.md §9-B (v5.41) e seed-praticas.md §19.4 (v1.3), MANIFESTO §194. Pergunta dele: "temos uma voz oficial da Clara no EllevenLabs, esse tipo de informação vai no DS?". Vai — pelo mesmo motivo do logotipo: duas locuções diferentes soam como duas empresas. Registrada com o dado lido na fonte pelo conector: Clara — Voz Oficial SEED, identificador dAX8JJOgGutSLfY2AkgK, voz clonada, pt. O identificador não é credencial (nomeia, não dá acesso) e por isso vive no canon; a chave da API continua proibida, e a URL de pré-escuta devolvida pelo conector não entrou por ser assinada e expirável. Cinco regras, entre elas: a voz não narra laudo nem parecer assinado, porque responsabilidade técnica tem nome e CREA. Nasce MR-P16: parâmetros de geração e escopo de uso não decididos — vai a gate de escuta, duas versões lado a lado. |
| 2.37 | 2026-09-08 | Fila CP: três das quatro pendências FECHAM por veredito dele no mesmo dia (MANIFESTO §193.8). CP-P1 — "pode adotar a tabela acima": nasce o §4.8 do marca-seed.md (v5.40), o piso tipográfico por classe de peça que o canon nunca teve para impresso. 12 pt em cláusula contratual é lei (CDC art. 54, § 3º); altura = distância ÷ 200 e 15 a 50 mm em sinalização são norma (ABNT NBR 9050:2015/Em1:2020, 5.2.9.1.3, que também confirma sem serifa e caixa alta e baixa — a regra de bolso da §23 do seed-praticas.md ganha fonte); 10 pt em texto corrido e 8 pt de piso absoluto são convenção, escolhidas com custo medido (8 pt custa 10 % e 15 % dos trechos; 12 pt custaria 96 % e 97 %). O CP-3 deixa de avisar e reprova. CP-P2 — "providencie o que falta, nao precisava nem me perguntar": o conferidor passa a ler SVG (família de fonte pela DECLARAÇÃO, porque o MuPDF substitui fonte na leitura) e HTML (impresso pelo Chrome, que é o caminho real de produção); o CP-10 passa a distinguir documento de peça. Provado: SVG com defeito plantado reprova nos itens certos, e a peça aprovada placa-obra-1000x500mm.html passa 10 de 10 com o símbolo oficial reconhecido a 0,983. CP-P4 — "adicione a regra que vc citou": identificador de plataforma pode em relatório para quem já tem acesso à conta, não pode em peça pública, nunca ao lado de token; entra no CLAUDE.md do projeto e o CP-9b segue como AVISO. CP-P3 fica com ele (vai solicitar o refazimento); e a dúvida dele sobre a skill foi medida na documentação oficial: o Claude Code observa os diretórios de skill e lê o SKILL.md a cada invocação — não precisa limpar a sessão, basta invocar de novo. |
| 2.36 | 2026-09-08 | F9.10 — a peça PRONTA passa a ser medida (contrato CP), por ordem dele (MANIFESTO §193). Outra sessão do Code produziu dois PDF com a skill seed-ds e desenhou a logo à mão, com o SVG oficial dentro do próprio pacote. Veredito verbatim: "Se existe uma skill de DS da seed instalada, é primordial usar as regras do DS para tudo, nao tentar inventar algo (…) isso é inadimissivel." E a pergunta que definiu o trabalho: "se as capas ficaram erradas, fico questionando o que mais ele deixou de aplicar na criação" — que não tinha como ser respondida, porque a skill tinha a regra e não tinha teste. Nasce o conferir-peca.py: dez itens medidos no arquivo que vai ao cliente (cor · tipografia · tamanho · contraste contra o fundo amostrado · marca por sobreposição com o asset oficial · grafismo contra o gerador · grafia · dado institucional · segredo · camada de máquina), com ficha de conformidade e quatro estados (PASS · FAIL · AVISO · NÃO MEDI). A skill muda em três lugares: a regra de ouro nº 3 ganha a ordem obrigatória (asset → gerador → pedido de cobertura → provisório declarado) e a frase "desenhar à mão um elemento de marca é reprovação automática"; a checagem deixa de ser caixa de marcar e passa a exigir a ficha; e o pacote leva o conferidor e o token cru. Cobaia: os dois PDF reais — a régua achou quatro defeitos próprios antes de acusar a peça (o 0800 casando dentro de um id de 18 dígitos; um ` |
| 2.35 | 2026-09-08 | F9.8 FECHADA — a onda 5 escreve as OITO bases novas do V-B2 e a base vai a v1.2, com 22 seções (MANIFESTO §192). Pedido dele, verbatim: "continue com a onda 5". Diferente das quatro ondas anteriores, que auditavam texto herdado, esta escreveu do zero sob a mesma régua de prova. Nasce a quinta etiqueta [norma] — lei, resolução de conselho, norma regulamentadora e norma técnica, sempre com número, ano da edição, órgão emissor e data de leitura —, admitida pela guarda PB. Os achados de primeira mão: ⛔ a Resolução CONFEA 1.025/2009, que boa parte do mercado ainda cita para laudo e ART, está revogada desde 2023, e a palavra "laudo" aparece zero vez na resolução que a substituiu (medido); ⛔ a NR-10 está em transição e o arquivo oficial engana — o nr-10.pdf do gov.br já é o texto novo, cuja vigência só começa em 01/06/2027, e nele o gatilho de 75 kW do Prontuário sai; ⛔ a NR-26 não tem tabela de cor — as palavras "vermelho", "amarelo", "verde" e "azul" aparecem zero vez no texto de 2022 (medido), o que invalida a tabela que circula como sendo dela; ⭐ existe norma brasileira de acessibilidade digital desde 11/03/2025 (ABNT NBR 17225, alinhada à WCAG 2.2), e o acervo mede só pela WCAG; ⛔ música em conta de empresa é proibida sem licença na Meta e no TikTok, e o som da biblioteca comercial do TikTok não pode sair do TikTok; ⭐ o Instagram publicou uma consequência de distribuição — "reels com mais de três minutos não serão recomendados para novos públicos"; ⛔ a Meta proíbe perguntar sobre a situação financeira de quem vê o anúncio, que é a fórmula clássica do anúncio de energia; e Gmail (01/02/2024) e Outlook (05/05/2025) convergiram no mesmo pacote de autenticação e cancelamento acima de 5.000 mensagens/dia. Pendências novas: PB-P7 (edição vigente das NBR no catálogo da ABNT), PB-P8 (citar a NBR 17225 ao lado da WCAG no canon?), PB-P9 (o símbolo de acessibilidade que o art. 63 da LBI exige nos sites da casa) e PB-P10 (a sinalização elétrica muda de item na NR-10 em 01/06/2027, e as peças sinalizacao-nr10 e placa-quadro precisam ser revistas antes disso). |
| 2.34 | 2026-09-08 | F9.8, onda 4: as §12 a §14 auditadas — as 14 seções importadas fechadas e a base em seed-praticas.md v1.0 (MANIFESTO §191; cobertura da guarda PB 14 de 14). Pedido dele, verbatim: "continue com a §12 a §14". ⛔ (1) Metade da escala tipográfica não existia no design system — a §12 prescrevia 11/13/16/18/20/24/30/36 e quatro não existem, entre eles o do corpo de texto: mandava 13 px onde o DS tem 14 (font.size.body); 30 e 36 contra os 32 e 42 reais. A mesma seção listava "spacing arbitrário (13px…)" como anti-padrão enquanto prescrevia 13 px. ⛔ (2) A §13 foi a seção com mais achado grave do arquivo: o catálogo "sintético" trazia nomes de organizações reais com valor de contrato inventado ao lado, o nome do próprio decisor como cliente PF com CPF falso, um organograma fictício que não é a equipe da SEED, e 0 de 10 CNPJ válidos numa seção que exigia dígito plausível. A regra nova é o contrário da antiga: dígito deliberadamente inválido, porque CNPJ válido pertence a alguém; nome de organização conferido para não existir; nenhum nome de pessoa real; e marca "dados ilustrativos" em todo mockup que sai da casa. ⛔ (3) A §14 tratava o apelido do shadcn como fonte do token — a fonte são as 575 variáveis --seed-*, os 32 apelidos são camada derivada, e a regra canônica é o §44 do seed-componentes.md; o consumo hoje é pelo registry publicado em ds.seed.eng.br/r/, que em maio não existia. ⚠ (4) Nasce a PB-P6: roadmap e sobreaseed.md discordam sobre a plataforma do ERP (Vite/TanStack contra Lovable). ⚠ (5) §12 e §14 se contradiziam sobre acessibilidade — a §14 estava certa (2.5.8 pede 24 × 24 px em AA; 44 × 44 é AAA), e a casa mantém 44 × 44 por decisão própria. Com esta onda a regra de versão do próprio arquivo dispara e a base vira v1.0; o cabeçalho foi reescrito porque a frase "ainda não foi auditada seção a seção" virou falsa. Falta a onda 5: as oito bases novas do V-B2. |
| 2.33 | 2026-09-08 | F9.8, onda 3: as §10 e §11 auditadas (MANIFESTO §190; seed-praticas.md v0.6; cobertura da guarda PB de 9 para 11 de 14). Pedido dele, verbatim: "continue com a §10 e §11". Três classes de defeito novas. ⛔ (1) A base tinha criado uma oferta comercial sozinha: um modelo pronto para copiar prometia "diagnóstico das primeiras 3 faturas em 1 semana, sem custo se não houver oportunidade clara" — prazo e trabalho gratuito que não vieram de decisão dele nem de canon nenhum. Número falso é afirmação errada; oferta é compromisso. Removida. ⛔ (2) A estatística que a seção usava para contrariar a decisão comercial dele é de 1942 — os "80 % das vendas exigem cinco retomadas" vêm de uma enquete de menos de 40 participantes sobre venda de porta em porta, e a seção mandava responder a ele "não, está estatisticamente cedo demais". Fica a regra: a base informa, não decide. ⚠ (3) O respaldo legal do contato frio não está resolvido e era tratado como se estivesse — nasce a PB-P5, para quem tem competência; a base não opina sobre base legal. Sete números dentro de modelos viraram marcadores, mais um prospecto com nome próprio e uma notícia inventada. Terceira ocorrência do empresa.md de maio como fonte de consulta, corrigida. Melhor colheita de estudo da base até aqui: Sparkle (81.966 e-mails, comparando formas de escrever — identificar-se primeiro 4,46 % contra 1,80 %; retomada simples 3,63 % contra 1,46 %; uma pergunta 1,81 % contra 1,21 %) e o Super Panorama Mobile Time / Opinion Box de junho/2026, o único estudo brasileiro da base: 4.138 donos de smartphone, coleta de 4 a 24 de março de 2026, margem de 1,5 p.p., WhatsApp em 98,3 % dos aparelhos. |
| 2.32 | 2026-09-08 | F9.8, onda 2: as §6 a §9 auditadas (MANIFESTO §189; seed-praticas.md v0.5; cobertura da guarda PB de 5 para 9 de 14). Pedido dele, verbatim: "continue com a §6 a §9". Onde a onda social derrubou estatística, esta derrubou contradição com o próprio canon, e o achado já saiu do papel: ⛔ cinco das treze cores da biblioteca de slides não existem mais no seed-tokens.json — a pior é o texto principal, #2a3942 contra o #0B3330 vivo, o que significa que todo deck e toda proposta gerados a partir dessas seções escreveram o corpo de texto fora da marca, em todas as páginas, sem nada acusar. Correção de raiz: a §7.0 passa a derivar a cor do arquivo de token (função token()) em vez de digitá-la. ⛔ Os dois caminhos de arquivo de logotipo estavam errados (faltava o prefixo logo-), ⛔ a tagline do fechamento pedia Indie Flower, aposentada em 2026-07-30, ⛔ a §8 mandava conferir o endereço da sede no empresa.md de maio — o arquivo que carrega justamente o erro da matriz que ele corrigiu em 2026-08-24 — e ⛔ a regra de cor de gráfico usava tinta de borda de interface, quando o seed-dataviz.md tem o DG17 e a lei "posição categórica nunca serve de neutro". Pela segunda vez em dois dias apareceu um estudo real com crédito e objeto errados: os "202 % melhor" são da HubSpot (330 mil chamadas para ação em seis meses), não da "Martal 2026", e medem botão de página web, não proposta em PDF. Saíram por falta de fonte os 61 % da Gartner, os 43 % da McKinsey, o caso único de fornecedor, a curva de atenção, os 60-70 % do sumário, as taxas de conversão B2B, os 92 % e o parcelamento "padrão de mercado". Ficou de pé, etiquetado como escola de ofício: Duarte, Minto, Tufte, Reynolds, Handal, PROLINK e Xait. Pendência nova PB-P4 (a série do código da proposta, que o ERP vai precisar emitir). |
| 2.31 | 2026-09-08 | F9.8, onda social: as §2 a §5 auditadas (MANIFESTO §188; seed-praticas.md v0.4; cobertura da guarda PB de 1 para 5 de 14). Pedido dele, verbatim: "continue com a §2 a §5". Dezoito afirmações de desempenho sem fonte saíram; três estudos com amostra e período entraram. Cinco achados mudam a produção: (1) carrossel tem três tetos — 20 no post orgânico, 10 pela API, 10 no anúncio de feed, 3 no anúncio de Stories — e o arquivo trazia dois deles em contradição entre a §3 e a §4; convenção nova: desenhar até 10, o teto comum aos três caminhos; (2) ⛔ o anúncio em carrossel reordena os cartões sozinho — o interruptor "destacar cartão do carrossel" vem LIGADO por padrão — e as seis estruturas narrativas da §5 dependem da ordem: a §3.3 passa a exigir a instrução de desligar por escrito na entrega; (3) ⛔ a grade do perfil do Instagram corta em 3:4, não em quadrado — medição direta no perfil @seedengenharia (12 miniaturas de 311 × 414 px = 0,750), o que corrige a §1 escrita no dia anterior; (4) ⛔ a linha "1.92 % carrossel · 1.74 % Reels · 1.22 % imagem" tinha três erros: estudo de 2020, o 1,74 % é de imagem e o 1,22 % não existe no estudo; (5) ⛔ dois casos de cliente inventados dentro de modelos prontos para copiar, um rotulado "caso real" — agora todo número de exemplo é marcador e case exige dado em documento da SEED + autorização do cliente + revisão do engenheiro responsável. Fora também o "8.25 segundos de attention span" (o mito do peixinho dourado, desmentido pela BBC) e toda a classe de limiar de algoritmo, que plataforma nenhuma publica. Canal novo descoberto: o artigo da ajuda do Instagram renderiza em facebook.com/help/instagram/<id> — segundo furo na limitação da §1.6. |
| 2.30 | 2026-09-07 | PB-P3 autorizada e medida: o canal abre, o dado ainda não vem. Ele liberou a permissão (quatro ferramentas de LEITURA do conector de anúncios da Meta; as que criam anúncio e gastam dinheiro continuam pedindo autorização a cada vez) e a sessão testou na hora: a comparação com anunciantes semelhantes devolve "sem dado para os critérios" em quatro janelas (padrão, histórico completo, últimos 28 dias e com objetivo de geração de cadastro); a de leilão devolve a coorte correta e lista os anúncios em veiculação, mas as três classificações — qualidade, taxa de engajamento e taxa de conversão — voltam como "ainda não disponível", porque os anúncios são novos. A conta NÃO está vazia (há campanhas ativas com entrega nos últimos 90 dias), então a ausência é de volume na coorte, não de acesso. Consequência para a F9.8: a fonte de primeira mão de desempenho por tipo de anúncio está aberta e silenciosa — as seções seguem com as quatro etiquetas e sem número de desempenho até ela falar. O limiar de entrega que a Meta exige para publicar as classificações não foi conferido na fonte nesta sessão (a busca da central de ajuda não achou o artigo) — fica [não conferido]. |
| 2.29 | 2026-09-07 | A pista dele abriu três canais da Meta, e um deles corrigiu a §1 no mesmo dia (MANIFESTO §187). Ele escreveu, verbatim: "nunca acessei, mas me disseram que da pra acessar através da meta brandmarket ou algo do tipo que mostra sobre performace de tipos de anuncio. estanda sua pesquisa a isso" — e a pista valeu mais que o nome. Provados: texto dos artigos da central de ajuda (o conteúdo, não o resumo do buscador) e a Biblioteca de Anúncios (31 anúncios ativos de engenharia elétrica no Brasil, com página, data e endereço público de cada um). O terceiro, a comparação com anunciantes semelhantes, foi bloqueado pelo classificador e virou PB-P3. ⛔ O canal de ajuda desmentiu a §1 no mesmo dia: os "14 % / 35 % / 6 %" que ela afirmava vieram do resumo do índice de busca, não do artigo — o único percentual publicado é 40 % da base, para Reels com aviso legal. seed-praticas.md v0.3 corrige, acrescenta as especificações de Stories e fixa a regra: resumo de índice de busca não é fonte. Nascem PB-P2 e PB-P3. |
| 2.28 | 2026-09-07 | Vereditos da F9.8 e a onda 1 começada (MANIFESTO §186). V-B1 = A · V-B2 = as oito bases · V-B3 = A · veto: nenhum. No campo do veto ele não vetou: redefiniu o alvo — a base tem de ensinar a produzir cada tipo de conteúdo por PLATAFORMA (post do Instagram, Reels, post do TikTok, post do LinkedIn), trazendo as regras de postagem e o que os melhores do mercado, os que têm resultado, estão fazendo. Consequências: nasce a régua das quatro etiquetas; o custo sobe de ≈ 3 para ≈ 7,2 sessões (declarado antes de começar, para que cortar escopo seja escolha dele e não surpresa); e nasce a pendência PB-P1, porque desempenho de conta de terceiro a sessão não consegue medir — o resultado que a SEED pode medir é o dela. Entregue nesta rodada: §1 auditada (seed-praticas.md v0.2 — quatro divergências corrigidas, entre elas a chamada para ação de Story que estava dentro dos 35 % da base que a zona de segurança da Meta reserva) e a guarda guarda-praticas.py (contrato PB), que lê a data de revisão de cada seção e acusa a vencida no fechamento de todo brick — provada em cobaia (--hoje 2027-06-01 reprova as 14). |
| 2.27 | 2026-09-07 | F9.8 ABERTA pelo Reconhecimento (MANIFESTO §185), por ordem dele no fim da mensagem das correções do menu: "feito isso, abra F9.8". O censo do seed-praticas.md v0.1: 14 seções, 177 KB, nenhuma auditada contra o DS v2, todas vindas da mesma fonte de 13/05/2026 (117 dias) e quatro citando hex de cor. As bases que faltam saíram de CRUZAMENTO, não de palpite de mercado: o que a SEED comprovadamente produz (peça do §12, canônico, site) contra o que as 14 seções cobrem — a maior lacuna é documento técnico de engenharia (o §12 dá a forma do laudo, do memorial e do as-built; como se escreve um não está em lugar nenhum), seguida de fotografia de obra (quatro peças pedem "rol de fotos" e nenhuma diz como a foto tem de ser) e acessibilidade fora da tela. Aguarda o veredito das três perguntas. |
| 2.26 | 2026-09-07 | A rodada de correções dele sobre o menu lateral da F9.9 (MANIFESTO §184). Seis pedidos numa mensagem só, verbatim: "fixe barra superior" · "porque em tokens nao tem menu lateral?" · "componentes vc pode manter o filtro no centro, mas tbm está sem menu lateral" · "telas e peças, onde a ordem do conteúdo é indiferente, organize o menu esquerdo em ordem alfabetica. (aplique em outros que possam ser assim tbm)" · "tem alguns com letras maiusculas e outras com minusculas, padronize" · "Não achei o botao no rodapé para as solicitações". Aplicados: barra superior fixa de 640 px para cima (a 390 px ela mede 177 px e comeria um quinto da tela — medido, exposto a veto); coluna própria em /tokens/ e /componentes/, que não têm H2 no corpo (a coluna vai de 343 para 345 das 347 páginas); ordem alfabética em Telas, Peças e Canônicos (Componentes não — o § agrupa por bloco); caixa dos títulos padronizada no CANÔNICO (marca-seed.md v5.39, 14 títulos do §12), não na exibição; o pedido de cobertura vira BOTÃO no rodapé. Guarda nova VT-15 (o botão em 347 de 347) e a VT-14 deixa de adivinhar o tipo do menu. Instrumento novo medida-barra-fixa.mjs: 24 de 24 combinações de página × largura sem vazamento — e ele achou um vazamento REAL de 40 px em /componentes/ a 1024 px, que a coluna nova criou (grade de cartões com trilha 1fr). |
| 2.25 | 2026-09-07 | F9.9 FECHADA — o menu lateral esquerdo está no ar (MANIFESTO §182 vereditos, §183 construção). Vereditos dele, verbatim: "V-A1 (variante): A — V2 (menu da seção à esquerda + 'nesta página' à direita)" · "V-A2 (seções sem páginas filhas): A — a coluna mostra os subtópicos da própria página" · "Veto ao aplicado: nenhum". A coluna esquerda passa de 288 para 343 das 347 páginas (ficam sem ela o início, o 404 e as duas páginas sem nenhum H2 no corpo); o trilho "nesta página" aparece à direita a partir de 1200 px; no celular a coluna vira gaveta fechada, com aria-expanded sincronizado. Todo H2 do corpo ganha âncora (356 não tinham). Guarda nova VT-14: 343 páginas com coluna, 0 defeitos — e ela achou, antes do ar, os 12 índices de canônico que não marcavam item atual (nasce o "Visão geral"); a VT-5 teve o denominador corrigido para contar só os cartões. |
| 2.24 | 2026-09-07 | F9.9 ABERTA pelo Reconhecimento (MANIFESTO §181). O pedido dele era ambíguo em um ponto que a medição resolveu: o menu lateral das páginas de canônico NÃO é sumário de página — cada seção do canônico é uma página, e aquele menu já é navegação entre páginas; o que falta é o mesmo nas outras nove seções, onde as páginas filhas são cartões no meio do corpo (74 em Componentes, 31 em Peças, 17 em Telas). Estudo de mercado datado, medido no HTML servido e no navegador com viewport emulado (Primer, MDN, shadcn/ui, IBM Carbon, Tailwind, GOV.UK, Polaris, Atlassian, USWDS, Stripe): a coluna esquerda é navegação entre páginas em todos, o sumário da página fica à DIREITA em nove, e a largura vive entre 225 e 308 px (a vitrine já usa 250). Três variantes renderizadas com o CSS real (V1 menu da seção ≈ 0,8 sessão · V2 com trilho "nesta página" ≈ 1,4 · V3 árvore colápsavel ≈ 1,9), 12 de 12 combinações cabem nas quatro larguras. Gate de abertura em endereço NOVO de Artifact, com carimbo de versão (regra do §180.3). |
| 2.23 | 2026-09-07 | F9.7 FECHADA — veredito dele verbatim no MANIFESTO §180: "V-F1 (fechamento): A — aprovada; a F9.7 fecha e a próxima abre pelo Reconhecimento" · "V-F2 (ordem da F9.9): A — F9.9 (menu lateral) antes da F9.8" · "Veto ao aplicado: nenhum". A F9.7 é o canal de entrada de pedidos de cobertura (quando o canon não cobre algo, a pessoa ou a IA avisa por ds.seed.eng.br/pedidos/); ficou provada com quatro envios reais. A F9.9 (menu lateral esquerdo da vitrine com os subtópicos) passa a ser a próxima etapa e a F9.8 (bases de boas práticas) vem depois dela. Correção de acesso pedida por ele no mesmo movimento (§180.2, verbatim: "nao achei no site onde está o botao de acesso aos pedidos (…) talvez nao seja no cabeçalho, mas sim no rodapé"): a /pedidos/ entra na barra do RODAPÉ, presente em todas as páginas da vitrine — antes só era alcançável de dentro de três páginas específicas. |
| 2.22 | 2026-09-07 | F9.7 CONSTRUÍDA (MANIFESTO §179): o receptor é a migration B5-01 do repositório do site (private.ds_pedidos, série PC-AAAA-NNNN, RPC ds_pedido_registrar para anon com os tetos do B4 e o IP lido de request.headers — provado no vivo: ip_visto true, a saída C não foi necessária); a página /pedidos/ (formulário direto na RPC + a fila LC gerada desta tabela + endereço para qualquer IA); a skill com a 1ª linha ref: seed-ds <versão> · <data>, /pedidos/ no lugar do e-mail e scripts/enviar-pedido.py (mostra, exige --confirmo); o leitor triar-pedidos.py (a IA lê todos e julga pelo mérito — obs dele na Q2). Provas reais PC-2026-0001/0002/0003/0004 (a última no domínio, em produção). Gate de fechamento publicado. Nasce a F9.9 — menu lateral esquerdo da vitrine com os subtópicos (pedido dele no chat, verbatim na linha); a ordem em relação à F9.8 vai ao gate de fechamento da F9.7. |
| 2.21 | 2026-09-07 | F9.7 ABERTA pelo Reconhecimento (MANIFESTO §177): medido o que existe — a fila LC já é pública na fatia F9 deste roadmap; a vitrine é estática; o site já tem o receptor (Supabase "SEED Site", RPC lead_registrar com tetos por IP e global, série CT-, migrations com replay e pgTAP na CI); o PostgREST expõe request.headers à função (docs v13, 2026-09-07) — falta só provar que o gateway repassa o IP do navegador. Desenho em cinco itens (página /pedidos/, RPC irmã ds_pedido_registrar com série PC-AAAA-NNNN, skill com ref: e enviar-pedido.py, leitor da sessão, prova), custo ≈ 1,1 sessão. Gate: Q1 campos · Q2 referência e spam · Q3 fila pública · Q4 receptor. §176.4: guardas em produção do commit 7f14f61 — VT 13 · SK 11 · CI 9 · RG 7 PASS. |
| 2.20 | 2026-09-06 | O consumidor de IA é qualquer agente — regra explícita depois do erro na página /skill/ (ordem dele, MANIFESTO §176): seed-componentes.md v1.45 ganha o MK23 no §47 (audiência "qualquer IA", caminho por endereço primeiro, checagem com quatro verbos: achar, ler, citar e USAR); guarda transversal consumidor_unico.py (VT-13 na vitrine e no llms.txt, SK-11 na skill) provada em cobaia contra a primeira versão da página; checklist de nascimento de superfície no CLAUDE.md; SKILL.md com a regra de ouro 7. Restos do vício corrigidos (aside do início, .md da página, seção do llms.txt). Próximo: F9.7 pelo Reconhecimento. |
| 2.19 | 2026-09-06 | Nasce a F9.8 — atualização e ampliação das bases de boas práticas (pedido dele, MANIFESTO §174): pesquisa datada de cada uma das 14 seções do seed-praticas.md, levantamento de mercado das bases que faltam, ciclo de revisão (PR-P1 absorvida). A skill ganha a regra explícita "base de boas práticas primeiro, internet só para o que a base não tem", com a tabela tema → seção gerada do índice, e o modo código passa a citar o §14. |
| 2.18 | 2026-09-06 | Página /skill/ na vitrine (item "Skill" no menu, botão de baixar o zip, instalação por superfície) e VERSIONAMENTO da skill com aviso e atualização — dois pedidos dele no chat (MANIFESTO §172): a skill compara a própria versão com o VERSAO.json publicado em todo uso com rede; no Claude Code oferece scripts/atualizar.py (MD5 de cada arquivo conferido antes de trocar a pasta); onde não dá para trocar arquivos, avisa e aponta /skill/. SK-7 exige metadata.versao = versao_skill. |
| 2.17 | 2026-09-06 | Rodada das correções LC (autorizada por ele no §170, V-F2 = A; MANIFESTO §171): LC-03 e LC-08 na marca v5.38 (corpo de slide em text-secondary; eyebrow em cinza-600, 4,74:1), LC-06 no componentes v1.44 (tinta do botão primário text-on-action-primary no §1.3, §1.9, §1.10 e §54), LC-07 no gen-camada-ia.py (o tokens.md ganha a seção das variáveis só do CSS; CI-6 ajustada). Expostas a veto no relatório. |
| 2.16 | 2026-09-06 | F9.5 FECHADA — veredito dele verbatim no MANIFESTO §170: "A — aprovada; a F9.5 fecha e as sete podem ser apagadas agora"; correções LC-03/06/07/08 autorizadas para a rodada seguinte sem folha própria (expostas a veto no relatório); veto: nenhum. As sete skills de 2026-05-13 foram apagadas por nome (§170.2) depois do substituto provado. Ordem seguinte: rodada das correções LC → F9.7 (roadmap público e entrada de pedidos) → F9.4 (GEO do site, remedir) → F9.6. |
| 2.15 | 2026-09-06 | Nasce a F9.7 — roadmap público e entrada de pedidos de cobertura (decisão dele no chat, MANIFESTO §169.5): a demanda que a skill seed-ds gera passa a entrar por um formulário público na vitrine (a pessoa cola e envia; no Claude Code a skill envia com autorização), com código de referência para filtrar spam, receptor só de inserção e a fila LC visível sem os textos. Correção de registro: até a F9.7 existir, o pedido vai por e-mail e a linha LC é criada pela sessão à mão — não havia recebimento automático. PR-P1 registrada (automação parcial da manutenção do seed-praticas.md, veredito manual). |
| 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.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. |
| 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.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. |
| 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 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. |