17. Pendências explícitas

CMYK "U" (superfície fosca) — a confirmar se surgir demanda de impressão fosca crítica.

Curadoria do banco fotográfico real — processo operacional a organizar (pasta no Drive, critérios da §8); sem ele, a diretriz de fotografia fica sem matéria-prima. Desde 2026-09-04 existe a ESPECIFICAÇÃO DE COMPRA das fotos: quatro listas geradas (07-pecas/frota/fotos-necessarias-frota.md · one-pagers/fotos-necessarias-onepagers.md · rollup-totem/fotos-necessarias-rollup.md · portfolio/fotos-necessarias.md) com enquadramento, orientação e resolução mínima calculada da MESMA constante que desenha cada área — uma sessão de fotos alimenta frota e portfólio. A pendência deixa de ser "sem matéria-prima" e vira "sessão de fotos a executar".

✅ Vetores do Grafismo v2 — RESOLVIDA em 2026-08-22 (v5.12). O SERRA-CENA fechou na v5.4 (geradores, §7.7); os três usos internos — textura de fundo, marcador de seção e divisor editorial — fecharam na v5.12 com o gerador 06-validacao/geradores/gen-detalhe.py (extração por AST do aprovado, nunca cópia) e os 5 assets de referência em 03-assets/grafismos/. Especificação consolidada na tabela da §7.6.

✅ Redesenho executivo das peças físicas — FECHADA em 2026-09-04 (v5.32). Papelaria (Onda 1, §12.1–§12.8), frota (§12.22) e uniforme/EPI (§12.23) entregues com gerador, gate e spec; a F8 fecha nas três ondas.

✅ SANGRIA E MARGEM DE SEGURANÇA — RESOLVIDA em 2026-08-22 (MR-P10). Nasceu e fechou no mesmo dia: pesquisada em três fontes, medida na peça e decidida por veredito dele — 3 mm de sangria e 3 mm de margem, com a composição definida para a área de corte e a sangria como crescimento para fora. A regra é a §7.4-e e a conferência é automática (cláusulas MM1-d e MM1-e). ✅ O caso da DOBRA (MR-P12) DEIXA DE SER BLOQUEIO em 2026-08-25, por decisão dele — e o que a substitui é uma FRONTEIRA, não uma medida.

A pergunta dele, verbatim: "aqui você está entrando muito no detalhe de produção do crachá, isso é mesmo necessário no design system? o DS não seria um template que depois onde fosse ser produzido seria visto as regras do local para poder seguir o template? eu estendo esse questionamento para tudo que estamos fazendo."

⚠ A pergunta estava certa, e o custo da MR-P12 era real: ela vinha bloqueando "arquivo de produção" em peça atrás de peça — pasta com aba, crachá, diário em bloco, lombada, etiqueta de bloqueio — e o bloqueio não produzia nada: ninguém estava esperando aquele arquivo, e a medida que faltava (margem de vinco em milímetro) é do fornecedor, varia de gráfica para gráfica e só se conhece na cotação.

⭐⭐ A FRONTEIRA NÃO É "produção × design" — É "MUDA O DESENHO × NÃO MUDA". Dizer que detalhe de produção sai do DS estaria errado, e o próprio acervo prova: a sangria de 3 mm existe porque o corte erra e o piso de 0,25 mm existe porque traço fino some na impressão. As duas são restrições de produção, e as duas mudam o desenho — tirá-las quebraria as peças.

O caso do crachá mostra a linha exata: a zona de 9 mm livre no topo FICA (é desenho — nada de conteúdo ali, e isso vale em qualquer gráfica); a posição e o tamanho do furo SAEM (é produção, e o fornecedor tem a faca).

⭐ Consequência imediata: nenhuma peça fica mais esperando "arquivo de produção". Crachá, diário, lombada, pasta com aba e etiqueta de bloqueio saem completos, com a lista de restrições ao lado. Três pendências de peça viram linha de spec. ⚠ E os dois tipos de arquivo da §7.4-e continuam existindo — GATE e PRODUÇÃO —; o que muda é que o arquivo de produção passa a ser feito sob demanda, com a medida do fornecedor na mão, e não a ser esperado.

✅ AMARELO DE MARCA × AMARELO NORMATIVO — RESOLVIDA em 2026-08-22 (MR-P11, v5.13), saída (a) aprovada pelo Rafael ("essa está aprovada, pode propagar"). A REGRA: o amarelo de marca #FAD61D NÃO ENTRA em peça instalada em ambiente com sinalização de segurança (subestação, sala de painéis, canteiro — onde a NR-10 10.10.1 obriga as cores da NR-26 → ABNT NBR 7195, em que amarelo significa CUIDADO/ADVERTÊNCIA); nessas peças a assinatura da SEED é turquesa e branco. Em papelaria, escritório e digital, o amarelo segue como acento único, sem restrição. Uma regra, uma fronteira. Motivo: sinalização que confunde é sinalização que não protege, e a responsabilidade técnica da peça é da SEED. Desbloqueia sinalização (2.9) e uniforme/EPI (3.2) do plano-producao-pecas.md. Conformidade conferida na propagação: o marcador amarelo da v5.12 é elemento de papelaria/digital — fora do escopo, sem conflito. Levantamento e fontes em inventario-pecas-ds.md §3.2.

⭐⭐ A FRONTEIRA DE 2026-08-25 — quando a peça NÃO compartilha o campo visual, mas É o campo visual. Veredito dele, sobre a SN-P6:

"normal de segurança deve seguir as cores da norma de segurança, nao podemos impor nosso DS sobre isso."

A REGRA: em peça de SEGURANÇA, quando a exigência normativa colide com a identidade visual, a NORMA GANHA — e isso é linha de spec, não escolha caso a caso.

⚠ E A REGRA TEM FRONTEIRA, delimitada por ele em 2026-08-25 (ao confirmar a regra): "estou falando apenas sobre norma de segurança, as demais normas temos que ver caso a caso, mas acredito nao ter outro tipo de normal que va se sobressair sobre ao nosso normativo interno do DS." Só norma de SEGURANÇA supera o normativo interno automaticamente. Qualquer outra colisão — ABNT de desenho técnico, norma de concessionária, regra dos Correios — vai a ele caso a caso, com o custo de cada saída medido. ⭐ Regra sem fronteira é regra que cresce sozinha: sem esta delimitação, a próxima sessão aplicaria "a norma ganha" a qualquer norma e apagaria identidade onde ele não mandou apagar.

