Atualizações
437 versões, 12 canônicos, uma linha do tempo
Derivada dos changelogs de cada canônico — nunca escrita à mão. Em ordem de data; o resumo é a primeira frase em negrito da própria entrada, e o texto inteiro está dobrado logo abaixo. Assine o feed Atom.
Entradas por canônico: Roadmap 179 · Componentes 79 · Marca SEED 70 · Tokens 41 · Dataviz 22 · Boas práticas 20 · E-mail 12 · Sobre a SEED 10 · Composição 1 · Inventário de peças 1 · Plano de produção 1 · Mapa de cobertura 1. Quatro formatos de origem: tabela Versão/Data (6 arquivos), "Registro do documento" (2), a linha de título antiga do seed-componentes, hoje dentro do changelog dele (79 versões) e o cabeçalho (2).
2026-10-31
a leva 50 (MANIFESTO §327).
texto inteiro da versão
a leva 50 (MANIFESTO §327). (1) §46.7 SH22, tempos da prévia (
SH-P70 b): a prévia do rail abre depois de 150 ms de intenção e fecha 500 ms depois de o ponteiro sair (eram 300/500); veredito dele, folha 17, Q1 = b, 2026-10-30 23:28 UTC (MANIFESTO §326.8; a opção b da folha: «150/500 ms: abre em ≈ 156 ms, fecha em 500 ms»). O sobrevoo que EXPANDE o rail (SH19) NÃO mudou: tem constantes próprias, 300/500 ms (decisão da sessão: a pergunta foi só sobre a prévia). Medido no Chrome (sonda render-shell.mjs R17-02): a prévia abriu em 152 e 157 ms; R19-13: 158 a 173 ms depois de o rail abrir. (2) §46.9 SH24, tooltip do rótulo curto (SH-P74 d): na Encurtada, o item de rótulo curto mostra o nome completo num tooltip no sobrevoo e no foco (veredito dele, folha 17, Q3 = d; a opção d da folha: «Vc: rótulo curto + tooltip com o nome completo»); mecanismo position: fixed posicionado por script (alcança 16 de 16 destinos a 1440 × 500 px, contra 5 de 16 com overflow: visible); opt-in rail(..., tooltip=True); vale também na gaveta de 800 px. (3) §83 AU-43, o anúncio do envio da vista Entrar (AU-P16 a; tela v0.14): com o e-mail em erro, o envio anuncia o texto do erro do campo em vez de «Envio simulado», move o foco ao campo e NÃO recusa o envio (veredito dele, folha 17, Q5 = a; a opção a da folha: «anunciar o erro em vez de «Envio simulado» quando o campo acusa, mover o foco ao campo, sem recusar o envio»); suíte 161 PASS · 0 FAIL · 2 [n/a]. (4) §31.4, o Esc fecha UMA camada (SH-P78): a regra vale também para o menu de envio e a lista de pessoa do detalhe com o painel aberto (4 casos novos, PASS de primeira: não havia defeito); a mensageria passa a ignorar o Esc durante a composição de IME (método de entrada; isComposing), como o módulo do painel. (5) §83 e §96 TE8, produto que usa o DS sem a marca SEED (LC-66): no lugar da logo vertical vai o nome do produto em texto (regra inteira em marca-seed.md §5.7); decisão DELEGADA a ele e exposta a veto (resposta «pode fazer», MANIFESTO §327.1, 2026-10-31).A leva 50 (MANIFESTO §327): §5.7 nova (LC-66), a bobina do comprovante de ponto com a altura (PR-P216), seis folhas de medida do selo e o piso de 8 pt na cartela de circuito (PR-P185 b).
texto inteiro da versão
A leva 50 (MANIFESTO §327): §5.7 nova (
LC-66), a bobina do comprovante de ponto com a altura (PR-P216), seis folhas de medida do selo e o piso de 8 pt na cartela de circuito (PR-P185 b). (1) §5.7 — produto que usa o DS (design system) sem a marca SEED: o nome do produto em texto no lugar da logo vertical, papel titulo-tela, tinta text-primary, <p> e nunca heading; sem logo, símbolo, EEny, favicon SEED nem selo "construído com". Decisão DELEGADA a ele ("pode fazer", MANIFESTO §327.1, 2026-10-31) e exposta a veto. (2) §12.3 (comprovante de ponto) e a tabela de superfícies dela: a bobina passa a dizer 80 × 126 mm (era só "80 mm"); 126 mm é o valor do gerador desde o commit a08ac64b5 (2026-10-25, PR-P186 c); os manifestos de 2026-09-26 ficam como história. (3) §12.14: seis folhas de medida do selo (eram cinco; a sexta nasceu do piso de 8 pt). (4) §12.21: a cartela de circuito sai do piso angular de 13,75′ e entra no piso absoluto de 8 pt da §4.8 (34 px = 8,16 pt a 300 DPI); veredito dele, folha 17, Q4 = b, 2026-10-30 23:28 UTC (MANIFESTO §326.8).A leva 50 (MANIFESTO §327), loop orquestrado de 2026-10-31 (pedido dele: "rode loop orquestrado 850k, já autorizei as demandas nas respostas acima. se surgir demanda até o checkpoint pode resolver dentro desse loop";…
texto inteiro da versão
A leva 50 (MANIFESTO §327), loop orquestrado de 2026-10-31 (pedido dele: "rode loop orquestrado 850k, já autorizei as demandas nas respostas acima. se surgir demanda até o checkpoint pode resolver dentro desse loop"; folha 17 respondida 8 de 8): fecham
SH-P70 (prévia SH22 em 150/500 ms, Q1 = b; o SH19 mantém 300/500 com constantes próprias), SH-P74 (tooltip do rótulo curto na Encurtada, Q3 = d, opt-in), AU-P16 (tela de autenticação v0.14: o envio anuncia o erro do campo e move o foco, Q5 = a; suíte 161 PASS · 0 FAIL), SH-P77 (variantes A e B de degradê na base do rail entregues; a decisão vai à folha 18), SH-P78 (Esc de uma camada no menu de envio e na lista de pessoa; isComposing na mensageria), SH-P79 (5 itens dos instrumentos do rail e da animação), SH-P68 (resto: medido já fechado, 0 ids duplicados), PR-P199 (sonda de DOM do conferidor espera pela condição e nomeia o motivo: 3 de 48 sem resposta antes, 0 de 96 depois; amostra pequena), PR-P212 (título do laudo cede a 2.ª linha; guarda 41 de 41), PR-P213 (variável de cobaia herdada sem SEED_COBAIA_PROVA faz o rito sair 2; em modo cobaia o rito nunca grava o selo), PR-P214 (código: autoteste da HV1 32 de 32; as 5 linhas de base ficam para a sessão regravar), PR-P215 (o pré-voo compara a versão das 6 dependências diretas), PR-P216 (a bobina do comprovante de ponto é 80 × 126 mm no canon), PR-P217 (a régua de contraste serve o 03-assets à tela copiada; arvore na linha de base da móvel), CT-P30 (linha «Readonly (texto)» 11,49:1 no claro e 15,43:1 no escuro) e LC-66 (marca-seed.md §5.7: produto que usa o DS sem a marca SEED; decisão delegada a ele, «pode fazer», exposta a veto). PR-P185 b PARCIAL (piso de 8 pt para tudo, Q4 = b; conserto por família, no gerador): uniforme e frota 5 de 10 passam o CP-3 e 5 ficam como estavam para a folha 18 (escritório-camisa-social, escritório-4-cores, campo-camisa, colete, estudo-gola-mercado); selo-prancha (medidas), one-pagers, portfolio e pasta-a4 16 de 16 (o selo passa a 6 folhas de medida); etiquetas, crachá, cartão, comprovante de ponto e cartões do gate 13 de 13 (a cartela de circuito sai do piso angular de 13,75′); envelope, sinalização NR-10, placa-quadro, timbrado e agenda 15 de 15 — 49 de 54 peças das quatro listas; a recontagem contra as 51 do censo é da sessão. Fecham SEM código, por decisão dele: SH-P67 (folha 17, Q2 = a: a mensageria mantém 12 a 25 Tab sob o painel) e CT-P29 (b) (Q7 = a: selo por versão e --regrava a cada bump). Placar do rito: no MANIFESTO §327.9 (escrito depois do selo, para não o invalidar). Custo dos agentes até o fechamento: US$ 123,88 com 39 agentes (MANIFESTO §327.3). Componentes v2.00, marca v5.64.2026-10-30
a leva 49 (MANIFESTO §326).
texto inteiro da versão
a leva 49 (MANIFESTO §326). (1) AU-43 estendida (
AU-P15; tela v0.13): a exceção do ponteiro vale na vista Entrar e em todo campo que valida no blur. Se o gesto termina sem clique (mouse solto fora do botão de envio, gesto cancelado, toque solto fora), a validação que o blur suprimiu é refeita na hora e o campo mostra o erro; solto dentro do botão, a validação é a do envio. Só o botão principal do ponteiro arma a exceção (o botão direito e o do meio não geram clique e acusam o erro). Ir da senha ao botão de revelar senha (e voltar) nunca acusa a senha em digitação, em nenhum formulário; sair do conjunto campo + botão para fora acusa, como manda o B4. O envio da vista Entrar mostra o erro do campo de e-mail de formato ruim, sem recusar o envio (o gabarito não sabe de credencial, CD13; o anúncio desse caso era a pendência AU-P16, decisão dele — resolvida na v2.00: o envio anuncia o erro do campo e move o foco a ele, ver o bloco acima e o AU-43 do §83). (2) Painel lateral e rail (SH-P76, SH-P67 parte): o Esc com o foco dentro do painel aberto fecha o painel e devolve o foco ao gatilho, no chat, no detalhe e na mensageria; um Esc fecha UMA camada (o Esc do menu de conta chama preventDefault e o painel respeita defaultPrevented; a composição de IME não fecha). O rail tem scrollbar-width: none (a barra horizontal de 15 px aparecia em 4 de 26 quadros na troca 80 → 160 px) e a prévia do painel do rail acompanha o rail quadro a quadro durante os 150 ms e na troca de data-rail/data-sidebar (o desvio de 80 px passa a 0 px). (3) Documentos de escritório (PR-P208): o cabeçalho C / NC / NA do checklist usa coluna de resultado de 20 mm com os rótulos centrados nas caixas (vão NC–NA de 0,60 para 1,86 mm); o título do caderno as-built cabe em uma linha (7,70 mm) com o número do placeholder e cede a uma segunda linha com número longo, sem sair da área útil. O subscrito do memorial fica no tamanho do corpo (8,16 pt): veredito dele, folha 16, Q2 = a. (4) Vitrine (PR-P207): a página /redes/ lista os glifos de redes sociais de TERCEIROS (uso nominativo; NÃO são assets da marca SEED); veredito dele, folha 16, Q1 = a.A leva 49 (MANIFESTO §326), loop orquestrado de 2026-10-30 (pedido dele: "folha respondida, tode loop orquestrado 800k. demandas que aparecerem durante o loop pode adicionar e resolver dentro desse mesmo loop até o…
texto inteiro da versão
**A leva 49 (MANIFESTO §326), loop orquestrado de 2026-10-30 (pedido dele: "folha respondida, tode loop orquestrado 800k. demandas que aparecerem durante o loop pode adicionar e resolver dentro desse mesmo loop até o teto"; folha 16 respondida 3 de 3: Q1 = a, Q2 = a, Q3 = a): fecham
PR-P202, PR-P206, PR-P207, PR-P208, PR-P209, PR-P210, PR-P211, PR-P192 (parte do repositório), CT-P29 (a, c), CP-P66, CP-P67, AU-P15 e SH-P76; o rito ganha fechar.sh --regrava (90 de 90 derivados em 30 a 292 s) e o pré-voo passa a CARREGAR cada pacote JS; a tela de autenticação vai a v0.13; nasce a página /redes/ da vitrine; estudos prontos para a folha 17: SH-P70, SH-P67, SH-P74 e o censo das 122 peças (PR-P185, o canon não define piso de etiqueta). Nascem AU-P16, SH-P77, SH-P78, SH-P79, CP-P68, PR-P212 a PR-P217 e CT-P30. Custo US$ 127,38 com 36 agentes. Componentes v1.99.2026-10-28
a leva 48 (MANIFESTO §325).
texto inteiro da versão
a leva 48 (MANIFESTO §325). (1) AU-43 estendida (
AU-P12, AU-P13, AU-P14; tela v0.12): o aria-describedby de um campo cita o erro só enquanto ele está visível e ANTES da ajuda (§2.9; veredito dele, folha 15, Q4 = a); o envio recusado move o foco ao resumo; o ponteiro até o botão de envio não valida no blur (a exceção, que era só da senha do "Criar conta", vale para qualquer campo que valida no blur nos três formulários: decisão da sessão, exposta a veto). (2) §46.10 SH29, D14 SUPERSEDIDA (SH-P71, SH-P75): a coluna de contexto, a troca de formato do rail e o empurrão do painel lateral animam a largura em 150 ms (--seed-dur-productive; movimento reduzido: de uma vez); veredito dele, folha 14, Q5 = c, 2026-10-28, verbatim: "aplicar 150 ms direto.", contra a recomendação "a" da folha; SH19 e §31.4 PL10 ganham a frase, e o Q3, o piso de 640 px e a cessão do rail leem o estado FINAL, nunca o meio da animação. (3) Campo em erro (CT-P28, tokens v1.40): a borda de erro passa a ser a MESMA cor do texto de erro (7,18:1 no claro, 7,56:1 no escuro; antes 5,19:1 e 5,52:1); veredito dele, folha 13, P4 = a, 2026-10-28; §2.5 (estado error, linhas dos tokens e a tabela de contraste).A leva 48 (MANIFESTO §325), loop orquestrado de 2026-10-28 (pedido dele: "folhas respondidas, rode loop orquestrado"; folha 13, 7 de 7, e folha 14, 8 de 8, respondidas): fecham AU-P12, AU-P13, AU-P14, CP-P61, CP-P64,…
texto inteiro da versão
A leva 48 (MANIFESTO §325), loop orquestrado de 2026-10-28 (pedido dele: "folhas respondidas, rode loop orquestrado"; folha 13, 7 de 7, e folha 14, 8 de 8, respondidas): fecham
AU-P12, AU-P13, AU-P14, CP-P61, CP-P64, CP-P65, CT-P28, SH-P71, SH-P75, HV-P55, VT-P21 e PR-P204; a PR-P205 foi VARRIDA (nada consertado); a PR-P185 fecha em PARTE (laudo, as-built, checklist e memorial a 8 pt); componentes v1.98 e tokens v1.40. Contexto para quem lê sem ter visto a conversa: a leva 47 deixou aberta uma fila de resíduos de tela e de instrumento e duas folhas sem resposta; ele respondeu as duas em 2026-10-28 e esta leva aplicou o que as respostas mandavam. Sete trabalhos com agentes Sonnet 5.5 em clones separados, cada um com revisão independente (Opus 5.5 para o shell; 17 agentes com transcrito); 3 dos 7 trabalhos foram BLOQUEADOS ao menos uma vez por revisão independente e consertados antes de entrar (MANIFESTO §325.5). (1) Autenticação v0.12 (AU-P12..P14): erro ANTES da ajuda e fora do aria-describedby enquanto oculto, nos 9 campos (veredito dele, folha 15, Q4 = a); foco no resumo do envio recusado; o clique no botão de envio por ponteiro deixa de se perder para qualquer campo que valida no blur (decisão da sessão, exposta a veto); suíte 88 → 121 PASS · 0 FAIL. (2) Conferidor de peça (CP-P64, CP-P61, CP-P65): casos sem medir saem 2 (folha 15, Q5 = a), a razão social completa passa no CP-7 (folha 14, Q2 = a), "0 de 0" é NÃO MEDI, texto invisível não conta, --sem-texto com motivo; prova nova 74 de 74. (3) CT-P28 (folha 13, P4 = a): a borda de erro do campo é a cor do texto de erro, 7,18:1 no claro e 7,56:1 no escuro (eram 5,19:1 e 5,52:1), tokens v1.40; prova da borda de erro, cobaias 26 de 26. (4) SH-P71 e SH-P75 (folha 14, Q5 = c, 2026-10-28, verbatim: "aplicar 150 ms direto.", contra a recomendação "a" da folha): a D14 do SH29 ("sem animação de largura") é SUPERSEDIDA; a coluna de contexto, o rail e o empurrão do painel animam a largura em --seed-dur-productive (150 ms; movimento reduzido: de uma vez); o ResizeObserver do painel reavalia na mesma passada; prova nova shell-animacao 27 de 27 mais a --cobaia; a R18 do render-rail passa a medir congelada e é cega ao meio da animação. (5) PR-P185 em parte (folha 13, P3 = a e folha 14, Q3 = a: só os quatro documentos de escritório sobem a 8 pt; as peças físicas e de etiqueta ficam): CP-3 do laudo de 157 de 276 trechos abaixo de 8 pt para 0 de 285, do as-built de 13 de 138 para 0 de 138, do checklist de 175 de 608 para 0 de 613 e do memorial de 48 de 536 para 0 de 512, a FS_PISO = 8,16 pt (34 px a 300 DPI, o menor inteiro que cumpre o piso); o piso de 8 pt já constava do marca-seed.md §4.8 como regra geral (não por documento) e o seed-componentes.md não o cita por documento, então esta linha é o único registro (marca-seed.md NÃO foi editada). (6) Instrumentos (HV-P55, PR-P204, VT-P21): a guarda do toggle .itgl lê o nome acessível com a origem e reprova nome vazio, só pontuação ou só de title (22 de 22); a HV1 ganha --saida-json e as três guardas irmãs exigem --motivo; o título da tela de envio ao fornecedor perde "proposta para gate". Segue aberto: PR-P185 (resto: o mecanismo de "etiqueta" por declaração no CP-3 e o censo das 122 peças físicas), SH-P70 (medir o sobrevoo do rail com 300/500, 150/250 e 0/150 ms, folha 14, Q4 = a), PR-P202 e PR-P206 (não feitos: o agente G chegou ao teto de chamadas) e, da PR-P205, o que a varredura não alcançou. Nascem o que as revisões acharam: AU-P15, CP-P66, CP-P67, SH-P76, PR-P207, PR-P208, PR-P209, CT-P29 (MANIFESTO §325.6). Custo medido US$ 58,26 (Sonnet 5.5 US$ 50,92; Opus 5.5 US$ 7,34; MANIFESTO §325.5). O rito comum desta árvore e a publicação ficam registrados no commit seguinte.CT-P28 (folha 13, P4 = a, gravada em 2026-10-28; leva 48) — a borda do campo em erro do banco-formfield passa a ter a cor do texto de erro.
texto inteiro da versão
CT-P28 (folha 13, P4 = a, gravada em 2026-10-28; leva 48) — a borda do campo em erro do banco-formfield passa a ter a cor do texto de erro. Veredito dele, verbatim: "igualar: o token passa a ter a cor do texto de erro, como você pediu para 'todos os campos'. Mexe em um token do canon, com as provas de contraste (cerca de 1 hora)." Contexto para quem lê sem ter visto: na folha 9 (M7 = a, MANIFESTO §319–§320) ele escolheu a cor do texto de erro na borda de TODOS os campos das telas e bancadas (seis arquivos mudaram na leva 45); o componente banco-formfield seguiu com o token próprio --seed-field-border-error (vermelho-600 #C6393B no claro, vermelho-400 #FC6F6A no escuro), que passava de 3:1 (o mínimo de acessibilidade para borda, WCAG 2.2 SC 1.4.11) mas era mais fraco que a borda dos outros campos. Agora --seed-field-border-error vale o MESMO que --seed-field-error-text: #A5272A (vermelho-700) no claro e #FF9C95 (vermelho-300) no escuro, nos gêmeos seed-tokens.json (semantic.field.border-error) e seed-tokens.css (três pontos: :root, [data-theme="dark"] e o bloco prefers-color-scheme), que passam ao número 1.40. Medido (razão de contraste WCAG, 06-validacao/provas/borda-erro e conta própria, 2026-10-28): sobre a superfície do campo 7,18:1 no claro (era 5,19) e 7,56:1 no escuro (era 5,52); sobre surface-sunken 5,95:1 no claro; sobre surface-page do escuro 9,25:1; piso 3:1. Nenhum hex novo nasce: só o primitivo de origem muda; a guarda paridade-tokens.py (tabela CAMPO_ALIAS) passa a exigir vermelho-700/vermelho-300 para o par. Efeito em cadeia: o carimbo "seed-tokens.css v1.40" entra nos blocos de tokens gerados (telas, bancadas, peças, publicação) na próxima regeneração; o --checar de cada um acusa selo velho até lá. Alternativa descartada: manter o token mais fraco só no banco-formfield (duas bordas de erro diferentes para o mesmo estado).2026-10-25
a leva 47 (MANIFESTO §324).
texto inteiro da versão
a leva 47 (MANIFESTO §324). (1) AU-43 refeita (
AU-P11): a senha do "Criar conta" valida no blur (B4), com exceção estreita para o clique no botão de envio por ponteiro, e o resumo role="alert" diz a regra e recebe o foco; a frase da leva 46 "no envio, não no blur" saiu; tela v0.11 (AU-P8, AU-P9, AU-P10). (2) Toggle .itgl (HV-P53, HV-P54): o aria-label é nome estável nos dois estados e o title é tooltip da ação; guarda permanente de nome acessível. (3) SH19 e §31.4 PL10 (SH-P69, SH-P73): com um painel aberto a coluna larga do rail cede de 160 para 80 px quando o conteúdo ficaria abaixo de 640 px (decisão da sessão, opção (a) da folha 13, exposta a veto), sem depender do caminho da janela.a leva 46 (MANIFESTO §322).
texto inteiro da versão
a leva 46 (MANIFESTO §322). (1) §46.4 VT-P18: as telas do parceiro indicador entram na vitrine,
tela-portal-parceiro (A30, governada pelo §48) e tela-cadastro-indicado (A31, governada pelo §2), 25 telas e 20 gabaritos (eram 23 e 18); numeração, governança e nomes são decisão da sessão, expostos a veto. (2) §83 A19 v0.10 — AU-43 (AU-P7): o "Criar conta" RECUSA no envio senha com menos de 12 caracteres ou vazia, com erro de campo anunciado; a frase "a tela não impede enviar senha curta" da AU-39..42 (texto da sessão da leva 45, apoiado no CD14) sai, porque o CD14 trata da FORÇA e o piso de 12 é FORMATO (CD4, CD13); nova nota ao CD14 (divergência com o canon anterior, exposta a veto). (3) §66.2 CD14, nota de emenda e o aria-describedby do campo senha só cita o erro enquanto ele existe (achado médio da revisão independente, consertado). Nada mais mudou.§12.2: a faixa de rodapé do timbrado ofício passa a dizer o que o render mede (PR-P186, MANIFESTO §322).
texto inteiro da versão
§12.2: a faixa de rodapé do timbrado ofício passa a dizer o que o render mede (
PR-P186, MANIFESTO §322). Contexto para quem lê sem ter visto a conversa: a PR-P174 (leva 45) subiu o texto do rodapé do timbrado ao piso de 8 pt (2,85 mm) e o bloco passou a ocupar mais da faixa; o texto da tabela seguia com a medida velha. Medido em 2026-10-25 em duas larguras de janela (1200 e 1500 px), mesmo resultado, na peça timbrado-a4-oficio-limpo.html: o topo do bloco do rodapé fica a 32,249 mm do corte inferior, logo a folga na faixa de 33 mm é de 0,751 mm (antes o canon dizia 30,72 mm e 2,28 mm). Só a coluna ofício mudou. A área útil vigente por variante, medida no <meta name="area-util"> dos seis arquivos de 07-pecas/timbrado-a4/: ofício 196 × 227 mm, orçamento 196 × 241 mm e compacto 196 × 256 mm, todas a partir de (7, 29) mm; a tabela já estava certa e 196 × 241 mm é o orçamento, não "o timbrado".A leva 47 (MANIFESTO §324), loop orquestrado de 2026-10-25 ("Vc tem meu sim para publicar novas versões. Rode loop orquestrado"): fecham SH-P69, SH-P73, AU-P8, AU-P9, AU-P10, AU-P11, HV-P53, HV-P54, VT-P19, VT-P20,…
texto inteiro da versão
A leva 47 (MANIFESTO §324), loop orquestrado de 2026-10-25 ("Vc tem meu sim para publicar novas versões. Rode loop orquestrado"): fecham
SH-P69, SH-P73, AU-P8, AU-P9, AU-P10, AU-P11, HV-P53, HV-P54, VT-P19, VT-P20, PR-P194, PR-P195, PR-P196, PR-P197, PR-P198, PR-P200 e PR-P201; componentes v1.97; nasce o que as revisões acharam (AU-P12..P14, HV-P55, VT-P21, SH-P75, PR-P202..P206, CP-P64, CP-P65). Contexto para quem lê sem ter visto a conversa: a leva 46 deixou o rito sem selo por duas reprovações (a R18-a-chat do render-rail, de propósito, por uma regressão real do rail com painel aberto — SH-P69 — e a S2 da prova da queda, que oscilava sob carga — PR-P201) e uma fila de resíduos de instrumentos e telas. Esta leva usou 5 agentes Sonnet 5.5 em clones separados e 10 revisões independentes; 5 dos 5 trabalhos tiveram ao menos uma revisão que BLOQUEOU (achados médios: PASS falso na isenção do acordeão, --motivo da HV1 que falhava aberto, histerese do rail, NÃO MEDI que virava PASS) e todos foram consertados e revisados de novo antes de entrar. (1) SH-P69 (opção (a) da folha 13 P6, exposta a veto): com o painel aberto a coluna larga do rail cede de 160 para 80 px quando o conteúdo ficaria abaixo de 640 px, sem depender do caminho da janela; render-rail 159 de 159. (2) Autenticação v0.11: erro de senha só no aria-describedby enquanto visível, blur com exceção por ponteiro, resumo que recebe o foco; suíte 88 PASS. (3) Instrumentos: prova da queda sem processo alheio de PID reaproveitado, guarda de corte com acordeão declarado fechado, _mede com teto, conferidor com saída 0/1/2, HV1 só regrava com --motivo, CI-13 por identidade. (4) Bancada e vitrine: guarda permanente de nome acessível do .itgl. Custo medido US$ 66,72 (estimado ~US$ 45). O rito comum desta árvore e a publicação ficam registrados no commit seguinte.A leva 46 (MANIFESTO §322), loop orquestrado de 2026-10-25 ("paralelo a isso rode o proximo grupo com loop orquestrado"): fecham PR-P184, PR-P186, PR-P187, PR-P188, PR-P189, PR-P190, AU-P7, HV-P52, VT-P18 e o passo 1 da…
texto inteiro da versão
A leva 46 (MANIFESTO §322), loop orquestrado de 2026-10-25 ("paralelo a isso rode o proximo grupo com loop orquestrado"): fecham
PR-P184, PR-P186, PR-P187, PR-P188, PR-P189, PR-P190, AU-P7, HV-P52, VT-P18 e o passo 1 da PR-P191; o rito comum roda (285 guardas, 0 NÃO MEDI, 2 reprovações: a R18-a-chat de propósito, SH-P69, e a S2 da prova da queda, que oscila sob carga, PR-P201) e NÃO há selo; nada publicado (produção 80d82504). Contexto para quem lê sem ter visto a conversa: a leva 45 deixou o rito sem verde e uma fila de pendências de instrumento; esta leva a atacou com 6 agentes Sonnet 5.5 em clones separados (G1 conferidor de peça, G2 guarda de corte e provas, G3 instrumentos com teto, G4 vitrine do parceiro e .itgl, G5 senha curta) e 7 revisões independentes: 3 dos 6 trabalhos foram BLOQUEADOS (achado médio) e consertados antes de entrar. (1) Conferidor (PR-P184, PR-P189): o CP-3 de peça física é medido no PDF a 8 pt e o CP-10 sem DOM sai NÃO MEDI; efeito medido no acervo, sem alterar peça: 65 de 122 peças físicas passam a reprovar o CP-3 (36 delas fora das 7 famílias do PR-P185, que ficou MAIOR). (2) Guarda de corte (PR-P186): --tocadas no rito comum, caixa de altura 0 e margem negativa, a bobina do comprovante a 126 mm. (3) Instrumentos (PR-P188, PR-P190): teto e morte por PID, a prova da queda 15 de 15, suite-quadro por espera por condição. (4) Vitrine (VT-P18, HV-P52): A30 e A31, 25 telas e 20 gabaritos; nome acessível nos 2 .itgl. (5) AU-P7: o "Criar conta" recusa senha curta (componentes v1.96, AU-43; divergência com uma frase da própria sessão na AU-39..42, exposta a veto). (6) Marca v5.63: rodapé do timbrado ofício a 32,25 mm. (7) Estudo do Gmail (MANIFESTO §321): três propostas, SH-P70 (latência do sobrevoo), SH-P71 (animação de 150 ms), SH-P72 (prévia viva), todas de decisão dele. Nascem 23 pendências com código (MANIFESTO §322.7).2026-10-24
a leva 45 (MANIFESTO §320).
texto inteiro da versão
a leva 45 (MANIFESTO §320). (1) §31.4 PAINEL LATERAL À DIREITA (SH-P62, folha 11, SH62a..e): uma regra só para chat, detalhe e mensageria — o painel EMPURRA o conteúdo até o piso de 640 px e, passado o piso, SOBREPÕE; três tokens (420 / 320 / 640 px, tokens v1.39); arraste pela borda com teclado; a conversa NÃO fica inerte (SH62c = b; custo do Tab sob o painel medido no PL7); o módulo único
painel_lateral_bloco.py emite a camada. (2) §49.9 fecha a SH-P63 (o painel do detalhe não esmaga mais a lista); a CH3 e o §55.5 do chat e a MS5 da mensageria são substituídas (SH62d = b) e a gaveta da mensageria nasce abaixo do cabeçalho (SH-P60, SH60 = a); o limite antigo de 1560 px fica como histórico no §94.11. (3) Campo em erro (CT-P25, folha 9, M7 = a): a borda usa a cor do texto de erro; AU-39..42 no §83 (CPF em toda conta, senha de 12 no Criar conta). (4) O ⓘ ligado da mensageria segue o par do botão secundário (decisão da sessão, exposta a veto). · v1.94 — a leva 43 (MANIFESTO §316), as respostas da folha 11. (1) §46.10 SH29 coluna de contexto FIXA ou SOLTA (G1 = "a" com a observação dele). (2) §93 MA9 emendada, MA13 vidro sobre imagem e MA14 topo mais espesso (MA1 = MA2 = "a"; piso do claro 82 %, decisão da sessão exposta a veto). (3) §96 telas de estado de sistema TE1–TE11 (VI2 = "a"). (4) §47.8 MK30 aviso de cookies com o risco escrito (TQ4 = "b"). (5) §66.2 nota ao CD7: olho riscado (AU6 = "b").A persona da Clara entra no §9-B.4 (MR-P31; MANIFESTO §320) e a frase de elevação do §12 passa a dizer o que os tokens emitem (PR-P183).
texto inteiro da versão
A persona da Clara entra no §9-B.4 (
MR-P31; MANIFESTO §320) e a frase de elevação do §12 passa a dizer o que os tokens emitem (PR-P183). Contexto para quem lê sem ter visto: a folha 9 (2026-10-18) perguntou como a Clara fala de si e da IA; ele respondeu M8 = a (a 1.ª resposta a "você é robô?" segue como roda hoje, sem afirmar nem negar), M9 = a (ela NÃO se anuncia como IA no começo da conversa), M10 = a (sem rótulo de IA em vídeo e anúncio), M10b = a (o texto de privacidade do SEED Chat fica; por isso MR-P32 ficou sem efeito) e M10c = a (a persona entra no canon). O §9-B.4 ganhou a persona com a regra 4 escrita assim; o §9-B.2 regra 4 (verbatim dele de 2026-10-12) ganhou uma nota de ajuste que tira o exemplo "funcionária" de uso. Risco registrado sem contrariar a decisão dele: a política de uso da fornecedora da IA, citada na própria folha, exige aviso de IA no começo de cada conversa (em vigor, lido em 2026-10-12) e a versão de 12/11/2026 aceita o aviso na interface; a punição NÃO foi lida [não conferido]. Também: a linha de elevação (§12, "sombras tintadas no cinza-900") ganhou a exceção do tema escuro, e a citação do tom corrigida de sobreaseed.md:466 para :488. Revisão independente: SEM BLOQUEANTE.A leva 45 (MANIFESTO §320), loop orquestrado de 2026-10-23 ("loop orquestrado"): fecham PR-P174, PR-P182 (menos a vitrine, VT-P18), SH-P62, SH-P63, SH-P60, HV-P49, HV-P50, HV-P51, PR-P173, PR-P179 e PR-P183; AU-P4,…
texto inteiro da versão
A leva 45 (MANIFESTO §320), loop orquestrado de 2026-10-23 ("loop orquestrado"): fecham
PR-P174, PR-P182 (menos a vitrine, VT-P18), SH-P62, SH-P63, SH-P60, HV-P49, HV-P50, HV-P51, PR-P173, PR-P179 e PR-P183; AU-P4, AU-P5, CT-P25 e MR-P31 fecham dentro da PR-P182; MR-P32 fica sem efeito. Cinco agentes em clones separados (A PR-P174 Sonnet; B PR-P182 Sonnet; C SH-P62 Opus; D PR-P181 pesquisador; E instrumentos Sonnet) e sete revisões independentes (Sonnet): quatro BLOQUEARAM e foram corrigidas (diário de obra cortava 17 px; furo da linha de base da guarda nova; cobaias derivadas sem regenerar; P14 da HV1 afirmando o defeito que a SH-P60 conserta). Componentes v1.95 (§31.4 painel lateral, §49.9, CH3 e MS5 substituídas, AU-39..42), tokens v1.39 (três tokens do painel: 420 / 320 / 640 px), marca v5.62 (persona da Clara no §9-B.4), práticas v1.13. Guarda nova guarda-corte-caixa (caixa overflow:hidden de peça que corta conteúdo). Nascem PR-P184..PR-P191, HV-P52, AU-P7, CT-P28, SH-P67, SH-P68, SH-P69 (regressão real do rail largo com painel aberto, à folha). No fechamento desta versão o rito comum NÃO está verde: os consertos de instrumento (4fadbaf1) ainda não tiveram a 2.ª revisão independente nem rito novo; nada foi publicado (MANIFESTO §320.8). PR-P181 segue aberta: a leitura dos termos dos kits mostra que o download público dos glifos não tem base nos termos lidos (decisão dele na folha).SH-P62 (folha 11 de 2026-10-18, respostas dele SH62a = a, SH62b = a, SH62c = b, SH62d = b, SH62e = a; MANIFESTO §320) — nascem três tokens do painel lateral à direita.
texto inteiro da versão
SH-P62 (folha 11 de 2026-10-18, respostas dele SH62a = a, SH62b = a, SH62c = b, SH62d = b, SH62e = a; MANIFESTO §320) — nascem três tokens do painel lateral à direita. Contexto para quem lê sem ter visto: quando um painel (conversa de apoio, detalhe de registro, gaveta da mensageria) abre à direita da tela, a regra nova diz que ele EMPURRA o conteúdo até o conteúdo chegar a um piso e, passado o piso, SOBREPÕE; os três números dessa regra viram token em vez de número solto em cada tela: --seed-side-panel-width = 420px (largura de abertura), --seed-side-panel-width-min = 320px (menor largura no arraste da borda) e --seed-side-panel-content-min = 640px (o piso do conteúdo, resposta SH62a = a). Origem dos valores e a regra completa: §3f deste arquivo e seed-componentes.md §31.4. Nos gêmeos, seed-tokens.json e seed-tokens.css ganham os mesmos três tokens e passam ao número 1.39. Adição pura: nenhum valor anterior muda. Alternativa descartada: deixar os três números dentro de cada tela (três cópias que divergem).PR-P183 (MANIFESTO §320): o item do checklist do mockup do SIGA que dizia "Sombra pelo token shadow.raised, nunca preto puro" passa a dizer o que os tokens emitem
texto inteiro da versão
PR-P183 (MANIFESTO §320): o item do checklist do mockup do SIGA que dizia "Sombra pelo token shadow.raised, nunca preto puro" passa a dizer o que os tokens emitem — no tema claro a sombra é tintada no cinza-900 e no escuro é preta com opacidade (tokens v1.38, PR-P177). Nenhuma regra de prática muda: continua valendo "use o token, não um valor solto".2026-10-22
PR-P177 FECHADA (MANIFESTO §319): a frase de sombras do §2.8 do seed-tokens.md deixa de dizer "nunca preto" e passa a descrever o que os tokens emitem
texto inteiro da versão
PR-P177 FECHADA (MANIFESTO §319): a frase de sombras do §2.8 do seed-tokens.md deixa de dizer "nunca preto" e passa a descrever o que os tokens emitem (claro: tintada no cinza-900; escuro: preto com opacidade 0,40/0,50/0,60). Resposta dele na folha 12, P177 = "a". Tokens v1.38 (só o .md; os gêmeos .json e .css seguem em v1.37, nenhum valor muda). Nasce PR-P183 (as 4 ocorrências que sobram da mesma frase: seed-praticas.md, marca-seed.md, seed-tokens.json e o HANDOFF congelado).PR-P177 (folha 12, P177 = "a", resposta dele gravada em 2026-10-19 02:14Z; MANIFESTO §319) — a frase de sombras do §2.8 deixa de dizer "nunca preto".
texto inteiro da versão
PR-P177 (folha 12, P177 = "a", resposta dele gravada em 2026-10-19 02:14Z; MANIFESTO §319) — a frase de sombras do §2.8 deixa de dizer "nunca preto". Contexto para quem lê sem ter visto: o §2.8 dizia "Sombras tintadas no cinza-900 (#242E34), nunca preto", mas as três sombras de elevação do tema escuro (--seed-shadow-raised/-overlay/-modal = rgba(0,0,0,0.40/0.50/0.60), seed-tokens.css linhas 1095–1097 e 1306–1308) são pretas com opacidade; só as do tema claro são tintadas (rgba(36,46,52,…)). Medido pela sessão na leva 43 (MANIFESTO §316) e levado à folha 12; ele escolheu mudar a frase (opção "a") e não os tokens. Alternativa descartada: tingir as sombras do escuro (mudaria pixels em todas as telas e peças, sem ganho medido; a razão "uma sombra tintada some sobre superfície escura" é [inferência: não medida]). Nenhum valor de token mudou: só o texto do §2.8, por isso os gêmeos (seed-tokens.json e .css) ficam em v1.37, como nas v1.32 a v1.34 (só texto; REV-P27); na próxima mudança de valor os gêmeos pegam o número vigente do .md (1.39 ou mais), como a v1.35 fez.2026-10-21
§12.34: os 7 glifos oficiais das redes entram (PR-P175; MANIFESTO §318).
texto inteiro da versão
§12.34: os 7 glifos oficiais das redes entram (
PR-P175; MANIFESTO §318). Ele aceitou os termos e baixou os kits no Chrome dele (folha 12, P175 = "b"). O glifo de uma tinta (Instagram, TikTok, X) tem par claro/escuro; o colorido (Facebook, LinkedIn, YouTube, WhatsApp) é um arquivo só. A regra "nunca recolorido" passa a "só nas cores que o kit oferece" (decisão da sessão, exposta a veto: o preto do X é o traçado do SVG oficial branco com preenchimento preto, porque a variante preta do kit só vem em PNG; o vermelho do YouTube é o #ff0033 do PNG digital oficial). Facebook e YouTube vieram de .ai/.pdf convertidos de formato. Regra de uso por rede [não conferido]: PR-P181.§1, regra 4 das redes: os 7 glifos oficiais estão instalados (PR-P175 fechada; MANIFESTO §318).
texto inteiro da versão
§1, regra 4 das redes: os 7 glifos oficiais estão instalados (
PR-P175 fechada; MANIFESTO §318). Ele marcou o aceite e baixou os kits no Chrome dele (folha 12, P175 = "b"); a regra deixa de dizer "ainda não foram baixados" e passa a "nunca recolorido além do que o kit da própria marca oferece". Regra de uso por rede [não conferido]: PR-P181.PR-P175 FECHADA (MANIFESTO §318): os 7 glifos oficiais das redes entram na página de links (marca v5.61, §12.34).
texto inteiro da versão
PR-P175 FECHADA (MANIFESTO §318): os 7 glifos oficiais das redes entram na página de links (marca v5.61, §12.34). Ele aceitou os termos e baixou os kits (Instagram, Facebook, WhatsApp, LinkedIn, X, YouTube, TikTok); ele mesmo achou o kit novo do X (o da página em inglês era o passarinho de 2021). Glifo de uma tinta tem par claro/escuro, o colorido é um arquivo só; Facebook e YouTube vieram de vetor oficial convertido de formato (diferença média contra o PNG oficial 0,64 e 0,62 em 255). prova-pagina-de-links.py 30 de 30. Nascem PR-P181 (regra de uso de cada rede, [não conferido]) e PR-P182 (aplicar a folha 9, que estava respondida desde 18/10 e só foi lida hoje; leitura no MANIFESTO §318.4).MET-12 (MANIFESTO §317), por ordem dele de 2026-10-21 13:21Z.
texto inteiro da versão
MET-12 (MANIFESTO §317), por ordem dele de 2026-10-21 ~13:21Z. O
CLAUDE.md do projeto vai de 321 linhas e 22.777 bytes a 193 linhas e 14.964 bytes, sem apagar regra (prova 285 de 285): o que saiu está em 6 arquivos novos de docs/, com 9 ponteiros "Quando ler"; guarda nova de tamanho (120 a 200 linhas) no rito; docs/ entra na lista de publicados. Revisão independente SEM BLOQUEANTE, 6 baixos consertados.2026-10-19
Nasce o §12.34 "Página de links" (proposta; pedidos PC-2026-0072 e PC-2026-0089; leva 43, MANIFESTO §316).
texto inteiro da versão
Nasce o §12.34 "Página de links" (
proposta; pedidos PC-2026-0072 e PC-2026-0089; leva 43, MANIFESTO §316). Consequência do veredito dele na folha 11, TQ1 = "a" (verbatim no §12.34: "… página de links vira peça nova …"). A spec traz a fonte única (a tabela de redes do sobreaseed.md §1, lida célula a célula pelo gen-pagina-de-links.py), os ícones só oficiais e ainda não baixados (folha 12, P175 = "b": os kits se abrem no Chrome dele, PR-P175), o rótulo do 0800, atendimento institucional (comercial, suporte e setores) (folha 12, P176 = "c", observação verbatim na spec), e a capa pagina-de-links-capa.png (390 × 844 px, render-peca.mjs), que leva a peça ao cartão da vitrine. O §12 passa de 33 para 34 specs.Nasce a tabela «Redes sociais oficiais» no §1 (leva 43, MANIFESTO §316; pedidos PC-2026-0089 e PC-2026-0072).
texto inteiro da versão
Nasce a tabela «Redes sociais oficiais» no §1 (leva 43, MANIFESTO §316; pedidos
PC-2026-0089 e PC-2026-0072). Veredito dele na folha 11, TQ1 = "a" (verbatim no §1): 7 redes com endereço e @, ícones só no formato oficial, página de links como peça nova (marca-seed.md §12.34). Na integração (2026-10-19), as duas respostas da folha 12 que tocam a tabela: P176 = "c" — o 0800 vira atendimento institucional (comercial, suporte e setores) (sai o [não conferido] do rótulo «comercial»); P175 = "b" — os kits de ícones se baixam com ele no Chrome. (Esta linha entrou na integração: o cabeçalho já dizia 2026-10-19 e o §14 parava em 2026-10-10.)A leva 43 (MANIFESTO §316), as respostas da folha 11 aplicadas, ainda no loop orquestrado 800k.
texto inteiro da versão
A leva 43 (MANIFESTO §316), as respostas da folha 11 aplicadas, ainda no loop orquestrado 800k. Coluna de menu FIXA ou SOLTA (SH29, §46.10); vidro sobre imagem e tinta forte em todo vidro (MA13/MA14, MA9); ficha de uma tela por componente e
/tokens/armadilhas/; telas de estado de sistema (§96); script de tema e tokens em TypeScript no registry; plugin seed-ds do Claude Code; redes oficiais e página de links; rótulos da proposta a 8 pt; MK30 cookies; olho riscado. Triagem dos 47 pedidos gravada; LC-42..LC-65 entram na Fila LC. Fecham SH-P61, MA-P8..MA-P10, PR-P171, PR-P151, AU-P6. Nascem MA-P12, MA-P13, PR-P173..PR-P180. Revisão independente bloqueou 7 defeitos médios em 6 de 9 trabalhos, todos consertados e revisados de novo.MA-P8 aplicado pela folha 11 (leva 43, MANIFESTO §316) — nascem três tokens do material e um derivado: o vidro sobre imagem (MA13) e o topo do vidro mais espesso (MA14).
texto inteiro da versão
MA-P8 aplicado pela folha 11 (leva 43, MANIFESTO §316) — nascem três tokens do material e um derivado: o vidro sobre imagem (MA13) e o topo do vidro mais espesso (MA14). Veredito dele na folha 11 (2026-10-18), verbatim no §3d: MA2 = "a" — "sim, 92 % e véu 35 %". No grupo semantic.mat do JSON e no CSS: --seed-mat-glass-thick-delta 10% (invariante de tema), --seed-mat-glass-alpha-midia 82% claro / 92% escuro e --seed-mat-media-dim 0% claro / 35% escuro; derivado só no gêmeo CSS: --seed-mat-glass-thick (alfa + 10 pontos, teto 100 %). O §3d passa de 18 tokens e 2 derivados para 21 e 3. Adição pura: nenhum valor anterior muda; o V-2 dele (80 % / 72 %) continua o mínimo. (Esta linha entrou na integração das levas 42 e 43, 2026-10-19: o cabeçalho e a linha "Editado" já diziam v1.37 e o §9 parava na 1.36 — a guarda VL-7 reprovou.)2026-10-18
A leva 42 (MANIFESTO §315), loop orquestrado 800k — pedido dele: "rode o loop orquestrado 800k".
texto inteiro da versão
A leva 42 (MANIFESTO §315), loop orquestrado 800k — pedido dele: "rode o loop orquestrado 800k". A guarda de sobrevoo (MH2) avalia a media no navegador e alcança as 23 bancadas (118
:hover levados para @media (hover: hover) nos moldes; gen-banco-cn.py e gen-banco-composicao.py nascem); nasce a guarda dos botões de alternância (IT1); o contraste das vistas compara tela a tela (piso por alvo) e a 390 px mede na altura 844; a prova da queda da HV1 deixa de depender do relógio; as suítes do cadastro, do fornecedor e do parceiro entram na prova da tela empurrada. Folha 10 aplicada (N1 = "c", N2 = "a", N3 = "a"). Fecham HV-P32, HV-P40..HV-P48, PR-P169, PR-P170. Seis estudos (coluna recolhível SH29 fase 2, painel que empurra × sobrepõe, Liquid Glass, Viver de IA, triagem dos 47 pedidos, SH-P60/AU-P6) vão à folha 11 (https://claude.ai/artifact/9dyLybSRiEhB3ZxEYb19Aa); a SH29 espera o gate G1. Nascem SH-P62..SH-P66, MA-P9..MA-P11, HV-P49..HV-P51, PR-P172. Três revisões independentes bloquearam defeito real (2 médios na IT1, 1 médio no piso de medidos), consertados e revisados de novo.2026-10-13
a leva 41 (MANIFESTO §314).
texto inteiro da versão
a leva 41 (MANIFESTO §314). (1) §1 MH1 → MH2: todo
:hover de TELA vive sob @media (hover: hover) (24 telas, 548 regras; guarda guarda-sobrevoo-telas.mjs). (2) §46 SH3/SH19: o alvo de 44 × 44 do avatar do RAIL é declarado na casca (AV2). (3) §49 PD17: o ícone dos botões de tamanho e de regime da tela-detalhe passa a acompanhar o estado (antes nunca trocava, defeito de script). (4) §94 MS5: o painel de informações da mensageria obedece ao teclado (foco entra ao abrir, Esc fecha e devolve o foco; CN6/DW3/Y3). (5) Caixas de seleção: accent-color: var(--seed-action-primary) nas caixas de linha da lista e da tabela e no painel (no escuro o anel do painel vai de #098475 a #66D1C2). Nenhum token novo.a leva 40 (MANIFESTO §313).
texto inteiro da versão
a leva 40 (MANIFESTO §313). (1) §46.4: parágrafo "Endereço dos links públicos" — host
https://siga.seed.eng.br, token de 22 caracteres base64url no CAMINHO, /i/<token> para o link de indicação, /f/<token> para o fornecedor (proposta a veto), noindex e no-referrer, meta seed-proibidas com o identificador da lista de palavras (PR-P159, PR-P158). (2) Telas: o avatar da topbar deixa a declaração morta de 32 px nos moldes (a casca dá o 44; SH-P56); a tela-detalhe e o shell levam o sobrevoo para @media (hover: hover) (HV-P31). Nenhum token novo.A leva 41 (MANIFESTO §314), ainda no loop orquestrado 800k.
texto inteiro da versão
A leva 41 (MANIFESTO §314), ainda no loop orquestrado 800k. O sobrevoo das 24 telas fica inteiro sob
@media (hover: hover) com a guarda MH2; o avatar do rail na casca; as vistas a 390 px no --bloco; o ícone do detalhe que nunca trocava; o painel do chat obedece ao teclado; a lista de palavras proibidas vira fonte única. Fecham SH-P57..SH-P59, HV-P34..HV-P39, CT-P27, PR-P166..PR-P168. Nascem HV-P40..HV-P44, PR-P169, PR-P170 (sessão), SH-P60 e AU-P6 (dele, folha 11); a revisão independente bloqueou 2 médios, consertados; nascem ainda HV-P45..HV-P47, SH-P61 (coluna de menu recolhível), PR-P171 (estudo do DS do Viver de IA), MA-P8 (Liquid Glass) e HV-P48.A leva 40 (MANIFESTO §313), loop orquestrado 800k — pedido dele: "rode o loop orquestrado 800k".
texto inteiro da versão
A leva 40 (MANIFESTO §313), loop orquestrado 800k — pedido dele: "rode o loop orquestrado 800k". A leva 39 fecha e vai ao ar (
6c6f0395); a 40 toma as pendências que ela fez nascer: tema e versão do Chrome fora das provas, guarda do avatar, caixa em 19 suítes de celular, vistas na gaveta e na âncora, guardas do contêiner próprio, do controle nativo, das palavras proibidas e do changelog do conferidor, endereço dos links públicos no §46.4. Fecham PR-P161..PR-P165, SH-P55, SH-P56, HV-P27..HV-P31, HV-P33, CT-P26, CP-P60, PR-P158, PR-P159, VT-P17. Nascem SH-P57, SH-P58, HV-P34..HV-P36, CT-P27, PR-P166, PR-P167; HV-P32 vai à folha 10.2026-10-12
a leva 39 (MANIFESTO §312).
texto inteiro da versão
a leva 39 (MANIFESTO §312). (1) §46 SH3/SH19 + SH-P54 (folha 8, L7 = b): na Encurtada, o rótulo que só cabe na Expandida vira abreviação ("Docs." dele; "Finanças" e "Indic." da sessão, a veto) com o nome completo no
aria-label; AREAS aceita o curto e ganha pasta, balão, Indicações, Indicar e Comissões (SH-P53); a guarda do rótulo cobra RL-5/RL-6. (2) SH-P52: o avatar da topbar tem alvo de 44 × 44 em todas as telas (12 de 14 mediam 32). (3) §83 A19 v0.8: cadastro do parceiro indicador (CPF obrigatório com máscara e dígitos verificadores, telefone opcional, senha de 12), "Confirme seu e-mail", "E-mail confirmado", CPF já cadastrado; revelar-senha 44 × 44 (HV-P25); suíte 57 de 57. (4) Telas novas fora da vitrine (a gate na folha 9): tela-portal-parceiro (área do parceiro, folha 8) e tela-cadastro-indicado (página pública do link). (5) §46.4: a área do cliente (A27) e o envio do fornecedor (A28) entram na vitrine; o número de telas citado passa a ser medido por guarda (VT-P15/VT-P16). (6) tela-detalhe: o filtro ligado ganha sobrevoo e pressionado pela gramática de marca chapada do §71.6 (HV-P21).a leva 38, parte 2 (MANIFESTO §311).
texto inteiro da versão
a leva 38, parte 2 (MANIFESTO §311). (1) §46 SH3/SH19: a tela que nasce no formato Expandida (
data-rail="largo") mede o rótulo contra 100 px (RL-4 da guarda-rotulo-rail.py), e a gaveta do SH12 mostra a Expandida nessas telas; a área do cliente usa a Expandida com "Financeiro" e "Documentos" (K2 dele). (2) §86 A18 v0.5: nasce a vista Pessoas (convidar, alterar papel/unidade, reenviar, revogar, variante sem permissão; suíte 42 de 42).a leva 38, parte 1: o acesso ao SIGA (MANIFESTO §310).
texto inteiro da versão
a leva 38, parte 1: o acesso ao SIGA (MANIFESTO §310). (1) §83 A19 v0.7: o aceite de convite — convite válido (regra de 12 caracteres antes do erro, e-mail fixo, aceite com links), expirado ou usado (alerta genérico), senha vazada, conta já existe; AU-18 a AU-24, suíte 33 de 33. (2) Tela nova
tela-portal-cliente (o PN10 e o DP12 numa tela: a área do cliente com Início, Finanças, Arquivos e Chamados), fora da vitrine até o gate (PR-P156).a leva 37, respostas da folha 6 (MANIFESTO §309).
texto inteiro da versão
a leva 37, respostas da folha 6 (MANIFESTO §309). (1) §95 AB11: a folha "Mais" é Perfil · Trocar de conta · Tema · Sair (
SH-P47, J2 = b; a forma do Tema, percorrer, exposta a veto em SH-P50). (2) §95 AB8: o selo cita o par text-on-action-destructive × feedback-danger-solid, 5,19/5,26 (SH-P48, J3 = a). (3) §95 AB12 (nova) e §46.7 SH22: o destino balao na barra de abas abre folha modal igual à do "Mais"; no rail segue ao lado (LC-41, J5 = b); §95.4 respondido; a guarda passa a 33 cláusulas. (4) O título do §95 deixa de dizer "sem tela de referência e sem instrumento".§9-B.2 regra 4 reescrita por veredito dele (folha 7, K10, verbatim na regra):
texto inteiro da versão
§9-B.2 regra 4 reescrita por veredito dele (folha 7, K10, verbatim na regra): a Clara se porta como pessoa, não como agente de IA; em vídeo, foto e anúncio nunca diz que é IA; perguntada no atendimento, confirma de forma leve. REVOGA a regra "voz sintética se declara" (2026-09-08) e a frase do telefone do §9-B.3; responde a T5 da folha 5. MANIFESTO §311.
A leva 39 (MANIFESTO §312), loop orquestrado 500k — pedido dele: "1 e 2 ok / rode o loop orquestrado 500k".
texto inteiro da versão
A leva 39 (MANIFESTO §312), loop orquestrado 500k — pedido dele: "1 e 2 ok / rode o loop orquestrado 500k". A folha 8 entra: a área do parceiro é refeita (sem aviso ao indicado, cadastro repetido "Em análise", dois status, Pix, link de indicação), nasce a página pública do link e o cadastro do parceiro com CPF na A19. Fecham
SH-P52, SH-P53, SH-P54, HV-P21, HV-P22, HV-P23, HV-P24, HV-P25, HV-P26, VT-P15, VT-P16, CP-P59. Nascem HV-P27..HV-P31, SH-P55, SH-P56, CT-P25, CT-P26, CP-P60, VT-P17, VT-P18, PR-P158, PR-P159, PR-P160, AU-P4, AU-P5, MR-P32, HV-P32, HV-P33, PR-P161, PR-P162; MR-P31 segue para a folha 9.A leva 38, parte 2 (MANIFESTO §311): a folha 7 (05:24Z) aprova as telas de acesso ao SIGA.
texto inteiro da versão
A leva 38, parte 2 (MANIFESTO §311): a folha 7 (05:24Z) aprova as telas de acesso ao SIGA. A área do cliente usa o rail Expandida e o link do grupo da obra; nasce a vista Pessoas na A18; a regra 4 da Clara (marca §9-B.2) é reescrita por veredito dele (se porta como pessoa). Fecham
PR-P156, SH-P51, SH-P50; nascem SH-P54 (dele), MR-P31 (sessão), PR-P157 (SIGA).A leva 38, parte 1 (MANIFESTO §310): o acesso ao SIGA
texto inteiro da versão
A leva 38, parte 1 (MANIFESTO §310): o acesso ao SIGA — pedido dele: "precisamos ter um SIGA já logavel até amanhã". Nascem a
tela-portal-cliente (área do cliente) e o aceite de convite na A19 (v0.7). Nascem PR-P156 e SH-P51 (dele, folha 7), SH-P52, SH-P53, HV-P24 e HV-P25 (sessão).A leva 37 (MANIFESTO §309): as respostas da folha 6 (gravadas 01:02Z, todas na recomendação) entram no shell e no canon
texto inteiro da versão
A leva 37 (MANIFESTO §309): as respostas da folha 6 (gravadas 01:02Z, todas na recomendação) entram no shell e no canon — Tema na folha "Mais", selo pelo par de tokens, AB12 (o destino balão na barra é folha modal); a /marca/ ganha um bloco por nome nas assinaturas (pedido dele de ~01:25Z). Fecham
MR-P30, SH-P47, SH-P48, SH-P49, TK-P11, PR-P155 e LC-41; nascem SH-P50 (dele) e CT-P24 (sessão).2026-10-11
v2.6 · 2026-10-11: a linha "Chat / mensageria" do §3 segue a §94.14 do seed-componentes.md (LC-37, MANIFESTO §308) — balão radius-4 com o canto do autor em radius-1, sombra --seed-shadow-raised, divisor de data em…
texto inteiro da versão
v2.6 · 2026-10-11: a linha "Chat / mensageria" do §3 segue a §94.14 do
seed-componentes.md (LC-37, MANIFESTO §308) — balão radius-4 com o canto do autor em radius-1, sombra --seed-shadow-raised, divisor de data em pílula, ritmo de 4 px (sp-1) e sp-2; e o canvas passa a "uma peça, separadas por borda" (MS4), não mais "peças irmãs em split (CP29)" — decisão da sessão exposta a veto. Antes: v2.5 · 2026-09-27: REV-P23 (MANIFESTO §268.3): o §0 passa a citar as donas dos dois conceitos que declara — a arquitetura das três camadas (seed-tokens.md §1) e a lei de base da montagem (§1 deste arquivo). Até a leva 4 um "§1" do seed-componentes.md no §0 passava por essa citação; quando a régua CI-11 passou a ler de qual documento é cada "§N" (PR-P43), as duas pontes que faltavam apareceram. Nenhuma regra muda. · v2.4 · 2026-09-19: F12.4 (MANIFESTO §234, 2026-09-19): a história de cada seção migra para o fim dela, sob ### Histórico da seção (V-SK1 = b) — 2 de 16 seções alcançadas (§7b e §7c, 1 grupo cada, as duas "alternativa descartada"), texto movido byte a byte, 0 linha perdida, 4 linhas novas, arquivo LF puro sem CRLF criado, geradores byte-idênticos. · v2.3 · 2026-09-14: o CP28 ganha a fronteira que faltava — a raiz tela significa "sem shell NA BANCADA"; no produto toda tela de aplicação vive dentro do shell (SH17, seed-componentes.md §46.4). Motivo: a sessão do ERP leu "arquétipo que roda SEM shell" como decisão de produto e construiu uma tela sem rail (MANIFESTO §219); nenhuma regra de composição muda. v2.2 · 2026-09-13: a bancada banco-tokens.html sai do mapa de nomes do §7d (removida pelo processo de remoção, veredito dele D-3 na folha "Fila do DS — decisões rápidas", MANIFESTO §208) — nenhuma regra muda. v2.1 · 2026-08-16: promoção estável (ver cabeçalho). v2.0 — A FUNDAÇÃO · 2026-08-15. Primeira edição que amplia o sistema em vez de refinar: CP2 vai de 6 a 7 tipos (SUP-7), nasce a camada de primitivos (SUP-8, CP25), o responsivo passa a ter duas camadas com fronteira normativa (SUP-9, CP26–CP28), arraste vira lei do sistema (SUP-10, CP30), relações de composição ganham contrato (CP29) e bancada×tela viram classes nomeadas (SUP-11, CP31). A tabela do §3 vai de 11 para 23 gabaritos. Origem: consolidado da F7.1 aprovado pelo Rafael em 2026-08-15 ("aprovo"), após 3 rodadas de pesquisa e o mapa-cobertura-ds.md v0.3. Histórico: v1.6 fechou a CP-P2 e a errata de cabeçalho; v1.5 fechou a CP-P1; v1.4 mudou o rail para peça; v1.0–v1.3 nasceram e consolidaram a Fase 2.a leva 36, primeiro loop orquestrado (MANIFESTO §308).
texto inteiro da versão
a leva 36, primeiro loop orquestrado (MANIFESTO §308). (1) §95 e §1.14: a barra de abas, a folha "Mais" e o botão flutuante saem emitidos pelo
shell_bloco.py; tela de referência tela-shell-abas.html (terceiro regime do A1) e guarda guarda-barra-abas.mjs no rito, 22 cláusulas (os 7 testes do §95.3, F1–F7, M1–M8) — os textos "sem tela de referência e sem instrumento" deixam de valer (LC-39, LC-40); o ativo responde ao ponteiro na família do botão secundário. (2) §94: nasce a forma TELA da mensageria, tela-mensageria.html (segunda tela do A23), com a suite-mensageria.mjs (94.12 com instrumento, 29 de 29); 94.13 item 3 cumprido; 94.14 registra o composição editado (LC-38, LC-37). (3) §46.4: 20 telas, 15 gabaritos (o texto dizia 17). (4) Régua do ponteiro: HV1 nos papéis de lista, menu, aba, rádio, árvore e interruptor (PR-P154), no modal do A8 (HV-P20) e a 390 px. Decisões da sessão expostas a veto na folha 6 (SH-P47, SH-P48, SH-P49, TK-P11, PR-P155).a leva 35, fila da sessão (MANIFESTO §307).
texto inteiro da versão
a leva 35, fila da sessão (MANIFESTO §307). (1) §2.4: o erro vence o sobrevoo também no seletor, na busca, na hora do calendário, no filtro e nos
select do painel; em controle com invólucro o erro pode estar no controle interno, e a exclusão é :not([aria-invalid="true"]):not(:has([aria-invalid="true"])) (PR-P148). (2) §57 QD22: o quadro de funil tem a variante sem permissão de gerir funil — "Editar funil" e "Novo funil" não existem no DOM e uma nota diz como pedir (QD-P20). (3) §62.4: a lista aberta do seletor de pessoa ganha cobaia medida nos dois temas e o caso da lista que sobe (PD-P11). (4) §46 SH3: todo rótulo de rail das telas é medido no rito pela tabela de avanços (PR-P147, guarda guarda-rotulo-rail.py).a leva 34, fila da sessão (MANIFESTO §306).
texto inteiro da versão
a leva 34, fila da sessão (MANIFESTO §306). (1) §22: as telas de notas fiscais e de propostas ganham as classes da paleta de entidade do chip de status, do módulo único (
QD-P19). (2) §46 SH3: o rótulo do rail se mede por tabela de avanços da Montserrat Bold 700 com kerning, não por contagem de letras (PR-P146; desvio máximo 0,014 px contra o Chrome). (3) §62.4 / PD22: a lista aberta do seletor de pessoa medida no gabarito A8 — 320 px de largura, 264 px de altura máxima, 4 px do campo, --seed-z-popover (PD-P10). (4) §57 QD22: exercido no gabarito novo tela-quadro-funil (mesmo A7, modo funil comercial; QD-P14); linha nova na tabela do §46.4. (5) §68.2: a proposta é a peça do modo peça da skill seed-ds (as skills antigas não existem; SK-P12).as levas 32 e 33: as folhas 3 e 4 sobre o STATUS (MANIFESTO §303–§304).
texto inteiro da versão
as levas 32 e 33: as folhas 3 e 4 sobre o STATUS (MANIFESTO §303–§304). (1) §22: nasce o tom
st-erro (vermelho de perigo existente; "Perdido", G1 = a); W9 e §22.4 — a cor do status é CAMPO EDITÁVEL numa paleta fechada de 11 cores (os 5 tons + 6 de entidade, todas ≥ 4,5 nos dois temas; observação dele no G2 e H4 = a), com a sugestão de fábrica marcada (Pendente cinza, H1 = a); W10 — cada TIPO de registro tem o seu conjunto (H3 = a); 22.4.5 — "Atrasada" deixa de ser status e vira marca de PRAZO ao lado dele (H2 = a). (2) §57: QD23 emendado, QD24 novo, §57.7 (G2, G3). (3) §86.4: a tela Configurações → Status no gabarito tela-configuracoes v0.4 (H5 = b), com o controle de cor num módulo único (cor_status_bloco.py). Telas: detalhe v0.7, tabela v0.6, chat v0.5, quadro v0.6; bancada banco-escolha v0.5. Aplicado pelos agentes das levas 32 e 33, consolidado pela sessão.§5.6 em duas classes (pedido dele de 2026-10-11, verbatim no §5.6):
texto inteiro da versão
§5.6 em duas classes (pedido dele de 2026-10-11, verbatim no §5.6): assinaturas de produto (SEED chat, SEED siga — em uso nas telas de entrada; os 18 arquivos seguem em
03-assets/logos/produtos/, mesmos bytes) e de empresa do grupo (SEED holding, SEED energia — reservadas, sem uso até decisão dele; 03-assets/logos/empresas/, 18 arquivos). A holding muda de pasta com os mesmos bytes (301 no deploy); nasce a SEED energia com 9 variações, pelo mesmo gerador e a mesma construção. Nenhum dado institucional sobre as duas: o sobreaseed.md não traz. MANIFESTO §308; uso e nome da pasta na folha 6 (MR-P30).A leva 36, primeiro loop orquestrado (MANIFESTO §308; pedido dele, verbatim: "Rode loop orquestrado 600k").
texto inteiro da versão
A leva 36, primeiro loop orquestrado (MANIFESTO §308; pedido dele, verbatim: "Rode loop orquestrado 600k"). Fecham
CP-P58 (o CP-5 vê as assinaturas; relato do SIGA), HV-P20, PR-P154, LC-37, LC-38, LC-39 e LC-40; holding e energia viram assinaturas de empresa do grupo (pedido dele de 19:08Z). Nascem MR-P30, SH-P47, SH-P48, SH-P49, TK-P11, PR-P155 (folha 6, dele), CP-P59, HV-P21, HV-P22, HV-P23 e VT-P15 (sessão); LC-41 à folha 6 com prancha.A leva 35 (MANIFESTO §307): quatro pendências da fila da sessão fecham.
texto inteiro da versão
A leva 35 (MANIFESTO §307): quatro pendências da fila da sessão fecham.
PD-P11 (cobaia do seletor de pessoa aberto), QD-P20 (funil sem permissão), PR-P147 (guarda nova guarda-rotulo-rail.py: 52 rótulos, 0 reprovam) e PR-P148 (o erro vence o sobrevoo em mais 5 controles). Nascem PR-P154 (a HV1 não alcança role="option") e HV-P20 (12 identidades da HV1 com o modal do A8 aberto). Componentes v1.86.A leva 34 (MANIFESTO §306): cinco pendências da fila da sessão fecham.
texto inteiro da versão
A leva 34 (MANIFESTO §306): cinco pendências da fila da sessão fecham.
QD-P19 (cor editável nas telas de notas e propostas), PR-P146 (rótulo do rail medido por tabela de avanços), SK-P12 (citação das skills extintas), PD-P10 (seletor de pessoa aberto e medido no A8; z-index solto da bancada vira token) e QD-P14 (gabarito tela-quadro-funil, na vitrine). Nascem PD-P11 e QD-P20. Componentes v1.85.As levas 32 e 33 (MANIFESTO §303–§304) e a régua do CP-1 no escuro (§305).
texto inteiro da versão
As levas 32 e 33 (MANIFESTO §303–§304) e a régua do CP-1 no escuro (§305). Folha 3 (G1 a, G2 ok com a cor editável, G3 a) e folha 4 (H1 a, H2 a, H3 a, H4 a, H5 b): tom
st-erro, um conjunto de status por tipo de registro, a cor do status editável numa paleta fechada de 11, "Atrasada" vira marca de prazo, a tela Configurações → Status; QD-P17 e QD-P18 fecham, nasce QD-P19. O conferir-peca.py passa a aceitar as cores do tema escuro no CP-1 (CP-P57, relato da sessão SIGA). Triagem dos pedidos de cobertura no banco (PR-P151): 35 de 74 gravados pela decisão "a, a, a"; os 39 restantes na folha 5. Componentes v1.84.2026-10-10
a leva 31: as respostas dele às folhas 2, QD-P16 e 3 (MANIFESTO §302).
texto inteiro da versão
a leva 31: as respostas dele às folhas 2, QD-P16 e 3 (MANIFESTO §302). (1) §94
estável (Q10 sem veto) e o tique "lida" em AZUL feedback-info-text na MS14 (Q5, observação dele; azul confirmado na folha 3, G5 = ok). (2) §95 AB11: a última aba do celular é "Mais", com a conta dentro (F4c = a), e "Mais" abre folha modal de baixo (G4 = a). (3) Select com estado de erro igual ao campo (§2.4, §7.3, §7.6; PR-P149, F5 = a). (4) §47.7 MK29 revisada: a barra de acessibilidade da vitrine fica sem accesskey e sem número (F1a = b, PB-P12). (5) §57 QD23: o status da etapa é o chip do §22 no cabeçalho da coluna, N etapas : 1 status, o cartão não repete (F7 a e QD-P16 = c, verbatim no QD23); QD2 reaberto, QD13 emendado. (6) Token --seed-toast-bg/--seed-toast-text (tokens v1.36, PR-P152 = b). Aplicado pelos agentes a–d da leva 31, consolidado pela sessão.a leva 30: as folhas v3 pela recomendação da sessão (resposta dele "a, a, a", MANIFESTO §301).
texto inteiro da versão
a leva 30: as folhas v3 pela recomendação da sessão (resposta dele "a, a, a", MANIFESTO §301). §57 ganha QD15–QD22 (pílula neutra da etapa, aviso da etapa sem criação, setas do degrau estreito, selos da tarefa e ação compacta, pele do alerta no cartão fora do prazo, ações do funil) e §49 ganha PD20–PD24 (barra de ações do registro, PD9 na grade, seletor de pessoa em sobreposição, ajuda do exigido, rótulo truncado com foco e balão); gabaritos A7 v0.5 e A8 v0.6 regenerados. CH7 do §55 ganha a exceção nomeada do motivo permanente de falha e a MS14 do §94 os dois rótulos ("Não enviada" × "Não entregue").
estável no título de 10 seções transversais (REV-P12 6a) e no §95 (marcador da sessão, exposto a veto).as respostas dele à folha de 2026-10-10 entram no canon (MANIFESTO §300).
texto inteiro da versão
as respostas dele à folha de 2026-10-10 entram no canon (MANIFESTO §300). (1) Chat de atendimento (pranchas LC-15/LC-16/LC-19): nasce o §94 Mensageria de atendimento (MS1–MS40) com as escolhas dele, verbatim "Q1 a, Q2 c, Q3 b, Q4 a, Q5 a, Q6 a, Q7 a, Q8 a, Q9 a" — a Q10 (veto geral) ficou sem resposta e segue a decidir; supersede parcial do CH14 do §55. (2) Barra de abas de aplicativo (§95, AB1–AB10, "V-AB1 a, V-AB2 b") e botão flutuante (§1.14, FB1–FB8, "V-FB1 c, V-FB2 b", veto nenhum); exceção ao SH12 do §46. (3) Campo: o vermelho do erro VENCE o sobrevoo (
PR-P133, resposta "A" depois da folha visual) e o stepper segue a mesma regra do campo, E10 do §5.2 (PR-P134, "a"). (4) Rail: a SH3 passa de "≤ 9 letras" para "cabe em 68 px medidos" (SH-P31, "a"; "Qualidade", 9 letras, mede 68,55 px no ativo e não cabe — a letra não prevê a largura) e o anel duplo de foco do rail sobe ao canon como SH15-c (SH-P38, "a", exposto a veto). Aplicado pelos agentes a e b da leva 29, consolidado pela sessão.MR-P29 — os logos de fundo azul e de fundo cinza saem das variantes (§5.1: 14 → 12).
texto inteiro da versão
MR-P29 — os logos de fundo azul e de fundo cinza saem das variantes (§5.1: 14 → 12). Achado dele: são o logo branco aplicado sobre painel, exemplos do manual de 2018. Os dois SVG vão para 08-historico/logos-exemplos-do-manual/, saem da página /marca/ e do conferidor de peça (as provas prova-cp5-fase-e-borda e prova-cp5-forma-alterada montam o painel e pousam o mono-negativo: 12 de 12 e 29 de 29). Na v5.56 a sessão escreveu "sem as de fundo azul e cinza" sobre as assinaturas e ele entendeu, com razão, que os oficiais também tinham saído — não tinham; esta versão faz o que a resposta "a" pediu. MANIFESTO §299.MR-P28 — as assinaturas de produto SEED chat, SEED siga e SEED holding (§5.6, nova).
texto inteiro da versão
MR-P28 — as assinaturas de produto SEED chat, SEED siga e SEED holding (§5.6, nova). Pedido dele (2026-10-09) e respostas à folha de gate, verbatim no §5.6: o logo oficial com a palavra de baixo trocada, gerado (gen-logos-produto.py) a partir dos SVG oficiais — fonte Montserrat ExtraLight (200, provada contra o "engenharia" oficial), vão óptico uniforme medido no oficial, barrinha byte a byte; 9 variações por nome (sem as de fundo azul e cinza, achado dele), 27 arquivos em 03-assets/logos/produtos/; SEED chat no login do SEED Chat, SEED siga no login do SIGA, SEED holding reservada. MANIFESTO §298.§6 ganha "Soluções — escopo padrão" (SK-P1 fecha; resposta dele à P11 da folha de 2026-10-10: "a" = "b nas 7 fichas (aprovo com as correções das divergências) e os itens SEM FONTE SAEM").
texto inteiro da versão
§6 ganha "Soluções — escopo padrão" (
SK-P1 fecha; resposta dele à P11 da folha de 2026-10-10: "a" = "b nas 7 fichas (aprovo com as correções das divergências) e os itens SEM FONTE SAEM"). Entra só o que confere com o canon (18 itens) e as 6 divergências já corrigidas (GMG com dois regimes e "gás natural"; SPDA pela NBR 5419-1 a -4 edição 2026; o laudo de Análises; as oportunidades do Diagnóstico 360°), cada item com a fonte. Saem os 57 itens sem fonte (preço, faixa, garantia, prazo, premissa, número técnico) e as 14 normas/leis "a conferir". Nada de preço, prazo ou garantia: a proposta pergunta. Auditoria: ds-w30-entregas/d/auditoria.json. MANIFESTO §300. E a errata do §9 (LC-33 e, MANIFESTO §301): a manuscrita deixa de citar a Indie Flower (aposentada em 2026-07-30; sucessora Caveat, marca-seed.md §4.3/§4.4). Nenhum dado institucional muda.A leva 31 (MANIFESTO §302): as respostas das folhas 2, QD-P16 e 3 entram no canon e nas telas.
texto inteiro da versão
A leva 31 (MANIFESTO §302): as respostas das folhas 2, QD-P16 e 3 entram no canon e nas telas. Token do aviso
--seed-toast-bg/-text (tokens v1.36, PR-P152 = b) e a entrega g da leva 30; guarda-valor-gemeo de volta ao rito de todo commit (F8a = b); barra da vitrine sem accesskey (MK29 revisada, F1a = b) e guarda nova de vigência de lei guarda-leis.py, só no --bloco (F1b = sim; PB-P12 fecha); §94 estável e tique "lida" azul (Q5; G5 = ok); AB11 "Mais" com a conta, folha modal (F4c = a, G4 = a); select com estado de erro (PR-P149, F5 = a); QD23 status da etapa no cabeçalho da coluna (F7 a, QD-P16 = c; QD-P15/QD-P16 fecham). Componentes v1.83. Nascem QD-P17 e QD-P18 (folha 3, G1–G3 e a cor editável do status, leva 32).A leva 30 (MANIFESTO §301): as três folhas v3 (76 itens) pela recomendação da sessão — resposta dele "a, a, a".
texto inteiro da versão
A leva 30 (MANIFESTO §301): as três folhas v3 (76 itens) pela recomendação da sessão — resposta dele "a, a, a". Triagem: 17 linhas novas na Fila LC (LC-20..LC-36), 3 pedidos juntados à LC-32, a exceção da CH7 e os dois rótulos de falha no canon; fatias: estado
estável/histórico declarado em 7 canônicos (REV-P12 6a, REV-P25 fecham); quadro e detalhe: QD15–QD22 e PD20–PD24 com as telas pelo gerador. A parte da leva 4 de rail, tokens, contraste forçado e rito (agente g) fica para o §302: carrega 1 FAIL conhecido (a cor do aviso .toast, PR-P152, dele). Componentes v1.82, práticas v1.12.A leva 29 (MANIFESTO §300): as respostas da folha de 2026-10-10 entram no canon.
texto inteiro da versão
A leva 29 (MANIFESTO §300): as respostas da folha de 2026-10-10 entram no canon. Chat de atendimento §94 (Q1–Q9 dele; Q10 a decidir), barra de abas §95 e botão flutuante §1.14 (LC-15..LC-19 fecham no canon); o erro vence o sobrevoo e o stepper segue o campo (PR-P133, PR-P134); SH3 por largura medida e SH15-c (SH-P31, SH-P38); "Soluções — escopo padrão" no sobreaseed (SK-P1); o CLAUDE.md do projeto aponta o requirements-rito e diz que o selo é guarda de processo (PR-P37). Componentes v1.81. Nascem PR-P146..P150, LC-37..LC-41, SK-P11..P13.
Os logos de fundo azul e cinza saem das variantes (MANIFESTO §299, MR-P29 fecha).
texto inteiro da versão
Os logos de fundo azul e cinza saem das variantes (MANIFESTO §299,
MR-P29 fecha). Achado e resposta "a" dele: são o logo branco sobre painel, exemplos do manual; vão para 08-historico/logos-exemplos-do-manual/, saem da página /marca/ (Logotipo: 12) e das provas do conferidor (12 de 12 e 29 de 29, montando o painel); marca-seed.md v5.57. Ele viu os dois ainda na página depois do checkpoint — a frase de entrega da v2.143 falava só das assinaturas e não nomeava a MR-P29 aberta.As assinaturas de produto (MANIFESTO §298, MR-P28).
texto inteiro da versão
As assinaturas de produto (MANIFESTO §298,
MR-P28). Pedido dele: o logo com "chat", "SIGA" e "holding" no lugar de "engenharia" — SEED chat para o login do SEED Chat, SEED siga para o login do SIGA, SEED holding reservada. Gerador novo a partir dos SVG oficiais, na fonte do descritor (Montserrat ExtraLight, provada por medida) e no vão óptico uniforme do oficial; 9 variações por nome (sem fundo azul e cinza, achado dele); marca-seed.md v5.56 §5.6 e seção nova na página /marca/. Nasce MR-P29 (os dois logos oficiais de fundo azul e cinza, dele).PR-P152 = b (leva 31, MANIFESTO §302) — nascem --seed-toast-bg e --seed-toast-text.
texto inteiro da versão
PR-P152 = b (leva 31, MANIFESTO §302) — nascem --seed-toast-bg e --seed-toast-text. Resposta dele na folha 2 (gravada 2026-10-10 11:22Z): F2 = b, "token semântico novo com a mesma cor de hoje". #00352F (turquesa-900) de fundo e #FFFFFF de texto, invariantes de tema, no CSS, no JSON (semantic.toast) e no §3e; consumidos pelos moldes de tela-detalhe, gantt, quadro e domínio, que antes pintavam o valor solto (o que fazia a suite-escolha reprovar a tela-detalhe). Adição pura: nenhum valor anterior muda.Estado estável declarado no cabeçalho (REV-P12 item 6a).
texto inteiro da versão
Estado
estável declarado no cabeçalho (REV-P12 item 6a). Resposta dele à P12 da folha de perguntas de 2026-10-10: "a, a, a" — a recomendação da folha das fatias. Nenhuma regra muda. MANIFESTO §301.2026-10-09
A leva 28 (MANIFESTO §297)
texto inteiro da versão
A leva 28 (MANIFESTO §297) — mesma rodada contínua: a HV1 ganha a cláusula de monotonia do pressionado (HV1-e) e os 151 casos que ela reprovava são consertados pela gramática aprovada (V-HV4.1 = a); a auditoria de borda passa a ver o invólucro do campo; a régua de contraste a 390 px trata queda do navegador como NÃO MEDI com uma reexecução (inclusive a queda na abertura, que só deixa o aviso de espera de topo) e separa a variância de cobertura do veredito. Fecham PR-P143, PR-P130, PR-P144, PR-P145.
A leva 27 em modo contínuo (MANIFESTO §296).
texto inteiro da versão
A leva 27 em modo contínuo (MANIFESTO §296). "pode seguir, so pare quando nao tiver mais pendencias ou quando atingir 900 mil de contexto" (só nesta rodada): a HV1 ganha a cláusula de campos (HV1-d) e o acervo inteiro ganha o sobrevoo de campo do canon (51 campos de produto e a barra de provas); a HV1 zera fora do baseline (HV-P9, HV-P8); oito pendências de setembro que esta tabela ainda marcava ⚪ fecham (e três células de estado velhas são corrigidas); sete bancadas e a dataviz-di ganham gerador; quatro lacunas de instrumento ganham cobaia (RC em
<details>, AC5 no @media escuro, monotonia do pressionado). Nascem PR-P143, PR-P130 (sessão) e PR-P133, PR-P134 (dele, canon de campo). Folha de perguntas da rodada no fechamento.A leva 26 (MANIFESTO §295).
texto inteiro da versão
A leva 26 (MANIFESTO §295). "abra o proximo grupo, pode continuar abrindo novos grupos de pendencia" e, na folha da PR-P118, "B." — "só pare quando precisar compactar, siga abrindo as demandas, mesmo as novas que aparecer": o seletor de frequência da
tela-painel ganha sobrevoo próprio (turquesa --seed-button-secondary-border no claro, 3,31; --seed-field-border-hover no escuro, 5,62), com asserções e cobaia no rito; a tela sobe a v0.19. Nascem PR-P119 (sobrevoo de campo sem régua) e PR-P120 (pastas de entrega dos agentes).2026-10-08
o rail ganha o TERCEIRO formato e o sobrevoo que expande (SH-P46, o §46 sobe a v0.52).
texto inteiro da versão
o rail ganha o TERCEIRO formato e o sobrevoo que expande (
SH-P46, o §46 sobe a v0.52). Pedido dele, verbatim: "preciso que crie um novo formato para o Rail. hoje temos 2, minimizado e encurtado, crie o formato expandido. o usuário poderá optar pelo formato que quiser. o formato padrao continua o mesmo, ele pode expandir e encurtar pelo botao ou alterar suas preferencias. no formato encurtado quero que nas preferencias vc coloque opçãp de expandir para o formato expandido se passar o mouse em cima". Veredito sobre a folha do estudo, verbatim: "pode seguir / folha nao abriu" — aprova as 8 saídas marcadas "← leitura da sessão" (Q1 a Q8). O SH19 é reescrito (três formatos: Minimizada recolhido 56 · Encurtada expandido 80, o padrão · Expandida largo 160 = sp-16 + sp-24; o botão alterna Encurtada ↔ Expandida; o limiar do Q3; o sobrevoo data-rail-sobrevoo), e as duas linhas de "Descartado" de setembro (o expandido de 220 px e o sobrevoo que expande) passam a "superadas pelo veredito de 2026-10-08", com o texto antigo preservado. O SH3 diz que os 80 px são do formato padrão; o SH21 ganha o grupo "Barra lateral" e o item "Expandir ao passar o mouse"; o SH22 registra que a prévia cede ao sobrevoo; a porta do SIGA passa a 3 valores + 1 booleano. Régua nova: render-rail.mjs (R18 limiar, R19 sobrevoo, R20 botão e menu) com a prova de cobaias provas/rail-formatos/.A leva 25 e o rail com três formatos (MANIFESTO §294).
texto inteiro da versão
A leva 25 e o rail com três formatos (MANIFESTO §294). "1 turquesa, 2 aplica, e abra o proximo grupo": a borda do select do painel passa a turquesa (PR-P103) e a folha da assinatura imprime em piso (PR-P110); três provas intermitentes têm a causa medida (PR-P114 a cobaia, PR-P117 a carga, PR-P115 não reproduzida) e a de estabilidade é partida por alvo (PR-P108/P116). Pedido novo dele (SH-P46): o rail ganha o formato Expandida de 160 px e o sobrevoo que expande, como preferência do usuário (canon
seed-componentes.md v1.80, SH19 reescrito; supersede duas linhas descartadas em 2026-09-15).A leva 24 (MANIFESTO §293).
texto inteiro da versão
A leva 24 (MANIFESTO §293). "abra o proximo grupo": a razão de contraste passa a decidir sem arredondar e sem folga em todo o acervo (PR-P105, PR-P107, PR-P111; 0 veredito mudou) e a imprimir em piso (PR-P106); as réguas de forced-colors e peça×token ficam verdes pelo gerador sem mudar o que se vê (PR-P102, PR-P104); a pasta
contraste/ entra na guarda IR e no rito (PR-P112, 191 instrumentos); o DS acha o SIGA em dev/seed-siga (PR-P113, aviso REV-45). Duas decisões de conteúdo vão a ele: PR-P110 (números da folha da assinatura) e PR-P103 (borda do select sobre o véu do hero).2026-10-07
O fechamento da leva 23 sem perguntas (MANIFESTO §292).
texto inteiro da versão
O fechamento da leva 23 sem perguntas (MANIFESTO §292). "vc deve terminar o trabalho e nessa etapa deve fazer o que precisa ser feito": o
render-malha.mjs morto sai (PR-P109) e a leva é publicada junto com o §290 e o §291; a trava do rm -rf dos clones é uma regra deny do settings.json dele, entregue para ele editar.A leva 23 (MANIFESTO §291).
texto inteiro da versão
A leva 23 (MANIFESTO §291). "abra o proximo grupo": o censo mostrou que o rito iniciava 94 de 171 instrumentos; 69 verdes e baratos entram, 7 caros vão ao
--bloco, e a guarda nova guarda-instrumento-no-rito exige exceção declarada para quem ficar fora (100 → 172 guardas; rito ~31 → ~42 min). Três réguas estavam vermelhas por defeito de artefato (PR-P102 a PR-P104). A razão de contraste passa a ser impressa em piso por um módulo comum (JS e Python) em 32 instrumentos, e três lugares que decidiam sobre a razão arredondada passam a decidir sobre a inteira. Fecham PR-P100 e PR-P101; nascem PR-P102 a PR-P109.A publicação da leva 22 e os 8 PNG regenerados (MANIFESTO §290).
texto inteiro da versão
A publicação da leva 22 e os 8 PNG regenerados (MANIFESTO §290). "pode regenerar os 8 PNG, pode publicar e abra o proximo grupo":
71daea3c no ar (1696 de 1696 por MD5, produção zero FAIL); os 8 PNG velhos desde a MR-B regenerados pelo render-peca.mjs (8 de 8, duas cargas idênticas); a PF-01 do acervo inteiro dá 161 PASS · 0 FAIL e passa a rodar no --bloco. Fecha PF-P9.A leva 22 (MANIFESTO §289).
texto inteiro da versão
A leva 22 (MANIFESTO §289). "autorizo vc a remover pastas quando precisar, nao quero que vc me peça. / abra o proximo grupo". Três agentes Sonnet em série: as suítes
render-painel/render-site entram no rito (~14 s e ~8 s); guarda nova guarda-escritor-mkdir (0 achados em 32 escritores); a PF-01 confere as peças de gate numa 2.ª captura (0 → 5 conferidas) e roda no rito pela primeira vez; os 8 FAIL do acervo são PNG velho desde a MR-B (a regeneração foi negada à sessão pelo classificador: vai a ele); o número de contraste sobre degradê sai igual nos 3 rasters ("≥ X" em piso). Na consolidação, uma prova antiga fora do rito quebrada pela mudança: consertada e posta no rito. Fecham PR-P97, PR-P98, PR-P99, PF-P7, PF-P8; nascem PF-P9, PF-P10, PR-P100, PR-P101.2026-10-06
A publicação das levas 20 e 21 (MANIFESTO §288).
texto inteiro da versão
A publicação das levas 20 e 21 (MANIFESTO §288). "pode publicar":
c4999f23 no ar (1696 de 1696 por MD5), com o nginx.conf testado antes por nginx -t na imagem exata de produção; os 3 endereços antigos com "erp" respondem 301; produção zero FAIL. Fecha SH-P45.A leva 21 (MANIFESTO §287).
texto inteiro da versão
A leva 21 (MANIFESTO §287). "Execute a remoção. Abra o próximo grupo": as 3
folha-estudo-* saem do repositório (recuperáveis por git). Três agentes Sonnet em série: as suítes render-site/render-painel criam a pasta de saída e o calendário deixa de contar 37 dias (era o seletor da suíte); a prova da GR1-b para de sortear o raster; a guarda-gi2 lê o fundo sob o texto (.btn-solucao 3,31 → 9,7, nenhum veredito vira); a guarda-peca-fresca reconhece peça de tela; o resto do SIGA (42 linhas, 3 títulos) com redirecionamento 301 dos endereços antigos e guarda nova no rito. Fecham PR-P92 a PR-P96, PF-P6, SH-P44; nascem PR-P97 a PR-P99, PF-P7, PF-P8, SH-P45.A publicação da leva 19 e a leva 20 (MANIFESTO §286).
texto inteiro da versão
A publicação da leva 19 e a leva 20 (MANIFESTO §286). "pode publicar": o
3c4b0df1 no ar, produção zero FAIL. "sim, está correto, definimos SIGA como nome": o sistema de gestão da SEED passa a se chamar SIGA no DS (SH23, componentes v1.79; 286 menções trocadas, história intocada). Folha respondida ("CP-P53: B", "CP-P54: pode aplicar nas 22"): 22 peças aprovadas passam no CP-10 com a imagem idêntica, e o rótulo bancário da proposta vira [DADOS BANCÁRIOS DA SEED]. Mais 10 instrumentos congelam pseudo-elementos, prova de estabilidade sob carga (fora do rito), e a guarda-gi2 sem empate no anel. Fecham SH-P43, CP-P53, CP-P54, PR-P88 a PR-P91; nascem PR-P92 a PR-P96, PF-P6 e SH-P44.2026-10-05
o sistema de gestão da SEED passa a se chamar SIGA no DS (SH-P43, nasce a SH23 no §46.8, o §46 sobe a v0.51).
texto inteiro da versão
o sistema de gestão da SEED passa a se chamar SIGA no DS (
SH-P43, nasce a SH23 no §46.8, o §46 sobe a v0.51). Veredito dele, dado no seed-erp (MANIFESTO §285): "o nome é "SIGA" – Sistema Integrado de Gestão Assistida. com a tagline "Gestão inteligente""; confirmado ao ser perguntado se o nome entra no DS: "sim, está correto, definimos SIGA como nome". A SH23 registra o nome, a tagline e a forma do <title> (entrada "SIGA · Gestão inteligente"; internas "<Tela> · SIGA"). No corpo deste arquivo as menções ao produto da SEED trocaram de "ERP" para "SIGA"; ficam como estavam o changelog, o verbatim, as datas passadas e o uso de "ERP" como categoria de software ("sistemas ERP", Fiori, SAP).A publicação da leva 18 e a leva 19 (MANIFESTO §285).
texto inteiro da versão
A publicação da leva 18 e a leva 19 (MANIFESTO §285). "pode publicar e depois abra a proxima": o
ef955979 no ar, produção zero FAIL. Dois agentes Sonnet em série: a prova-inercia deixa de reprovar a si mesma (o congelamento não alcançava ::after; raster parcial sob carga — 0 px em 8 comparações solo e 32 sob carga); a guarda-tinta-marca sem alvo diz NÃO MEDI; render-dg, render-painel, render-site, render-shell, render-promocao e auditoria-borda-campo repetem o PNG sob carga (o render-dg só depois do conserto da sessão no aviso que fecha sozinho); 3 ferramentas com playwright-core solto portadas. Fecham PR-P84 a PR-P87; nascem PR-P88 a PR-P91 e a SH-P43 (dele: o nome SIGA no DS).2026-10-04
A publicação da leva 17 e a leva 18 (MANIFESTO §284).
texto inteiro da versão
A publicação da leva 17 e a leva 18 (MANIFESTO §284). "ok, pode publicar quando terminar": o
7cb35d32 no ar, produção zero FAIL. "após o checkpoint, inicie as novas pendencias": dois agentes Sonnet em série. O CP-10 só cobra <h1> de página, e-mail, slide e tela (peça física e imagem de rede: não se aplica) — ficha inteira nas 189 peças FAIL 170→35, PASS 13→120; o cor_em lê o buffer uma vez por página (CP-4 de PDF 524→303 s, mesmas amostras em 181 de 181); a régua de contraste e a prova-47o-defeito passam ao raster determinista (0 viradas de veredito em 19.082 textos; baseline regerado igual em 2 de 2). Fecham CP-P51, CP-P52, PR-P82, PR-P83; nascem CP-P54 (dele: 22 FAIL reais do CP-10 em peças aprovadas), PR-P84–PR-P87.A leva 17 (MANIFESTO §283).
texto inteiro da versão
A leva 17 (MANIFESTO §283). "pode abrir a leva 17": dois agentes Sonnet em série. O conferidor de peça perde o último FAIL do CP-5 (era o anel tracejado de anotação do avatar, não a marca: PASS 146→147, FAIL 1→0 em 189 peças), volta a ver a serra nas capas de tela, cai de ~105 s para ~39 s na lateral de frota e passa a tratar
[ASSIM] como placeholder; o requirements-rito.txt vira a fonte única do pré-voo, com checagem lista × imports; o censo do raster por GPU (86 lançadores de Chrome) achou só 1 no rito, com veredito estável. Fecham CP-P47–P50, PR-P80, PR-P81; nascem CP-P51–P53 (a P53 é dele), PR-P82, PR-P83. Publicado no dia anterior: o 08a9d85e (produção zero FAIL).2026-10-03
MR-P25 fecha — MR-B: D: a família vertical do logo passa às três cores da horizontal principal (leva 16, agente A).
texto inteiro da versão
MR-P25 fecha — MR-B: D: a família vertical do logo passa às três cores da horizontal principal (leva 16, agente A). Veredito dele, verbatim (2026-10-03, ~18:01Z): "MR-B: D, e regenere as folhas com carimbo novo" (a saída D: "alinhar a família vertical à horizontal principal: #10B4AF → #00ACAC, #5B727E → cinza-600 #617683, #F6D333 → amarelo-200 #FAD61D"). §5.1: parágrafo novo ao lado da exceção da MR-A. Três arquivos de 03-assets/logos/ trocam o hex (logo-vertical-principal 3, logo-vertical-fundo-turquesa 2, logo-vertical-fundo-turquesa-2 1) e mais nada; contraste do turquesa sobre branco 2,57 → 2,80; mancha interna do fundo turquesa 1,03 e ΔE76 9,48 contra #11B0A0. As peças impressas já aprovadas que embutem a cor antiga não mudam (evidência de gate).A leva 16 no computador novo (MANIFESTO §282).
texto inteiro da versão
A leva 16 no computador novo (MANIFESTO §282). "estarte de maneira orquestrada as pendencias do ds que nao dependem de mim": a base ajustada ao PC novo (dependências, Chrome 154: PDF do deck e baseline de contraste remedidos); as três folhas antigas (72 de 72 abertas) regeradas com dados atuais e publicadas em links novos; MR-B = D (vertical alinhada à horizontal, marca v5.55, 9 peças e a tela-autenticacao regeneradas); dois agentes Sonnet em série: o conferidor imprime no tamanho declarado (PASS 130→146, FAIL 5→1) e o rito ficou portável com pré-voo. Fecham MR-P25, CP-P43–P46, PR-P75–P79, HV-P17, GR-P27; nascem CP-P47–P50, PR-P80, PR-P81.
2026-09-30
GR-P25, GR-P26, GR-P19 e MR-A — quatro respostas dele aplicadas ao pé da letra (leva 15).
texto inteiro da versão
GR-P25, GR-P26, GR-P19 e MR-A — quatro respostas dele aplicadas ao pé da letra (leva 15). Respostas dele, verbatim (coladas em 2026-09-30, ~00:20Z): "GR-P25: C · GR-P26: A · TK-P9: C · PR-P71: regra C · automação R" e "GR-P19: C1 · MR-A: A · MR-C: B" (a MR-B e a MR-C tocam arquivo e token: ver seed-tokens.md §9 e o MANIFESTO). (a) §7.4: a linha do WhatsApp passa de 62/396 para 77/490 (a serra que a capa aprovada tem) e nascem as linhas do Facebook (99/630), LinkedIn (40/256), X (60/380, faixa exibida) e YouTube (66/423, faixa exibida), todas com peca: capa-rede na guarda-grafismo.mjs (CANON_TETOS); a GR1-c das 10 capas passa de 0 PASS · 2 FAIL · 8 [n/a] para 10 PASS · 0 FAIL · 0 [n/a] (medido em 2026-09-30) e a prova prova-teto-capas-rede.py (16 de 16) prende as cinco linhas. Nenhuma peça muda. (b) §7.4-b: o peso da linha da montanha do topo é proporcional à largura (o que o gerador já fazia), preso pelo teste-montanha-peso-proporcional.py (6 de 6). Nenhum desenho muda. (c) §5.1: #00ACAC registrado como cor própria do arquivo oficial (exceção, só vale dentro dele). Nenhum logo muda. Alternativas que ele não escolheu ficam nas folhas de 2026-09-29 (09-pesquisa/2026-09-29-folha-canon/ e 09-pesquisa/2026-09-29-gate-montanha-paleta/).O "sim" do 642e966f e a leva 15 (MANIFESTO §281).
texto inteiro da versão
O "sim" do
642e966f e a leva 15 (MANIFESTO §281). Publicado 23:18Z (produção zero FAIL). As respostas às duas folhas aplicadas (GR-P19 C1, GR-P25 C, GR-P26 A, TK-P9 C, PR-P71 C+R, MR-A A, MR-C B; MR-B D espera a imagem da vertical). Três agentes Sonnet em série: conferidor sem as 7 reprovações sem causa, JetBrains Mono em woff2 nas 16 peças (render idêntico), duas provas do CP-5 e a barra-gramatica com NÃO MEDI no rito. Nascem CP-P43–P46, GR-P27, PR-P75–P77, HV-P17.TK-P9 = C e MR-C = B (leva 15) — nasce --seed-preto e o letterSpacing.normal ganha descrição.
texto inteiro da versão
TK-P9 = C e MR-C = B (leva 15) — nasce --seed-preto e o letterSpacing.normal ganha descrição. Respostas dele, verbatim (coladas em 2026-09-30, ~00:20Z): "TK-P9: C" e "MR-C: B". (a) color.preto #000000 no JSON e --seed-preto no CSS (§2.1-b): o preto da impressão P&B ganha token; os arquivos monocromáticos oficiais de 03-assets/ trocam #000001 → #000000 e #FEFEFE → #FFFFFF (conferido por render: diferença de pixel medida no RELATORIO da leva 15). (b) font.letterSpacing.normal ganha a descrição "0 px = o espaçamento padrão; sem variável no CSS de propósito" e a exceção SO_NO_JSON da paridade-tokens.py aponta para ela (a exceção continua 1 declarada). Versão dos gêmeos: v1.30 → v1.35 (o número que segue a 1.34 deste arquivo, para não repetir o caso de dois donos do 1.30 da linha 1.32); o selo "seed-tokens.css v1.30" dos HTML gerados passa a v1.35 pelos geradores. Adição pura: nenhum valor anterior muda.2026-09-29
MR-P24 — o §3, o §11 e o §15 citam de volta o seed-tokens.md §3 (só remissão, nenhuma regra muda).
texto inteiro da versão
MR-P24 — o §3, o §11 e o §15 citam de volta o seed-tokens.md §3 (só remissão, nenhuma regra muda). A PR-P58 (a CI-11 deixou de ler a subseção da própria marca, "§3.5", "§3.6" e "§3.1", como citação do tokens) revelou 4 dívidas de ponteiro: o §3 declarava "cor" e era dona de "cor" sem citar o seed-tokens.md §3 (dois sentidos), o §11 declarava "tema" e o §15 declarava "cor" sem citá-lo. Cada uma ganhou uma frase de remissão ao §3 do tokens (os semânticos de cor, claro e escuro): no §3.1 depois de "Valores e método", no §11 na linha "Fonte executável" e no §15 no item 3. A base da CI-11 passa de 473 a 469.O "sim" do 1932724d e a leva 14 (MANIFESTO §280).
texto inteiro da versão
O "sim" do
1932724d e a leva 14 (MANIFESTO §280). Publicado 18:48Z (produção zero FAIL). Dois agentes Sonnet em série: o CP-5 do conferidor reconhece a forma do logo (CP-P35, CP-P36 fecham; CP-P37 era defeito da cobaia) e a folha das quatro decisões de canon (GR-P25, GR-P26, TK-P9, PR-P71) vai a ele. Nascem CP-P39–CP-P42, PR-P73, PR-P74.A leva 13 (MANIFESTO §279).
texto inteiro da versão
A leva 13 (MANIFESTO §279). "pode abrir o proximo grupo, nao precisa ser em paralelo, foco em economizar tokens": um agente, quatro pendências em série. Fecham PR-P70 (captura-mr6 congelado), PR-P72 (gen-zero-formatos no geradores-checar, 68 de 68), CP-P34 (os logos casam; a cobaia achou três desvios do CP-5) e VT-P13 (página da peça +0 B). Nascem CP-P35–CP-P38.
O "sim, publicar" do 0c273c6f e a leva 12 (MANIFESTO §278).
texto inteiro da versão
O "sim, publicar" do
0c273c6f e a leva 12 (MANIFESTO §278). Publicado 10:51Z (produção zero FAIL). As respostas dele às três decisões do §277.7: GR-P19 e MR-P25 viram folha visual (publicada, 4 respostas); a PR-P67 foi delegada — 5 geradores congelados, o gen-zero-formatos migra. Quatro agentes em série fecham 18 pendências (PR-P65–P69, PB-P17, MR-P24, CP-P31–P33, TK-P8, GR-P20–P24, HV-P15, HV-P16). Nascem GR-P25, GR-P26, TK-P9, PR-P72, CP-P34, VT-P13.O "sim" que pôs o 1744ea56 no ar e a leva 11 (MANIFESTO §277).
texto inteiro da versão
O "sim" que pôs o
1744ea56 no ar e a leva 11 (MANIFESTO §277). Publicado 23:46Z (1.696 de 1.696; produção zero FAIL). Verbatim "pode abrir": quatro agentes em série fecham 18 pendências da fila (PR-P58–PR-P63, TK-P7, PB-P15, PB-P16, HV-P14, CP-P27–CP-P30, GR-P15–GR-P18) — a guarda de grafismo deixa de sair instável, o conferidor lê a declaração tela × físico, nove geradores param de esvaziar o destino. Nascem PR-P65–PR-P71, TK-P8, MR-P24, MR-P25, HV-P15, HV-P16, PB-P17, CP-P31–CP-P33, GR-P19–GR-P24; três vão a ele.PB-P17 — o §7 aponta a spec do deck no formato e no fundo.
texto inteiro da versão
PB-P17 — o §7 aponta a spec do deck no formato e no fundo. O §7 (biblioteca de slide de maio/2026) ainda mandava o fundo brand-deep (#006C62) e ensinava o deck em python-pptx, contra o marca-seed.md §13 (turquesa-800 na capa escura, na seção e no encerramento) e contra o D-FORMATO A do MANIFESTO §276 (o template é o gen-deck.py, HTML → PDF, sem PPTX). Uma nota no topo do §7 e uma linha nos layouts 1 e 10 apontam a spec; o código e as constantes não mudam (a prática aponta a marca, não a reescreve: regra de precedência). Revisão do §7: 2026-09-29.PB-P15 e PB-P16 — a tabela de logo e o panorama apontam a spec.
texto inteiro da versão
PB-P15 e PB-P16 — a tabela de logo e o panorama apontam a spec. (a) A tabela de logo do §7 mandava o logo-horizontal-fundo-turquesa.svg na capa e no agradecimento; o deck usa o logo-horizontal-mono-negativo.svg sobre o turquesa-800 (capa escura e encerramento) e o logo-horizontal-principal.svg na capa branca (marca-seed.md §12.32 e §13, gen-deck.py). A tabela e a linha "Logo" do layout 1 passam a dizer isso, e uma nota aponta a spec. (b) O §3.4 ensinava o panorama como "1080 × N para N cartões quadrados"; para a faixa contínua de grafismo do carrossel de feed isso repete o mesmo trecho em todo slide em 1:1 — a nota aponta o §12.33. A prática aponta a marca, não a reescreve (regra de precedência). Revisão das §3 e §7: 2026-09-29.2026-09-28
LC-04 fecha — o carrossel de feed 4:5 vira peça estável (§12.33).
texto inteiro da versão
LC-04 fecha — o carrossel de feed 4:5 vira peça estável (§12.33). Veredito dele no gate, verbatim: LC4-1: A · LC4-2: A · LC4-3: A · LC4-4: A · LC4-5: A · LC4-6: confirmo todos ("segue respostas, pode abrir todo o grupo, pode abrir 1 a 1 para economizar token."). Nasce o §12.33 (gerador gen-carrossel.py, 5 slides de 1080 × 1350 em 07-pecas/carrossel/, contador 01 / 05, "Arraste" só na capa, todos claros, chamada final com o 0800, título em <h1>, texto alternativo de entrega). §7.4 ganha a linha post / carrossel 4:5 = 107px de 1350 (7,93 %), espelhada no CANON_TETOS da guarda-grafismo.mjs com fixture 6 de 6. §7.6 ganha a faixa contínua do carrossel (UMA faixa svg_divisor(n × 1080) cortada em janelas contíguas pela nova svg_janela do gen-detalhe.py), com a cláusula GE-6 da guarda-grafismo.py (fecha a GR-P14: janela deslocada ou repetida reprova).LC-02 fecha — o deck 16:9 vira peça estável (§12.32).
texto inteiro da versão
LC-02 fecha — o deck 16:9 vira peça estável (§12.32). Veredito dele no gate, verbatim: D-FORMATO: A · D-GRAFISMO: G1 · D-TETO-16x9: T1 · D-ESCALA: K25 · D-SECAO: S2 · D-PADROES: N1 ("segue respostas, pode abrir todo o grupo, pode abrir 1 a 1 para economizar token."). Nasce o §12.32 (gerador gen-deck.py, seis slides e o PDF de entrega em 07-pecas/deck/, K = 2,5 sobre a §4.7, serra de 85 px só na abertura, seção e encerramento, numeração "03", notas do apresentador no PDF). §7.4 ganha a linha slide 16:9 = 85px de 1080 (7,9 %), a regra da linha 1 — não foi a recomendada (152px); a guarda-grafismo.mjs cobra a linha só de peça com <meta name="peca" content="deck">, com fixture 5 de 5. §13: a seção passa a turquesa-800 com número amarelo (sai "turquesa-400 ou brand-deep", que media 2,71:1) e a capa escura passa a turquesa-800 (sai o surface-brand-deep, onde o plano de trás da serra some). PR-P64 (a prova do texto sobre o rodapé) e CP-P28 (um <h1> por página) resolvidos no gerador.O gate das peças respondido (MANIFESTO §276).
texto inteiro da versão
O gate das peças respondido (MANIFESTO §276). Verbatim "segue respostas, pode abrir todo o grupo, pode abrir 1 a 1 para economizar token."
LC-02 fecha: deck 16:9 estável (marca-seed.md §12.32, v5.51; gen-deck.py, PDF com a fonte embutida; teto 16:9 = 85 px, o T1 dele). LC-04 fecha: carrossel 4:5 estável (§12.33, v5.52; gen-carrossel.py, faixa contínua pela svg_janela do gen-detalhe.py, GE-6 na guarda). Fecham também PR-P64, PB-P14, GR-P14 e SK-P10; nascem CP-P30, GR-P18, PB-P15, PB-P16. Quatro provas novas no rito.O relato de acesso (MANIFESTO §275).
texto inteiro da versão
O relato de acesso (MANIFESTO §275). Com o domínio liberado, a nuvem do Claude segue sem chegar ao site (20 de 20 pontos do mundo respondem; nenhum pedido da nuvem nos registros). A página
.md de cada peça passa a trazer estado, data, versão e o texto da spec; a skill explica o 403/tempo esgotado. Correção: a skill do §274 é a 2026.09.28+442d48cf. Nasce SK-P10."sim" e SK-P9 (MANIFESTO §274).
texto inteiro da versão
"sim" e SK-P9 (MANIFESTO §274).
efd13823 publicado. Uma sessão do Cowork não achava o timbrado: a rede dela não chega ao site (nenhum pedido nos registros) e o pacote da skill nunca levou peça, embora prometesse trabalho sem rede. Veredito: "apenas corrija a skill sem prometer as peças offline" — skill 2026.09.28+418d225b."execute os 3 primeiros" (MANIFESTO §273).
texto inteiro da versão
"execute os 3 primeiros" (MANIFESTO §273). Publicado o
ffaf9b10 (1.653 de 1.653 conferidos; produção zero FAIL). CP-P26 fecha (1.377 pastas do conferidor, 3,18 GB). GR-P13 fecha (a peça de gate das peças largas regerada com as fontes do repositório; --checar no rito). As specs de peça LC-02 (deck) e LC-04 (carrossel) abrem pelo pedido dele e chegam ao material de gate (6 + 6 perguntas). Triagem dos pedidos PC-2026-0044/0045 para a folha versão 3. Nascem GR-P14–P17, CP-P28, CP-P29, MR-P23, PB-P14, PR-P64.PB-P14 — a seção sem logo, nos dois lugares.
texto inteiro da versão
PB-P14 — a seção sem logo, nos dois lugares. A tabela de logo do §7 dizia "Slide de seção: logo vertical" e o §6.3.5 dizia "sem logotipo e sem rodapé"; vale o §6.3.5, que é o que o template do deck faz (marca-seed.md §12.32, LC-02, veredito "D-SECAO: S2" de 2026-09-28). O §6.3.5 passa a dizer o tom (turquesa-800) e aponta o template. Revisão das §6 e §7: 2026-09-28.2026-09-27
o comando de produção do §82.8 deixa de mandar gravar numa pasta producao/ que o repositório não tem (REV-P29 (d)).
texto inteiro da versão
o comando de produção do §82.8 deixa de mandar gravar numa pasta
producao/ que o repositório não tem (REV-P29 (d)). O gen-z3-largos.py grava onde a variável DEST_LARGOS mandar, relativo à pasta de onde roda; o padrão do código é render-audit/gate-z3/largos (a pasta do GATE), e /render-audit/ está no .gitignore desde a REV-P14. A pasta de produção migrou na fundação do repositório para 07-pecas/producao-cartao-90x50/ e foi removida de propósito em 2026-08-25 (commit 82bf6a9f: as peças de produção do cartão da era anterior); rodado da raiz, o comando antigo criaria producao/ fora do .gitignore. O destino passa a render-audit/producao/cartao-90x50: fora do git e fora da pasta do gate, a separação que o próprio §82.8 exige. Não é 07-pecas/cartao-90x50/: aquela pasta é a peça de gate do gen-cartao.py, e o gen-z3-largos.py APAGA a pasta de destino antes de escrever (medido em 2026-09-27 numa pasta descartável). O ### Histórico da seção não se toca.os três comandos que ainda chamavam a pasta da era anterior (REV-P27 (b), MANIFESTO §269.4): o §70, o §77 e o §82 passam a mandar rodar o instrumento no caminho de hoje.
texto inteiro da versão
os três comandos que ainda chamavam a pasta da era anterior (
REV-P27 (b), MANIFESTO §269.4): o §70, o §77 e o §82 passam a mandar rodar o instrumento no caminho de hoje. A v1.76 trocou as 57 ocorrências de `validacao/…` entre crases; sobraram 8 sem crase à esquerda, dentro de comandos (node validacao/…, python3 validacao/…), que a busca daquela leva não alcançava. Três estão no corpo e passam ao caminho vivo, conferido por git ls-files em 2026-09-27: §70 06-validacao/guardas/guarda-centro-alvo.mjs, §77 06-validacao/suites/prova-47o-defeito.mjs, §82 06-validacao/geradores/gen-z3-largos.py. O resultado impresso abaixo do comando do §70 (23 PASS · 0 FAIL · 28 [n/a]) é a medição daquela data e fica como está. As outras 5 estão no ### Histórico da seção do §77 (os comandos e placares da GR1 de 2026-08-21) e não se tocam: são registro.as pontes que a régua passou a enxergar, os caminhos da era anterior e o grupo da âncora no endereço (REV-P23, REV-P24 e SH-P40, MANIFESTO §268.4): quatro seções passam a citar a seção com que têm relação real, 57…
texto inteiro da versão
as pontes que a régua passou a enxergar, os caminhos da era anterior e o grupo da âncora no endereço (
REV-P23, REV-P24 e SH-P40, MANIFESTO §268.4): quatro seções passam a citar a seção com que têm relação real, 57 caminhos validacao/… do corpo apontam para o arquivo de hoje, o segundo aviso do §76.7 ganha nota de supersede, e o §46.7 diz como o grupo do subitem atravessa uma navegação. (1) REV-P23: quando a régua CI-11 da guarda-camada-ia.py passou a ler de qual documento é cada "§N" (PR-P43), apareceram pontes recíprocas que um "§N" de outro documento escondia. Cada uma foi lida pelo conteúdo, e as seis deste arquivo são reais; nenhuma declaração de conceito estava errada. O §0 cita o form-field (§2.9: nome acessível e ordem de anúncio de erro e ajuda); o §46 cita a busca-filtro do §4 (no SH9: filtrar o dado da tela é outra busca) e o contrato por arquétipo do seed-composicao.md §3 (no §46.4); o §64 cita a marca §11 (o escuro como cidadão de primeira classe); o §65 cita a admissão de cor de entidade da marca-seed.md §3.6-b e os tokens --seed-entity-* do seed-tokens.md §3. (2) REV-P24: das 83 ocorrências de `validacao/…` (74 linhas), 62 estavam no corpo das seções: 57 passam ao caminho vivo (todas existem hoje, conferidas por git ls-files), 1 ganha "(a pasta de então; hoje 06-validacao/)" porque é uma contagem daquela data (§70), e 4 ficam como estão porque falam do caminho antigo de propósito (a mudança de pasta do §48, o aviso de 2026-08-21 do §76.7, a nota de remedição do §77.6). As 10 do changelog deste cabeçalho e as 11 dos ### Histórico da seção não se tocam: são registro. O §76.7 ganha a nota de supersede do segundo aviso ("A GR1-c REPROVA QUATRO PEÇAS APROVADAS"): o §78 mudou o teto no canon, e as peças largas medem 15 · 0 · 0 (remedido em 2026-09-27, 17:34Z). A nota do §77.6 de que a folha, o monta-folha-gr1.py e o LEIA-ME.md da GR1 não estão no repositório já existia desde a v1.75. (3) SH-P40 (§46.7, contrato do tipo painel): quando ancorar num subitem exige navegar para outra tela, o produto leva o grupo no endereço e a tela de destino abre a coluna só com aquele submenu e o "voltar à área"; dentro da mesma tela, o evento seed-rail-ancora basta. É decisão da sessão, exposta a veto dele; o resto do SH22 não muda.as notas de canon da revisão (REV-P17 a REV-P22, MANIFESTO §267.4): o verbatim que é FONTE de regra volta ao corpo, perto da regra; duas contradições ganham nota de supersede datada, sem apagar a história; e os placares…
texto inteiro da versão
as notas de canon da revisão (REV-P17 a REV-P22, MANIFESTO §267.4): o verbatim que é FONTE de regra volta ao corpo, perto da regra; duas contradições ganham nota de supersede datada, sem apagar a história; e os placares de referência do corpo são remedidos. (1) REV-P18: cinco verbatins que a F12.4 (2026-09-19) tinha levado ao Histórico e que são a fonte de uma regra ou de um estado voltam ao lugar de onde saíram, byte a byte como estavam antes dela — o do §79.1 ("acho que deixar 1:1 nao seria o ideial…"), o "aprovo" que é a fonte do
estável do §46, a confirmação da tabela SH17 (§46.4), o veredito V-LC11 do SH18 (§46.5) e o "troca a bolinha" da CC-P8 (§65.11). O critério é o do §267 (o F1-47d do §47): fala dele entre aspas, que é decisão (não queixa nem motivo), de que a regra do corpo deriva, e que o corpo não traz em outro lugar. Dos 113 ponteiros "(decisão registrada — ver Histórico da seção)" medidos, os outros 108 ficam: são pesquisa, contexto, motivo ou verbatim que o corpo já cita; os casos de dúvida foram à sessão. (2) REV-P17: o §72 passa a citar o §46 no corpo (a tela estreita é contrato do SH12), e a nota "Estrutura da Fase 3" vai ao Histórico do §72 (3.164 bytes). (3) REV-P19: nota de supersede no §85.2 — o véu por box-shadow inset cede ao §71.6, com a prova por git log -S. (4) REV-P20: nota de supersede no §76.7 — a guarda existe desde o §77. (5) REV-P21: remedidos em 2026-09-27 os placares do corpo do §66 (30), do §67 (23) e do §68 (25), que os títulos já diziam, e os do §77.6 com os caminhos de hoje; os números antigos foram ao Histórico de cada seção. (6) REV-P22: o título do §65.13 volta a uma linha só. (7) Sobre a entrada rotulada "v1.73" logo abaixo da v1.74: ela não é uma versão — é a portadora do título antigo, movida em 2026-09-26 pela REV-P7; a v1.73 é de 2026-09-25 (commit 2185e81f, SH-P24).REV-P23 — o §3 passa a citar o §7 de volta (§3.2).
texto inteiro da versão
REV-P23 — o §3 passa a citar o §7 de volta (§3.2). Contexto para quem lê sem ter visto: a régua CI-11 da guarda-camada-ia.py exige que a seção dona de um conceito cite cada seção que o declara, e o §7 (grafismo) declara "cor" porque o §7.5 decide a cor das linhas. Até a leva 4 um "§7" de outro documento no §3 (o seed-composicao.md §7) passava por essa citação; quando a régua passou a ler de qual documento é cada "§N" (PR-P43, MANIFESTO §268.3), a ponte que faltava apareceu. A relação é real, e o §3.2 ganhou uma frase que a diz: o grafismo só desenha com degraus da rampa turquesa, e o amarelo não entra nas linhas. Nenhuma regra muda.A leva 8 (MANIFESTO §272) — as oito pendências nascidas na leva 7 fecham.
texto inteiro da versão
A leva 8 (MANIFESTO §272) — as oito pendências nascidas na leva 7 fecham.
PR-P54 (o gen-z3-largos não apaga mais o destino; teste no rito), PR-P55 (item morto na base da eol-misto reprova), PR-P56 (a guarda de versões mede o cabeçalho do tokens, VL-7), PR-P57 (CI-4: disco e git; a raiz sem "/"), TK-P6 (os 39 tokens do retrofit v1.14 documentados; tokens v1.34), VT-P10–P12 (barra em atributo, renderizador sem estado global, "byte a byte" só da fatia). A folha de triagem vai à versão 2 com os pedidos PC-2026-0041 a 0043 (19 respostas). Nascem PR-P58–P63, TK-P7, GR-P13, CP-P27. Nada publicado.A leva 7 (MANIFESTO §271) — as pendências que não dependiam dele.
texto inteiro da versão
A leva 7 (MANIFESTO §271) — as pendências que não dependiam dele. Quatro agentes Opus em paralelo:
PR-P52 (a guarda de versões mede o práticas, VL-6) e PR-P34; PR-P53/PR-P31 (as cobaias MH1 do sobrevoo voltam a regenerar e entram no rito); REV-P29 (composição §9 sem conceito, CI-11 471 → 469; o §9 do tokens com as versões 1.13–1.20 reconstituídas; §82 com o caminho vivo); VT-P9 (a barra invertida do veredito de 2026-08-26 volta à vitrine; régua VT-17 e prova no rito) e VT-P6 (fecha por medição) — componentes v1.78, tokens v1.33. Nascem PR-P54–P57, TK-P6, VT-P10–P12. Nada publicado."sim para os 2" e a leva 6 (MANIFESTO §270).
texto inteiro da versão
"sim para os 2" e a leva 6 (MANIFESTO §270). Publicado
750a81ca (1653 de 1653; produção zero FAIL). PC-P3 fecha: a triagem lê e grava pelo papel ds_triagem (6 de 6: private.leads, update de texto e delete negados). Leva 6: REV-P26–P28 (CI-11 473 → 471), PR-P51 (o defeito estava no checar_bloco), GR-P12, CP-P24 (o conferidor não deixa mais pasta temporária; a prova do caso S no rito) e CP-P25 (cobaia do rail ILUSTRATIVO; cobaias 18 de 18) — componentes v1.77, tokens v1.32, práticas v1.8. Folha de triagem dos 30 pedidos ao Rafael (16 respostas; LC-20 a LC-33 propostas). Nascem PC-P4, PR-P52/P53, CP-P26, REV-P29.A leva 4 no ar e a leva 5 (MANIFESTO §269).
texto inteiro da versão
A leva 4 no ar e a leva 5 (MANIFESTO §269). Publicado
23815189 (1653 de 1653 conferidos; produção zero FAIL; .sig 200; VT-P8 sem a porta 8080). Leva 5, cinco agentes: REV-P23 (10 dívidas da CI-11 pagas), REV-P24, SH-P40 (grupo da âncora no endereço, exposto a veto) — componentes v1.76, marca v5.50, composição v2.5, tokens v1.31; CP-P21/P22 e CP-P23 (o CP-13 volta a reprovar tela local sem casca; cobaias 17 de 17); PR-P48 (opção desconhecida não grava), PR-P49 (render-shell no relógio da página), PR-P50; GR-P11. Folha do estado das fatias ao Rafael (14 respostas). Base da CI-11 485 → 473, 0 nova. Nascem CP-P24/P25, PR-P51, GR-P12, REV-P26–P28.Leva 4 (MANIFESTO §268): seis agentes em paralelo, 16 pendências fecham.
texto inteiro da versão
Leva 4 (MANIFESTO §268): seis agentes em paralelo, 16 pendências fecham. A CI-11 atribui cada "§N" ao seu documento (
PR-P43) e revela 10 dívidas de ponteiro recíproco (REV-P23); regravar base exige --motivo (PR-P45); VL-5 confere a versão do componentes (PR-P46); gen-indice --checar, mensagens do --checar e SK-6 por árvore (PR-P42/P44/P47); REV-P17–P22 e o 6a derivável (estado herdado do cabeçalho, CI-18) — componentes v1.75; SH-P37 e SH-P39 (rail: o → não abre prévia do ativo); provas de PR-P40/P41/CP-P20 prontas, entrada no rito na folha. Folha da leva 4 publicada (40 respostas) e o "sim" dele para publicar. Nascem SH-P40–P42, CT-P21/P22, CP-P21/P22, PR-P48–P50, REV-P23–P25, GR-P11.REV-P28 — a linha de versão do cabeçalho volta a dizer a versão vigente.
texto inteiro da versão
REV-P28 — a linha de versão do cabeçalho volta a dizer a versão vigente. Contexto para quem lê sem ter visto: a terceira linha deste arquivo dizia "Versão: v1.3 · Data: 2026-09-08" enquanto o H1 e este registro já estavam em 1.7 de 2026-09-15 — quatro versões de atraso (1.4 a 1.7 subiram o H1 e escreveram a linha aqui, e ninguém tocou a linha 3; medido pelo git log do arquivo em 2026-09-27: ela acompanhou o H1 até a 1.3, commit 1bfb9e04, e parou a partir da 1.4, commit 40566720). Achado da folha 2 da leva 5 (2026-09-27). A linha 3 passa a v1.8 · 2026-09-27, igual ao H1 e ao topo deste registro; as entradas antigas não se tocam. Nenhuma regra muda. A guarda-versao-log.py (contrato VL, versão × registro) não mede este arquivo: a linha de versão fica no meio da linha 3 e a versão deste registro vem em negrito, duas formas que os três medidores dela não leem (medido em 2026-09-27: 3 de 3 saem NÃO MEDI) — pôr o arquivo na guarda é forma nova, proposta à parte.TK-P6 (MANIFESTO §271.8) — o corpo passa a documentar os tokens do retrofit da v1.14 (RV1–RV10).
texto inteiro da versão
TK-P6 (MANIFESTO §271.8) — o corpo passa a documentar os tokens do retrofit da v1.14 (RV1–RV10). Contexto para quem lê sem ter visto: desde a v1.14 (2026-08-15) os gêmeos emitem 39 custom properties que o corpo deste arquivo não documentava — medido em 2026-09-27 (script de placar da leva 8, agente C): 0 de 39 nomes no corpo (§1 a §6), só no §9. São 24 variáveis dos seis papéis tipográficos (--seed-txt-titulo-tela, -titulo-secao, -corpo, -corpo-denso, -rotulo, -micro, cada um com -size, -weight, -lh e -ls; no JSON, seis compostos em semantic.typography-role), 7 passos da escala de raio (--seed-radius-1 a --seed-radius-8, sem o 7), 2 meios-passos de espaço (--seed-sp-1-5, --seed-sp-2-5) e 6 alturas de controle (--seed-control-sm/md/lg e o preset -compacto); os quatro apelidos --seed-radius-sm/md/lg/xl passaram a apontar para os numéricos no CSS. O §2.6 ainda dizia só "radius sm 4 · md 8 · lg 12 · xl 16" (achado 4 do relatório C da leva 7, 09-pesquisa/2026-09-27-leva7/relatorio-c.md). Agora os papéis estão no §2.5 e o resto no §2.6, com o valor dos gêmeos e o papel que os gêmeos escrevem (comentários v1.14 do CSS, $description do JSON); onde nenhuma fonte escreve papel (--seed-radius-1, -3 e -5; o sm e o lg da altura de controle), o texto diz "não registrado" em vez de deduzir. Placar depois: 39 de 39. A correspondência de cada grupo com um item RV-n não está escrita em nenhuma fonte (só RV1/RV3 nos papéis, e a razão do RV3 na paridade-tokens.py), e o texto novo diz isso. Nenhum valor muda e nenhum token nasce ou morre: os gêmeos seguem em v1.30. A entrada 1.14 abaixo e as demais ficam intactas.REV-P29 (b) e (c) — as oito versões que faltavam nesta tabela (1.13 a 1.20) entram reconstituídas, e a linha "Editado" do cabeçalho volta a dizer a versão viva.
texto inteiro da versão
REV-P29 (b) e (c) — as oito versões que faltavam nesta tabela (1.13 a 1.20) entram reconstituídas, e a linha "Editado" do cabeçalho volta a dizer a versão viva. Contexto para quem lê sem ter visto: esta tabela pulava da 1.21 para a 1.12 — 0 de 8 linhas para as versões 1.13 a 1.20, que existem no corpo (§2.5, §3, §5-b a §5-g), nos gêmeos ($description do JSON, comentários do CSS) e no MANIFESTO. A lacuna já estava no primeiro commit deste repositório (fbba442e, 2026-08-22), que nasceu com este arquivo em v1.20 e a tabela parada na 1.12: as oito versões são da era anterior ao repositório. A entrada 1.21 já registrava a lacuna ("Nota de lacuna desta tabela") e deixou a restauração para depois, porque aquela edição era de emissão de token; esta é a restauração. O git log -S de dois marcadores de cada versão (16 no md e nos gêmeos) devolve fbba442e como o commit que os introduziu em 16 de 16 — o commit de origem de cada versão NÃO está neste git (não conferido). Cada linha nova diz de onde saiu; as entradas antigas ficam intactas, no mesmo modo das entradas retroativas 1.7 a 1.10 escritas na v1.11. A linha "Editado:" do cabeçalho estava parada na v1.22 com o H1 em v1.32 (a mesma classe da errata de cabeçalho de 2026-08-20, no topo deste arquivo) e passa à v1.33; o texto anterior dela fica, depois de "Anterior:". Nenhum token muda: os gêmeos seed-tokens.json e seed-tokens.css seguem em v1.30, como a 1.32 registra.REV-P27 (a) — o registro que faltava: a v1.30 dos gêmeos é a TK-P2, e o número 1.30 tem dois donos.
texto inteiro da versão
REV-P27 (a) — o registro que faltava: a v1.30 dos gêmeos é a TK-P2, e o número 1.30 tem dois donos. Contexto para quem lê sem ter visto: em 2026-09-16 (commit c3c338a2, MANIFESTO §232) a TK-P2 subiu os gêmeos seed-tokens.css e seed-tokens.json para v1.30 — (a) remove action-secondary-text (turquesa-700, #006C62 claro / #66D1C2 escuro), duplicata do button-secondary-text (turquesa-800) que o §1.6 do seed-componentes.md já resolve, com os dois consumidores diretos migrados no mesmo commit (06-validacao/templates/painel-template.html e 06-validacao/geradores/gen-art-diario.py); (b) a nota do --seed-fw-medium no JSON deixa de dizer "uso exclusivo da mono" (a Montserrat 500 é servida e usada). Aquele commit não tocou este arquivo: o H1 seguiu em v1.29 e esta tabela não ganhou linha. Em 2026-09-19 (commit 8e9ebff8, F12.4, MANIFESTO §234) este arquivo subiu para 1.30 sem registrar a primeira — por isso a linha 1.30 abaixo é a F12.4, e a v1.30 do cabeçalho do CSS é a TK-P2. Medido pelo git log -S em 2026-09-27 (TK-P2 e Design Tokens v1.30 em 02-tokens/; a linha 1.30 desta tabela). As duas entradas antigas não se reescrevem: esta linha é o registro. Nenhum valor muda: os gêmeos seguem em v1.30 — esta versão é só do texto.REV-P23 (MANIFESTO §268.3) — o §3 passa a citar de volta o §2 e a marca §11.
texto inteiro da versão
REV-P23 (MANIFESTO §268.3) — o §3 passa a citar de volta o §2 e a marca §11. Contexto para quem lê sem ter visto: a régua CI-11 da guarda-camada-ia.py exige que a seção dona de um conceito cite cada seção que o declara. O §3 é dono de "cor" e de "tema"; o §2 declara "cor" (as rampas) e o §11 do marca-seed.md declara "tema" (o escuro como cidadão de primeira classe). Até a leva 4 um "§2" e um "§11" de outros documentos no §3 passavam por essas citações; quando a régua passou a ler de qual documento é cada "§N" (PR-P43), as duas pontes que faltavam apareceram. O §3 ganhou uma frase que diz as duas relações; a frase "em regra" é medida: 142 de 151 valores claros de papel do seed-tokens.json são degraus das rampas (2026-09-27). Nenhum valor muda: os gêmeos seed-tokens.json e seed-tokens.css seguem em v1.30 — esta versão é só do texto.2026-09-26
a REV-P7 aplicada (MANIFESTO §247 e seguintes, modo DENTRO): o título volta a ser só o título, e a história solta de cada seção vai para o ### Histórico da seção da PRÓPRIA seção; a regra SH22 (tipos de destino do rail)…
texto inteiro da versão
a
REV-P7 aplicada (MANIFESTO §247 e seguintes, modo DENTRO): o título volta a ser só o título, e a história solta de cada seção vai para o ### Histórico da seção da PRÓPRIA seção; a regra SH22 (tipos de destino do rail) sobe ao §46. (1) Título curto: a linha de 63.499 bytes que o H1 carregava desde a v1.09 está inteira na entrada logo abaixo, byte a byte; a versão nova se registra como entrada deste changelog, a mais nova em cima. (2) Movimento DENTRO: 77 blocos de história (39.167 bytes) saíram do corpo e foram, sem mudar um byte, para o fim do Histórico da mesma seção — 5 no §45–§47, 33 no §48–§65 e 39 no §66–§93 (em 21 das 98 seções H2); nenhum título numerado muda, e onde uma subseção ficou sem corpo entra um ponteiro de uma linha. Ficaram no corpo, de propósito, o parágrafo que mistura regra e história, o verbatim que é fonte de regra ou de estado (o "aprovo" do estável do §47 incluído) e as 14 lições da rodada 3 do §48; a frase "no escuro, elevação é LUZ, não sombra" segue no texto vigente do §48 (4b, supersede do §250.2). (3) SH22 (§46.7): o destino do rail declara o tipo painel, balao ou direto — prévia no sobrevoo, coluna ancorada no clique, balão e destino direto; SH3, SH12, SH14 e SH19 ganham uma frase cada. Veredito dele, verbatim (MANIFESTO §264.1): "ficou otimo" e "Sim, tudo como aplicado (Recommended)" (V-SH34.1 a .6 = a). (4) Registro de medida, sem regra nova: §49.5 ganha o piso de 64 px do rótulo que cede (PD8) e o §49.1/PD7 diz onde a container query peca é declarada (agente DET, §264.4); o §35.2 registra o sobrevoo provisório do menu sobre surface-overlay (HV-P12, §262); o título do §46 ganha as contagens remedidas das suítes da casca.REV-P6 — peça impressa e PDF embutem a Montserrat COMPLETA em woff2 (§4.5).
texto inteiro da versão
REV-P6 — peça impressa e PDF embutem a Montserrat COMPLETA em woff2 (§4.5). Veredito dele na folha da REV-P1, v2 (MANIFESTO §249.2 e §250), verbatim: "3 fonte das peças: woff2". A letra da regra passa de "TTF completo" para "fonte completa, embutida em woff2", e o motivo (cobertura) fica: o woff2 completo tem os mesmos 2.747 glifos e 1.312 pontos de código do TTF. Nasce 03-assets/fontes/montserrat/woff2-completa/ (300 a 700), gerado pelo gen-subset-fontes.py com --checar. As 67 peças que embutiam o TTF: 135,6 MB → 39,4 MB; PNG com o MESMO MD5 em 67 de 67; PDF com as mesmas páginas, as mesmas fontes e 0 px a 150 dpi em 67 de 67. §4.1 (Light em peça impressa) acompanha a letra.REV-P4 aplicada (MANIFESTO §254) — nasce a guarda VL: o cabeçalho do roadmap é a primeira linha do Log.
texto inteiro da versão
REV-P4 aplicada (MANIFESTO §254) — nasce a guarda VL: o cabeçalho do roadmap é a primeira linha do Log. O cabeçalho alimenta o llms.txt, o VERSAO.json da skill e a vitrine, e ficou atrás do Log três vezes. A guarda guarda-versao-log.py compara versão e data do cabeçalho com o topo do Log (e o Log em ordem decrescente) e, na composição, o cabeçalho com a célula `Publicar: "sim." (MANIFESTO §253).
texto inteiro da versão
Publicar: "sim." (MANIFESTO §253). Sobe tudo o que estava pronto desde
68d2f17 — c660274, 2b916c5, 442a7da, fe12414, 106723c, 2185e81 — e este registro. Backup REV-P15: "todo backup ao fica agendado nessa maquina, o Robo deve gerenciar, porque sao feitos no mesmo local" — a tarefa agendada local é descartada e o backup vira pedido à sessão do ERP, dona do robô (leitura "não fica" exposta a veto). A SH-P25 sai depois da publicação, junto com o pedido.REV-P7 aplicada (MANIFESTO §267, agente REV7 da leva 3 sobre F0–F3 da leva 2).
texto inteiro da versão
REV-P7 aplicada (MANIFESTO §267, agente REV7 da leva 3 sobre F0–F3 da leva 2). 77 blocos de história vão ao Histórico da própria seção (F1 5 · F2 33 · F3 39; perda zero 6/6 · 9/9 · 53/53), o H1 do componentes volta a ser só o título, a fila LC vai ao fim do roadmap, 21 seções de registro passam a historico; a frase "no escuro, elevação é LUZ, não sombra" fica no §48 como princípio norteador (veredito do §250.2); a SH22 (o rail no padrão ClickUp) entra no §46.7 e o DET no §49 — componentes v1.74; a vitrine passa a ler a forma nova do changelog (311 atualizações). Nascem REV-P17 a REV-P22, PR-P43 a PR-P47 e SH-P38.O atualizador da skill não deixa a instalação pela metade, e os ponteiros do gêmeo de tokens citam só a seção (MANIFESTO §266, leva 3, agentes P39 e TK4).
texto inteiro da versão
O atualizador da skill não deixa a instalação pela metade, e os ponteiros do gêmeo de tokens citam só a seção (MANIFESTO §266, leva 3, agentes P39 e TK4). Causa medida da falha intermitente da prova do atualizador: o Windows recusa renomear pasta com arquivo aberto por outro processo (7 de 300 numa janela de 2,5 min); numa atualização isso deixava a skill sem pasta nenhuma — agora a troca tenta por até 5 s e, ao desistir, sai 3 com a instalação anterior de volta, e a prova não cai mais em cascata (13 de 13; 24 de 24 sob carga) —
PR-P39 fecha. Os 87 ponteiros do seed-tokens.css e 5 descrições do json citam a seção certa, sem número de linha, e a guarda nova PT entra no rito — TK-P4 fecha. Nasce a PR-P42 (o índice sem --checar).Geradores de peça sem duplicação (MANIFESTO §265, agente E da leva 2 e agente REV14 da leva 3).
texto inteiro da versão
Geradores de peça sem duplicação (MANIFESTO §265, agente E da leva 2 e agente REV14 da leva 3). A fonte embutida e o laço grava-ou-compara das peças passam a morar num lugar só cada um (
fonte_bloco.py, 20 geradores; checar_bloco.emite_peca, 22 geradores), 7 funções mortas e 15 imports sem uso saem (o gen-dp deixa de exigir numpy e scipy e gera em 0,8 s em vez de 6,7 s): 604 linhas líquidas a menos, 37 de 37 geradores byte-idênticos (525 de 525 artefatos em duas gerações); na leva 3, irmao(), argumentos(), placar_tela() e px_de() no checar_bloco levam mais 352 linhas (78 de 83 itens, 526 de 526 artefatos iguais) — REV-P14, as duas partes.O driver geradores-checar ganha o gen-sia (censo 63) e reprova gerador com --checar fora do censo sem motivo escrito — PR-P35 fecha. Nasce a PR-P41 (guardas de escape e de peça fresca fora do rito).O rail no padrão ClickUp (MANIFESTO §264, SH-P34) — pedido e aprovado por ele no mesmo dia ("ficou otimo").
texto inteiro da versão
O rail no padrão ClickUp (MANIFESTO §264,
SH-P34) — pedido e aprovado por ele no mesmo dia ("ficou otimo"). Três tipos de destino, declarados pelo produto: painel (o sobrevoo abre, depois de 300 ms, a prévia na caixa da coluna; o clique ancora a sidebar de contexto; o subitem carrega só o submenu dele), balao (abre e fecha no clique, nunca ancora) e direto. Teclado, toque, rail recolhido e gaveta estreita medidos (R17, 22 casos). A regra SH22 sobe ao canon com a REV-P7. Nascem SH-P35, SH-P36, QD-P11 e QD-P12, da sessão do ERP. Na integração, o agente J2 (leva 3) consertou uma regressão real que a régua de resposta ao ponteiro achou (o pressionado igual ao sobrevoo com a prévia aberta) e fechou a HV-P13; o agente DET consertou três defeitos da tela-detalhe pedidos pelo ERP (a atividade que nunca empilhava, o travessão do valor vazio escondido, o valor truncado antes do rótulo a 390 px). QD-P11 fecha pela resposta dele na folha do ERP; nascem QD-P13, PD-P5 a PD-P9, SH-P37 e PR-P40.O conferidor de peça não trava mais no Chrome do Windows (MANIFESTO §263, leva 2, agente H).
texto inteiro da versão
O conferidor de peça não trava mais no Chrome do Windows (MANIFESTO §263, leva 2, agente H). O
conferir-peca.py roda o Chrome num Job Object do Windows que encerra a árvore inteira no prazo (antes, com o prazo de 20 s, voltava em 77, 97 e mais de 150 s; agora em 25 s, sem Chrome vivo) — CP-P19 fecha; a cobaia 9 do CP-13 passa a ser o retrato da casca nova do ERP, com CP-13 PASS e 0 achados como o ERP mediu — SH-P26 fecha; a prova nova prova-trava-chrome.py entra no rito pelo caso determinístico (--casos C, ~11 s, sem navegador). Nasce a CP-P20 (as 17 cobaias do CP-13 fora do rito). O rail no padrão ClickUp (SH-P34) passa ao número seguinte.O anel de foco do rail e os literais da casca (MANIFESTO §262, leva 2, agente G).
texto inteiro da versão
O anel de foco do rail e os literais da casca (MANIFESTO §262, leva 2, agente G). O foco visível do item do rail passa de 1,19:1 a ≥ 3:1 contra as duas cores vizinhas nos dois temas, só com tokens existentes (
SH-P29, que o ERP esperava); a casca troca literais pelos tokens do canon, o menu de conta vai para a superfície de overlay e o véu passa a ser um só (SH-P28); o convite do quadro deixa de sair em Arial (QD-P5) e o gatilho "Mover para…" deixa de sumir no toque (QD-P6); a gaveta de navegação vai ao degrau 65 da escala do §31 (SH-P33, metade). A prancha das perguntas SH-P27, HV-P12 e SH-P30 vai à folha dele. Nasce HV-P13.Primeira área da leva 2 (MANIFESTO §261) — o índice em 18 s em vez de 13 min, e a bancada que responde como o ar.
texto inteiro da versão
Primeira área da leva 2 (MANIFESTO §261) — o índice em 18 s em vez de 13 min, e a bancada que responde como o ar. O
gen-indice.py varria o acervo inteiro duas vezes para cada um dos 3.534 arquivos; agora conta tudo numa passada (777 s → 18 s, as três vistas byte-idênticas em sete gerações), o que encurta todo rito (PR-P33). A bancada local responde como o nginx em 46 de 47 endereços (VT-P7); a guarda da skill instalada deixa de contar o cache de bytecode (SK-P8); seis suítes passam pelo ambiente.mjs (PR-P36). Nascem dez códigos: SH-P34 (o rail no padrão ClickUp, pedido dele), PC-P3 (a triagem pelo papel ds_triagem, pedido do site), e do ERP TK-P5, SH-P32, SH-P33 e QD-P6 a QD-P10.REV-P6 e REV-P5 aplicadas (MANIFESTO §260) — a peça impressa embute a Montserrat completa em woff2, e o rito passa a provar as peças.
texto inteiro da versão
REV-P6 e REV-P5 aplicadas (MANIFESTO §260) — a peça impressa embute a Montserrat completa em woff2, e o rito passa a provar as peças. Veredito "3 fonte das peças: woff2": as 67 peças impressas trocam o TTF inteiro pela woff2 completa (−96,16 MB; 67 de 67 PNG com MD5 igual, PDF 0 px); a regra da marca muda para "fonte completa, embutida em woff2" (marca-seed.md v5.49). Os 33 geradores de peça entram no checar_bloco, o driver geradores-checar vai a 62 de 62 (184 s, tudo no rito normal; a proposta de mandar destaques e favicon ao --bloco vai à folha dele), e as 155 peças que divergiam se regeneram uma vez só, sem mudança visual. Fecha a leva 1: as cinco áreas estão na main.REV-P8 e REV-P9 aplicadas (MANIFESTO §259) — a segurança do publicado e da skill.
texto inteiro da versão
REV-P8 e REV-P9 aplicadas (MANIFESTO §259) — a segurança do publicado e da skill. Os cabeçalhos de segurança (HSTS, enquadramento, CSP em Report-Only) passam a ser declarados uma vez só no nginx, que troca para a imagem oficial sem root, com raiz só-leitura e nenhuma capability; o /COMMIT sai do ar; o VERSAO.json da skill passa a ser assinado e o atualizador confere a assinatura e recusa caminho que saia da pasta; nasce a guarda-publicado.py (contrato PU), que reprova segredo, dado pessoal, caminho de máquina ou endereço da VM em qualquer arquivo do conjunto publicado. A linha do veredito verbatim de 2026-08-26 fica intacta e isenta até a resposta dele (REV-P16). O redirecionamento de pasta deixa de vazar a porta interna (VT-P8). Nascem VT-P9, SH-P31 e QD-P5.REV-P12 parte a aplicada (MANIFESTO §258) — a superfície para IA sem os tropeços que a R5 mediu.
texto inteiro da versão
REV-P12 parte a aplicada (MANIFESTO §258) — a superfície para IA sem os tropeços que a R5 mediu. O sitemap ganha as 54 páginas de roteamento que a regra de consulta manda ler primeiro (833 → 887 URLs); o llms.txt deixa de mandar o agente a uma pasta que dá 403 e passa a apontar o registry; o título do componentes deixa de sair cortado; os _index.md mostram a frase "quando consultar" (veredito 6b: 290 de 290) e deixam de citar a LC-12 fechada; os ponteiros de linha dos tokens, 18 de 54 errados, viram ponteiros de seção; a medir-consulta.py volta a medir e entra no rito com a cobaia. Nascem TK-P4 (os mesmos ponteiros no gêmeo CSS), HV-P12 (sobrevoo invisível sobre o overlay no escuro) e SH-P30 (token do véu), os dois últimos da REV-29 do ERP.REV-P13 aplicada (MANIFESTO §257) — a publicação conferida arquivo a arquivo.
texto inteiro da versão
REV-P13 aplicada (MANIFESTO §257) — a publicação conferida arquivo a arquivo. O deploy/publicar.sh monta o .tar do commit em disco local (não mais por pipe no ssh, que corrompe em silêncio no Git Bash), envia por scp, o servidor confere o MD5 do .tar e, depois de aplicar, devolve o MD5 de CADA arquivo servido de dentro do contêiner (antes: 1 de 1.627); só publica commit que está em origin/main. As dependências do rito passam a morar no repositório (06-validacao/ambiente/). A prova do publicar.sh (13 cenários, sem ssh real) roda no rito quando o commit toca deploy/. A leva 2 abre com oito agentes em paralelo a partir de uma base com a leva 1 inteira; nascem REV-P16, PR-P33 a PR-P37, VT-P6, VT-P7, SK-P8, SH-P27, SH-P28 e SH-P29.REV-P11 aplicada (MANIFESTO §256) — o vermelho fora do rito.
texto inteiro da versão
REV-P11 aplicada (MANIFESTO §256) — o vermelho fora do rito. A suite-prioridade volta a medir (clicava um botão renomeado no 874d78d); a barra de provas da tela-shell-sem-topbar deixa de perder o topo a 390 px (body com altura fixa no molde do shell desde a fundação); o peso 800 que sobrou no molde do painel vira 700, como a SH-P9 e a marca §4.1 mandam; o placar do rito separa a guarda "sem alvo" (0 de 0) das que mediram; contagens em prosa envelhecidas saem. Primeira área da leva 1 de agentes. E a REV-19 do ERP (casca 2 × 2 e menu de conta) é registrada; nascem CP-P19 (conferidor travando no Windows) e SH-P26 (retrato novo da casca do ERP).REV-P10 aplicada (MANIFESTO §255) — as réguas que deixavam passar.
texto inteiro da versão
REV-P10 aplicada (MANIFESTO §255) — as réguas que deixavam passar. O --producao deixa de declarar "zero FAIL" com uma guarda que não mediu; o repouso do contraste a 390 px passa a exato (a variância medida é zero); "0 na rolagem" sem medir vira "NÃO MEDIDA"; seis cobaias entram no rito e a da marca-embutida deixa de sair com erro ao reprovar como esperado; as duas normas fora do censo são lidas. E a HV1 passa a comparar IDENTIDADES em vez de contagens com ±2: medida item a item nos 34 logs gravados, a oscilação está toda em 8 itens da tela-site, e item novo passa a reprovar sempre. O rito vai de 33 para 42 guardas e provas.2026-09-25
SH-P24 (MANIFESTO §252, 2026-09-25) — a topbar passa a ocupar a largura inteira, ACIMA do rail: supersede da posição da SH3 do §46 ("altura total, à esquerda da topbar", gate de 2026-08-11), com o veredito dele verbatim…
texto inteiro da versão
SH-P24 (MANIFESTO §252, 2026-09-25) — a topbar passa a ocupar a largura inteira, ACIMA do rail: supersede da posição da SH3 do §46 ("altura total, à esquerda da topbar", gate de 2026-08-11), com o veredito dele verbatim "1 arranjo: sim". A casca vira grade 2 × 2 no módulo único shell_bloco.py; nos 12 moldes com topbar ela passa a ser o primeiro filho do .app. O resto do contrato do rail não muda.SH-P24 aplicada (MANIFESTO §252) — a topbar de ponta a ponta, acima do rail.
texto inteiro da versão
SH-P24 aplicada (MANIFESTO §252) — a topbar de ponta a ponta, acima do rail. Veredito dele na folha: "1 arranjo: sim". Supersede da posição da SH3 do §46 (componentes v1.73). A casca vira grade 2 × 2 no shell_bloco.py; nos 12 moldes com topbar ela passa a ser o primeiro filho do .app; a tela sem topbar sai com a marcação idêntica. Medido em 12 de 12 telas a 1440, 800 e com o rail recolhido. As oito suítes da casca passaram sem mudança — nenhuma media a posição —, então nasce a régua render-shell TB-01 a TB-03 (12 de 12 na tela nova, 12 de 12 FAIL na cobaia antiga). A ficha de conformidade (conferir-peca.py CP-13), que ainda provava o "rail altura total", troca de sinal; as 10 cobaias derivadas são regravadas. Nasce SH-P25: avisar a sessão do ERP depois da publicação.REV-P3 aplicada (MANIFESTO §251) — o CLAUDE.md enxuto e a leitura de abertura que cabe.
texto inteiro da versão
REV-P3 aplicada (MANIFESTO §251) — o CLAUDE.md enxuto e a leitura de abertura que cabe. Autorização dele: "2 CLAUDE.md/abertura: sim". O CLAUDE.md vai de 29.399 para 22.232 bytes: sete blocos de história (entre eles os vereditos de 2026-08-26 sobre a cópia no Drive) mudam POR CÓPIA para 08-historico/abertura-texto-movido-rev-p1.md, e a "Fonte de verdade" passa a dizer que o repositório mora em disco local (veredito "1 Drive: c"). A leitura de abertura cai de 1.327.871 bytes para cerca de 15 KB além do que entra sozinho: cabeçalho do roadmap e 5 linhas do Log sempre, o resto por consulta. O INDICE.md vai de 898.125 para 521.160 bytes com uma linha por pasta gerada (ia/, vitrine/, skill/; o detalhe segue no indice.json) e a raiz num bloco só. Perda zero provada: 9 de 9 provas, duas cobaias reprovando, gerações byte-idênticas.A folha da REV-P1 respondida de novo e o pedido da topbar acima do rail (MANIFESTO §250).
texto inteiro da versão
A folha da
REV-P1 respondida de novo e o pedido da topbar acima do rail (MANIFESTO §250). Ele colou de novo a resposta da folha (17:57Z): a frase "no escuro, elevação é LUZ, não sombra" passa de superada a vigente, como princípio norteador ("apenas uma frase para nos nortear, aqui estamos criando conceitos e regras proprias" — o comentário mora na caixa logo abaixo da 4b, medido no script da folha); a REV-P7 a leva para a regra do §48. O resto do veredito do §249 não muda, e a REV-P15 (backup) segue aberta. Na mesma mensagem, o pedido "quero que o topbar seja fixo inicando acima da rail" nasce como SH-P24: supersede da posição da SH3 do §46 ("altura total, à esquerda da topbar", gate de 2026-08-11), com protótipo medido (rail 615 → 543 px, topbar 1.291 → 1.383 px a 1440, Tab passa pela topbar antes do rail) e folha de gate https://claude.ai/artifact/7ffo63pdGApA4A9GijyUs4. Nada muda no material até o "confere" dele.REV-P1 consolidada e veredito dele (MANIFESTO §248–§249) — o repositório sai do Google Drive para um clone em disco local (<raiz-do-repo>; caminho de máquina retirado do texto publicado pela REV-P9).
texto inteiro da versão
REV-P1 consolidada e veredito dele (MANIFESTO §248–§249) — o repositório sai do Google Drive para um clone em disco local (<raiz-do-repo>; caminho de máquina retirado do texto publicado pela REV-P9). 8 agentes executor-opus só leitura (7 revisores por área + 1 verificador de perda zero), 524 chamadas, US$ 23,29, 8 de 8 transcripts 100 % claude-opus-5-5; a sessão confirmou 12 de 12 achados graves por outro caminho. Durante a revisão o Google Drive travou com TOO_MANY_OPEN_FILES, e o próprio git fsck o derrubou em 3 de 3 tentativas (33.649 objetos soltos, gc.auto=0). Veredito verbatim no §249.1 (folha versão 2, 02:55Z): "1 Drive: c" com backup semanal das 8 últimas semanas do DS e de cada repositório; "2 CLAUDE.md/abertura: sim"; "3 fonte das peças: woff2"; "4 canônicos: dentro"; "4b … superada"; "5a atualizador: assinar"; "5b … manter"; "5c CSP: report"; "6a … depois"; "6b … a"; "7 mapa: nao"; "8 … vetos: nenhum". Clone local do GitHub: git fsck exit 0 em 23 s, git status 108 ms (2,1–2,6 s no Drive). Nascem REV-P2…REV-P15 (§248.4, §249.4); a REV-P2 fecha neste mesmo commit. Cabeçalho deste roadmap corrigido (parte mínima da REV-P4).2026-09-24
Grupo 9 (MANIFESTO §245, 2026-09-24) — o BT2 do §64.1 passa a ser medido também no ARTEFATO, no Chrome, pelo rito (guarda-barra-gramatica.mjs, PR-P26), e o banco-dataviz-dp entra na gramática única da barra (BT-P8): 27…
texto inteiro da versão
Grupo 9 (MANIFESTO §245, 2026-09-24) — o BT2 do §64.1 passa a ser medido também no ARTEFATO, no Chrome, pelo rito (
guarda-barra-gramatica.mjs, PR-P26), e o banco-dataviz-dp entra na gramática única da barra (BT-P8): 27 de 27 barras emitidas pelo módulo controles_bloco.py. O denominador verdadeiro é 39: 12 barras seguem fora (BT-P10). Nenhuma regra muda — é atualização de número e de instrumento, aplicação da sessão exposta a veto.Pergunta 2 da §238.6 respondida (MANIFESTO §244, 2026-09-24) — o nome acessível da trilha passa a ser "Trilha" no §36 BC2, que cede ao §46 SH2.
texto inteiro da versão
Pergunta 2 da §238.6 respondida (MANIFESTO §244, 2026-09-24) — o nome acessível da trilha passa a ser "Trilha" no §36 BC2, que cede ao §46 SH2. As duas seções eram
estável e se contradiziam; a suite-shell já media o do §46. Veredito dele: "sigo sua recomendação". A única bancada com o nome longo (banco-navegacao.html, sem gerador) foi alinhada. Nenhuma outra decisão muda.**REV-P1 nasce (MANIFESTO §247) — revisão geral do repositório com agentes Opus 5.5 em paralelo, antes de continuar.
texto inteiro da versão
REV-P1 nasce (MANIFESTO §247) — revisão geral do repositório com agentes Opus 5.5 em paralelo, antes de continuar. Pedido dele, verbatim: "se eu pedir para voce usar o opus 5.5 para orquestrar vários agentes simultaneos para revisar todo o codigo desse projeto otimizando ele antes de continuarmos, acha uma boa ideia? nao só fazendo isso que eu disse, mas o que voce tbm achar que seja proveitoso." · regra de modelo: "os varios agentes simultaneos também serão apenas opus 5.5" e "vc pode usar o sonnet para ler, mas quem vai pensar e escrever tem que ser o opus 5.5". Só leitura; folha de gate com custo por saída; aplicação depois do veredito. É o próximo passo depois da compactação, antes da GT-P9.Veredito dele, verbatim: "pode publicar e seguir com as recomendações" (MANIFESTO §246).
texto inteiro da versão
Veredito dele, verbatim: "pode publicar e seguir com as recomendações" (MANIFESTO §246). O
68d2f17 é publicado (produção zero FAIL; skill servida 2026.09.21+532f9049). O Grupo 9 fecha 13 de 13: o G9-10 (EOL-P1) refaz o censo de fim de linha (45 CRLF + 33 mistos → 40 + 2), põe o mapa-cobertura-ds.md em LF (só o fim de linha muda, provado 7 de 7) e entrega a guarda-eol-misto.py, que entra no rito e na estreia pega 24 fatias de IA velhas. SH-P21 parte 2: o escopo da tela vira trilha-nav nos dois moldes, render idêntico em 8 de 8 capturas — e a sessão corrige, por medição, a própria afirmação de que a regra antiga pintava o Kanban. Fecham SH-P21, CT-P20 (os gen-variantes-* ficam), PF-P5, EOL-P1; nascem PR-P31 e PR-P32. Os 13 clones do grupo removidos com prova arquivo a arquivo.Grupo 9 consolidado (MANIFESTO §245) — 12 agentes em paralelo (no máximo 5 ao mesmo tempo, ordem dele), 12 de 13 entregues; 13 pendências fecham.
texto inteiro da versão
Grupo 9 consolidado (MANIFESTO §245) — 12 agentes em paralelo (no máximo 5 ao mesmo tempo, ordem dele), 12 de 13 entregues; 13 pendências fecham.
SK-P5 (nada sai da zona garantida da skill: a régua contava o frontmatter; folga real medida numa compactação), SK-P6, PR-P21 (bytes de controle por lista de binários), PR-P22/PR-P23 (o acha() pelo censo do git; prova ambiente-alvo no rito), PR-P24 (dm/dg), PR-P25 (log vazio = NÃO MEDI e bloqueia; guarda/prova fatoradas), PR-P26 (guarda-barra-gramatica.mjs no rito: o BT2 medido no Chrome), CP-P16 (conferidor sem falso positivo em ${…}), BT-P8 (dp na gramática: 27 de 27), BT-P9 (BT1 por assinatura, e agora no rito), PF-P4 (sobras do preview arquivadas) e a A3 do §244 (fechar.sh --bloco). O rito passa a CONTAR as próprias guardas. Regressão da V-PR15 achada e consertada (a largura em px da barra perdeu a mono). Ambiente jsdom compartilhado reconstruído (estava podado). Componentes v1.72. 18 pendências novas (BT-P10…BT-P12, DP-P11, PR-P27…PR-P30, SK-P7, CP-P17, CP-P18, MA-P7, SH-P23, PB-P13, MR-P22, PF-P5, GT-P9 — a triagem de 20 pedidos novos do SEED Chat —, GT-P10). Ao gate: prancha do chat (LC-15/16/19, Q1–Q10), prancha de abas e botão flutuante (LC-17/18), folha LC-13/14 + LC-01/02/04, os nomes de "trilha" (SH-P21 parte 2) e a tabela de remoção (CT-P20 parte 2, PF-P5). Fica para depois deste commit: G9-10 (EOL-P1, fim de linha).Checkpoint e respostas dele (MANIFESTO §243.6 e §244).
texto inteiro da versão
Checkpoint e respostas dele (MANIFESTO §243.6 e §244). Os achados de 21/09 que estavam em prosa ganham código (
PR-P25, PR-P26, BT-P8, BT-P9, SK-P6, GT-P8), com errata ao §243 (o log vazio foi da rolagem; a lição de CRLF já existia e foi violada — EOL-P1). Ele respondeu tudo de uma vez: o §36 BC2 cede ao §46 SH2 (nome acessível "Trilha", aplicado: componentes v1.71); SK-P5 se MEDE antes de cortar ("mais contexto é mais assertivo"); modo rolado da RCM uma vez por bloco; publicar (e a regra: a sessão pergunta e publica); a troca do zip no Lovable ele faz com a aba aberta pela sessão; clone de agente consolidado se remove sem perguntar (GT-P8 executada com prova); Grupo 9 com tudo que não depende dele, até 5 agentes ao mesmo tempo; LC-15..19 se fazem; LC-13/14 e LC-01/02/04 voltam a ele. Correção: o 874d78d levou a v2.89 deste roadmap sem regenerar as fatias de IA — este rito regenera.2026-09-21
V-PR15 (2026-09-21) — A BARRA DE PROVAS PASSA A TER UMA GRAMÁTICA SÓ, E O BT2 SAI DE "NÃO VERIFICADO" PARA "VERIFICADO POR INSTRUMENTO".
texto inteiro da versão
V-PR15 (2026-09-21) — A BARRA DE PROVAS PASSA A TER UMA GRAMÁTICA SÓ, E O BT2 SAI DE "NÃO VERIFICADO" PARA "VERIFICADO POR INSTRUMENTO". O estudo PR-P15 (Grupo 7, 2026-09-20) mediu duas gramáticas perfeitamente separadas nos 26 artefatos com barra — 12 na de bancada (sem role="group", sem nome acessível, com type="button" e o <select> das cinco larguras do BT2) e 14 na de tela (com nome acessível, sem type="button", com três botões de largura que não são as do contrato, e em só 4 dos 14) — e o achado que reordenou tudo: 14 dos 26 não tinham controle de largura NENHUM, inclusive a bancada banco-dominio. Veredito dele no gate, verbatim: "não vejo que isso seja decisao minha, parto do principio de que é uma barra para simular situações para eu avaliar, logo, voce deve colocar o maximo de informações nessa barra e padroniza-la para todas as telas. Identifique o que precisa e pode aplicar sua recomendaçao. veto: nenhum". Aplicada a recomendação medida (a gramática ÚNICA): nome acessível de grupo, type="button" e o <select> das cinco larguras do BT2 em 26 de 26 (antes: 14, 35 de 95 botões e 8, respectivamente), tudo emitido pelo módulo único controles_bloco.py, que cresce da MOLDURA (PR-P11) para a barra inteira — HTML do núcleo, aparência dos botões e script da largura —, e cujo conferir() passa a PROVAR sete cláusulas no ato de gerar, entre elas o BT2 e o token fantasma (NV-01). Placares medidos: BT1 39·0·15 igual ao baseline · BP1 26·0·15 igual · HV1 74 PASS · 6 FAIL · 2 [n/a] igual em veredito (denominador 1476 → 1452, exatamente os 12 botões que saíram × 2 temas) · contraste rasterizado 0 FAIL em 39 de 39 a 1440 e a 390 nos dois temas · regeneração byte-idêntica 25 de 25 · MH1 (sobrevoo da barra dentro de @media (hover: hover), pendência HV-P10) 6 PASS · 20 FAIL → 26 PASS · 0 FAIL, baseline regravado. Fecha a BT-P3 do §74.9 (supersede no §64.1 e na tabela do §74.9, com a colisão de código registrada: há duas BT-P3 no arquivo, e a do §64.11.1 é outra pendência, fechada em 2026-08-17). Três achados de conserto que a medição pegou e que ficam registrados: seis geradores consumiam token que o bloco embutido não definia (NV-01, a geração abortou até os nomes entrarem em NOMES), quatro moldes ficaram com identificador JavaScript inválido no rename (var b-tema) e a BT1 caiu de 39 para 35 até o conserto, e o corte do CSS do shell levou junto a regra GLOBAL button {…} do PRODUTO e a HV1 mediu 1,23 no escuro até ela voltar. Fronteira declarada: o script de tema e o de escala de cinza continuam por molde (não mudam pixel); os controles PRÓPRIOS de cada artefato continuam no molde, por dentro da barra.**Veredito do estudo SH-P20 (MANIFESTO §241/§242, 2026-09-21) — o §36 BC4 muda de "antes do <main>" para "primeiro filho DENTRO do <main>", supersede formal.
texto inteiro da versão
Veredito do estudo
SH-P20 (MANIFESTO §241/§242, 2026-09-21) — o §36 BC4 muda de "antes do <main>" para "primeiro filho DENTRO do <main>", supersede formal. A redação antiga nunca se cumpria nos quatro moldes do shell (a trilha sempre esteve dentro do <main>) e a tentativa de aplicá-la de verdade derrubou a régua de contraste de 10·0 para 5·5 (o <main> é a peça branca do CP1; fora dele a trilha herda o canvas com material do §93). Veredito dele, verbatim: "Saída A — fica onde está; o BC4 muda. se depois do sistema funcionando acharmos que será melhor mudar o local, reanalisamos no futuro." Nenhum molde muda (a posição real já era essa); nenhum placar muda.**PR-P15/V-PR15 fecha (MANIFESTO §243) — a barra de provas dos 26 artefatos ganha UMA gramática, a BT-P3 fecha com número e instrumento, e a HV-P10 vai junto.
texto inteiro da versão
PR-P15/V-PR15 fecha (MANIFESTO §243) — a barra de provas dos 26 artefatos ganha UMA gramática, a BT-P3 fecha com número e instrumento, e a HV-P10 vai junto. Ele delegou a escolha técnica ("não vejo que isso seja decisao minha... voce deve colocar o maximo de informações nessa barra e padroniza-la para todas as telas... aplique sua recomendaçao. veto: nenhum") — aplicada a gramática ÚNICA recomendada pelo estudo do Grupo 7: nome acessível de grupo (14→26 de 26), type="button" (35→83 de 83) e seletor de largura do BT2 (8→26 de 26, fechando a BT-P3 do §74.9 desde 2026-08-20), tudo pelo módulo único controles_bloco.py; de quebra, o sobrevoo da barra entra em @media (hover: hover) nos 26 (MH1: 6·20 FAIL → 26·0 FAIL, fecha a HV-P10). Executado por um agente Opus 5 em clone isolado, consolidado por esta sessão (que aplicou o canon à mão para não herdar, de novo, a normalização integral de quebra de linha que a edição de seed-componentes.md por estas ferramentas causa sem avisar — achado registrado no §243.4). seed-componentes.md v1.69→v1.70, com dois supersede formais e a colisão de código de duas BT-P3 distintas registrada verbatim. Rito completo, 25 guardas, zero FAIL, depois de regenerar 10 cobaias do shell que tinham ficado desatualizadas.SH-P20/V-SH20 fecha por decisão dele (MANIFESTO §242) — a trilha (breadcrumb) fica onde está, o BC4 do §36 é supersedido.
texto inteiro da versão
SH-P20/V-SH20 fecha por decisão dele (MANIFESTO §242) — a trilha (breadcrumb) fica onde está, o BC4 do §36 é supersedido. O estudo achou o enunciado do BC4 errado em três pontos (os 4 moldes não divergem, a trilha sempre foi o primeiro filho DENTRO do <main>; são 5 de 17 telas, não 11; o skip-link nunca deixou de levar a trilha junto) e mostrou que aplicar a redação antiga ao pé da letra (trilha ANTES do <main>) derruba a régua de contraste de 10·0 para 5·5 — o <main> é a peça branca do CP1, fora dele a trilha herda o canvas com material do §93. Veredito verbatim: "Saída A — fica onde está; o BC4 muda. se depois do sistema funcionando acharmos que será melhor mudar o local, reanalisamos no futuro." seed-componentes.md §36 BC4 reescrito com supersede formal (v0.41 → v0.42; arquivo v1.68 → v1.69); nenhum molde ou placar muda — a posição real já era essa.SH-P19 pergunta 1 fecha por decisão dele (MANIFESTO §241) — tela-chat fica COM topbar, o regime sem topbar arquiva sem promoção.
texto inteiro da versão
SH-P19 pergunta 1 fecha por decisão dele (MANIFESTO §241) — tela-chat fica COM topbar, o regime sem topbar arquiva sem promoção. Ele confirmou o topbar em todo o ERP e informou que o SEED Chat de verdade roda em tela separada, só com a Rail; a sessão explicou que tela-chat.html é gabarito de referência do DS (arquétipo A23, §55), não o mockup do produto, e que a variante --sem-topbar já preparada e provada (reaproveita o mecanismo da SH-P17) seria a candidata mais próxima. Veredito verbatim: "só como estudo arquivado. quando formos construir algum chat para o ERP, vamos usar o SEED Chat como modelo, não o contrario." Nenhum código muda; a variante e a folha de comparação ficam em 09-pesquisa/2026-09-20-grupo-7/sh-p19/, arquivadas. Nasce a doutrina (linha nova em "Decisões estruturais"): chat do ERP segue o SEED Chat, não o tela-chat do DS.Grupo 8 (MANIFESTO §240) — seis agentes Sonnet 5 em paralelo sobre as pendências do Grupo 7 que não dependiam de decisão, medido 1,08×–1,88× do estimado, zero conflito em seis patches.
texto inteiro da versão
Grupo 8 (MANIFESTO §240) — seis agentes Sonnet 5 em paralelo sobre as pendências do Grupo 7 que não dependiam de decisão, medido 1,08×–1,88× do estimado, zero conflito em seis patches.
banco-dataviz-dm.html e -dg.html ganham molde + gerador com a primeira geração byte-idêntica e o gen-dm.py (fragmentos para colagem manual, já divergentes do artefato) aposentado — o driver do rito passa a 29 de 29 (PR-P18); quatro instrumentos que morriam ou mediam zero em silêncio sem alvo passam pelo alvosHtml (PR-P19: o contraste-composicao varria o cwd desde a reestruturação); o relógio da tela-onboarding vira exemplo literal com ?vivo e o teste ON-07 deixa de depender da hora da máquina (PR-P20); a folha da F9.8 sai de preview/atual.html para preview/arquivo/2026-09-f98-abertura.html e a guarda PF2 diz NÃO MEDI com 0 de 0 quando não há folha (PF-P3); o conferidor deixa de ler comentários em fontes .ts/.tsx/.js/.jsx em três detecções, com seis cobaias (CP-P15); a guarda de rolagem remede sozinha as páginas NÃO MEDI e grava os cinco temporários com PID — censo de %TEMP% em 364 de 364 arquivos (RL-P6, CT-P19); nasce a régua MH1 guarda-barra-sobrevoo.mjs (sobrevoo da barra de provas dentro de @media (hover: hover)), no rito por baseline em 20 FAIL · 6 PASS de 26, com três defeitos de instrumento pegos pelas cobaias antes de valer (HV-P10, que fica aberta até a V-PR15 consertar os moldes). Consolidação: acha() acha uma fixture não rastreada do eval-skill e torna seed-tokens.css ambíguo só no Drive (PR-P23). Nascem PR-P21 · CP-P16 · PR-P22 · PR-P23 · PR-P24 · PF-P4 · CT-P20.2026-09-20
Grupo 6 (MANIFESTO §238, 2026-09-20) — SH-P17: nasce a tela-shell-sem-topbar.html, o segundo REGIME do shell (produto SEM topbar, avatar do menu de conta na BASE do rail, ☰ do SH12 como primeiro elemento do conteúdo),…
texto inteiro da versão
Grupo 6 (MANIFESTO §238, 2026-09-20) —
SH-P17: nasce a tela-shell-sem-topbar.html, o segundo REGIME do shell (produto SEM topbar, avatar do menu de conta na BASE do rail, ☰ do SH12 como primeiro elemento do conteúdo), emitida do mesmo molde pelo mesmo gen-shell.py; o §46.6 deixa de dizer que "não existe tela de referência SEM topbar"; o §46.2 diz onde vive o ☰ sem topbar; a coluna "referência traz a casca" do §46.4 passa a ser medida pelo RAIL e a tabela do SH17 ganha a linha nova; errata de contagem: são 15 gabaritos para 17 telas (o A2 sempre teve duas), não "16 gabaritos". Achado do olho, medido: o avatar no rail não ficava na base (151 px do botão de recolher) — faltava o margin-top:auto; R14/R15 do render-shell.mjs passam a medir geometria. Nenhuma outra decisão muda.Grupo 7 (MANIFESTO §239) — nove agentes em paralelo (Sonnet 5 × 7, Opus 5 × 2), medido 0,68×–2,8× do estimado, zero conflito em nove patches.
texto inteiro da versão
Grupo 7 (MANIFESTO §239) — nove agentes em paralelo (Sonnet 5 × 7, Opus 5 × 2), medido 0,68×–2,8× do estimado, zero conflito em nove patches. Os 27 geradores de tela e bancada entram no rito por
--checar (PR-P12 + PR-P16: checar_bloco.py, driver geradores-checar.py, 23 geradores sem sys.exit corrigidos, sétimo artefato em v1.29 achado); a guarda do preview entra no rito e a folha da F9.8 que morava em preview/atual.html volta a ser legível (PR-P13); HV1 e mais oito guardas dizem NÃO MEDI sem alvo (PR-P14); tela-configuracoes 3,02 → 9,01 (CT-P16: o #a3dcd9 era o canvas de material composto, --seed-text-brand-strong também falhava a 4,15); o CP-13 estático ignora comentários HTML e ganha a décima cobaia (CP-P13, CP-P14); o toast estacionado do dataviz some de verdade e a régua rasterizada nunca mais corta o documento — ALTURA_MAX vira alarme (CT-P17, CT-P18: o banco-formfield perdia 84 de 290 textos com "0 FAIL"); o relógio da tela-painel vira dado literal com ?vivo (PR-P17); a tela-chat ganha o position:relative preventivo e a conversão ao regime sem topbar fica renderizada para a decisão (SH-P19). Dois estudos Opus para o gate: a trilha (SH-P20: os 4 moldes NÃO divergem, 5 de 17 telas, o BC4 não se cumpre em nenhuma e a fonte NN/g não diz o que ele atribui; mover derruba o contraste de 10·0 para 5·5) e a barra de provas (PR-P15: duas gramáticas exatas, 18 formas → 3, 14 de 26 sem controle de largura, quatro convergências que nenhuma régua distingue). Consolidação: as três guardas de contraste gravavam o JSON com nome fixo em %TEMP% e se contaminavam em paralelo — PID no nome. Nascem PR-P18 · PR-P19 · PR-P20 · PF-P3 · CP-P15 · RL-P6 · HV-P10 · SH-P21 · CT-P19.Grupo 6 (MANIFESTO §238) — oito agentes em paralelo (Opus 5 × 3, Sonnet 5 × 5), medido 0,33×–2,9× do estimado.
texto inteiro da versão
Grupo 6 (MANIFESTO §238) — oito agentes em paralelo (Opus 5 × 3, Sonnet 5 × 5), medido 0,33×–2,9× do estimado. Nasce a
tela-shell-sem-topbar (SH-P17, componentes v1.68; o avatar no rail não ficava na base — 151 px do botão, achado do olho); a barra de provas vira módulo único controles_bloco.py com a sombra inset (PR-P11 + CT-P13 c: 16 cópias divergentes, z-index 60 × 9000; trilha 3,26 → 4,52); o conferidor diz NÃO MEDI atrás de login (CP-P11) e deixa de aceitar a barra de abas como rail (CP-P12: era o aria-label="Áreas", não o regex); tela-tabela a 390 px consertada com position:relative (CT-P14); trilha com ol/li e "Início" (SH-P18, que achou a contradição §36 × §46); a régua de contraste ganha o modo móvel (390 px) e o rolado, e a 14.ª guarda (RCM) entra no rito só em repouso (CT-P15: 194 textos abaixo do piso na rolagem, 112 pela barra; tela-configuracoes a 3,02 é o pior do acervo no celular); PC-2026-0010 → LC-19; 15 clones removidos com prova no ato. Causa dos seis artefatos desatualizados: o rito não roda os geradores de tela (PR-P12). Nascem PR-P12 · PR-P13 · CP-P13 · CP-P14 · SH-P19 · SH-P20 · PR-P14 · PR-P15 · PR-P16 · CT-P16 · CT-P17 · PR-P17 · CT-P18.Grupo 5 (MANIFESTO §237) — seis pendências do fechamento da F12 em paralelo (Opus 5 × 2, Sonnet 5 × 4, Fable orquestrando; medido 0,58×–1,7× do estimado) e a causa real da Clara no Lovable.
texto inteiro da versão
Grupo 5 (MANIFESTO §237) — seis pendências do fechamento da F12 em paralelo (Opus 5 × 2, Sonnet 5 × 4, Fable orquestrando; medido 0,58×–1,7× do estimado) e a causa real da Clara no Lovable. Fecham
CP-P9 (CP-13 com dois regimes, com e sem topbar), CP-P10 (segredo no --alvo), SK-P2 (SKILL.md −40 %, modos em references/), SK-P3 (suíte do eval enfim na main, fixture por hash, rodada 3 Δ +1,00 em 3 de 4), PR-P10 (índice carimba o HEAD) e SK-P4 (o conhecimento do workspace do Lovable dizia "flat, sem sombras" em toda mensagem — corrigido; cobaia 3 leu a skill, rodou a ficha e citou §46/§93). CT-P13 medida (3,25, barra de controles do preview) e devolvida ao gate. SH-P17 reenunciada (as onze telas têm topbar). Correção da §236.9: a suíte do eval nunca esteve na main. Skill o commit do código (9e27da0) emitiu 2026.09.19+d7654de1; o commit deste registro muda o roadmap (v2.83) e, com ele, a versão de novo — a versão PUBLICADA se mede depois da publicação e entra no relatório de fechamento, na memória e na próxima seção, nunca antes do rito (lição do §237.4). Nascem CP-P11 · CP-P12 · CT-P14 · CT-P15 · SH-P18 · PR-P11 · SK-P5 · GT-P7.2026-09-19
F12.9 (MANIFESTO §235.2 e §236, 2026-09-19) — nasce o SH21, conta e tema no shell: UM menu de conta por tela, aberto pelo avatar (Perfil · Tema com claro, escuro e seguir o sistema · Sair); avatar na zona direita da…
texto inteiro da versão
F12.9 (MANIFESTO §235.2 e §236, 2026-09-19) — nasce o SH21, conta e tema no shell: UM menu de conta por tela, aberto pelo avatar (Perfil · Tema com claro, escuro e seguir o sistema · Sair); avatar na zona direita da topbar (SH10) e, em produto sem topbar, na base do rail acima do botão do SH19; o tema nasce pelo sistema e a primeira escolha da pessoa passa a valer por CONTA — decisão dele no gate
SH-P16, verbatim: "V-SH16.1: b · V-SH16.2: (…) na parte inferior da rail · V-SH16.3: a · veto: nenhum"; aplicado no módulo único shell_bloco.py nas onze telas, suíte 84 → 97, render 54 → 63, régua rasterizada com o menu ABERTO nos dois temas 0 FAIL; a redação da 46.6 é a que o código implementou (Tab FECHA o menu, como manda o §35 — a proposta dizia "prende o foco" e estava errada).F12.4 (MANIFESTO §234, 2026-09-19) — a fonte de verdade passa a dizer onde mora o acabamento, a REGRA vem antes da HISTÓRIA, e a história de cada seção migra para o fim dela.
texto inteiro da versão
F12.4 (MANIFESTO §234, 2026-09-19) — a fonte de verdade passa a dizer onde mora o acabamento, a REGRA vem antes da HISTÓRIA, e a história de cada seção migra para o fim dela. Três mudanças, nenhuma de valor. (1) D-1, o ponteiro que faltava: o §46 (shell de aplicação) citava o §93 (material) ZERO vezes — medido na fatia publicada, 0 ocorrências de "§93" em 286 linhas — e por isso a IA que adequou os dois apps de chat da empresa em 2026-09-18 não achou que o rail é metálico, obrigando o decisor a corrigi-la ("voce nao aplicou da maneira correta a cor da rail que é metalizado tbm"). SH3 e SH15 ganham a oração "acabamento: metal escovado quando a tela declara
data-material (§93 MA2, receita metal_rail → .rail)", e o bloco "Natureza" ganha a regra geral do sistema: toda seção vestida por uma camada transversal (material §93, composição CP1–CP32, tema/tokens) APONTA a camada. (2) D-7, a regra antes da história: a única afirmação do raio do rail vivia depois da oração "A exceção nomeada do rail foi SUPERSEDIDA" — quem lia o começo concluía o contrário. O §46.1 passa a abrir por "O rail é peça sobre o canvas como as demais — radius-lg, calha nos quatro lados, sem borda" e a supersede desce para uma "Nota de histórico"; o §74.5 recebe a mesma inversão. Nasce a regra de redação: nenhum enunciado normativo começa pela palavra que o revoga. A varredura de SUPERSEDID|REVOGAD|superad nos quatro canônicos achou 7 aberturas candidatas, 5 recusadas a olho com o motivo registrado. (3) V-SK1 = b, o ### Histórico da seção: 72 de 98 seções ganham, no FIM, um H3 ### Histórico da seção para onde migram 118 blocos em 109 grupos (pesquisa de origem, pendência fechada, placar de rodada, veredito narrado, alternativa descartada, gênese da regra), em ordem cronológica inversa, texto byte a byte, nada reescrito; no corpo fica uma linha *(decisão registrada — ver Histórico da seção)* por grupo. Prova: 0 linha não vazia perdida, 181 linhas novas (72 H3 + 109 ponteiros), LF puro 124 → 124 (o arquivo é misto e não foi normalizado), gen-camada-ia.py e gen-vitrine.py byte-idênticos em --checar, e as guardas CI, VT, BC, UC, SG e NB no mesmo placar de antes. Oito blocos foram VETADOS à mão, com o motivo escrito no relatório do brick — seis são pendência ABERTA ou ressalva viva, dois são avisos que anotam a tabela logo abaixo deles. Mudam o cabeçalho, o §46 e 71 outras seções.**F12.4 (MANIFESTO §234, 2026-09-19) — a história de cada seção migra para o fim dela (### Histórico da seção), por V-SK1 = b.
texto inteiro da versão
F12.4 (MANIFESTO §234, 2026-09-19) — a história de cada seção migra para o fim dela (
### Histórico da seção), por V-SK1 = b. Contexto para quem lê sem ter visto: em 2026-09-18 o decisor pediu, nos dois apps de chat da empresa, que a IA adequasse o material ao DS, e teve de corrigi-la seis vezes; o reconhecimento de 2026-09-19 mediu que 25,7 % a 40,2 % dos bytes que um agente de IA lê nos canônicos de construção são rastro histórico, não a regra a aplicar. A saída aprovada foi separar os dois DENTRO do arquivo: cada seção termina com um H3 ### Histórico da seção, que o gen-camada-ia.py poderá servir como fatia à parte (brick F12.3b). Neste arquivo o movimento alcançou 2 de 19 seções — §7 (grafismo, 6 grupos: os vereditos verbatim dele de 2026-08-20 a 2026-08-22 sobre serra-cena, teto de largura, piso de traço, medida física do cartão e sangria) e §12 (camada física, 3 grupos). A cobertura é baixa e ISSO É O MEDIDO: quase toda a história deste canônico está no §18 Versionamento, que é changelog e não é alvo deste brick. Texto MOVIDO byte a byte, nada reescrito; no corpo fica *(decisão registrada — ver Histórico da seção)*. Prova: 0 linha não vazia perdida, 11 linhas novas (2 H3 + 9 ponteiros), 0 CRLF criado (o arquivo é LF puro), geradores byte-idênticos, guardas no placar de antes. Um bloco foi vetado à mão: a pendência PT-P2 do §12.3, que está ABERTA — pendência aberta é estado vivo, não história.F12 FECHADA (MANIFESTO §236) — consolidação dos nove bricks, publicação autorizada ("Sim, publique agora"), fase 2 do aceite e dois defeitos da própria skill achados por ela.
texto inteiro da versão
F12 FECHADA (MANIFESTO §236) — consolidação dos nove bricks, publicação autorizada ("Sim, publique agora"), fase 2 do aceite e dois defeitos da própria skill achados por ela. Tempo medido × estimado por brick entre 0,08× e 0,26× (o reconhecimento já estava feito); consolidação pela sessão principal foi o custo dominante e onde as costuras apareceram (tipo de campo entre bricks, receita por URL, orçamento de bytes do SKILL.md, baselines CI-11/CI-13, tolerância da HV1). Eval com a skill nova: nenhuma regressão real (caso
lacuna-declarada envelheceu com o SH21; grader caminho só aceita Read). Cobaia real do SEED Chat em sessão nova, sem dica: mediu antes de editar, achou rail metálico e bordas, pôs o tema no menu do avatar na base do rail, declarou o que o canon não cobre — e achou a CP-P9. Cobaia da Clara no Lovable (remix): a skill NÃO foi lida, nem em prosa nem com /seed-ds pela API (0 de 2) — o problema daquela superfície é o disparo, não o conteúdo (SK-P4; o conhecimento do projeto da Clara vira o caminho, espera o "sim" dele). Fase 2 achou na skill: frontmatter YAML inválido para o Lovable (description com : ) e versão que não mudava com o texto — consertados no gerador e na SK-1; skill 2026.09.19+22a3085b nas três superfícies. Nascem CP-P9, CP-P10, SK-P2, SK-P3, SK-P4, SH-P17, PR-P10, CT-P13.Vereditos da F12.6 e da F12.5 (MANIFESTO §235).
texto inteiro da versão
Vereditos da F12.6 e da F12.5 (MANIFESTO §235). Triagem dos pedidos de cobertura: LC-13 (seção sobre o X) e LC-14 (calendário editorial) nascem em ⏸ aguarda por decisão dele ("foco em Instagram e Facebook primeiro"); LC-15/LC-16 (mensageria de atendimento e revisão do CH14) e LC-17/LC-18 (barra de abas de app e botão flutuante) ABERTAS, com a orientação dele verbatim (WhatsApp como referência; painel lateral direito para ações do ERP/CRM); PC-0009 descartado (já era a MR-P20). Gate SH-P16: V-SH16.1 = b (tema dentro do menu de conta), V-SH16.2 verbatim (sem topbar, o avatar fica na base do rail e abre o mesmo menu), V-SH16.3 = a (segue o sistema até a pessoa escolher; por conta) — nasce o SH21 e o brick F12.9 (Opus 5) para aplicá-lo no
shell_bloco.py. Banco private.ds_pedidos gravado na mesma rodada.F12 ABERTA (MANIFESTO §234) — a skill em uso real depois do lançamento.
texto inteiro da versão
F12 ABERTA (MANIFESTO §234) — a skill em uso real depois do lançamento. Reconhecimento em cinco frentes (SEED Chat, Clara/Lovable, acervo, Clau, mercado) mediu a causa das seis correções dele: comportamento de consulta (uma fatia e para; ficha 0 execuções; pedido 0 envios), skill sem modo de adequação, §46 sem ponteiro para o §93, rastro de 25,7–40,2 % dos bytes. Gate v1 respondido verbatim (§234.5): canônicos no modo completo (b), Claude Code atualizado 2.1.258→2.1.278, consumidores editados por esta sessão, nenhuma frente vetada, roteamento Opus 5 × Sonnet 5. Oito bricks F12.1–F12.8 abertos em paralelo; nasce
SH-P16; consulta_bloco.py é a fonte única da regra de consulta. Achado de processo: origin/main estava 3 commits atrás do HEAD — push feito.F12.4 (MANIFESTO §234, 2026-09-19) — a história de cada seção migra para o fim dela (### Histórico da seção), por V-SK1 = b.
texto inteiro da versão
F12.4 (MANIFESTO §234, 2026-09-19) — a história de cada seção migra para o fim dela (
### Histórico da seção), por V-SK1 = b. Mesma mudança do marca-seed.md v5.48 e do seed-componentes.md v1.66, aplicada aqui: o reconhecimento de 2026-09-19 mediu que este é o canônico mais contaminado por rastro (53,0 % dos bytes das fatias, régua ampla) e que um agente de IA lê história onde precisa de regra. Alcance neste arquivo: 3 de 17 seções — §3 (1 grupo), §3c dataviz (5 grupos: os achados de gate e os "Estado: estável desde") e §5-g (1 grupo). Texto MOVIDO byte a byte; no corpo fica *(decisão registrada — ver Histórico da seção)*. Prova: 0 linha não vazia perdida, 10 linhas novas (3 H3 + 7 ponteiros), 0 CRLF criado (arquivo LF puro), gen-camada-ia.py e gen-vitrine.py byte-idênticos em --checar, guardas no placar de antes. Vetado à mão: a TK-P1 do §5-g, pendência ABERTA. A maior parte da história deste canônico continua no §9 Versionamento, que é changelog e não é alvo deste brick (separar cabeçalho de changelog é o D-8, do brick F12.3b).2026-09-16
SH-P12 item 2 fechado, 2026-09-16 (MANIFESTO §233): veredito dele, verbatim, "V-SH12.2 (Escopo rail × acordeão): a (vira rail) · veto/observação: nenhum". Nasce a decisão
texto inteiro da versão
SH-P12 item 2 fechado, 2026-09-16 (MANIFESTO §233): veredito dele, verbatim, "V-SH12.2 (Escopo rail × acordeão): a (vira rail) · veto/observação: nenhum". Nasce a decisão SH20 no §46.1: o painel
.escopo (a árvore de filtro de 250 px de tela-quadro.html, tela-detalhe.html e tela-gantt.html) vira uma EXTENSÃO do rail do shell — some do conteúdo no MESMO limiar do SH12 (860 px de contêiner app) e reaparece dentro do MESMO <dialog class="nav-drawer">, reaproveitando o mecanismo já testado (render-shell.mjs), em vez de ganhar um acordeão próprio com regra e cobertura de teste novas (a Alternativa B descartada). Resolve de quebra a lacuna de acessibilidade da SH-P15 (abaixo de 420 px o .escopo sumia sem nenhum jeito de reabrir) — agora ele está SEMPRE alcançável pelo botão ☰. Emitido pelo módulo único shell_bloco.py (2 linhas: o seletor CSS do colapso e o seletor JS que move os nós para o drawer) mais a remoção da regra própria .escopo{display:none} a 420 px nos 3 moldes que têm o painel; suite-shell 84 · 0, render-shell 54 · 0, contraste-shell 55 · 0, suite-composicao 33 · 0, suite-quadro 35 · 0, suite-detalhe 73 · 0, suite-gantt 43 · 0 — placares idênticos aos já declarados no canon, sem regressão. Mudam o cabeçalho, §46.1 e §46.2.TK-P2, 2026-09-16 (MANIFESTO §225.4-b): o §71.6 ganha uma nota de DADO, sem gate e sem conserto -- no tema escuro, surface-sunken e surface-page são o mesmo hex (#0B1419), e por isso o botão desabilitado…
texto inteiro da versão
TK-P2, 2026-09-16 (MANIFESTO §225.4-b): o §71.6 ganha uma nota de DADO, sem gate e sem conserto -- no tema escuro,
surface-sunken e surface-page são o mesmo hex (#0B1419), e por isso o botão desabilitado (.seed-btn:disabled) e o campo em modo leitura (.seed-field__control[readonly]) ficam sem fronteira visível contra a página nesse tema (os dois zeram a borda por CSS e dependem só do fundo para se distinguir). O outro achado da mesma pendência -- duas verdades para a tinta do botão secundário -- é corrigido em 02-tokens/seed-tokens.json/.css (remove action-secondary-text, duplicata do button-secondary-text que este canon já define no §1.6) e não toca este arquivo. Mudam o cabeçalho e o §71.6.Gate SH-P12 item 2 respondido (MANIFESTO §233) — o painel .escopo de quadro/detalhe/gantt vira extensão do rail.
texto inteiro da versão
Gate SH-P12 item 2 respondido (MANIFESTO §233) — o painel
.escopo de quadro/detalhe/gantt vira extensão do rail. Veredito dele, verbatim: "V-SH12.2 (Escopo rail × acordeão): a (vira rail) · veto/observação: nenhum". Nasce a decisão SH20 (componentes v1.65, §46.1/§46.2): o .escopo some no MESMO limiar de 860 px do SH12 e reaparece no MESMO drawer, reusando o mecanismo já testado do SH12/SH19 (shell_bloco.py, 2 linhas) em vez de um acordeão novo sem cobertura (Alternativa B, descartada); resolve de quebra a SH-P15 (o painel não tem mais largura em que fica inalcançável). SH-P12 e SH-P15 FECHAM. Regenerado nas onze telas com casca (byte-idêntico em duas rodadas); placares sem regressão (suite-shell 84 · 0 nas onze, render-shell 54 · 0, contraste-shell 55 · 0, suite-composicao 33 · 0, suite-quadro 35 · 0, suite-detalhe 73 · 0, suite-gantt 43 · 0, suite-configuracoes 18 · 0).Grupo 4 — oito pendências em paralelo, consolidadas (MANIFESTO §232): PR-P8 (a HV1 entra no rito por baseline, não por "0 FAIL" — 250 controles sem :active são backlog de conteúdo, não ruído; a causa da oscilação era…
texto inteiro da versão
Grupo 4 — oito pendências em paralelo, consolidadas (MANIFESTO §232):
PR-P8 (a HV1 entra no rito por baseline, não por "0 FAIL" — 250 controles sem :active são backlog de conteúdo, não ruído; a causa da oscilação era antialiasing do Chromium, não um await faltando), HV-P4 resto (4 bancadas sem cobertura + 3 resíduos do HV-A), CT-P11 (a RC passa a ler <text> de SVG — 18.ª guarda, contraste-total, cobre todo o acervo), FF-P4 (token fantasma vivo em 10 citações + guarda que mentia sobre a isenção), SH-P12 (itens 1/3/4 aplicados — dois nav duplicados, :focus-visible, sidebar do chat a 280 px; item 2 em gate), TK-P2 resto (remove o token duplicado action-secondary-text), CP-P7 (o conferir-peca.py passa a medir a TELA, não o PDF, em entrada HTML) e MR-P20 (demanda do SEED Chat: o */ embutido no comentário do registry engolia o @font-face do peso 400 — corrigido e republicado). Componentes v1.64, tokens v1.30. Oito achados sem código nascem (PR-P9, HV-P9, SH-P15, CT-P12, FF-P5, CP-P8, TK-P3, MR-P21). Rito: 18 guardas, zero FAIL.2026-09-15
SH-P14 aplicada, Grupo 3, 2026-09-15 (MANIFESTO §229) — o rail ganha o estado RECOLHIDO só ícone (nova decisão
texto inteiro da versão
SH-P14 aplicada, Grupo 3, 2026-09-15 (MANIFESTO §229) — o rail ganha o estado RECOLHIDO só ícone (nova decisão SH19 no §46.1): veredito dele, verbatim, "V-SH14.1 modo recolhido: b · V-SH14.2 gatilho: a · V-SH14.3 posição do botão: a · V-SH14.4 quem lembra: a · veto: nenhum". Padrão 80 px com rótulo (SH3, agora "no estado padrão" — supersede parcial com as duas fontes do NN/g datadas) · recolhido 56 px = sp-12 + 2·sp-1, item 48 × 48, ícone 24, rótulo no DOM com clip de 1 px que vira tooltip em :hover/:focus-visible (§23 X1/X3/X6; o do 1.º destino desce para não cobrir o seletor de contexto) · gatilho: botão
.alterna-rail na base do rail, último focável, aria-expanded · quem lembra é o PRODUTO (preferência do usuário, global, nasce expandido; as telas de referência não persistem nada) · o recolhido não existe abaixo do limiar do SH12 nem no toque. Tudo emitido pelo módulo único shell_bloco.py nas onze telas; suite-shell 84 · 0, render-shell 54 · 0, contraste-shell 55 · 0, CP-13 11 de 11 (aceita 80 ou 56 pelo data-rail), RC 22 de 22. Mudam o cabeçalho, §23.2, §46 (título), §46.1, §46.2, §46.3 e §46.5.Grupo 3, onda 2, 2026-09-15 (MANIFESTO §228) — SH-P13: o §46.2 fixa por escrito o limiar do SH12 (860 px de CONTÊINER app, nunca de janela) e o módulo shellbloco.py passa a emitir a casca inteira do colapso (botão ☰,…
texto inteiro da versão
Grupo 3, onda 2, 2026-09-15 (MANIFESTO §228) —
SH-P13: o §46.2 fixa por escrito o limiar do SH12 (860 px de CONTÊINER app, nunca de janela) e o módulo shell_bloco.py passa a emitir a casca inteira do colapso (botão ☰, dialog.nav-drawer, regra e script) — as onze telas com casca respondem igual (88 de 88 cenas a 390/768/1024/1366); HV-P4 G-B aplicado nas dez telas, no shell e no site (o item ATIVO do rail ganha sobrevoo/pressionado na rampa da pílula: turquesa-200/300, tinta 9,35/7,39) — §71.8 registra o recenso: HV1-a 552 → 94 · HV1-b 1.224 → 240 · HV1-c 0. Mudam o cabeçalho, §46.2 e §71.8.Grupo 3, onda 1 — aplicação do veredito do gate do Grupo 2, 2026-09-15 (MANIFESTO §226–§227): §71.6 ganha as duas linhas que os vereditos V-HV4.1 = a e V-HV4.2 = a decidem (par action-neutral-on-subtle-hover/-active…
texto inteiro da versão
Grupo 3, onda 1 — aplicação do veredito do gate do Grupo 2, 2026-09-15 (MANIFESTO §226–§227): §71.6 ganha as duas linhas que os vereditos V-HV4.1 = a e V-HV4.2 = a decidem (par
action-neutral-on-subtle-hover/-active para controle transparente sobre a casca; regra D3(a): ghost/outline dentro de cartão consome o par neutro) e o parágrafo do veredito, §1.5 a linha active (primário escuro monotônico, tokens v1.29), §73.5 a ponte para o negrito por cor, §75.8 nova (V-FT2.1 = b e V-FT2.2 = c: negrito dentro de texto já 700 marca por text-brand-strong, rótulo em JetBrains Mono declara 700), §47.7 nova — MK29 (V-PB9.1 = b: barra de acessibilidade no topo de toda página pública, atalhos accesskey 1–4, o alvo se declara; não substitui o skip link SH8). Mudam o cabeçalho, §1.5, §47.7, §71.6, §71.8, §73.5 e §75.8.Grupo 2, segunda leva, 2026-09-15 (MANIFESTO §225.5–§225.8) — SH-P11: a tabela SH17 (§46.4) ganha a coluna "rail funcional (medido)" — as dez telas de aplicação passam a compor a casca REAL do shell pelo módulo único…
texto inteiro da versão
Grupo 2, segunda leva, 2026-09-15 (MANIFESTO §225.5–§225.8) —
SH-P11: a tabela SH17 (§46.4) ganha a coluna "rail funcional (medido)" — as dez telas de aplicação passam a compor a casca REAL do shell pelo módulo único shell_bloco.py (CP-13 11 de 11 PASS; antes só a tela-shell tinha rail funcional), e o §46.5 diz que casca ilustrativa é o que o SH18 chama de bancada. HV-P4 relida: erratas no §71.5 (censo de 2026-09-15 ao lado do de agosto: 552 HV1-a · 1.224 HV1-b · 0 HV1-c em 39 arquivos), §71.6 (a frase "nenhum consumidor de action-ghost-hover sobre elevada" envelheceu — são 5; action-neutral-hover é surface-subtle, logo controle transparente sobre a casca tem sobrevoo invisível por construção — decisão em gate; o metal do §93.3 é a terceira forma aceita de pressionado) e §71.8 (estado e plano). Mudam o cabeçalho, §46.4, §46.5, §71.5, §71.6 e §71.8.Grupo 2, primeira leva, 2026-09-15 (MANIFESTO §225.2) — LC-05 FECHADA: o pressionado é fundo por TOKEN nas cinco variantes do botão (o destructive também não tinha :active: eram quatro sem par, não três). Nascem nos…
texto inteiro da versão
Grupo 2, primeira leva, 2026-09-15 (MANIFESTO §225.2) —
LC-05 FECHADA: o pressionado é fundo por TOKEN nas cinco variantes do botão (o destructive também não tinha :active: eram quatro sem par, não três). Nascem nos gêmeos (tokens v1.28), sem hex novo, action-secondary-bg-hover/-active, action-ghost-active e action-destructive-active; §1.5 ganha a regra "pressionado é SEMPRE fundo por token, um passo além do sobrevoo, na mesma direção — nunca véu/filter" (o canon já decidia amplitude, mecanismo e direção em §1.5/§71.2/§71.6; faltavam os tokens); §1.6, §1.9, §1.10 e §1.11 acompanham; o §18.3 deixa de citar o token fantasma --seed-action-primary-bg (o certo é --seed-action-primary, 3,81/5,31 sobre o trilho). Nasce a suite-botao.mjs (47 de 47). Aplicação da sessão, exposta a veto com os renders na folha do Grupo 2.Veredito do gate do Grupo 1, 2026-09-15 (MANIFESTO §224.1), verbatim: "V-CT9 regra: a · V-LC11 data-arquetipo: sim · V-STASH: a · veto: nenhum". CT-P9 FECHA: a tinta de marca sobre superfície suave EM REPOUSO…
texto inteiro da versão
Veredito do gate do Grupo 1, 2026-09-15 (MANIFESTO §224.1), verbatim: "V-CT9 regra: a · V-LC11 data-arquetipo: sim · V-STASH: a · veto: nenhum".
CT-P9 FECHA: a tinta de marca sobre superfície suave EM REPOUSO (surface-subtle, surface-brand-subtle: 4,23 e 4,28) é text-brand-strong (5,82 e 5,89) em qualquer estado — linha nova na gramática do §73.5, notas de consumo nos §22.2, §32.2 e §46.5; nenhum token muda. Nasce o SH18 (§46.5): toda tela publicada declara no <html> o data-arquetipo (aplicacao · autenticacao · pagina · bancada · documento) — os 16 moldes declaram, o CP-13 mede sem --arquetipo. Os sete itens do §223.7 (SH-P9 = b no acervo inteiro, entre eles) passam de aplicação exposta a veto a decisão dele. Mudam o cabeçalho, §22.2, §32.2, §46.5 e §73.5.Grupo 3, onda 1 — aplicação do veredito do gate do Grupo 2 (MANIFESTO §226–§227).
texto inteiro da versão
Grupo 3, onda 1 — aplicação do veredito do gate do Grupo 2 (MANIFESTO §226–§227). §4.1 (V-FT2.4 = b e V-FT2.3 = b): os pesos carregados pelo sistema são 400/500/600/700 — o 300 (Light) fica para peça impressa, corpo em tela é Regular; itálico não é carregado, o oblíquo sintético do navegador é o aceito; ponte para a regra do negrito por cor (componentes §75.8). §12.22 (V-CT10.1 = c+b): como se mede a legibilidade do adesivo — pelo par declarado e pela régua física, porque a RC não lê texto de SVG; a anotação do mock foi para um cartão.
PB-P11 (V-PB11.3/11.4): §12.25 cita "ABNT NBR 5419-1 a -4" com classes e periodicidade [a conferir na edição 2026]; §12.22 uniforme pela NBR IEC 61482-2:2023; §4.8 NBR 9050:2020 VC:2021; §12.13 12699 → 12972:2009/13314:2009; §12.14 o ano da 10582 é 1988 e a linha carrega o cancelamento — o §12.14 segue citando a NBR 8402 até a V-PB11.1 (leitura da 16861 pelo RT).§6, solução 3 (SPDA): passa a citar as ABNT NBR 5419-1 a -4 (edição 2026) por decisão do responsável técnico — V-PB11.3 = a, MANIFESTO §226.1; "classes I a IV" marcado [a conferir na edição 2026] até a leitura do texto.
texto inteiro da versão
§6, solução 3 (SPDA): passa a citar as ABNT NBR 5419-1 a -4 (edição 2026) por decisão do responsável técnico — V-PB11.3 = a, MANIFESTO §226.1; "classes I a IV" marcado
[a conferir na edição 2026] até a leitura do texto. Aplicado pelo Grupo 3, onda 1 (MANIFESTO §227).SH-P14 aplicada e FECHADA (MANIFESTO §230) — o rail ganha o estado recolhido só ícone (SH19): 56 px, rótulo no DOM e em tooltip, botão na base, opção do usuário no desktop, nunca abaixo do limiar do SH12 nem no toque;…
texto inteiro da versão
SH-P14 aplicada e FECHADA (MANIFESTO §230) — o rail ganha o estado recolhido só ícone (SH19): 56 px, rótulo no DOM e em tooltip, botão na base, opção do usuário no desktop, nunca abaixo do limiar do SH12 nem no toque; quem lembra é o produto (§46.5). Componentes v1.63; 11 telas regeneradas (+0,1 cada); 2 cobaias novas do CP-13. Agente 72 min × 5 h estimadas (0,24×). O Grupo 3 termina com as 28 respostas dele aplicadas.Veredito do gate do Grupo 3 (MANIFESTO §229) — a única decisão que sobrou da aplicação do Grupo 2: SH-P14, o rail recolhível.
texto inteiro da versão
Veredito do gate do Grupo 3 (MANIFESTO §229) — a única decisão que sobrou da aplicação do Grupo 2:
SH-P14, o rail recolhível. Verbatim no §229.1: "V-SH14.1 modo recolhido: b · V-SH14.2 gatilho: a · V-SH14.3 posição do botão: a · V-SH14.4 quem lembra: a · veto: nenhum" — 4 de 4 iguais à leitura da sessão. O rail ganha um estado recolhido só ícone (56 px, rótulo no DOM e em tooltip), acionado por botão na base do rail, como opção do usuário no desktop; nunca abaixo do limiar do SH12 nem no toque; o ERP lembra por usuário e toda tela nasce expandida. Supersede parcial do SH3 (nasce SH19); sem V3. Aplicação num agente em clone local (§229.3); nenhum canon de conteúdo muda neste commit.Grupo 3, onda 2 (MANIFESTO §228): SH-P13 FECHA por aplicação (o SH12 nas onze telas pelo módulo único — 88 de 88 cenas; correção ao enunciado do §226.5: a 390 px oito telas viravam o rail em faixa horizontal e duas…
texto inteiro da versão
Grupo 3, onda 2 (MANIFESTO §228):
SH-P13 FECHA por aplicação (o SH12 nas onze telas pelo módulo único — 88 de 88 cenas; correção ao enunciado do §226.5: a 390 px oito telas viravam o rail em faixa horizontal e duas mantinham a coluna com 274 px de conteúdo); HV-P4 G-B aplicado (GB-1 42 min × 60, GB-2 41 × 60, SH-P13 57 × 75) e o item ativo do rail; recenso HV1 552/1.224/0 → 94/240/0 — o resto tem causa nomeada (quatro bancadas sem item, resíduos do HV-A, CTA metálico). Componentes v1.62. Folha do Grupo 3 só com o SH-P14 e o veto.Grupo 3, onda 1 — o veredito do Grupo 2 aplicado (MANIFESTO §227): cinco agentes em clones locais (FT-P2 61 min × 60 estimados · PB-P11 41 × 75 · PB-P9 48 × 60 · HV-A 55 × 90 · HV-B 51 × 90) + o estudo SH-P14 (40 × 60)…
texto inteiro da versão
Grupo 3, onda 1 — o veredito do Grupo 2 aplicado (MANIFESTO §227): cinco agentes em clones locais (FT-P2 61 min × 60 estimados · PB-P11 41 × 75 · PB-P9 48 × 60 · HV-A 55 × 90 · HV-B 51 × 90) + o estudo SH-P14 (40 × 60) + a sessão principal (CT-P10, MR-P19, consolidação). FECHAM:
CT-P10, FT-P2, MR-P19; PB-P11 com 6 de 7 aplicadas (a 11.1 espera a leitura da NBR 16861 pelo RT); PB-P9 aplicada na vitrine (barra de acessibilidade, MK29; site decide em separado); HV-P4 com G0 + G-A feitos e tokens v1.29 (recenso 552/1.224/0 → 283/518/0), G-B na onda 2; SH-P14 estudo pronto para a folha. Componentes v1.61, marca v5.47, práticas v1.7, tokens v1.29, sobreaseed 2026-09-15.Veredito do gate do Grupo 2 (MANIFESTO §226) — 23 respostas, 21 iguais à recomendação da sessão; as duas diferentes: V-PB9.3 = não (o site institucional decide o símbolo de acessibilidade em separado, P-064 de lá) e…
texto inteiro da versão
Veredito do gate do Grupo 2 (MANIFESTO §226) — 23 respostas, 21 iguais à recomendação da sessão; as duas diferentes: V-PB9.3 = não (o site institucional decide o símbolo de acessibilidade em separado, P-064 de lá) e nenhuma outra — a V-PB11.1 = a fica esperando a leitura da NBR 16861 por ele (é o RT). Veredito verbatim no §226.1; o que cada resposta executa no §226.2. Nascem
SH-P13 (o SH12 só existe no shell: 0 de 10 telas com casca real escondem o rail em tela estreita — aplicação) e SH-P14 (estudo com renders do rail recolhível "só ícone", pergunta dele — gate, porque supersede o SH3). Aplicação em duas ondas de agentes (§226.6); nenhum canon de conteúdo muda neste commit.Grupo 2, segunda leva (MANIFESTO §225.5–§225.9): SH-P11 FECHA por aplicação (casca real nas dez telas, módulo shellbloco.py, CP-13 11 de 11); PB-P11, PB-P9 e HV-P4 preparadas para o gate; nascem SH-P12, CP-P7, PB-P12.
texto inteiro da versão
Grupo 2, segunda leva (MANIFESTO §225.5–§225.9):
SH-P11 FECHA por aplicação (casca real nas dez telas, módulo shell_bloco.py, CP-13 11 de 11); PB-P11, PB-P9 e HV-P4 preparadas para o gate; nascem SH-P12, CP-P7, PB-P12. Estimado × medido: SH-P11 1,5 h × 1 h 25 · PB-P11 1 h × 43 min · PB-P9 40 min × 46 · HV-P4 20–30 min × 23. Componentes v1.60 (SH17 com "rail funcional (medido)", erratas do §71), práticas v1.6 (o Decreto 5.296 não remete ao SIA para sítios — errata; estado da PB-P11), asset do SIA com procedência em 03-assets/acessibilidade/. A folha do Grupo 2 reúne V-SH11 · V-CT10 · V-FT2 · V-PB11 · V-PB9 · V-HV4 · veto.Grupo 2, primeira leva consolidada (MANIFESTO §225.1–§225.4): LC-05 FECHA; FT-P2 e CT-P10 medidas, parte aplicada, o resto em gate; seis pendências nascem.
texto inteiro da versão
Grupo 2, primeira leva consolidada (MANIFESTO §225.1–§225.4):
LC-05 FECHA; FT-P2 e CT-P10 medidas, parte aplicada, o resto em gate; seis pendências nascem. Sete demandas por ordem dele ("pode abrir as 4 primeiras, assim que uma for finalizando, pode abrir outra até finalizar as 7"), agentes em clones locais (nunca a árvore do Drive). Estimado × medido: LC-05 45 min × 37 · FT-P2 1 h × 44 · CT-P10 1 h × 58. LC-05: quatro semânticos de ação sem hex novo (tokens v1.28), canon v1.59 (§1.5 "pressionado é fundo por token, nunca véu"), suite-botao.mjs 47/47, HV1-b da bancada 55 → 0; 12 previews com o 800 residual da SH-P9 reinjetados. FT-P2: censo 260/260; 800 residual (10) → 700 com 0 px; gen-nome-de-fonte.py corrigido; quatro perguntas com bytes (V-FT2.1–2.4). CT-P10: tela-detalhe e banco-dataviz-tokens (portado: molde + gerador) consertados, RC claro 0 de 81; a frota em gate com o achado de que a régua media a anotação e não o adesivo (texto em SVG, que a RC não lê). Nascem FF-P4, HV-P8, TK-P2, CT-P11, MR-P19, PR-P8. Em curso: SH-P11, PB-P11, PB-P9, HV-P4.Veredito do gate do Grupo 1 (MANIFESTO §224) — CT-P9 FECHA, nasce o SH18, o stash de 26/08 é descartado, os sete itens do §223.7 viram decisão dele.
texto inteiro da versão
Veredito do gate do Grupo 1 (MANIFESTO §224) —
CT-P9 FECHA, nasce o SH18, o stash de 26/08 é descartado, os sete itens do §223.7 viram decisão dele. Verbatim: "V-CT9 regra: a · V-LC11 data-arquetipo: sim · V-STASH: a · veto: nenhum", mais a ordem sobre a fila: "temos 7 pendencias, pode abrir as 4 primeiras, assim que uma for finalizando, pode abrir outra até finalizar as 7". CT-P9: a tinta de marca sobre superfície suave em repouso é text-brand-strong — linha nova no §73.5, notas em §22.2/§32.2/§46.5 (componentes v1.58), nota datada no §5-g dos tokens (versão dos gêmeos fica em v1.27: nenhum valor muda). SH18 (§46.5): toda tela publicada declara data-arquetipo (aplicacao · autenticacao · pagina · bancada · documento); os 16 moldes declaram (11 aplicacao, 3 bancada, 1 autenticacao, 1 pagina), o CP-13 do conferir-peca.py lê o atributo e só pede --arquetipo quando nada decide; o shell do ERP declara aplicacao e passa a lang="pt-BR". Stash: git stash drop do 39ead22… de 2026-08-26 com o §223.2 como prova. Grupo 2 aberto (§225): SH-P11, CT-P10, FT-P2, LC-05 em paralelo; PB-P11, PB-P9, HV-P4 entram à medida que cada uma fecha.Grupo 1 em paralelo (MANIFESTO §223) — quatro demandas em quatro subagentes ao mesmo tempo, pela regra nova dele de 2026-09-14 (grupos com tempo estimado; "sigo com sua sugestão").
texto inteiro da versão
Grupo 1 em paralelo (MANIFESTO §223) — quatro demandas em quatro subagentes ao mesmo tempo, pela regra nova dele de 2026-09-14 (grupos com tempo estimado; "sigo com sua sugestão"). Tempo estimado × medido: LC-11 3–4 h × 57 min · CT-P9 1,5–2 h × 48 min · SH-P9 1–2 h × 58 min · stash 20–40 min × 11 min; parede ~1 h em vez de ~6 h somadas.
SH-P9 fechada por aplicação (o 800 nunca foi sintetizado: 0 px de diferença; 800 → 700 no acervo, tokens v1.27, componentes v1.57, TP1-d). CT-P9 censo feito (208 de 208 HTML, zero em bancadas e telas; 2 folhas de gate corrigidas) e regra em gate (V-CT9). LC-11 fechada (CP-13 no conferir-peca.py; 11 de 11 cobaias; peça de fora = shell do ERP). Stash de 26/08 medido: 111 arquivos, todos já na main desde dd32811 (109 idênticos + 2 superconjunto, 0 linhas perdidas) — tabela de remoção na folha. Nascem CT-P10 (outros pares do censo), SH-P11 (as dez telas com casca ilustrativa: main sem id/tabindex, sem skip link, nav duplicada; a tabela SH17 não distingue rail funcional de ilustrativo) e FT-P2 (pesos e estilos pedidos sem face: Mono 600/900, <strong> em texto 700 computando 900 e rendendo 700, itálico sintético). Incidente: o Google Drive File Stream esgotou o próprio limite de arquivos abertos ("Content cache has over 1000 open streams") com quatro agentes lendo o acervo ao mesmo tempo e ficou 31 min sem servir leitura (23:00–23:31 UTC) — reiniciado pela sessão; lição no global. Régua RC ganha ALTURA_MAX por variável (5 arquivos do acervo passavam de 6.000 px e saíam cortados).Grupo 3, onda 1 (MANIFESTO §227): PB-P11 aplicada em 6 de 7 respostas do RT (§23 tem o estado; só a leitura da NBR 16861 fica aberta); §21 termografia cita a NBR 16969:2021 (sucessora da 16292); a guarda-normas.py ganha…
texto inteiro da versão
**Grupo 3, onda 1 (MANIFESTO §227):
PB-P11 aplicada em 6 de 7 respostas do RT (§23 tem o estado; só a leitura da NBR 16861 fica aberta); §21 termografia cita a NBR 16969:2021 (sucessora da 16292); a guarda-normas.py ganha regex com ISO/IEC, regra de forma e TOLERADAS só com 8402/8403 — placar 0 FAIL · 9 AVISO · 2 NÃO MEDI (era 21 AVISO). PB-P9 (V-PB9.1 = b, V-PB9.2 = ambos): a vitrine ds.seed.eng.br ganha a barra de acessibilidade no topo (símbolo + atalhos 1–4), regra MK29 no componentes §47.7; o site institucional decide em separado (V-PB9.3 = não). Nenhuma seção muda de data de revisão.Grupo 2 (MANIFESTO §225.6–§225.7): errata na §18 — o Decreto 5.296/2004 não remete ao SIA para sítios (lido no Planalto; a frase de 2026-09-10 estava errada), a Lei 15.459/2026 vetou o símbolo novo, e o asset do SIA com…
texto inteiro da versão
**Grupo 2 (MANIFESTO §225.6–§225.7): errata na §18 — o Decreto 5.296/2004 não remete ao SIA para sítios (lido no Planalto; a frase de 2026-09-10 estava errada), a Lei 15.459/2026 vetou o símbolo novo, e o asset do SIA com procedência entrou em
03-assets/acessibilidade/; a PB-P11 (§16) ganha o estado: folha de revisão do RT pronta, três fatos novos sobre as sucessoras. Nenhuma seção muda de data de revisão: são notas de pendência, não conteúdo revisado.HV-P4 — gate do Grupo 2 (MANIFESTO §226), veredito dele verbatim: V-HV4.1 casca: a · V-HV4.2 primário escuro: a.
texto inteiro da versão
HV-P4 — gate do Grupo 2 (MANIFESTO §226), veredito dele verbatim:
V-HV4.1 casca: a · V-HV4.2 primário escuro: a. (1) Nasce um par por superfície, sem hex novo: action-neutral-on-subtle-hover (#E3EBF0 cinza-100 = surface-sunken · escuro #1D272D = surface-raised) e action-neutral-on-subtle-active (#C8D6DF cinza-200 · escuro #273137 = surface-overlay) — para controle transparente posado sobre a casca (surface-subtle, o canvas de toda tela de aplicação). Motivo medido (censo de superfície de 2026-09-15, relatório HV-P4): action-neutral-hover vale #F2F6F9 claro / #141D23 escuro, os mesmos hex de surface-subtle — 118 controles no claro e 117 no escuro tinham sobrevoo invisível por construção, e não existe segundo degrau neutro na escala de superfície abaixo de sunken (claro) nem de page (escuro): por isso os seis moldes da MA-P3 usaram véu. No claro o par escurece (casca → cinza-100 → cinza-200, Δ 15 e 27/255); no escuro sobe (casca → raised → overlay, Δ 10 e 10/255), o mesmo sentido de action-ghost-*. Tintas medidas sobre o pressionado (o pior estado): claro text-primary 9,24 · text-secondary 5,22 · text-muted 3,78 (ícone, piso 3,0) · text-brand-strong 4,26 — abaixo do piso 4,5; escuro 10,90 · 7,08 · 5,93 · 7,25 — 15 de 16 pares ≥ piso: a exceção é a tinta de marca do §73.5 sobre o pressionado claro, que nenhum consumidor do par tem hoje (os controles transparentes sobre a casca levam text-secondary/text-primary); regra registrada no §71.6: controle com tinta de marca sobre a casca troca a tinta para text-primary no :active (9,24) — hex novo não se inventa. As alternativas renderizadas para ele (relatório HV-G0, folha/d1-*.png): (b) surface-sunken + anel interno no pressionado — sem token, mas um segundo mecanismo numa família que a v1.28 acabou de padronizar em fundo por token; (c) manter o véu de 12 % — a HV1-c mede a superfície errada e dá verde, e no escuro o clique é invisível (Δ 3/255). (2) Um valor muda — action-primary-active do tema ESCURO: #11B0A0 (turquesa-400) → #CDF3EC (turquesa-100). O primário escuro era a única família não-monotônica do sistema: base turquesa-300 → hover turquesa-200 (clareia) → active turquesa-400 (escurece abaixo da base; Δ 139/255 para baixo), contra o §71.2 (direção única) e o §1.5 do seed-componentes.md. Agora 300 → 200 → 100, clareia nos dois passos como o claro escurece nos dois. Tinta text-on-action-primary (#00352F) sobre o pressionado: 11,37 (antes 4,99). Alternativa (b) inverter a direção foi descartada por número: a tinta escura já estava no último degrau que passa (turquesa-500 dá 4,20). O claro não muda (#005048; capturas de (a) e (c) idênticas nos três estados). Supersede declarado em paridade-tokens.py (SUPERSEDES_V129_DARK); afeta todo botão primário escuro do acervo e do ERP no estado pressionado. paridade-tokens 110 PASS · 0 FAIL. Nenhum outro valor muda.LC-05 (MANIFESTO §225.2) — o pressionado das quatro variantes que não o tinham, sem hex novo.
texto inteiro da versão
LC-05 (MANIFESTO §225.2) — o pressionado das quatro variantes que não o tinham, sem hex novo. A bancada do botão declarava
:active só no primary e o secondary tinha véu (filter: brightness(.96)), que a régua da casa não mede (§71.6 do seed-componentes.md); a guarda HV1 media 55 de 55 .seed-btn da bancada com pressionado igual ao sobrevoo. Nascem QUATRO semânticos de ação: action-secondary-bg-hover (#CDF3EC turquesa-100 · escuro #005048 turquesa-800) e action-secondary-bg-active (#9CE4D8 turquesa-200 · escuro #006C62 turquesa-700) — §1.5 "1 stop / 2 stops"; action-ghost-active (#E3EBF0 = surface-sunken · escuro #273137 = surface-overlay) — o par de action-ghost-hover, um passo além na mesma direção; action-destructive-active (#7A1C1E vermelho-800 · escuro #FFC2BD vermelho-200). Tinta sobre cada fundo novo: 5,24–11,37 claro · 5,31–10,90 escuro. Descartados com número: action-neutral-active para ghost/outline — no escuro vale #0B1419 = surface-page, e o pressionado ficaria igual ao repouso (Δ ≤ 1/255 no pixel); vermelho-500 no destrutivo escuro (3,38). paridade-tokens 110 PASS · 0 FAIL (183 semânticos). Nenhum valor anterior muda.SH-P9 (MANIFESTO §223.4) — o papel titulo-tela deixa de pedir um peso que não existe.
texto inteiro da versão
SH-P9 (MANIFESTO §223.4) — o papel
titulo-tela deixa de pedir um peso que não existe. --seed-txt-titulo-tela-weight passa de 800 para 700 nos dois gêmeos. Motivo medido: a casa carrega Montserrat 400/500/600/700 (subset montserrat-seed-*.woff2), e o Chrome só sintetiza negrito quando a face casada pesa menos de 600 — com a 700 carregada, todo font-weight: 800 do acervo rendia a própria 700: capturas do shell e do painel, nos dois temas, pixel-idênticas entre o estado anterior e o 700 declarado (0 px diferentes, duas medições independentes). A mudança torna a declaração verdadeira e não altera nada visível; a marca §4.1/§4.3 já reservava 800/900 ao display de marketing. Aplicação da sessão, exposta a veto (não houve gate); a alternativa — trazer o ExtraBold real (instância wght=800 da Montserrat variável v9.000, a mesma linhagem dos cinco TTF da casa) — foi renderizada e descartada: engrossaria o H1 de toda tela e o rótulo ativo do rail passaria a 68,375 px, além dos 68 úteis do SH3.2026-09-14
Grupo 1 em paralelo, 2026-09-14/15 (MANIFESTO §223) — SH-P9 FECHADA por aplicação: o "peso 800" do shell, do painel, de 24 moldes de bancada/tela e do papel titulo-tela NUNCA foi sintetizado — o Chrome só engrossa por…
texto inteiro da versão
Grupo 1 em paralelo, 2026-09-14/15 (MANIFESTO §223) —
SH-P9 FECHADA por aplicação: o "peso 800" do shell, do painel, de 24 moldes de bancada/tela e do papel titulo-tela NUNCA foi sintetizado — o Chrome só engrossa por síntese quando a face casada pesa menos de 600, e com a face 700 carregada o 800 rendia a própria 700; provado por captura pixel-idêntica (0 px em 4 telas × 2 temas pelo agente e, de novo, 0 px pela sessão principal forçando TODO peso ≥ 800 a 700). Os 800 viram 700 no acervo inteiro (tokens v1.27), sem mudança visível; a nota do §46, o PN13 e o BU-02 dizem 700; a guarda TP1 ganha a cláusula TP1-d "peso pedido tem face" (achado contado). CT-P9 medida: censo RC em 208 de 208 HTML — ZERO ocorrências do par em bancadas e telas; a regra vai ao gate (V-CT9). LC-11 FECHADA: o conferir-peca.py ganha o CP-13 (shell §46 medido no DOM). Nada mais muda neste canônico.MA-P2 FECHADA, 2026-09-14 — veredito dele, verbatim (MANIFESTO §221.1): "V-MA2.1 MA-P2: fechar · V-MA2.2 site: a · veto: nenhum". O MA12 do §93 deixa de esperar a medição: vidro fora do chrome e dos cartões do painel…
texto inteiro da versão
MA-P2 FECHADA, 2026-09-14 — veredito dele, verbatim (MANIFESTO §221.1): "V-MA2.1 MA-P2: fechar · V-MA2.2 site: a · veto: nenhum". O MA12 do §93 deixa de esperar a medição: vidro fora do chrome e dos cartões do painel está LIBERADO com o piso de campo medido em 2026-09-14 (MANIFESTO §220.2): 4 núcleos · 8 GB · monitor de 60 Hz · janela 2560 px — as duas cenas seguram a taxa do monitor (16,7–17 ms por quadro com e sem a camada) e o único custo é UM quadro isolado de 50–67 ms por rolagem de 3 s, [inferência] no primeiro desenho; nenhum custo contínuo em cinco portes de máquina — sempre sob a régua obrigatória (MA7). E o site (§47) recebe a camada:
tela-site.html v0.3 com casca com luz, cabeçalho em vidro e ação primária em metal (a variante que ele viu nas folhas F10.5 e MA-P2), tinta de marca em text-brand-strong (§5-g: text-link caiu a 3,83 e 4,29 sobre a luz e o vidro; linha de base sem a camada 84/84), régua RC 84/84 nos dois temas, suite-site 66/66, render-site 23/23, cabeçalho fixo medido em y = 0 a 1440 e 390 px. Mudam o cabeçalho, o MA12, o §93.6 e a linha do §47.Gate F11.1 APROVADO, 2026-09-14 — veredito dele, verbatim (MANIFESTO §220.1): "V-F11.1 tabela SH17: confirmo · V-F11.2 login: aprovo · veto: nenhum". A tabela do SH17 (§46.4) deixa de ser "aplicado sem pergunta —…
texto inteiro da versão
Gate F11.1 APROVADO, 2026-09-14 — veredito dele, verbatim (MANIFESTO §220.1): "V-F11.1 tabela SH17: confirmo · V-F11.2 login: aprovo · veto: nenhum". A tabela do SH17 (§46.4) deixa de ser "aplicado sem pergunta — exposto a veto" e vira decisão dele; o login v0.5 com a logo vertical (§83) está aprovado e a
MA-P3 fecha. Só o §46.4 e este cabeçalho mudam.F11.1 + MR-P18, 2026-09-14 — nasce o SH17 no §46.4: NO PRODUTO, TODA TELA DE APLICAÇÃO VIVE DENTRO DO SHELL — o shell é a casca e o gabarito A1–A20 é o conteúdo; a referência de um gabarito publicada sem casca (raiz…
texto inteiro da versão
F11.1 + MR-P18, 2026-09-14 — nasce o SH17 no §46.4: NO PRODUTO, TODA TELA DE APLICAÇÃO VIVE DENTRO DO SHELL — o shell é a casca e o gabarito A1–A20 é o conteúdo; a referência de um gabarito publicada sem casca (raiz
tela, CP28) é decisão de bancada, nunca de produto. Tabela dos 16 gabaritos com "referência traz a casca" (medido no disco) × "no produto" (decisão) — A4 painel, A13 documento e A18 configurações ficam DENTRO; A19 login e A5 site, FORA. Motivo: em 2026-09-14 a sessão do ERP construiu "Configurar funil" pelo A18 e a tela saiu sem rail — ele reprovou ("tem certeza que as telas sao assim? o quadro aprovado do ERP tem uma rail a esquerda"); o §86 não citava o §46 e nada no canon dizia a frase. Notas de casca nos §48/§83/§86/§88. E a MR-P18 (gate MA-P3, observação dele no login): a §83 passa a registrar a tela v0.5 — logo VERTICAL oficial por tema no lugar de símbolo + nome escrito, classes dos <style> de SVG prefixadas (o <style> de SVG embutido é global e o fill branco do escuro apagava o turquesa do claro) — suíte 24 PASS (AU-12 reescrito, AU-16 e AU-17 novos). Registro: MANIFESTO §218 e §219.LC-12 FECHADA (MANIFESTO §222) — o índice por necessidade cobre o acervo inteiro.
texto inteiro da versão
LC-12 FECHADA (MANIFESTO §222) — o índice por necessidade cobre o acervo inteiro. Ordem dele: "pode compactar. depois siga para a LC-12". As 135 frases "quando consultar" dos oito canônicos restantes (sobreaseed 15 · seed-dataviz 12 · seed-email 17 · seed-praticas 25 · seed-ds-roadmap 17 · mapa-cobertura-ds 24 · inventario-pecas-ds 13 · plano-producao-pecas 12) entram no seed-consulta.json, escritas para quem chega com uma tarefa (o que a seção responde) a partir dos títulos e da abertura de cada seção; os documentos históricos (mapa, inventário, plano, registros de sessão) dizem na frase que são origem, não regra viva. CI-10: 289 de 289 fatias com frase, 12 de 12 canônicos completos, 0 chaves órfãs; gen-camada-ia.py --checar 307 de 307 idênticas. De quebra, titulo_curto() deixou de cortar em todo " · ": só corta quando o resto tem cara de processo — "Missão · Visão · Valores · Propósito" (sobreaseed §04) virava "Missão" no _index.md, o único dos 289 ferido. Nada muda no canon; só o índice de consulta e as vistas geradas.Gate MA-P2 aprovado (MANIFESTO §221) — MA-P2 FECHA e o site recebe a camada de material.
texto inteiro da versão
Gate MA-P2 aprovado (MANIFESTO §221) —
MA-P2 FECHA e o site recebe a camada de material. Veredito verbatim: "V-MA2.1 MA-P2: fechar · V-MA2.2 site: a · veto: nenhum". Componentes v1.56: o MA12 do §93 deixa de esperar a medição e escreve o piso de campo (4 núcleos · 8 GB · 60 Hz · 2560 px: taxa do monitor mantida, um quadro isolado de até 67 ms por rolagem); §93.6 e a linha do §47 atualizados. gen-site.py v0.3 emite a camada pelo material_bloco.py (casca com luz, cabeçalho em vidro, ação primária em metal — as três peças da variante que ele viu nas folhas F10.5 e MA-P2) e o <html> declara data-material; a régua RC achou 2 textos de tinta de marca abaixo do piso no claro DEPOIS da camada (a linha de base do HEAD passava 84/84) — text-brand-strong pela §5-g, como na MA-P3; placar final RC 84/84 nos dois temas, 15 de 15 telas com data-material no rito; suite-site 66/66; render-site 23/23 depois de a régua aprender que data: URL não é terceiro (o grão da casca; cobaia com um terceiro real reprova nos 4 asserts); cabeçalho fixo medido em y = 0 a 1440 e 390 px, nenhuma rolagem lateral; evidência fresca nos dois temas em evidencia-ma-p2/. O registry (LEIA-ME e o comentário do seed-material.css) e a página /material/ dizem que o vidro fora do chrome está liberado; a nota "sem a camada" da /material/ passa a exigir motivo por tela (aborta sem). Aberto depois desta: CT-P9, LC-11, LC-12, SH-P9, HV-P4, LC-01/02/04/05, PB-P9, PB-P11.Gate F11.1 aprovado (MANIFESTO §220.1) — MA-P3 e F11 FECHAM; as cinco medições da MA-P2 nas máquinas da empresa entram (§220.2) e a MA-P2 vai a gate (§220.4).
texto inteiro da versão
Gate F11.1 aprovado (MANIFESTO §220.1) —
MA-P3 e F11 FECHAM; as cinco medições da MA-P2 nas máquinas da empresa entram (§220.2) e a MA-P2 vai a gate (§220.4). Veredito verbatim: "V-F11.1 tabela SH17: confirmo · V-F11.2 login: aprovo · veto: nenhum" — componentes v1.55 (o §46.4 registra a confirmação). MA-P2: sete medições em cinco portes; nas cinco máquinas da empresa as duas cenas seguram os 60 Hz do monitor (16,7 ms médio e p95 com e sem); o custo é um quadro isolado de 50–67 ms nas de 4 núcleos · 8 GB a 2560 px, provado único pela contagem de quadros; a posição na rolagem não conferida. A bancada passa a dizer em que quadro caiu o pior intervalo e ganha o "como ler" (o quadro médio é o teto do monitor, não o custo). Reprodução local com CPU estrangulada: sustenta "primeiro desenho da rolagem" mas exagera (custo contínuo que as máquinas dele não têm) — proxy, não campo (§220.3). Folha do gate MA-P2 v1: V-MA2.1 (fechar e liberar vidro fora do chrome, MA12 — recomendação: fechar) · V-MA2.2 (o site: a) agora · b) depois de medir num celular · c) manter — recomendação: b) · veto. Nada do §93 muda antes do veredito.F11 ABERTA (MANIFESTO §219) — consumo do DS por agentes de dentro de um consumidor; veredito do gate MA-P3 registrado (§218); MR-P18 fechada.
texto inteiro da versão
F11 ABERTA (MANIFESTO §219) — consumo do DS por agentes de dentro de um consumidor; veredito do gate MA-P3 registrado (§218);
MR-P18 fechada. Ele perguntou se a organização do DS era boa o bastante para IA depois de a sessão do ERP construir uma tela sem o shell; a análise da transcrição achou três causas (porta do ERP apontando para um canon concorrente; gabaritos publicados sem casca sem dizer que é bancada; skill apagada pela compactação) e ele mandou executar. Feito: SH17 no §46.4 (componentes v1.54) com a tabela dos 16 gabaritos e a /telas/ remedindo a casca; CP28 (composição v2.3); índice por necessidade (seed-consulta.json → fatias, _index.md, llms.txt com regra de consulta, CI-10, 154 de 288); skill com o passo 0 "shell primeiro" e "por tarefa"; porta do ERP (commit a3e015a na dev do ERP); marca do login refeita (logo vertical, AU-12/16/17, 12.ª guarda guarda-marca-embutida.py, contrato ME); LC-11 e LC-12 na fila. Gate F11.1: V-F11.1 (tabela SH17) e V-F11.2 (login).MA-P3 EM GATE (MANIFESTO §217) — as seis telas de referência sem gerador ganharam gerador, e cinco receberam a camada de material.
texto inteiro da versão
MA-P3 EM GATE (MANIFESTO §217) — as seis telas de referência sem gerador ganharam gerador, e cinco receberam a camada de material. Ordem dele: "siga pra sua proxima etapa"; a próxima, escolhida pela sessão e exposta a veto, foi a MA-P3 (última fronteira do §93, MA12). Porte: cada HTML aprovado em 2026-08-23 virou molde + gen-tela-<x>.py (bloco de tokens do gêmeo pelo tokens_bloco, sentinelas, versão em fonte única); a primeira geração mudou 1 linha por tela (o selo do bloco, v1.20 → v1.26 — os 300 valores já eram idênticos ao gêmeo vivo), quebras de linha mistas preservadas, duas gerações com MD5 igual. Material: atividade v0.2, busca v0.3, onboarding v0.3 (casca, topbar em vidro, rail em metal, botão primário em metal), configurações v0.2 (casca, navegação lateral em vidro, botão em metal), autenticação v0.4 (casca no palco, botão em metal); documento v0.1 fica sem (C25: o canvas é a tela; MA3). Régua RC: a primeira rodada deu 7 FAIL e a linha de base no HEAD explicou 10 deles como dívida pré-existente (tinta de marca sobre brand-subtle, 4,28) — corrigida com text-brand-strong (§5-g); o avatar claro saiu do metal (3,63); o item ativo do rail das três telas passou do véu branco de agosto à pílula clara do SH15-b. Final: 0 FAIL em 14 de 14 telas, dois temas; seis suítes jsdom com o placar de agosto; guardas transversais sem FAIL. Nasce CT-P9 (o par no acervo inteiro). Marcador da F10 corrigido para ✅ (estava ⚪ com as seis fases fechadas). Folha do gate MA-P3: V-P3.1–V-P3.5 + veto.PR-P7 FECHADA (MANIFESTO §216.2) — a unicidade de código de pendência vira a 11.ª guarda do rito.
texto inteiro da versão
PR-P7 FECHADA (MANIFESTO §216.2) — a unicidade de código de pendência vira a 11.ª guarda do rito. guarda-codigo-pendencia.py (contrato UC): UC-1 nenhum código XX-Pn nasce em duas seções de topo do MANIFESTO sem colisão registrada (a forma "nasceu como X" do §214.2 aceita a evidência mantida); UC-2 nenhum código com duas linhas nesta fila; UC-3 por série o maior em uso e o próximo livre — a linha que a sessão lê antes de escrever um código; UC-4 cobertura (791 de 2.157 arquivos rastreados, 296 códigos em 76 séries). Provada nas duas colisões reais lidas do git (--cobaia: VT-P4 em d32f465, MR-P14 em 1bfb9e0 — reprova exatamente o código de cada uma) e numa negativa sintética; HEAD passa. Dois consertos do instrumento antes do placar (a linha de versão do MANIFESTO recapitula os "nasce" e não conta; "NASCEM: A · B · C" conta a cadeia inteira). MA-P2: primeira medição dele (máquina de porte de desenvolvimento, custo indistinguível) registrada no §216.1; ele mede hoje em outras máquinas. Nada muda no material, nas telas nem na vitrine.2026-09-13
F10.6, 2026-09-13 — a camada de material (§93) chega a quem consome o DS por três caminhos gerados da mesma fonte: o registry ganha o item @seed/material (classes .seed-mat- emitidas pelo materialbloco.py, a mesma…
texto inteiro da versão
F10.6, 2026-09-13 — a camada de material (§93) chega a quem consome o DS por três caminhos gerados da mesma fonte: o registry ganha o item
@seed/material (classes .seed-mat-* emitidas pelo material_bloco.py, a mesma receita das nove telas), a vitrine ganha a página /material/ (a regra byte a byte, a amostra viva montada só com o registry, controles que mexem nos tokens ao vivo, as telas que carregam a camada medidas no disco e a bancada de custo da MA-P2) e a skill seed-ds herda o passo do material no modo código. A bancada mediu nesta máquina de desenvolvimento (8 núcleos, 16 GB, Chrome 153): custo do vidro indistinguível até 240 cartões — 8,3 a 8,9 ms por quadro com e sem a camada; a medição em máquina de CAMPO continua sendo o que libera vidro fora do chrome (MA12). §93.6 atualizado. Registro: MANIFESTO §213.Gate F10.5 APROVADO, 2026-09-13 — veredito dele, verbatim (MANIFESTO §212): "V-M5 chat: aprovo · V-M5 detalhe: aprovo · V-M5 gantt: aprovo · V-M5 lista: aprovo · V-M5 quadro: aprovo · V-M5 referencia: aprovo · V-M5…
texto inteiro da versão
Gate F10.5 APROVADO, 2026-09-13 — veredito dele, verbatim (MANIFESTO §212): "V-M5 chat: aprovo · V-M5 detalhe: aprovo · V-M5 gantt: aprovo · V-M5 lista: aprovo · V-M5 quadro: aprovo · V-M5 referencia: aprovo · V-M5 tabela: aprovo · V-M6 luz do topo do rail: 8 · V-M7 site: a · veto: nenhum". As sete telas de aplicação saem de "em gate"; a luz do topo do metal do rail fica em 8 % (tokens v1.26, agora decisão dele); o site (§47) fica SEM a camada até a medição de GPU (
MA-P2), por veredito. Nove telas com material, todas na régua RC do rito. Nenhuma mudança de gerador nesta edição.F10.5, 2026-09-13 — a camada de MATERIAL (§93) entra nas sete telas de referência com gerador que faltavam: chat §55, detalhe §49, gantt §58, lista §92, quadro §57, referência e tabela §40 — pelo mesmo módulo único da…
texto inteiro da versão
F10.5, 2026-09-13 — a camada de MATERIAL (§93) entra nas sete telas de referência com gerador que faltavam: chat §55, detalhe §49, gantt §58, lista §92, quadro §57, referência e tabela §40 — pelo mesmo módulo único da F10.4 (
material_bloco.py), com as peças que o decisor marcou em V-3 e que existem em cada tela (casca com luz, barra superior e sidebar em vidro, rail em metal, avatar e botão de enviar em metal, número das faixas de estatística com brilho; conteúdo opaco por MA3). A régua de contraste rasterizado (RC) achou o que a primeira aplicação não podia ver: 12 rótulos brancos do alto do rail abaixo do piso (3,25–4,27) sob a luz do topo do metal — o shell passara na F10.4 porque o item ATIVO, com pílula clara, ocupa a primeira posição do rail; o próprio shell sem a pílula reprova igual (3,62). Correção medida nos tokens v1.26 (a luz do topo do metal-sheen cai de 30 % para 8 %; 18/18 medições passam, pior 4,69), aplicando a regra MA2 que já existia. Três instrumentos aprenderam a camada com o sinal certo (RAIL-02 da suite-composicao, SH1-c da guarda-colisao, rota 1 do contraste-composicao); §93.3–93.7 atualizados. Nove telas com material; a tela do site (§47) foi renderizada como variante e aguarda o veredito dele (V-M7). Estado: entregue em gate (F10.5). Registro: MANIFESTO §211.SH-P10 FECHADA, 2026-09-13 — veredito dele, verbatim: "SH-P10: b-tirar-do-rail". O SH5 do §46 ganha a redação por região: no RAIL a marca do item ativo que sobrevive ao cinza é a pílula clara (turquesa-100 sobre o…
texto inteiro da versão
SH-P10 FECHADA, 2026-09-13 — veredito dele, verbatim: "SH-P10: b-tirar-do-rail". O SH5 do §46 ganha a redação por região: no RAIL a marca do item ativo que sobrevive ao cinza é a pílula clara (turquesa-100 sobre o gradiente escuro — luminância, 5,31/7,87) mais o peso; a barra lateral de 3 px é da SIDEBAR, onde o ativo é só um fundo quase igual ao papel. A regra
::before saiu dos 8 moldes com rail (shell + chat, detalhe, gantt, lista, quadro, referência, tabela), as 8 telas foram regeradas byte-idênticas, a suite-shell (SH5-04) e a suite-composicao (PX-01/PX-02) passaram a provar a AUSÊNCIA da barra e a presença da pílula. Registro: MANIFESTO §209.§93 estável, 2026-09-13 — veredito dele no gate F10.4 (MANIFESTO §207, verbatim: "V-M1 shell: aprovo", "V-M2 painel: aprovo", "V-M3 metal do rail: 1", "V-M4 sidebar: vidro", "veto: nenhum"). A sidebar entra na receita…
texto inteiro da versão
§93
estável, 2026-09-13 — veredito dele no gate F10.4 (MANIFESTO §207, verbatim: "V-M1 shell: aprovo", "V-M2 painel: aprovo", "V-M3 metal do rail: 1", "V-M4 sidebar: vidro", "veto: nenhum"). A sidebar entra na receita de vidro (MA1; fecha a MA-P4), o rail fica no valor do token (§93.5) e a §93 sai de emitido · em gate para estável. Do mesmo gate nasce a SH-P10 no §46: ele apontou a barra vertical branca ao lado do item ativo do rail ("essa barra nao deveria estar ali") — é a marca de ativo do SH5, decisão registrada, medida e levada a ele com as duas saídas renderizadas; não foi mexida.MR-P17 FECHADA — o subset seed ganha a faixa de setas e sinais e passa a ter gerador (§4.5).
texto inteiro da versão
MR-P17 FECHADA — o subset seed ganha a faixa de setas e sinais e passa a ter gerador (§4.5). Veredito dele na folha "Fila do DS — decisões rápidas", verbatim: "D-2 (MR-P17, subset): A" = ampliar com o gerador e o re-render (MANIFESTO §208). Nasce 06-validacao/geradores/gen-subset-fontes.py: repertório declarado faixa a faixa (a base de 2026-08-27 lida do cmap e fixada; mais os 25 pontos de código de U+2190–U+22FF que a Montserrat possui), saída determinística (recalcTimestamp=False; duas gerações, mesmo MD5; --checar 7 de 7), nome interno conferido (herança do conserto de 2026-09-08). Custo medido: Montserrat +760 a +852 B por peso (400: 25.928 → 26.728 B); JetBrains Mono +892 a +964 B. As 12 famílias de peça que embutem o subset (agenda, capas de rede, comprovante de ponto, destaques do Instagram, favicon, frota, one-pagers, pasta A4, placa de instalação, portfólio, roll-up, uniforme) foram regeradas pelos geradores e a evidência PNG re-renderizada e conferida (guarda-peca-fresca). A regra do §4.5 (tela usa o subset; impresso e PDF usam a TTF completa) continua.O item 7 do §6 (Mercado Livre) é CONFIRMADO por ele
texto inteiro da versão
O item 7 do §6 (Mercado Livre) é CONFIRMADO por ele — folha "Fila do DS — decisões rápidas", D-1 = A ("mantém como está"), registrada verbatim no MANIFESTO §208. A nota "exposto a veto" vira nota de confirmação; o escopo do serviço segue não registrado porque o campo opcional ficou em branco.
PR-P6 FECHADA (MANIFESTO §215) — o rito de fechamento passa a gravar um SELO e a publicação recusa commit sem selo.
texto inteiro da versão
PR-P6 FECHADA (MANIFESTO §215) — o rito de fechamento passa a gravar um SELO e a publicação recusa commit sem selo. O selo é a árvore do índice provada pelas dez guardas (git write-tree), gravada em .git/seed-rito-selo no fim de toda rodada local verde do fechar.sh e apagada no início de cada rodada; o deploy/publicar.sh compara com a árvore do commit a publicar antes de abrir qualquer ssh e sai 1 sem selo ou com selo de outra árvore — sem variável de contorno, de propósito. Mecânica nascida do incidente c30cb3b (§213.11): a cadeia com ; publicou sem o rito; agora, mesmo que a cadeia falhe, o servidor não recebe árvore não provada. Nada muda no material, nas telas nem na vitrine.VT-P5 FECHADA por veredito dele (MANIFESTO §214) — o rótulo "Design System" sai do cabeçalho da vitrine.
texto inteiro da versão
VT-P5 FECHADA por veredito dele (MANIFESTO §214) — o rótulo "Design System" sai do cabeçalho da vitrine. Resposta dele no chat, verbatim: "VT-P4: a". A pendência tinha nascido como VT-P4 no §213.6 e o código já era da publicação incremental (§165.4, 2026-09-06): renumerada VT-P5 (§214.2), com o §213.6 mantido como evidência do que ele leu. Nasce a PR-P7 (guarda de unicidade de código de pendência no rito), porque é a segunda colisão da mesma classe em cinco dias (MR-P14, 2026-09-08). Mudança: o gen-vitrine.py deixa de emitir o rótulo e o vitrine.css perde as regras dele; navegação em UMA linha de 1280 a 1920 px (medição no §214.4). Achado de passagem (§214.5): o censo de rolagem horizontal das 360 páginas do sitemap, com o CSS do HEAD, achou ONZE rolando de lado a 390 px (a pior, /pedidos/, em 682 px) — quatro regras de CSS (overflow-wrap no <code>, no cartão e no corpo; duas colunas de cartões abaixo de 960 px) levam a 360 de 360, e nasce a décima guarda do rito, guarda-rolagem.py (contrato RL), que mede todas as páginas a 390 e 1366 px, na bancada e em produção. Aplicado sem pergunta, exposto a veto: as quatro regras de CSS; e as linhas deste log estavam em três ordens ao mesmo tempo (2.39–2.51 crescente no topo, 2.60→2.52 decrescente, 2.38→1.0 decrescente) — reordenadas numa ordem só, a mais nova primeiro, sem mudar uma letra de nenhuma linha (conferido por multiconjunto). Publicação (§214.9): o modo incremental do publicar.sh caiu com 396 caminhos num git archive só ("Argument list too long" do Windows) sem tocar o servidor; passa a empacotar em lotes de 40 e a viajar num tar único por uma sessão ssh, ensaiado com a lista real antes de commitar.Incidente do fechamento da F10.6 e a PR-P6 (MANIFESTO §213.11).
texto inteiro da versão
Incidente do fechamento da F10.6 e a
PR-P6 (MANIFESTO §213.11). O commit c30cb3b subiu e foi publicado SEM o rito: a cadeia estava com ; depois do rito, e o script de registro caiu (um % literal num texto formatado por %, a lição do dia anterior repetida) depois de já ter gravado componentes v1.53 e roadmap v2.59 — as fatias da camada de IA ficaram velhas em produção por minutos ("10 de 12 canônicos reconstituem") até o commit seguinte rerodar o rito. Nasce a PR-P6: o rito grava um selo com o HEAD que provou e o publicar.sh recusa HEAD sem selo — mecânica, não lembrete. Nada muda no material nem nas telas.F10.6 FECHADA (MANIFESTO §213) — a camada de material chega a quem consome o DS, pelos três caminhos, gerados da mesma fonte.
texto inteiro da versão
F10.6 FECHADA (MANIFESTO §213) — a camada de material chega a quem consome o DS, pelos três caminhos, gerados da mesma fonte. Ordem dele: "pode abrir a F10.6". Registry: 4.º item
@seed/material — src/styles/seed-material.css com as classes .seed-mat-* emitidas pelo material_bloco.py (a mesma receita das nove telas, com nome de classe no lugar do seletor de molde), sob html[data-material="vidro-metal"], só var(--seed-*), dependente de @seed/tokens; LEIA-ME com a tabela de classes, onde não vai (MA3/MA12) e a obrigação de medir (MA7); guarda-registry conta 4 itens e ganha o RG-8 (interruptor, só tokens, content, dependência). A linha desta fase dizia "@seed/theme ganha a camada": medido na implementação, o tema do shadcn só carrega apelidos de cor — a forma certa é o item próprio. Vitrine: /material/ — a regra (§93 e §3d dos tokens, byte a byte), a amostra viva montada SÓ com as classes do registry (a página é a primeira consumidora do item; o <html> dela leva data-material), controles que mexem nos tokens ao vivo (o var() resolve no mesmo elemento, então funciona no <html>), a lista das telas com a camada medida no arquivo, e a bancada da MA-P2 (window.seedMatMedir(n, ms)); pagina() ganhou html_attrs/extra_head; a página de cada tela diz se carrega a camada; "Material" entrou na navegação. Skill: passo do material no modo código (herdado por geração; registry.md e mapa-do-canon.md já vinham). Medição da bancada nesta máquina de desenvolvimento (8 núcleos, 16 GB, Chrome 153 com janela e GPU): 8,3–8,9 ms por quadro com e sem a camada até 240 cartões; a MA-P2 fica aberta com o instrumento pronto — falta a máquina de campo. Achado pré-existente, medido: a navegação do cabeçalho da vitrine quebra em duas linhas acima de 1400 px — com 11 itens em produção e com 12 agora — porque o rótulo "Design System" só some abaixo de 1400 px e o contêiner é fixo em 1240 px: acima de 1400 nunca cabe (medido de 1401 a 1680 px: duas linhas com o rótulo, uma sem). Vira VT-P4 (MANIFESTO §213), com as saídas e o custo para ele. Aberto: MA-P2 (campo), MA-P3 (6 telas), VT-P4, SH-P9, HV-P4, LC-01/02/04, PB-P9, PB-P11, LC-05.Gate F10.5 aprovado (MANIFESTO §212) — a F10.5 vira ✅; F10.1–F10.5 fechadas.
texto inteiro da versão
Gate F10.5 aprovado (MANIFESTO §212) — a F10.5 vira ✅; F10.1–F10.5 fechadas. Veredito verbatim: "V-M5 chat: aprovo · V-M5 detalhe: aprovo · V-M5 gantt: aprovo · V-M5 lista: aprovo · V-M5 quadro: aprovo · V-M5 referencia: aprovo · V-M5 tabela: aprovo · V-M6 luz do topo do rail: 8 · V-M7 site: a · veto: nenhum". Aplicado: nenhum gerador muda (as telas ficam como o commit 3fef650 as gerou); a luz do topo do metal do rail fica em 8 % (tokens v1.26, agora decisão dele; a alternativa 0 % descartada); o site (§47) fica sem a camada até a medição de GPU (
MA-P2) — quando ela fechar, a pergunta volta com o número; os sete itens expostos a veto ficam. Componentes v1.52. Próximo: F10.6 (vitrine /material/, @seed/theme, skill) e MA-P2; MA-P3 espera o gerador das seis telas. Aberto fora da F10: SH-P9, HV-P4, LC-01/02/04 (fila sem prazo), PB-P9, PB-P11, LC-05.F10.5 entregue em gate (MANIFESTO §211) — a camada de material entra nas sete telas de aplicação que faltavam, e a régua acha o ponto cego da primeira aplicação.
texto inteiro da versão
F10.5 entregue em gate (MANIFESTO §211) — a camada de material entra nas sete telas de aplicação que faltavam, e a régua acha o ponto cego da primeira aplicação. Ordem dele: "pode abrir a F10.5". Os sete geradores (
gen-tela-chat/detalhe/gantt/lista/quadro/referencia/tabela.py) passam a emitir a camada pelo módulo único (material_bloco.receita + completar + exigir), com as peças de V-3 que existem em cada tela; conteúdo opaco (MA3); moldes com data-material; regeneração byte-idêntica. Achado da régua RC: 12 rótulos brancos do alto do rail em 3,25–4,27 (6 telas × 2 temas) sob a luz do topo do metal-sheen — o shell passara na F10.4 porque o item ativo, com pílula clara, ocupa a primeira posição (provado: o shell sem a pílula reprova em 3,62). Tokens v1.26: a luz cai de 30 % para 8 % (some a 18 % da altura); candidatos medidos nas 8 telas × 2 temas (0 % → pior 5,32; 8 % → pior 4,69); ficou o 8 %, aplicando a MA2 que já existia, exposto a veto com a alternativa renderizada. Placar final: 18/18 medições, nenhum texto abaixo do piso. Três instrumentos por cor declarada aprenderam a camada (linha de base no HEAD medida antes): suite-composicao RAIL-02 exige o anel do estado de cada peça (vidro → glass-border); guarda-colisao SH1-c conta o nó de texto só no eixo que transborda (39.º refinamento); contraste-composicao compõe o gradiente do metal sobre a cor opaca (31.º) — antes lia o canvas fora do círculo do avatar, 1,09 falso. Achado pré-existente consertado no caminho: os moldes do gantt e do quadro carregavam o sentinela do bloco de tokens 3× e 2× (o :root saía repetido na tela gerada); ficou um. Contagens corrigidas nesta linha da F10.5: são 8 telas com gerador no lote 2 (o site inclusive) e 6 sem gerador, não 7 e 7. Faixas de estatística em vidro foram renderizadas e descartadas sem gate (vidro sobre conteúdo opaco não muda pixel). O site (§47) vai ao gate como pergunta (V-M7), renderizado com e sem a camada; o gerador não o emite até o veredito. Suítes: composicao 33·0/32·0/27·0 (= HEAD), detalhe 73·0, gantt 43·0, quadro 35·0, container 66·0, colisão 36·0 (nove telas) e 212·0 (acervo), contraste-composicao 18·0, forced-colors 18·0, valor-gêmeo 9·0, tinta-marca 2·0, tipografia-viva 9·0, barra-fixa 9·0, paridade 110·0; HV-P4 segue pré-existente (igual ou melhor que o HEAD). Aberto: gate F10.5 (V-M5 sete telas · V-M6 luz do topo · V-M7 site · veto), F10.6, MA-P2, MA-P3 (6 telas), SH-P9, HV-P4.Bloco D-1..D-4 executado (MANIFESTO §208 o veredito, §210 a execução).
texto inteiro da versão
Bloco D-1..D-4 executado (MANIFESTO §208 o veredito, §210 a execução). D-1: o item 7 do §6 do
sobreaseed.md (Mercado Livre) passa de "exposto a veto" a confirmado por ele (A = mantém como está; escopo do serviço segue não registrado). D-2: MR-P17 fecha — nasce gen-subset-fontes.py (repertório declarado, saída determinística, --checar 7 de 7), o subset seed ganha a faixa de setas e sinais nas duas famílias (+760 a +964 B por peso), as 12 famílias de peça que o embutem foram regeradas pelos geradores e a evidência PNG re-renderizada; marca v5.46 §4.5. D-3: banco-tokens.html removida pelo processo (tabela aprovada; VT-P2 fecha; composição v2.2 tira a linha do mapa de nomes). D-4: LC-01, LC-02 e LC-04 ficam na fila sem prazo, por decisão dele.SH-P10 FECHA — a barra do item ativo sai do rail (MANIFESTO §209).
texto inteiro da versão
SH-P10 FECHA — a barra do item ativo sai do rail (MANIFESTO §209). Veredito dele verbatim: "SH-P10: b-tirar-do-rail". O SH5 do §46 passa a ser por região (sidebar: barra + peso · rail: pílula clara + peso), a regra ::before saiu dos 8 moldes com rail, as 8 telas foram regeradas byte-idênticas e as duas suítes que a sondavam (SH5-04, PX-01/PX-02) passaram a provar a AUSÊNCIA da barra e a presença da pílula. Componentes v1.50.Gate F10.4 aprovado (MANIFESTO §207) — a F10.4 vira ✅ e a §93 vira estável (v1.49).
texto inteiro da versão
Gate F10.4 aprovado (MANIFESTO §207) — a F10.4 vira ✅ e a §93 vira
estável (v1.49). Veredito verbatim: "V-M1 shell: aprovo · V-M2 painel: aprovo · V-M3 metal do rail: 1 · V-M4 sidebar: vidro · veto: nenhum". Aplicado: a sidebar entra na receita de vidro do shell (gen-shell.py, regeneração byte-idêntica; régua RC 71/71 nos dois temas; suite-shell 72·0, render-shell 34·0) — MA-P4 FECHA; o rail fica em --seed-mat-metal: 1. Achado dele fora do escopo, medido antes de mexer: a barra vertical do item ativo do rail é a marca do SH5 (decisão registrada, 8 moldes, sondada em pixel pela suite-composicao) — nasce SH-P10 com as duas saídas renderizadas em cor e em cinza e o custo de cada uma; nada foi mexido. Aberto: SH-P10, F10.5, F10.6, MA-P2, MA-P3, SH-P9.F10.5 — a camada entra nas sete telas seguintes e a régua corrige a luz do topo do metal do rail.
texto inteiro da versão
F10.5 — a camada entra nas sete telas seguintes e a régua corrige a luz do topo do metal do rail. As sete telas de referência com gerador que faltavam (chat §55, detalhe §49, gantt §58, lista §92, quadro §57, referência, tabela §40) passaram a emitir a camada pelo módulo único
06-validacao/ferramentas/material_bloco.py — fundo com luz, barra superior e sidebar em vidro, rail em metal, avatar (e o botão de enviar do chat) em metal, número das faixas de estatística com brilho onde usa o papel titulo-tela; o conteúdo fica opaco (§93 MA3). A régua de contraste rasterizado (RC) rodou nas nove telas com material, nos dois temas, e achou 12 reprovações em 6 telas, todas no mesmo lugar: o primeiro (às vezes o segundo e o terceiro) rótulo branco do rail sob a luz do topo do --seed-mat-metal-sheen — "Comercial" 3,62 (chat, referência, tabela) e 3,25 (lista), "Obras" 3,99, "Usinas" 3,67/4,27, "Propostas" 3,77 (piso 4,5). Por que a F10.4 não viu: o shell tem o item ATIVO na primeira posição do rail, e a pílula clara com tinta escura cobre exatamente a faixa onde a luz é mais forte (o pior rótulo branco medido lá, "Compras" 4,73, estava na terceira posição); o próprio shell, com a pílula do primeiro item removida por CSS de variante, reprova no mesmo número (3,62). Era ponto cego da medição, e a regra de contraste do metal (§3d e MA2 do §93: o gradiente só vai do token para o lado escuro onde há texto) já proibia a luz ali. Correção: mat.metal-sheen passa de 30 % de branco no topo (6 % a 18 % da altura) para 8 % no topo, transparente a 18 %; o meio neutro e os 34 % de preto embaixo não mudam; --seed-mat-metal segue em 1 (V-M3 dele). Candidatos medidos nas 8 telas × 2 temas: sem luz no topo → 16/16, pior rótulo do alto do rail 5,32; 8 % → 16/16, pior 4,69 ("Comercial", lista, escuro). Ficou o 8 % — o mais próximo do que ele aprovou em V-M1, com margem da mesma ordem que o shell já tinha; a alternativa sem luz vai renderizada à folha do gate F10.5. Supersede declarado na paridade-tokens.py (G1). Nenhum token nasce nem some. Na mesma edição o cabeçalho do §3d deixa de dizer "emitido · aplicação em gate" (o §93 é estável desde 2026-09-13). Registro: MANIFESTO §211.2026-09-12
§93 NOVA, 2026-09-12 — F10.2: MATERIAL, vidro e metal, entra no canon como camada transversal de acabamento (MA1–MA12), no mesmo dia em que a F10.4 a aplica pelos geradores nas duas primeiras telas (shell §46 e painel…
texto inteiro da versão
§93 NOVA, 2026-09-12 — F10.2: MATERIAL, vidro e metal, entra no canon como camada transversal de acabamento (MA1–MA12), no mesmo dia em que a F10.4 a aplica pelos geradores nas duas primeiras telas (shell §46 e painel §48) e a régua de contraste rasterizado (contrato RC) as mede nos dois temas — zero texto abaixo do piso. A seção diz onde vai vidro, onde vai metal, o que fica opaco, como se emite (módulo único
material_bloco.py, nunca CSS copiado), a regra de contraste do metal, a tinta de marca dentro do vidro (text-brand-strong, §5-g), a calibração por peça e as medições da primeira aplicação. Origem: veredito dele V-1 = B em 2026-09-12 (MANIFESTO §204), tokens seed-tokens.md §3d v1.24/v1.25. Na mesma edição: errata E-CF-06 no §46 (a conta de "9 caracteres em 68 px" do SH3 foi medida a 9 px em agosto e o papel micro passou a 11 px na v1.14 — o rótulo ativo a 800 media 71,5 px e vazava 1 px da pílula, MA-P6; conserto no gerador: o rótulo consome o tracking do papel) e nasce a SH-P9 (o shell e o painel pedem peso 800 sem declarar face 800 — negrito sintético do 700).F10.2 fecha e F10.4 é entregue em gate (MANIFESTO §206) — o material entra no canon e nas duas primeiras telas no mesmo dia.
texto inteiro da versão
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.F10.1 e F10.3 fecham (MANIFESTO §205).
texto inteiro da versão
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.Nasce a F10 — Material: vidro e metal (MANIFESTO §204; pesquisa em 09-pesquisa/material-vidro-metal-2026-09-12/).
texto inteiro da versão
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.F10.4 — a camada ENTRA nas duas primeiras telas, e a régua corrige dois valores da v1.24 (mesmo dia).
texto inteiro da versão
F10.4 — a camada ENTRA nas duas primeiras telas, e a régua corrige dois valores da v1.24 (mesmo dia). O shell (§46) e o painel (§48) passaram a emitir a camada pelo módulo único
06-validacao/ferramentas/material_bloco.py (receita por peça, fallbacks extraídos verbatim deste gêmeo, tokens --seed-mat-* medidos, nunca listados à mão), com data-material="vidro-metal" no <html> — e a régua de contraste rasterizado (contrato RC, F10.3) rodou nas duas, nos dois temas. (1) A luz do canvas ESCURO cai: mat.canvas passa de turquesa-400 40 % / turquesa-500 26 % para 26 % / 18 %. Motivo medido: com 40 % o micro-rótulo text-secondary do primeiro KPI do painel, sob vidro a 72 %, media 4,41 no ponto mais quente da luz (piso 4,5); medido em quatro intensidades (40/26 → 4,41 · 34/22 → 4,47 · 30/20 → 4,52 · 26/18 → 4,58) e escolhida a que passa com margem. O alfa do vidro (72 %, V-2 dele) não mudou — a luz era valor do estudo, não veredito. (2) Errata da calibração do metal (§3d): sobrescrever --seed-mat-metal no escopo de um componente não calibra nada — o var() dentro do valor de uma custom property é resolvido onde ela é declarada, não onde é consumida (a régua devolveu os mesmos números em 1, 0,7 e 0,4 até o conserto); a calibração por peça reemite no escopo os tokens que multiplicam pelo botão, com texto lido deste gêmeo (material_bloco.calibracao_metal()). Nenhum token nasce nem some; os valores claros não mudam. Achados da mesma rodada que não mexem em token: a tinta de marca (text-brand/text-link) dentro de cartão de vidro é remapeada para text-brand-strong no escopo do cartão (§5-g: 4,60 só sobre branco puro; sobre o vidro media 4,42–4,49) — regra no seed-componentes.md §93.NASCE A CAMADA DE MATERIAL — vidro e metal (F10.1; §3d).
texto inteiro da versão
NASCE A CAMADA DE MATERIAL — vidro e metal (F10.1; §3d). Para quem lê sem ter visto a conversa: em 2026-09-12 o Rafael disse que as telas feitas com o DS estavam "muito básicas" e pediu pesquisa sobre "liquid Glass metalizado em DS de grandes empresas" com dois exemplos para comparar; a pesquisa (13 fontes; 0 de 8 DS corporativos usam metal em controles — é aposta da casa, e o registro diz isso) e o par de telas estão em
09-pesquisa/material-vidro-metal-2026-09-12/, o veredito verbatim no MANIFESTO §204: V-1 = B (adotar inteira) · V-2 80 % claro, 72 % escuro, 18 px · V-3 tudo menos a sidebar. O que entra: 18 tokens no grupo semantic.mat (--seed-mat-*) — opacidade, desfoque, saturação, borda, especular e duas sombras do vidro; o fundo com luz derivado da rampa turquesa; a intensidade do metal e suas receitas (reflexo vertical, faixa especular, curvatura, ação primária, arestas); o grão; duas durações de micro-movimento — mais dois derivados só do gêmeo (--seed-mat-glass, --seed-mat-glass-filter). Adição pura: nenhum valor anterior muda (G1 da paridade-tokens.py). Os fallbacks são executáveis no gêmeo (sem backdrop-filter, prefers-reduced-transparency, prefers-contrast: more, prefers-reduced-motion): o consumidor não precisa lembrar da media query. O que NÃO entrou, com motivo no §3d: o escovado de 1 px (moiré — achado dele no gate, MA-P5), o 20 % de metal do controle (reação ao moiré, não preferência; calibração por peça na F10.4), os hex de fundo do estudo (não existem na paleta; o canvas é derivado) e um multiplicador de luz. ⚠ Nenhuma tela consome a camada ainda: a aplicação (F10.4) espera a régua de contraste rasterizado (F10.3), porque a folha do gate declarou "não medi" (MA-P1). Alternativas descartadas: (a) estruturar sombra e gradiente no formato DTCG — não expressa inset nem calc(), e o precedente rail.background (v1.11) já grava sintaxe CSS; (b) grupo próprio seed.material fora de semantic — sairia da paridade G2, que só varre semantic.*, e o material É camada de propósito (muda com o tema); (c) fixar o 20 % — fixaria no canon a calibração de um defeito.2026-09-11
MR-P16 FECHADA — a voz da marca ganha parâmetro, escopo e regra de escrita, por gate de ESCUTA (MANIFESTO §203, vereditos verbatim).
texto inteiro da versão
MR-P16 FECHADA — a voz da marca ganha parâmetro, escopo e regra de escrita, por gate de ESCUTA (MANIFESTO §203, vereditos verbatim). Folha com o áudio de referência de agosto embutido e amostras em dois modelos e duas escritas. V-C1: modelo eleven_multilingual_v2 (consistência; o eleven_v3 fica fora). V-C2: toda locução se escreve para ser falada — número, unidade, sigla e endereço por extenso ou soletrados no roteiro; o texto exibido segue a grafia normal. V-C3: os valores moram NA VOZ, no painel — estabilidade 50 % · similaridade 75 % · estilo 0 · speaker boost ativado · velocidade 1,0 — que são exatamente os padrões da API: a voz nunca tinha sido ajustada, e o áudio aprovado saiu deles; "registrar o que existe" era a resposta. V-C4: escopo comunicação + ERP + telefonia/URA ("a Clara vai atender por voz em todos os canais que dermos acesso a ela"), com as fronteiras escritas: tempo real exige gate próprio de modelo, telefone exige a declaração de voz sintética na abertura, base legal é do projeto do canal. V-C5: toda locução publicada registra modelo, parâmetros, semente, roteiro e data (tabela nova no §9-B.3). Medido no caminho: o conector do ElevenLabs desta sessão não expõe parâmetro nem devolve áudio — por isso a rota A.Entra no §6 o item 7 — migração do mercado cativo para o Mercado Livre de energia.
texto inteiro da versão
Entra no §6 o item 7 — migração do mercado cativo para o Mercado Livre de energia. Veredito dele à sessão do site em 2026-09-11, verbatim: "Fazemos migração do cliente que está no mercado cativo de energia para o mercado livre de energia." Repassado ao DS pela sessão do site (P-057 de lá); incorporado como exposto a veto, porque a sessão do DS não ouviu a resposta diretamente. O título da lista deixa de dizer "6 soluções" (contagem em prosa é denominador sem guarda). O que o serviço entrega por dentro segue não registrado e não se inventa em peça.
MR-P16 FECHA por gate de escuta (MANIFESTO §203; marca v5.45; práticas v1.5).
texto inteiro da versão
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.A §19.4 deixa de dizer "provisório": a MR-P16 fechou por gate de escuta
texto inteiro da versão
A §19.4 deixa de dizer "provisório": a
MR-P16 fechou por gate de escuta (marca-seed.md v5.45 §9-B.3, MANIFESTO §203). Parâmetros canônicos na própria voz, roteiro de locução escrito para ser falado, e registro de modelo, parâmetros, semente e roteiro em toda locução publicada.2026-09-10
2026-09-10: três correções medidas — o alvo de toque de 44×44px é regra da SEED, NÃO da WCAG (o piso AA do SC 2.5.8 é 24×24; os 44 são o SC 2.5.5 AAA), e o canon passa a citar a ABNT NBR 17225:2025 ao lado da WCAG 2.2…
texto inteiro da versão
2026-09-10: três correções medidas — o alvo de toque de 44×44px é regra da SEED, NÃO da WCAG (o piso AA do SC 2.5.8 é 24×24; os 44 são o SC 2.5.5 AAA), e o canon passa a citar a ABNT NBR 17225:2025 ao lado da WCAG 2.2 (
PB-P8 fechada); e o exemplo do MK28 sobre o domínio vira história datada, porque o principal passou a servir o site novo.Bloco PB-P7·P8·P9·P10 (MANIFESTO §200) — a F9 está fechada, então isto é fila, não fase.
texto inteiro da versão
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).O bloco PB-P7·P8·P9·P10 — duas fecham, duas ganham instrumento, uma nasce.
texto inteiro da versão
O bloco
PB-P7·P8·P9·P10 — duas fecham, duas ganham instrumento, uma nasce. ✅ PB-P7 FECHADA: as 43 normas que o acervo citava foram lidas uma a uma na ficha oficial do catálogo da ABNT (campo Status, 2026-09-10; 43 de 43 em fonte oficial). O cruzamento com os 701 arquivos rastreados achou 12 normas mortas ainda citadas — as quatro de desenho técnico do selo de prancha (8402, 8403, 10068, 13142 — esta sem sucessora), a de vestimenta contra arco do uniforme (16213, substituída há dez anos), a de sinalização de emergência (13434 → 16820:2022), duas de termografia (15718, 16292 → 16969:2021), a de envelope (12699) e a NBR 5419 na edição de 2015, cancelada em 10/03/2026 pela segunda edição —, 2 com ano errado (9050, 5419-3) e 7 que a ABNT marca "em revisão". A conferência virou a guarda guarda-normas.py (contrato NB, 6 itens), que carrega o censo datado, reprova citação morta nova e avisa da idade do censo; placar de nascimento 0 FAIL · 21 AVISO · 1 NÃO MEDI, batido como declarado, e 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 a pendência destapou o alvo de toque de 44×44 atribuído à WCAG (é regra SEED; o AA é 24×24). ⚠ PB-P9 MEDIDA: o art. 63 § 1º da LBI ("os sítios devem conter símbolo de acessibilidade em destaque", lido no Planalto) está descumprido nos dois sites — o DS tem página e link, nenhum símbolo; o institucional não tem símbolo, página nem a palavra. A arte do símbolo vai ao gate (não se desenha à mão e a casa não tem o arquivo); o institucional vira pendência no projeto do site. ⏱ PB-P10 ganha instrumento: o NB-5 da guarda mapeou 58 citações do item 10.10.1 da NR-10, avisa a 90 dias de 01/06/2027 e reprova depois — provado com --hoje 2027-06-02. ⛔ Nasce PB-P11: corrigir as citações mortas e os anos errados, com revisão do engenheiro responsável, porque a troca não é mecânica. Achado colateral do dia: seed.eng.br passou a servir o site novo (bytes idênticos a novo.seed.eng.br por MD5) — a virada não foi desta sessão.2026-09-09
§47.6, 2026-09-09: nasce o PACOTE GEO do site institucional — MK24 a MK28.
texto inteiro da versão
§47.6, 2026-09-09: nasce o PACOTE GEO do site institucional — MK24 a MK28. O DS especifica e o projeto do site aplica. MK24: a política de robôs é ESCRITA, nomeando cada robô em dois grupos (treino · busca e ação de pessoa), com a lista lida nas páginas oficiais em 2026-09-09 — apareceu o
OAI-AdsBot, ausente da lista de quatro dias antes, e as duas páginas mudaram de endereço. MK25: JSON-LD por TIPO de página, e nenhuma página do sitemap fica sem. MK26: o llms.txt do site é gerado do que o site publica. MK27: descoberta ativa — Bing Webmaster, Search Console e IndexNow, cuja chave tem o nome dela própria. MK28: a régua mede o site SERVIDO, com denominador, e a primeira coisa que confere é o DOMÍNIO — a medição de 2026-09-09 feita em seed.eng.br deu um retrato falso porque naquele dia o domínio principal ainda servia o site ANTIGO. Entregável da F9.4 do roadmap; linha de base medida no §47.6.**O "onde pegar o arquivo oficial" apontava para uma pasta que não existe, em três lugares vivos.
texto inteiro da versão
O "onde pegar o arquivo oficial" apontava para uma pasta que não existe, em três lugares vivos. Achado ao revisar a página
/marca/ recém-publicada, a pedido dele ("revise a pagina"): o §5 mandava buscar os vetores em 02_assets/logos/ e 02_assets/simbolos/, o §5.4 dizia "a fonte segue sendo 02_assets/" e o §6 citava 02_assets/mascote-eeny/ — 02_assets/ é o caminho da estrutura Cowork, anterior a este repositório, e não existe desde a migração de agosto. Pior: o trecho do §5 é exibido na PRÓPRIA página cuja função é ser o lugar de onde se baixa o arquivo. Agora o §5 lista três fontes em ordem — (1) a página https://ds.seed.eng.br/marca/, que é o caminho de quem produz e não exige o repositório; (2) 03-assets/ no repositório, publicado; (3) o espelho no Google Drive, explicitamente em terceiro, com a medição de 2026-08-20 ao lado (0 de 45 imagens carregam sem rede, pendência RD-P1). O §6 aponta a pasta e a página. Não se tocou na linha de changelog de 2026-05-09 que cita 02_assets/: era verdade quando foi escrita, e registro histórico não se reescreve.O seed-design-system.html v1.0 foi REMOVIDO, e as duas linhas deste arquivo que apontavam para ele passam a apontar para o v2.
texto inteiro da versão
O
seed-design-system.html v1.0 foi REMOVIDO, e as duas linhas deste arquivo que apontavam para ele passam a apontar para o v2. Contexto para quem lê sem ter visto: aquele HTML era o design system versão 1 inteiro num arquivo só, e este canônico o citava desde 2026-07 como "fonte de código até o site DS substituí-lo" — o cabeçalho (componentes e ícones) e o §11 ("inventário vivo (…) copiar de lá"). O site DS está no ar desde 2026-09-05, então o motivo declarado expirou; a remoção é o brick F9.6 e o veredito dele no chat foi "pode remover". As duas linhas agora mandam consumir o seed-componentes.md (98 seções, com estados e acessibilidade), as bancadas da vitrine e o registry instalável, e nomeiam os 31 ícones do set NM4 do §45 — contra os 24 do v1, todos redesenhados na linguagem de linha. Nada se perdeu: o mapa das 29 seções do v1 para o v2 está em 08-historico/ds-v1-para-consulta/MAPA-DAS-SECOES-V1-PARA-V2.md, o original de 2026-07-17 fica preservado como evidência na mesma pasta, e o histórico do git guarda o arquivo removido (MD5 9cbdbaf7e7533b666dd5250d0b8cf465).A F9 INTEIRA fecha — 10 de 10 bricks.
texto inteiro da versão
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.
A F9.4 FECHA — nasce o §47.6, o pacote GEO (MANIFESTO §199).
texto inteiro da versão
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.A F9.6 FECHA — o mapa de propagação final está completo.
texto inteiro da versão
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.A revisão que ele pediu da /marca/ achou o pior defeito do dia (MANIFESTO §198.5).
texto inteiro da versão
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.Nasce a página /marca/ — os ativos estavam públicos e invisíveis (MANIFESTO §198).
texto inteiro da versão
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.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).
texto inteiro da versão
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.Dois marcadores de estado mentiam, e o achado veio de responder "o que temos agora?" — segunda vez que este projeto pega a mesma classe
texto inteiro da versão
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.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).
texto inteiro da versão
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.Segunda vez que a ficha passa limpa numa peça com defeito de página — nasce o CP-12 (MANIFESTO §196).
texto inteiro da versão
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.2026-09-08
O subset seed da Montserrat não cobre a seta → (U+2192), e o buraco só aparece na peça pronta.
texto inteiro da versão
O subset
seed da Montserrat não cobre a seta → (U+2192), e o buraco só aparece na peça pronta. Medido ao refazer dois documentos com o DS: o navegador trocou os três caracteres pelo Segoe UI do sistema — sem erro, sem aviso —, e quem achou foi o conferir-peca.py (CP-2) medindo o PDF entregue. Os TTF completos de 03-assets/fontes/ têm o glifo. Regra nova na §4.5: peça de tela usa o subset; peça impressa e documento que vira PDF usam o TTF completo, como o PPTX e o DOCX já usavam. Nasce a pendência MR-P17 — ampliar o subset (custa bytes em toda página do site) ou manter a regra por tipo de peça.A VOZ FALADA da marca entra no canon: nasce o §9-B.
texto inteiro da versão
A VOZ FALADA da marca entra no canon: nasce o §9-B. Pergunta dele, verbatim: "temos uma voz oficial da Clara no EllevenLabs, esse tipo de informação vai no DS?" — vai, e pelo mesmo motivo do logotipo: quem ouve dois vídeos da casa com locuções diferentes ouve duas empresas. Registrada com o dado lido na fonte pelo conector em 2026-09-08: Clara — Voz Oficial SEED, identificador
dAX8JJOgGutSLfY2AkgK, voz clonada (própria da casa, não de biblioteca), idioma pt. O identificador não é credencial e por isso pode viver no canon; a chave da API continua proibida em qualquer conteúdo. Cinco regras: não se cria outra voz nem se usa voz de biblioteca parecida · locução não é obrigatória (o som nasce desligado, e legenda é que é obrigatória) · onde houver locução da marca, é a Clara · voz sintética se declara quando a peça poderia ser tomada por pessoa real falando · e a voz não assina laudo nem dá parecer técnico, porque responsabilidade técnica tem nome e CREA. Nasce a pendência MR-P16: os parâmetros de geração (modelo, estabilidade, similaridade) e o escopo de uso não estão decididos, e a decisão vai a gate de ESCUTA — as mesmas frases com dois ajustes, lado a lado.Nasce o §4.8 — o PISO TIPOGRÁFICO POR CLASSE DE PEÇA, que o canon nunca teve para impresso.
texto inteiro da versão
Nasce o §4.8 — o PISO TIPOGRÁFICO POR CLASSE DE PEÇA, que o canon nunca teve para impresso. A escala da §4.7 é de tela, em px; documento em A4 ficava sem régua, e o conferidor de peça da F9.10 tropeçou nisso ao medir dois PDF da casa (76 e 148 trechos abaixo do menor degrau de tela, sem régua que dissesse se estava certo). Pendência
CP-P1, fechada pelo veredito dele: "pode adotar a tabela acima". Cinco linhas, com a origem de cada uma separada: 12 pt em cláusula contratual é lei (CDC art. 54, § 3º, redação da Lei 11.785/2008 — "não será inferior ao corpo doze"); altura = distância ÷ 200 em peça lida à distância e 15 a 50 mm em sinalização de edificação são norma (ABNT NBR 9050:2015/Em1:2020, 5.2.9.1.3, lida em 2026-09-08 — que também traz sem serifa, caixa alta e baixa, e caixa alta só em advertência); 10 pt em texto corrido de documento e 8 pt como piso absoluto são convenção da casa, tomadas com o custo medido (8 pt custa mexer em 10 % e 15 % dos trechos; 10 ou 12 pt seria redesenho, 74 % a 97 %). O CP-3 do conferir-peca.py passa a reprovar abaixo de 8 pt em impresso, em vez de avisar.A régua refez as duas peças que a originaram — e achou três defeitos MEUS no caminho (MANIFESTO §195).
texto inteiro da versão
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.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.
texto inteiro da versão
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.Fila CP: três das quatro pendências FECHAM por veredito dele no mesmo dia (MANIFESTO §193.8).
texto inteiro da versão
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.F9.10 — a peça PRONTA passa a ser medida (contrato CP), por ordem dele (MANIFESTO §193).
texto inteiro da versão
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 `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).
texto inteiro da versão
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).F9.8, onda 4: as §12 a §14 auditadas — as 14 seções importadas fechadas e a base em seed-praticas.md
texto inteiro da versão
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.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).
texto inteiro da versão
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.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).
texto inteiro da versão
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).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).
texto inteiro da versão
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.A §19.4 passa a apontar a voz oficial da marca.
texto inteiro da versão
A §19.4 passa a apontar a voz oficial da marca. A casa tem uma voz falada própria — Clara — Voz Oficial SEED, registrada no
marca-seed.md §9-B (novo na v5.41) a pedido dele —, e a orientação de locução da §19 dizia apenas "locução gravada depois". Agora diz de quem é a voz, e por quê: voz de marca funciona como logotipo, duas locuções diferentes soam como duas empresas. Junto, duas proibições que vêm do canon: não se usa voz de biblioteca "parecida", e a voz sintética não narra laudo nem parecer assinado — responsabilidade técnica tem nome e CREA (§16). Os parâmetros de geração seguem sem valor canônico (pendência MR-P16), então quem produzir registra os que usou, como provisórios.AS OITO BASES NOVAS DO V-B2 ESTÃO ESCRITAS — a onda 5 fecha, e com ela a F9.8 (pedido dele, verbatim: "continue com a onda 5").
texto inteiro da versão
AS OITO BASES NOVAS DO V-B2 ESTÃO ESCRITAS — a onda 5 fecha, e com ela a F9.8 (pedido dele, verbatim: "continue com a onda 5"). Entram as cinco que faltavam. §19 — Vídeo curto e Reels: ⭐ o Instagram publica a consequência de distribuição, coisa rara — "reels com mais de três minutos não serão recomendados para novos públicos" —, o teto real é de 20 minutos, a capa recomendada é 420 × 654 e não pode ser trocada depois de carregada; YouTube classifica como Short o que for quadrado ou vertical até 3 minutos enviado a partir de 15/10/2024; o LinkedIn aceita de 3 s a 10 min e não suporta mais
.mov; e o TikTok entrega a zona de segurança em .zip, em vez de número. ⛔ E a regra que pega uma empresa de surpresa: música. A Meta proíbe "o uso de música para fins comerciais ou não pessoais (…) a menos que você tenha obtido as licenças apropriadas" (Diretrizes de Música, vigência 26/03/2024) e o TikTok é ainda mais direto — "businesses cannot use the general music library for commercial usage" —, com o agravante de que o som da biblioteca comercial só vale dentro do TikTok. §20 — E-mail de conteúdo: os dois maiores provedores convergiram para o mesmo pacote — Gmail desde 01/02/2024 (SPF ou DKIM para todos; SPF e DKIM e DMARC, alinhamento, cancelamento com um clique e taxa de spam abaixo de 0,3 % para quem passa de 5.000/dia) e Outlook desde 05/05/2025, que recusa com 550 5.7.515. Medido contra o seed-email.md: a casa já tem SPF, DKIM e DMARC no envio.seed.eng.br, e o que falta é o cancelamento com um clique, que vira condição de entrada da trilha de newsletter (adiada de propósito no EM13). §21 — Anúncio pago: ⛔ a política de atributos pessoais da Meta lista "vulnerable financial status" entre os proibidos e diz que perguntar também é afirmar — o exemplo que ela mesma dá é uma pergunta sobre dívida, que é a fórmula clássica do anúncio de energia; a saída que a Meta recomenda é falar do benefício do serviço. E a mecânica: revisão em até 24 horas, e editar criativo, segmentação, otimização ou cobrança dispara nova revisão (lance, orçamento e agenda não). No Google, o anúncio responsivo combina 3 a 15 títulos de 30 caracteres com 2 a 4 descrições de 90 — título que depende do anterior não funciona, o mesmo erro de ordem que a §5 achou no carrossel —, e a política de Deturpação proíbe promessa de resultado, com suspensão de conta. §22 — Artigo e conteúdo longo: post do LinkedIn tem 3.000 caracteres (limite oficial), o artigo e a newsletter não publicam limite ([não conferido]), e a newsletter dispara notificação por push, no app e por e-mail a cada edição. O Google pergunta, na autoavaliação oficial, se "o uso da automação, incluindo a geração de IA, fica evidente para os visitantes" — numa casa que produz com agente, a resposta é autor nomeado e revisão do engenheiro responsável. §23 — Sinalização e impresso de campo: placa de obra é lei (art. 16 da Lei 5.194/1966, lido no texto oficial); ⛔ medição: a NR-26 vigente não menciona cor nenhuma — "vermelho", "amarelo", "verde" e "azul" aparecem zero vez no texto de 2022, que remete às normas técnicas oficiais, então a "tabela de cores da NR-26" que circula não está na NR-26; e a norma diz que "a utilização de cores não dispensa o emprego de outras formas de prevenção", que é a mesma lei do DG17. Entram a régua de legibilidade por distância (1 mm de letra para cada 200 mm), o que se pede à gráfica e o ciclo de vida da peça — etiqueta de circuito desatualizada orienta manobra errada. Pendência nova PB-P10: em 01/06/2027 a sinalização elétrica muda de item na NR-10 (10.10.1 → 10.7.7) e ganha o 10.7.7.1, com conteúdo mínimo para painel e quadro — as peças sinalizacao-nr10 e placa-quadro e a citação do inventario-pecas-ds.md §3.2 têm de ser revistas antes dessa data.As três primeiras bases NOVAS entram — F9.8, onda 5 (veredito V-B2 dele, MANIFESTO §186; pedido verbatim: "continue com a onda 5").
texto inteiro da versão
As três primeiras bases NOVAS entram — F9.8, onda 5 (veredito V-B2 dele, MANIFESTO §186; pedido verbatim: "continue com a onda 5"). Diferente das 14 importadas, estas nascem auditadas. §16 — Documento técnico de engenharia: o acervo já tinha a FORMA (as peças de laudo, memorial, timbrado e selo de prancha) e não tinha COMO SE ESCREVE. Dois achados de primeira mão, lidos no texto oficial em 2026-09-08: ⛔ a Resolução CONFEA nº 1.025/2009, que boa parte do mercado ainda cita para laudo e ART, está revogada pelo art. 77 da Resolução nº 1.137/2023 — e a palavra "laudo" aparece zero vez na resolução nova (medido), que no lugar pede declaração do profissional (art. 59, § 1º); e ⛔ a NR-10 está em transição: o arquivo que o
gov.br serve como nr-10.pdf já é o texto novo, cuja vigência começa em 01/06/2027 (Portaria MTE nº 737, de 29/05/2026, art. 5º) — quem baixa "a NR-10" hoje pelo caminho óbvio leva norma que ainda não vale. No texto novo o gatilho de 75 kW do Prontuário SAI (o 10.15.6 passa a valer para quem integra o SEP ou trabalha em média e alta tensão), contra o 10.2.4 vigente. A seção traz ainda as sete regras de redação (fato separado de parecer, medição com instrumento e data, critério com edição, limite do trabalho declarado). §17 — Fotografia de obra: a foto é prova dentro do documento e afirmação pública fora dele, e as regras não são as mesmas; entram a LGPD (art. 5º, I — imagem de pessoa identificável é dado pessoal) e a Súmula 403 do STJ (uso comercial não autorizado indeniza sem precisar provar prejuízo), a lista de 12 coisas que não podem aparecer no quadro, o par obrigatório contexto + detalhe, o antes/depois do MESMO ponto, o par visual obrigatório da imagem térmica e a remoção de EXIF antes de publicar (a foto de celular leva GPS do cliente dentro do arquivo). §18 — Acessibilidade fora da tela: ⭐ existe desde 11/03/2025 a ABNT NBR 17225 — primeira norma brasileira de acessibilidade digital, alinhada à WCAG 2.2, com "conformidade regular" equivalente ao nível AA (texto lido em 2026-09-08) —, e o art. 63 da LBI já obriga acessibilidade em site de empresa privada, com símbolo de acessibilidade em destaque. A norma para no website: post, Reels, PDF e slide não são alcançados por norma nenhuma, e a casa aplica o mesmo piso por decisão. Texto alternativo lido na fonte oficial do Instagram e do LinkedIn (as duas plataformas escrevem um automático quando você não escreve; nenhuma das duas publica limite de caracteres — o 1.000 e o 300 que circulam são de blog, [não conferido]). Contrato: nasce a quinta etiqueta, [norma], e a contagem de etiquetas sai do texto corrido — o título da §1.0 dizia "três" desde o começo, com quatro na tabela. Pendências novas: PB-P7 (conferir no catálogo da ABNT a edição vigente de cada norma que o acervo cita), PB-P8 (o canon mede acessibilidade pela WCAG; decidir se passa a citar também a NBR 17225) e PB-P9 (conferir se os sites da casa têm o símbolo de acessibilidade que o § 1º do art. 63 exige). Faltam cinco das oito bases novas: vídeo curto e Reels · e-mail de conteúdo · anúncio pago · artigo e conteúdo longo · sinalização e impresso de campo.§12 a §14 auditadas — a onda 4 fecha as 14 seções importadas (F9.8; cobertura da guarda PB de 11 para
texto inteiro da versão
§12 a §14 auditadas — a onda 4 fecha as 14 seções importadas (F9.8; cobertura da guarda PB de 11 para 14 de 14). Pedido dele, verbatim: "continue com a §12 a §14". (1) ⛔ Quatro dos oito tamanhos de texto que a §12 prescrevia não existem no
seed-tokens.json — e o pior é o do corpo: a seção mandava 13 px, o DS tem 14 px (font.size.body); também não existem 20, 30 e 36, onde o DS tem 32 (h2) e 42 (h1). A escala de espaço era um subconjunto apresentado como a escala inteira, proibindo na prática o 20 e o 40, que são legítimos. Ironia que denuncia a origem: a mesma seção listava "spacing arbitrário (13px…)" como anti-padrão enquanto prescrevia 13 px. Correção de raiz, igual à da §7: escala se lê do arquivo de token, pelo nome, nunca se transcreve. A sombra também divergia — preto puro contra a sombra tingida de duas camadas do shadow.raised. (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 — "Indústria Mineradora Vale do Rio Doce S.A. · Itabira/MG · R$ 1.250.000" e "Hospital Santa Casa de Vitória" —, o nome do próprio decisor como cliente pessoa física com CPF de mentira, e um quadro de equipe fictício com quatro cargos que não são a equipe da SEED (sobreaseed.md §2). E nenhum dos dez CNPJ conferidos era válido (0 de 10), numa seção cujo anti-padrão nº 4 exigia dígito plausível. A regra nova é o contrário da antiga: documento em formato correto e 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 em papel nenhum; e todo mockup que sai da casa carrega a marca "dados ilustrativos". Saiu também a tarifa de energia da tabela de grandezas — muda por distribuidora, bandeira e reajuste, e número decorado envelhece sem ninguém ver. (3) ⛔ A §14 tratava o apelido do shadcn como se fosse a fonte do token. A fonte são as 575 variáveis --seed-*; os 32 apelidos (--primary…) são camada derivada, e a regra canônica é o §44 do seed-componentes.md. E o caminho de consumo mudou desde maio: hoje existe registry publicado em https://ds.seed.eng.br/r/ com tokens, theme e fontes. (4) ⚠ Dois canônicos discordam sobre a plataforma do ERP — o roadmap v2.6 traz supersede explícito ("o ERP é Vite/TanStack") e o sobreaseed.md registra "plataforma Lovable" na linha de 2026. Divergência entre canônicos não se resolve em silêncio: nasce a PB-P6. (5) Saíram por falta de fonte: os "~8 minutos contra 45" para montar um formulário, o "shadcn supera MUI e Chakra" de blog de fornecedor, os "20-30 %" de ganho do esqueleto sobre o girador, os "66 %" de abandono por onboarding ruim, os "22,4 % dos desktops em 1366 px" e os "~40 % das violações" pegas por ferramenta. (6) ⚠ Duas seções se contradiziam sobre acessibilidade: a §12 dizia que 44 × 44 px é exigência de AA, e a §14 estava certa — o critério 2.5.8 pede 24 × 24 px em AA, e 44 × 44 é o 2.5.5, de AAA. A §12 foi corrigida, e a casa mantém 44 × 44 por decisão própria, que é mais rigorosa. Também acertado o rótulo dos nove critérios novos da WCAG 2.2: dois em A, quatro em AA, três em AAA — a §14 dizia "6 em AA". Com esta onda, as 14 seções importadas em maio de 2026 estão auditadas — e a regra de versão do §0 deste próprio arquivo ("v1.0 quando todas estiverem") dispara: a base sai do 0.x e vira v1.0. O cabeçalho foi reescrito, porque a frase "ainda não foi auditada seção a seção" passou a ser falsa; a regra de precedência continua, agora com o motivo certo: o canon de marca muda, e orientação escrita hoje diverge dele amanhã sem ninguém ver — foi o que aconteceu com cinco cores e quatro tamanhos de texto entre maio e setembro. Faltam as oito bases novas aprovadas no V-B2, que entram como v1.x.§10 e §11 auditadas — a onda das mensagens (F9.8, onda 3; cobertura da guarda PB de 9 para 11 de 14).
texto inteiro da versão
§10 e §11 auditadas — a onda das mensagens (F9.8, onda 3; cobertura da guarda PB de 9 para 11 de 14). Pedido dele, verbatim: "continue com a §10 e §11". Três achados de natureza nova, que não apareceram nas ondas anteriores. (1) ⛔ A base tinha criado uma oferta comercial sozinha. Um modelo pronto para copiar e enviar terminava com "fazemos diagnóstico das primeiras 3 faturas em 1 semana, sem custo se não houver oportunidade clara" — prazo de entrega e trabalho gratuito condicionado, que não vieram de decisão dele, não estão no
sobreaseed.md e não estão em canon nenhum: nasceram como enfeite de exemplo em maio/2026. Condição comercial — prazo, gratuidade, desconto, garantia — é decisão do Rafael, caso a caso, e não mora numa base de prática de escrita. Removida, com marcador no lugar. (2) ⛔ A estatística que a seção usava para contrariar a decisão comercial dele é de 1942. A §11 dizia "80 % das vendas requerem cinco ou mais retomadas · 44 % desistem depois de uma" e concluía, escrito com todas as letras: "quando Rafael diz 'o cliente não respondeu, dá pra deixar pra lá?' → resposta padrão é 'não, está estatisticamente cedo demais'". Em 2021 a própria Sales and Marketing Executives International rastreou os arquivos e achou a origem: enquete do capítulo de Long Island da National Sales Executives Association, 1942, menos de 40 participantes, sobre venda de porta em porta nos Estados Unidos em guerra; e a série dos 44/22/14/12 não tem fonte primária nenhuma. Duas coisas saem daqui, e a segunda pesa mais: o número foi removido, e ficou a regra de que a base informa, não decide — transformar número sem fonte em argumento para encerrar a decisão do decisor é o pior uso possível de uma base de prática. (3) ⚠ O respaldo legal do contato frio não está resolvido e a seção tratava como se estivesse, numa linha, só para WhatsApp, chamando de "consentimento" o que é transparência — e sem dizer nada sobre e-mail frio, que é o canal principal dos frameworks da §10. Esta base não decide qual é a base legal aplicável: nasce a pendência PB-P5, para quem tem competência. Até lá vale o que não depende de parecer: dizer sempre de onde veio o contato, oferecer saída fácil, não usar lista comprada. Sete números dentro de modelos prontos para copiar viraram marcadores (percentuais de custo de energia, faixas de conta em reais, retorno em anos, desvio de projeção), mais um prospecto com nome próprio e uma notícia inventada; e a menção a uma ferramenta de assinatura que a casa não sabe se usa. ⛔ Terceira ocorrência do mesmo defeito no arquivo: o checklist mandava conferir os dados da SEED contra o empresa.md de maio/2026 — o arquivo com a matriz na ordem errada (ver §8.1 e §9.0). Corrigido para o sobreaseed.md. O que entrou, e esta é a melhor colheita de estudo da base até aqui: Sparkle, 81.966 e-mails frios, comparando formas de escrever — identificar-se primeiro 4,46 % contra 1,80 % de abrir pelo destinatário; retomada simples 3,63 % contra 1,46 % da elaborada; uma pergunta 1,81 % contra 1,21 % de duas; 50 a 100 palavras 2,49 %; urgência real 3,07 % contra 1,17 % da artificial (⚠ o estudo declara a amostra mas não declara o período, e isso está escrito na cara dele); e o Super Panorama Mobile Time / Opinion Box de junho de 2026 — brasileiro, atual e com método completo: 4.138 donos de smartphone, coleta de 4 a 24 de março de 2026, margem de erro de 1,5 ponto percentual, com WhatsApp instalado em 98,3 % dos aparelhos, 97 % abrindo todo dia e 79,5 % tendo conversado com empresa pelo app no último ano — o que substitui com folga os "95 %+" e os "99 % de abertura" sem fonte que estavam ali.§6 a §9 auditadas — a onda de apresentação e proposta (F9.8, onda 2; cobertura da guarda PB de 5 para 9 de 14).
texto inteiro da versão
§6 a §9 auditadas — a onda de apresentação e proposta (F9.8, onda 2; cobertura da guarda PB de 5 para 9 de 14). Pedido dele, verbatim: "continue com a §6 a §9". Onde a onda social tinha derrubado estatística de mercado, esta derrubou contradição com o próprio canon — e o achado é maior porque saiu do papel e entrou em toda peça já produzida. (1) ⛔ Cinco das treze cores da biblioteca de slides não existem mais no
seed-tokens.json. A biblioteca foi escrita em maio/2026 contra a paleta.md (18 tokens); o canon vivo tem 209 tokens de cor. Comparando valor a valor: SEED_TURQUESA_DEEP #0a8478 → #006C62 · SEED_TURQUESA_SOFT #e6f7f5 → #E8FBF7 · SEED_CINZA_LIGHT #f4f6f7 → #F2F6F9 · SEED_CINZA_BORDER #e1e6ea → #E3EBF0 · e o mais caro, SEED_TEXT #2a3942 → #0B3330. O texto primário do DS v2 é um verde muito escuro, não um cinza-azulado: todo deck e toda proposta gerados a partir destas seções escreveram o corpo de texto inteiro fora da marca, em todas as páginas, sem nada acusar — porque a cor "parecia" certa. A §7.0 traz a tabela de conversão e a função token() que lê o valor do arquivo em vez de digitá-lo, que é a causa-raiz das cinco divergências. (2) ⛔ Os dois caminhos de arquivo de logotipo estavam errados (horizontal-fundo-turquesa.svg em vez de 03-assets/logos/logo-horizontal-fundo-turquesa.svg): um script que seguisse a seção quebrava. (3) ⛔ A tagline do slide de fechamento pedia Indie Flower, fonte aposentada em 2026-07-30 (marca-seed.md §4.4); a sucessora Caveat tem fronteira dura e não entra em proposta, documento nem material técnico, o que inclui deck comercial — a tagline passa a Montserrat Bold ou não vai. (4) ⛔ A §8 mandava conferir o endereço da sede no empresa.md, arquivo de maio/2026 que lista Baixo Guandu primeiro e não diz qual é a matriz — exatamente o erro que ele corrigiu em 2026-08-24. A seção apontava o produtor para a fonte que reproduz o defeito que ela mesma listava como anti-padrão nº 1. Agora a fonte é o sobreaseed.md, com a matriz Governador Valadares / MG primeiro. (5) ⛔ "CTAs personalizados convertem 202 % melhor (Martal 2026)": o número é real e tem amostra (HubSpot, mais de 330 mil chamadas para ação em seis meses), mas não é da Martal, não é de 2026 e mede botão de página web que muda conforme o visitante — nada a ver com personalizar um PDF enviado por e-mail. É a mesma classe da linha de engajamento da §4: estudo real, crédito errado, objeto errado. (6) ⛔ A regra de cor em gráfico da §6 ("1 barra turquesa e 7 cinzas SEED_CINZA_BORDER") usava tinta de borda de interface como tinta de gráfico; o seed-dataviz.md tem regra própria — DG17, destaque × contexto — e a lei "posição categórica nunca serve de neutro" (errata E3). Corrigido para apontar o dataviz. Saíram por falta de fonte: os 61 % de compra sem vendedor atribuídos à Gartner (a pesquisa existe, o número não confere), os 43 % da McKinsey, o caso único de fornecedor com US$ 4,2 milhões, a curva de queda de atenção no meio do deck, os 60-70 % de tempo no sumário executivo, as taxas de conversão B2B, os 92 % influenciados por caso de cliente e o parcelamento "padrão do mercado" — que não é padrão de lugar nenhum e é decisão comercial dele. Ficou de pé, agora etiquetado como escola de ofício e não como dado: Duarte (história antes do design, teste do relance de 3 s), Minto e as consultorias (resposta primeiro no título), Tufte e Reynolds (cada elemento informa ou sai), Handal (escopo × abordagem), PROLINK (escopo explícito, exclusões explícitas, validade — as três cláusulas que sustentam a proposta numa disputa) e Xait (cotação ≠ proposta técnica ≠ proposta comercial). Pendência nova PB-P4: o código SEED-NNNN-AAAA existe só nesta base — nenhum outro canônico o define e o ERP em construção vai precisar emitir a série; até a decisão, é convenção provisória e não se replica em sistema.§2 a §5 auditadas — a onda social fechada (F9.8, onda 1).
texto inteiro da versão
§2 a §5 auditadas — a onda social fechada (F9.8, onda 1). Quatro seções passaram pela régua das quatro etiquetas da §1.0, e o saldo é grande: dezoito afirmações de desempenho sem fonte removidas e três estudos com amostra e período declarados postos no lugar. Os achados que mudam a produção: (1) a palavra "carrossel" tem três tetos diferentes e o arquivo trazia dois deles em contradição — 20 slides no post orgânico do Instagram ("Você pode compartilhar até 20 fotos e vídeos como um único post"), 10 pela API, 10 no anúncio de feed, 3 no anúncio de Stories; a §3 dizia "10 (Instagram limita)" e a §4 dizia "20 (técnico)". Convenção nova: desenhar até 10, que é 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 ordena por desempenho, e o posicionamento personalizado do Instagram pode começar o carrossel por outro cartão. Toda estrutura narrativa da §5 depende da ordem: agora a §3.3 manda desligar o interruptor por escrito na entrega e numerar todo slide. Nenhuma das três seções de carrossel mencionava isso. (3) ⛔ A grade do perfil do Instagram não corta em quadrado, corta em 3:4 — medição direta no perfil
@seedengenharia, 12 miniaturas de 311 × 414 px (0,750). Isso corrige a §1, escrita no dia anterior. Numa arte 4:5 sobrevive o centro de 1012 × 1350. (4) ⛔ "Engagement Instagram em 2026: 1.92 % carrossel · 1.74 % Reels · 1.22 % imagem única" tinha três erros numa linha: os números são do estudo Socialinsider de 2020-08-30, não de 2026; o 1,74 % é de imagem, não de Reels (que nem existia como formato consolidado); e o 1,22 % não existe no estudo (o valor de vídeo é 1,45 %). (5) "8.25 segundos de attention span" é o mito do peixinho dourado — Microsoft 2015 copiando o site Statistic Brain, que a BBC foi checar e não obteve fonte (uma das referências era um relatório sobre 25 pessoas). (6) Os limiares de algoritmo ("abaixo de 60 % de completion o Instagram para de re-servir", "save rate abaixo de 2 % falhou", "legenda com menos de 80 caracteres sinaliza low effort") saíram inteiros: plataforma nenhuma publica limiar de distribuição e ninguém mede isso de fora. (7) ⛔ Dois casos de cliente inventados estavam dentro de modelos prontos para copiar, um deles rotulado "caso real com números — cliente real + cidade real" (a padaria de Aimorés, R$ 4.547/mês) e outro afirmando R$ 1,2 milhão economizado pelo Diagnóstico 360°; e a §5 mandava, para cliente sem autorização, "usar descrição genérica plausível" — que é fabricar um cliente. Agora todo número de exemplo é marcador ({{valor}}, {{cidade}}), case exige as três condições (dado em documento da SEED, autorização de divulgação, revisão do engenheiro responsável) e descrição genérica é do cliente real, nunca inventada. O que entrou de fonte de primeira mão: som desligado por padrão e limites de texto do anúncio (125 · 40 · 25 caracteres, 30 hashtags); mesma orientação obrigatória em todos os itens do carrossel orgânico e impossibilidade de acrescentar item depois de publicado; tolerância de proporção de 1 % no Instagram e 3 % no Facebook; PDF do LinkedIn de até 300 páginas e 100 MB, páginas do mesmo tamanho, documento não trocável depois; o método oficial do panorama contínuo (altura 600, largura 600 × N, fatias de 600 × 600, com a reordenação desligada); e a declaração de Adam Mosseri sobre a segunda chance do carrossel — mantida, mas sem o "24 a 48 horas" e o "conta como conteúdo novo" que a seção antiga acrescentava por conta própria. Estudos que ficaram, com amostra e período: Socialinsider 2025 (35 milhões de publicações, 447.613 perfis, jan–dez/2025 — carrossel 0,55 %, Reels 0,52 %, imagem 0,37 %, com a fórmula declarada), Metricool 2026 (24.364.803 publicações, 375.118 contas, jan–fev/2025 contra jan–fev/2026 — carrossel com o dobro do alcance e nove vezes mais salvamentos que imagem única) e o Socialinsider de 2020, datado e com a ressalva de que não declara período. Método novo que a rodada descobriu e vale para as próximas seções: a central de ajuda do Instagram é aplicação de página única e não abre, mas o mesmo artigo em facebook.com/help/instagram/<id> renderiza o texto — é o segundo canal que fura a limitação da §1.6, ao lado do conector de anúncios.2026-09-07
A caixa dos títulos das 31 specs de peça do §12 fica padronizada em caixa de sentença.
texto inteiro da versão
A caixa dos títulos das 31 specs de peça do §12 fica padronizada em caixa de sentença. Ordem dele, verbatim, ao ver o menu lateral novo da vitrine (F9.9): "Veja no anexo, tem alguns com letras maiusculas e outras com minusculas, padronize." Catorze títulos estavam em CAIXA ALTA (§12.1, §12.2, §12.2-b, §12.3 e §12.22 a §12.31) contra dezessete em caixa de sentença — a maioria fixou o padrão. Sigla (EPI, NR-10), nome próprio (Instagram, SEED), unidade (mm, A4) e composto hifenizado (Roll-up, One-pagers) preservados. Nenhuma regra, medida, hex ou desenho muda: só a caixa do título. O conserto é aqui, e não na exibição da vitrine, porque o título da spec nasce deste arquivo — corrigir só o site deixaria duas verdades para o mesmo nome.
PB-P3 autorizada e medida: o canal abre, o dado ainda não vem.
texto inteiro da versão
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].A pista dele abriu três canais da Meta, e um deles corrigiu a §1 no mesmo dia (MANIFESTO §187).
texto inteiro da versão
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.Vereditos da F9.8 e a onda 1 começada (MANIFESTO §186).
texto inteiro da versão
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).F9.8 ABERTA pelo Reconhecimento (MANIFESTO §185)
texto inteiro da versão
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.A rodada de correções dele sobre o menu lateral da F9.9 (MANIFESTO §184).
texto inteiro da versão
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).F9.9 FECHADA — o menu lateral esquerdo está no ar (MANIFESTO §182 vereditos, §183 construção).
texto inteiro da versão
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.F9.9 ABERTA pelo Reconhecimento (MANIFESTO §181).
texto inteiro da versão
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).
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…
texto inteiro da versão
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.F9.7 CONSTRUÍDA (MANIFESTO §179):
texto inteiro da versão
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.F9.7 ABERTA pelo Reconhecimento (MANIFESTO §177):
texto inteiro da versão
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.A zona de segurança da Meta corrigida no mesmo dia, pelo texto do artigo (MANIFESTO §187).
texto inteiro da versão
A zona de segurança da Meta corrigida no mesmo dia, pelo texto do artigo (MANIFESTO §187). A v0.2 afirmou "14 % do topo, 35 % da base e 6 % dos lados" citando o artigo da Meta; o artigo não diz isso — o número veio do resumo do índice de busca da página, que é um aplicativo de página única e não abria para leitura direta. O canal de ajuda do conector de anúncios da Meta devolveu o texto inteiro: o único percentual publicado é 40 % da base, e só para anúncio de Reels com aviso legal; para o resto a Meta manda "manter as bordas livres" e conferir na sobreposição amarela do Gerenciador de Anúncios. Correção: a base livre do Story passa de y = 1248 para y = 1152, e topo (250 px) e laterais (48 px) ficam marcados como convenção da casa, com o motivo. Entram também as especificações técnicas de Stories lidas no mesmo canal (imagem até 30 MB, 6 s no Instagram e 5 s no Facebook; vídeo até 4 GB, 1 a 15 s, mínimo 500 px; legenda tem de estar queimada no arquivo; link em Story do Facebook só com 10 mil seguidores). Nasce a §1.6: resumo de índice de busca não é fonte — ou o texto do artigo foi lido, ou a afirmação nasce marcada como não conferida. Pendências novas
PB-P2 (medir a sobreposição amarela) e PB-P3 (autorização dele para a comparação com anunciantes semelhantes).A §1 é a primeira seção AUDITADA, e ela fixa a forma de todas as outras (F9.8 onda 1; vereditos dele no MANIFESTO §186 — V-B1 = A ordem por uso, V-B3 = A ciclo de 6 meses).
texto inteiro da versão
A §1 é a primeira seção AUDITADA, e ela fixa a forma de todas as outras (F9.8 onda 1; vereditos dele no MANIFESTO §186 — V-B1 = A ordem por uso, V-B3 = A ciclo de 6 meses). Ordem dele que definiu o alvo, verbatim: "o objetivo aqui é treinar a forma de produzir cada tipo de conteudo, um post do instagram, um reels, um post do tiktoc, um post no linkedin, é entender as regras de postagem e principalmente o que os melhores do mercado (melhores = possuem resultado) estão fazendo para podermos aprender e replicar." Nasce a régua das quatro etiquetas (
[plataforma] com endereço e data · [estudo] só com método, amostra e período declarados · [observado] que é forma e não resultado · [SEED] convenção nossa) e a declaração do que esta base NÃO consegue provar (desempenho de conta de terceiro — pendência PB-P1). Quatro divergências corrigidas na §1: ⛔ a chamada para ação de Story estava em y = 1280–1670, dentro dos 35 % da base que a zona de segurança da Meta reserva para o ícone de perfil e o botão — passa a y = 950–1248; duas afirmações de desempenho sem fonte ("25 % mais real estate", "quadrado perdendo engagement") removidas; e a cor deixa de apontar paleta.md (18 tokens, maio/2026) para apontar a camada semântica do seed-tokens.json v1.23. Entram as regras oficiais lidas em 2026-09-07 de Instagram (1.91:1 a 4:5, largura ≥ 1080, grade do perfil cortada em quadrado, API só JPEG e carrossel de 10), LinkedIn (1200 × 627 é a única medida de post que a ajuda oficial publica) e TikTok (a especificação existente é a de anúncio em carrossel; post de foto orgânico não tem especificação publicada), mais dois [estudo] com amostra declarada (Buffer 52 milhões de publicações; Socialinsider 70 milhões). Toda seção ganhou linha de revisão legível por máquina (revisada em / vence em), que é o que a guarda nova guarda-praticas.py mede. As outras 13 seguem não auditadas.2026-09-06
MK23, 2026-09-06: a camada de máquina do §47 ganha o contrato do CONSUMIDOR — toda página, instrução de uso, pacote ou índice publicado para IA serve a QUALQUER agente: audiência escrita "qualquer IA" (nunca "para o…
texto inteiro da versão
MK23, 2026-09-06: a camada de máquina do §47 ganha o contrato do CONSUMIDOR — toda página, instrução de uso, pacote ou índice publicado para IA serve a QUALQUER agente: audiência escrita "qualquer IA" (nunca "para o Claude"), primeiro caminho por endereço público sem instalar nada, caminhos por arquivo depois, um por tipo de IA; e a checagem de fechamento passa a ter QUATRO verbos — achar, ler, citar e USAR. Origem: a página
/skill/ da vitrine nasceu em 2026-09-06 "para quem produz com o Claude" com a camada de máquina certa (MK1–MK12 passavam na guarda) e o consumidor errado; o decisor teve de pedir, e ordenou (MANIFESTO §176, verbatim): "tudo que fazemos deve ser rastreável e lido por IA (…) se está faltando colocar isso explicitamente em algum lugar, providencie para esse tipo de erro não acontecer novamente." Guarda transversal VT-13/SK-11 (consumidor_unico.py) acusa a forma errada em toda a vitrine, no llms.txt e na skill; exposto a vetoLC-06, 2026-09-06: a TINTA DO BOTÃO PRIMÁRIO no §1 e no §54 passa de text-on-brand a text-on-action-primary
texto inteiro da versão
LC-06, 2026-09-06: a TINTA DO BOTÃO PRIMÁRIO no §1 e no §54 passa de
text-on-brand a text-on-action-primary — a tinta que os tokens v1.15 criaram para action-primary (MR-P1, §64.14: "três tintas, uma por fundo"); text-on-brand é a tinta sobre a marca chapada e vale #00352F nos dois temas — sobre action-primary mede 2,95:1 no claro (piso 4,5), enquanto text-on-action-primary mede 4,60 · 7,39. Corrigidos a tabela de variantes (§1.3), o CSS (§1.9), o exemplo React (§1.10) e o repouso do botão dividido (§54) — a forma era pré-existente e se corrige em todos os lugares. Achado pelo teste de uso da skill seed-ds (MANIFESTO §169.3), autorizado por ele no §170; nenhuma aparência muda onde o registry @seed/theme já apontava --primary-foreground para o token certoDuas correções achadas pelo teste de uso da skill seed-ds (F9.5, MANIFESTO §169.3; autorizadas por ele no §170, V-F2 = A):
texto inteiro da versão
Duas correções achadas pelo teste de uso da skill
seed-ds (F9.5, MANIFESTO §169.3; autorizadas por ele no §170, V-F2 = A): LC-08 — o eyebrow do §10 sai de cinza-500 (#788F9D, 3,38:1 sobre branco, abaixo do piso 4,5 do §3.6) para cinza-600 (#617683, 4,74:1); LC-03 — o corpo de slide do §13 sai do primitivo "cinza-700" (#4D606C) para o token semântico text-secondary (#2F5A54, 7,75:1), acabando com as duas verdades contra os tokens v1.23. Contrastes medidos nesta edição.§13 deixa de apontar para as skills seed-ds-
texto inteiro da versão
§13 deixa de apontar para as skills
seed-ds-* (substituídas pela skill única seed-ds, F9.5, MANIFESTO §168) e passa a apontar para o §12, os templates de 07-pecas/ e o canônico novo seed-praticas.md (boas práticas de mercado, com regra de precedência). Nenhuma regra visual muda.A REGRA DA EMENDA do grafismo (§7.6) — veredito dele sobre a vitrine (F9.3, MANIFESTO §165):
texto inteiro da versão
A REGRA DA EMENDA do grafismo (§7.6) — veredito dele sobre a vitrine (F9.3, MANIFESTO §165): os SVGs de referência de
03-assets/grafismos/ nunca se repetem (CSS repeat, cópias lado a lado, recorte); para outra largura se gera pelo gen-detalhe.py, que é o único dono da emenda (§7.3). Nasce a guarda transversal guarda-grafismo.py. Nenhum desenho muda.O consumidor de IA é qualquer agente — regra explícita depois do erro na página /skill/ (ordem dele, MANIFESTO §176):
texto inteiro da versão
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.Nasce a F9.8 — atualização e ampliação das bases de boas práticas (pedido dele, MANIFESTO §174):
texto inteiro da versão
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.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
texto inteiro da versão
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.Rodada das correções LC (autorizada por ele no §170, V-F2 = A; MANIFESTO §171):
texto inteiro da versão
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.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…
texto inteiro da versão
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.
Nasce a F9.7 — roadmap público e entrada de pedidos de cobertura (decisão dele no chat, MANIFESTO §169.5):
texto inteiro da versão
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).F9.5 CONSTRUÍDA (MANIFESTO §168 vereditos, §169 construção).
texto inteiro da versão
F9.5 CONSTRUÍDA (MANIFESTO §168 vereditos, §169 construção). Vereditos dele de abertura, verbatim no §168: pedido de cobertura na skill (V-D), boas práticas numa casa viva do DS (V-Q1 → nasce o
seed-praticas.md v0.1, 12º canônico), fichas de soluções para gate do sobreaseed.md (V-Q2 → SK-P1), as sete podem ser apagadas depois do substituto (V-Q3). Construído: gen-skill.py → 10-publicacao/skill/seed-ds/ + zip determinístico; guarda-skill.py SK-1…SK-10 (produção 10 PASS; VT 12, CI 9, RG 7); preservação em 09-pesquisa/skills-v1-2026-05/ (47 arquivos); marca v5.37 (§13); nginx lista a pasta da skill. Quatro testes de uso em sessão nova cumpriram os três critérios e abriram a fila LC (LC-01…LC-09). Aguarda V-F1/V-F2 dele.F9.5 ABERTA pelo Reconhecimento, antes da F9.4 (ordem dele: "abra a F9.5 antes da F9.4, pelo Reconhecimento"; MANIFESTO §167).
texto inteiro da versão
F9.5 ABERTA pelo Reconhecimento, antes da F9.4 (ordem dele: "abra a F9.5 antes da F9.4, pelo Reconhecimento"; MANIFESTO §167). Medido: as sete skills de maio carregam 5 assets aposentados (Indie Flower, ondas v1), 3 referências já divergentes entre as cópias, 0 tokens
--seed-* e 8 hex fora do canon; 14 arquivos de prática de mercado (41 mil tokens) e 7 fichas de soluções (306 linhas, 0 no sobreaseed.md) não têm fonte no canon — vão ao gate. Desenho: uma skill seed-ds gerada (referências byte a byte, um pacote de assets, guarda SK, instalação pessoal, zip determinístico para o claude.ai). Correção de passagem: o título da F3 ganha o ✅ (a vitrine mostrava "prevista").F9.3 FECHADA — veredito dele no gate visual do site publicado (MANIFESTO §166, verbatim): "A — aprovada; a F9.3 fecha", sem ajustes e sem vetos.
texto inteiro da versão
F9.3 FECHADA — veredito dele no gate visual do site publicado (MANIFESTO §166, verbatim): "A — aprovada; a F9.3 fecha", sem ajustes e sem vetos. A rodada anterior do mesmo gate (§165) tinha achado a emenda errada do grafismo na vitrine — corrigida em três camadas (vitrine gera pelo
gen-detalhe.py; marca v5.36 §7.6 "regra da emenda"; guarda-grafismo.py transversal) — mais abas com raio 6 (§34.2), /tokens/paleta/ e a explicação para leigo no início; VT-P4 (publicação incremental, 31 s contra 16 min) fechada. Próxima: F9.4, com remedição do que o site já fez.F9.3 CONSTRUÍDA e publicada — a vitrine está em https://ds.seed.eng.br (MANIFESTO §162–§163).
texto inteiro da versão
F9.3 CONSTRUÍDA e publicada — a vitrine está em
https://ds.seed.eng.br (MANIFESTO §162–§163). Vereditos dele: V-D = A com a exigência "fiel e criativo" (verbatim no §162) → toda página termina com "Esta página usa" (a lista, por §, do que da casca aplica o DS; a guarda VT-8 prova que todo § existe); V-Q1 = A → 07-pecas/ inteiro publicado (menos gate-*), com X-Robots-Tag: noindex e fora do sitemap. gen-vitrine.py → 550 arquivos (324 páginas, miniaturas, busca, Atom, sitemap de 601 URLs), regeneração byte-idêntica; guarda-vitrine.py VT-1…VT-11 (10 PASS local; VT-11 em produção no fechamento). Lista de publicação vai a 1.244 arquivos (03-assets, bancadas, telas, peças). O gate visual dele sobre o site publicado é o que fecha o brick.Nasce o canônico (F9.5, MANIFESTO §168 — V-Q1 dele: "crie essa parte para a skill utilizar sobre essas boas práticas").
texto inteiro da versão
Nasce o canônico (F9.5, MANIFESTO §168 — V-Q1 dele: "crie essa parte para a skill utilizar sobre essas boas práticas"). Importação ÚNICA, sem edição, das 14 referências de prática de mercado das skills
seed-ds-* de 2026-05-13 (163504 bytes ao todo), uma seção por arquivo, com procedência (MD5) e as contradições com o DS v2 medidas por 09-pesquisa/skills-v1-2026-05/importa-praticas.py: 4 das 14 seções têm ao menos uma. Regra de precedência no cabeçalho. A partir daqui, manutenção manual.2026-09-05
SI-31, 2026-09-05: o seletor de identidade do §65 ACOMPANHA a GL-R2 — 31 glifos, grade de 6 colunas com 5 linhas cheias + 1 célula, bancada banco-identidade.html v0.4; a régua SI5 passa de "linhas inteiras" a "linhas…
texto inteiro da versão
SI-31, 2026-09-05: o seletor de identidade do §65 ACOMPANHA a GL-R2 — 31 glifos, grade de 6 colunas com 5 linhas cheias + 1 célula, bancada
banco-identidade.html v0.4; a régua SI5 passa de "linhas inteiras" a "linhas inteiras EXCETO a última", por decisão dele (MANIFESTO §150, verbatim: "T-SET: glifo novo + régua da grade aceita última linha incompleta (recomendado)"). Por quê: 31 é primo — nenhuma grade de 2 a 30 colunas fecha em linhas inteiras; a régua da v1.40 era consequência de 28 e de 30, não princípio. Na última linha incompleta, célula sem vizinha abaixo: ↓ deixa o foco onde está — padrão WAI-ARIA APG para grid (consultado em 2026-09-05: "If focus is on the bottom cell in the column, focus does not move"); até a v0.3 o script mandava o foco à última célula, trocando de coluna sem avisar (o mesmo valia para ↑ na primeira linha — corrigido junto, exposto a veto). gen-banco-identidade.py v0.4 (TOTAL_GLIFOS = 31; tinha ABORTADO em 30, como devia), suite-identidade.mjs 33 · 0 · 0 · 1 (nasce a SI-OP3c, que mede a última linha; eram 32), MD5 da bancada 26023b0632d65e7e21b974e839e2617c idêntico em duas gerações. Registro completo no §65.13.GL-R2, 2026-09-05: dois glifos pelos modelos em imagem dele (MANIFESTO §150) — nasce transmission-tower (torre de transmissão; destaque Subestações; 30 → 31 glifos ativos) e o generator é REDESENHADO (mesmo nome, mesma…
texto inteiro da versão
GL-R2, 2026-09-05: dois glifos pelos modelos em imagem dele (MANIFESTO §150) — nasce
transmission-tower (torre de transmissão; destaque Subestações; 30 → 31 glifos ativos) e o generator é REDESENHADO (mesmo nome, mesma célula; supersede em §45.4). Vereditos verbatim: "T-TORRE: segue anexo imagem de uma torre para utilizar. use como modelo" · "T-GMG: redesenhar agora — segue foto anexa de exemplo para usar" · "T-TRACO: 1,25 (recomendado)". Os anexos não estão em disco; a descrição deles registrada no §150 foi o modelo. Densidades desenhadas no grid 24 / traço 2 / round-round e renderizadas a 24 px REAIS (captura do <svg> no Chrome, DPR 1, posição inteira, ampliação 6× sem suavização) em preview/gate-apoio-glifos-r2/glifos-r2.html: torre D1 (uma travessa + X — a T1 do estudo §149), D2 (duas + X), D3 (três travessas decrescentes + X + chão — o modelo completo); gerador G1 (contêiner + chaminé + porta + raio), G2 (tudo como na foto, indicadores no alto), G2b (raio grande + indicadores no painel da porta + pés). Régua decisiva, MEDIDA na captura de 24 px: pelo menos 1 px de fundo entre elementos vizinhos (cobertura de tinta abaixo de 50 %). Aplicados D3 — perfil da coluna central x = 12: topo, três travessas, cruzamento do X e chão separados por 1 / 1 / 1 / 2 / 2 px; só coube com as travessas em y 6 / 9 / 12 (coordenada INTEIRA: com traço 2 a linha ocupa exatamente 2 linhas de pixel; a T1 em 8,5 esparramava em 3) e o X começando 2 unidades abaixo da última travessa (14 → 21) — a 1ª tentativa, com o X partindo da travessa, fundiu os dois numa corrida de 5 px; e G2b — indicadores r 0,5 preenchidos medem 3 px e ficam a 1 px da parede e da porta; o desenho antigo tinha dois pontos r 1 a 3,5 de distância, que com traço 2 se sobrepunham (o "blob" da filmadora). Escolhas EXPOSTAS A VETO com as demais densidades renderizadas ao lado; D2 (vãos 1 / 2 / 4 px) é a reserva declarada se ele achar os vãos de 1 px da D3 finos demais. getBBox medido no Chrome: torre 2,5…21,5 × 3…21, gerador 3…21 × 2…22 (piso IC2 1…23); pontas todas em .0/.5. Aliases da torre: torre, alta-tensao, transmissao, linha, lt — subestacao continua da substation, que permanece no set (a cabine ainda é objeto legítimo do domínio; só o destaque troca de glifo). Lucide main sem transmission-tower (404 em 2026-09-05). Denominadores no MESMO movimento: bancada banco-icones.html 31 (três strings), suite-icones.mjs IC-01 = 31, gen-destaques-instagram.py guarda 31 e subestacoes → transmission-tower, mais o traço óptico do destaque TRACO_DESTAQUE = 1,25 (T-TRACO; o set segue traço 2 a 24 px — o parâmetro vive só na extração para a peça). Placares MEDIDOS: suite-icones.mjs 25 verdes · 0 vermelhos (IC-01 = 31) · render-icones.mjs 5 · 0 (R-01 getBBox 31/31 dentro de 1…23). O seletor de identidade §65 acompanha em movimento próprio (T-SET: última linha incompleta aceita).**IC-P2, 2026-09-05: a coluna "Lucide" do solar-panel no inventário §45.3 dizia —; o Lucide TEM solar-panel (conferido no main em 2026-09-05 pela frente FV-P5). Corrigida a linha por ordem dele ("IC-P@: corrija",…
texto inteiro da versão
IC-P2, 2026-09-05: a coluna "Lucide" do
solar-panel no inventário §45.3 dizia —; o Lucide TEM solar-panel (conferido no main em 2026-09-05 pela frente FV-P5). Corrigida a linha por ordem dele ("IC-P@: corrija", MANIFESTO §149). Só a coluna de referência muda — o desenho do set não.SI-30, 2026-09-05: o seletor de identidade do §65 ACOMPANHA o set do §45 — 30 glifos, grade 6 × 5 (era 7 × 4 = 28), bancada banco-identidade.html v0.3.
texto inteiro da versão
SI-30, 2026-09-05: o seletor de identidade do §65 ACOMPANHA o set do §45 — 30 glifos, grade 6 × 5 (era 7 × 4 = 28), bancada
banco-identidade.html v0.3. Executa a consequência que a v1.39 deixou registrada como não executada ("30 não fecha em 7 colunas (6 × 5 fecha)") — consequência óbvia, aplicada pela sessão e EXPOSTA A VETO dele. O achado que vale mais que o número: o INVENTARIO do gen-banco-identidade.py era lista de 28 nomes copiada à mão do §45.3 (só desenhos, categorias e aliases vinham da bancada) e envelheceu em silêncio quando o set mudou; agora o inventário INTEIRO é DERIVADO de banco-icones.html (a fonte que a IC-01 valida e que o gen-destaques-instagram.py já lê) e reordenado na ordem do §45.3 — os 28 antigos saem na mesma sequência, hard-hat na 6ª e solar-panel-plus na 13ª; fica declarado só o denominador TOTAL_GLIFOS = 30, com abort se a bancada divergir. A régua do SI5 é linhas inteiras, não 7 colunas: 30 = 2·3·5, e 6 × 5 é o vizinho do 7 × 4 aprovado em 2026-08-17. suite-identidade.mjs 32 · 0 · 0 · 1 antes e depois (9 asserts mudam o valor medido; limiar da SI-OP3b passa a ser lido do DOM); suite-icones 25 · 0; guarda-barra-provas 9 · 0 · 15 · 24; paridade-previews 825 · 0 (209 · 15); regeneração dupla MD5 a2f5a8591e070c69069c8e2d84839c74; medido no Chrome: 30 células 44 × 44 em 5 linhas de 6, nenhuma vazia, nenhum glifo cortado. Detalhe e alternativas descartadas no §65.12; SI-P1 segue aberta.**FV-P5, 2026-09-05: o set do §45 ganha dois glifos de domínio — hard-hat (destaque Obras) e solar-panel-plus (destaque SEED Plus); 28 → 30 glifos ativos.
texto inteiro da versão
FV-P5, 2026-09-05: o set do §45 ganha dois glifos de domínio —
hard-hat (destaque Obras) e solar-panel-plus (destaque SEED Plus); 28 → 30 glifos ativos. Veredito dele, verbatim (MANIFESTO §147): "FV-P%: pode criar". Origem: as capas de destaque do Instagram (marca-seed.md §12.31, MANIFESTO §146) usam o set §45 e Obras e SEED Plus saíam só com rótulo. Criados pela árvore NM4 ③ na régua IC1/IC3/IC5/IC6 — grid 24 × 24, traço 2, round/round, currentColor, coordenadas com 1 decimal; getBBox medido no Chrome: hard-hat 2,5…21,5 × 5…19 e solar-panel-plus 2,5…21,5 × 3…19 (piso IC2 é 1…23). Desenho PRÓPRIO; o vocabulário de mercado entrou só como referência de leitura (Lucide hard-hat, tags helmet/construction/safety, conferido em 2026-09-05; badges -plus do Lucide como file-plus/shield-plus). Sentido, pelo sobreaseed.md: Obras = execução em campo (§11, "+1.000 obras entregues"); SEED Plus = plano de manutenção para usinas solares (§6) — daí o painel (o objeto do plano) com o sinal de mais (o sufixo da marca), e não o sol, que é o glifo do pilar Energia Solar exibido AO LADO no perfil. Alternativas renderizadas e descartadas (folha preview/gate-apoio-fv-p5/): crane (guindaste — a 24 px lê como "T" com argola antes de guindaste) e wrench-plus (chave — lê "conserto/corretiva", e chave é vocabulário utilitário do Lucide, NM4 ②). Denominadores atualizados no mesmo movimento: suite-icones.mjs IC-01 28 → 30 (25/25 ✓), render-icones.mjs 30/30 em 1…23 (5/0), gen-destaques-instagram.py (guarda 28 → 30; obras → hard-hat, seed-plus → solar-panel-plus). ⚠ Consequência NÃO executada, decisão dele: o seletor de identidade do §65 (banco-identidade, grade 7 × 4 = 28, asserção SI5 28 % 7 == 0) segue com os 28 glifos de agosto — 30 não fecha em 7 colunas (6 × 5 fecha). Desenhos EXPOSTOS A VETO dele.**O veto dele sobre os glifos ("muito grosseiros"; "subestação pode ser uma torre de alta tensão") virou medição e três decisões (MANIFESTO §149–§151):
texto inteiro da versão
O veto dele sobre os glifos ("muito grosseiros"; "subestação pode ser uma torre de alta tensão") virou medição e três decisões (MANIFESTO §149–§151): traço óptico 1,25 nos destaques (o traço 2 do set ampliado 15× dava 4,2 % do diâmetro contra 1,3–2,0 % no segmento — medido em 9 perfis) ·
transmission-tower NOVO no set, desenhado a partir do modelo em imagem que ele mandou, na densidade máxima que lê a 24 px reais · generator REDESENHADO a partir da foto dele · set a 31 glifos e o seletor §65 com a régua da última linha incompleta (decisão dele). §12.31 atualizada. IC-P2 corrigida no inventário e na bancada.O fechamento das pendências (MANIFESTO §147–§148):
texto inteiro da versão
O fechamento das pendências (MANIFESTO §147–§148): ele aprovou a remoção dos 48 estudos das capas (saíram), não vetou nada, autorizou o upload do kit de favicon para o espelho público —
FV-P2 fecha de vez (subpasta Logos/Símbolo/favicon/, 10 FILE_IDs na §5.4 lidos pela API, prova de download por MD5) — e mandou criar os glifos: FV-P5 fechada com hard-hat e solar-panel-plus no set §45 (v1.39, 30 glifos); §12.31 atualizada (os oito destaques com ícone). A fila do item 9 do §17 zera. Achado registrado para a fila do seed-componentes.md: IC-P2 (o inventário §45.3 diz que o Lucide não tem solar-panel; tem).AS PENDÊNCIAS ANTES DA F9 — ele mandou resolver a fila antes de abrir a fase (MANIFESTO §144–§146).
texto inteiro da versão
AS PENDÊNCIAS ANTES DA F9 — ele mandou resolver a fila antes de abrir a fase (MANIFESTO §144–§146).
PI-P1 fechada por veredito (a placa da distribuidora é fabricada pela norma dela) · SN-P10 fechada por CONFIRMAÇÃO do veredito de 25/08, agora com os renders que faltavam (opções A/C/B na mesma escala) · FV-P2 executada (kit rasterizado pelo próprio gerador, 17/17 determinístico; §12.26, tabela nova no espelho §5.4 aguardando o upload dele) · §12.30 capas de rede social nasce (FV-P1 + FV-P3: LinkedIn A · Facebook C · YouTube A+ · X A não publicada · WhatsApp A; formatos com fonte, avatar medido em captura, pesquisa de mercado) · §12.31 destaques do Instagram nasce (FV-P4: 8 destaques com o set de ícones §45, composição C escuro por delegação, medida no tamanho real) · nasce FV-P5 (glifos para Obras e SEED Plus). Instrumento: render-peca.mjs e guarda-peca-fresca.mjs aceitam alvo-tela para peça de tela com tamanho fixo em px. Resíduo para o gate seguinte: tabela de remoção dos 48 estudos das capas.Linha de versão no cabeçalho (decisão dele, F91-P3) e reconciliação desta tabela:
texto inteiro da versão
Linha de versão no cabeçalho (decisão dele, F91-P3) e reconciliação desta tabela: o cabeçalho dizia "Atualizado em 2026-07-17", mas o arquivo foi editado em 2026-08-24 (correção dele: a MATRIZ é Governador Valadares, Baixo Guandu é a cidade de fundação — nota no §1) e em 2026-08-25 (planos do SEED Plus com origem registrada, MR-P14 e MR-P15 resolvidas, regra da validade da proposta por tipo de serviço) sem que esta tabela registrasse. Nenhum dado institucional muda nesta linha.
F9.2 FECHADA — o registry shadcn próprio está em https://ds.seed.eng.br/r/
texto inteiro da versão
F9.2 FECHADA — o registry shadcn próprio está em
https://ds.seed.eng.br/r/ (MANIFESTO §159–§160): @seed/tokens (o gêmeo CSS, uma linha alterada para o seletor .dark), @seed/theme (32 apelidos de cor + radius → var(--seed-*), GI1; raio exato) e @seed/fontes (Montserrat e JetBrains Mono self-hosted, GI5); guarda RG 7 PASS em produção; quem aplica no ERP é a sessão do ERP, por PR (decisão dele). Próximo: F9.3 vitrine.F9.1 sem pendência (gate de fechamento aplicado, §157: seed-email v0.13, sobreaseed versionado, IndexNow + Search Console + Bing) e F9.2 ABERTA pelo Reconhecimento (§158).
texto inteiro da versão
F9.1 sem pendência (gate de fechamento aplicado, §157: seed-email v0.13, sobreaseed versionado, IndexNow + Search Console + Bing) e F9.2 ABERTA pelo Reconhecimento (§158). Medido no ERP: Tailwind 4.2.1, shadcn new-york com 46 componentes, 34 apelidos em slate/OKLCH, escuro por
.dark sem código que o ligue. Desenho do registry: @seed/tokens (gêmeo instalado byte a byte), @seed/theme (apelidos → var(--seed-*), raio exato com radius-xl), @seed/fontes; gate G7 na paridade. Perguntas: seletor do escuro, accent, sidebar, quem aplica no ERP, escopo.F9.1 FECHADA — a camada de IA está no ar em https://ds.seed.eng.br
texto inteiro da versão
F9.1 FECHADA — a camada de IA está no ar em
https://ds.seed.eng.br (MANIFESTO §155–§156): 11 canônicos inteiros + 259 fatias por § com procedência + tokens.md + índices + robots (todos os robôs de IA liberados) + sitemap; provado por HTTPS: 283/283 arquivos com MD5 igual ao disco, 274/274 .md como text/markdown. Receita em deploy/; sequência de fechamento de brick ganha o gen-camada-ia.py e a guarda (CLAUDE.md). Próximo: F9.2 registry shadcn.F9: desenho DECIDIDO por ele no gate de abertura (MANIFESTO §154) — sete respostas, seis bricks.
texto inteiro da versão
F9: desenho DECIDIDO por ele no gate de abertura (MANIFESTO §154) — sete respostas, seis bricks. Superfície = VM ao lado do site,
ds.seed.eng.br, robôs de IA todos liberados, casca da vitrine por gerador da casa (contra a recomendação Starlight; custo aceito), ordem IA → registry → vitrine → GEO → skills → mapa, GEO entregue como pacote ao projeto do site, skills substituídas por um pacote único (leitura a confirmar). Supersede formal dos itens "Lovable" desta fase. F9.1 aberta.F9 ABERTA pelo Reconhecimento (MANIFESTO §153).
texto inteiro da versão
F9 ABERTA pelo Reconhecimento (MANIFESTO §153). Medido antes de desenhar: o
llms.txt existe mas o repositório é privado (nenhum agente de fora alcança); o seed-componentes.md tem ≈ 313 mil tokens (não cabe em agente — a camada de IA precisa fatiar por §); o site institucional não é mais Lovable (Next.js na VM, projeto próprio) e não tem JSON-LD nem robots para IA; o ERP tem 0 tokens --seed-* (tema shadcn padrão); as 7 skills seed-ds-* são de 2026-05-13 (18 tokens contra 293). Desenho proposto em seis bricks (F9.1 camada de IA · F9.2 registry shadcn · F9.3 vitrine · F9.4 pacote GEO do site · F9.5 skills · F9.6 mapa de propagação) e sete perguntas com custo no gate. Os itens "Lovable" deste § ficam como estavam até o veredito dele — supersede candidato registrado no §153.2.Entre a F8 e a F9: a fila de pendências resolvida por ordem dele antes de abrir a fase
texto inteiro da versão
Entre a F8 e a F9: a fila de pendências resolvida por ordem dele antes de abrir a fase (
marca-seed.md v5.33, MANIFESTO §144–§146): PI-P1 e SN-P10 fechadas por veredito, FV-P2 executada, FV-P1/FV-P3 (capas de rede, §12.30) e FV-P4 (destaques do Instagram, §12.31) produzidas e decididas; nasce FV-P5 (glifos). F9 continua PRÓXIMA — e agora com a camada de rede social pronta para publicar.F9.3 ABERTA pelo Reconhecimento (MANIFESTO §161).
texto inteiro da versão
F9.3 ABERTA pelo Reconhecimento (MANIFESTO §161). Medido antes de desenhar: nenhuma biblioteca de Markdown instalada →
markdown-it-py 3.0.0 (CommonMark + tabela + tachado) provada nas 259 fatias (532 de 532 tabelas, 4 s); 40 bancadas/telas autossuficientes (fontes por caminho relativo já publicado; 7 ainda chamam o Google Fonts → VT-P1); 68 de 69 seções de componente citadas por alguma bancada; 07-pecas com 187 MB (168 templates HTML = 150,8 MB; 165 PNG = 44,7 MB), VM com 87 GB livres e subida de ≈ 8 MB/s; changelogs em quatro formatos; 21 critérios WCAG citados no canon. Desenho: gen-vitrine.py → 10-publicacao/vitrine/ servido na raiz por try_files, páginas de canon a partir das fatias (o .md da F9.1 não muda de endereço), camada de máquina MK2–MK5/MK10, guarda VT-1…VT-10; custo 5,5–7 sessões. Gate de abertura com duas perguntas: V-D (o desenho, rascunho renderizado com os tokens reais a 1280 e 390 px) e V-Q1 (publicar as peças originais, 185 MB, ou só miniaturas). Pendências VT-P1–VT-P3 registradas.Só endereço de seção, nenhuma decisão muda (F91-P2, MANIFESTO §157):
texto inteiro da versão
Só endereço de seção, nenhuma decisão muda (F91-P2, MANIFESTO §157): o bloco da errata v0.12 repetia o título "## 4. EM1 — camada de tokens resolvidos" — o arquivo tinha dois §4, e um agente que citasse "§4 do seed-email" não sabia qual. O bloco da errata passa a §4-a; o §4 original fica único. Achado pela camada de IA (F9.1), que fatia os canônicos por seção. (O registro pulou a 0.12 aqui porque a errata de 2026-08-14 já usava esse número no próprio título.)
2026-09-04
A ONDA 3 FECHA E ENTRA NO CANÔNICO — nove specs novas (§12.22–§12.29 + §12.2-b), e com ela a F8 inteira.
texto inteiro da versão
A ONDA 3 FECHA E ENTRA NO CANÔNICO — nove specs novas (§12.22–§12.29 + §12.2-b), e com ela a F8 inteira. Última decisão aberta respondida em 2026-09-04 (MANIFESTO §142: R6-U1 "Linha 2 — cor da marca" · R6-U3 "20 mm" · R6-REM "aprovo a remoção (…) deve ficar salvo e registrado o desenho aprovado de todos os lados do carro" · R6-VETO "todos ficam"). ⭐⭐⭐ §12.22 FROTA — a peça que ele apontou como faltante nasceu do zero, foi REPROVADA por erro de categoria ("pensar na adesivagem dos carros como peças de papelaria é errado") e voltou como arte final DITADA por ele: 4 veículos × 3 vistas, cordilheira em escala de lataria (F 353–419 mm, traço ≥ 9 mm), traseira pelo modelo da FOTO REAL da Strada e sem ondas, EEny pose 07, 5 áreas de foto a 150 DPI, contato a 45/45 mm; nasce a tipografia do contato (§138.1) — o bicromatismo da logomarca espelhado em 0800/site, com ícones e a segunda fonte na lista; a regra do formato veículo (9 itens) decidida e promovida. §12.23 UNIFORME/EPI — a E1 refina a MR-P11 ("podemos usar o amarelo, mas atendendo essas condições do padrao da propria logo"); 4 cores de escritório; a regra geral do bolso (com bolso → vertical no bolso; sem → horizontal); campo cinza com logo branca direto; boné = símbolo, chapéu/capacete = vertical; gola interna turquesa nas 4 decidida com estudo de mercado; colete refeito com prova de interseção no DOM (0 de 10) depois de o gate ver o número sobre a faixa — guarda que mede com a constante do gerador confirma o gerador. §12.24 ONE-PAGERS — dor→solução, coluna de foto, radar com fonte, 2 números ("+10 anos de mercado"), estatística redundante não se cria. §12.25 ROLL-UP + TOTEM — institucional clean + comercial A/B ("a da BV financeira…"), ondas canto a canto SÓ nas comerciais ("mas nao é regra"), zona de sacrifício 250 mm, toque de 0,00 mm no amarelo consertado. §12.26 FAVICON/AVATARES — as 5 decisões (® sempre · margem 0% · escuro colorido · 2 fundos oficiais · maskable 40% W3C); raster e capas de rede fora, por decisão. §12.27 PLACA DE INSTALAÇÃO CONCLUÍDA — voluntária pelo texto da lei, 2 tamanhos sub-múltiplos da chapa, sem amarelo ("nesse caso da placa sim"), QR real wa.me em 4-Q com segno 1.6.6 (leitura por celular é etapa do gate). §12.28 PORTFÓLIO — template com fotos em branco, sem RT ("a empresa é o foco"), rol de fotos. §12.29 AGENDA — o brinde mudou de veredito ("não precisa ter" → "gere um layout para agenda"): 3 capas, 2 contracapas, sem ano, Cidade/UF. §12.2-b MARCA D'ÁGUA — E1 explodida aplicada nas 12 peças, P3 cantos opostos oficial, símbolo medido pelo CORPO (a caixa do viewBox fazia 58 mm virarem 40), ® fora por recorte, tinta 700 nos números (o furo dos 4,60:1 contra o branco puro). §17: fecham os itens 4 (redesenho executivo — F8) e 7 (kit de favicon; capas de rede ficam como
FV-P1); o item 2 ganha matéria (quatro listas de fotos); nascem PI-P1, FV-P1/P2 (as demais divergências da auditoria de fechamento — gola no gerador, capôs de Saveiro/Strada, rename da folha da regra, PNG das institucionais, docstrings defasadas — foram resolvidas ANTES desta promoção, não nomeadas). Roadmap v2.3: F8 FECHADA, três ondas; próximo = F9. Nenhum hex muda, nenhum vetor muda.F8 FECHADA — a Onda 3 fecha 7 de 7 em seis rodadas de gate (MANIFESTO §136–§142), e o §12 do marca-seed.md vai a 30 specs (v5.32: §12.22–§12.29 + §12.2-b).
texto inteiro da versão
F8 FECHADA — a Onda 3 fecha 7 de 7 em seis rodadas de gate (MANIFESTO §136–§142), e o §12 do
marca-seed.md vai a 30 specs (v5.32: §12.22–§12.29 + §12.2-b). O que a onda deixou de regra além das peças: tipografia do contato (§138.1), regra do formato veículo, regra geral do bolso, moldura ampla (v5.30), marca d'água de contorno (E1 aplicada, P3 oficial). Corrigido: "8 itens ≈ 16 peças" → 7 itens (3.4 saiu em 27/08). Próximo: F9 — publicação e camada de IA/GEO. Regra que fica reafirmada: este arquivo se atualiza NO FECHAMENTO da onda — esta edição é o próprio fechamento.2026-09-03
O diário de obra perde o furo (R5-M3, §140)
texto inteiro da versão
O diário de obra perde o furo (R5-M3, §140) — "nao se usa mais furo": corpo a 7 mm como o rodapé, colunas proporcionais em 196 mm; §12.15 anotado. Na mesma rodada, sem mudança de canon: a repetitiva oficial da marca d'água é a P3 (cantos opostos), a E1 segue aplicada; o colete foi refeito com prova de interseção contra as faixas refletivas (a folga declarada antes media uma constante errada do gerador — §141.1); a gola interna ganhou estudo de mercado antes da decisão (§141.2).
2026-08-31
A MOLDURA AMPLA promovida ao §12.2 (R4-M2, MANIFESTO §139)
texto inteiro da versão
A MOLDURA AMPLA promovida ao §12.2 (R4-M2, MANIFESTO §139) — margem 7 mm (o limite é a zona de exclusão X da logo, 6,72 mm medidos no asset), cabeçalho 29, rodapés 33/22/8, área útil 196×227/241/256 a partir de (7,29); +24,6% de área no orçamento. Propagada à família inteira (~45 peças regeneradas, colisão medida no DOM em todas: laudo e checklist tinham tabelas presas em 170 mm e foram realargadas com conta declarada). Nasce junto: a marca d'água de contorno do símbolo EXPLODIDO (360 mm, sangrando as 4 bordas, ® fora por conta) na família orçamento/proposta/portfólio, e a tinta dos números de seção sobe de turquesa-600 para 700 — o furo achado na re-medição: 600 mede 4,60:1 sobre o branco PURO, e qualquer véu o derruba (régua nova: contraste se confere contra o pior fundo que a peça admite).
2026-08-27
A ONDA 3 ABRE, por ordem dele ("Vamos abrir a 3 onda, tudo em paralelo") — e três vereditos moldam o escopo ANTES da produção.
texto inteiro da versão
A ONDA 3 ABRE, por ordem dele ("Vamos abrir a 3 onda, tudo em paralelo") — e três vereditos moldam o escopo ANTES da produção. ⭐ (a) o conteúdo dos one-pagers é produzido por mim ("vc deve produzilos, nao eu"), com fonte única no
sobreaseed.md — nada fora dele entra na peça (§14.1); ⭐⭐ (b) o item 3.4 (material próprio do Diagnóstico 360°) SAI da onda e do DS — veredito dele: é serviço que a SEED vende, não marca com identidade própria ("diagnostico 360 nao consigo ver ele tendo material de DS (...) é um serviço que vendemos"); ele vive como conteúdo dentro do one-pager de Consultorias; ⭐ (c) o portfólio nasce como TEMPLATE com área de foto em branco ("deixe em branco o local da foto") + lista das fotos necessárias entregue no fechamento — foto real é insumo de produção, não de DS. Escopo final da onda: 7 itens ≈ 15 peças (3.1 frota · 3.2 uniforme/EPI · 3.3 one-pagers ×5 · 3.5 banner/roll-up + totem · 3.6 kit favicon + avatares · 3.7 placa de instalação concluída · 3.8 portfólio + brinde). Registro operacional no plano-producao-pecas.md §6.OS MARCADORES DE ESTADO MENTIAM, E UMA PENDÊNCIA ESTAVA ÓRFÃ HÁ TRÊS DIAS — achado ao responder "quanto falta pra finalizarmos o DS?".
texto inteiro da versão
OS MARCADORES DE ESTADO MENTIAM, E UMA PENDÊNCIA ESTAVA ÓRFÃ HÁ TRÊS DIAS — achado ao responder "quanto falta pra finalizarmos o DS?". ⭐⭐⭐ A pergunta dele é respondida LENDO ESTA LISTA e o
seed-ds-roadmap.md, e os dois estavam defasados: (a) CT-P8, PF-P2, FT-P1 e GT-P1 foram fechadas na v5.27 e o fechamento foi escrito só no changelog — as quatro entradas continuaram marcadas ⏳, ou seja, quem lesse a fila veria como aberto o que fechou ontem (mesma classe da defasagem que o roadmap pagou em 2026-08-22, quando uma sessão quase reabriu trabalho concluído 11 dias antes); marcador corrigido para ✅ sem reescrever o texto do achado, que é registro datado (regra CP31). (b) ⭐ A SN-P10 nunca existiu como entrada: nasceu em 2026-08-24 dentro do PARÁGRAFO do §17.6 (perda de reconhecimento a distância da placa A3 NR-10 ao sair a tarja turquesa: logo 60 mm → legível a 1,75 m numa peça de 4,0 m) e três rodadas de "resolver tudo em aberto" passaram por cima dela, porque "em aberto" se lê NA LISTA. Agora tem entrada própria, classificada como decisão dele com custo em mm — sai com as duas opções renderizadas (§14.13). RÉGUA: pendência citada em prosa não existe; só existe o que tem entrada na fila, e ela entra no mesmo movimento em que é nomeada.A FILA ZERADA — dez pendências fechadas numa rodada, a mando dele ("resolva as pendencias em aberto, assim que acabar eu autorizo a onda 3").
texto inteiro da versão
A FILA ZERADA — dez pendências fechadas numa rodada, a mando dele ("resolva as pendencias em aberto, assim que acabar eu autorizo a onda 3"). ✅
CT-P8 — CT1 no acervo: 168 PASS · 0 FAIL (era 32 FAIL). Dois consertos: a peneira aprendeu que texto alfanumérico é rótulo (botões "1"/"2" da paginação saíam como ícone e tinta de dígito nunca centra na caixa — é tipografia, não desalinhamento), e os três glifos tipográficos usados como ícone (⋯ ‹ ›) viraram SVG de viewBox simétrico — ⭐ glifo de texto como ícone mede a tinta fora do centro porque a em-box posiciona pela linha de base. ✅ PF-P2 — nasce a guarda-preview-contraste.mjs (contrato PF2): piso 4,5 texto normal / 3,0 grande — mais duro que o 3,0 das bancadas, porque folha de decisão é texto de leitura. Cobaia dupla provada, e na estreia achou 7 defeitos reais na folha (os .ok verdes a 4,23 sobre fundos tingidos); consertados com os pares DO SISTEMA (feedback-success-text, text-muted): 122 medidos · 0 FAIL. ✅ IC-P1 — encerrada como FALSO REGISTRO: o par real mede 5,62 nos dois temas, a gi2 dá 22·0 em duas rodadas, o arquivo não muda desde a fundação — e a rodada que a registrou usava a gi2 pré-conserto do contrato de alvo, com a sonda de placar do §130.10. ⭐ Pendência nascida de rodada com instrumento depois consertado se re-mede antes de se trabalhar. ✅ GN-P1 — cinco instrumentos ancorados (o remendo sai do .gitignore junto com o defeito), e os 4 captura-*.mjs tinham defeito MAIOR escondido: apontavam para o Chrome do container do Cowork — instrumentos mortos com aparência de vivos. Leitura na fixture viva de 07-pecas/, escrita na área ignorada — ⭐ evidência não se regenera, se preserva. ✅ SN-P14 — a MM1-e ganhou alcance declarado (%/calc/transform saem nomeados — 7 blocos no acervo que eram silêncio) e o regex de px aprendeu decimal (o antigo lia "5px" de "10.5px": número errado com cara de medido). ⚠ E o conserto quebrou a guarda no caminho — âncora de edição sem a indentação completa des-indentou um try e a MM1 passou a medir NADA (0·0·0, exit 0); a §14.9 pegou. ⭐⭐ Âncora de edição em python COMEÇA no início da linha, com a indentação inteira. Placar final: 185·0, idêntico, mais a cobaia reprovando como deve. ✅ FT-P1 — nascem os subsets woff2 da SEED (subset-seed/, fontTools instalado): 25–34 KB/peso, cobertura provada por cmap (JetBrains 50/50 técnico + 86/86 vivos; Montserrat sem ✓✗ porque o original não os tem). A GL1 aprendeu woff2 via fontTools OPCIONAL (sem a lib, volta ao [n/a] honesto) — e de brinde passou a MEDIR as 18 históricas. As 4 peças migraram: ~3,1 MB → ~290 KB (10×), GL1/MM1/render/fonte-efetiva todos verdes. ✅ RL-P1 — a §5–§6 da ISO 3864-2 lida por inteiro (texto extraído do PDF dele): só a etiqueta de impedimento está no escopo, e CONFERE (combination label §6.5: texto abaixo do sinal, painel retangular, severidade opcional ausente). As outras três eram classificação errada da rodada anterior — ⭐ "é etiqueta" não faz de uma peça um safety label: a norma agrupa por FUNÇÃO (comunicar perigo), não por formato. ✅ RD-P1 — medida com o interruptor CHROMIUM_DETERMINISTA=1: quatro placares idênticos → não estender (placar de tela é invariante; instrumento de tela consome placar, não PNG). ✅ RD-P2 — não reproduz: 12 capturas em 12 processos separados, 12 MD5 idênticos. O fenômeno sumiu antes do isolamento, e encerrar assim é mais honesto que atribuir causa sem reprodução. ✅ AD-P5 — a convenção de MOCK DE TELA em 07-pecas/ vira texto (§12.15): superficie=tela + alvo-tela + estatuto + papel-irmao — a solução já existia de fato no exemplar. ⏳ PT-P2 e AD-P7 RECLASSIFICADAS: produção nova e decisão de escopo — fila da onda de aplicações, não de conserto. Chamar produção nova de pendência faria a lista nunca zerar, e lista que nunca zera deixa de informar.O MAPA MESTRE VOLTOU A FICAR PARA TRÁS — 5 dias desta vez, achado ao ele perguntar "quanto falta pra finalizarmos o DS?".
texto inteiro da versão
O MAPA MESTRE VOLTOU A FICAR PARA TRÁS — 5 dias desta vez, achado ao ele perguntar "quanto falta pra finalizarmos o DS?". ⭐⭐ Essa pergunta se responde LENDO ESTE ARQUIVO, e ele ainda dizia "Próximo: Onda 2" com a Onda 2 aprovada em 2026-08-26 ("1. todos aprovados", dez peças,
marca-seed.md §12.11–§12.21). É a segunda ocorrência da mesma defasagem — a v2.1 nasceu justamente de o arquivo estar 12 dias atrás. A diferença: em 2026-08-22 a defasagem foi descoberta quando quase custou trabalho refeito; agora foi descoberta ao tentar RESPONDER com ela. Esta edição registra: F8 com a Onda 2 fechada 9/9 (10 peças, duas fora do plano, nascidas de defeito achado na própria onda) + §12.9/§12.10 fora das ondas = 21 specs de peça aprovadas; e a Onda 3 destravada, 8 itens ≈ 16 peças, aguardando só a palavra dele. RÉGUA QUE FICA: o estado do projeto se responde do arquivo, e por isso o arquivo se atualiza no fechamento de cada onda — não quando alguém pergunta.2026-08-26
PV-P1 RESOLVIDA — a paridade das bancadas ZERA pela primeira vez (513 PASS · 0 FAIL) — e a fonte canônica consertou metade da CT-P8 de brinde.
texto inteiro da versão
PV-P1 RESOLVIDA — a paridade das bancadas ZERA pela primeira vez (513 PASS · 0 FAIL) — e a fonte canônica consertou metade da CT-P8 de brinde. (a) o .selo do base-bancada.css consome os dois feedback-info e o gen-banco-dominio era o único dos 9 gerados sem eles na lista NOMES — ⭐ quem consome CSS compartilhado herda a lista de tokens do compartilhado. (b) o banco-identidade consumia --seed-surface-default, que não existe; a intenção estava escrita no próprio template ("superfície neutra com fio de 1px") e o consumo passou ao --seed-surface-raised, que já estava na lista — nada criado (§14.1). ⭐⭐ E um efeito colateral medido que ninguém previu: a CT1 caiu de 32 para 16 FAIL. banco-data e tela-shell passaram a centrar os ícones depois de receber a fonte canônica — metade da CT-P8 era a métrica da fonte errada, não geometria. Restam banco-navegacao e tela-tabela (8 FAIL cada), que continuam na fila.A FONTE CANÔNICA PASSA A SER FORÇADA NO ACERVO INTEIRO — PP-P1-b resolvida, e o achado era maior que o enunciado.
texto inteiro da versão
A FONTE CANÔNICA PASSA A SER FORÇADA NO ACERVO INTEIRO —
PP-P1-b resolvida, e o achado era maior que o enunciado. Veredito dele: "podemos deixar o plano B, mas temos que forçar sempre a fonte canônica, nem que seja dando opção de instalá-la ou avisando que precisa instalar e dando o link". ⭐⭐ O achado que mudou o escopo: ZERO dos 42 arquivos de 05-html-de-referencia/ tinha @font-face — até a Montserrat dependia da fonte instalada no sistema, e funcionava nesta máquina por sorte. O mono rasterizava Consolas em 26 de 42. A solução por camada: peça impressa EMBUTE (comprovante e pasta A4, TP1, ~1,07 MB/peça declarado; assinatura de e-mail fora — cliente de e-mail não carrega @font-face) · bancada/tela ganha @font-face por URL RELATIVA para os TTF versionados (⭐ base64 nas 42 custaria ~45 MB para arquivos que nunca saem do repo; URL relativa dá o mesmo por ~1 KB) · nasce 03-assets/fontes/LEIA-ME.md com o aviso e o link que ele pediu. Aplicação pela §14.4: base-bancada.css cobre as 9 bancadas geradas; os 11 templates de tela regenerados; artefato direto só nos sem gerador (o banco-dataviz-dm com a nota da GN-P1). ⚠ Dois defeitos pegos no caminho: sete templates usam str.format() e as chaves {} do CSS viraram placeholder — ⭐ bloco inserido em template herda o mecanismo de escape do template; e o mede-fonte-efetiva.mjs chamava nó sem pixel de "recebeu outra" — nasce o veredito [sem-pixel], ⭐ não-mensurável é veredito próprio, nunca FAIL nem PASS. MEDIDO NO FIM (132 arquivos): 55 aplicam mono → 53 RECEBEM · 1 [sem-pixel] · 1 TROCOU: a assinatura de e-mail, a exceção declarada. Guardas nas 4 peças regeneradas: MM1 12·0 · GL1 4·0 · render 4·0 · PT 0 FAIL; paridade-previews mantém os MESMOS 2 FAIL pré-existentes da PV-P1 (não aumentou). A §4.5 ganha a nota: a pilha de reserva deixa de ser o mecanismo primário e vira plano B de verdade.AS CINCO COISAS QUE ELE LEVANTOU — quatro resolvidas, e o defeito que ele achou OLHANDO era meu.
texto inteiro da versão
AS CINCO COISAS QUE ELE LEVANTOU — quatro resolvidas, e o defeito que ele achou OLHANDO era meu. ⭐⭐⭐
SN-P8 CONSERTADA SEM COMPRAR, e a chave estava nos números da véspera. Ele decidiu "nao vamos comprar, use a melhor opcao conforme sua recomendacao". A medição já havia separado dois erros que eu tratava como um: a razão da caixa batia em ~1,7% — a silhueta estava certa — e só a espessura errava, em −12,1%. ⭐ Se o defeito é só espessura, o conserto não é redesenhar: é ENGROSSAR. Um stroke da própria cor não move nenhum dos 11 vértices — e é por isso que passou onde reconstruir vértices havia sido reprovado. Medido: espessura −12,1% → −2,3%, tinta −16,2% → −5,2%, forma 29,51% → 27,17% (W012) e 16,39% → 16,16% (W042). ⚠ A razão da caixa PIOROU (1,7% → 3,8%) e fica na tabela — conserto que melhora quatro colunas e piora uma não é gratuito, e omitir a quinta seria escolher a régua depois de ver o resultado. ⚠⚠ E eu quase publiquei duas réguas na mesma tabela: o instrumento do teste normaliza pelo preto (26,45%) e o do canônico pelo amarelo (29,51%). ⭐⭐ Comparação só vale DENTRO do mesmo instrumento — número de régua diferente na mesma coluna é comparação falsa, porque quem lê supõe a mesma unidade. ⚠ O resíduo está declarado NA PEÇA: 27,17% segue acima do piso de ruído de ~10%; os dois textos públicos foram reescritos no MESMO commit que mudou o número. ⭐⭐ A PERGUNTA DELE SOBRE A FONTE EXPÔS O DEFEITO MELHOR QUE EU: "porque estamos olhando Consolas x JetBrains Mono, isso é outra fonte sem ser as canônicas?". A JetBrains Mono é canônica desde 2026-07-30 (§4.2), com papel escrito — dados de medição, identificadores, código. Quem não é do sistema é a Consolas, que é o terceiro item da pilha de reserva da §4.5. ⭐ Não estamos escolhendo entre duas fontes: estamos vendo a fonte que o canônico manda perder para o plano B de emergência. Isso reduz a PP-P1-b de "decisão de gosto" a "quando eu conserto". ⚠⚠⚠ PF-P2 — ELE ACHOU UM DEFEITO DE LEGIBILIDADE OLHANDO, e o número dá 1,01 de contraste contra o piso 3,00: cinco <code> brancos sobre branco na folha que pedia decisão dele. Causa de classe: o code declarava background e não color, então dentro do bloco escuro herdava tinta clara e mantinha fundo claro. ⭐⭐ Régua: fundo e tinta se declaram JUNTOS, sempre. Consertado e medido: 274 elementos, mínimo 4,23, zero abaixo do piso. ⚠ E a lacuna estrutural fica aberta: preview/ é isento das guardas de contraste — ⭐ rascunho que serve de base para o decisor decidir não é rascunho. ✅ GR-P10 RESOLVIDA com UMA LINHA, e o quase-erro vale mais que o conserto. Eu ia copiar 14 arquivos da pasta do Drive antes de ele deletar — até conferir por MD5 e descobrir que 12 de 12 já estavam no repositório. ⭐⭐⭐ Antes de resgatar um arquivo, conferir se ele já está salvo em outro lugar: o resgate errado teria plantado aqui dentro a doença que estávamos tirando de lá — duas cópias graváveis do mesmo material. Placar GR1 21 · 0 · 7 de 7 alvos — a guarda roda pela primeira vez neste repositório. ✅ GT-P1 — DELEÇÃO LIBERADA, e por MEDIÇÃO. Conferido por MD5 (135 idênticos · 172 canônicos antigos · 629 de evidência) e por EXECUÇÃO (33 instrumentos rodados; 6 morrem por falta de arquivo e nenhum pela pasta do Drive). ⭐⭐⭐ E o caminho ensina: minha primeira análise disse 75 dependências e a segunda disse zero — as duas erradas. Foi a linha de conferência contra a prova empírica que salvou. Quando duas análises estáticas seguidas erram, o problema não é o regex — é o método: dependência em runtime se mede EXECUTANDO. ✅ GT-P2 — a subpasta assistente de email não tem relação com o projeto: é pasta de 2026-05-04 de outro projeto, e o DS nasceu dentro dela em 2026-08-22. Renomear é seguro — nenhum arquivo versionado cita o nome e nenhum código depende do caminho.AS TRÊS DECISÕES DELE, APRESENTADAS COM O VISUAL E O NÚMERO — e uma correção de afirmação falsa que eu escrevi ontem neste arquivo.
texto inteiro da versão
AS TRÊS DECISÕES DELE, APRESENTADAS COM O VISUAL E O NÚMERO — e uma correção de afirmação falsa que eu escrevi ontem neste arquivo. ⭐⭐⭐ A cobrança que gerou esta versão nomeia um erro de leitura da §14.13 que eu vinha repetindo. Ele disse: "porque nao me apresentou as peças pra eu ver a diferença, vc disse que muda as peças, mas nao fez nenhum comentário sobre" e "eu pedi para ser mais claro no contexto da pergunta, vc precisa me explicar o que precisa e até recomendar algo para eu decidir". A §14.13 manda que toda pergunta ao decisor saia com o custo medido de cada saída — e eu lia custo como preço. ⭐ O custo de uma saída inclui o que ela muda no que já está aprovado, e isso não se enuncia: se olha. É a terceira vez que ele cobra a mesma classe de falha (antes na
GD-P1, "eu nao entendi se aqui é pra eu resolver algo ou só vc"). ⚠⚠⚠ A CORREÇÃO: a PP-P1 da v5.22 afirmava que "número em peça impressa continua em Montserrat com tabular-nums", e é FALSO. O gen-comprovante-ponto.py:190 pede var(--seed-font-mono) e o Chrome rasteriza Consolas — fonte da Microsoft que a peça não embute. A regra estava sendo desobedecida em silêncio, e o erro não foi de redação: eu deduzi de "a regra manda Montserrat" que "as peças estão em Montserrat". ⭐⭐ Régua: afirmação sobre o estado de uma peça tem de ser MEDIDA na peça, nunca deduzida da regra — mesma classe do defeito da §12.19, a placa que afirmava uma conferência que não aconteceu. ⏳ PP-P1-b apresentada com visual: nasce ferramentas/mede-fonte-efetiva.mjs, que mede pelo CDP a família que o navegador de fato rasterizou — não a que o CSS pediu. Das 90 peças, 22 aplicam mono a texto: 17 recebem a JetBrains (todas da era anterior, que a embute) e 5 recebem Consolas (as vivas). Custo medido: +9,12% de largura, zero transbordos, ~357 KB por peça. ⭐ Medir o CSS mede a intenção; medir o pixel mede o resultado — getComputedStyle devolveria 'JetBrains Mono' nas 22, inclusive nas 5 que desenham Consolas. ⚠ E um erro meu de instrumento pego antes de virar número: a medição acusou um nó 88,94% mais estreito, impossível numa monoespaçada; era o getBoundingClientRect de Range colapsando na última linha em texto que quebra. ⭐ Número fora do padrão dos irmãos acusa o instrumento antes do objeto — 56 nós entre +9,01% e +9,13% denunciaram o outlier. ⏳ GT-P1 apresentada, e a premissa dele estava invertida: o Drive não perdeu papel — ele é o disco onde o repositório mora (G: é File Stream; 399 MB e 1.309 arquivos de .git sincronizando). E a pasta de origem da migração continua gravável com 172 canônicos DIVERGENTES, entre eles marca-seed.md v5.11 — onze versões de atraso num arquivo com o nome certo, numa casa cuja regra fundadora é que metade das pesquisas é feita por IA. Medido: Drive de 1,8× a 2,6× mais lento; fsck passa nos dois. ⏳ FT-P1 REFORMULADA, e a reformulação inverte o pedido: o .woff2 leve já estava no repositório, escondido num data-URI de peça de gate — 12,6× menor — mas é recorte latin e não tem ≤ ≥ √ Ω Δ ≠ ■ ✓ ✗ ∅ ∞. ⭐⭐ Cobertura contra o acervo de hoje responde "quebra agora?"; contra o repertório da DISCIPLINA responde "vai quebrar?" — o empate em 86/86 me faria adotar o arquivo leve e plantar um defeito na primeira peça com um ohm. Ω e Δ são caracteres de trabalho em engenharia elétrica. E é o segundo achado da revisão da era Cowork: as 18 peças de gate dela embutem esse recorte incompleto. ⭐⭐ SN-P8 ganha a leitura que muda a conta: o W042 e o W012 compartilham o MESMO objeto de raio (RAIO_5036, constante única), então o "+0,5%" do W042 mede o conjunto e mascara o raio fino, e comprar só o W012 conserta os dois. Recomendação: CHF 60 (W012 + W042), não CHF 90 — os CHF 30 do P031 pagariam para confirmar o que já bate em +0,6%. O que justifica os CHF 60 é a linha de picos do W042, que está numa placa de arco elétrico e vem de desenho que a própria fonte não afirma ser oficial.AS CINCO PONTAS SOLTAS, e a maior delas inverteu uma pendência de meses.
texto inteiro da versão
AS CINCO PONTAS SOLTAS, e a maior delas inverteu uma pendência de meses. Ele mandou fechar antes da Onda 3: "é melhor voltarmos corrigindo pontas soltas do que ficar costurando coisas erradas o tempo todo". ⭐⭐⭐
SN-P8 — o pictograma que o projeto tratava como sólido é o que está 12% errado. A SN-P12 perguntava se a linha de picos do W042 (fonte única) estava certa; medido contra a arte oficial da ISO, o W042 confere (espessura +0,5%, discordância de forma 16,4%), o P031 confere (anel +0,6%, 9,65%) e o W012 DIVERGE: 12,1% mais fino, com 29,51% de discordância — três vezes o piso de ruído que o P031 estabelece. ⭐ A causa é erro de raciocínio, não de execução: o raio foi desenhado da IEC 60417-5036, e reaproveitado não é idêntico — a ficha do W042 diz "Relâmpago (da ISO 7010-W012)" e o W012, adotado da IEC, não preservou a proporção de traço. A razão da caixa bate em 1,4%: a silhueta é a mesma família, o que difere é a espessura dos membros. ⭐⭐ E o caminho que destravou isso era gratuito o tempo todo: a ISO 3864-3:2024, na NOTE 2 da Introdução, diz que todos os sinais estão no OBP da própria ISO. Uma tentativa anterior tomou HTTP 403 e o projeto registrou "o catálogo responde 403 a acesso automatizado" — frase certa, conclusão falsa: não era paywall, era user-agent. ⭐ 403 não é "não tenho acesso": é "não me identifiquei como quem tem". ⚠ O conserto do W012 NÃO foi feito, e o motivo é medido: reconstruir os vértices do PNG de 200 px foi tentado e reprovado — melhora a espessura (9,7% contra 12,1%) e destrói a forma (Jaccard cai de 0,74 para 0,56), porque o Douglas-Peucker só fecha em 11 vértices com 5,7% de tolerância. Trocar erro conhecido de espessura por erro maior de forma é piorar com aparência de conserto. Fecha com o vetor oficial: CHF 30,00 por símbolo no OBP — decisão de gasto dele, e a peça imprime o número. ⭐ Achado de brinde, e é shall: as fichas oficiais do W042 e do P031 exigem sinal de texto suplementar por falta de dado de teste ISO 9186-1. As duas peças já cumprem — mas cumpriam por acidente de composição. Agora o requisito tem nome, e regra com nome sobrevive ao próximo redesenho que "limpa" o texto. ✅ PQ-P2 FEITA: nasce a §12.21, a cartela de identificação de dispositivo DENTRO do quadro (IEC 61439-1 §6.3), 120+40 tiras por A4 no passo de 17,5 mm do trilho DIN. Três defeitos nela pegos pelo gate visual, e o primeiro vale régua: display:flex num container de texto corrido quebra o parágrafo em cada tag inline — o rodapé saiu com "deve", "devem", "devem" em linhas sozinhas e transbordando a margem. ✅ PP-P1 RESOLVIDA: JetBrains Mono v2.304 versionada (400/500/700, OFL), com cobertura de glifo medida antes de declarar — 1363 glifos, todo o repertório técnico presente, e exatamente um ausente (U+2011, com zero ocorrências no acervo). ⚠ Isso resolve disponibilidade, não uso: passar as peças a consumir --seed-font-mono muda a aparência de dez peças aprovadas e é decisão dele. ⭐ Destravar um recurso não autoriza gastá-lo. ✅ GD-P1 RESOLVIDA, e ela era 100% minha — ele teve de pedir clareza: "seja mais claro no que disser, eu nao entendi se aqui é pra eu resolver algo ou só vc". Nasce alvosHtml() no ambiente.mjs e 12 instrumentos passam a usá-lo. O defeito tinha classe própria: onze guardas descartavam em silêncio todo argumento que não terminasse em .html e caíam na varredura do acervo. ⭐ Não é quebrar nem dar veredito falso: é medir outra coisa e não avisar — o placar sai verdadeiro e a leitura de quem pediu sai falsa. ✅ A REVISÃO DA ERA ANTERIOR, que ele pediu antes da Onda 3, tem número — e é boa notícia. Nasce o censo-era-cowork.py: 18 de 88 peças físicas (20%) são invisíveis para a guarda de token e para o render, e todas as 18 são evidência de gate histórica — nenhuma peça viva está na lista. ⚠ E o censo reprovou em bloco duas vezes antes de acertar: primeiro cobrando de bancada o que só peça deve ter (43 falsos positivos em 54), depois acusando a assinatura de e-mail, cuja isenção já estava escrita na §12.8. ⭐⭐ Caminho não é classificador de tipo: 07-pecas/ guarda peça física, fragmento de e-mail e evidência histórica — três naturezas na mesma pasta. E o render-peca.mjs deixa de reportar 4 FAIL crônicos e passa a dar-lhes veredito [hist], como a PF-01 já fazia.O GATE DA ONDA 2: as dez peças entram no canônico (§12.11–§12.20), e a décima não estava no plano.
texto inteiro da versão
O GATE DA ONDA 2: as dez peças entram no canônico (§12.11–§12.20), e a décima não estava no plano. O veredito dele, verbatim: "1. todos aprovados". Para quem lê sem ter visto a conversa: a Onda 2 produziu nove peças em 2026-08-25 — laudo, memorial, checklist, selo de prancha, ART/diário, as-built, crachá, etiqueta e sinalização —, e elas ficaram em
07-pecas/ sem seção canônica, porque a regra §0-b não deixa regra de marca nascer sem veredito dele. Esta versão promove as dez. ⭐⭐ A DÉCIMA nasceu de uma pendência que ele REFORMULOU em vez de responder. A SN-P13 perguntava se quadro elétrico isolado precisa de placa de advertência própria (medido: exigiria A2 — em A4 paisagem estoura 138 mm, em A3, 59 mm). Ele respondeu outra coisa: "os quadros eletricos possuem placas de fabricação e identificação, que pode ser um placa da seed, ela motra a tensao do quadro e pode ter mais alguma informação." Nasce a §12.20 — placa de identificação do quadro, 100 × 70 mm, com a SEED na condição de fabricante do conjunto. A pergunta certa não era "que sinalização falta?", era "que placa a norma já exige de nós e nós não estávamos fazendo?". ⭐ E a lacuna estava anotada no acervo desde a Onda 2: o gen-etiqueta.py já dizia por escrito que "esta etiqueta não substitui a placa de dados do fabricante" — a peça que ela dizia não substituir simplesmente não existia. ⚠⚠ E o achado normativo da §12.20 contraria o que o mercado repete. Lida a IEC 61439-1 Ed. 2.0 (2011-08), cláusula 6.1, a etiqueta do conjunto exige quatro informações e só quatro: nome/marca do fabricante · designação de tipo ou nº · meio de identificar a data de fabricação · IEC 61439-X. Tensão, corrente, frequência, Icc e IP não estão nela — a cláusula 6.2.1 manda esses dados para a documentação técnica. Três páginas brasileiras afirmam o contrário e nenhuma cita cláusula. A norma foi lida; as páginas, não. A peça traz os dados elétricos assim mesmo, por decisão dele e pela NBR 14039 4.2.5.3, e imprime na própria placa qual metade é obrigação e qual é escolha — peça que mistura o obrigatório com o escolhido, sem dizer qual é qual, transforma decisão nossa em norma alheia. ⚠⚠⚠ A CORREÇÃO MAIS SÉRIA DESTA VERSÃO, e ela é na §12.19: a placa de sinalização AFIRMAVA uma conferência que não aconteceu. O SVG do W042 saía com data-conferido-visualmente="sim, contra a arte oficial (…) p.405, em 2026-08-25". Duas vias independentes desmentem: (a) o extrato da leitura da norma tem a seção "O que foi conferido" com duas entradas, W012 e P031, e cita o W042 na seção de ações; (b) a data é anterior ao desenho — o W042 nasceu no commit de 2026-08-26. ⭐ Não se confere visualmente um desenho que ainda não existe, e a data que estava ali para dar credibilidade é o que derruba a afirmação. ⭐⭐ A classe importa mais que o caso: o W042 foi acrescentado a três listas que já diziam "FEITA e CONFERE" (o texto impresso, o metadado e o stdout) e herdou o verbo de graça — acrescentar item a uma lista de coisas verificadas propaga o veredito sem propagar a verificação, e o custo de conferir some no meio da vírgula. Custo máximo aqui, porque isso sai impresso numa placa de segurança que alguém pode mostrar a um órgão. SN-P12 fechada com decisão, não com fonte: a busca por uma segunda digitalização da linha de picos achou algo pior — a única fonte que existe se declara "similar to recommendation issued in ISO 7010:2019", obra própria de terceiro. ⭐ "Fonte única" quer dizer que ninguém confirmou; isto quer dizer que a própria fonte não afirma ser a oficial. O W042 fica, porque sem ele a placa cita o item 10.7.7.1 b) da NR-10 (choque e arco) e cumpre metade — pictograma aproximado que comunica "arco elétrico" protege mais que a ausência de pictograma. Fecha com ~5 min de leitura da p. 405, numa assinatura paga por tempo, e não foi feito porque ele perguntou em 2026-08-25 se ainda precisava dela e a resposta foi não.A CAMADA 3 FECHA (SG1 a ZERO FAIL) e a COLISÃO DE ALTURA, aberta em 2026-08-15, é RECONCILIADA.
texto inteiro da versão
A CAMADA 3 FECHA (SG1 a ZERO FAIL) e a COLISÃO DE ALTURA, aberta em 2026-08-15, é RECONCILIADA. Para quem lê sem ter visto a conversa: a entrada v1.22 desta mesma tabela terminava com uma lista chamada "o que fica para a sessão principal" — decidir o par dark do
divider-strong, marcar switch-off-bg/slider-track como medição pendente, fixar a curva do ease-out, isentar o input-affix e abrir a pendência do estado OFF no tema claro. Esta versão fecha a lista inteira, e vale dizer por quê: lista de pendência que ninguém fecha vira lista de desculpa, e a única prova de que ela servia é ela acabar. Todas as seis decisões vieram do Rafael em 2026-08-26, no gate das nove peças da Onda 2. ① O SWITCH — e a medição achou três coisas, não uma. Ele decidiu: "acredito que tem que conseguir um tom que atenda o piso. analise e decida". (a) O tom é cinza-500 #788F9D = 3,38:1, primeiro degrau da escala acima do piso — o cinza-400 ainda reprova, com 2,53. Zero cor nova (§14.1). (b) ⭐ Medir "3:1 sobre a página" era medir METADE do componente: o thumb é BRANCO, e branco sobre cinza-300 dá os mesmos 1,91 — o thumb sumia dentro do trilho, e a posição do thumb é o único canal que separa ON de OFF (K3: nunca "ON/OFF" escrito no trilho). Cinza-500 conserta os dois pares de uma vez. (c) ⭐⭐ No tema ESCURO quem reprovava era o estado LIGADO, não o desligado — thumb cinza-100 sobre o trilho ligado dá 2,25 — e ninguém tinha visto porque a cláusula só mandava medir o OFF. A saída não precisou de cor nova: "o que vai sobre a superfície de ação" já é par medido e canonizado (--seed-text-on-action-primary), e o thumb de um switch ligado é exatamente isso — 7,39:1. Nasce --seed-switch-thumb-on; no claro ele coincide com o thumb desligado, e isso é a regra colapsando, não duplicação. (d) Dois erros de NOME na mesma linha da spec, consertados junto: ela apontava para --seed-action-primary-bg, o token fantasma da FF-P2/FF-P3, e dizia "turquesa-400 sobre dark" quando action-primary escuro é #66D1C2 = turquesa-300. ⭐ Spec que aponta para nome morto passa em toda guarda de valor, porque não há valor nenhum para conferir. ② O SLIDER tinha a mesma doença, e ela só apareceu porque o switch foi medido — cinza-300, os mesmos 1,91. Passa a cinza-500. ⚠ Mas aqui a saída é diferente, e a diferença importa: nenhum degrau atende os dois pares, porque o vazio precisa ficar longe do branco da página e longe do turquesa do preenchido, e o turquesa-600 mora no meio da escala (cinza-300 dá 2,40 contra o preenchido, cinza-500 dá 1,36). A decisão não foi escolher o menos pior; foi ver o que cada par carrega: o valor tem canal textual garantido pela própria spec ("valor corrente visível SEMPRE") e canal de forma no thumb de 24px com borda, então a divisão preenchido/vazio é o terceiro canal e fica decorativa declarada, com o número escrito (1,36 claro / 2,59 escuro) — mesmo tratamento de card-border e divider-color. Exigir 3:1 ali seria criar cláusula que o canon nunca teve, e cláusula nova é decisão dele. ③ E OS DOIS TINHAM O MESMO DEFEITO ESTRUTURAL, que era o que ele já havia apontado: --seed-switch-off-bg e --seed-slider-track eram declarados só no tema escuro e com escopo de elemento ([data-theme="dark"] .seed-switch{…}) — e como não existiam no gêmeo, no tema CLARO o var() não resolvia e o controle ficava sem fundo nenhum. Com o token no gêmeo, as duas regras de escopo somem e o defeito morre pela raiz. ⭐ Token declarado só num tema não é "tema faltando" — é um estado que não existe na metade do sistema. ④ A CURVA: ele mandou "teste os 2 e decida", e o teste devolveu uma resposta melhor que "escolha um". Resolvendo o bézier em 21 instantes de um movimento de 120 ms e convertendo para tempo — porque milissegundo é o que o olho pode ou não perceber, e "parecem diferentes no papel" não é medida de nada: .2,.8,.4,1 e .2,.7,.3,1 diferem no máximo 1,5% do percurso e 0,3 ms. A 60 Hz um quadro dura 16,7 ms, então a diferença é 1/56 de quadro e não existe em nenhum monitor — eram dois nomes para a mesma curva. Escolhida a de maior uso (3 artefatos contra 2), que também faz o conserto ser de 2 arquivos e não 3. ⭐⭐ E o mesmo teste respondeu a pergunta que ninguém tinha feito: --seed-ease-out deve existir, ou era apelido de --seed-ease-productive? Contra o productive a diferença é 36,8% e 24,9 ms — 83 vezes maior que a diferença entre as candidatas. São curvas diferentes de verdade, então o token merece existir. Sem o número, isso se responderia por gosto. ⑤ O DIVISOR FORTE: a v1.22 recusou emiti-lo, com um argumento bom — e o que mudou não foi a opinião, foi a medição. A recusa se apoiava no "1,91 light" da spec. ⚠⚠ Esse número não existe: medidas as cinco superfícies do tema claro contra o border-default, nenhuma dá 1,91 (page/raised/overlay = 1,49; subtle 1,37; sunken 1,23). O número foi transplantado — 1,91 é o que o border-subtle escuro dá sobre a página escura. ⭐ O número estava certo em algum lugar do arquivo; só estava grudado no token errado. E o irmão só batia porque foi medido contra outro fundo: o "1,75 dark" do divider-color não sai da surface-page (1,91) — sai da surface-subtle. ⭐⭐ Régua: contraste sem fundo declarado não é um número, é uma família de números — e foi variando o fundo, uma condição por vez (§14.5), que os três valores se explicaram. Sem o 1,91, o cinza-600 do consumidor vivo se revela dialeto local e vale a regra simétrica do irmão: border-default nos dois temas (1,49 / 2,84, decorativo declarado). ⑥ O --seed-input-w-md NÃO foi emitido, e a saída certa não era nenhuma das duas que a SG1 oferece. O nome aparecia uma vez, num exemplo de HTML da §2.5: style="max-width:var(--seed-input-w-md,320px)" — um var() apontando para um token que nunca existiu, que é o mesmo defeito do switch. ⭐ Exemplo de código num canônico é código que alguém copia; citar nele um var() que não resolve não é citação, é ensinar o defeito. O exemplo passou a escrever 320px direto e o nome saiu do canônico. ⚠ E aí nasceu a 6ª classe de falso positivo da SG1: o comentário que EXPLICA a remoção cita o nome, e a guarda reprovou de novo — com razão, porque para ela nome no arquivo é nome no arquivo. Reescrever o comentário sem o nome faria a guarda passar e apagaria a lição, trapaça que a isenção do --seed-tq-300 já proíbe. Isentado com o motivo escrito. As seis classes hoje: curinga · placeholder maiúsculo · classe BEM · contraexemplo documentado · nome de exemplo em diagrama · nome citado no registro da própria remoção. Todas dizem citar não é pedir. ⑦ A ALTURA DE CONTROLE — ele mandou "reconcilie para todos seguirem o padrão". De 2026-08-15 a 2026-08-26 o DS teve três réguas com dois números: 32/40/48 em --seed-control-* (v1.14, genérica, herdada do Fluent) contra 32/44/52 em --seed-button-height-* e --seed-field-height-* (fixados por escrito na §1.6 e na §2.5, com a decisão explícita "md = 44px (não 40px)"). O sm já coincidia. ⚠ O desempate não foi por gosto: medido, NENHUM artefato do acervo consome --seed-control-* — os três consumidores são a spec, a guarda de paridade e o gêmeo. A régua genérica era a de papel; vence quem tem spec. ⚠ E o argumento certo para o 44 não é o SC 2.5.8, que pede 24×24 (AA) e que 40 também cumpriria: o 44 é fundamento próprio do DS, mais generoso que a norma — e é por ser decisão nossa que ele precisava ser reconciliado em vez de deduzido de fora. O preset compacto (28/32/40) não muda: é densidade para tela de dado com mouse, e fica abaixo do alvo de toque de propósito. PLACARES. SG1: 140 PASS · 7 FAIL · 6 [isento] → 147 PASS · 0 FAIL · 7 [isento] — a camada 3 não tem mais nenhum nome que o canon cite e o gêmeo não defina. paridade-tokens.py: 103 → 110 PASS · 0 FAIL. ⚠ E esta é a primeira leva que NÃO é adição pura — as v1.21 e v1.22 podiam se gabar disso; esta muda dois valores, e o G1 acusou, exigindo supersede declarado (SUPERSEDES_V123_ROOT). Declarar é o preço de mudar valor, e o preço é barato. :root 323 → 330 (+7), dark 129 → 135 (+6). ⭐ E a linha info: do G6, que desde a v1.22 imprimia "COLISÃO DECLARADA de altura" a cada execução, passa a imprimir "RÉGUA ÚNICA desde a v1.23: md=44px · lg=52px nos três grupos" — e continua imprimindo os três pares, de modo que, se algum dia um deles derivar, a divergência aparece na mesma linha que hoje diz que não há nenhuma. O oposto de declarar um problema não é silêncio: é declarar que ele fechou. CONSUMIDORES. As duas bancadas que carregavam a curva divergente (banco-feedback, banco-superficies) foram atualizadas pelo reinjeta-tokens.py — ⭐ o build de quem não tem gerador fez sozinho o trabalho, e sem chance de errar um hex —, e o mesmo build apagou o dialeto do divisor (cinza-600 → #4D606C). ⚠ O que ele NÃO faz, por regra declarada, quase me custou as duas bancadas: ele não acrescenta token que o preview não consumia. Ao apagar as regras de escopo local do switch e do slider eu deixei banco-formfield.html consumindo var() de tokens que não estavam escritos nele — e o arquivo carrega cópia embutida, não lê o gêmeo. Os dez tokens foram acrescentados aos blocos :root e dark, e o reinjetor, rodado em seguida, confirmou 0 divergências contra o gêmeo. ⭐ Apagar dialeto local só é seguro depois de o canônico chegar ao arquivo — e num preview de cópia embutida, "chegar" quer dizer estar escrito nele.2026-08-25
AS DECISÕES DELE SOBRE A ONDA 2, e três delas mudam REGRA e não peça.
texto inteiro da versão
AS DECISÕES DELE SOBRE A ONDA 2, e três delas mudam REGRA e não peça. ⭐ NASCE A TERCEIRA VARIANTE DE RODAPÉ,
compacto (8 mm, uma linha de contato, sem grafismo, área útil de 241 mm), e com ela a regra de uso das três como [LEI]: ofício só para carta e correspondência formal; orçamento para documento técnico e comercial; compacto onde área útil é o recurso escasso. Verbatim dele: "o foco é otimizar a area útil para caber mais informação com o foco em diminuir o numero de paginas sempre". Quatro peças da Onda 2 estavam na variante errada, todas com o mesmo argumento plausível — argumento plausível não vence prioridade declarada. ⭐ E a variante nasceu de uma PEÇA, não de uma proposta: o rodapé de uma linha existia local no diário de obra e ele o reconheceu como padrão ("é um modelo de rodapé"). Ganho medido numa pasta real: 1 folha em 6, 16,7% menos papel. ⭐⭐ A MR-P12 DEIXA DE SER BLOQUEIO, e o que a substitui é uma FRONTEIRA que ele pediu: "o DS nao seria um template que depois onde fosse ser produzido seria visto as regras do local?". A fronteira NÃO é "produção × design" — é "MUDA O DESENHO × NÃO MUDA": a sangria de 3 mm e o piso de 0,25 mm são restrições de produção e mudam o desenho, então ficam; tolerância de faca, posição de furo e margem de vinco saem. O DS entrega o template e a lista declarada de restrições, nunca um "arquivo de produção". Cinco peças deixam de esperar. ⭐⭐ A §17.6 ganha a fronteira da peça que NÃO compartilha o campo visual, mas É o campo visual (veredito dele: "normal de segurança deve seguir as cores da norma de segurança, nao podemos impor nosso DS sobre isso"): em peça de segurança, quando a norma colide com a identidade, a NORMA GANHA. Na família NR-10 a assinatura é monocromática, pela NR-26 26.1.4. ⚠ E o que NÃO sai está declarado: tinta de texto fica — reduzir cor não é apagar tinta. Custo medido: contraste MELHORA (9,37:1 → 21,00:1) e o reconhecimento a distância piora só na placa A3 (1,75 m contra 4,0 m de premissa).AS DUAS PENDÊNCIAS DE DADO FECHARAM, e as duas confirmaram o canônico.
texto inteiro da versão
AS DUAS PENDÊNCIAS DE DADO FECHARAM, e as duas confirmaram o canônico. ✅ MR-P15: "o contrato está correto" — três itens separam o Essencial do Premium, não um; a peça já estava assim, então o veredito não mudou artefato, mudou o ESTADO da regra, de divergente para confirmada (divergência aberta convida a próxima sessão a "consertar" o que está certo). Fica registrado o que o Essencial NÃO tem — nem suporte por WhatsApp/telefone, nem apoio junto à concessionária —, porque é contraintuitivo: não se pode presumir que "todo plano tem um canal de suporte". ✅ MR-P14: o endereço de Governador Valadares é Rua Duarte Coelho, 205, e o canônico estava certo nas DUAS vezes em que foi questionado — primeiro contra o orçamento, depois contra o CONTRATO. Nenhuma peça alterada; a ação virou correção do material em circulação e do contrato que o cliente assina. ⭐ Régua: decisão tomada com uma evidência merece ser reapresentada quando aparece outra — e foi por NÃO ter sido alterado "para casar com o material" que o canônico seguiu servindo de referência.
O CONTRATO-MODELO FECHA AS CINCO LACUNAS DO SEED PLUS
texto inteiro da versão
O CONTRATO-MODELO FECHA AS CINCO LACUNAS DO SEED PLUS e a §12.10 passa a poder afirmar o que antes era proibido: o escopo da manutenção preventiva (reaperto de conexões e estruturas · medição de grandezas · limpeza de inversores, disjuntores e DPS · limpeza dos painéis), os prazos de execução (90 dias para a primeira, 30 para data fora da programação, 15 para verificar corretiva), renovação automática, reajuste, e que é VENDA ANUAL parcelada em 12×, não mensalidade. As obrigações do contratante entram nas observações — proposta que esconde a obrigação do cliente cria surpresa na execução, e surpresa chega como reclamação, não como aditivo. ⭐ A VALIDADE É POR TIPO DE SERVIÇO, não constante da empresa: função da volatilidade do custo — SEED Plus 10 dias, energia solar 5, porque o preço do material muda. Pesa mais na §12.7, que serve material E serviço. ⚠ MR-P15 aberta: ele afirmou que só a preventiva separa Essencial de Premium, mas o orçamento E o contrato trazem matriz idêntica com três itens de diferença — a peça segue os documentos, porque é o contrato que obriga. §12.9: as três peças antigas do cartão foram removidas com o ponteiro da §7.4-d repontado ANTES, e as evidências de gate ganharam veredito próprio
[hist] na PF-01.§12.10 A PROPOSTA DO SEED PLUS — a peça em que o cliente ESCOLHE.
texto inteiro da versão
§12.10 A PROPOSTA DO SEED PLUS — a peça em que o cliente ESCOLHE. Três folhas, itens 1 a 10 contínuos, matriz comparativa dos três planos (2 · 4 · 7 itens, do
sobreaseed.md §6) e um campo que a §12.7 não tem: PLANO CONTRATADO, destacado na folha que se assina — sem ele, o que foi contratado depende de memória. Preço por USINA, não por cliente. ⚠ A marca de "inclui" é Unicode explícito com aria-label, nunca fonte simbólica: o orçamento de origem usava Webdings (a = ✔, x = 🚫), e lidos como letras os dois não dizem nada — marca em fonte simbólica morre em extração de texto e em leitor de tela. ⚠ table-layout:fixed é obrigatório na matriz: no layout automático o width de célula é SUGESTÃO, e o navegador deu à coluna de descrição menos espaço que às de marca (48/41/41/41 mm), levando cada linha a 29 mm. §12.4 ganha a trava 7: nenhuma marcação aparece como texto na peça (guarda-escape.py, ES-01/ES-02) — três ocorrências num dia, todas por o contrato de escape não estar declarado, e uma delas estourou uma folha em 167,7 mm; ⭐ isinstance(str) NÃO é teste de "precisa escapar".A RODADA DE CORREÇÕES DELE SOBRE A ONDA 1 — e ela rendeu uma LEI NOVA.
texto inteiro da versão
A RODADA DE CORREÇÕES DELE SOBRE A ONDA 1 — e ela rendeu uma LEI NOVA. ⭐ §7.4-f: o grafismo de linha exige span ≥ 125 mm para cumprir o piso de 0,25 mm, medido em nove spans (78 mm → 0,157 · 124 mm → 0,249 · 125 mm → 0,251 · 170 mm → 0,342). Altura do divisor e espessura do traço são a MESMA grandeza, então não há como encolher um sem o outro — peça menor que 125 mm SANGRA o grafismo ou não o usa. §12.9 CARTÃO 90×50 refeito do zero por veredito dele ("nada é definitivo. se podemos melhorar, vamos melhorar"), e o erro que o fundou vale a lei: medi 0,250 mm nos arquivos antigos e concluí escala 1:1, mas eles usam OUTRA cena do grafismo — ⭐ medir o artefato antigo não substitui medir o INSTRUMENTO que vai gerar o novo. §12.7 a proposta virou UM documento numerado de ponta a ponta (itens 1 a 15 atravessando as duas partes, folhas 1 a 4 "de [N]", total como placeholder porque depende do preenchimento), sem duplicação entre as capas, com o RESUMO DO INVESTIMENTO e os OPCIONAIS subindo para a capa comercial e o PRAZO vindo da técnica para lá (art. 40 do CDC exige datas no ORÇAMENTO), e sem campo de assinatura na técnica — assinar duas vezes o mesmo negócio cria a dúvida de qual das duas obriga. §12.5 a grade de soluções da pasta refeita: cinco filetes curtos liam como cabeçalho de tabela; entram rótulo, UM fio contínuo e numeração 01–05. ⚠ E a régua do
<br> pegou o próprio autor — o comentário que eu escrevi ao lado dela afirmava uma largura que eu NÃO tinha medido.SEGUNDA LEVA DA CAMADA 3 — 19 tokens em seis grupos, e a classe da AD-P6 passa a ter INSTRUMENTO.
texto inteiro da versão
SEGUNDA LEVA DA CAMADA 3 — 19 tokens em seis grupos, e a classe da AD-P6 passa a ter INSTRUMENTO. Para quem lê sem ter visto a conversa: a v1.21 (mesmo dia) emitiu o primeiro grupo de componente dos gêmeos, o form-field, porque o
seed-componentes.md descrevia 21 tokens --seed-field-* que nenhum artefato podia consumir — a spec citava, o gêmeo não definia. Esta entrada fecha a mesma classe para os grupos seguintes. O que mudou no método, e é o mais importante desta versão: a pergunta "quais grupos ainda faltam?" era respondida por grep e memória, e errou por quatro caminhos diferentes numa única tentativa — família escrita com * (--seed-field-* não é um token), família com posição genérica (-N), classe CSS em BEM lida como token (o -- duplo de .seed-btn--primary) e contraexemplo documentado lido como pedido. Nasce então a guarda 06-validacao/guardas/guarda-spec-gemeo.py (contrato SG1), que varre os 01-canonicos/*.md e reprova todo custom property que o canon nomeia e o gêmeo seed-tokens.css não define, imprimindo nome, quem cita, quantas vezes e a linha de contexto. Placar SG1: 121 PASS · 29 FAIL · 3 [isento] antes desta edição → 140 PASS · 10 FAIL · 3 [isento] depois (cobertura: 153 nomes distintos em 10 canônicos, conferidos contra 323 definidos no gêmeo). OS 19 EMITIDOS, cada um com valor e origem. Botão (12), seed-componentes.md §1.6 l.126-148 — a spec escreve o bloco CSS inteiro, com o par dark explícito e a regra que o gerou verbatim ("token de componente que referencia primitivo DEVE declarar o par dark — primitivo não troca de modo sozinho", correção v0.5): button-radius 8px (= radius-md) · button-font-weight 600 (= fw-semibold) · button-height-sm/md/lg 32/44/52px (fixados) · button-gap 8px (= sp-2) · button-secondary-border turquesa-600 #098475 / turquesa-300 #66D1C2 · button-secondary-text turquesa-800 #005048 / turquesa-100 #CDF3EC · button-outline-border cinza-600 #617683 / cinza-400 #90A6B3 · button-ghost-text turquesa-700 #006C62 / turquesa-300 #66D1C2 · button-toggle-on-bg turquesa-800 #005048 / turquesa-300 #66D1C2 · button-toggle-on-fg #FFFFFF (único valor de cor da leva que a spec fixa em hex, não em alias) / turquesa-900 #00352F. Cartão (3), §26 l.1954: card-bg = surface-raised · card-border = border-subtle (borda decorativa declarada: 1,21 claro / 1,75 escuro, abaixo do piso 3,00 da SC 1.4.11 de propósito, porque a separação é carregada por espaço + raio + superfície + tipografia) · card-radius 12px (= radius-lg → radius-6). Divisor (1), §26-F l.1976: divider-color = border-subtle. Lista (1), §26-F l.2000: list-hover = surface-subtle no claro e o hex #273137 no escuro — a assimetria é da spec e foi preservada, porque #273137 é o surface-overlay do escuro, não o surface-subtle (#141D23), e é o que os quatro consumidores vivos renderizam. Item destrutivo de menu (1), §27 l.2181: danger-item = vermelho-700 #A5272A / vermelho-200 #FFC2BD. Espera (1), §17 R3-c l.1687: wait-delay 1000ms, número que a própria linha fixa por escrito ("default 1000ms"), fundamentado no limite de 1s de Nielsen, com revisão por telemetria real do ERP na F4 declarada ali como "pendência declarada, não decisão aberta". OS 10 QUE NÃO SE EMITE, com o motivo — e eles são a lição desta versão, porque nem todo nome citado é um pedido. ⓐ Três contraexemplos documentados (documentação de um defeito CITA o defeito, e citar não é pedir): --seed-button-primary-bg aparece só no diagrama de arquitetura do §1 deste arquivo e do seed-email.md ("3. COMPONENTE — exceção local"), como ilustração do conceito de camada 3 — e a §1.6, que é a spec real do botão, deliberadamente não o cria, porque o botão primário consome --seed-action-primary sem divergir (a regra do §1 daqui: "a camada 3 só nasce quando um componente precisa divergir do semântico"); --seed-input-affix está na coluna Descartado da tabela de decisões do §3.10 ("duplicaria help-text sem caso de uso divergente"), com a §3.6 dizendo em texto "Tokens novos: nenhum de cor"; --seed-danger-solid é nomeado no mapa-cobertura-ds.md §21 dentro da tabela da "cegueira de nome" — a mesma superfície vermelha sólida vive no acervo sob três nomes, e este é justamente o que carrega o valor divergente (#D94545 contra #C6393B), já registrado como pendência AC-P5 e MR-P3; emiti-lo canonizaria o defeito. ⓑ Quatro lacunas reais da spec (nome sem origem de valor declarada — §14.1: valor que não existe no canônico não se cria): --seed-input-w-md aparece uma vez, dentro de um exemplo HTML de style embutido, como var(--seed-input-w-md,320px); o 320px é fallback de CSS, não declaração, não existe escala de largura (-w-sm/-w-lg) e não há medição nem racional — emitir inventaria uma escala de um membro só. --seed-divider-strong: a §26-F fixa o alias (border-default) e mede 1,91 apenas no claro, sem declarar o par dark, e o único consumidor vivo (banco-superficies.html) usa cinza-600 #617683 no escuro, que não é o border-default dark (#4D606C) — emitir qualquer um dos dois lados criaria contradição com o consumidor ou invenção de valor. --seed-switch-thumb: a spec diz "branco / cinza-100", mas a bancada banco-formfield.html fixa #fff nos dois temas e não consome o token; divergência sem decisão registrada. --seed-ease-out: a spec o usa quatro vezes e nunca fixa a curva, e o acervo tem dois valores diferentes rodando — cubic-bezier(.2,.8,.4,1) em três artefatos e cubic-bezier(.2,.7,.3,1) em dois (medido por varredura nas bancadas); o gêmeo não tem ease-out, só ease-productive/ease-expressive. ⓒ Três de dependência circular com o fantasma: --seed-switch-off-bg e --seed-slider-track têm o alias condicionado a uma medição que nunca foi feita (a própria spec escreve "3:1 sobre a página: medir na produção do preview") — e o valor que ela propõe não passaria: cinza-300 #ACBECA sobre a página clara mede 1,91, medido aqui, contra o piso de 3,00 que a linha exige; o único consumidor declara só a metade escura, e com escopo de elemento ([data-theme="dark"] .seed-switch{…}), o que deixa o estado OFF do tema claro com background inválido — defeito real, medível, e que merece pendência própria. --seed-switch-on-bg tem como origem declarada o --seed-action-primary-bg, que é token fantasma isento na SG1 (FF-P2/FF-P3), e o valor dark que a spec lhe dá (turquesa-400) contradiz o --seed-action-primary vivo do tema escuro (turquesa-300 #66D1C2), que é o que a bancada de fato renderiza — além de o componente não divergir do semântico, o que pela regra do §1 proíbe criar a camada 3. VERIFICAÇÃO DE SUPERSEDE, feita antes de emitir cada valor (a régua que a v1.21 pagou caro: spec desatualizada que ninguém anota vira token errado). Três decisões posteriores foram achadas e nenhuma muda valor dos 19: CD-P7 (2026-08-17, fechada) decidiu que os 93 botões com borda abaixo de 3:1 não são defeito de SC 1.4.11, porque rótulo legível já identifica o controle — é veredito sobre conformidade, não sobre valor; MR-P1/MR-P2 (2026-08-17) reescreveram a tinta sobre fundo de marca, mas na família text-on-*, e o registro diz explicitamente que "o botão primário não muda de aparência"; CP-P4 (2026-08-15) supersedeu a forma de aplicar a borda do cartão (de border para o par anel-de-1px + sombra), sem tocar no valor do token. Os consumidores vivos foram conferidos um a um e concordam com a spec em todos os 19 — banco-componentes.html (l.406-411) já declarava os seis tokens de cor do botão com os mesmos aliases, banco-superficies.html os três do cartão e o divisor, quatro bancadas o list-hover e duas o danger-item. PLACARES, antes e depois. paridade-tokens.py: 85 → 104 PASS · 0 FAIL, com o gate novo G6 (irmão do G5: presença nos dois gêmeos, fidelidade alias→valor e espelho prefers-color-scheme idêntico ao [data-theme="dark"]); o G6 imprime a cada execução uma linha de INFORMAÇÃO com a colisão de altura, para que ninguém a descubra por acidente. G1 estrito contra o CSS v1.21 real: 0 sumidos, 0 alterados, :root 304 → 323 (+19), dark 118 → 129 (+11) — adição pura provada, não afirmada. paridade-previews.py: 505 PASS · 0 FAIL, inalterado. guarda-valor-gemeo.mjs (contrato AC5, artefato × gêmeo no Chrome real): 40 PASS · 0 FAIL nos dois lados, com a medição feita duas vezes variando UMA condição (o gêmeo) — contra o v1.21: 11 [achado], 5.556 valores comparados, 76 declarações de dialeto local; contra o v1.22: 10 [achado], 5.588 valores comparados (+32), 60 declarações de dialeto local (−16). Ou seja: 16 redeclarações que eram "dialeto local, ninguém confere" viraram valor conferido contra o gêmeo, nos dois temas, e todas passaram. PROVA DE CONSUMO (cobaia mínima no scratchpad, fora do repositório, ligada ao gêmeo real por file:// e sem repetir nenhum valor literal; Chrome real pelo contrato ambiente.mjs, medição por getComputedStyle): 38 PASS · 0 FAIL — 19 tokens × 2 temas. E a contraprova, que é o que dá sentido ao número: a mesma cobaia apontada para o gêmeo v1.21 devolve 0 PASS · 38 FAIL, com as cores caindo em rgba(0,0,0,0) e o delay em 0s — a camada é medida de verdade, e reprova quando não existe. COLISÃO DECLARADA E NÃO RESOLVIDA, com os três números lado a lado, para decisão do Rafael: --seed-button-height-md/lg = 44/52px (§1.6) e --seed-field-height-md/lg = 44/52px (§2.5, decisão explícita "md = 44px (não 40px)", alvo de toque WCAG) contra --seed-control-md/lg = 40/48px (v1.14, régua genérica de altura de controle). Dois números para o mesmo degrau da escala, agora em três grupos. Emitido como cada spec fixa; reconciliar é decisão de canônico, não dos gêmeos. O QUE FICA PARA A SESSÃO PRINCIPAL, porque é promoção de texto canônico e não emissão de token: anotar no seed-componentes.md que a §3.6/§3.10 já resolveram o input-affix (para a SG1 poder isentá-lo em vez de reprová-lo), decidir o par dark do divider-strong, marcar o switch-off-bg/slider-track como medição pendente, fixar a curva do ease-out num dos dois valores que já rodam, e abrir a pendência do estado OFF do switch no tema claro.A CAMADA 3 (componente) COMEÇA A EXISTIR NOS GÊMEOS — form-field, fecha a AD-P6.
texto inteiro da versão
A CAMADA 3 (componente) COMEÇA A EXISTIR NOS GÊMEOS — form-field, fecha a AD-P6. O defeito, medido:
seed-componentes.md §2.5 (validada pelo Rafael em 2026-08-02, v0.6/v0.7) especifica 21 tokens --seed-field-* com contraste medido par a par; seed-field- aparecia 116 vezes na spec e ZERO nos gêmeos — a camada era perfeitamente descrita e inconsumível, e o ERP (resultado nº 1 do projeto) consome exatamente ela. A emissão: adição pura (nenhum valor anterior muda), cada token gravado como o hex RESOLVIDO do alias que a §2.5 declara (ex.: field-label = cinza-900 #242E34), nos três blocos do CSS (:root, [data-theme="dark"] e o espelho prefers-color-scheme) e no grupo semantic.field do JSON — com UMA exceção obrigatória, achada pela verificação de colisão com decisão posterior: field-border NÃO segue a §2.5 l.400 (cinza-600), porque a CD-P2 (2026-08-17, fechada) a supersedeu — o alias vigente é --seed-border-interactive (cinza-500 #788F9D nos dois temas; medido 3,13 claro / 5,05 escuro, o local degradava na inversão 4,74→3,21), e a bancada banco-formfield.html já renderiza assim desde CD-P2; as variantes de estado (-hover/-error/-success/-warning) não migraram, por decisão da própria CD-P2. A colisão foi flagrada pela guarda-valor-gemeo.mjs, que comparou a emissão com o consumidor vivo — a primeira emissão seguia a §2.5 verbatim e reprovou. Estrutura fixada pela spec: alturas 32/44/52px — o md=44 é decisão explícita do canônico ("md = 44px (não 40px)", alvo de toque WCAG) e coexiste declaradamente com a régua genérica --seed-control-md 40px da v1.14; reconciliar é decisão de canônico, apontada ao decisor. Guarda nova: gate G5 na paridade-tokens.py — presença nos dois gêmeos, fidelidade alias→valor (se o token-base mudar e o field não seguir, reprova — mata a fossilização da classe "defasado e invisível" do reinjeta-tokens) e, pela primeira vez, o espelho prefers-color-scheme é lido por um gate (antes um token esquecido lá era invisível). Placar: 85 PASS · 0 FAIL (64 anteriores + 21 do G5); G1 estrito contra o CSS v1.20 real: 0 sumidos, 0 alterados, +21 :root / +15 dark. Prova de consumo no Chrome real (contrato ambiente.mjs): 6 tokens consumidos por uma cobaia de scratchpad (altura, raio, fundo, borda, ajuda, erro) e medidos no render por getComputedStyle — 9 medições · 9 PASS nos dois temas. Divergências INTERNAS da §2.5 achadas na emissão (spec escrita antes da implementação, registradas para o gate, não corrigidas aqui): (a) o comentário do readonly-bg claro diz "sobre cinza-50" e o surface-sunken vigente é cinza-100 #E3EBF0 (o alias vence, o número 12,75:1 está defasado); (b) as medições dark citam "dark-default #141D23", que hoje é o surface-subtle (a página dark é #0B1419) — e a bancada banco-formfield.html carrega --seed-field-readonly-bg: #141D23 LITERAL no bloco dark (resolução da era da spec), divergindo do alias vigente surface-sunken = #0B1419; (c) a §2.5 l.400 (field-border = cinza-600) está SUPERSEDIDA pela CD-P2 e a tabela da §2.5 nunca recebeu a anotação — promover a nota no seed-componentes.md é da sessão principal. Nota de lacuna desta tabela: as linhas v1.13–v1.20 nunca foram escritas aqui (mesma classe da errata que a v1.11 registrou e restaurou para v1.7–v1.10); lacuna apontada ao decisor em 2026-08-25 — não restaurada nesta edição porque reconstrução histórica não é emissão de token.2026-08-24
§90 e §91 EMENDADAS no mesmo dia (2026-08-24, tarde), por informação nova dele: o app de campo com cadastro OFFLINE e sincronização — OS e ponto — é decisão tomada, não hipótese.
texto inteiro da versão
§90 e §91 EMENDADAS no mesmo dia (2026-08-24, tarde), por informação nova dele: o app de campo com cadastro OFFLINE e sincronização — OS e ponto — é decisão tomada, não hipótese. Isso NÃO contradiz a decisão (c) do gate, que guardou exatamente a peça comum aos dois mundos, mas revela o que faltava: nascem OF10 (quatro estados por item — enviado · não enviado · sincronizando · falhou; a sincronização é evento COM RESULTADO que não some sozinho; o pendente é alcançável antes de sair do local; e nunca "sincronizado" otimista) e OF11/§90.11 — a OF-P1 deixa de ser hipótese e ⚠ o PONTO tem regra própria acima da LGPD: a Portaria MTP 671/2021 admite marcação offline com sincronização posterior, mas exige criptografia de 128 bits em trânsito E em repouso, comprovante ao trabalhador por marcação em PDF com assinatura PAdES (peça que não existe no inventário — PT-P1) e registro que não se altera. ⭐ E a emenda resolve uma COLISÃO REAL entre duas cláusulas aprovadas no mesmo gate: a CE4 manda travar o objeto que gera documento com ART, e não se adquire trava sem rede — a CE4-f separa COLETA (offline-first, sem trava) de EMISSÃO (online, com trava), e isso não afrouxa nada, porque dado que chega por sincronização não se mescla em silêncio: entra com autoria e horário, e quem assina decide. Nasce ainda a CE9, o conflito detectado na SINCRONIZAÇÃO — chega em lote, tarde e sem ação em curso, então é aviso assíncrono e nunca
alertdialog, nunca resolve sozinho, nunca descarta, e não vira trinta diálogos em sequência.**§90, §91 e §92 NOVAS (2026-08-24, F7.7-P5): os TRÊS ESTADOS que o §6.1 do mapa marcava ❌ AUSENTE desde a F7.1 passam a estável por cinco decisões dele no gate.
texto inteiro da versão
§90, §91 e §92 NOVAS (2026-08-24, F7.7-P5): os TRÊS ESTADOS que o §6.1 do mapa marcava ❌ AUSENTE desde a F7.1 passam a
estável por cinco decisões dele no gate. §90 OFFLINE (OF1–OF9): offline NUNCA se declara por flag — navigator.onLine devolvendo true não garante nada e desabilitar por ela travaria quem usa VPN, que é a nossa gente de campo — e são DOIS estados, "você está sem conexão" × "não foi possível alcançar o sistema", continuação direta da MC3 que ele decidiu na §89. A fila de ações fica como OF-P1 com a obrigação de LGPD escrita ANTES de alguém implementá-la, porque fila grava dado pessoal no dispositivo. §91 CONFLITO DE EDIÇÃO (CE1–CE8): detectar é obrigatório e é do servidor (ETag/If-Match/412 da RFC 9110 — aviso na interface não impede perda, informa); regime padrão OTIMISTA com aviso de presença que não bloqueia, e ⭐ exceção de TRAVA EXCLUSIVA para objeto que gera documento com ART, porque quem assina responde pelo que está lá e conteúdo mesclado em silêncio é risco que a interface não pode criar; três saídas no conflito, com as destrutivas sob MC4 e MC5. §92 LISTA LONGA (LL1–LL6), que FECHA A BU-P1: a regra nasceu de COBAIA porque a lista mais longa do acervo tem 38 itens e não exercita o problema; limiar MEDIDO em 2.000 linhas (um layout forçado custa 222–395 ms contra orçamento de 200 ms de INP); paginação é o padrão da lista de trabalho por ACHABILIDADE, não por desempenho; e ⭐ contenção nativa rende 5,87×–25,47× em blocos e NADA em tabela — mas getComputedStyle devolve auto nas duas, logo esta regra não tem conferência por declaração, só por tempo (LL-P1), terceira vez que a régua óbvia mente nesta casa.§89 NOVA (2026-08-24, F7.7-P4): a MICROCÓPIA DE INTERFACE é estável por CINCO decisões dele no gate — MC1 rótulo = verbo + substantivo · MC2 sentence case · MC3 voz do erro IMPESSOAL (com "nós" só quando a falha é da…
texto inteiro da versão
§89 NOVA (2026-08-24, F7.7-P4): a MICROCÓPIA DE INTERFACE é
estável por CINCO decisões dele no gate — MC1 rótulo = verbo + substantivo · MC2 sentence case · MC3 voz do erro IMPESSOAL (com "nós" só quando a falha é da SEED, porque o produto emite documento com ART) · MC4 confirmação com verbo específico (ele preferiu (a) à minha recomendação, e o custo enunciado no gate ficou escrito) · MC5 o corpo do diálogo declara a CONSEQUÊNCIA, não faz pergunta retórica. Mais 13 regras que a evidência ou o nosso canon já fechavam — a §10 da marca já proibia emoji e exclamação, então a §89 só propaga. A rodada de pesquisa (12 fontes, incluindo o guia de localização pt-BR da Microsoft e o guia do GNOME Brasil) mostrou que três "consensos" extraídos do produto medido eram DIVERGÊNCIA entre guias maduros: copiar o vizinho teria importado escolha alheia como lei. A §89.3 é a parte que só fonte brasileira resolvia: o registro verbal por elemento (infinitivo em botão, 3ª pessoa em tooltip, imperativo em instrução) e a distinção "não é possível" × "não foi possível". Sem guarda automatizada ainda — MC-P2 lista o que é mecanicamente verificável.A ONDA 1 DA F8 FECHA COM SETE PEÇAS — §12.5 a §12.8, todas estável.
texto inteiro da versão
A ONDA 1 DA F8 FECHA COM SETE PEÇAS — §12.5 a §12.8, todas
estável. §12.5 PASTA A4: capa de uma face, duas variantes que exercitam a matriz §5.1 (branco → logo principal; brand-deep → mono-negativo), logo ao centro pela §5.3; ⚠ NÃO é o arquivo de produção, porque a MR-P12 (margem de vinco) está aberta, e ⚠ NÃO é o F6-pasta-A4.html, que é evidência do gate do GRAFISMO em razão A4. §12.6 ENVELOPE (ofício 229×114 pela ABNT NBR 13314, saco A4 240×340 de mercado e declarado [não conferido]): ⭐ a regra que manda na peça não é da marca, é dos CORREIOS — 20 mm na base da frente são da máquina de triagem (guia CEPNet, ÁREA 4), e a serra para a 23 mm; três faces por formato, porque guia impressa em envelope é defeito de produção. §12.7 PROPOSTA: modelo PADRÃO e FLEXÍVEL fixado por ele (só material · só serviço · ambos; fotovoltaico e SEED Plus fora), DOIS documentos (técnica sem preço, comercial que não vale isolada), PRAZO como bloco próprio pelo art. 40 do CDC, e a moldura IMPORTADA do gen-timbrado.py em vez de copiada — o que se provou no mesmo dia, quando a correção PP-P2 propagou sozinha. §12.8 ASSINATURA DE E-MAIL, que NÃO é peça física e por isso não declara alvo-fisico: ela DERIVA do ea-assinatura.html com prova de derivação byte a byte, e a folha de gate mostra os quatro estados reais (com Montserrat, na pilha de reserva, com imagem bloqueada, a 320 px). ⚠ §12.4 ganha a regra 7: a evidência tem de ser FRESCA e isso se prova — quatro peças ficaram com o PNG de um commit anterior ao do próprio HTML, e nenhum instrumento olhava para essa relação.A CAMADA FÍSICA GANHA AS TRÊS PRIMEIRAS PEÇAS DA F8 — §12.1, §12.2 e §12.3, todas estável, com gerador, mock renderizado e regeneração byte-idêntica.
texto inteiro da versão
A CAMADA FÍSICA GANHA AS TRÊS PRIMEIRAS PEÇAS DA F8 — §12.1, §12.2 e §12.3, todas
estável, com gerador, mock renderizado e regeneração byte-idêntica. §12.1 PLACA DE OBRA [LEI] (Lei 5.194/66 art. 16 + Res. CONFEA 407/1996 — a lei fixa o CONTEÚDO e não a FORMA, e é isso que faz dela peça do DS): dois tamanhos, campos como placeholder, e ⚠ a MR-P11 morde aqui de um jeito não óbvio — o simbolo-principal.svg CARREGA o amarelo, então placa de canteiro usa o MONO-NEGATIVO; a violação estaria dentro do asset oficial. §12.2 TIMBRADO A4, cujo entregável é a ÁREA ÚTIL: 170 × 205 mm a partir de (20, 44), impressa no próprio arquivo para a proposta e o laudo LEREM em vez de redescobrir — o plano fixa que os três nascem dele. §12.3 COMPROVANTE DE PONTO (fecha a PT-P1): Portaria MTP 671/2021, REP-P, NSR, PAdES; a peça mais sensível do acervo em LGPD, porque a norma exige nome e PIS. §12.4 fixa o que passa a valer para toda peça física — incluindo a régua nova: ⭐ peça prova que consome token MEDINDO no navegador, nunca conferindo que a string está no arquivo (a guarda-peca-token.mjs nasce de um :root aninhado que fez uma peça inteira renderizar SEM NENHUM token, parecendo certa).A DP-P7 FECHA no mesmo dia em que nasceu, por veredito ("opção B é melhor"): o coropleto passa a desenhar a fronteira que o DP4 obriga.
texto inteiro da versão
A DP-P7 FECHA no mesmo dia em que nasceu, por veredito ("opção B é melhor"): o coropleto passa a desenhar a fronteira que o DP4 obriga. O
gen-dp.py deixou de tratar a variante coropleto no ramo dos municípios com obra (que no coropleto é vazio) e passou a desenhar em todos, como a completa. Medido depois: 1.348 fronteiras em #788F9D a 0,5 de espessura. A E19-b é o que permitiu o conserto sem FAIL. Nenhum hex muda, nenhuma decisão de cor muda — muda o que É DESENHADO.Nasce a E19-b — exceção declarada por veredito na fronteira geográfica sobre o sem-medição.
texto inteiro da versão
Nasce a E19-b — exceção declarada por veredito na fronteira geográfica sobre o sem-medição. O porte da camada de validação (F7.7-P1) mediu o que a E19 não tinha medido: no claro a tinta adotada rende 2,80 sobre
chart-no-data/surface-sunken (o par canonizado, sobre o contexto, segue 3,11 PASS). Veredito do Rafael, saída (a): aceitar como exceção declarada — a hachura é o segundo separador (1.4.11 cobra o par só quando ele é o ÚNICO identificador); mesmo veredito para cat-2-stroke × sunken (2,89), cujo segundo portador é a FORMA (E20). Candidatas medidas e descartadas: ci-600 (colide em valor com a hachura — estrutura E3) e ci-700 (dobra o peso do traço). NENHUM hex muda; a exceção vira categoria própria [exceção] no contraste-dp.py, com número impresso. Placar: 27 PASS · 0 FAIL · 3 exceções. A prova visual da decisão (mapa real, lupa 12× por captura) achou de carona a pendência DP-P7: a demo do coropleto não desenha fronteira nenhuma, contra o DP4 — e a E19-b é o que permite consertá-la sem criar FAIL.2026-08-23
§88 NOVA (2026-08-23, VIGÉSIMA SEXTA parte): a
texto inteiro da versão
§88 NOVA (2026-08-23, VIGÉSIMA SEXTA parte): a TELA A13 — DOCUMENTO/LEITURA é
estável por gate dele ("aprovo") e A F7.6 FECHA — 6 TELAS DE 6, produzidas em DOIS DIAS de gates encadeados sobre o consolidado de 2026-08-22: A19 §83 · A20 §84 · A17 §85 · A18 §86 · A14 §87 · A13 §88 — seis suítes, 101 PASS · 0 FAIL somados. A A13: canvas chapado C25 (o canvas É a tela), coluna de leitura 660px no registro da marca §4.1 (16px Light 1.65, "aproveitar a tela" recusado), figura com tokens de dado + fallback DG1, e o PAPEL como contrato: @media print no padrão DI com a TINTA VIGENTE — a errata do banco-dataviz-di virou LEI (a suíte reprova hex aposentado; o PDF real medido nos bytes: zero). RT/CREA/ART como placeholders de template (Lei 5.194). Divergência declarada: rota, não overlay. Da F7 resta a F7.7.§87 NOVA (2026-08-23, VIGÉSIMA QUINTA parte): a
texto inteiro da versão
§87 NOVA (2026-08-23, VIGÉSIMA QUINTA parte): a TELA A14 — FEED/ATIVIDADE é
estável por gate dele ("aprovado"), suíte 16 · 0 · 0. A INVERSÃO C33 — exceção escrita do CP2 desde a F7.1 — aplicada pela primeira vez em tela, com a condição de admissão MEDIDA (agrupador sunken sem sombra e não-acionável; objetos = peças claras acionáveis); os DOIS PESOS do §56 em composição real (evento = linha com de→para inline; comentário = BLOCO não-cartão); e o C27 timeline ganha a primeira spec (fio + marcador; o do comentário distinto), fechando a lacuna "existe no painel sem spec". Escopo = P3 do consolidado: atividade GLOBAL (histórico de projeto/manutenção), não a central §33. Divergência declarada: rota, não overlay.§86 NOVA (2026-08-23, VIGÉSIMA QUARTA parte): a
texto inteiro da versão
§86 NOVA (2026-08-23, VIGÉSIMA QUARTA parte): a TELA A18 — CONFIGURAÇÕES é
estável por gate dele ("aprovo"). Era um dos DOIS arquétipos SEM leitura — fechado pela volta dirigida de 2026-08-22. A decisão que o consolidado deixou em aberto foi tomada e gateada: DOIS REGIMES DE GRAVAÇÃO — formulário salva EXPLÍCITO (barra de dirty; o botão confirma "Salvo." no lugar; salvar NUNCA desabilitado) e switch aplica IMEDIATO com anúncio (o §8 já dizia "configuração é Switch"). Mais: "Sair" isolado no rodapé da navegação · chip de estado que ESPELHA o grupo · preset Padrão/Personalizado com engrenagem condicional · indisponível com correção inline · lateral vira ABAS <600px (provado em navegador real). Contratos CF-01…CF-11 na suite-configuracoes.mjs (18 · 0 · 1 [n/a] provado) — incluindo CF-11, o primeiro check de LGPD em suíte (reprova se dado pessoal real entrar na demo). Primeira tela da F7.6 que NASCE conforme à HV1. Registro: a régua CF-09a saiu com &&…|| traiçoeiro e foi reescrita antes da promoção — régua que passa por acaso é régua que mente.§85 NOVA (2026-08-23, VIGÉSIMA TERCEIRA parte): a
texto inteiro da versão
§85 NOVA (2026-08-23, VIGÉSIMA TERCEIRA parte): a TELA A17 — BUSCA/RESULTADOS é
estável por gate dele ("fora isso está aprovado"), com a correção do "fora isso" aplicada ANTES da promoção: ele pegou a HV1 de novo, a olho nu — a paginação sem resposta ao sobrevoo ("pelo que definimos era pra ter um efeito sobre o botao?" — TINHA: §71, nascido de gate DELE em 2026-08-19) — e o conserto foi RETROATIVO às três telas da F7.6 (hover neutro = degrau sunken · hover de fundo de marca = véu 8% · pressionado = véu 12%, monotônico, sob a receita do §71.2; hover só em @media (hover:hover), :active fora — toque pressiona). Contratos BU-01…BU-12 na suite-busca.mjs (15 · 0 · 1 [n/a] provado em navegador real): query ecoada + contagem sempre visível (D4-b) · realce por SUBLINHADO+peso 800 medido no pixel · chips que desmarcam a origem e voltam à página 1 (TD2/TD3/PG4) · zero-resultado D9 · debounce do espelho falado MEDIDO por espera real · gaveta mobile. ⚠ 49º defeito de instrumento: o check CSSOM reprovou as 3 telas CORRETAS — style rule também tem .cssRules (CSS Nesting), vazia mas truthy, e o flatMap ingênuo a trocava por lista vazia, engolindo os :active de topo. Suítes das irmãs cresceram junto: A19 22·0·0 · A20 15·0·1. Pendência nova BU-P1 (virtualização de lista longa — regra ausente no acervo).§84 NOVA (2026-08-23, VIGÉSIMA SEGUNDA parte): a
texto inteiro da versão
§84 NOVA (2026-08-23, VIGÉSIMA SEGUNDA parte): a TELA A20 — ONBOARDING/PRIMEIRO USO é
estável por gate dele ("a imagem da onboarding está ok. aprovo"). A taxonomia Z1 do §25 posta VIVA em composição, no hospedeiro painel §48: TRÊS estados não intercambiáveis (primeiro-uso educativo com EEny + critério dito · esvaziado · sem-permissão SEM EEny — Z5 provado por suíte), contratos ON-01…ON-09, suite-onboarding.mjs 14 · 0 · 1 [n/a] declarado (o [n/a] é container query = render, PROVADA em navegador real a 390px). Régua nova de mascote: medir o bounding box do pose por PIXEL antes de embutir (o pose-05, escolhido por peso, era o EEny DE COSTAS ocupando ~35% do canvas) e crop de APRESENTAÇÃO no viewBox do embed, desenho intocado. Esclarecimento de termo no gate: "byte-idêntico" = fidelidade embed↔asset, nunca igualdade entre poses — 8 poses, 8 MD5 distintos, medidos a pedido dele.§83 NOVA (2026-08-23, VIGÉSIMA PRIMEIRA parte): a
texto inteiro da versão
§83 NOVA (2026-08-23, VIGÉSIMA PRIMEIRA parte): a TELA A19 — AUTENTICAÇÃO existe e é
estável — fecha a CD-P5 (aberta desde o §66). Primeira entrega da F7.6, na ordem aprovada no consolidado de 2026-08-22 (P1–P5, "aprovo"). A tela compõe o §66/§2/§1/gabarito F7.1 SEM componente novo; 14 contratos AU-01…AU-14 medidos por COMPORTAMENTO na suite-autenticacao.mjs (21 · 0 · 0). Gate visual dele em 2026-08-23 com uma correção, verbatim: "a tela de login deve ter o icone da seed no lugar do botao turquesa. fazendo essa correção, está aprovado" — o símbolo OFICIAL entrou por INJEÇÃO DE SCRIPT byte-idêntica (claro=principal · escuro=mono-negativo, tabela §5.1 da marca), e a AU-12 passou a conferir o path contra o asset. Sustenta a spec a LEITURA DIRIGIDA de 2026-08-22 (09-pesquisa/leitura-f76-bordas.md): os vizinhos REPROVAM nas normas que o §66 já absorveu (CU: autocomplete ausente, submit desabilitado, zero h1/main, placeholder-como-rótulo). Achados de produção: container query não estiliza o próprio container (pego por medição em navegador real; o container subiu ao body) · o Chrome CLI inventou um overflow a 390px que o navegador real desmente (reincidência da armadilha do marco v1.9) · o G: rejeita junction e o jsdom passou a viver fora do stream (env JSDOM_DIR; pendência AU-P1 para as suítes antigas). Pendências novas: AU-P1 (ambiente das suítes), AU-P2 (variante com faixa CP19), AU-P3 (multi-empresa pós-login).2026-08-22
§82 CRESCE para 5 cláusulas (2026-08-22, VIGÉSIMA parte): nascem
texto inteiro da versão
§82 CRESCE para 5 cláusulas (2026-08-22, VIGÉSIMA parte): nascem MM1-d (arquivo de produção declara sangria ≥ 3 mm) e MM1-e (conteúdo a ≥ 3 mm do corte), com o veredito da sangria — "acredito que 3+3" — e o MÉTODO dele: "deixar o desenho dentro da area real, e a parte da sangria vc cresce o desenho". Consequência: passam a existir DOIS TIPOS DE ARQUIVO, gate e produção, cada um declarando o próprio papel no artefato. Pasta de prova de 7 para 11 fixtures; produção 15 PASS · 0 FAIL · 0 [n/a]. Canon v5.10 §7.4-e.
§82 NOVA (2026-08-22, DÉCIMA OITAVA parte): nasce o
texto inteiro da versão
§82 NOVA (2026-08-22, DÉCIMA OITAVA parte): nasce o CONTRATO MM1 — a guarda do piso de traço em milímetros, de ALVO DE PASTA, com 3 cláusulas (piso ≥ 0,25 mm · alvo físico coerente com a razão em px · ≥ 3 pesos distintos) e pasta de prova de 7 fixtures escrita ANTES (13 PASS · 3 FAIL · 5 [n/a], batendo com o previsto). Decisão de arquitetura: quem é peça impressa é decidido pelo que o ARTEFATO DECLARA (
<meta name="alvo-fisico">), nunca por nome de arquivo. E a MR-P8 fechou: pasta A4 de 105,7 para 300 DPI exatos, com o piso aplicado. Na estreia a guarda achou um defeito real do gerador: o piso estava sendo violado pelo ARREDONDAMENTO (0,24980 mm) — virou esclarecimento normativo no canon v5.8.§81 NOVA (2026-08-22, DÉCIMA SÉTIMA parte): a
texto inteiro da versão
§81 NOVA (2026-08-22, DÉCIMA SÉTIMA parte): a MEDIDA FÍSICA DO CARTÃO é
90×50 mm, o padrão BRASILEIRO — veredito dele, verbatim: "escolho B". Canon marca-seed.md v5.7 §7.4-d. O achado: os 89×51 mm eram 3,5×2 polegadas, medida de EUA/Canadá que entrou como default de ferramenta, nunca como decisão de marca. Custo medido: uma linha nova no teto da §7.4 (84px de 590 = 14,2%), porque a tabela é indexada pela RAZÃO da peça. Custo zero em impressão: o piso de 0,25 mm sai em 0,250 mm nos três formatos testados. GR1 15·0·0; acervo dos 7 formatos 21·0·0, intacto. Pendência nova MR-P10: SANGRIA.§80 PASSA A estável (2026-08-22, DÉCIMA SEXTA parte): o
texto inteiro da versão
§80 PASSA A
estável (2026-08-22, DÉCIMA SEXTA parte): o PISO DE TRAÇO EM MILÍMETROS existe. Veredito dele, verbatim: "saída B — piso de 0,25 mm por ESCALA, e só para peça IMPRESSA" → canon marca-seed.md v5.6 §7.4-c. Aplicado: o plano mais fino do cartão sai de 0,180 mm (2% de folga sobre o piso digital reverso) para 0,250 mm (42%), com os 4 pesos preservados — escala, não grampo, porque grampo achataria a hierarquia de peso, que é uma das três condições do §7.1. Peça de TELA fica fora, e isso está no código: ppmm só é passado nas chamadas de cartão. GR1 na pasta: 15 PASS · 0 FAIL · 0 [n/a].§80 NOVA (2026-08-22, DÉCIMA QUINTA parte): o
texto inteiro da versão
§80 NOVA (2026-08-22, DÉCIMA QUINTA parte): o TRAÇO DO GRAFISMO EM MILÍMETROS — a lei do traço é em PIXEL, logo o traço físico de peça impressa é função da resolução de exportação. Medido: o verso do cartão APROVADO passa o piso digital reverso por 0,004 mm (2%), e a variante do verso nos 7 formatos REPROVA nos quatro planos. Três saídas com imagem, recomendação de piso de 0,25 mm por ESCALA — nada entrou no canon: piso é valor de marca e espera veredito.
Versão: 1.0 · Data: 2026-08-22 · Estado: proposta — nada aqui é
texto inteiro da versão
Versão: 1.0 · Data: 2026-08-22 · Estado:
proposta — **nada aqui éVersão: 1.0 · Data: 2026-08-22 · Estado: histórico (era aprovado na estrutura; plano executado: as três ondas fecharam com a F8 em 2026-09-04) —
texto inteiro da versão
Versão: 1.0 · Data: 2026-08-22 · Estado:
histórico (era aprovado na estrutura; plano executado: as três ondas fecharam com a F8 em 2026-09-04) —A §12 ganha o INVENTÁRIO AMPLIADO e a §17 ganha a pendência MR-P11.
texto inteiro da versão
A §12 ganha o INVENTÁRIO AMPLIADO e a §17 ganha a pendência
MR-P11. O inventário de peças físicas da §12 era o do Manual 2018 e não continha uma única peça específica de engenharia elétrica — faltava a classe regulada por lei e por norma. O levantamento completo (36 peças em 5 famílias, com fonte por peça regulada) passa a viver em inventario-pecas-ds.md v1.0, estado proposta. Peças reguladas identificadas: placa de obra (Lei nº 5.194/1966, Art. 16 + Resolução CONFEA nº 407/1996 — conteúdo obrigatório, forma livre, logo é peça legítima de DS) e sinalização de segurança elétrica (NR-10 item 10.10.1, sete situações; cores pela NR-26 → ABNT NBR 7195). Nasce a pendência MR-P11: o amarelo de marca #FAD61D colide em SIGNIFICADO com o amarelo normativo de advertência da NBR 7195 em ambiente industrial. Nenhum hex muda, nenhuma regra é revogada — o que entra é o registro do conflito e o apontamento do inventário.Esclarecimento normativo na §7.4-c: o piso de 0,25 mm não pode ser violado pelo ARREDONDAMENTO.
texto inteiro da versão
Esclarecimento normativo na §7.4-c: o piso de 0,25 mm não pode ser violado pelo ARREDONDAMENTO. Ao aplicar o fator de escala, o menor peso arredonda para CIMA. Motivo medido: na pasta A4 (11,80952 px/mm) o arredondamento normal devolvia 0,24980 mm — 0,0002 mm abaixo do canon, e a guarda nova pegou. A §7.4-c passa a nomear DOIS instrumentos com papéis distintos: a guarda
guarda-piso-mm.py (contrato MM1, alvo de pasta), que julga contra o piso do canon, e o diagnóstico mede-traco-mm.py, que compara com pisos de mercado. E fica escrito como uma peça declara que é impressa: <meta name="alvo-fisico"> no próprio artefato — nunca por nome de arquivo; peça sem a declaração sai [n/a] nomeado. Nenhum hex muda, nenhum vetor muda, nenhum teto muda.Nasce a §7.4-d: a medida física do cartão é 90×50 mm, o padrão BRASILEIRO.
texto inteiro da versão
Nasce a §7.4-d: a medida física do cartão é
90×50 mm, o padrão BRASILEIRO. Veredito do Rafael, verbatim: "escolho B / qualquer ajuste é minimo se precisar fazer, e o desenho se ajusta hoje proporcionalmente". SUPERSEDE os 89×51 mm, que eram 3,5×2 polegadas — medida de EUA/Canadá que entrou como default de ferramenta, nunca como decisão de marca (não há registro de escolha). A §7.4 ganha o teto do novo formato (84px de 590 = 14,2%) e a linha antiga fica marcada como HERDADA, mantida só porque o acervo dos 7 formatos ainda está na razão 1,745. Medido: o piso de 0,25 mm da §7.4-c atravessa a troca de formato (0,250 mm nos três formatos testados), o verso reverso segue PASS, GR1 nas peças largas 15·0·0 e o acervo dos 7 formatos 21·0·0 — nenhuma regressão. Nenhum hex muda, nenhum vetor muda. Pendência nova MR-P10: SANGRIA — o verso é fundo cheio e nenhuma peça do projeto tem área além do corte.Nasce a §7.4-c: PISO DE TRAÇO EM MILÍMETROS para peça impressa.
texto inteiro da versão
Nasce a §7.4-c: PISO DE TRAÇO EM MILÍMETROS para peça impressa. Veredito do Rafael, verbatim: "saída B — piso de 0,25 mm por ESCALA, e só para peça IMPRESSA". Piso 0,25 mm, aplicado por ESCALA (fator único em todos os planos), só em peça com alvo físico declarado. Motivo medido: a lei do traço da §7.4 é em px, logo o traço físico dependia da resolução de exportação; o verso do cartão passava o piso digital reverso por 0,004 mm (2% de margem) e agora tem 42%. Escala e não grampo porque grampo achata 4 pesos em 2 e a hierarquia de peso é uma das três condições do §7.1. Escopo declarado: peça de TELA fica de fora, e o marcador de seção (risco amarelo, 0,170 mm) fica intocado até veredito próprio. Nenhum hex muda; nenhuma regra da v5.0 é revogada.
A MR-P11 RESOLVE — saída (a) aprovada por veredito
texto inteiro da versão
A MR-P11 RESOLVE — saída (a) aprovada por veredito ("essa está aprovada, pode propagar"): o amarelo de marca não entra em peça instalada em ambiente com sinalização de segurança; nessas peças a assinatura é turquesa e branco; papelaria, escritório e digital mantêm o acento único sem restrição. Uma regra, uma fronteira. Propagação feita com verificação de conformidade contra o que foi construído depois da recomendação (ordem dele na mesma data): único amarelo novo desde então é o marcador da v5.12, elemento de papelaria/digital, fora do escopo — sem conflito. Desbloqueia as peças 2.9 (sinalização) e 3.2 (uniforme/EPI) do
plano-producao-pecas.md; a placa de obra (1.1) já era desenhada sem amarelo e fica correta. Nenhum hex muda.Os três usos INTERNOS do grafismo ganham geometria canônica e a pendência §17.3 FECHA.
texto inteiro da versão
Os três usos INTERNOS do grafismo ganham geometria canônica e a pendência §17.3 FECHA. Nasce
06-validacao/geradores/gen-detalhe.py (traçado extraído do gen-zero-formatos.py por AST, nunca redigitado) e os 5 assets de referência em 03-assets/grafismos/. TEXTURA = a cena Z3 inteira a ≤10% — supersede as "2–4 linhas paralelas" da §7.6, por veredito: "vc tem que criar essas linhas igual as do rodapé que já estão aprovadas" (paralelismo é ritmo; serra é profundidade, §7.1); reclassificada como uso interno do SERRA-CENA. DIVISOR = a imagem do rodapé repetida emendada com corte no limite direito (verbatim: "a quantidade de cópias que precisar em sequência emendadas, e o que passar do limite do lado direito vc corta"); altura natural = largura/12,7; piso de leitura = §7.2 (regra já feita, escolhida por ele sobre um piso novo em px); sem teto; escala proporcional (§7.4). A EMENDA é a §7.3 aplicada: toque exato natural (a máscara de oclusão aprovada corta a ponta do FUNDO na crista da cópia seguinte) + mergulho da ponta esquerda abaixo da faixa, na zona que a moldura já cortava. MARCADOR = o risco aprovado fica intocado, inclusive o amarelo: quando o "apenas o turquesa" da Fase 2 colidiu com o §78.3-6, o veredito foi "prevalece o veredito que vc achou já estabelecido". Sangria por tipo de arquivo (§7.4-e): o transbordo natural de 6% cobre os 36px em todo formato impresso (cartão 63,78px · A4 148,80px) — nenhum desenho novo. Alternativas descartadas, cada uma com o número que a matou: 4 políticas paramétricas de amplitude (todas trocavam n=7 por 3 — redesenhavam a curva; a lei do §76.4 já respondia), duas linhas contínuas defasadas (só 17,5% de oclusão real — fita trançada), cadeia de arcos (fatiava o desenho), cena reduzida (o piso de traço da serra exige F≥58,64 — "profundidade custa altura"), cópias com profundidade alternada (linha listrada; §7.2 exclui oclusão do regime), descida-A construída (a natural já existia; construída abria talho ou nó). Lição de instrumento: a composição roda PURA sobre o desenho intocado — modificar fundo_v antes de compoe() desloca os retângulos de supressão de fragmento e o corte cai no meio do ar. Nenhum hex muda; nenhum traçado aprovado muda.A §7.4-e ganha a regra do ARQUIVO SOB DEMANDA
texto inteiro da versão
A §7.4-e ganha a regra do ARQUIVO SOB DEMANDA, por veredito dele: "sobre a producao, apenas o mock, quando for ter a producao de alguma peça especifica, ai sim trabalhamos o arquivo de producao para aquela demanda". O entregável padrão de toda peça passa a ser o MOCK; o arquivo com sangria (e a faca, quando houver dobra) só é feito quando existe a compra. Motivo: arquivo de produção feito antes da demanda envelhece — a gráfica escolhida pode pedir 5 mm em vez de 3, ou faca diferente, e o arquivo pronto vira arquivo errado com aparência de pronto. Nenhum valor muda; o que muda é quando o arquivo nasce.
Nasce a §7.4-e: SANGRIA de 3 mm e MARGEM DE SEGURANÇA de 3 mm em peça impressa
texto inteiro da versão
Nasce a §7.4-e: SANGRIA de 3 mm e MARGEM DE SEGURANÇA de 3 mm em peça impressa, por veredito dele: "a sangria vc tem que usar o que o mercado indica nas suas pesquisas. acredito que 3+3". E o MÉTODO entra como regra, também dele: "vc tem que deixar o desenho dentro da area real, e a parte da sangria vc cresce o desenho" — a composição é definida para a área de corte e não se mexe; a sangria é crescimento para fora. Consequência formal: passam a existir dois tipos de arquivo — GATE (tamanho do corte, é o que a GR1 mede e o que ele aprova) e PRODUÇÃO (corte + 3 mm) —, cada um declarando o próprio papel no artefato (
<meta name="papel">, corte-px, sangria). Medido: a serra toca 3 bordas, logo sangria é obrigatória; e o conteúdo do cartão está a 4,24 mm do corte, folga de 1,24 mm contra a margem de 3 mm — o layout aprovado cabe sem mexer. Sangria em px arredonda para cima (36 px = 3,05 mm), mesma regra do piso de traço. A guarda MM1 ganha as cláusulas MM1-d e MM1-e. Fica aberta a MR-P12: peça com dobra/vinco tem margem própria e a pasta A4 com aba não existe como arquivo de produção. Nenhum hex muda, nenhum vetor muda, nenhuma composição muda.RECONCILIAÇÃO DE ESTADO — o mapa mestre estava 12 dias e duas fases atrás do projeto, e o custo apareceu: uma sessão quase reabriu como "próximo brick" a formalização da F5, concluída 11 dias antes.
texto inteiro da versão
RECONCILIAÇÃO DE ESTADO — o mapa mestre estava 12 dias e duas fases atrás do projeto, e o custo apareceu: uma sessão quase reabriu como "próximo brick" a formalização da F5, concluída 11 dias antes. O que esta edição corrige, tudo ancorado em documento existente (nenhuma decisão nova): (a) errata de cabeçalho — dizia v1.9 · 2026-08-09 com o log já em v2.0; (b) F5 → FECHADA 6/6 (2026-08-11;
seed-dataviz.md v0.20; marcos v1.8/v1.9 do ESTADO_ATUAL; a "pendência crítica" da v2.0 foi resolvida NO DIA SEGUINTE a ser escrita — §3c v1.5/v1.6 + gêmeos + spec DM1–DM11 + suite do DM — e este arquivo nunca registrou); (c) F6 → FECHADA 3/3 (marco v2.0, 2026-08-13/14: âncora vira turquesa; marco v2.1, 2026-08-15: shell consolidado, "tudo 100%"); (d) renumeração de fases de 2026-08-15 aplicada: F7 = COBERTURA (F7.1–F7.7 do mapa-cobertura-ds.md, com F7.1–F7.5 entregues), aplicações = F8, publicação/IA-GEO = F9 — supersede formal no §12 do marca-seed.md, que até hoje apontava para uma errata deste arquivo que ficou superada; (e) tabela de canônicos reescrita com as versões vigentes (tokens v1.20 · marca v5.13 · componentes v1.29 · composicao v2.1 · email v0.12 · dataviz v0.20 · mapa-cobertura v2.22), incluindo os canônicos que nasceram depois da v2.0 e nunca entraram nela; (f) estado da F8 registrado (grafismo ✅ 2026-08-22 · cartão ✅ · MR-P11 resolvida v5.13 · insumos da Onda 1 respondidos). Regra que a reconciliação deixa no cabeçalho: se este arquivo contradisser o ESTADO_ATUAL ou o changelog de um canônico, o mais recente vence e a reconciliação precede o uso. A causa raiz é a mesma classe do defeito do marco v1.4 (afirmado, nunca lido de volta): os fechamentos de fase atualizaram checkpoint, ESTADO_ATUAL e canônicos, mas nenhum rito exigia voltar AQUI — e o arquivo que o CLAUDE.md manda ler primeiro era o único que ninguém mantinha.2026-08-21
§79 NOVA (2026-08-21, DÉCIMA QUARTA parte): o teto do grafismo no
texto inteiro da versão
§79 NOVA (2026-08-21, DÉCIMA QUARTA parte): o teto do grafismo no TOPO é de LARGURA, não de altura —
F ≤ w / 6,5625, por veredito dele: "o ponto é medir a aplicação na largura se atende ao desenho selecionado para o topo, a altura nao importa". A altura da peça não entra e a razão de aspecto não gateia nada; a % da altura passa a ser DIAGNÓSTICO. Canon marca-seed.md v5.5 §7.4-b.§78 NOVA (2026-08-21, DÉCIMA TERCEIRA parte): o decisor APROVOU a emenda de canon MR-P4 e o marca-seed.md passou a
texto inteiro da versão
§78 NOVA (2026-08-21, DÉCIMA TERCEIRA parte): o decisor APROVOU a emenda de canon MR-P4 e o
marca-seed.md passou a v5.4 — o grafismo agora tem DOIS REGIMES (DETALHE DE LINHA ≤~8% e SERRA-CENA com tetos POR FORMATO), e a guarda GR1 passou a ler o canon novo no mesmo dia: 5 fixtures novas escritas ANTES, inércia 7 de 7 nas antigas, e as peças largas de 11·4·0 para 15·0·0 — fechamento POR CANON, sem afrouxar limite nenhum.§77 NOVA (2026-08-21, DÉCIMA SEGUNDA parte): o contrato
texto inteiro da versão
§77 NOVA (2026-08-21, DÉCIMA SEGUNDA parte): o contrato GR1 do grafismo GANHA INSTRUMENTO —
validacao/guarda-grafismo.mjs reescrita do zero (a original nunca foi propagada), alvo de pasta sem filtro de nome, medição por renderização diferencial julgada no pixel, pasta de prova render-audit/prova-gr1/ escrita ANTES com 7 fixtures e referência 10 PASS · 3 FAIL · 8 [n/a], e placar em 18 peças reais. Os 4 FAILs de L2/L3/L4/L5 são SANCIONADOS pelo decisor e esperam a emenda MR-P4. Nasce o 47º defeito de instrumento.Nasce a §7.4-b: o teto do grafismo no TOPO é de LARGURA, não de altura.
texto inteiro da versão
Nasce a §7.4-b: o teto do grafismo no TOPO é de LARGURA, não de altura. Veredito do Rafael, verbatim: "o ponto é medir a aplicação na largura se atende ao desenho selecionado para o topo, a altura nao importa". Teto:
F ≤ w / 6,5625, razão derivada da própria peça aprovada (w=420, F=64). SUPERSEDE a leitura de que o topo respondia a 15,24% da altura e só na razão 1:1 — aquele número passa a ser descrição da peça, não o teto, e peça larga deixa de precisar de veredito novo. Escopo declarado: só o topo; o rodapé segue com os tetos por formato da §7.4. Nenhum hex muda, nenhum vetor muda, nenhuma regra da v5.0 é revogada.A §7 (Grafismo v2) é reescrita: nascem os DOIS REGIMES — DETALHE DE LINHA (o uso original, teto de 8%) e SERRA-CENA (3–4 planos com cruzamento, oclusão e hierarquia de peso, com tetos POR FORMATO).
texto inteiro da versão
A §7 (Grafismo v2) é reescrita: nascem os DOIS REGIMES —
DETALHE DE LINHA (o uso original, teto de ~8%) e SERRA-CENA (3–4 planos com cruzamento, oclusão e hierarquia de peso, com tetos POR FORMATO). Nenhum hex muda, nenhum vetor muda, nenhuma regra da v5.0 é revogada — o teto de ~8% continua valendo para o regime de detalhe e o teto de área ≤10% continua valendo para os dois. Novidades: §7.1 a ORIGEM do desenho (as ondas são montanhas — dita pelo Rafael em 2026-08-20 e que não estava escrita em documento nenhum) mais as três condições de leitura de plano e o critério do MOVIMENTO · §7.2 os dois regimes, com o número que os separa (a serra precisa de ~15% da altura para LER como serra; abaixo disso ela não fica discreta, desaparece) · §7.3 os DOIS MODELOS de serra-cena com regras INDEPENDENTES — arcos no RODAPÉ (PADRÃO, toque exato) e montanha no TOPO (OPÇÃO, oclusão com folga), por veredito dele: "considere que o topo segue uma regra e o rodapé outra regra" · §7.4 a LEI DA ESCALA (forma constante em unidades de faixa, razão natural w/F = 12,7) e os tetos aprovados por formato (cartão 13,8% · banner 11,8% · capa 15,7% · topo 15,24%) · §7.5 a cor do grafismo só em stops da rampa canônica, com o precedente registrado do hex inventado que foi retirado por ordem dele (#0A6B60 → #006C62, ΔE76 = 1,03) e a REGRA §0-b · §7.6 tabela consolidada de usos · §7.7 os vetores da serra-cena existem como GERADORES, o que muda o estado da pendência §17.3. Especificação completa e medições em seed-componentes.md §76; registro da rodada em validacao/MANIFESTO.md §103.2026-08-20
§76 NOVA (2026-08-20/21, DECIMA PRIMEIRA parte): o GRAFISMO DA MARCA entra como componente — a
texto inteiro da versão
§76 NOVA (2026-08-20/21, DECIMA PRIMEIRA parte): o GRAFISMO DA MARCA entra como componente — a SERRA EM ARCOS no rodape (PADRAO, 4 planos, TOQUE EXATO, 12 pecas medidas) e a MONTANHA no topo (OPCAO do criador, 3 planos, oclusao com folga). ⚠ DOIS REGIMES DE REGRA INDEPENDENTES, por veredito do decisor: "considere que o topo segue uma regra e o rodape outra regra" — o toque exato e regra do RODAPE, nao lei da casa. Escada E1-nevoa aprovada no tema escuro; supersede formal do
#0A6B60, cor de marca criada sem autorizacao e retirada por ordem dele (ΔE76 = 1,03 contra o token #006C62). Contrato GR1 escrito com as tres clausulas (area ≤10% · glifo velado 0px · faixa de rodape ≤~8%) mas HOJE SEM INSTRUMENTO: a guarda nunca foi propagada e todo placar GR1 antigo e historico e irreproduzivel (GR-P3). Registro completo no MANIFESTO §103; dimensoes novas no mapa §22.15. · **§75 (2026-08-20, DECIMA parte, SEGUNDA rodada) (2026-08-20, DECIMA parte, SEGUNDA rodada): nasce o contrato TP1 — a tipografia e os recursos que o artefato declara REALMENTE CARREGAM, validacao/guarda-tipografia-viva.mjs, alvo de pasta: 30 PASS · 21 FAIL · 0 [n/a] no acervo (0 TP1-a · 21 TP1-b · 14 TP1-c) mais 85 achados de PORTABILIDADE e 56 de PRIMEIRA ESCOLHA. Ele nasceu de o Rafael perguntar se "uma imagem que nao carregou" mudava a avaliacao: NAO mudava (cor, tamanho, peso, retangulo dentro do cartao e pixel do fundo IDENTICOS com e sem imagem), mas a investigacao achou que o seed-design-system.html depende de 47 recursos de REDE e que 0 de 45 imagens e 0 de 2 familias tipograficas carregam — logo TODO recorte daquele artefato ja mostrado ao decisor saiu com a tipografia de RESERVA. ⚠ A regua obvia MENTE: document.fonts.check() devolve true com a fonte FALHANDO; as honestas sao [...document.fonts].length (0 antes, 7 depois) e a LARGURA EM CANVAS (348 = 348). ⚠⚠ Esta guarda esteve errada CINCO vezes (48, 46, 22 com 3 falsos, 6 de 6, e finalmente correta) e o numero de passes E o achado: quando uma regua nova reprova EM BLOCO, a primeira hipotese nao e "o acervo esta ruim", e "a regua esta medindo outra coisa". Nasce a pasta prova-tp1 (3 · 3 · 0). §75.6 registra as DUAS DECISOES DE COR que esperam gate e NAO foram aplicadas: (i) no amarelo, o pedido dele (manter o amarelo em 18px) nao era entregue por nenhuma das cinco opcoes porque a ONDA decorativa cruza a segunda linha — a saida e (E+), cartao #005048 + onda #00352F, 6,56 e 8,54, zero hex novo; e o kicker com opacity:.9 ja reprovava em 4,01 real contra 4,60 declarado. (ii) no dourado, a recomendacao (D) da folha v14.1 CONTRARIAVA o seed-tokens.md v1.5 de 2026-08-11, aprovado por gate dele — regua nova: antes de propor mudanca de VALOR de cor de marca, leia a linha do canon sobre aquela cor. A saida preserva o hex: #F9B11C intocado mede 7,48 sobre #242E34 ou como AREA com rotulo escuro. Pendencias novas: RD-P1, CC-P11, CC-P12, TP-P1. Anterior: v1.19 — **§74 NOVA (2026-08-20, DECIMA parte): o contrato BT1 (barra de provas travada no topo, §64.1, de 2026-08-16) FECHA POR INSTRUMENTO — nasce validacao/guarda-barra-fixa.mjs, de ALVO DE PASTA, com quatro clausulas das quais TRES sao COMPORTAMENTAIS (a pagina e rolada de verdade). O motivo de existir: a BT-P2 foi declarada FECHADA em 2026-08-17 sobre uma LISTA ESCRITA A MAO de dez artefatos, e o acervo tem trinta e quatro — o Rafael achou o resto a olho nu ("acredito ter outros"). Placar: 22 PASS · 11 FAIL · 18 [n/a] -> 33 · 0 · 18, medido a 1440x900 E a 320x900 (9 BT1-a · 10 BT1-b · 0 BT1-c · 2 BT1-d). LICAO: pendencia de contrato TRANSVERSAL nao fecha por lista — fecha por instrumento de ALVO DE PASTA. A primeira tentativa de conserto foi REVOGADA pelo print (a barra travou ABAIXO do titulo; o no foi MOVIDO para primeiro filho de <body>), e duas suites reprovaram o conserto com razao (tokens fantasma em seis arquivos: 38·1 -> 39·0 e 92·1 -> 93·0). Nasce a pasta de prova prova-bt1 (1 PASS · 4 FAIL · 2 [n/a]), que pegou DOIS defeitos do proprio instrumento antes do acervo. Nasce tambem a regra de forma de entrega DEMONSTRACAO VIVA E EXTRAIDA, NUNCA REDIGITADA (validacao/extrai-vivo.mjs), com o 44o defeito: a v1 lia CSS por REGEX e chave dentro de COMENTARIO desalinhou o parser — 3 de 5 quadros sairam sem tokens; reescrita por CSSOM, 5 de 5. Pendencias novas: BT-P3 (o BT2, seletor de LARGURA, nunca foi medido) e IN-P2 (nenhum censo diz quais .mjs leem CSS por texto em vez de CSSOM). Anterior: v1.18 — **§73 NOVA (2026-08-20, NONA parte): a HV-P5 FECHA — nasce --seed-text-brand-strong (gemeos v1.19, claro #006C62 / escuro #66D1C2, ZERO hex novo) e o contrato HV1-e: tinta cujo piso foi verificado num UNICO fundo nao serve a estado. O numero que fecha a decisao: para #098475 alcancar 4,5 o fundo precisa de luminancia >= 0,978 — o cinza mais escuro que serve e #FDFDFD — logo NAO EXISTE superficie de interacao possivel para a tinta de marca atual. Os 90 casos eram 100 depois de consertada a regua (41o defeito: a HV1-c lia a tinta DO CONTROLE, nao a de quem PINTA a letra — 1 artefato correto condenado e 12 defeitos reais invisiveis), e nao estavam em 7 classes: estavam em 5 arquivos, 64 num so. Consertar o pior obrigou a abrir o seed-design-system.html, onde o 42o defeito (a varredura de contraste escolhia alvo por PREFIXO DE NOME e deixava 17 dos 51 HTMLs de fora) escondia 862 folhas de texto reprovadas em repouso: 862 -> 46. Nasce ainda o 43o defeito (a ferramenta de recorte nao desligava rolagem suave — era o 33o, num terceiro instrumento). Pendencias novas: HV-P6, SE-P1, CC-P9, CC-P10, ES-P1, TK-P1. Anterior: v1.17 — **§72 REVISTA (2026-08-20, oitava parte): nasce a clausula SH1-d — O CONTEUDO NAO VAZA DA PROPRIA CAIXA, de o Rafael apontar num anexo a 390px o rotulo saindo POR FORA DA BORDA de dois botoes do tela-gantt que as tres clausulas anteriores davam como limpos. Causa medida: display:flex da flex-shrink:1 por padrao e o min-width:44px do piso de ALVO da SC 2.5.8 SUBSTITUIU a protecao min-width:auto do flexbox — duas regras boas que juntas produzem uma ruim; conserto flex-wrap:wrap + flex:0 0 auto, com quatro alternativas descartadas registradas no proprio molde. Dois defeitos de instrumento morreram no caminho: o 39o (clientWidth de inline nao-substituido vale ZERO — 168 falsos vazamentos, 124 deles em code) e o 40o (opacity:0 NAO tira o elemento do hit-test — 2 falsos FAIL que so apareciam a 390x844). Placares: acervo 204 PASS · 0 FAIL a 1440px e 198 PASS · 6 FAIL a 390px, este confirmado em DUAS alturas de janela; pasta de prova a 42 PASS · 22 FAIL em 16 fixtures. A SH-P8 foi reescrita: dizia "18 FAIL em 4 arquivos" e o numero medido e 6 FAIL em 2 arquivos. Anterior: v1.16 — §71 e §72 (2026-08-19, sétima parte): nasce HV1 — RESPOSTA AO PONTEIRO e PRESSIONADO DISTINTO — de o Rafael RECUSAR uma pergunta que eu não devia ter feito; medido, 619 de 1.410 controles ativos não davam NENHUMA resposta ao mouse, 1.350 tinham o pressionado igual ao sobrevoo e 90 violam a norma de contraste HOJE, com 0 PASS em 51 arquivos. E nasce SH1 — COLISÃO, COBERTURA E CORTE —, que FECHA a SH-P3: 204 PASS · 0 FAIL a 1440px, com o espaçamento da SC 1.4.12 medido pela primeira vez e CINCO defeitos de instrumento mortos no caminho. Gêmeos de token a v1.18. Anterior: v1.15 — ** §70 reescrito (2026-08-19, sexta parte): as duas confissões do CT1 FECHAM — CT-P1 (media só o tema claro) e CT-P2 (media só o repouso). Nascem CT1-d e CT1-e: 2 temas × 4 estados × 2 larguras, 1.480 medições, 0 fora do centro, NENHUM artefato alterado. Tema escuro só é medido em quem PROMETE tema escuro, e a promessa é medida por assinatura de cor, não por grep. §70.5 supersede · §70.6 prova de inércia (a dimensão antiga reproduz 23·0·28) · §70.7 pendências CT-P3 a CT-P7. Anterior: v1.14 — ** §65.9, §65.10, §65.11 e §70 (2026-08-19, gate v13.3 respondido pelo Rafael): a SI-P5 FECHA e a resposta não foi nenhuma das três alternativas — aquele quadrado é a EMPRESA LOGADA e o ERP é MULTI-EMPRESA (SI17-e: cor por empresa, glifo constante; SEED energia na posição 3, escolhida por distância de luminância 3,80); a PS-P6 FECHA com os contratos SI19 (pessoa é círculo, empresa é quadrado) e SI20 (foto e logo SUBSTITUEM o fundo, nunca se deitam sobre a cor de entidade), e a matriz dos QUATRO estados nasce em banco-identidade.html; a PN-P6 FECHA — a linha da planilha sobe de 40 para 44px, alvo medido 234×44; a CC-P8 FECHA — o ponto da legenda deixa de ser o CARACTERE ● e vira forma, trocando o critério de SC 1.4.3 para SC 1.4.11 sem mexer em uma cor sequer; e nasce o §70 com o contrato CT1 e a guarda guarda-centro-alvo.mjs (189 controles, 0 fora do centro) a partir de um defeito que o RAFAEL viu a olho nu e que NENHUMA das 60+ guardas via. §65.8 e §62.8 (2026-08-19): nasce o contrato SI18 (2026-08-19): nasce o contrato SI18 para o ponto de cor .ent — spec PRÓPRIA, porque ele NÃO é o §65.7 mal-feito — e a PS-P5 é REVOGADA pela medição: o .mini-avatar carrega um CLIENTE, não uma pessoa. §67.7 (2026-08-19): a IL-P2 EXECUTA — a grade do §48 passa a cumprir o padrão grid da ARIA e o §67; nasce o contrato IL15 e a guarda que TECLA para medir; o defeito principal era TECLADO e não estava escrito na pendência. §65.7 (2026-08-19): a SI-P4 EXECUTA — o .sigla ganha bloco ÚNICO nas OITO telas que o carregam (o censo dizia quatro), nascem os contratos SI17-a/b/c/d e a guarda-si17.mjs que os mede por COMPORTAMENTO; nasce a SI-P5, de produto. Fase 3 FECHADA 7/7 ✅ · FASE 6 — 6A, 6B e 6C FECHADOS: §48 Painel estável desde 2026-08-13, PN1–PN54. INVERSÃO DO HERO na mesma data: o azul sai, a âncora passa a TURQUESA VIVO turquesa-400, a ação volta à família da marca e o conflito com o §3.5 de marca-seed.md DESAPARECE — S4 retirado, S3 revisto, S11 novo. Preview v0.8, cinco camadas verdes (139 · 37 · 142 · 6 · 78). Segue proposta apenas a tinta da família (S6) — pendência PN-P1, agora menorNasce --seed-font-expressive (Caveat, pesos 400/600/700): o sistema tem TRÊS famílias, não duas.
texto inteiro da versão
(entrada reconstituída em 2026-09-27, na v1.33 —
REV-P29; fonte: a errata formal do §2.5, com o veredito dele verbatim; o cabeçalho do seed-tokens.css; a errata de cabeçalho do topo deste arquivo; tudo presente desde fbba442e, o commit de origem é anterior a este repositório) Nasce --seed-font-expressive (Caveat, pesos 400/600/700): o sistema tem TRÊS famílias, não duas. Terciária de escopo estreito — peça de marketing alegórica, festiva; nunca interface, nunca documento técnico. Supersede a frase "Sistema final: 2 famílias" do §2.5 e a "3ª família" que a tabela do §8 tinha como alternativa descartada. Na mesma edição o H1 deste arquivo, que dizia v1.17 com os gêmeos em v1.19, foi corrigido. O MANIFESTO não registra esta versão pelo nome do token (0 ocorrências de font-expressive, medido em 2026-09-27).Nasce text-brand-strong (#006C62 claro · #66D1C2 escuro) e fecha a HV-P5:
texto inteiro da versão
(entrada reconstituída em 2026-09-27, na v1.33 —
REV-P29; fonte: o §5-g; a $description do JSON e o comentário do CSS; MANIFESTO §100.5; presentes desde fbba442e, o commit de origem é anterior a este repositório) Nasce text-brand-strong (#006C62 claro · #66D1C2 escuro) e fecha a HV-P5: a tinta de marca text-brand mede 4,60 sobre a página branca, 0,10 acima do piso, e cai abaixo dele assim que a superfície deixa de ser branca; estado vigente no §5-g. Na mesma versão, errata declarada no cabeçalho do seed-tokens.css, que dizia v1.17 depois de a v1.18 ter nascido (o conteúdo estava em v1.18; só o cabeçalho atrasou).2026-08-19
Nascem action-neutral-hover (#F2F6F9 claro · #141D23 escuro) e action-neutral-active (#E3EBF0 · #0B1419) — sobrevoo e pressionado de controle NEUTRO, contrato HV1, sem hex novo:
texto inteiro da versão
(entrada reconstituída em 2026-09-27, na v1.33 —
REV-P29; fonte: MANIFESTO §98.9; a $description do JSON e o comentário do CSS (contrato HV1); a menção no §5-g; presentes desde fbba442e, o commit de origem é anterior a este repositório) Nascem action-neutral-hover (#F2F6F9 claro · #141D23 escuro) e action-neutral-active (#E3EBF0 · #0B1419) — sobrevoo e pressionado de controle NEUTRO, contrato HV1, sem hex novo: os valores eram os de surface-subtle e surface-sunken; o que nasceu foi o propósito com nome. Motivo medido, registrado no JSON: 619 de 1.410 controles ativos do acervo não tinham nenhuma resposta ao ponteiro. Valores da época (MANIFESTO §98.9); o estado de hoje é o do §3.2026-08-18
A marca que carrega texto desce um degrau — supersede de metade do §5-b.
texto inteiro da versão
(entrada reconstituída em 2026-09-27, na v1.33 —
REV-P29; fonte: o §5-d; MANIFESTO §88 (edição v12.6); a $description do JSON; a cadeia "Anterior" da linha "Editado" do cabeçalho; presentes desde fbba442e, o commit de origem é anterior a este repositório) A marca que carrega texto desce um degrau — supersede de metade do §5-b. O gate visual vetou a tinta escura sobre a marca e pediu texto branco; com o branco fixado, nascem surface-brand-strong (turquesa-600 #098475, igual nos dois temas) e text-on-brand-strong (#FFFFFF, 4,60). A marca chapada #11B0A0 segue âncora, reservada para área sem texto. Estado vigente no §5-d.Nasce text-on-action-destructive e fecha a AD-P1:
texto inteiro da versão
(entrada reconstituída em 2026-09-27, na v1.33 —
REV-P29; fonte: o §5-c; MANIFESTO §87 (edição v12.5); a $description do JSON; a cadeia "Anterior" da linha "Editado" do cabeçalho; presentes desde fbba442e, o commit de origem é anterior a este repositório) Nasce text-on-action-destructive e fecha a AD-P1: o botão destrutivo clareia no tema escuro e a tinta continuava branca, medindo 2,71 a 2,76 contra o piso 4,50. A tinta nova é #FFFFFF no claro e #521112 (vermelho-900) no escuro — 5,19 e 5,26 em repouso, 7,18 e 7,21 no sobrevoo.2026-08-17
As três tintas de marca fecham a MR-P1 e a MR-P2:
texto inteiro da versão
(entrada reconstituída em 2026-09-27, na v1.33 —
REV-P29; fonte: o §5-b e a errata dupla do §5; MANIFESTO §86 (edição v12.4), onde os gêmeos passam de v1.14 a v1.15; a $description do JSON; a cadeia "Anterior" da linha "Editado" do cabeçalho; presentes desde fbba442e, o commit de origem é anterior a este repositório) As três tintas de marca fecham a MR-P1 e a MR-P2: um único token de tinta servia três fundos de marca com necessidades opostas e errava dois deles, um em cada tema. Passam a ser text-on-brand (escura, #00352F, sobre a marca chapada, 4,99), text-on-brand-deep (branca, 6,32 no claro e 9,37 no escuro) e text-on-action-primary (inverte com o tema, 4,60 e 7,39). Parcialmente supersedida pela 1.17 (§5-d).2026-08-15
v1.1 · 2026-08-15 (v0.1 consolidado; v0.2 registra D1–D5; v0.3 fecha a D6; v0.4 corrige a errata da contagem de gabaritos e registra o estado da F7.1; v0.5 registra a ENTREGA da F7.2 e reclassifica os oito itens do eixo…
texto inteiro da versão
v1.1 · 2026-08-15 (v0.1 consolidado; v0.2 registra D1–D5; v0.3 fecha a D6; v0.4 corrige a errata da contagem de gabaritos e registra o estado da F7.1; v0.5 registra a ENTREGA da F7.2 e reclassifica os oito itens do eixo C que ela fecha; v0.6 acrescenta a §11 — sessão de 2026-08-17 tarde: E-P1, CD-P2 e CD-P3 fechadas, BT-P1/PS-P4 prontas para gate; v0.7 acrescenta a §12 — o gate das quatro bancadas é OBSERVADO, BT-P1/PS-P4/DH-P6 FECHAM, e seis linhas do eixo C são reclassificadas ou corrigidas por errata de versão medida; v0.8 acrescenta a §13 — nasce a auditoria transversal de consumidor (§69 do
seed-componentes.md), a EA-P1 fecha, e a auditoria da SI-P4 e da IL-P2 acaba; v0.9 acrescenta a §14 — a GI2 vira guarda transversal, a BT-P3 fecha na forma supersedida, e o acervo deixa de estar sem defeito medido em aberto; v1.0 acrescenta a §15 — a CD-P7 ganha rito completo e veredito proposto, e a rodada de normas achou CD-P9; v1.1 acrescenta a §16 — BT-P6 fecha na causa, CD-P7 fecha por decisão, SI-P4/IL-P2/PS-P5 decididas, e nasce a MR-P1: o número 3,22 que sustenta a regra de branco sobre a marca nunca existiu)Duas descrições, e esta reconstituição não decide entre elas.
texto inteiro da versão
(entrada reconstituída em 2026-09-27, na v1.33 —
REV-P29; fonte: os comentários v1.14 do seed-tokens.css e as $description do JSON; a cadeia "Anterior" da linha "Editado" do cabeçalho; MANIFESTO §85 (edição v12.3) e §86; presentes desde fbba442e, o commit de origem é anterior a este repositório) Duas descrições, e esta reconstituição não decide entre elas. (1) Os gêmeos marcam como v1.14 o lote do retrofit RV1–RV10 de 2026-08-15: papéis tipográficos (--seed-txt-*), escala de raio em passo 2, meios-passos de espaço (6 e 10 px) e altura de controle (--seed-control-*) — o MANIFESTO §45 (edição v8.3, 2026-08-15) descreve esse lote sem citar o número da versão. (2) A cadeia "Anterior" da linha "Editado" deste arquivo descreve a v1.14 como surface-brand-subtle (#E8FBF7 claro · #1A3833 escuro), que fechou a BT-P6 na causa em 2026-08-17 (MANIFESTO §85), mais a primeira errata do "3,22". O MANIFESTO §86 (2026-08-17) registra os gêmeos saindo da v1.14 para a v1.15, o que é compatível com as duas. Se o retrofit e o surface-brand-subtle foram a mesma versão, ou se um deles entrou sem subir o número: não conferido — a história anterior a fbba442e não está neste repositório.Nascem os três row-selected-: o realce da linha selecionada em lista e tabela (F7.2).
texto inteiro da versão
(entrada reconstituída em 2026-09-27, na v1.33 —
REV-P29; fonte: a subseção row-selected-* do §3; a $description do JSON (F7.2) e o comentário do CSS; MANIFESTO §44 (edição v8.2), que lista os gêmeos em v1.13 com MD5; a cadeia "Anterior" da linha "Editado" do cabeçalho; presentes desde fbba442e, o commit de origem é anterior a este repositório) Nascem os três row-selected-*: o realce da linha selecionada em lista e tabela (F7.2). Adição pura. O realce não pode ser primitivo fixo — turquesa-100 mede 1,57 contra a tinta do tema escuro. Fecha a lacuna que a bancada banco-dados.html já vivia com definição local; quatro guardas novas na paridade.2026-08-14
A §3.6-b é promovida a estável
texto inteiro da versão
A §3.6-b é promovida a
estável pelo gate visual do Rafael sobre o seed-composicao-preview.html v0.1 (veredito G3: as seis posições da paleta de entidade aprovadas; veredito G4, na mesma sessão: marcador de "agora" em turquesa-600 fixo nos dois temas — registrado no CP24 do seed-composicao.md v1.1, terceiro membro da classe invariante de tema). Nenhum hex muda.Nasce a §3.6-b — REGRA DE ADMISSÃO DE COR DE ENTIDADE (rascunho, gate visual pendente; SUP-5 do confronto de referências).
texto inteiro da versão
Nasce a §3.6-b — REGRA DE ADMISSÃO DE COR DE ENTIDADE (
rascunho, gate visual pendente; SUP-5 do confronto de referências). Nenhum hex muda, nenhum vetor muda. Cor de entidade sai de paleta FECHADA (decisão Q1) e só é admitida passando 4,5:1 com uma de duas tintas declaradas (entity-ink-dark = cinza-900 · entity-ink-light = branco) — verificação estática na definição da paleta, nunca em render. Medição de 120 pares (6 famílias × 10 stops × 2 tintas): stops 50–400 admitem a tinta escura (pior 5,03) · stop 500 de QUALQUER família é inadmissível (zona de cruzamento, pior 4,30) · stops 600–900 admitem branco (pior 4,60). A paleta de 6 posições proposta e o consumo em composição vivem no seed-composicao.md §7 (novo 12º canônico da Fase 2). Precedente interno: a regra do amarelo do §3.6 já era tinta-por-cor.Sub-bloco DP (mapas):
texto inteiro da versão
(entrada retroativa, escrita na v1.11) Sub-bloco DP (mapas): adição de
chart-geo-base (território de contexto) e chart-geo-boundary (fronteira de município, piso 3:1). Nenhum valor anterior muda. Nota na §3c; errata E19 relacionada (chart-grid tem o mesmo hex de no-data).border-interactive — FECHA A SH-P1/PN-P5
texto inteiro da versão
border-interactive — FECHA A SH-P1/PN-P5 (aberta desde o bloco 6A, 2026-08-11). Fronteira de componente interativo (SC 1.4.11): promoção do empréstimo declarado do cinza-500 #788F9D a semântico, mesmo hex nos dois temas por medição (seis superfícies, 3,11–5,51, todas ≥3,0), slot dark declarado de propósito (coincidência medida, não invariância). Alternativa cinza-600 descartada com número (passa, mas mudaria cor renderizada aprovada em gate sem motivo). Gatilho: regra GI2 — a camada 2 foi editada pela CP-P3 (v1.11) e o Rafael mandou fechar na mesma janela. Gêmeos na MESMA edição; paridade-tokens.py 52 · 0. O campo de busca do shell passa a consumir o semântico (preview v0.3). Racional completo na nota do §3.Semânticos de COMPOSIÇÃO E CHROME (CP-P3 · SUP-6 em escopo mínimo) — nova subseção no §3.
texto inteiro da versão
Semânticos de COMPOSIÇÃO E CHROME (CP-P3 · SUP-6 em escopo mínimo) — nova subseção no §3. Entram, todos INVARIANTES de tema (sem redeclaração no bloco dark, de propósito):
rail-background (gradiente turquesa-700 → turquesa-800 do CP20, adotado no gate G2; extremos medidos 6,32/9,37) · chrome-overlay-hover/-active (véu branco .12/.14 sobre a rampa da marca — alphas fixados depois de medição em COMPOSIÇÃO: rótulo branco sobre overlay composto em cada extremo = 4,88/6,82 e 4,68/6,50, todos ≥4,5) · entity-1…6 com tinta por posição entity-N-ink (paleta fechada do CP23, gate G3; admissão CP22 medida: 5,11/5,30/5,63/9,37/6,43/6,68) · marker-now (turquesa-600 fixo, CP24/G4, ≥3,0 contra as cinco superfícies canônicas). Gêmeos JSON+CSS na MESMA edição (v1.11), paridade-tokens.py 52 PASS · 0 FAIL (G1 sem regressão: nenhum valor anterior muda — é ADIÇÃO). Motivação: pendência CP-P3 do seed-composicao.md (regeneração do shell, que também fecha a errata E-CP-01 — o C1 deixava de consumir a categórica). Errata desta edição, fechada pela regra GI2: a tabela deste §9 estava parada na v1.6 — as entradas v1.7–v1.10 nunca foram escritas aqui (mesma classe da E-6C-01 do seed-componentes.md: quem bumpa o título escreve a entrada na mesma edição); restauradas abaixo a partir das notas inline deste arquivo e do MANIFESTO, marcadas como retroativas.Normalização do focus-ring
texto inteiro da versão
(entrada retroativa, escrita na v1.11) Normalização do
focus-ring — o tema claro deixa de consumir o primitivo --seed-branco e passa ao semântico --seed-surface-page (o que o escuro já fazia); cor renderizada idêntica, muda a EXPRESSÃO. Achado veio de fora: paridade-previews.py acusou os previews, e eles estavam mais corretos que o canônico. Racional completo na nota do §3.2026-08-13
Registro da rodada do §48 Painel, sem mudança de paleta nem de logo — os 8 hex canônicos e os vetores seguem intocados.
texto inteiro da versão
Registro da rodada do §48 Painel, sem mudança de paleta nem de logo — os 8 hex canônicos e os vetores seguem intocados. Três seções novas: §3.5-b — a régua de ação foi CONFIRMADA; uma proposta de ação em
azul-800 viveu num preview, conflitava com o §3.5 e foi retirada no mesmo dia, sem nunca chegar ao canônico (a camada de tokens sempre teve action-primary = #098475). §3.5-c — nasce a ÂNCORA DE ÊNFASE: uma por página, cromática e não escura, base turquesa-400 com tinta única turquesa-900, anel turquesa-600 e véu de luz a 35%; com as três alternativas reprovadas e seus números. §3.5-d — a TINTA DE TEXTO passa à família da marca, só o texto: bordas e superfícies ficam neutras e a página branca, como faz a referência medida, e porque esverdear a superfície roubaria o contraste de saturação da âncora (medido: 2,71 → 2,21). Valores e medições no seed-tokens.md v1.9.SUPERSEDE DA TINTA DE TEXTO
texto inteiro da versão
(entrada retroativa, escrita na v1.11) SUPERSEDE DA TINTA DE TEXTO —
text-primary/secondary/muted migram da família cinza para a família turquesa da marca nos dois temas (#0B3330/#2F5A54/#40706A no claro), com supersede formal da restrição "nenhum hex novo" (valores entram como SEMÂNTICOS). Fecha na mesma edição a errata do text-muted, que REPROVAVA (2,80–3,38 no claro). Racional, tabela e alternativas descartadas na nota do §3. Fecha o PN-P1.2026-08-11
chart-no-data-hatch:
texto inteiro da versão
(entrada retroativa, escrita na v1.11)
chart-no-data-hatch: a tinta das linhas da hachura ganha token próprio (a E3 provou que papel de desenho sem token toma emprestado o de outro papel — era cat-5-stroke e virou violeta na v1.5). Medido contra o preenchimento: 3,93/3,84.Promoção da categórica ESTENDIDA da §3c a estável
texto inteiro da versão
Promoção da categórica ESTENDIDA da §3c a
estável, por "aprovo" explícito do Rafael sobre o lote de formalização da Fase 5 (o gate visual havia acontecido em 2026-08-10; o lote formalizou o que estava só nos previews). Nenhum valor de token muda nesta versão — é mudança de estado. Os gêmeos seed-tokens.json e seed-tokens.css acompanham para v1.6 para preservar a unidade md+json+css declarada no cabeçalho, seguindo o precedente da v1.4 (que também foi uma promoção de estado). Alternativa descartada: declarar o estado sem bump de versão, deixando os três em v1.5 — economizaria uma edição, mas criaria um arquivo cujo rótulo de versão não distingue "proposto" de "aprovado", que é exatamente a informação que o gate produz. Achado colateral registrado no seed-dataviz.md v0.6 §5 (errata E3): o supersede da categórica teve uma consequência não intencional — o cat-5, que na v1.0 era cinza-400 e servia de referência neutra no gráfico do alerta ET5, virou violeta na v1.5; referência de comparação não pode carregar cor de categoria viva, e o ET5 passa a consumir tinta neutra. É a classe de risco que qualquer troca de paleta cria: quem usava uma posição categórica como "neutro" perde o neutro em silêncio.Categórica ESTENDIDA (§3c) — supersede formal da categórica v1.0 e da restrição "nenhum hex novo" do DT.
texto inteiro da versão
Categórica ESTENDIDA (§3c) — supersede formal da categórica v1.0 e da restrição "nenhum hex novo" do DT. Racional medido: a marca tem só 3 matizes livres para dado (turquesa ~170°, dourado/amarelo ~36–50° — mesma família —, azul ~192–197°; vermelho e cinza são reservados), então nascem 2 matizes exclusivos de dataviz que nunca aparecem em UI (padrão IBM Carbon/GitLab): magenta 332° (
#CD518B/#E8A1C2) e violeta 268° (#966AC8/#BD9CE2), 6 hex novos no total, sem rampa no §2.1 de propósito. Sequência: turquesa → dourado → magenta → azul → violeta → azul-800 — 5 famílias, nenhuma repete antes da 6ª posição; ordem 2↔3 decidida no gate (dourado separa por peso os dois tons médios saturados). cat-1 light muda de turquesa-400 para turquesa-500 #00A192 (3.22 vs branco — o DG14 removeu o contorno e o fill passou a ter de passar 3:1 sozinho). Regra do dourado: permitido em área grande com rótulo direto; vetado como fill solitário sem rótulo (1.85 é insolúvel sem matar a cor da marca). O cinza sai da categórica (conflitava com a reserva de "sem dado"). Supersede DM3 no gauge: bandas viram intensidades de cinza (medido: as faixas coloridas distavam 1 ponto de claridade no light e 0 no dark); a barra de valor carrega a severidade; nenhum hex muda. Emenda GI2 cumprida: registrado que a rampa categórica ESCURA colapsa em claridade (75/75/71/71/67) por construção — é o que obriga o DG13. Achado da formalização: os previews aprovados embutiam 5 hex com deriva do canônico; a seção ancora nos stops reais do §2.1, com remedição provando veredito idêntico. Aprovação: gate visual do Rafael em 2026-08-10 ("tudo ok" sobre os previews v1.2/v0.7); leis de consumo no seed-dataviz.md v0.5. Gêmeos atualizados NA MESMA edição (v1.5), paridade-tokens.py com allowlist de supersede declarada.Sub-bloco DI escrito — §4c, DI1–DI19 — em duas partes: DI-a estável e DI-b aberto.
texto inteiro da versão
Sub-bloco DI escrito — §4c, DI1–DI19 — em duas partes: DI-a
estável e DI-b aberto. Consolidado aprovado pelo Rafael após 4 rodadas encadeadas (a 4ª disparada por regra: impresso é domínio novo para o projeto). O achado central não estava no roteiro: ao remedir a premissa represada no §5 ("o claro tem 7 pontos de espalhamento"), descobriu-se que o número era da categórica v1.0 com três séries; com as seis posições da v1.5 o pior par no modo claro mede 1 ponto (cat-1 × cat-4 e cat-3 × cat-5; claridades 56/75/49/55/50/27). O modo claro é seguro até três séries e colapsa a partir da quarta — fato de tela, anterior a qualquer discussão sobre papel. Daí o DI2, supersede formal do gatilho do DG13, que passa de "escuro ∩ grayscale" para grayscale ∩ (escuro OU ≥4 séries), e a errata E7 contra a redação anterior do §5. Por que o defeito sobreviveu dois sub-blocos: o contraste-dg.py percorre apenas cat1/cat2/cat3 — o detector estava recortado no lugar onde o defeito não mora; a pendência P8 do MANIFESTO.md deixa de ser higiene e passa a ser guarda ausente (reescrita especificada no DI18). Decisões de impresso: DI1 separa os dois destinos (laser de escritório = escopo; offset da gráfica, que exige PDF/X-1a em CMYK e declara variação de ±10% na cor dentro do mesmo lote = Fase 7) · DI4 proíbe informação de gráfico em background-color de CSS, porque print-color-adjust: exact é dica e a preferência do usuário no diálogo de impressão vence — com a inferência complementar (o fill de SVG sobrevive por ser conteúdo) declarada como não medida e transformada em teste da folha de prova · DI5 break-inside: avoid no <figure> inteiro · DI6 piso de traço a calibrar no papel · DI7 o DS não converte para CMYK (evita um segundo lugar onde a cor mora, contra o DF7) · DI8 PDF/A não adotado: nada no arcabouço CONFEA/CREA exige formato, o PDF/A é recomendação do CONARQ para o setor público, e o PDF/A-1 admite apenas assinatura simples — colidiria com o PAdES da ICP-Brasil, que é o que dá validade jurídica ao laudo assinado · DI9 fotocópia sem regra própria, com gatilho · DI10 fronteira com a F7. Guia da stack (DI11–DI17): a cadeia tem quatro saltos, não três — o fill do Recharts consome var(--color-CHAVE) gerado pelo ChartContainer, nunca --chart-N direto; sintaxe v3 sem hsl(); tema por [data-theme] e não pelo objeto theme do chartConfig; accessibilityLayer obrigatório e insuficiente (não cobre 1.1.1 nem 1.3.1 — o invólucro DG1 permanece por cima). DI19 decide o caminho do PNG do ET5: /email/v1/, porque a imutabilidade daquele caminho proíbe substituir arte, não acrescentar — e fecha a P4-b junto. DI-b (DI3) fica ABERTO por método: o veredito do gatilho da textura no papel só sai de prova impressa real, com protocolo de 7 itens fechado no §4c.3. Erratas novas: E7 (acima) e E8 (a §3c do seed-tokens.md cita o fundo dark #1C252B; o token real é #1D272D — remedido, deltas ≤0,24, nenhum veredito muda). Pendente deste lote: preview do DI, suíte, contraste-dg.py reescrito, PNG do ET5 e a folha de prova impressa.Gate visual aprovado nos previews corrigidos
texto inteiro da versão
Gate visual aprovado nos previews corrigidos — as v1.3/v0.8 passam a artefatos VIGENTES do DG e do DM. Mudança de estado apenas; nenhuma decisão de conteúdo. Fecha a janela de 2026-08-11, na qual a Fase 5 ganhou: a categórica ESTENDIDA
estável (tokens v1.6), o redesenho DG14–DG17 formalizado, o sub-bloco DM escrito e promovido, a P6 aberta e fechada no mesmo dia, e as seis erratas achadas e corrigidas. Próximo sub-bloco: DI (impresso/PDF + integração da stack), com o contraste-dg.py a atualizar antes ou durante — ele ainda mede o DG11 e a paleta anterior à v1.5.As seis erratas E1–E6 corrigidas nos previews
texto inteiro da versão
As seis erratas E1–E6 corrigidas nos previews, que passam a
seed-dataviz-graficos-preview.html v1.3 e seed-dataviz-monitoramento-preview.html v0.8 — na entrega, ambos aguardando gate visual (aprovado no mesmo dia, v0.8), porque correção de artefato aprovado não se auto-aprova e três das mudanças são visíveis (E1 medidores com role="meter", E3 troca de cor do "esperado" e da hachura, E5 rótulo da pizza sai da fatia). Nenhuma decisão de spec muda nesta versão: as erratas eram divergências do PREVIEW em relação à spec, e a correção fez o artefato alcançar a regra que já existia. Sétimo ponto achado durante a correção, tratado dentro da E3: a hachura do chart-no-data desenhava as linhas em cat-5-stroke — mesma armadilha do ET5, no lugar mais sensível possível, já que "sem medição" é exatamente o que não pode parecer categoria; passou a chart-axis. Regra nova, generalizada a partir daí: posição categórica nunca serve de neutro — referência, contexto e ausência consomem token com papel declarado (chart-no-data, chart-grid, chart-axis, cinza de contexto do DG17), porque cat-N pode trocar de cor em qualquer supersede de paleta, como trocou na v1.5. Validação: DG 163 PASS · 0 FAIL; DM 105 PASS · 0 FAIL · 0 FAIL DOCUMENTADO (a suite ganhou v2.1 com dois falsos negativos corrigidos: exigia aria-valuenow do medidor SEM leitura, que legitimamente não o tem, e não resolvia o alias novo do "esperado").PROMOÇÃO: o sub-bloco DM passa de spec escrita a estável
texto inteiro da versão
PROMOÇÃO: o sub-bloco DM passa de spec escrita a
estável, por "aprovo" explícito do Rafael sobre o lote de formalização. A Fase 5 fica com DF, DT, DG e DM concluídos; restam DP e DI. Nenhuma decisão de conteúdo mudou nesta versão — é mudança de ESTADO mais os registros que a promoção obriga. Pendência P6 FECHADA no mesmo dia em que nasceu: os dois previews aprovados foram reanexados e conferidos por MD5 2/2 (gráficos v1.2 8d1930…0fbf · monitoramento v0.7 f146c8…334c), e as suites passaram de placar reproduzido a placar executado contra os artefatos reais — suite-dataviz-dg.mjs 163 PASS · 0 FAIL e suite-dataviz-dm.mjs v2: 85 PASS · 0 FAIL · 6 FAIL DOCUMENTADO. Seis erratas E1–E6 medidas (§5), todas nascidas de rodar a automação contra o artefato depois do gate humano: role="meter" ausente no preview do DM (E1 — o DM4 não chegou a ser exercido no gate), sparkline a 1,6px contra os 2px que o próprio arquivo declara (E2), ET5 "esperado" em cat-5 que a v1.5 transformou em violeta (E3 — primeira consequência colateral medida de um supersede de paleta), deriva de 4 primitivos nos dois previews (E4 — nenhum veredito muda, deltas ≤1 ponto, mas prova que o bloco de tokens foi digitado e não copiado), rótulo interno da pizza a 4,30 (E5) e os dois arquivos declarando "v0.1" no próprio título (E6 — a identificação positiva por leitura do MANIFESTO §3.1 não funciona neles). Lição de método registrada na suite: a v1 da suite-dataviz-dm.mjs, escrita contra uma reconstrução enquanto o artefato estava ausente, produziu 26 FAIL no artefato real — 23 eram premissa da suite (ela codificava os NOMES da reconstrução como se fossem spec) e só 3 eram desvio genuíno. Suite escrita contra reconstrução testa a reconstrução; a v2 testa a mesma spec pelo COMPORTAMENTO (o alias resolve para cinza? o gatilho exige as duas condições?), não pelo seletor.Lote de formalização da F5 — o material aprovado nos gates de 2026-08-10 sai da conversa e entra no canônico.
texto inteiro da versão
Lote de formalização da F5 — o material aprovado nos gates de 2026-08-10 sai da conversa e entra no canônico. (1) Redesenho DG14–DG17 (§4.6, "gráfico de produto"): DG14 supersede o DG11 (zero contorno; vão de 2px como espaço negativo; possível porque a categórica v1.5 passa 3:1 sozinha); DG15 geometria orgânica (rx=3 universal, pílula em ranking, curva monótona Fritsch–Carlson 2px, gradiente 22%→0) + guarda DG15b (raio consistente — defeito achado pelo olho do Rafael, não pela regex); DG16 palco mínimo (≤3 gridlines, sem linha de eixo, número protagonista, badge-pílula, ponto de status com rótulo); DG17 destaque×contexto. Duas leis transversais: hierarquia de traço (2/1/0,5px + meta 1,5px como exceção +
vector-effect: non-scaling-stroke obrigatório — viewBox escalam 0,66×–12,4× medidos) e consumo da categórica estendida (5 famílias distintas até 5 séries; 6ª posição única exceção; teto 6; regra do dourado; ordem 2↔3 decidida no gate pelo peso do dourado). (2) Sub-bloco DM escrito por extenso (§4b, DM1–DM11): bullet graph canônico (Few/Cleveland–McGill), anatomia de 6 partes, DM3 papéis invertidos (supersede na §3c), role="meter"+aria-valuetext via useMeter (descartados <meter> nativo e progressbar), sparkline de Tufte com contrato decorativo DM6, DM7 rótulo de estado sempre visível, DM8 fecha o slot ET5 (PNG @2x 560px no R2), DM9 no-data nunca vira zero, DM11 textura de banda no gatilho do DG13 — com o registro de que o piso de 6 pontos não transfere de contexto (bandas a 9/8/17 seguiam indistintas; emenda no DG13). 4 defeitos de produção viraram guarda (variáveis órfãs, DM7 ausente, overflow de viewBox detectável só por getBBox em navegador real, acentos). Estado do DM: aguardando aprovo do lote. (3) Emendas: DG5-b remedido para a paleta v1.5 (interno só em cat-2/cat-6; errata do "45%" latente no preview), DG10-b com racional supersedido e teto mantido, DG12 restrito ao rótulo + exceção do DM. (4) Achados da formalização: previews aprovados AUSENTES do Drive (alvos MD5 registrados; pendência P6) · deriva de 5 hex nos previews vs canônico (ancoragem nos stops reais, veredito idêntico) · GI2 do colapso dark CUMPRIDA na §3c v1.5. Suite do DG na versão final: 163 verificações.GATE VISUAL DO PREVIEW v0.4 APROVADO — o sub-bloco DP fica SEM NENHUMA PENDÊNCIA ABERTA, e com isso a Fase 5 fecha sem ponta solta.
texto inteiro da versão
GATE VISUAL DO PREVIEW v0.4 APROVADO — o sub-bloco DP fica SEM NENHUMA PENDÊNCIA ABERTA, e com isso a Fase 5 fecha sem ponta solta. Nenhuma decisão de conteúdo muda: é mudança de estado mais o registro que a aprovação obriga. As seis pendências nominais do DP, todas fechadas no mesmo dia em que o sub-bloco nasceu: DP-P1 (token do território e da fronteira — fechou com dois tokens novos e as erratas E19/E20) · DP-P2 (largura mínima da variante malha completa — medida agora: ≥ 640px) · DP-P3 (piso de claridade do polígono — fecha como decisão, com o piso declarado NÃO herdável e transferido ao DP14) · DP-P4 (paralelos da projeção) · DP-P5 (tolerância de simplificação, que superseiu o DP9) · DP-P6 (edição da Malha Municipal Digital). Placar final das quatro camadas com a geografia real: jsdom 82 PASS · 0 FAIL · render em Chrome real 22 PASS · 0 FAIL · contraste 27 PASS com 23 candidatas reprovadas de propósito · gate visual aprovado. Nota de fronteira sobre a DP-P3, para que ninguém a leia como resolvida por decreto: o piso de claridade para polígono de município não foi calibrado — foi declarado como não herdável e adiado até existir um coropleto com dado real, porque calibrar contra exemplo inventado produz o verde que impede a procura. A pendência fecha como decisão, não como medição, e isso está escrito no §4d.6.
A MALHA REAL DO IBGE ENTRA E FECHA TRÊS PENDÊNCIAS (DP-P4, DP-P5, DP-P6). O preview deixa de usar malha sintética.
texto inteiro da versão
A MALHA REAL DO IBGE ENTRA E FECHA TRÊS PENDÊNCIAS (DP-P4, DP-P5, DP-P6). O preview deixa de usar malha sintética. Fonte: Malha Municipal Digital do IBGE, edição 2025, baixada do portal oficial pelo Rafael em três pacotes Shapefile (MG, ES, BA), SIRGAS 2000, UTF-8 — 1.348 municípios, 4.251.625 vértices, 135,9 MB de GeoJSON bruto. Registro de fonte descartada: antes disso a malha veio do espelho
tbrugz/geodata-br (GitHub, CC0), porque o domínio do IBGE não é acessível da máquina de execução; as contagens batiam, mas os vértices não — 143.319 contra 4.251.625. O espelho já era ~30× simplificado e não declarava. DP15 (novo, §4d.14b): as ilhas oceânicas de Vitória saem do desenho, não do dado — a extensão de longitude cai de 22,20° para 13,70°, evitando 40% de figura em oceano vazio. DP-P4 fechada: paralelos -20,52° / -10,93° calculados da extensão real. DP-P5 fechada, e o resultado SUPERSEDIU o DP9: um único asset a 2%, no lugar de dois níveis — a diferença medida entre os níveis era de 192 KB, e duas fontes da mesma geometria por isso viola o DF7. Piso declarado: erro de área p99 ≤ 2% (medido 1,78%). DP-P6 fechada: edição 2025, no nome do asset. Instrumento novo: erro de área por município medido na projeção real, contra a malha bruta — é a métrica certa porque num coropleto a área desenhada é o que compara os dados. Caso-limite achado sozinho: Santa Cruz de Minas (MG), 3,565 km², erra 4,2% a 2% e 20,5% a 1%. Preview a v0.4, com a malha oficial renderizada pela cadeia REAL do DP2 (d3-geo + topojson-client). Suíte a 82 PASS · 0 FAIL (era 77) e render 22 PASS · 0 FAIL. Três defeitos achados na inspeção das capturas, nenhum visto pela automação: (1) a tabela do fallback transbordava 8px a 360px — corrigida com o contêiner rolável nomeado e focável do Bloco 6; (2) a descrição do DP1 ainda dizia "malha sintética" depois da troca — artefato mentindo sobre si mesmo, a classe da errata E6; (3) dois códigos IBGE digitados de memória apontavam para municípios errados (Vitória virou Cariacica, Cachoeiro virou São Mateus): o preview ficava correto e dizendo outra coisa. Regra que sai daqui: identificador digitado de cabeça é a mesma classe de defeito que a regra "geometria é calculada, nunca digitada" já cobria — a seleção passou a ser resolvida por nome contra a própria malha, com asserção.PROMOÇÃO: o sub-bloco DP passa a estável e A FASE 5 ESTÁ FECHADA.
texto inteiro da versão
PROMOÇÃO: o sub-bloco DP passa a
estável e A FASE 5 ESTÁ FECHADA. Os seis sub-blocos — DF, DT, DG, DM, DI e DP — são todos estável, e o marco v1.6 é disparado. Nenhuma decisão de conteúdo muda nesta versão: é mudança de ESTADO mais o registro que a promoção obriga. Placar final das quatro camadas de validação do DP: jsdom 77 PASS · 0 FAIL · render em Chrome real 22 PASS · 0 FAIL · contraste 27 PASS com 23 candidatas reprovadas de propósito (é a evidência que fundamenta os dois tokens novos) · gate visual aprovado. Fronteira do que o gate cobriu: o Rafael inspecionou o preview v0.2 e respondeu os cinco pontos do protocolo; a v0.3 difere em um único ponto (a tinta da contagem, corrigida pelo DG12) e foi aprovada sobre relato de medição e de inspeção de captura. Registrado porque fato e inferência se declaram separados. Pendências que o DP leva consigo para a Fase 6, todas declaradas: DP-P2 (largura mínima da variante malha completa) · DP-P3 (piso de claridade do polígono de município, que só fecha com coropleto de dado real) · DP-P4 (paralelos da projeção para o recorte MG-ES-BA) · DP-P5 (tolerância de simplificação) · DP-P6 (ano da Malha Municipal Digital do IBGE). O preview usa malha SINTÉTICA declarada enquanto a DP-P6 não fecha. Item obrigatório do marco, executado: a AUDITORIA DE IMPACTO DAS LACUNAS do §6 do estudo-viver-de-ia.md, agora na §6b daquele arquivo (v1.3). Veredito: nenhuma lacuna exige supersede em algo estável; e uma das cinco lacunas vermelhas não existia — a "camada de movimento" está nos gêmeos desde a camada de primitivos (errata E-EST1).A camada de RENDER do sub-bloco DP foi executada — e ela havia sido PULADA em silêncio nos lotes anteriores.
texto inteiro da versão
A camada de RENDER do sub-bloco DP foi executada — e ela havia sido PULADA em silêncio nos lotes anteriores. Cobrança do Rafael, correta: "você precisa rodar o teste e enxergar essas coisas antes de eu testar". Fato registrado sem atenuante: nos lotes das v0.14–v0.16 eu verifiquei que não havia navegador headless na máquina, não avisei, e segui — de modo que a régua de quatro camadas (jsdom · render · contraste · gate humano) rodou com três. O defeito das 360px morava exatamente na camada ausente. Ambiente resolvido com o binário de Chromium empacotado em npm (
@sparticuz/chromium + puppeteer-core), já que o download normal do Chrome não passa pela rede desta máquina. Nasce a render-dp.mjs: 22 PASS · 0 FAIL, medindo o que jsdom não vê — colapso real da grade em cada largura (R1), equivalência entre o controle de largura e o redimensionamento real da janela (R2, a regra do §4d.15), estouro de viewBox por getBBox() em navegador real (R3), espessura RENDERIZADA das fronteiras com o viewBox escalando 0,82× (R4, prova do non-scaling-stroke) e ausência de transbordo horizontal (R5). O defeito que só a inspeção das capturas achou, e que é violação de regra existente: a contagem de agrupamento do DP11 estava pintada em branco fixo. O DG12 determina há dois sub-blocos que tinta sobre dado não segue o tema e consome cinza-900 nos dois modos, porque o fill categórico é claro nos dois modos. Medido: branco contra os fills do tema escuro dá 1,83 · 2,04 · 2,05; cinza-900 dá 7,57 · 6,80 · 6,77 no escuro e 4,30 · 3,40 · 4,17 no claro. Preview a v0.3, guardas DP11-02b/c/d na suíte (77 PASS · 0 FAIL, era 74); prova de que são reais: contra o preview v0.2, reprovam em 2. Classe do defeito: regra do sistema não aplicada em consumidor novo — o DG12 nasceu para rótulo interno de barra e fatia, e o marcador de mapa é rótulo interno também; ninguém fez a ligação. Parente direto da E19, que herdou de outro consumidor sem remedir. Lição de método, e é a mais cara deste sub-bloco: camada de validação indisponível não é camada dispensável — é pendência a declarar. Pular em silêncio produz o mesmo verde de quando tudo passou. Nenhuma decisão de spec mudou nesta versão.O gate visual do Rafael achou um defeito que 68 verificações automatizadas não viam — e o defeito era no INSTRUMENTO, não no desenho.
texto inteiro da versão
O gate visual do Rafael achou um defeito que 68 verificações automatizadas não viam — e o defeito era no INSTRUMENTO, não no desenho. Ele testou os cinco pontos do gate no preview v0.1 e mandou uma captura da tela a 360px: as duas figuras do DP5 apareciam lado a lado, com cerca de 170px cada, em vez de empilhadas. Causa medida: o controle de largura da barra mudava o
max-width do contêiner, enquanto a regra que empilha a grade era uma @media ancorada na largura da janela — que continuava larga. Consequência dura: a dimensão "largura" da matriz de render nunca foi exercida de verdade; o que aparecia na tela ao escolher "360" era uma célula que não existe na matriz. Regra nova, registrada no §4d.15 e mais geral que o sub-bloco: simular uma dimensão da matriz só vale se a simulação dirigir as MESMAS regras que a realidade dirige. Correção: preview a v0.2, com o contêiner virando container de consulta (container-type: inline-size) e as regras de layout passando a @container — assim o controle e a janela real disparam o mesmo conjunto de regras. Guardas novas LARG-01…LARG-05 na suíte; prova de que são reais: contra o preview v0.1, reprovam em 3. Segunda correção de âncora no mesmo lote: a verificação HIG-03 procurava a string literal preview v0.1 no título — guarda que quebra a cada revisão e que, pior, convida a mentir de volta, que é exatamente a errata E6. Passou a exigir que o título declare alguma versão e que ela seja a mesma do <h1>. Placar da suíte: 74 PASS · 0 FAIL (era 68). O que o episódio prova, e é o motivo de o gate visual ser estruturalmente não-opcional: nenhuma das verificações automatizadas via o defeito, porque jsdom não resolve layout e a suíte conferia a presença da regra, não quem a dispara. Nenhuma decisão de spec do DP mudou nesta versão.A medição do DP mudou DUAS decisões que já haviam sido aprovadas no gate — e fechou a pendência DP-P1 no mesmo dia em que ela nasceu.
texto inteiro da versão
A medição do DP mudou DUAS decisões que já haviam sido aprovadas no gate — e fechou a pendência DP-P1 no mesmo dia em que ela nasceu. Nasce o
contraste-dp.py v1, instrumento do sub-bloco DP, que extrai os hex do seed-tokens.css em vez de digitá-los (lição das erratas E4/E16) e mede seis famílias de pares nos dois temas: colisões de valor entre papéis, território × fronteira, território × sem-medição, hachura, marcador × território e marcadores entre si em escala de cinza. Achado 1, que é um fato do sistema e não do mapa: chart-grid e chart-no-data têm o mesmo hex nos dois temas (#E3EBF0 light, #38464F dark) — o que torna a condição (b) da §3c ("fronteira sustentada por chart-grid") impossível de cumprir sobre uma célula sem medição, com razão 1,00. O defeito é antigo e nunca apareceu porque no heatmap a célula no-data é hachurada e as vizinhas são sequenciais saturadas: a fronteira nunca precisava separar dois cinzas. Num mapa, separar dois cinzas é o caso normal. Errata E19 e supersede no §6. Achado 2: no tema escuro chart-axis é o mesmo hex do chart-no-data-hatch (#90A6B3) — logo emprestar chart-axis para a fronteira repetiria a estrutura da E3. Daí dois tokens novos na v1.8 dos três gêmeos: chart-geo-base (território de contexto) e chart-geo-boundary (fronteira), ambos com valor idêntico a tokens existentes de propósito — o que muda não é a cor, é a responsabilidade de mantê-la. Achado 3, o mais incômodo: o DP10 dizia "cor até 3 categorias, forma acima disso", e descartava por raciocínio a redundância cor+forma desde a primeira. A medição inverte: no dark os três pares de marcador medem 3,6 · 3,7 · 0,2 pontos de claridade e no light o par cat-1 × cat-4 mede 0,9, todos abaixo do piso de 6. A forma passa a ser o portador permanente da categoria e a cor vira redundância (errata E20). O dourado sai da paleta de marcador por aplicação da regra do dourado que já existia (fill pequeno e solitário), e o marcador ganha contorno em cat-N-stroke, cuja própria descrição nos gêmeos nomeia o caso: "marcador pequeno — o pior caso do 1.4.11". Lição de método, terceira ocorrência registrada: não diagnostique por raciocínio, meça — aqui o raciocínio não errou um diagnóstico, errou uma decisão de design aprovada, e o que a pegou foi a pendência ter sido declarada em vez de resolvida por escolha. Gêmeos a v1.8 (adição pura: nenhum valor anterior muda) e a guarda paridade-tokens.py estendida para os dois tokens novos — 52 PASS · 0 FAIL, e prova de que a guarda nova é real: rodada contra o CSS v1.7, reprova em 4. Errata E8 CORRIGIDA de passagem na mesma edição, pela regra GI2: a §3c citava o fundo dark #1C252B, e o token é #1D272D. Pendente deste lote: preview do DP construído sobre a spec corrigida, suíte, gate visual e a edição do MANIFESTO.md.Spec do sub-bloco DP — mapas de atuação MG-ES-BA — em §4d, DP1–DP14. Com ela, os SEIS sub-blocos da Fase 5 existem; falta o gate visual do DP para fechar a fase.
texto inteiro da versão
Spec do sub-bloco DP — mapas de atuação MG-ES-BA — em §4d, DP1–DP14. Com ela, os SEIS sub-blocos da Fase 5 existem; falta o gate visual do DP para fechar a fase. Consolidado aprovado pelo Rafael após 3 rodadas encadeadas de pesquisa (R1 canon interno · R2 mercado/stack de mapa em React · R3 normas: IBGE, projeção cartográfica, acessibilidade de mapa). Escopo decidido em briefing ANTES da pesquisa — pontos e não coropleto, três destinos (impresso, ERP, site), figura fixa, três níveis geográficos, sem identificação de cliente em peça externa, sem fonte de malha preexistente na empresa. Registro de método: a primeira formulação da pergunta (d) foi respondida com uma correção do Rafael — a proposta de dois níveis (estado + ponto) foi recusada com "eu tenho que ter todos os municípios", e a redação da proposta induzia a leitura errada de que municípios sem obra sumiriam do mapa; a decisão final (DP5) mantém o território sempre inteiro e torna seletiva apenas a linha de fronteira. Três achados da R1 mudaram o desenho: (1) a §3c do
seed-tokens.md já nomeia "mapa coroplético" como consumidor da escala sequencial e já traz as três condições obrigatórias da isenção do WCAG 1.4.11 — entre elas fronteira por chart-grid, o que dispensa o supersede do DG14 que eu previa e o reduz a precisão de escopo (DP4); (2) o traço de 0,5px seguia sem consumidor e a fronteira municipal da variante malha completa é o primeiro (DP5); (3) o DF2 tem uma lacuna: declara shadcn Chart sobre Recharts como consumidor canônico web, e Recharts não desenha mapa — emenda formal no §6. Achado da R2/R3: projeção equivalente (Albers) é obrigatória e Mercator é vetado, porque nosso recorte vai de ~-8° a ~-22° de latitude e a deformação de área seria sistemática e direcional, inflando a Bahia contra Minas — mentira visual da empresa sobre si mesma. Achado que inventa vocabulário, o único do sub-bloco: o DI2 manda texturizar, mas textura não cabe num marcador de 8–12px; em mapa a distinção em escala de cinza passa a ser por forma (círculo/quadrado/triângulo), com teto de 3 categorias — menor que o teto de 6 da categórica, e portanto um mapa da SEED não consegue mostrar os cinco pilares como cinco marcadores legíveis em mono. Advertências do IBGE que entram no canônico (DP8): os limites da Malha Municipal Digital são aproximados, o IBGE não tem atribuição legal de demarcação, e a malha é republicada anualmente — logo o mapa da SEED não serve como peça de definição de limite territorial, e o asset declara o ano. Matriz de render ganha dimensão nova: largura de renderização (360 · 768 · 1200), cruzada com tema × grayscale × impressão. Seis pendências nominais nascem declaradas (DP-P1…DP-P6, §4d.16), nenhuma bloqueando a spec e todas bloqueando a promoção a estável. Pendente deste lote: preview do DP, suíte, gate visual do Rafael e a edição do MANIFESTO.md que ancora este arquivo e os artefatos do DP.SUPERSEDE do DM8: o e-mail de alerta de geração não leva gráfico.
texto inteiro da versão
SUPERSEDE do DM8: o e-mail de alerta de geração não leva gráfico. Decisão do Rafael no gate de produção do asset, contra o desenho que eu havia especificado e produzido. Racional, que é mais forte que o original: o PNG hospedado no R2 é arquivo único servido a todos os disparos, logo os números nele são ilustrativos — o cliente cujo desvio real é de 6% receberia um e-mail com imagem mostrando 18%, contradizendo o texto ao lado. Quem vê isso não conclui "a imagem é genérica", conclui que o sistema erra; e um alerta existe precisamente para ser confiável. Regra vigente: o e-mail avisa, o sistema mostra — dado real vive onde o cliente entra para ver. O slot ET5 sai da dataviz e volta ao
seed-email.md SEM REGRA NOVA: o EC5 já determina ícone raster sob demanda, rasterizado do SVG normalizado quando um template o pede, em /email/v1/icones/; um template de alerta pedindo glifo de alerta é o caso previsto, e o DM8 havia contornado essa lei ao especificar um PNG de conteúdo. Descartado: gráfico gerado por usina no envio — não por mérito, mas por domínio, já que o DM10 pôs comportamento dependente de dado vivo no produto. Registro material: o PNG seed-email-et5-grafico@2x.png (1120×520 @2x, 28.441 B, MD5 f2ad29b3a8075da85c67f157399711fd) chegou a ser produzido, com fonte SVG e gerador, e foi descartado sem subir ao R2 — fica anotado que existiu para que ninguém o ache num diretório de trabalho e o suba supondo propagação pendente. O DI19 permanece válido quanto ao caminho e muda de objeto. Lição de método: a spec do DM8 foi escrita sem perguntar de quem é o dado que a peça mostra — a pergunta que o gate fez em dez segundos e que teria evitado a produção inteira.DI-b FECHADO por prova impressa física. O sub-bloco DI está completo e a Fase 5 fica a um sub-bloco do marco.
texto inteiro da versão
DI-b FECHADO por prova impressa física. O sub-bloco DI está completo e a Fase 5 fica a um sub-bloco do marco. (1) Produzida a folha de prova de 7 itens (
seed-dataviz-di-prova-impressa.pdf, A4 retrato com orientação declarada em CSS, 3 páginas, questionário de 6 perguntas na última) e impressa pelo Rafael duas vezes na mesma impressora física, em cor e em escala de cinza pelo driver. (2) Veredito do DI3: o modo de impressão NÃO entra no gatilho da textura, porque não precisa. Em cor as 6 séries se distinguem — textura ali seria o ruído que derrubou o DG11. Em mono, que é grayscale por definição, o gatilho do DI2 já dispara com 6 séries. Descartado: acrescentar "impresso" como terceira condição — redundante e pior, porque regra duplicada é o que deriva quando uma das duas é editada e a outra não, a classe de defeito das erratas E12/E14/E16. O item 1 da folha era controle, não caso de uso: 6 séries sem textura em cinza é situação que a regra vigente já proíbe, e falhou como previsto. A prova validou a regra existente no meio em que ela nunca havia sido testada, em vez de pedir regra nova. (3) Os dois pares que colapsaram a olho são exatamente os dois previstos: "Fora de ponta" ≈ "Bombeamento" (cat-1 × cat-4, 56% × 55%) e "Reservado" ≈ "Iluminação" (cat-3 × cat-5, 49% × 50%), ambos a 1 ponto — zero falso positivo e zero falso negativo em 15 pares. (4) SUPERSEDE da regra do piso, e é o achado mais valioso do sub-bloco: ela dizia que o piso decide só no contexto em que foi calibrado, e foi lida como meio novo exige calibração nova — foi por isso que o DI3 nasceu prevendo piso próprio para papel. A variável nunca foi o meio, foi a FORMA. No DM11 eram bandas finas de medidor a 9/8/17 pontos, indistinguíveis na tela; aqui são barras altas adjacentes, a forma em que o piso foi calibrado, e o instrumento acertou no papel. Forma diferente + mesmo meio → erra; mesma forma + meio diferente → acerta. Regra vigente: o piso é calibrado por forma e vale para aquela forma em qualquer meio; forma nova (banda, fatia fina, célula de heatmap) exige recalibração por gate mesmo no meio de sempre. (5) As 6 texturas se distinguem no papel em escala de cinza — o vocabulário estendido a 6 posições da v0.10 sobrevive ao impresso. (6) DI6 fechado sem piso próprio: as quatro espessuras (2 · 1,5 · 1 · 0,5px) saíram distintas na impressão física, nenhuma sumiu nem engordou; a hierarquia de traço vale igual no papel. (7) Fronteira do instrumento, por crítica do Rafael: a régua mede sobrevivência, não adequação — espessura isolada com rótulo abstrato responde "a impressora deposita?" e não "é adequada aqui?"; a segunda pergunta exigiria as espessuras aplicadas no gráfico. Achado colateral: o piso de 0,5px não tem consumidor — a grade do preview do DG está toda em 1px, e valor que existe na lei sem ser exercido deriva; a verificar na Fase 6. Pendente do lote: PNG @2x do ET5 e a edição do MANIFESTO que ancora a folha de prova, o preview do DI v0.3, a suíte do DI e este arquivo.O DI4 sai de inferência para fato medido, e nasce a suíte do sub-bloco DI.
texto inteiro da versão
O DI4 sai de inferência para fato medido, e nasce a suíte do sub-bloco DI. (1) Gate de impressão do Rafael (Chrome, "Salvar como PDF", A4): a matriz de quatro células do preview do DI devolveu C sumiu · D sobreviveu com "Gráficos de segundo plano" desmarcado —
background-color de CSS desaparece quando nada o protege, fill de SVG sobrevive por ser conteúdo desenhado. Regra do DI4 provada como escrita (§4c.4). Segundo achado não previsto: a célula A sobreviveu, ou seja, o Chrome honra print-color-adjust: exact mesmo contra a preferência desmarcada — há duas camadas de proteção e elas não valem o mesmo; a regra dura do DS continua sendo a estrutural, porque a de CSS é documentadamente uma dica. Fronteira declarada: um navegador, um destino; Firefox e driver físico não medidos. (2) Erro de método registrado: a v0.1 do preview tinha duas células e não isolava a variável, porque a folha de impressão declara exact num seletor universal e protegia os dois braços do próprio teste — a primeira rodada devolveu um resultado verdadeiro que respondia outra pergunta. (3) Preview do DI chega à v0.3 e a suite-dataviz-di.mjs nasce com 32 verificações, cobrindo DI4, DI5, DI6, o modo de impressão forçado ao claro, as cinco partes do DG1 no exemplo, o guia de integração e a higiene de tokens; rodada contra a v0.1, reprova em 4 — as guardas são reais. (4) Errata E17: vector-effect não é herdada (SVG 2 a define como Inherited: no), então declará-la num <g> é inócuo; o preview do DG sempre aplicou por seletor universal e o do DI copiou o conceito da lei do §4.6 sem copiar a implementação que a torna verdadeira. (5) Dois defeitos de papel achados pelo gate e que nenhuma automação veria: uma .nota partindo entre páginas (o break-inside: avoid cobria só os blocos longos) e as células do teste com áreas diferentes (o SVG preservava a proporção do viewBox). Padrão que se repetiu três vezes neste lote e vale como regra: quando um teste e o comportamento discordam, quase sempre é o teste que está olhando para o lugar errado — aconteceu no DG7-03, no contraste-dg.py e no DI6-02. Pendente: PNG @2x do ET5 e a folha de prova do DI-b (o gatilho da textura no papel, que segue ABERTO — o gate de impressão desta versão mediu o DI4, não o DI3).Lote de produção do DI-a.
texto inteiro da versão
Lote de produção do DI-a. Nenhum gráfico novo e nenhum tipo novo: o DI não cria gráfico, cria comportamento. (1) Vocabulário de textura do DG13 ESTENDIDO de 4 para 6 posições (linhas verticais na 5, diagonal a 135° na 6 — nunca 45°, que é exclusiva do
chart-no-data), aprovado no gate de 2026-08-11. A lacuna existia desde sempre e era invisível porque o gatilho antigo nunca foi exercido contra um gráfico de 5 ou 6 séries. (2) seed-tokens.md vai a v1.7 com o token novo chart-no-data-hatch (cinza-600 / cinza-400), fechando a errata E13; os três gêmeos foram editados na mesma edição e o paridade-tokens.py fecha em 50 PASS · 0 FAIL. (3) contraste-dg.py reescrito (v2, DI18): mede o DG14 em vez do DG11 morto, as seis séries da v1.5 em vez de três, e opera o portão do DI2 varrendo todos os pares para 2…6 séries nos dois modos — 38 PASS · 0 FAIL · 20 MITIGADO · 4 ISENTO. Fecha a pendência P8. (4) Preview do DG a v1.4 com a E11 corrigida (a pizza de 5 séries passa a texturizar), o gatilho DI2 implementado por atributo data-series no <figure> — para a condição ficar auditável no DOM e não escondida em JS —, os patterns tex-s5/tex-s6 e a hachura no token novo. (5) A suíte ganha a seção que o §6 dizia existir e não existia (errata E12): 11 verificações TEX-* + 2 NEU-*, levando o placar de 163 a 176 PASS · 0 FAIL. Prova de que a guarda é real: rodada contra o preview v1.3 antigo, ela reprova em 4. Oito erratas E9–E16 (§5), três delas de uma classe nova — correção declarada que não foi inteiramente aplicada: a E14 mostra que a E3 trocou a tinta da hachura só no swatch da legenda, deixando os dois <pattern> SVG em violeta desde a v1.5; a E15 acha a terceira ocorrência da mesma armadilha na série "Esperada"; a E16 mede 19 tokens semânticos derivados no bloco embutido do preview e os corrige por script a partir do canônico — a guarda que a E4 havia pedido — e de quebra explica a E8, porque a §3c copiou o fundo de referência dark do preview em vez de copiar do token. Regra de método que sai do lote: correção de errata se verifica pela medição do que ela prometia consertar, não pelo fato de o arquivo ter mudado. Percalço de produção registrado: a primeira edição do CSS dos tokens usou replace de texto e a linha indentada a 2 espaços casou dentro da indentada a 4, dentro do @media (prefers-color-scheme: dark), duplicando uma declaração fora de qualquer seletor; pego na leitura de volta e refeito por regex de linha inteira. Guarda que fica: edição cirúrgica de CSS por replace de texto é insegura quando o mesmo token existe em blocos de indentação diferente — o casamento tem de ser ancorado na linha. Pendente: gate visual do preview v1.4, preview do DI, PNG do ET5 e a edição do MANIFESTO (que fecha E9, E10, P8 e P4-b).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).
texto inteiro da versão
MARCO v1.7 — o sub-bloco DG (gráficos core) fecha
estável com 13 decisões, e o sistema ganha uma PALETA CATEGÓRICA ESTENDIDA e um redesenho visual inteiro (DG14–DG17). O DG cobre sete tipos — barra, empilhada, agrupada, linha, área, pizza, dispersão — mais os três estados herdados do Bloco 3. Duas emendas aconteceram durante a produção: a barra empilhada foi puxada para dentro do escopo a pedido do Rafael (caso real: consumo por posto tarifário), trazendo junto a agrupada como saída obrigatória; e o DG13 (textura) nasceu do gate. Âncoras da spec: DG1 — todo gráfico é um invólucro de 5 partes com fallback textual sempre presente, porque a auditoria pública de 2024 do shadcn Charts reprovou a biblioteca em 1.1.1 (sem alternativa textual) e 1.3.1 (legenda sem relação codificada): acessibilidade de gráfico não se delega à lib · DG2 — um tab-stop + setas, com o gap do VoiceOver declarado e não resolvido (o Recharts contorna com role="application", que o VO não suporta), logo o teclado é enriquecimento e quem garante o acesso é a tabela · DG4 — eixo zero é regra dura assimétrica: barra e área sempre do zero porque comprimento e área codificam valor por geometria; linha pode truncar sob três condições, e a SEED precisa disso (PR de usina e tensão de rede variam pouco e importam muito) · DG5 — pizza com 8 travas, incluindo a regra dos 5 p.p. e o corte do dado ordinal · DG10 — empilhada com teto de 4 segmentos (aperto deliberado sobre os 5 do mercado, por motivo interno: acima disso a paleta pareia matizes da mesma família, e segmento preenchido não carrega tracejado para desambiguar). O MARCO TEM QUATRO FATOS DE MÉTODO, TODOS NASCIDOS NO GATE VISUAL E NENHUM ANTECIPÁVEL PELA PESQUISA. (1) Instrumento errado, medição certa. O portão de grayscale media razão de contraste WCAG entre séries convertidas para cinza e reprovava o modo claro (cat-1 × cat-3 = 1,22) — exatamente onde o gate humano lia bem. A razão de contraste foi calibrada para texto sobre fundo, não para faixas grandes adjacentes separadas por contorno; a métrica correta é o espalhamento de claridade (claro espalha 20 pontos; escuro comprime em 4, com duas séries idênticas). O piso de 6 pontos ficou declarado no código como calibrado pelo gate, não derivado de norma — e quando tentei generalizá-lo para as bandas finas do DM, o gate reprovou de novo: um piso vale só no contexto em que foi medido. (2) A paleta da marca tem teto físico. Medindo o matiz de todos os primitivos: para dado existem 3 matizes livres (turquesa ~170°, dourado/amarelo ~36–50° — mesma família —, azul ~197°), porque vermelho e cinza são reservados. A restrição "nenhum hex novo" que eu mesmo propus no DT provou-se apertada demais e vai a supersede. Seguindo o padrão IBM Carbon/GitLab (paleta de dataviz separada da marca), nasceram 2 matizes exclusivos de dado, que nunca aparecem em UI: magenta 332° e violeta 268°, calibrados na claridade das âncoras SEED. Sequência final: turquesa → dourado → magenta → azul → violeta → azul-800, cobrindo 5 famílias, com a regra de que nenhuma família repete antes da 6ª posição e nenhum gráfico multi-série pareia tons da mesma família — esta última nasceu do Rafael apontar que a linha dupla e o gráfico do ET5 tinham ficado turquesa × turquesa. (3) Vida não vem de cor, vem de renderização. O Rafael trouxe 7 telas de um produto de referência e pediu análise antes de qualquer execução. O achado contrariou minha própria hipótese: os gráficos da referência são quase monocromáticos e mesmo assim parecem vivos. O que separava era a renderização — daí DG14 (zero contorno; separação de segmentos por vão de 2px, geometria em vez de contraste; cat-1 claro → turquesa-500 para passar 3:1 sozinho), DG15 (canto arredondado em todo retângulo de dado; curva monótona, nunca spline genérica, que inventa picos inexistentes; gradiente 22%→0), DG16 (palco mínimo: ≤3 gridlines hairline, sem linha de eixo, número protagonista com micro-caps mono e variação em pílula) e DG17 (destaque×contexto). O DG11 — contorno cinza-900, que eu havia criado por medição poucos dias antes — foi superado por completo: era ele que dava o ar de relatório antigo. A acessibilidade foi preservada por outros mecanismos, todos medidos, e o DG13 permanece: a paleta estendida melhora o colorido, não revoga a textura. (4) A matriz de render se CRUZA, não se amostra. Havia 4 cenários cobrindo claro+grayscale e escuro, mas nunca a combinaçã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.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).
texto inteiro da versão
MARCO v1.6 — A FASE 5 (DATA VISUALIZATION) ABRE, e seus dois primeiros sub-blocos já são
estável: DF (fundamento) e DT (tokens de dado). Nasce o 9º arquivo canônico, seed-dataviz.md v0.3, pela mesma classe de conflito que criou o seed-email.md na F4: cor de dado não é cor de UI. O semântico de UI carrega intenção de interface — a série 2 de um gráfico não é "ação" nem "erro", é a segunda categoria de um dado, e obedece a leis que a UI não tem (ordem fixa, diferenciação perceptual entre vizinhas, comportamento sob grayscale, e uma isenção normativa que nenhum componente de UI possui: o WCAG 1.4.11 isenta explicitamente heatmap). Hospedar isso no seed-componentes.md — que já tem 341 KB — contaminaria a regra-mãe do arquivo. O que o DF fixou em 7 decisões: o canônico é agnóstico de biblioteca, mas o consumidor canônico web é o Chart do shadcn/ui sobre Recharts v3 (a stack real do Lovable), com o detalhe técnico de que no v3 a referência é var(--chart-N) direto, sem o wrapper hsl() antigo · régua de 4 pisos, todos medidos por script: 1.4.1 (cor nunca é o único portador), 1.4.11 (3:1, com isenção declarada e condicionada para a escala sequencial), 1.4.3 (rótulo/eixo/legenda ≥4.5:1) e 1.1.1 (todo gráfico tem fallback textual) · grayscale vira gate ESTRUTURAL, não teste opcional — todo preview da fase carrega modo P&B acionável, o que serve de uma vez o "aperto de olhos" do método e o impresso da F7 (laudo e O&M saem em P&B), evitando uma fase inteira de gráficos que não degradam. O FATO DE MÉTODO DO MARCO SÃO DOIS, E OS DOIS SÃO SOBRE DETECTORES. (1) O gate humano achou de novo o que a automação não podia achar. O DT foi ao gate com três camadas automatizadas verdes; o Rafael olhou o preview e perguntou se a escala inicial "era pra ser toda em cinza mesmo". Os stops 50/100 da rampa turquesa têm chroma tão baixo que perdem o matiz em tela — e cinza, em dataviz, significa "sem dado": valor baixo e ausência de medição eram ambíguos. As três camadas mediam razões de contraste, não percepção de matiz; nenhuma delas poderia ter visto. Correção estrutural aprovada sobre preview comparativo: a rampa desloca um stop (100→900 light / 800→100 dark) e nasce o token chart-no-data — cinza exclusivo de "sem medição", sempre hachurado, de modo que a distinção "gerou pouco × não reportou" nunca dependa de cor (1.4.1, grayscale e impresso de graça). Alternativa descartada: manter 50→800 e resolver só pela regra do no-data — rejeitada porque a leitura-cinza permaneceria na tela. (2) Uma regra sem detector não é uma regra. A promoção obrigou a abrir os arquivos gêmeos de token e a medição mostrou que seed-tokens.json e seed-tokens.css declaravam v1.1 e não continham nenhum token do pacote mobile v1.2 — zero ocorrências de breakpoint, safe-area, fs-field-touch e clamp. A defasagem era de duas versões, e a própria pendência §7.0 do seed-tokens.md a descrevia como sendo de uma. Causa raiz: a regra "os três arquivos formam uma unidade" existia desde a v1.0 sem nenhum detector — ler o .md não revela nada sobre o conteúdo dos gêmeos, e o .md é justamente onde a versão dos três é declarada; a fonte da afirmação e o objeto da afirmação nunca se encontravam. Mesma classe do defeito de propagação do marco v1.4. Correção estrutural: nasce validacao/paridade-tokens.py (G1 não-regressão · G2 paridade json↔css · G3 cobertura nominal em light e dark), 43 PASS · 0 FAIL — e ela reprovou a primeira tentativa de regeneração, que reescrevia o CSS a partir do JSON e no caminho renomeou --seed-sp-* para --seed-space-*, perdeu o composto --seed-focus-ring (que só existe no CSS) e serializou sombras, famílias e beziers como estrutura DTCG. A entrega passou a ser por edição cirúrgica do arquivo anterior. Lição transferível: regeneração total a partir de um modelo incompleto perde token em silêncio; preservar bytes é mais seguro do que reconstruir e conferir. Terceiro fato, de propagação: o Rafael anexou o repositório inteiro em zip, o que permitiu a primeira leitura de volta COMPLETA contra a âncora do MANIFESTO — 27 de 27 artefatos batem byte a byte, e permitiu fechar a pendência P4 (os artefatos de e-mail do marco v1.5 nunca tinham sido ancorados). O MANIFESTO.md vai a v1.2 com 21 linhas novas. Aprendizado de ferramenta da fase: a camada de render da F5 usa puppeteer (viewport + fullPage), nunca o CLI --screenshot do Chrome — medido: o CLI truncou a renderização à direita e simulou um overflow inexistente (scrollWidth real 360, zero elementos estourando). Erratas encerradas neste marco: a do seed-tokens.md §5 (par info), aberta desde 2026-08-04 — pela regra GI2, a F5 editou o arquivo por outro motivo e a errata foi fechada junto, com correção mais completa que a prevista (o par semântico real é azul-800 = 8.57 AAA, não uma simples troca de rótulo). Validação do marco: contraste-dataviz.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.Promoção da §3c a estável
texto inteiro da versão
Promoção da §3c a
estável (gate visual do DT aprovado pelo Rafael sobre o preview v0.2 completo) e fechamento do débito do §7.0: os gêmeos seed-tokens.json e seed-tokens.css foram regenerados e passam a v1.4. Nenhum valor de token foi alterado nesta versão — é mudança de estado + restabelecimento da unidade md+json+css. Achado da execução: o débito era de DUAS versões, não uma — os gêmeos declaravam v1.1 e não continham nenhum token do pacote mobile v1.2 (breakpoints, tipografia fluida clamp(), --seed-fs-field-touch, safe-area); a redação anterior da pendência 7.0 é superada com racional completo. Guarda nova: validacao/paridade-tokens.py (G1 não-regressão · G2 paridade json↔css · G3 cobertura nominal), 43 PASS · 0 FAIL — ela reprovou a primeira tentativa de regeneração (renome de --seed-sp-*, perda de --seed-focus-ring, sombras serializadas como DTCG), o que levou a entrega a ser feita por edição cirúrgica. Cruzamento §3c × gêmeos: 26/26 hex batem. contraste-dataviz.py reproduzido na janela: 29 PASS · 3 FAIL (os 3 documentados do fill em traço fino).Escalas de dado da Fase 5 (sub-bloco DT), nova §3c
texto inteiro da versão
Escalas de dado da Fase 5 (sub-bloco DT), nova §3c — a entrega prometida desde a v1.0. Sequencial
chart-seq-1…7 (rampa turquesa; escala final 100→900 light / 800→100 dark, decidida no gate visual: o Rafael reprovou a proposta original 50→800 porque os dois primeiros stops liam como cinza — ambíguos com "sem dado" — e aprovou a opção A sobre preview comparativo; nasce junto o token chart-no-data, cinza exclusivo de "sem medição", SEMPRE hachurado; isenção 1.4.11 declarada com condições de acompanhamento e gatilho de revisão) · divergente chart-div-neg-3…pos-3 (vermelho↔cinza↔turquesa, alinhada por construção ao par positive/negative da v1.0; posições plenas passam 3:1 medido nos dois modos; regra da zona-zero declarada) · gauge gauge-track/value/range-* (faixas referenciam a taxonomia de feedback — nenhuma severidade paralela) · variante cat-N-stroke light+dark para traço fino, nascida de remedição que reprovou cat-1/2/5 a ≤3px (fill intocado; os pares dark vieram do achado V2 do render). Dois achados do script corrigiram a proposta antes da spec: warning light dourado-500→600 (2.35→3.25 vs trilha) e critical dark vermelho-400→300 (2.38→3.26). Nenhum hex novo — tudo stop existente do §2.1. Errata §5 fechada nesta edição (regra GI2 — aberta desde o roadmap v1.3, 2026-08-04): a linha do par info dizia "azul-700 · 5.79 · AA"; medição de 2026-08-09 provou que 5.79 é de fato o azul-700, mas o par semântico usado pelo sistema (feedback-info-text, consumido inclusive pelo e-mail §4.2) é o azul-800, que mede 8.57 · AAA — a linha passa a documentar o par real, e a errata original (que previa só troca de rótulo) é superada pela correção completa rótulo+número+veredicto. Consumidor primário desta seção: seed-dataviz.md (9º canônico, DF7: uma fonte, referência sem duplicação).Sub-bloco DG (gráficos core) estável — 13 decisões, §4 nova.
texto inteiro da versão
Sub-bloco DG (gráficos core)
estável — 13 decisões, §4 nova. Sete tipos (barra, empilhada, agrupada, linha, área, pizza, dispersão) mais os três estados herdados do Bloco 3. Consolidado aprovado após 3 rodadas encadeadas de pesquisa, com duas emendas durante a produção: a barra empilhada foi puxada para dentro do escopo a pedido do Rafael (caso real: consumo por posto tarifário), trazendo junto a agrupada como saída obrigatória; e o DG13 (textura) nasceu do gate. Três regras nasceram da medição, não do consolidado: DG11 (contorno cinza-900 — o fill categórico reprova sozinho contra o fundo claro), DG12 (tinta sobre dado não segue o tema — o fill é claro nos dois modos) e DG13 (textura na interseção escuro+grayscale). O gate levou o preview da v0.1 à v0.5, e os dois achados decisivos foram do olho do Rafael: o colapso das séries em cinza no modo escuro, e o escopo exato do gatilho da textura. Correção de instrumento registrada: o portão de grayscale media razão de contraste WCAG e reprovava o modo claro, onde o gate humano lia bem — foi trocado por espalhamento de claridade, com piso declarado como calibrado pelo gate e não derivado de norma. Validação: jsdom 147/0 · contraste 32 PASS · 0 FAIL · 14 MITIGADO · 4 ISENTO · render puppeteer 6 cenários (matriz tema × grayscale × largura, agora cruzada e não amostrada — a versão anterior não gerava escuro+grayscale, que era exatamente onde o defeito morava).PROMOÇÃO: DF e DT passam de rascunho a estável
texto inteiro da versão
PROMOÇÃO: DF e DT passam de
rascunho a estável, após "aprovo" explícito do Rafael no gate visual do preview seed-dataviz-tokens-preview.html v0.2 completo (2ª rodada do gate; a 1ª aprovara só a escala A sobre o preview comparativo). Nenhuma decisão de conteúdo mudou nesta versão — a v0.3 é mudança de ESTADO mais os registros que a promoção obriga. Junto: validação reproduzida na janela (29 PASS · 3 FAIL, os 3 documentados do fill em traço fino) e cruzamento §3c×gêmeos (26/26 hex batem). Débito dos gêmeos ENCERRADO — seed-tokens.json/.css regenerados para v1.4, e a execução revelou que a defasagem era de duas versões (faltava todo o pacote mobile v1.2), não uma; nasceu daí a guarda paridade-tokens.py. MANIFESTO.md v1.2 ancora os artefatos da F5.Achado do gate visual do Rafael na escala sequencial:
texto inteiro da versão
Achado do gate visual do Rafael na escala sequencial: os stops 50/100 da proposta original liam como cinza — ambíguos com "sem dado". Correção aprovada (opção A sobre preview comparativo): escala desloca para 100→900 (light) / 800→100 (dark), e nasce o token
chart-no-data (cinza exclusivo de "sem medição", sempre hachurado). Alternativa B descartada (manter 50→800 e resolver só por regra — a leitura-cinza permaneceria). Valores e supersede na §3c do seed-tokens.md v1.3. Bug de regressão corrigido no contraste-dataviz.py (seção do gauge media os stops rejeitados, não os canônicos).Correção de estado congelado — nenhuma decisão, supersede ou artefato muda
texto inteiro da versão
Correção de estado congelado — nenhuma decisão, supersede ou artefato muda (mesma classe da errata de cabeçalho corrigida no
seed-ds-roadmap.md v1.8). Três pontos estavam parados no escopo da v0.2 enquanto o corpo já continha os 6 sub-blocos estável: (a) o cabeçalho declarava "EM+EL estáveis, base v0.3, GV1–GV4" e "EC/ET/EN/EA ainda não escritos" — reescrito para refletir a Fase 4 completa, com a lista de artefatos vigentes e GV1–GV8; (b) a tabela de fases do §0 marcava a F4 como "🔄 em produção" — corrigida para ✅ concluída; (c) a pendência "EC/ET/EN/EA não escritos" do §8 — marcada RESOLVIDA com referência às §§8-B–8-E, linha riscada mantida para rastreabilidade. As demais pendências do §8 permanecem intactas: ou seguem realmente abertas (rodapé com dado real, trilha EN5, clientes fora da matriz mínima), ou não têm comprovação de resolução dentro deste arquivo (Cache Rule) — não se corrige por memória. Divergência detectada na verificação de retomada pós-marco v1.5 (2026-08-09); correção imediata por decisão do Rafael de não deixar a pendência para trás.Primeira entrega da Fase 5. Nasce o 9º canônico com o fundamento DF1–DF7 (consolidado aprovado pelo Rafael em 2026-08-09 após 3 rodadas: R1 canon interno · R2 mercado/stack shadcn Chart+Recharts v3 · R3 normas WCAG…
texto inteiro da versão
Primeira entrega da Fase 5. Nasce o 9º canônico com o fundamento DF1–DF7 (consolidado aprovado pelo Rafael em 2026-08-09 após 3 rodadas: R1 canon interno · R2 mercado/stack shadcn Chart+Recharts v3 · R3 normas WCAG 1.4.1/1.4.11/1.4.3) e o registro do sub-bloco DT, cujos valores vivem no
seed-tokens.md v1.3 §3c (DF7: uma fonte). Medição prévia corrigiu 2 propostas de gauge e originou a variante cat-N-stroke. Estado: rascunho, aguardando gate visual do preview de tokens.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.
texto inteiro da versão
MARCO v1.5 — A FASE 4 (SISTEMA DE E-MAIL) FECHA COMPLETA, 6/6 SUB-BLOCOS
estável, EM ~36 HORAS DE ABERTURA A FECHAMENTO. Nasce o 8º arquivo canônico, seed-email.md v0.10, porque e-mail é OUTRO RUNTIME: consome hex literal (var() é morto em Gmail/Outlook), layout por tabela, PNG com cor assada — hospedar isso no seed-componentes.md contaminaria a regra-mãe "componente consome semântico". Infraestrutura REAL montada e verificada na própria fase: Cloudflare R2 servindo assets.seed.eng.br/email/v1/ (caminho imutável) e Resend verificado em envio.seed.eng.br (São Paulo) com DKIM/SPF/MX + DMARC. Entregues: template-base v0.4 · preview de componentes v0.3 · 3 transacionais do ERP (proposta · fatura · alerta esperado×medido×desvio) com inventário de placeholders mustache como contrato formal com o ERP · newsletter modular v3.2 (4 módulos removíveis) · comercial texto-quase-puro · assinatura corporativa v0.2 instalada e provada no Gmail real do diretor. O FATO DE MÉTODO DO MARCO: 11 defeitos reais encontrados pelo gate visual do Rafael, 11 corrigidos, 8 famílias de teste-guarda permanentes (GV1–GV8) — e NENHUM dos 11 era visível às verificações automatizadas. A previsão da abertura (em e-mail o gate humano é a camada determinante) confirmou-se com números: a suíte estática é o piso, o olho é o juiz. Destaques do ciclo: o defeito 9 (faixas cinza no Outlook) levou TRÊS hipóteses até o veredito — qualquer row-spacer com fantasmagoriza em zoom ≠100% no motor Word; espaçamento vertical canônico passa a ser padding/margin — com direito a uma reclassificação prematura de Claude derrubada pelo print seguinte do Rafael (registrada, não apagada); o defeito 10 foi erro de ferramenta do próprio produtor (uma linha "no-op" destruiu 9 </p> e a suíte passou verde — nasceu o GV7 de balanceamento); o defeito 11 fundou a classe "artefato composto desatualizado" (o comercial embutia a assinatura antiga após o supersede do logo — nasceu o GV8 com a lista viva de assets aposentados). Decisão de fechamento do Rafael ("aprovo b"): row-spacers do acervo promovido ficam como tolerância monitorada (retrofit só quando um template for editado por outro motivo). Protocolos permanentes novos: print de e-mail encaminhado não é evidência de gate (encaminhar descarta head e VML) · API key de teste é descartável (Read-Host + revogação) · matriz de gate mínima = Gmail web + Gmail Android dark forçado + Outlook 2024 clássico. Placar: 312 PASS / 0 FAIL em 14 arquivos · contraste 14 pares/0 reprovações · 9+ evidências de recebimento direto. Backlog que a fase deixa: rodapé com endereço real antes do 1º envio a cliente · trilha de campanha (EN5, aguarda lista) · DKIM Workspace/DMARC raiz (TI da SEED) · EM14 provisória. Delta no CHECKPOINT_v1_5_fase4_email.md; vigente no ESTADO_ATUAL_SeedDS.md v1.5. Próximo: escolha de fase do Rafael (F5 dataviz — recomendada; o alerta de geração já reservou o slot de gráfico · F6 patterns · F8).Correção retroativa em todo o acervo
texto inteiro da versão
Gate EN: defeitos 8 (chaves órfãs — erro de geração com asserção fraca, GV6a) e 9 (spacer sem fundo no Outlook, GV6b). Correção retroativa em todo o acervo (base v0.4, componentes v0.3, ET v0.2). 284 PASS / 0 FAIL em 14 arquivos.
Sub-blocos EA (assinatura: canônico + amostra + guia + PNG novo logo-seed-assinatura@2x.png MD5 15f8f4821677cfddb81a868681ea9a1d) e EN (newsletter modular de 4 módulos + comercial texto-puro, com amostras) em rascunho.…
texto inteiro da versão
Sub-blocos EA (assinatura: canônico + amostra + guia + PNG novo
logo-seed-assinatura@2x.png MD5 15f8f4821677cfddb81a868681ea9a1d) e EN (newsletter modular de 4 módulos + comercial texto-puro, com amostras) em rascunho. 3 refinamentos de suíte documentados (URL-placeholder, modo fragmento, GV3 na assinatura). 110 PASS / 0 FAIL nos 6 arquivos novos; regressão 60/0.Promoção do ET a estável
texto inteiro da versão
Promoção do ET a
estável pelo gate do Rafael: 9 evidências em 3 motores, zero defeito novo. Fase com EM/EL/EC/ET fechados; restam EN e EA.Sub-bloco ET em rascunho: 3 transacionais (proposta · fatura · alerta) compostos sobre o base v0.3, inventário de placeholders mustache como contrato com o ERP, supersede ET7 do From (notificacoes@) registrado na EM14.…
texto inteiro da versão
Sub-bloco ET em
rascunho: 3 transacionais (proposta · fatura · alerta) compostos sobre o base v0.3, inventário de placeholders mustache como contrato com o ERP, supersede ET7 do From (notificacoes@) registrado na EM14. 120 PASS / 0 FAIL nos 6 arquivos.Promoção do EC a estável
texto inteiro da versão
Promoção do EC a
estável pelo gate do Rafael: EC1–EC8, preview v0.2, GV5. Confirmação da correção dos achados 6 e 7 nos três clientes da matriz. Nota cosmética número/unidade registrada sem bloqueio.Gate visual do EC: achados 6 (nowrap em valores) e 7 (barra de severidade → border-left, supersede da anatomia EC2, guarda GV5). Preview v0.2, suíte com 20 verificações.
texto inteiro da versão
Gate visual do EC: achados 6 (nowrap em valores) e 7 (barra de severidade → border-left, supersede da anatomia EC2, guarda GV5). Preview v0.2, suíte com 20 verificações.
Sub-bloco EC em rascunho: consolidado EC1–EC8 aprovado, seção 8-B com as 8 decisões, preview canônico seed-email-componentes.html v0.1 herdando o template-base v0.3 (19 PASS / 0 FAIL), errata de suíte do atributo…
texto inteiro da versão
Sub-bloco EC em
rascunho: consolidado EC1–EC8 aprovado, seção 8-B com as 8 decisões, preview canônico seed-email-componentes.html v0.1 herdando o template-base v0.3 (19 PASS / 0 FAIL), errata de suíte do atributo booleano registrada. Aguardando gate visual da matriz real.Promoção a estável
texto inteiro da versão
Promoção a
estável dos sub-blocos EM+EL e do template-base v0.3, pelo gate do Rafael. Nova §7.2 com o ciclo completo de gate (5 defeitos reais em 3 clientes, todos corrigidos e virados guarda GV1–GV4), §7.3 com o registro da promoção, decisões novas EL9 (corpo 16px) e EL10 (espaçador em vez de margin), regra unificada NADA IMPLÍCITO, protocolo de gate sem encaminhamento, e atualização das pendências (placeholders do rodapé, política de chave descartável, clientes pendentes).PROMOÇÃO FINAL — EA e EN a estável; os 6 sub-blocos da F4 fechados.
texto inteiro da versão
PROMOÇÃO FINAL — EA e EN a
estável; os 6 sub-blocos da F4 fechados. Veredito final do defeito 9 (row-spacer × zoom; padding como técnica canônica), defeitos 10 (GV7) e 11 (GV8), decisão "aprovo b" da tolerância monitorada para o acervo. Newsletter consolidada em v3.2 (zero row-spacers, tags balanceadas), comercial v2 com assinatura vertical embutida, assinatura EA v0.2 instalada e provada em produção real. Balanço da fase: 11 defeitos do gate, 11 corrigidos, GV1–GV8.2026-08-07
MARCO v1.4 — A FASE 3 FECHA: 7 DE 7 BLOCOS.
texto inteiro da versão
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).Primeira entrega da Fase 4. Sub-blocos EM (fundamento técnico, EM0–EM15) e EL (layout, EL1–EL8). Paleta resolvida com 14 pares medidos e 0 reprovações. Infraestrutura montada e verificada: Cloudflare R2 +…
texto inteiro da versão
Primeira entrega da Fase 4. Sub-blocos EM (fundamento técnico, EM0–EM15) e EL (layout, EL1–EL8). Paleta resolvida com 14 pares medidos e 0 reprovações. Infraestrutura montada e verificada: Cloudflare R2 +
assets.seed.eng.br ativo; Resend + envio.seed.eng.br verificado com DKIM/SPF/MX/DMARC. Cinco supersedes formais registrados, incluindo duas correções de erro do próprio autor (racional do EM13-b e classificação de contraste decorativo). Estado: rascunho, aguardando gate visual.2026-08-06
Marco v1.3 fechado — Bloco 6 (Dados) completo 5/5
texto inteiro da versão
Marco v1.3 fechado — Bloco 6 (Dados) completo 5/5 (
seed-componentes.md v0.45; 43 componentes + patterns CN/⌘K). Produzido em 2 lotes do modo autônomo (6A+6B · 6C+6D+6E). Fato novo do marco: os dois gates humanos passaram SEM errata — primeira vez na F3 — a camada render pegou os 2 bugs reais do bloco (sticky×border-collapse, guarda DT-13; piso da densidade compacta) ANTES do gate, e os detectores do v1.2 (token fantasma NV, whitelists) pegaram as reincidências sozinhos. Pendências históricas encerradas: indeterminate (B2→SL2) · busca composta EUI (B2→TD1) · densidade ERP→mobile (B2→DT2/LD2). Coerência org: skill seed-ds-ui lida no GI — cadeia de tokens formalizada (GI1) + pendência de alinhamento da skill registrada (GI2). Validação: 420 jsdom + 38 render. Delta no CHECKPOINT_v1_3_bloco6.md; vigente no ESTADO_ATUAL_SeedDS.md v1.3. Próximo: Bloco 7 (Iconografia) fecha a Fase 3.Marco v1.2 fechado — DUPLO: CN §33 + Bloco 5 (Navegação) completo 6/6
texto inteiro da versão
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).2026-08-05
Marco v1.1 fechado — Bloco 4 (Superfícies) completo 7/7
texto inteiro da versão
Marco v1.1 fechado — Bloco 4 (Superfícies) completo 7/7 (
seed-componentes.md v0.32; preview v0.32; suite F 80 testes; 246 verdes acumulados). Régua de 3 degraus fechada (§23.1→§30); escala de sobreposição formalizada; drawer §31 destrava a spec da CN (F6) — backlog promovido a alta. 2 ciclos de crítica no gate visual (empilhamento H; +N/light-dismiss I) com emendas formais e testes-guarda. Delta completo no CHECKPOINT_v1_1_bloco4_superficies.md (Drive/marcos); vigente no ESTADO_ATUAL_SeedDS.md v1.1. Próximo (v1.2 duplo, escolha do Rafael): spec da CN primeiro, Bloco 5 na sequência.2026-08-04
Bloco 3 (Feedback e status) fechado: 11/11 estáveis
texto inteiro da versão
Bloco 3 (Feedback e status) fechado: 11/11 estáveis em
seed-componentes.md v0.24 (trajetória v0.15→v0.24 num único dia; 5 sub-blocos com 3 rodadas encadeadas cada + verificações primárias GOV.UK/Material; 166 testes de suite + ~40 pares medidos; 4 ciclos de crítica visual → emendas R3-b/R3-c/X6-b/botão-morto; nota 1.13-b). Adotado o padrão delta de fechamento: marco v1.0 (CHECKPOINT_v1_0 + ESTADO_ATUAL_SeedDS criados). Central de notificações decidida (CN1–CN4) e registrada no F6 com dependência do drawer (B4). Suites de validação viram artefato em /validacao. Pendência nova: errata de rótulo no seed-tokens.md §5 (azul-700→azul-800 no par 5.79) a corrigir quando o arquivo for editado. Pontas encaminhadas: stepper→B5 (nota na linha), skeleton/empty de dataviz→F5, telemetria do delay de 1s→F4. (Correção de sincronização em 2026-08-04: cabeçalho e tabela de canônicos desta versão haviam ficado com os valores da v1.2 — data/versão, linha do seed-componentes.md e linha deste arquivo atualizados; nenhuma mudança de conteúdo.)2026-08-03
Bloco 2 (Formulários) fechado: 13/13 estáveis
texto inteiro da versão
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.2026-08-02
Camada mobile/app (pacote M1–M3 aprovado pelo Rafael).
texto inteiro da versão
Camada mobile/app (pacote M1–M3 aprovado pelo Rafael). Breakpoints oficiais = escala Tailwind (sm 640…2xl 1536), canônicos no JSON + theme do Tailwind, com supersede do corte 960 do HTML v1; escala tipográfica fluida com
clamp() rem+vw nos 4 topos (regra WCAG 1.4.4 embutida); --seed-fs-field-touch 16px via pointer: coarse (anti-zoom iOS); tokens de safe-area para PWA/app. Nenhum valor de cor alterado. Contexto: diretriz de paridade mobile/app declarada pelo Rafael em 2026-08-02 — apps serão produzidos e o uso mobile supera o desktop.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…
texto inteiro da versão
Bloco 1 (Botão) aprovado em v0.5 após 5 iterações dirigidas por crítica: escada de mecanismos medida (containers 1.07→≥3:1), estado selected com sinais visuais M3, correção do dark (pares de componente), método dos 6 testes formalizado.
Criação, após auditoria de inventário (checklists da indústria + colateral corporativo) que expandiu o escopo de 55 para 95 itens: F3 de 4→7 blocos, adições em F4–F8, exclusões deliberadas formalizadas.
texto inteiro da versão
Criação, após auditoria de inventário (checklists da indústria + colateral corporativo) que expandiu o escopo de ~55 para ~95 itens: F3 de 4→7 blocos, adições em F4–F8, exclusões deliberadas formalizadas.
2026-07-30
Rebranding de aplicação (Fase 2 do DS v2).
texto inteiro da versão
Rebranding de aplicação (Fase 2 do DS v2). Hex e vetores intactos. Novidades: fundamento com 3 princípios (§2), Pantone/CMYK resgatados + errata azul-claro (§3.1), integração com tokens v1.1 (§3.2, §11), lei 70/20/10 (§3.3), hierarquia dos amarelos (§3.4), papel do azul (§3.5), contraste medido (§3.6), tipografia 2 famílias com JetBrains Mono e aposentadoria de Indie Flower/Neo Tech (§4), logo responsivo + matriz de posição (§5.2–5.3), EEny desacoplado com parcimônia (§6), Grafismo v2 de linhas (§7), fotografia real (§8), ilustração linha-primeiro (§9), linguagem editorial (§10), camada física (§12), aplicações atualizadas (§13), supersedes consolidados (§16). Morte do
erp-seed-design.md. Base: auditoria do Manual 2018 + pesquisa de referência (Carbon, Polaris, Atlassian, WGSN) + decisões aprovadas pelo Rafael na conversa do rebranding. Revisão por pesquisa aplicada pré-publicação (2026-07-30): kit de favicon padrão 2026 (§5.2), esclarecimentos de aplicação da lei 70/20/10 (§3.3), papel social do EEny recalibrado — de restritivo demais para ativo estratégico com regras (§6), legibilidade quantitativa de frota (§12), clear space como razão (§5.5), pendências 5 (§17). Decisões de 2026-07-31: camada expressiva Montserrat 800/900 para display de marketing e Caveat como fonte celebratória oficial (§4.3), escolhida em comparativo real vs. Shantell Sans e Kalam — fora dos tokens por decisão (garante a fronteira de UI).Hierarquia de uso da paleta (§3b): proporção 70/20/10 (supersede os 45% de 2018), amarelo=acento oficial vs dourado=trabalho, papel formal do azul (livre na UI/info, contido na marca, nunca ação primária). Novo grupo…
texto inteiro da versão
Hierarquia de uso da paleta (§3b): proporção 70/20/10 (supersede os 45% de 2018), amarelo=acento oficial vs dourado=trabalho, papel formal do azul (livre na UI/info, contido na marca, nunca ação primária). Novo grupo semântico
accent (highlight/highlight-subtle/on-highlight). Nenhum valor de cor alterado.Entrega inicial da Fase 1 do rebranding do DS. Rampas tonais das 6 famílias (8 cores de marca + vermelho funcional), semânticos light/dark, elevação, motion, tipografia (Montserrat+JetBrains Mono; Indie Flower e Neo…
texto inteiro da versão
Entrega inicial da Fase 1 do rebranding do DS. Rampas tonais das 6 famílias (8 cores de marca + vermelho funcional), semânticos light/dark, elevação, motion, tipografia (Montserrat+JetBrains Mono; Indie Flower e Neo Tech aposentadas), spacing/radius, dataviz. Supersedes declarados: #0d8f82 → surface-brand-deep; #2a3942 → cinza-900; hex dark ad-hoc → superfícies dark oficiais; #c63838 → vermelho-600; regra de contraste do turquesa reformulada com medição.
2026-07-17
Espelho público dos assets no Drive (22 FILEIDs) com padrão de embed e fallback.
texto inteiro da versão
Espelho público dos assets no Drive (22 FILE_IDs) com padrão de embed e fallback.
Reescopagem: arquivo exclusivamente visual; institucional movido ao sobreaseed.md; correção de endereço; fronteiras formais; regra das 8 cores; registro do #0d8f82.
texto inteiro da versão
Reescopagem: arquivo exclusivamente visual; institucional movido ao
sobreaseed.md; correção de endereço; fronteiras formais; regra das 8 cores; registro do #0d8f82.e de Qualidade
texto inteiro da versão
Ariana registrada como Líder Comercial e de Qualidade (informação declarada pelo Rafael em 17/07; corrige omissão — a liderança de Qualidade não constava). Ajustado o texto institucional longo.
Consolidação da revisão de arquivos de empresa/marca. Confirmado endereço de Governador Valadares como Rua Duarte Coelho, 205 (supersede "Rua Albânia, 81" do marca-seed.md v3.2). Absorvidos do marca-seed.md v3.2 os…
texto inteiro da versão
Consolidação da revisão de arquivos de empresa/marca. Confirmado endereço de Governador Valadares como Rua Duarte Coelho, 205 (supersede "Rua Albânia, 81" do
marca-seed.md v3.2). Absorvidos do marca-seed.md v3.2 os blocos institucionais "Pilares de marca" e "Governança em 4 frentes". Adicionado exemplo de tom de voz de mensagens de sistema. Declarada formalmente a fronteira com marca-seed.md (visual), seed-design-system.html (componentes) e erp-seed-design.md (produto SIGA, então chamado ERP).2026-05-17
Versão original consolidando identidade, cultura, portfólio, momento atual e equipe a partir da documentação interna SEED (marca, design system, site institucional).
texto inteiro da versão
Versão original consolidando identidade, cultura, portfólio, momento atual e equipe a partir da documentação interna SEED (marca, design system, site institucional).
2026-05-09
Assets reais de 02assets/ formalizados; variantes 9→14.
texto inteiro da versão
Assets reais de
02_assets/ formalizados; variantes 9→14.Expansão digital: tokens, escala, spacing, grid, foto/ilustração, componentes.
texto inteiro da versão
Expansão digital: tokens, escala, spacing, grid, foto/ilustração, componentes.
sem data
Migração para Cowork, conversão para markdown estruturado.
texto inteiro da versão
Migração para Cowork, conversão para markdown estruturado.