75. TP1 — A TIPOGRAFIA E OS RECURSOS DO ARTEFATO REALMENTE CARREGAM

Em uma frase: Fonte, peso e arquivo têm de carregar DE VERDADE no artefato: vale o que o navegador resolveu, não o que o CSS pede.

Para quem chega sem contexto. Esta seção nasceu de uma pergunta do Rafael que era sobre outra coisa. Ele viu, num anexo, "uma imagem que não carregou" e perguntou se ela mudava a avaliação de contraste. Não mudava — e a resposta está em §75.1, com número. Mas a investigação achou uma dimensão de cobertura inteira que não existia: ninguém nesta casa jamais mediu se as famílias tipográficas e os recursos externos que um artefato declara realmente chegam.

Pergunta do decisor sobre um detalhe é o modo mais barato de descobrir uma dimensão de cobertura inteira que não existia.

Vocabulário. Pilha de font-family = a lista de alternativas de uma declaração ('Montserrat', sans-serif é UMA pilha com uma família nomeada e uma genérica). Genérica = serif, sans-serif, cursive, monospace, system-ui e afins — o navegador sempre resolve. @font-face embutido = a fonte viaja dentro do arquivo (ou vem de um woff2 declarado), e por isso é portátil. Fonte de sistema = a família existe na máquina de quem olha, e por isso não é portátil.

75.1 A resposta à pergunta: a imagem quebrada NÃO muda o veredito#

Medido variando uma condição — o mesmo cartão renderizado (A) com as imagens quebradas e (B) com as imagens substituídas por um arquivo local do mesmo tamanho declarado:

O documento fica 1.099px mais alto com as 45 imagens presentes, e a caixa do logotipo muda 0,8px de altura — mas nenhum dos dois move o texto dentro do cartão. Logo os 3,22 do amarelo estão certos, com ou sem a imagem.

⚠ O que a pergunta não continha, e é maior. O seed-design-system.html depende de 47 recursos de rede: 45 imagens em lh3.googleusercontent.com (Google Drive) e 1 folha do Google Fonts que traz duas famílias. Medido: 0 de 45 imagens e 0 de 2 famílias carregam, todas com ERR_TUNNEL_CONNECTION_FAILED. Consequência: todo recorte daquele artefato que esta casa já mostrou ao decisor saiu com a tipografia de RESERVA. O número de contraste nunca mudou por isso — cor, tamanho e peso são declarados em CSS e não vêm da fonte —, mas a aparência que ele julgou não era a real. E aparência é o domínio dele, não do instrumento.

75.2 ⚠⚠ A RÉGUA ÓBVIA MENTE — e é por isso que a guarda existe#

document.fonts.check("18px 'Indie Flower'") devolveu true com a folha de fonte falhando. Ela responde sobre a família resolvida, e a resolvida era a de reserva.

Guarda de fonte escrita com check() mede sempre verde. Fica catalogado como armadilha de instrumento, ao lado do 31º defeito (CSSStyleRule também tem cssRules) e do 44º (parser de CSS por regex).

As duas réguas honestas — e a guarda usa as duas, porque medir duas vezes é variar uma condição:

O cruzamento das duas é o que distingue @font-face de fonte de sistema, e essa distinção é o valor principal da guarda.

75.3 Os contratos#

75.4 O placar, e a leitura correta dele#

Acervo (51 arquivos, 1440×900): 30 PASS · 21 FAIL · 0 [n/a] — 0 TP1-a · 21 TP1-b · 14 TP1-c. Achados contados: 85 de portabilidade · 56 de primeira escolha.

Nenhum artefato perdeu o controle da tipografia (0 TP1-a). As 21 reprovações são de dependência externa, e a atribuição por família muda o que elas significam:

Pasta de prova render-audit/prova-tp1/ — referência 3 PASS · 3 FAIL · 0 [n/a], com 1 TP1-a · 2 TP1-b · 1 TP1-c e 3 achados de portabilidade · 1 de primeira escolha. Seis fixtures, uma por cláusula e uma por caminho de achado. Nela, FAIL é o resultado desejado.

⚠⚠ CONTAMINAÇÃO DO AMBIENTE, DECLARADA. Para consertar a fidelidade dos recortes desta rodada, o contêiner recebeu apt install fonts-montserrat. Montserrat passou a resolver como fonte de sistema, e é por isso que os 85 achados de portabilidade existem: artefatos que declaram Montserrat sem embuti-la aparecem como "resolvem" aqui e não resolveriam numa máquina limpa. A guarda imprime esse aviso em toda execução. Contaminação de ambiente que não é declarada é dado sintético plausível com outro nome.

75.5 ⚠⚠⚠ ESTA GUARDA ESTEVE ERRADA CINCO VEZES, E O NÚMERO DE PASSES É O ACHADO#

Fica registrado inteiro, porque a repetição é a lição:

A LIÇÃO, e ela vale para toda guarda nova desta casa: quando uma régua nova reprova EM BLOCO, a primeira hipótese não é "o acervo está ruim" — é "a régua está medindo outra coisa". Cinco vezes seguidas o erro foi o mesmo em forma diferente: medir algo adjacente ao que o contrato nomeia. E as cinco vezes foram pegas pela pasta de prova ou pela atribuição por família — nunca pelo placar verde.

75.6 As duas decisões de COR que esta seção NÃO fecha — elas esperam gate#

Registradas aqui porque a medição está feita e não deve ser refeita. Nada disto foi aplicado a nenhum artefato.

(i) O amarelo no cartão de post social — o pedido dele não era entregue por nenhuma opção#