⚠ A distinção é mais fina que "a norma ganha", e é ela que importa: esta §17.6 foi escrita para peça que COMPARTILHA campo visual com sinalização — etiqueta de equipamento, crachá, uniforme —, e nessas o turquesa e branco continua valendo. A família de sinalização NR-10 É o campo visual, e nela governa a NR-26, item 26.1.4: "o uso de cores deve ser o mais reduzido possível, a fim de não ocasionar distração, confusão e fadiga ao trabalhador." Uma terceira cor ao lado do vermelho de proibição é exatamente o que esse item proíbe. Consequência: na família de sinalização a assinatura é monocromática (logo-horizontal-mono-positivo, pela linha "Impressão P&B" da matriz §5.1), separada do conteúdo por um fio e não por um campo de cor.

⚠ O QUE NÃO SAI, e está declarado para ninguém "consertar" depois: o que a decisão tira é cor de marca usada como acento ou sinal. A tinta de texto da casa (§3.5-d — text-primary, text-secondary, text-muted) fica: ela não sinaliza nada, não compete com cor de segurança, não aparece como campo de cor, e não existe tinta canônica alternativa. ⭐ Reduzir cor não é apagar tinta.

O custo foi medido, e é honesto dizê-lo: o contraste da assinatura melhorou (branco sobre brand-deep 9,37:1 → preto sobre branco 21,00:1). O que piorou é reconhecimento a distância, e só na placa A3: com o logo a 60 mm a caixa alta mede 8,75 mm, legível a 1,75 m numa peça projetada para 4,0 m. Antes, a tarja turquesa era um campo de cor contínuo — dizia "é da SEED" sem ler nada. É perda de marca, não de segurança, e numa peça de segurança é o lado certo de perder: uma placa de risco elétrico não existe para anunciar quem a fabricou. Pendência SN-P10, com saída medida que não acrescenta cor (logo maior, ao custo de área). ⭐ PRECISÃO DE ESCOPO — 2026-08-24, por ele. A redação acima diz "peça instalada em ambiente com sinalização de segurança" e dá "canteiro" como exemplo. É largo demais, e a largura pegou uma peça que não devia: eu apliquei a regra à PLACA DE OBRA (§12.1) e ela não se aplica. O critério, nas palavras dele: "objetivamente é onde existem placas de sinalização que tbm usa o amarelo (…) no caso de uma placa de obra nao é o caso, pois o local que ela fica instalada nao compartilha espaço com alguma sinalização de segurança. o exemplo que queremos abordar seria por exemplo, um quadro eletrico, uma porta de subestação, entre outros locais especificos que podem ter uma sinalização amarela de segurança."

A REGRA PASSA A SER, com o critério explícito: o amarelo #FAD61D não entra em peça que COMPARTILHA CAMPO VISUAL com sinalização de segurança amarela — quadro elétrico, porta de subestação, painel, e os pontos específicos onde a NR-26/NBR 7195 manda amarelo. Não é o terreno que decide, é a vizinhança visual da peça. Placa de obra na entrada da obra, totem, banner e papelaria seguem com o amarelo liberado.

⭐ A lição de método, e ela é de escrita de norma: a versão anterior nomeava LUGARES ("subestação, sala de painéis, canteiro") em vez de nomear a CONDIÇÃO. Lugar é fácil de escrever e fácil de aplicar errado; condição é mais difícil de escrever e não estica. Regra que enumera exemplos vira regra que se aplica por semelhança — e semelhança não é critério.

✅ Kit de favicon/app icons e avatares — FECHADA PARCIALMENTE em 2026-08-28/2026-09-04 (§12.26): kit SVG (favicon + masters de apple-touch, maskable e avatar, nos dois fundos) com as 5 decisões dele. O que NÃO fechou ganhou entrada própria no item 9: capas de rede (FV-P1) e rasterização + espelho §5.4 (FV-P2).

Pendências abertas pela Onda 1 da F8 (2026-08-24), todas nomeadas:

• ✅ RD-P1 — MEDIDA e fechada em 2026-08-27, com veredito NÃO ESTENDER. O experimento que a própria pendência pedia: a auditoria-borda-campo (80 medições × 2 temas) rodada 2× sem e 2× com as flags deterministas — via o interruptor CHROMIUM_DETERMINISTA=1 que o ambiente.mjs ganhou para isto (uma condição, um interruptor, zero edição nos instrumentos). Resultado: os QUATRO placares idênticos (80 PASS · 0 FAIL · 88 [n/a]). ⭐ Veredito: o placar de tela é INVARIANTE às flags — estender não compra nada (instrumento de tela consome placar, não PNG bit-a-bit) e custaria os ~15% de lentidão medidos na calibração original. O escopo declarado fica como está: rasterização determinística é para instrumento de PEÇA. O interruptor fica no ambiente para quem quiser re-medir.

• ✅ RD-P2 — fechada em 2026-08-27 como NÃO-REPRODUZÍVEL, com prova. O ruído registrado (2 px em 8,7 M, Δ1 nível) aparecia ENTRE execuções — e a prova §14.10 do render (duas cargas no MESMO processo) não o vê. O experimento reproduziu a condição real: 6 capturas em 6 processos node SEPARADOS, por peça, nas duas suspeitas de fundo escuro (pasta-a4-brand-deep, F3-cartao-fundo). Resultado: 12 de 12 PNG byte-idênticos por MD5. O fenômeno não existe no acervo atual — entre o registro e hoje mudaram as flags deterministas (55º defeito) e as próprias peças (fontes embutidas). ⚠ A suspeita original (névoa E1) não foi confirmada nem refutada: o fenômeno sumiu antes do isolamento, e encerrar assim é mais honesto que atribuir causa sem reprodução. Se voltar: o método é capturar N vezes em processos separados e comparar MD5.

• ✅ PC-P1 — RESOLVIDA em 2026-08-25, com as duas saídas usadas. As sete peças anteriores à convenção tiveram destinos diferentes, e a diferença é a que importa: as três do cartão de produção foram REMOVIDAS (eram arquivo de produção, e o vigente passou a ser a §12.9 — com o ponteiro da §7.4-d repontado ANTES de o arquivo sair); as quatro evidências de gate (peça larga e grafismo em razão A4) foram preservadas, porque reescrevê-las as faria deixar de provar o que provaram. Para elas nasceu o veredito [hist] na guarda-peca-fresca.mjs, com motivo escrito por arquivo e contagem separada do placar. ⭐ Não é cosmético: FAIL recorrente que "todo mundo sabe que pode ignorar" treina o operador a ignorar FAIL — e aí o próximo FAIL verdadeiro passa junto. A lista é explícita, por caminho: peça nova sem .peca cai em FAIL como deve. PF-01 no acervo passou de 25·7·16 para 25 PASS · 0 FAIL · 4 [hist] · 16 [n/a].

• ✅ PP-P1 — RESOLVIDA em 2026-08-26. A JetBrains Mono v2.304 está versionada em 03-assets/fontes/jetbrains-mono/ — pesos 400, 500 e 700 (os três que as bancadas pediam ao Google Fonts), mais LICENSE.txt (SIL Open Font License 1.1) e AUTHORS.txt. Baixada do release oficial do projeto no GitHub; MD5 de cada arquivo registrado no MANIFESTO. Cobertura de glifo MEDIDA antes de declarar resolvida, com o leitor de cmap da guarda-glifo.py: 1363 glifos em cada peso, e o repertório que uma peça técnica da SEED precisa — dígitos, alfabeto, acentuação portuguesa completa, e o técnico (° º ª ² ³ µ Ω · — –) — está todo presente. ⚠ Falta exatamente um: U+2011, o hífen inquebrável. Medido: zero ocorrências em todo o acervo (89 peças, as bancadas, os canônicos e os gêmeos), e se alguém o usar amanhã a GL1 reprova — foi para isso que ela nasceu. ⭐ Declarar a lacuna que se mediu vale mais que declarar a cobertura que se supôs. ⚠⚠ E ISSO RESOLVE DISPONIBILIDADE, NÃO USO. A pendência travava a fonte por ela não existir; agora ela existe. Passar as peças impressas a consumir --seed-font-mono é decisão separada e dele — a PP-P1-b abaixo, apresentada a ele com visual e número em 2026-08-26. ⭐ Destravar um recurso não autoriza gastá-lo: quem aprovou a peça aprovou a peça que viu. ⚠⚠⚠ CORREÇÃO DA v5.23 — esta entrada afirmava, na v5.22, que "número em peça impressa continua em Montserrat com tabular-nums". É FALSO, e foi medido em 2026-08-26. O gen-comprovante-ponto.py:190 declara .mono{font-family:var(--seed-font-mono);font-variant-numeric:tabular-nums} e o Chrome rasteriza aquilo em Consolas — fonte da Microsoft, que a peça não embute. A regra estava sendo desobedecida em silêncio, e a frase errada não era descuido 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. É a mesma classe do defeito da §12.19 — a placa que afirmava uma conferência que não aconteceu.

• ✅ GM-P1 — RESOLVIDA no mesmo dia. A guarda-piso-mm.py morria com UnicodeEncodeError antes de medir qualquer coisa, porque imprime ≥ no cabeçalho e o console do Windows abre em cp1252 — quem rodasse sem PYTHONIOENCODING=utf-8 via um traceback e podia ler isso como reprovação da peça. Instrumento que morre por codepage do console mente sobre o artefato. O script passou a reconfigurar a própria saída para UTF-8 com errors='replace': perder um símbolo no relatório é aceitável, perder a MEDIÇÃO não é. Conferido rodando sem a variável de ambiente.

• ✅ SN-P10 — FECHADA em 2026-09-04 por CONFIRMAÇÃO do veredito de 25/08 (MANIFESTO §145, resposta P-SN, verbatim: "A — confirmo o veredito de 25/08 (60 mm, como está)"). A placa A3 fica com o logo a 60 mm, legível a 1,75 m, de propósito — o critério é o de 25/08, "nao podemos competir com mensagem de segurança", registrado no gerador e na §12.19 mas nunca nesta fila (por isso a v5.28 a reabriu como órfã). Desta vez a confirmação saiu COM os renders que faltavam: opções A (60 mm · 1,75 m), C (94,8 mm · 2,77 m, só o rodapé) e B (137,1 mm · 4,0 m) na mesma escala, em preview/gate-apoio-sn-p10/, geradas pelo modo --logo-placa do gen-sinalizacao.py (instrumento que só consome espaço em branco e aborta se tocar conteúdo normativo; a saída oficial não mudou um byte). O registro original da pendência fica abaixo como história: PENDÊNCIA ÓRFÃ: existia em 2026-08-24 e nunca teve entrada nesta lista, só uma menção solta dentro do §17.6. Achada em 2026-08-27 ao responder "quanto falta". O que ela é: ao tirar o amarelo e a tarja turquesa da família NR-10 (MR-P11), a placa A3 perdeu reconhecimento a distância — o logo a 60 mm dá caixa alta de 8,75 mm, legível a 1,75 m numa peça projetada para 4,0 m. Contraste do texto MELHOROU (9,37 → 21,00); o que piorou é marca, não segurança. Saída medida que não acrescenta cor: logo maior, ao custo de área útil da placa. ⭐ É DECISÃO DELE, com custo em mm — e por isso a pergunta precisa sair com as duas opções renderizadas lado a lado (§14.13), não em prosa. ⭐⭐ RÉGUA QUE FICA: pendência citada dentro do texto de outra seção não existe. Só existe o que tem entrada na fila — três rodadas de "resolver tudo em aberto" passaram por cima desta sem vê-la, porque "em aberto" se lê NA LISTA. Toda pendência nomeada em prosa entra aqui no mesmo movimento em que é nomeada.