Pedido verbatim: "opção B é melhor mesmo, mas o texto amarelo do tamanho do C" — isto é, manter o amarelo, em 18px. Duas descobertas mudaram a pergunta:

A onda decorativa passa por baixo da SEGUNDA linha do texto amarelo. Ela é fill="#098475" opacity=".7". No cartão de hoje é invisível, porque o cartão também é #098475 — mesma cor sobre mesma cor. Assim que o cartão escurece, a onda passa a clarear aquele pedaço. Medido no pixel, linha por linha:

A linha #PROVEMOS EFICIÊNCIA já reprovava, e a régua não mostrava. Ela é branca com opacity:.9. A régua lê a cor declarada (#fff) e informa 4,60; o pixel real é #e6f2f1 e mede 4,01. Ou seja: (A) e (B) deixavam uma segunda reprovação no cartão, que a folha anterior dava como limpo. Escurecer o cartão conserta essa linha de graça: 5,44 em #006C62 e 7,90 em #005048.

RECOMENDAÇÃO ESCRITA — (E+): cartão #005048 (turquesa-800) e onda #00352F (turquesa-900) a 70%. O amarelo #FAD61D não muda de valor (é o acento oficial de marca), o tamanho fica 18px, zero hex novo, e tudo no cartão passa com margem: 6,56 · 8,54 · 7,90 · 9,37. E a onda fica mais visível — escurecer em vez de clarear é ganho de desenho. Alternativas descartadas, com número: (A) perde o amarelo e deixa o kicker em 4,01; (B) cresce o texto e deixa o kicker em 4,01; (C) para em 4,43/3,52; (E) para em 3,92 na segunda linha; (E++) para em 3,22 na primeira.

(ii) O dourado — a recomendação anterior CONTRARIAVA uma decisão já aprovada#

Ele escreveu: "escurecer o dourado está mudando a cor que realmente representa a empresa, ou mantem ou vc acha uma solução melhor".

ERRO REGISTRADO#

A recomendação (D) da folha v14.1 — escurecer #F9B11C para #986900 — contraria o seed-tokens.md v1.5, de 2026-08-11, aprovado por gate visual dele, que diz verbatim: "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)." E a decisão de 2026-07-30: "amarelo #FAD61D = acento oficial de marca; dourado #F9B11C = cor de trabalho (warning, dataviz cat-2, detalhe fotográfico). Nunca os dois na mesma peça."

Ele reconheceu de olho o que já estava escrito, e eu não conferi antes de recomendar. ⭐ Régua que sai daqui: antes de propor mudança de VALOR de cor de marca, leia a linha do canon sobre aquela cor — ela pode já ter decidido, com número. Alternativa descartada é alternativa que alguém já mediu; propor de novo o que foi vetado é desfazer trabalho aprovado.

A saída preserva o hex exato: o dourado não muda de valor, muda de PAPEL. Medido, com #F9B11C intocado:

Tamanho não salva o dourado: mesmo a 44px, com o piso caindo para 3,0, ele mede 1,85 sobre branco. Foi por isso que a folha anterior propôs escurecer — e por isso a proposta estava errada: a saída não é a cor, é a superfície.

Os cinco lugares onde o dourado pinta letra no seed-design-system.html, e a saída de cada um:

O caso do warning é diferente, e o canon já resolveu. Ali o dourado não representa a marca — sinaliza severidade. Os tokens existem e foram aprovados em 2026-08-09/11: feedback-warning-text #5B3E00 sobre feedback-warning-bg #FFF4E4 mede 9,05, enquanto feedback-warning-border e -solid continuam #F9B11C. A cor de marca fica intacta na borda e no sólido; só a LETRA usa o degrau escuro da mesma rampa. Não é escurecer a cor da empresa — é usar o token de severidade que a casa já tinha, o mesmo critério que decidiu o gauge-range-warning.

75.7 Pendências que esta seção abre#

75.8 Peso ou estilo pedido SEM FACE — as três regras do gate FT-P2 (2026-09-15, veredito dele, MANIFESTO §226.1)#

A cláusula TP1-d desta guarda conta os elementos que pedem um peso ou estilo que a família carregada não tem. O censo de 2026-09-15 (scratchpad FT-P2, 53 de 53 HTML de telas, bancadas e e-mails) achou 260: 141 JetBrains Mono a 600, 24 <strong>/<b> em texto já 700 (o bolder pede 900), 76 itálicos, 10 Montserrat 800 residuais da SH-P9 e 9 Montserrat 300 na tela-documento. O que se vê em cada caso é a face vizinha, em silêncio: o negrito dentro de 700 não aparece, o Mono 600 rende 700, o 300 rende 400. Ele decidiu, verbatim: "V-FT2.1 strong: b · V-FT2.2 mono 600: c · V-FT2.3 itálico: b · V-FT2.4 light: b". As regras, na ordem:

Depois da aplicação o censo TP1-d é 79 em 53 de 53 HTML: os 76 itálicos aceitos (TP1-d-3) e 3 botões mono do shell-template.html (.controles .b-larg, fora do escopo do agente FT-P2 — pendência da sessão). Duas verdades a mais que a aplicação achou: (i) o bloco de tokens embutido nas nove bancadas com gerador é por LISTA (tokens_bloco.py) e --seed-text-brand-strong não estava nela — a regra nova em base-bancada.css caía em var() indefinido e a cor não pintava (medido: 0 px onde se esperava tinta); o nome entrou nos nove geradores. Toda regra nova em CSS compartilhado confere o token no bloco de cada consumidor. (ii) .kanban h3 do painel tem a mesma forma (mono 600 + b) e não entrou no censo porque a lente não está visível na carga — corrigido junto (achado da mesma forma se corrige em todos os lugares).

---