• ⏳ PT-P2 — a tela de consulta do comprovante de ponto (§12.3-a) ainda não existe como artefato: a norma admite disponibilizar em sistema em vez de emitir, e a tela compartilha a FONTE com o PDF, não o layout. ⭐ RECLASSIFICADA em 2026-08-27: isto é PRODUÇÃO NOVA (arquétipo de tela do ERP), não ponta solta de conserto — entra na fila da onda de aplicações junto com a AD-P7, não na fila de pendências de fechamento. Chamar produção nova de pendência faria a lista de pendências nunca zerar, e uma lista que nunca zera deixa de informar.

• ✅ MR-P13 — FECHADA em 2026-08-25. O nome correto é Básico, não "Basic" — veredito dele: "sobre o nome, o correto é Basico, nao Basic". Os três planos são Básico · Essencial · Premium. E a lacuna maior fechou no mesmo ato: ele anexou um orçamento SEED Plus real e autorizou usar a estrutura, então o sobreaseed.md §6 passou a registrar o que cada plano contempla — uma escada de 2, 4 e 7 itens —, o que fica fora dos três, as observações operacionais e como o preço se estrutura (por USINA, não por cliente). Peça já pode descrever os planos.

• ✅ MR-P14 — RESOLVIDA em 2026-08-25, e o canônico estava certo nas DUAS vezes em que foi questionado. O orçamento SEED Plus (24/04/2026) e depois o contrato-modelo de prestação de serviço (rev. 00) traziam, os dois, Rua Albânia, 81 para Governador Valadares. Veredito dele: "O endereço correto em Governador Valadares é da Rua Duarte Coelho, vou solicitar pra corrigir onde estiver errado." Nenhuma peça do design system foi ou precisa ser alterada. A ação virou duas correções fora dele, e a segunda é de outra natureza: o orçamento em circulação, e o contrato que o cliente assina — endereço errado da CONTRATADA afeta notificação, foro e correspondência formal. ⭐ A régua: decisão tomada com uma evidência merece ser reapresentada quando aparece outra — não para duvidar do decisor, e sim porque quem decidiu tinha menos informação. Nas duas vezes o canônico venceu, e foi por não ter sido alterado "para casar com o material" que ele seguiu servindo de referência.

• ✅ MR-P15 — RESOLVIDA em 2026-08-25. Ver §12.10: o contrato está correto, e três itens separam o Essencial do Premium.

• ✅ PP-P1-b — RESOLVIDA em 2026-08-26, e a autorização veio mais forte que um "vai". Veredito dele, verbatim: "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 para isso". O QUE FOI FEITO, por camada — porque "forçar" tem um jeito para cada natureza de artefato: (a) PEÇA IMPRESSA viaja para fora do repo → fonte EMBUTIDA. Os geradores do comprovante de ponto e da pasta A4 embutem a JetBrains Mono 400/500/700 em base64, mesmo contrato TP1 da Montserrat (ABORTA se faltar). Custo: ~1,07 MB por peça, declarado. A assinatura de e-mail fica FORA, como apresentado: cliente de e-mail não carrega @font-face. (b) BANCADA/TELA é lente interna → @font-face por URL RELATIVA para os TTF versionados em 03-assets/fontes/ — Montserrat E JetBrains, porque o achado era maior que o enunciado: zero dos 42 arquivos de 05-html-de-referencia/ tinha @font-face, ou seja até a Montserrat deles dependia da fonte instalada no sistema (funcionava nesta máquina por sorte). ⭐ Embutir base64 nas 42 custaria ~45 MB de repo para arquivos que nunca saem dele; URL relativa dá o mesmo resultado por ~1 KB cada. 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.html recebeu direto COM nota: o gen-dm.py não regenera a bancada (pendência GN-P1). (c) AVISO + LINK, como ele pediu: nasce 03-assets/fontes/LEIA-ME.md — quando instalar (só para uso FORA do DS: Office, Figma), como (clique direito → Instalar nos TTF daqui), e os links oficiais. A PILHA DE RESERVA FICA (ordem dele: "podemos deixar o plano B") — com o @font-face presente ela só trabalha em arquivo aberto fora do repo ou mutilado, que é o papel de um plano B. MEDIDO NO FIM, pelo mede-fonte-efetiva.mjs (132 arquivos): 55 aplicam mono a texto → 53 RECEBEM a JetBrains · 1 [sem-pixel] (nó oculto da tela-autenticacao) · 1 TROCOU: a assinatura de e-mail — a exceção declarada. Antes do conserto eram 26 de 42 bancadas + as 5 peças vivas em Consolas. ⚠ Dois defeitos de aplicação pegos no caminho, com régua: (1) sete templates usam str.format() e as chaves {} do CSS viraram placeholder (KeyError: font-family) — ⭐ bloco inserido em template herda o MECANISMO DE ESCAPE do template; não existe "CSS neutro" dentro de um molde; (2) o medidor classificava nó que não pinta pixel como "recebeu outra" — nasce o veredito [sem-pixel], ⭐ "não mensurável" é veredito próprio, nunca FAIL nem PASS (a mesma régua do [n/a] das guardas). O texto da pendência original, para histórico: EMBUTIR ou não a JetBrains Mono nas peças impressas. APRESENTADA A ELE em 2026-08-26, com visual e número. Decisão dele. Para quem lê sem contexto: a PP-P1 (acima) resolveu a disponibilidade da fonte; esta resolve o uso. Ele cobrou a falta do visual, verbatim: "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 o que tenho que decidir". ⭐⭐ A cobrança é justa e nomeia uma leitura errada da §14.13 que eu vinha fazendo: "toda pergunta ao decisor sai 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. O ESTADO MEDIDO (instrumento novo ferramentas/mede-fonte-efetiva.mjs): das 90 peças, 22 aplicam o token mono a texto; 17 recebem a JetBrains — e são todas da era anterior, que a embute — e 5 recebem outra: são as peças vivas (mock da assinatura, os 2 comprovantes de ponto, as 2 pastas A4), que rasterizam Consolas. ⚠ Consolas é fonte da Microsoft, licenciada com o Windows: peça que depende dela sai diferente em Mac, em Linux e na gráfica. O CUSTO MEDIDO: a JetBrains Mono é +9,12% mais larga que Consolas no mesmo corpo (56 nós de uma linha, de +9,01% a +9,13% — a uniformidade é a assinatura de uma medição correta), e zero nós passam a transbordar nas cinco peças. Cada peça fica ~357 KB maior. RECOMENDAÇÃO APRESENTADA: embutir nas 4 peças impressas; a assinatura de e-mail fica de fora, porque cliente de e-mail não carrega @font-face e os 357 KB não mudariam o que o destinatário vê. Medição completa em 09-pesquisa/medicao-fonte-mono-e-papel-do-drive.md.

• ✅ GT-P1 — FECHADA em 2026-08-27 (v5.27): medida e decidida por ele — o Drive não guarda mais o DS. O texto abaixo é o REGISTRO DO ACHADO, preservado na data em que foi escrito. GT-P1 — o papel do Google Drive. APRESENTADA A ELE em 2026-08-26 com número. Decisão dele. Herdada da fundação (CLAUDE.md), e ele a abriu supondo: "acredito que hoje o google drive nao tenha papel nenhum, já que todos os arquivos foram migrados para github correto?" ⚠⚠ A premissa está invertida, e a inversão é grande: o Drive tem hoje o papel mais crítico da operação — ele é o DISCO onde o repositório mora. A cópia de trabalho está em G:\Meu Drive\Claude\code\assistente de email\, e G: é Google Drive File Stream 130.0.2.0. Os 399 MB em 1.309 arquivos do .git são sincronizados para a nuvem a cada commit. ⭐ O git já é a sincronização; o Drive sincronizando o .git por cima é uma segunda sincronização competindo com a primeira. E a pasta de ORIGEM da migração não foi removida: G:\Meu Drive\#nuvem\marca seed\Design System v2, 945 arquivos / 105 MB, gravável. Conferida por MD5 (nunca por tamanho — §14/D-62): 135 idênticos · 172 DIVERGENTES · 629 só lá · 9 de basename ambíguo. ⚠⚠ Os 172 divergentes são versões ANTIGAS dos canônicos, congeladas: marca-seed.md v5.11 contra a v5.22 do repositório; seed-tokens.css v1.20 contra v1.23; seed-componentes.md v1.29 contra v1.38. Existem hoje onze versões de atraso do canônico de marca num arquivo com o nome certo — e numa casa cuja regra fundadora é "~50% das pesquisas são feitas por IA", um agente que varra o Drive lê a v5.11 sem nada indicar que está errado. ⭐ A armadilha em forma literal: a pasta antiga tem temporaria/marca-seed-v5.4-PROPOSTA-aguardando-veredito.md, cujo conteúdo — por decisão dele de 22/08 — começa com "⚠ APAGUE ESTE ARQUIVO — ele é uma LÁPIDE". O nome anuncia pendência dele em aberto; o conteúdo diz que já foi decidida. O risco não é teórico: o CLAUDE.md registra que ele "já custou um arquivo em 2026-08-06". CUSTO DE OPERAR ALI, medido (e a primeira medição foi refeita porque a ORDEM de execução era uma segunda condição variando, §14.5): git status 275 ms local × 522 ms Drive · git log --stat -20 8.791 × 15.577 ms · git fsck 8,2 × 21,2 s. Drive de 1,8× a 2,6× mais lento. git fsck passa nos dois — não há dano instalado, há risco e lentidão. RECOMENDAÇÃO APRESENTADA: (a) mover o repositório para disco local, com o GitHub como única cópia remota; (b) aposentar a pasta antiga renomeando, nunca apagando, para Design System v2 — CONGELADO 22-08-2026 — NAO USAR, com um LEIA-ME.md apontando a fonte de verdade. ⭐ O nome faz o trabalho que o conteúdo não faz. Não apagar porque 629 daqueles arquivos são evidência de gate da era anterior, e evidência não se descarta. ⚠ Nada executado: mover o repositório muda o caminho de tudo, e renomear pasta no Drive dele é mexer nos arquivos dele. ⚠⚠ TERCEIRA AÇÃO, achada no fechamento e ela é MINHA: o eixo 1 do audita-fechamento.py lista 47 caminhos citados nos canônicos deste repositório que não estão aqui dentro, e cruzando a lista com a pasta antiga, 44 dos 47 ESTÃO lá (render-audit/, validacao/, temporaria/, lixeira/). ⭐⭐ Logo a pasta antiga não é só cópia morta: ela é a ÚNICA cópia de 44 arquivos que os canônicos daqui referenciam. Isso reforça renomear em vez de apagar, e exige um terceiro passo: marcar essas 44 citações como históricas, ou trazer os arquivos para o repositório. Aposentar a pasta sem tratar as citações deixaria 44 referências apontando para o nada, dentro dos canônicos. ⚠⚠⚠ CORREÇÃO DA v5.24 — o parágrafo acima EXAGERA, e a medição posterior o desqualifica. Escrevi "ela é a ÚNICA cópia de 44 arquivos que os canônicos referenciam" com base numa contagem de citações de caminho. Medido depois por execução (33 instrumentos rodados): nenhum código vivo depende daqueles 44 arquivos — são citações em prosa, dentro de documentação histórica. ⭐⭐ É a MESMA classe do erro que eu havia acabado de nomear na §131.14 — contar citação como dependência confunde escrita com leitura — e eu o repeti no parágrafo seguinte. O tratamento das 44 citações continua sendo trabalho meu, mas é conserto TEXTUAL: elas não bloqueiam a deleção. ✅✅✅ EXECUTADA em 2026-08-26, madrugada — o repositório MUDOU DE CASA: de G:\Meu Drive\Claude\codessistente de email\seed-design-system para G:\Meu Drive\Claude\code\seed-design-system. A pasta antiga do Drive ele mesmo deletou (verificado depois: guarda-grafismo 21·0 e audita-fechamento com os mesmos 2 achados — nada quebrou). O movimento travou duas vezes em Device or resource busy e as causas valem registro: cinco processos python de sessões anteriores — três na porta 8820 e dois de 25/08 — todos servidores de preview empilhados com cwd dentro do repo, mais o shell da própria sessão. ⭐ Pasta que "não quer" ser movida está sendo segurada por alguém — e o alguém costuma ser você mesmo, de outra sessão. Verificado no caminho novo: git status limpo, fsck OK, guardas rodam (ES 90·0, GR1 21·0), mede-fonte-efetiva confirma [ recebe ] em bancada e peça, preview servindo. A memória de sessões foi copiada para o project-key novo. A pasta assistente de email ficou com apenas o .claude/ do projeto antigo — deletá-la é decisão dele, não minha. ✅✅ VEREDITO DELE, 2026-08-26: "a pasta G:\Meu Drive#nuvem\marca seed\Design System v2 vou renomear e depois deletar, nao precisa dela mais la" · "a pasta seed-design-system vou deixar os arquivos disponiveis offline no pc para dar agilidade na leitura e gravacao". A DELEÇÃO ESTÁ LIBERADA, e a liberação é MEDIDA — não opinião. Antes de dizer "pode", conferi em duas vias: (a) por MD5: dos 945 arquivos, 135 são idênticos ao que já está aqui; 172 são versões antigas dos canônicos (o motivo de a pasta ir embora); 629 são evidência e ferramentas da era anterior; e o SEED-DS-EXPORT-2026-08-22.zip de 11,6 MB é o pacote que originou o commit de fundação — cujo conteúdo está no GitHub. (b) por EXECUÇÃO: rodei os 33 instrumentos que citam aquelas pastas. Seis morrem por falta de arquivo, e NENHUM pela pasta do Drive — morrem por falta de node_modules/@fontsource, dependência de programação do ambiente do Cowork que nunca esteve lá. ⭐⭐ E o caminho até essa resposta tem a lição: minha PRIMEIRA análise disse 75 dependências (contou menção a caminho, inclusive em comentário, como leitura de arquivo — o erro que eu tinha acabado de nomear na §131.14). A SEGUNDA, mais fina, disse zero — e também errou, porque o caminho da única dependência real é montado por join() em pedaços que nenhum regex de linha vê. Foi a linha de conferência contra a prova empírica que salvou: eu havia escrito que a análise só valeria se explicasse a morte observada da guarda-grafismo, e ela não explicou. ⭐⭐⭐ Quando duas análises estáticas seguidas erram, o problema não é o regex — é o MÉTODO: dependência de arquivo em runtime se mede EXECUTANDO. Sem aquela linha eu teria reportado "0 dependências — pode deletar" com o instrumento cego para o único caso provado. ⚠ SOBRE DEIXAR OFFLINE, e é preciso ser claro sem insistir: offline ataca a latência medida (1,8× a 2,6×) e é a metade do problema. O que continua é o Drive sincronizando o .git (399 MB, 1.309 arquivos) a cada commit — a origem do risco de conflito que já custou um arquivo em 2026-08-06. A decisão é dele e é razoável (backup na nuvem de graça, GitHub cobrindo o histórico); fica registrado que o risco não virou zero, e que erro estranho de git tem esta como primeira hipótese.

• ✅ GT-P2 — por que a pasta do projeto se chama assistente de email. Pergunta dele, respondida com data em 2026-08-26. "porque essa pasta tem uma subpasta com o nome \assistente de email? o que isso tem haver com o projeto?" — Nada. É herança acidental.

  o que	quando nasceu
  a pasta assistente de email	2026-05-04, 23h52
  o .claude/ dentro dela	2026-05-05, 00h51
  o design system	2026-08-22, 01h24 — três meses e meio depois
  o commit de fundação	2026-08-22, 01h33
  Era pasta de projeto de um assistente de e-mail, de maio, do qual **não
  sobrou nada** além de um settings.local.json de permissões. O DS foi criado
  dentro dela, provavelmente porque já estava configurada.
  Renomear é seguro do lado do repositório, e isso foi conferido: nenhum
  arquivo versionado cita assistente de email; nenhum código depende do
  caminho (os únicos caminhos absolutos funcionais apontam para o Chrome e para
  a pasta de dependências, ambos em C:); os oito arquivos que mencionam
  G:\Meu Drive são documentação. O que muda é fora daqui: o histórico das
  sessões fica indexado pelo caminho antigo. Decisão dele, sem pressa.

• ✅ FT-P1 — FECHADA em 2026-08-27 (v5.27): subsets woff2 da SEED, 4 peças de 3,1 MB → ~290 KB. O texto abaixo é o REGISTRO DO ACHADO, preservado na data em que foi escrito. FT-P1 — REFORMULADA em 2026-08-26, e a reformulação inverte o pedido. Ela dizia: "o acervo tem só .ttf, enquanto as peças antigas embutem .woff2 e pesam 113 KB — converter". Medido, converter para o .woff2 que existe seria plantar um defeito. O .woff2 da JetBrains já estava no repositório, escondido como data-URI dentro de 07-pecas/gate-7-formatos/F2-cartao.html: 21.832 B contra 273.860 B do .ttf, 12,6× menor, assinatura wOF2 conferida. Mas ele é o recorte "latin" do @fontsource, e a cobertura medida no Chrome dá: 86/86 no repertório que as peças vivas realmente imprimem (empate com o .ttf) e 39/50 no repertório técnico da disciplina. Os 11 ausentes: ≤ ≥ √ Ω Δ ≠ ■ ✓ ✗ ∅ ∞. ⚠⚠ Ω (ohm) e Δ (delta, ligação triângulo) são caracteres de TRABALHO numa empresa de engenharia elétrica, e ✓/✗ é o glifo do defeito fundador da GL1 na Montserrat. ⭐⭐ Régua: cobertura medida contra o acervo de HOJE responde "quebra agora?"; contra o repertório da DISCIPLINA responde "vai quebrar?". São perguntas diferentes, e é a segunda que escolhe formato. O empate em 86/86 me faria adotar o arquivo 12,6× menor e plantar um defeito silencioso na primeira peça que escrevesse um ohm. O pedido certo agora: gerar woff2 subsetado pelo repertório da SEED, não adotar subset de terceiro. Exige fontTools + brotli, que o ambiente não tem. ⚠ E é achado sobre a era anterior: as 18 peças de gate embutem esse recorte incompleto — funcionou porque nenhuma escreveu um Ω.

• ✅ PV-P1 — RESOLVIDA em 2026-08-26, no gerador, e a paridade ZEROU: 513 PASS · 0 FAIL pela primeira vez. Os dois casos, consertados pela §14.4: (a) o .selo do base-bancada.css consome --seed-feedback-info-bg/-text, e o gen-banco-dominio.py era o único dos 9 gerados sem os dois na lista NOMES — os 8 irmãos já os tinham. ⭐ Quem consome CSS COMPARTILHADO herda a lista de tokens do compartilhado — e lista escrita à mão é exatamente a classe que a G2 existe para pegar. (b) o banco-identidade consumia --seed-surface-default, que não existe — e a intenção estava ESCRITA no próprio template (SI20: "superfície neutra com fio de 1px"). Passou a consumir --seed-surface-raised, que já estava na lista NOMES do gerador: alguém a listou e depois consumiu outro nome. §14.1 respeitada: nada foi criado. O texto original da pendência:

• ⏳ PV-P1 — dois tokens FANTASMA em duas bancadas. Achado em 2026-08-26, e o pior nao e o defeito: e que eu nao o tinha visto. ⚠⚠ Como ele apareceu: rodando a paridade-previews.py no fechamento desta rodada. Placar: 511 PASS · 2 FAIL. Os dois arquivos estão intocados por esta rodada (git status vazio; última alteração no commit dd32811), então os FAIL são pré-existentes — e eu não rodei essa guarda no fechamento anterior, tendo reportado o placar da rodada sem ela. ⭐⭐ Régua: guarda que não roda não é guarda — é guarda em potencial. E placar de fechamento que omite uma guarda do conjunto não é placar incompleto: é placar falso, porque quem lê "tudo verde" lê "tudo medido". O QUE A G2 EXIGE, e ela está certa: token consumido tem de estar definido no PRÓPRIO arquivo — bancada é autocontida, e por isso embute o bloco :root. Os dois casos são de naturezas diferentes: (a) banco-dominio.html consome --seed-feedback-info-bg e --seed-feedback-info-text em um elemento (background e color) sem defini-los no próprio bloco. ⚠ Os valores EXISTEM no canônico (#ECF4FC/#006783 claro, #003241/#96E0FD escuro) — o conserto é mecânico e não cria valor. Mas ele muda o que se vê: hoje as duas propriedades não resolvem. (b) banco-identidade.html consome --seed-surface-default em um background, e esse token não existe em lugar nenhum — zero definições no seed-tokens.css. ⚠ Bate na §14.1: valor que não existe no canônico NÃO SE CRIA. Descobrir a intenção (provavelmente uma das superfícies existentes) é decisão de conteúdo, não conserto mecânico. ⚠ NÃO consertado nesta rodada, e o motivo é a §14.4: as duas bancadas são geradas (gen-banco-dominio.py + banco-dominio-template.html; idem identidade), então o conserto vai no gerador e se prova por regeneração byte-idêntica — trabalho próprio, com gate próprio. E ele não pediu isso: ampliar o escopo em silêncio é o que a régua desta mesma rodada condena.

• ✅ CT-P8 — FECHADA em 2026-08-27 (v5.27): CT1 em 168 PASS · 0 FAIL no acervo. O texto abaixo é o REGISTRO DO ACHADO, preservado na data em que foi escrito. CT-P8 — 32 FAIL da CT1 em quatro artefatos, e são PRÉ-EXISTENTES. Achado em 2026-08-26 ao rodar o conjunto COMPLETO de guardas. A guarda-centro-alvo.mjs (contrato CT1 — o centro do desenho tem de coincidir com o centro do alvo de toque) fecha em 168 PASS · 32 FAIL · 232 [n/a] sobre 54 arquivos, 1.514 medições efetivas, tolerância 1,00 px. Os quatro reprovados: banco-data.html, banco-navegacao.html, tela-shell.html, tela-tabela.html — 8 FAIL cada, uma por combinação tema × estado. ⭐ A uniformidade é o que dá confiança no achado: o mesmo número de controles fora do centro nas oito combinações (claro/escuro × repouso/hover/ativo/foco) diz que o defeito é geométrico, não de tema nem de estado. E como ele aparece também em claro/repouso, que a CT1 SEMPRE mediu, ele não é novidade da extensão da guarda (as CT-P1/CT-P2 resolvidas): estava visível e ninguém reportou. ⚠ Nenhum dos quatro foi tocado nesta rodada (git show --name-only do commit desta rodada não os contém), e o banco-navegacao.html não muda desde o commit de fundação fbba442, de 2026-08-22. ⚠ Não consertado aqui: são bancadas e telas, geradas por gen-banco-*.py + template (§14.4), e o conserto se prova por regeneração byte-idêntica com gate visual próprio. E ele não pediu isso.

• ✅ GR-P10 — RESOLVIDA em 2026-08-26, e o conserto foi UMA LINHA porque os arquivos já estavam aqui. O DIR padrão passa a ser 07-pecas/gate-7-formatos. Conferido por MD5 ANTES de copiar nada: os 7 HTML de gate-z3/formatos são idênticos aos de 07-pecas/gate-7-formatos/ e os 5 de gate-z3/largos aos de 07-pecas/gate-pecas-largas/ — 12 de 12. Os PNG daquela pasta são saída de uma execução antiga (SALVA_PNG), não entrada: a guarda lê um diretório de HTML e renderiza. Placar: GR1 21 PASS · 0 FAIL · 7 de 7 alvos medidos — pela primeira vez neste repositório. ⭐⭐⭐ RÉGUA: antes de resgatar um arquivo, conferir se ele já está salvo em outro lugar. Eu ia copiar 14 arquivos para dentro do repositório e criar uma SEGUNDA cópia do que ele já versiona — exatamente a doença que a GT-P1 descreve no Drive. O resgate errado teria plantado aqui dentro o problema que estávamos tirando de lá.

• ✅ PF-P2 — FECHADA em 2026-08-27 (v5.27): nasceu a guarda PF2, 7 defeitos reais na estreia. O texto abaixo é o REGISTRO DO ACHADO, preservado na data em que foi escrito. PF-P2 — a folha de preview/ não tem guarda de contraste, e foi nessa isenção que um defeito de legibilidade morou. Achado POR ELE, olhando. Ele apontou, verbatim: "essa fonte onde está marcado no texto nao está dando para ler, veja se aplicou de maneira errada ou configuramos algo errado". Medido no Chrome: contraste 1,01 em cinco trechos de <code> dentro do bloco escuro da folha — contra o piso 3,00. Praticamente branco sobre branco. A CAUSA É DE CLASSE, não descuido: o code declarava background e não declarava color. Dentro de um bloco de fundo escuro ele herdava a tinta clara do bloco e mantinha o fundo claro próprio. Qualquer bloco escuro com code dentro reproduziria. ⭐⭐ RÉGUA: fundo e tinta se declaram JUNTOS, sempre. Declarar só um deixa o outro à mercê da herança — e herança de bloco escuro com fundo próprio claro é a receita exata do invisível. ✅ A folha foi consertada e medida: 274 elementos de texto, mínimo 5,87 nos code e 4,23 na página inteira, zero abaixo do piso. ⏳ ✅ A GUARDA NASCEU na v5.27 (contrato PF2, guarda-preview-contraste.mjs, piso 4,5 / 3,0) — o que segue é o registro do que estava aberto em 2026-08-26: O que ficava aberto era a GUARDA: preview/ é isento das auditorias de contraste porque é lente de revisão, não peça — e a isenção tem motivo bom. ⭐ Mas rascunho que serve de base para o decisor decidir não é rascunho. Estender a guarda ao preview/ é trabalho meu, na fila.

• ⏳ GR-P10 — a guarda-grafismo.mjs NÃO RODA. Ver acima: RESOLVIDA. O texto original da pendência, para quem precisa do diagnóstico: Ela morre com ENOENT procurando 06-validacao/render-audit/gate-z3/formatos. Essa pasta não existe no repositório — e EXISTE na pasta antiga do Drive (#nuvem\marca seed\Design System v2\render-audit\gate-z3\formatos). ⭐⭐ Logo uma guarda VIVA e versionada aqui depende de uma pasta que está só no Drive. Não é mais uma questão de "citações históricas nos canônicos" (as 44 do eixo 1): é código de validação que não executa. O tamanho medido: 34 arquivos de 06-validacao/ citam render-audit/, e 21 citam caminho ausente. ⚠ Mas "caminho ausente" não é o mesmo que "quebrado": para várias guardas (guarda-piso-mm, paridade-previews, guarda-peca-fresca, guarda-escape) aquela pasta é saída que elas mesmas criam, e as quatro passam. ⭐ Contar citação de caminho como defeito confundiria escrita com leitura — e inflaria o número por um fator de 20. Medido de fato: 1 guarda morre. render-audit/ está no .gitignore desde 2026-08-26, então esses arquivos nunca vão aparecer por commit. O conserto é (a) trazer a fixture do gate-z3 para dentro do repositório, ou (b) reapontar a guarda — e as duas saídas dependem do veredito da GT-P1.

Pendências abertas pela Onda 3 da F8 (2026-09-04), todas nomeadas — códigos conferidos como não usados no marca-seed.md, no MANIFESTO e no seed-componentes.md:

• ✅ PI-P1 — FECHADA em 2026-09-04 por veredito dele, sem leitura de norma (MANIFESTO §144, verbatim: "PI-P1 nao precisa porque isso é fabricado conforme norma da concessionária"). A placa de advertência de geração própria é peça da distribuidora, fabricada no padrão dela em cada estado; o DS não precisa conhecê-la porque a placa SEED (§12.27) já declara que não a substitui. O registro abaixo é o que estava aberto: placas de EDP (ES) e Neoenergia Coelba (BA) não lidas (só a CEMIG ND-5.30 foi, §12.27). Nasceu citada em prosa como ET-P5 em gen-etiqueta.py e gen-placa-instalacao.py — sem entrada na fila, e com código que colidia com o ET-P5 do seed-componentes.md (consumidores do e-mail transacional). Repontada nos dois geradores em 2026-09-04. Efeito na peça: nenhum no desenho (a placa declara que não substitui a da distribuidora); o que muda é saber se ES/BA vedam publicidade como MG.
• ✅ FV-P1 — capas de rede social — FECHADA em 2026-09-04 (§12.30). Produzida em três direções por plataforma para gate comparativo com pesquisa de mercado; direção decidida por plataforma no MANIFESTO §145 (LinkedIn A · Facebook C · YouTube A+ · X A, não publicada). Os 48 arquivos de estudo saíram em 2026-09-05 por tabela de remoção aprovada (§147).
• ✅ FV-P4 — capas de destaques do Instagram — FECHADA em 2026-09-05 (§12.31), por ordem dele ("produzir agora as duas", §145): 8 destaques, ícone do set §45, composição C escuro decidida pela sessão por delegação (§146) e exposta a veto.
• ✅ FV-P5 — FECHADA em 2026-09-05 por ordem dele ("FV-P%: pode criar", §147): nascem hard-hat (Obras) e solar-panel-plus (SEED Plus) no set §45 do seed-componentes.md (v1.39, 30 glifos), com alternativas (crane, wrench-plus) desenhadas, renderizadas e descartadas com o porquê (MANIFESTO §148, folha preview/gate-apoio-fv-p5/); os dois destaques regeneram com ícone (§12.31). Exposto a veto no relatório.
• ✅ FV-P3 — capa do perfil comercial do WhatsApp Business — FECHADA em 2026-09-04 (§12.30), por ordem dele ("produzir agora as duas", §145), na direção A. Medida secundária (1211 × 681) e recorte medido em captura de 2022: a conferência no app antes de publicar é etapa do gate humano.
• ✅ FV-P2 — FECHADA: rasterização em 2026-09-04 (ordem dele: "PV-P2 pode fazer pra adiantar", MANIFESTO §144; §12.26 traz a lista, as provas e o defeito de instrumento) e upload para o espelho §5.4 em 2026-09-05, pela sessão com autorização explícita dele (§147): subpasta Logos/Símbolo/favicon/, 10 arquivos com MD5 conferido, permissão pública herdada, FILE_IDs lidos pela API e dois deles baixados pela URL pública com MD5 igual ao do repositório.