Componentes
47. Página institucional — esqueleto, camada de máquina e blocos de conteúdo
seed-componentes.md v2.00 · §47seção 95 de 18447-pagina-institucional-esqueleto-camada-de.md · MD5 11528143Título completo no canon: Página institucional — esqueleto, camada de máquina e blocos de conteúdo — estável (v0.55) · MK1–MK23 · pattern F6 · suíte suite-site.mjs 66/66 ✓ · render 23/0 · contraste 42/0 · gate visual aprovado 2026-08-12 — FECHA O BLOCO 6B · desde 2026-09-14 (MA-P2 fechada, V-MA2.2 = a, MANIFESTO §221) tela-site.html v0.3 carrega a camada de material do §93 — casca com luz, cabeçalho em vidro, ação primária em metal; conteúdo opaco (MA3); régua RC 84/84 nos dois temas; a régua render-site.mjs passou a classificar requisição local por esquema (file:/data:/blob:/about:), porque o grão da casca é um data: URL e não um terceiro
Em uma frase: Quatro tipos de página; toda página declara h1 único e real, title e descrição próprios, URL canônica, lang="pt-BR", alt explícito e JSON-LD por TIPO.
Vocabulário desta seção: camada de máquina · JSON-LD · mega menu
O que esta seção NÃO cobre: Marcação nunca descreve o que não está visível na página, e areaServed nunca afirma sede onde não há. — se é disto que você precisa, não preencha em silêncio: gere o pedido de cobertura (https://ds.seed.eng.br/pedidos/).
Natureza: pattern de COMPOSIÇÃO do F6, como o §46 e o §33 — nenhum componente novo nasce. Consome o botão (§1), o formulário (Bloco 2), o breadcrumb (§36), o menu como disclosure de links (§35/MN1), o accordion (§29) e a iconografia (§45).
O QUE ESTE LOTE ENTREGA E O QUE NÃO ENTREGA. O bloco 6B foi dividido em dois lotes por decisão do Rafael em 2026-08-12, porque o conteúdo se encaixa dentro do esqueleto e a ordem inversa obrigaria a redesenhar. Lote 1 (esta seção): contrato dos tipos de página, cabeçalho institucional, rodapé, o padrão de página de serviço autônoma e a camada de máquina (título, descrição, canônica, dados estruturados, orçamento de peso). Lote 2 (§47.5, escrito em 2026-08-12): hero, prova social, números, card de solução, depoimento, case em vídeo, FAQ e bloco de contato por serviço — MK13 a MK22. O preview e o gate visual do 6B são únicos, no fim do lote 2 — decisão do Rafael: um esqueleto sem conteúdo pareceria cru e o gate visual precisa de uma página de verdade.
PRINCÍPIO HERDADO DO §46, e que vale igual aqui: CONTRATO POR REGIÃO, COMPOSIÇÃO LIVRE. As regiões e os tipos de página são especificados; quais páginas existem, quais serviços ganham página e o que cada uma diz é decisão do projeto do site — não do Design System.
Escopo do produto, decidido em briefing antes da pesquisa (2026-08-12): o site institucional nasce mobile-first — é onde está o acesso em massa. O site informa para converter: cada parte é estruturada para o visitante reconhecer a própria dor e pedir contato para aquele serviço, e o Rafael quer direcionar tráfego pago para a página do serviço sem precisar criar landing page separada (o que não impede ter landing pages depois). Formulário por serviço, não um formulário geral. Foco B2B, com exceção de energia solar, que atende também B2C. O site novo é ruptura visual declarada, reaproveitando conteúdo, algumas imagens e a estrutura de mega menu do site atual.
FRONTEIRA REGISTRADA PARA NÃO VOLTAR (Rafael, 2026-08-12): o site será construído do zero; o site atual não será corrigido. Logo, dívida técnica, nome de pasta, slug e erro de digitação do site atual estão FORA DE ESCOPO. O
estudo-site-atual.mdserve como inventário de conteúdo e diagnóstico de padrão a não repetir — não como lista de correções.(decisão registrada — ver Histórico da seção)
47.1 A linha de base medida — o que NÃO repetir#
Números do estudo-site-atual.md, produzidos por leitura do backup do site atual. Não são
crítica ao site antigo: são o piso contra o qual o novo é medido, e a razão de várias
decisões abaixo existirem como regra explícita em vez de ficarem implícitas.
| Medida | Site atual |
|---|---|
Tags <img> com alt |
0 de 419 |
Páginas com <h1> real |
16 de 22 (as outras usam classe CSS para parecer título) |
Tags <nav> no site inteiro |
0 |
| Título e descrição próprios por página | 0 — a classe SetSeo existe e nunca é instanciada |
| Dados estruturados, Open Graph, canônica | 0 de cada |
| Páginas institucionais no sitemap | 0 de 22 |
| Zoom | bloqueado (maximum-scale=1, user-scalable=no) em toda página |
| Peso | esqueleto fixo de ~2,5 MB, com páginas de até 8,8 MB de mídia |
Diagnóstico central do estudo, e o que ele ensina: o servidor devolve o mesmo HTML vazio para qualquer URL — o roteamento nunca lê a URL pedida — e o conteúdo só chega numa segunda requisição feita por JavaScript. Lição de padrão: a página tem de existir na primeira resposta. Isso não é escolha de plataforma (que é do projeto do site); é requisito de padrão.
47.2 Decisões MK1–MK12#
| # | Decisão | Porquê | Descartado |
|---|---|---|---|
| MK1 | Quatro tipos de página, cada um com contrato próprio: institucional (quem somos, carreira) · serviço (autônoma, ver MK8) · conteúdo (artigo, vídeo, case) · utilitária (contato, obrigado, erro, legal) | O site atual tem 22 páginas sem tipagem nenhuma — mesmo esqueleto e mesmo título para todas, o que é a causa de o título genérico nunca ter incomodado ninguém: não havia onde declarar outro | Contrato único para tudo (produziu exatamente o site atual) · tipagem por assunto em vez de por comportamento (assunto muda, comportamento não) |
| MK2 | Toda página declara: um <h1> único e REAL · <title> próprio · meta descrição própria · URL canônica · lang="pt-BR" |
Linha de base: 6 de 22 páginas sem <h1> real, e nenhuma com título ou descrição próprios. Classe de defeito a evitar: capacidade construída e nunca ligada — a classe SetSeo do site atual estava pronta e nunca foi instanciada, o que é pior que não existir, porque parece resolvido |
<h1> simulado por classe CSS (quebra 1.3.1 e a hierarquia de leitura) · título por template genérico |
| MK3 | Toda <img> de conteúdo tem alt descritivo; decorativa tem alt="" EXPLÍCITO |
419 tags, zero alt, e nem a distinção entre conteúdo e decoração sendo feita. O alt="" explícito é o que diz ao leitor de tela "pule isto de propósito" — omitir o atributo faz o leitor tentar adivinhar pelo nome do arquivo |
alt opcional · alt gerado do nome do arquivo |
| MK4 | Zoom NUNCA é bloqueado. maximum-scale e user-scalable=no são proibidos |
Está no ar hoje em todas as páginas, e o público massivo é celular. Bloquear zoom não é preferência estética: é impedir alguém de ler | — (não há caso legítimo) |
| MK5 | Toda região de navegação é <nav> com nome acessível único, e o nome não contém a palavra "navegação" |
Zero <nav> no site inteiro. Herda o SH2 do §46 sem alteração — a página institucional tem cabeçalho, mega menu, trilha e rodapé, todos navegação |
div/ul genérico · nav anônimo |
| MK6 | Cabeçalho institucional em TRÊS MODOS: completo (institucional e conteúdo: itens de nível 1 expostos + mega menu) · reduzido (serviço: logo + uma ação primária + gatilho do mega menu, sem os itens de nível 1 expostos) · mínimo (utilitária: logo e saída) | Resolve um conflito medido. Página sem barra de navegação converte até 2× mais em teste controlado, e a recomendação de mercado é remover a navegação da página de conversão. Mas a página de serviço precisa pertencer ao site — é isso que evita manter landing pages paralelas, que é o requisito do Rafael. O modo reduzido mantém a navegação a um toque sem competir com o CTA | Remover a navegação (a página deixa de pertencer ao site e você mantém duas coisas) · cabeçalho completo na página de serviço (paga o custo de conversão sem necessidade) |
| MK7 | Mega menu: disclosure de links, nunca role="menu". Máximo 2 colunas, cada grupo com título próprio, imagem opcional por item |
O MN1 já decidiu a fronteira semântica das quatro saídas, e o §46 já consome a saída disclosure. O teto de 2 colunas vem do inventário: o mega menu atual usa 3 grupos, e o único com 2 colunas é "soluções" — que é o caso real de agrupamento duplo (técnicas + fotovoltaico por segmento) | role="menu" (anti-padrão testado, corpus Roselli/APG) · 3+ colunas (o inventário não sustenta a necessidade) |
| MK8 | PÁGINA DE SERVIÇO AUTÔNOMA, em cinco movimentos: conversão → dor → prova → escopo → conversão. Precisa se sustentar para quem cai de anúncio, sem contexto anterior. Um sinal mínimo de prova acompanha o CTA de topo — um número, não parede de logos. O formulário existe UMA VEZ; o CTA do fim é âncora que leva até ele | Sequência definida pelo Rafael. Dor → prova → escopo é PAS (problema, agitação, solução), o mesmo framework que a skill seed-ds-mensagem já usa; a conversão vem antes porque quem chega de tráfego pago já está no meio do PAS — fazer essa pessoa rolar para achar o formulário friciona quem já está pronto, e quem não está rola e encontra a explicação. O sinal de prova no topo tem número: contagem de clientes nomeada acima da dobra produziu +22%, o maior ganho de qualquer formato de prova testado. Formulário único porque duplicá-lo cria duas fontes de verdade, duas medições e o erro clássico de a pessoa preencher o de baixo depois que o de cima já falhou |
Dor → prova → escopo → conversão (minha proposta inicial: friciona quem já decidiu) · dois formulários na mesma página · parede de logos e metodologia no topo |
| MK9 | Variante de PÚBLICO dentro da página de serviço, não página duplicada. No fotovoltaico o recorte é por SEGMENTO — casa, comércio, indústria, área rural | Achado do estudo: o site atual já resolve exatamente assim, com quatro páginas por segmento. Segmento é mais operacional que "B2B/B2C" — o visitante se reconhece em "na minha indústria", não em "sou B2B" | Duas páginas B2B/B2C do mesmo serviço (competem entre si no buscador e dobram a manutenção) · uma página tentando falar com os dois ao mesmo tempo |
| MK10 | Dados estruturados por TIPO de página: Organization na home e na institucional · Service em cada página de serviço, com serviceType, areaServed e provider apontando para a Organization · BreadcrumbList onde há trilha · FAQPage só onde há FAQ real e visível |
O schema.org tem o tipo Service exatamente para isto, e página de serviço é onde a maioria subimplementa. A regra do Google é dura: nunca marcar conteúdo que não está visível ao usuário — marcação fabricada é pior que marcação ausente |
LocalBusiness em toda página (dilui o sinal de entidade) · FAQPage sem FAQ visível na página |
| MK11 | areaServed declara MG, ES e BA. A marcação nunca afirma sede onde não há |
A orientação é explícita: um negócio não deve fingir ter instalações de onde não opera de fato. A SEED atende três estados a partir de duas bases | Uma LocalBusiness por município atendido (fabricaria presença física e é o erro mais comum de marcação local) |
| MK12 | Orçamento de peso por página, MEDIDO no gate: HTML < 50KB · CSS < 60KB · JS < 150KB comprimido · imagens acima da dobra < 200KB. Metas de campo: LCP < 2,5s · INP < 200ms · CLS < 0,1. Toda imagem, vídeo e iframe com dimensão explícita | Orçamento de referência para mobile, e as metas são os limiares de "bom" avaliados no percentil 75 de usuários reais. Dimensão explícita é o que impede o deslocamento de layout. Linha de base: esqueleto fixo de 2,5 MB e páginas de até 8,8 MB de mídia | Orçamento aspiracional sem medição no gate (não é orçamento, é desejo) |
47.3 Anatomia e fronteiras#
Cabeçalho: herda a zona de identidade/ações do SH10 (§46), mas não é o shell de aplicação
— não há rail nem sidebar contextual. Rodapé: navegação secundária em <nav> nomeado,
identificação da empresa e links legais; é o lugar canônico do que não merece o cabeçalho.
Conteúdo: um <main> por página, com tabindex="-1" se houver troca de rota sem recarga
(herda o SH7). Skip link como primeiro focável (herda o SH8).
Nenhum par de cor novo — o lote 1 é esqueleto e camada de máquina; a cor entra com os blocos de conteúdo, no lote 2, e é lá que a medição de contraste tem objeto.
Fora do escopo deste lote, declarado: hero, prova social, números, card de solução,
depoimento, case em vídeo, FAQ e bloco de contato (lote 2) · copy de qualquer página
(projeto do site) · quais serviços ganham página e o que o formulário pergunta (projeto do
site) · escolha de plataforma e de framework (projeto do site) · llms.txt, robots
liberando rastreadores de IA, presença no índice Bing e validação de pré-renderização (Fase
8, ver a precisão de fronteira abaixo) · dívida do site atual (fora de escopo por decisão).
PRECISÃO DE FRONTEIRA COM A FASE 8, aprovada pelo Rafael em 2026-08-12. O
seed-ds-roadmap.mdcolocava toda a camada GEO na F8. Cumprir isso ao pé da letra faria o 6B escrever os padrões de página sem a camada de máquina — e o site novo poderia ser construído antes da F8, repetindo o defeito que o estudo acabou de medir. A divisão fica: o que é CONTRATO DE PÁGINA vem para o 6B (título, descrição, canônica, dados estruturados daquela página, orçamento de peso); o que é PUBLICAÇÃO E DESCOBERTA fica na F8 (llms.txt,robotspara rastreadores de IA, índice Bing, site do DS, validação de pré-renderização). Não é supersede: nenhuma decisão da F8 deixa de valer — o 6B diz o que toda página tem, a F8 diz como o conjunto é publicado.
47.5 Lote 2 — blocos de conteúdo · MK13–MK22#
(decisão registrada — ver Histórico da seção)
| # | Decisão | Porquê | Descartado |
|---|---|---|---|
| MK13 | HERO: um <h1> real, uma promessa, um CTA, um visual. Ficam fora do hero: história da empresa, parede de logos e metodologia |
O essencial precisa caber numa tela, no desktop e no celular. O hero é a única região onde a regra do um (§1.12) vale para tudo ao mesmo tempo | Carrossel de hero (o visitante vê um slide e vai embora; os demais são custo sem leitura) · dois CTAs concorrentes |
| MK14 | PROVA SOCIAL EM DOIS NÍVEIS: mínima no topo — um número nomeado, junto ao CTA — e completa abaixo (logos, depoimentos, cases) | Contagem de clientes nomeada acima da dobra produziu +22%, o maior ganho entre os formatos de prova testados. Parede de logos no topo não converte e ainda rouba a atenção do CTA | Prova só no fim da página · parede de logos acima da dobra · prova genérica ("milhares de clientes") |
| MK15 | NÚMEROS declaram fonte e data. Número sem procedência não entra na página | O site atual afirma números que o banco de dados não sustenta: a tabela de depoimentos está vazia e o portfólio é 100% dado de demonstração (estudo-site-atual.md). Numa página de engenharia, número inventado é risco de responsabilidade, não enfeite |
Números redondos sem origem · número atualizado à mão sem data (envelhece em silêncio) |
| MK16 | CARD DE SOLUÇÃO: título + uma linha de dor + link-com-seta. Não é mini-anúncio; é uma porta | Herda o A10 do estudo-viver-de-ia.md (link-com-seta como terceiro nível de ação, abaixo de primário e secundário). Card com botão compete com o CTA da página e dilui o único objetivo dela |
Card com botão primário · card com parágrafo (vira página dentro da página) |
| MK17 | DEPOIMENTO exige atribuição: nome, cargo e empresa. Sem os três, é texto, não prova. Depoimento nunca é gerado nem ilustrativo | O site no ar hoje exibe depoimentos que são copy de exemplo do CMS. Em B2B, depoimento anônimo tem valor negativo: sinaliza que não houve autorização, e o leitor lê isso | Só o primeiro nome · avatar genérico de banco de imagens · depoimento sem empresa |
| MK18 | CASE É PEÇA ENDEREÇÁVEL: página própria no domínio da SEED, com título, cliente, solução, resultado e vídeo | Requisito do Rafael: mandar o link do case direto ao cliente na conversa. Link do domínio da SEED constrói a autoridade da SEED; link do YouTube constrói a do YouTube. E case sem endereço próprio não é enviável | Case como item de lista sem âncora (não dá para mandar o link) · enviar o link do YouTube |
| MK19 | VÍDEO POR PADRÃO FACHADA, COM MEDIÇÃO — E NEUTRO EM FORNECEDOR. Contrato de quatro cláusulas: (a) miniatura estática + botão de play, e nada de terceiro carrega antes do clique; (b) ao carregar, o player emite início e marcos de 25/50/75/100%; (c) a página que hospeda o bloco vive no domínio da SEED (MK18); (d) se o fornecedor exibir sugestões ao fim da reprodução, elas ficam restritas ao próprio canal da SEED — e, quando o fornecedor não permitir sequer isso, o bloco declara a limitação em vez de fingir que a controla. O Design System NÃO escolhe fornecedor de vídeo | A incorporação padrão custa centenas de KB de JavaScript, abre várias conexões e disputa a linha principal mesmo que ninguém clique; o loading="lazy" nativo apenas adia o custo. A fachada carrega ~224× mais rápido e é a recomendação explícita do Lighthouse. A medição não briga com a fachada: só quem clica é medível de qualquer forma, então adiar o player não perde dado nenhum. Neutralidade de fornecedor decidida pelo Rafael em 2026-08-12: quem serve o arquivo — YouTube, hospedagem dedicada de plataforma de curso, ou servidor próprio — é decisão de produto, revisável sem tocar no padrão. O que o DS garante é o comportamento na página. Sobre a atribuição por pessoa, que parecia depender do fornecedor: não depende — como a página é da SEED e o colaborador está autenticado nela, a página atribui o progresso; o player só precisa emitir os eventos |
Incorporação direta · loading="lazy" como solução (adia, não elimina) · fachada sem API (seria performance sem medição, e o requisito é medir) · exigir hospedagem dedicada (resolveria os relacionados e os cookies, mas amarra o padrão a uma mensalidade e a um fornecedor, para um ganho que o caso da SEED não pede) · proibir o YouTube (custo zero e medição atendida; o único preço real é a grade de sugestões do próprio canal) |
| MK20 | FAQ: accordion §29, perguntas reais, com FAQPage marcado — pela CAMADA DE MÁQUINA, não pelo Google |
Os resultados ricos de FAQ deixaram de aparecer no Google em 7 de maio de 2026, inclusive para os sites de governo e saúde que eram a última exceção desde 2023. A marcação continua válida e segue sendo lida por Bingbot — cuja base alimenta a busca do ChatGPT e o Copilot —, pelo PerplexityBot e por indexadores de assistente de voz. Para uma empresa que quer ser citada quando alguém pergunta a um modelo sobre subestação em Minas, isso vale mais que o dropdown que morreu. Vale a regra do lote 1: só com FAQ visível na página | FAQ inventada para render marcação (foi o abuso que matou o recurso) · remover a marcação porque o dropdown acabou (confunde recurso de busca com leitura de máquina) |
| MK21 | BLOCO DE CONTATO POR SERVIÇO, dentro da página, com o mínimo de campos que qualifica. É o único formulário da página (MK8) | Cada campo a mais reduz conversão, mas o caso da SEED pede qualificação — então o mínimo é por serviço, não universal. Um formulário de fotovoltaico residencial e um de subestação não perguntam a mesma coisa | Formulário universal (não qualifica) · formulário em página separada (perde a intenção no caminho) · dois formulários na mesma página |
| MK22 | O BLOCO DE VÍDEO É O MESMO no site e na plataforma de treinamento interna. Um contrato, dois consumidores: página de case (externo) e aula (interno) — mesma fachada, mesmos eventos, mesma medição | O Rafael descreveu os dois usos na mesma frase, e são o mesmo objeto: vídeo empacotado no domínio da SEED, com progresso medido. Dois componentes divergiriam em seis meses e mediriam diferente, o que impede comparar | Player próprio para o treinamento (duplica manutenção e cria duas medições incomparáveis) |
| MK23 | O CONSUMIDOR DE IA É QUALQUER AGENTE. Toda página, instrução de uso, pacote ou índice publicado para IA (a) nomeia como audiência "qualquer IA" — nunca um fornecedor ("para o Claude", "para o ChatGPT"); (b) oferece PRIMEIRO o caminho por endereço público (a URL que o agente lê sem instalar nada) e só depois os caminhos por arquivo (zip, pasta, skill instalada), um por tipo de IA; (c) a checagem de fechamento tem quatro verbos — achar, ler, citar e USAR — e roda ANTES de mostrar ao decisor, nunca depois que ele pede | A regra canônica da casa ("~50% das pesquisas são feitas por IA") não escolhe fornecedor. A página /skill/ nasceu em 2026-09-06 escrita "para quem produz com o Claude": camada de máquina certa (MK1–MK12 passavam), consumidor errado — a ferramenta da sessão virou o público sem ninguém decidir isso, e o decisor teve de pedir (MANIFESTO §176). Guarda: consumidor_unico.py (VT-13 na vitrine e no llms.txt, SK-11 na skill) acusa a forma errada |
Página ou pacote "para o Claude" · instalação como único caminho (IA com web não instala nada) · checagem só de achar/ler/citar (passa com o público errado) |
ERRATA MK-E1 — contra o racional do MK10, no lote 1. O MK10 mandou marcar
FAQPagesem dizer para quê, e a suposição implícita era o resultado rico do Google — que não existe mais desde 7 de maio de 2026. A decisão permanece; o racional muda: a marcação serve à camada de máquina (Bing, e por consequência a busca do ChatGPT e o Copilot; Perplexity; indexadores de assistente), não à aparência na busca do Google. Classe de defeito: decisão certa pelo motivo errado — sobrevive ao teste enquanto o motivo não é questionado, e cai junto com ele. Parente da E19 da Fase 5 (regra herdada de outro consumidor sem remedir o contexto).
FRONTEIRA DE LGPD, declarada — MK19 e MK22. Medir o que um cliente assistiu e medir o que um colaborador assistiu são coisas juridicamente diferentes: a segunda é monitoramento de pessoa identificada em relação de trabalho, e exige base legal, transparência com o colaborador e finalidade declarada. O Design System declara o MECANISMO — o bloco de vídeo expõe os eventos de progresso. O que se coleta, de quem, por quanto tempo e para quê é decisão de produto e de conformidade, nunca de padrão. É a mesma separação que o DP12 fez no mapa entre destino externo e interno.
47.4 Os 7 testes#
- Nenhum par de cor novo neste lote; a medição de contraste tem objeto no lote 2.
- Escada de mecanismos: item ativo do cabeçalho por marca + peso +
aria-current, nunca só cor (herda o SH5). - Grayscale: cabeçalho, trilha e estado ativo permanecem legíveis (DF4 como gate estrutural).
- Regra do um: um
<h1>real por página · um<main>· um formulário por página de serviço · um item ativo por região de navegação. - Landmarks: todas as navegações com nome único, nenhum contendo a palavra "navegação" (MK5/SH2).
- Camada de máquina: título, descrição e canônica próprios; dados estruturados do tipo certo e só do que está visível; nada de marcação fabricada (MK10).
- Mobile primeiro, medido: zoom livre (MK4) · alvos ≥44px · orçamento de peso e metas de campo verificados no gate (MK12) · dimensão explícita em toda mídia · nenhuma incorporação de terceiro carrega antes do clique (MK19) · nenhum número, depoimento ou case sem procedência (MK15, MK17) — este último é teste documental, não visual, e reprova a página que afirma sem poder sustentar.
(Estado: estável desde 2026-08-12, por "aprovo" explícito do Rafael após o gate visual.
Quatro camadas cumpridas em 2026-08-12 sobre o preview
seed-site-preview.html v0.1, que exercita o contrato numa página de serviço — o tipo mais
exigente, por ser autônoma: suite-site.mjs 66 PASS · 0 FAIL — prova de que as guardas são
reais: contra um preview com 5 defeitos deliberados (zoom bloqueado, LocalBusiness no lugar de
Service, número sem fonte, player sem API, nav sem nome) ela reprova em 6;
render-site.mjs em Chrome real 23 PASS · 0 FAIL, medindo CTA acima da dobra em três
larguras, alvos de toque e — o teste que só o render faz — zero requisições externas antes de
qualquer clique, com o iframe aparecendo apenas após o clique na fachada; contraste-site.py
42 PASS · 0 FAIL após as correções que a própria medição exigiu; e o gate visual humano.
Pendência que o bloco leva consigo: nenhuma própria — a SH-P1 do §46 (falta de token
semântico de borda que passe 3:1 contra surface-raised no claro) valia aqui também, porque
o campo de formulário do §47 consumia o mesmo empréstimo de primitivo. Com a SH-P1 fechada
(gêmeos v1.12, 2026-08-14), o §47 tem o semântico --seed-border-interactive à disposição —
a migração do artefato do §47 é retroativo da classe PN-P7 (o preview do site não foi
regenerado nesta janela; regra GI2 vale para quando for).
✅ O retroativo FECHOU em 2026-08-15 (PN-P7 executado, MANIFESTO v7.6; aprovado pelo Rafael
na v7.7): o seed-site-preview.html foi a v0.2 com input, select, textarea consumindo o
semântico — e a prova em pixel mediu 0,00% de diferença contra o artefato anterior
(mesmo valor renderizado #788F9D: promoção de expressão, não de cor). Suíte 66·0 · render
23·0 · contraste 42·0 contra o artefato final.)
O que a medição de contraste corrigiu, e a lição é reaproveitável. A primeira execução deu 39 PASS · 3 FAIL, todas no tema escuro e todas pela mesma causa: eu havia usado
surface-brand-deepcomo cor de TEXTO (item ativo do mega menu, link-com-seta, marca). Ele é superfície: no tema escuro vira um verde quase preto e mede 1,99 contra a página. A correção é consumirtext-linkpara texto de marca (4,60 no claro · 10,16 no escuro) etext-brandpara a barra do depoimento (4,23 · 9,32;surface-brandmedia 2,50 no claro). Classe de defeito: token usado fora do papel declarado — o nomebrand-deepsugere "a versão escura da marca", e a leitura natural é que sirva para texto; o papel dele é superfície. Parente do SH15 do §46, ondesurface-inverseinvertia com o tema.
47.6 O pacote GEO do site institucional — MK24 a MK28 (novo na v1.46, F9.4)#
O que é este bloco, para quem nunca viu o projeto. "GEO" aqui é generative engine optimization: o conjunto de arquivos e marcações que fazem um site ser achado, lido e citado por sistemas de IA — não só pelo buscador clássico. O DS especifica o pacote; quem aplica é o projeto do site (decisão dele no gate de abertura da F9, Q6: "o DS entrega; o projeto do site aplica"). Este bloco é a especificação, e vale para qualquer site da casa, não só o institucional.
A linha de base MEDIDA em 2026-09-09, no site novo (novo.seed.eng.br), para que ninguém refaça o
que já existe: robots.txt com Sitemap: declarado · llms.txt de 5 KB com H1 e resumo ·
sitemap.xml com 22 URLs · JSON-LD WebSite + Organization na home, com 3 subOrganization e
areaServed = Minas Gerais, Espírito Santo e Bahia · Organization em 15 páginas e Service em 11
páginas de serviço. O que faltava, medido no mesmo varrimento: 7 páginas sem JSON-LD nenhum
(/artigos, /podcasts, /politica-de-privacidade, /portifolio, /videos e as 2 páginas de tag),
nenhum BreadcrumbList em nenhuma página, nenhum robô de IA nomeado no robots.txt e
IndexNow não implantado.
MK24 — a política de robôs é ESCRITA, nomeando cada robô, e datada#
Disallow: vazio para User-agent: * libera tudo, mas não é política: ninguém consegue auditar o
que a casa decidiu, e a decisão desaparece na primeira dúvida. O robots.txt de site institucional da
SEED nomeia os robôs em dois grupos, com a função de cada um, porque a decisão de negócio é
diferente para cada grupo:
- treino de modelo —
GPTBot(OpenAI) ·ClaudeBot(Anthropic) ·Google-Extended·CCBot·Applebot-Extended·Meta-ExternalAgent; - busca e ação de pessoa —
OAI-SearchBoteChatGPT-User(OpenAI) ·Claude-SearchBoteClaude-User(Anthropic) ·PerplexityBotePerplexity-User; - outros —
OAI-AdsBot(OpenAI), que valida a segurança de páginas submetidas como anúncio.
Padrão da casa para material institucional: LIBERAR os dois grupos, porque o objetivo do site é ser
citado. Bloquear o OAI-SearchBot tira o site das respostas da busca do ChatGPT; bloquear os de ação
de pessoa não adianta muito, porque eles podem ignorar o robots.txt. Mudar essa política é decisão de
negócio dele, e vai ao gate com os dois arquivos renderizados lado a lado.
⚠ A lista acima tem data: os nomes foram lidos nas páginas oficiais em 2026-09-09 —
https://developers.openai.com/api/docs/bots e
https://support.claude.com/en/articles/8896518-.... Ela muda: nesta leitura apareceu o
OAI-AdsBot, que não existia na lista que a casa tinha escrito quatro dias antes, e as duas páginas
mudaram de endereço (redirecionaram de platform.openai.com e de support.anthropic.com). Regra:
reler as páginas oficiais antes de aplicar o pacote, e datar a leitura no arquivo gerado.
E o robots.txt sempre declara o Sitemap: — é o caminho mais barato de descoberta que existe.
robots.txt não é proteção: o que não pode ser lido por robô não fica público, e dado pessoal
(LGPD) nunca chega à superfície que eles varrem.
MK25 — JSON-LD por TIPO de página, e nenhuma página fica sem#
| tipo de página | o que leva | regra |
|---|---|---|
| home / institucional | Organization (+ WebSite) |
uma vez, com areaServed e as unidades reais em subOrganization |
| serviço | Service com serviceType, areaServed e provider |
um por página de serviço |
| qualquer página com trilha | BreadcrumbList |
espelha a trilha visível, na mesma ordem |
| artigo / post | Article com headline, datePublished, author |
o headline tem de ser o <h1> visível |
| listagem (artigos, vídeos, podcasts) | CollectionPage + ItemList dos itens exibidos |
nunca listar item que não está na página |
| FAQ | FAQPage |
só onde há FAQ real e visível |
Nenhuma página do sitemap fica sem JSON-LD — a página sem marcação é a que o agente não consegue citar. E nunca se marca o que não está visível ao usuário: marcação fabricada é pior que ausente (foi o abuso que matou os resultados ricos de FAQ em 2026). Isso já é o MK10; aqui ele ganha a tabela por tipo.
MK26 — o llms.txt do site é gerado, não redigido#
Formato llmstxt.org: # com o nome, um blockquote de resumo, seções ## com listas de links
comentados e uma seção Optional para o secundário. O conteúdo deriva do que o site publica (as
páginas do sitemap, os serviços, os artigos reais), nunca é escrito à mão — texto escrito à mão sobre
uma lista que muda envelhece na primeira publicação. Toda página HTML serve o .md ao lado e declara
rel="alternate" type="text/markdown".
MK27 — descoberta é ATIVA, não só passiva#
Publicar e esperar não é descoberta. O site se cadastra no Bing Webmaster Tools (o índice do Bing é
o que a busca do ChatGPT e o Copilot consomem) e no Google Search Console, e avisa cada mudança por
IndexNow: uma chave hospedada em https://<dominio>/<chave>.txt — o arquivo tem o nome da
própria chave, e não indexnow.txt — mais um POST com a lista de URLs a cada publicação. O passo
entra no script de publicação, não na memória de quem publica.
MK28 — a régua: o pacote se confere MEDINDO o site servido#
O pacote não está aplicado porque alguém marcou uma caixa. A conferência roda contra a base pública
e mede, nesta ordem: (1) robots.txt, llms.txt e sitemap.xml respondem 200 e não devolvem HTML
— um servidor que responde a tudo com a página inicial devolve 200 para arquivos que não existem; (2)
para cada URL do sitemap, quais tipos de JSON-LD a página traz, com a lista das que não trazem
nenhum; (3) todo name/headline marcado aparece no texto visível; (4) a chave do IndexNow responde
200. A saída é um placar com denominador ("22 de 22 URLs medidas · 15 com Organization · 7 sem
JSON-LD"), nunca um "ok".
⚠ E a primeira coisa que a régua mede é o DOMÍNIO CERTO. Em 2026-09-09 a medição do pacote foi
feita primeiro em seed.eng.br e devolveu um retrato absurdo — llms.txt respondendo HTML,
sitemap com zero URLs, nenhum JSON-LD: naquele dia o domínio principal ainda servia o site
antigo, e o site novo vivia em novo.seed.eng.br. Medir a camada de máquina no endereço errado
produz um diagnóstico inteiramente falso, nas duas direções — e é por isso que a régua começa pelo
domínio.
✅ Aquele retrato durou um dia — e o registro dele fica como história, não como estado. Medido em
2026-09-10: https://seed.eng.br/ e https://novo.seed.eng.br/ devolvem bytes idênticos (MD5
a006e3ed173f7bdf0e1eeedae05a7dbf), com o <title> na grafia canônica "SEED engenharia"; no domínio
principal o robots.txt responde 200 em text/plain, o llms.txt tem 5.060 bytes, o
sitemap.xml traz 22 URLs e a home carrega 2 blocos de JSON-LD. E a camada de máquina aponta
para o endereço certo: os 21 links do llms.txt, as 22 URLs do sitemap e a canônica da home
citam todos https://seed.eng.br — nenhum sobrou apontando para o host secundário. A troca não foi
feita por esta sessão. Fica a regra que este parágrafo existe para ensinar: afirmação de estado tem
data, e esta envelheceu em vinte e quatro horas — quem for medir o pacote remede o domínio antes de
concluir qualquer coisa, em vez de acreditar nesta linha.
47.7 A barra de acessibilidade — MK29 (PB-P9, 2026-09-15)#
Por que existe. A Lei nº 13.146/2015 (LBI), art. 63, § 1º — texto lido no Planalto em 2026-09-15 —
manda, verbatim: "Os sítios devem conter símbolo de acessibilidade em destaque." A lei não define "em
destaque" nem nomeia o símbolo; o único símbolo que o ordenamento reconhece é o Símbolo Internacional de
Acesso (SIA, 1968 — ISO 7001 PI PF 006; ABNT NBR 9050:2020, 5.3.2; Anexo da Lei 7.405/1985; a Lei 15.459, de
7/7/2026, tentou trocá-lo e o desenho novo foi VETADO — Mensagem 586/2026). A prática do governo federal (eMAG
3.1, itens 4.1 e 4.3, lidos em 2026-09-15; gov.br medido no HTML servido no mesmo dia) é uma barra no topo de
toda página com link "Acessibilidade", atalhos de teclado e contraste. Veredito dele no gate do Grupo 2
(MANIFESTO §226.1), verbatim: "V-PB9.1 onde: b · V-PB9.2 arte: ambos · V-PB9.3 site: não" — (b) é a barra.
MK29 — toda página da vitrine do DS abre com a barra de acesso rápido, e ela tem esta forma:
| o quê | a regra | medido (2026-09-15) |
|---|---|---|
| posição no DOM | <nav class="barra-a11y" aria-label="Acesso rápido"> vem depois do skip link (SH8 do §46: .pular continua o PRIMEIRO focável) e antes do <header>; rola com a página, o cabeçalho continua fixo |
Tab 1 → .pular, Tab 2 → link Acessibilidade, nas 4 cenas |
| o símbolo | o arquivo INTEIRO de 03-assets/acessibilidade/simbolo-internacional-de-acesso.svg (com o campo azul; nunca recolorido com token, nunca espelhado), 20 px, alt="", dentro do <a href="/acessibilidade/"> cujo texto visível é "Acessibilidade" — o nome acessível é o texto, o alt vazio evita a palavra duas vezes |
campo #0A94D5 × surface-subtle: 3,11 : 1 claro · 5,05 : 1 escuro (SC 1.4.11, piso 3 : 1). Sobre surface-brand-* o azul mede 1,87 — ali só a forma -mono-positivo |
| os atalhos | quatro links visíveis, SEM accesskey e SEM número: Conteúdo · Menu · Busca · Rodapé (revisão de 2026-10-10, F1a = b; a versão de 2026-09-15 numerava 1–4 pela eMAG 3.1 §4.1). Cada atalho aponta para um id que EXISTE em toda página e RECEBE foco (tabindex="-1" em #conteudo, #nav-principal, #rodape); o da busca é um <button aria-haspopup="dialog" aria-controls="paleta"> porque a busca só existe com script — nenhum atalho sem alvo |
Enter/clique nos 4: foco em conteudo, nav-principal, rodape; a paleta abre e o foco cai no campo (1440 e 390) — medido em 2026-09-15 com a barra numerada, a mesma ação |
| o nome de cada atalho | prefixo só para leitor de tela (<span class="so-leitor">Ir para o </span>Conteúdo), como o gov.br faz; sem <kbd> |
nome acessível "Ir para o Conteúdo" |
por que NÃO há accesskey |
a combinação de teclas muda por navegador (Alt no Chrome/Edge/Opera para Windows · Alt + Shift no Firefox · Control + Option no Mac — MDN) e colide com atalhos do leitor de tela e do navegador: o MDN diz que "it is generally advised not to use accesskeys for most general-purpose websites" e o WebAIM, que "the accesskey attribute should typically be avoided" (ambos lidos em 2026-10-10). A WCAG 2.2 SC 2.1.4 não cobre accesskey: o risco é de uso, não de conformidade. Ficam o skip link (SH8) e a tecla Tab |
— |
| cor e tipografia | fundo surface-subtle, tinta text-secondary (fs-small), o link Acessibilidade em text-primary semibold; só tokens semânticos |
texto × barra 7,13 claro · 9,10 escuro (SC 1.4.3) |
| custo | altura 33 px a 1440 e 58 px a 390 (duas linhas); scrollWidth = viewport em todas as páginas do sitemap |
361 de 361 páginas a 390, 1366 e 1440 (guarda RL) |
a página /acessibilidade/ |
explica o símbolo (a lei, o SIA de 1968, o veto de 2026, a procedência do vetor e a troca prevista) e lista os quatro atalhos e diz que não há tecla de atalho (eMAG 3.1 §4.5) | seção "Atalhos de navegação" na página e no .md |
| onde vale | a vitrine ds.seed.eng.br (toda página do gen-vitrine.py). O site institucional seed.eng.br NÃO herda — "V-PB9.3 site: não"; a decisão de lá é do projeto do site |
— |
| a arte | "V-PB9.2 arte: ambos": publica com o vetor da Wikimedia Commons (domínio público; IoU 0,548 contra a Figura 35 da norma — 03-assets/acessibilidade/LEIA-ME.md) e troca pelo vetor oficial da ISO 7001 quando adquirido, no gen-sia.py, sem tocar a casca |
— |
| a régua | VT-16 da guarda-vitrine.py: uma barra por página, na ordem certa; símbolo inteiro com alt="" no link; NENHUM accesskey e nenhum <kbd> na barra, 3 links #alvo + o botão da busca, cada um com alvo existente; /acessibilidade/ cita a lei e descreve os atalhos |
362 de 362 páginas; a cobaia (árvore sem a barra) reprova 0 de 362 |
O que NÃO está medido, dito na cara: a ativação por teclado REAL dos quatro links (Tab + Enter) num leitor de tela; mediu-se o foco e a paleta por Enter e por clique. O accesskey foi retirado porque nunca foi medido por teclado real (Playwright não o honra, cobaia de 2026-09-15) e porque MDN e WebAIM mandam evitá-lo.
Revisão de 2026-10-10 (MK29 revisada). Resposta dele na folha 2 de 2026-10-10 (gravada 11:22Z): F1a = b (a barra fica sem accesskey, com os links visíveis Conteúdo, Menu, Busca e Rodapé, sem tecla nem número; o texto acima é a síntese da leva 31, a escolha "b" é dele). Substitui a parte "aplicação da sessão, exposta a veto" do accesskey da versão de 2026-09-15. Alto contraste e A-/A+ seguem FORA da barra (sem novo veredito).
O que NÃO entra na barra: o alto contraste do eMAG §4.2 (folha 7 : 1 preto/branco/amarelo) — a casa tem tema claro/escuro por token (BT5, §64.1) no botão ◐ do cabeçalho, que fica onde está; um segundo interruptor na barra seria dois controles para o mesmo estado. Se um dia houver "alto contraste" de verdade, ele nasce como tema, e aí entra na barra. Aplicação da sessão, exposta a veto.
47.8 O aviso de cookies — MK30 (pedidos PC-2026-0071 e PC-2026-0092; TQ4, 2026-10-18)#
Por que existe. O site público pediu um aviso de cookies (cartão + painel de preferências) e o canon não tinha a regra (a única menção a "cookie" neste arquivo era o MK19, do vídeo). Os dois pedidos perguntam o mesmo: o "Aceitar" pode ter mais destaque que o "Recusar"? O Guia Orientativo de Cookies e Proteção de Dados Pessoais da ANPD (Autoridade Nacional de Proteção de Dados) diz que não, em uma de suas práticas desaconselhadas. A decisão abaixo é dele.
Veredito dele (folha 11, 2026-10-18 18:56Z), verbatim: TQ4 = "b" — "manter o destaque no Aceitar como padrão do DS, com o risco escrito na regra — ≈ 2 h; a regra recomendaria o que o guia desaconselha".
MK30 — o aviso de cookies do site tem esta forma:
| o quê | a regra |
|---|---|
| "Aceitar" | destaque de ação primária: é o botão primário do §01 (um único primário no grupo, como o §01 já manda). É a escolha dele no TQ4. |
| "Recusar" | visível, alcançável e no mesmo nível de navegação, nunca escondido. Fica na PRIMEIRA camada do aviso (a que aparece sem clique), na mesma linha ou grupo de botões do "Aceitar", como botão de verdade (botão secundário do §01), e não como link de texto miúdo, nem dentro do painel de preferências, nem atrás de "Gerenciar". Entra na ordem de Tab junto dos outros botões do grupo, sem passo extra. Rejeitar custa o mesmo número de cliques que aceitar (1). |
| o que "destaque" quer dizer aqui | só a hierarquia visual do §01 (primário × secundário). Não vale esconder, reduzir, cinzar, atrasar nem tirar do foco o "Recusar": o texto do "Recusar" mantém o contraste de texto e o limite do botão mantém o contraste de componente do §01 (WCAG 1.4.3 e 1.4.11), e a área de toque é a mesma do "Aceitar". |
| rótulos | cada botão diz o que faz: "Aceitar" e "Recusar" (o guia usa "Rejeitar cookies não necessários", p. 36); nunca "OK", "Entendi" ou "Continuar" como única saída. |
| preferências | botão ou link "Preferências" visível na primeira camada; o painel abre com os cookies NÃO necessários desligados por padrão (prática listada como desaconselhada no guia, p. 33, quando ligados). |
| não é modal | o aviso não bloqueia a leitura nem a navegação enquanto a pessoa não responde [decisão da sessão, exposta a veto]: o pedido PC-2026-0071 propôs cartão flutuante não modal; o veredito dele não tratou disso. |
RISCO ACEITO, ESCRITO NA REGRA (TQ4 = b, decisão dele em 2026-10-18). O Guia Orientativo de Cookies e Proteção de Dados Pessoais da ANPD (versão de out/2022; PDF no portal gov.br, p. 33) lista entre as práticas desaconselhadas em banners de cookies: "Dificultar a visualização ou compreensão dos botões de rejeitar cookies ou de configurar cookies, e conferir maior destaque apenas ao botão de aceite". O guia mostra, na p. 22, um banner com as opções "todas com o mesmo formato e destaque". Esta regra recomenda o destaque de ação primária no "Aceitar", o que o guia desaconselha. O que a regra faz para reduzir o risco: o "Recusar" é botão visível na mesma camada, com a mesma área de toque, o mesmo contraste mínimo e o mesmo número de cliques. O que a regra NÃO elimina: a leitura da ANPD de que "maior destaque apenas ao aceite" é prática a evitar; o risco jurídico é dele (decisor). Revisar quando houver parecer da encarregada (DPO, Encarregado pelo Tratamento de Dados Pessoais). Quando o parecer chegar, esta regra é revisada no mesmo dia: se ele pedir simetria, "Aceitar" e "Recusar" passam a ter o mesmo peso (opção
ada folha 11, ≈ 2 h).
Fonte do guia, lida em 2026-10-18 19:09Z: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia-orientativo-cookies-e-protecao-de-dados-pessoais.pdf (portal da ANPD, criado em 18/10/2022 e modificado em 23/01/2025 segundo a própria página; PDF de 40 páginas, md5 4a9ff9d236295e993fb0a7ccb552c012). A citação do pedido ("dar maior destaque apenas ao botão de aceite") difere do texto do guia, que diz "conferir maior destaque apenas ao botão de aceite"; a página confere (p. 33).
O que o MK30 NÃO decide (continuam abertos nos pedidos): o botão "destaque de marca" com estados próprios de hover e pressionado sobre surface.brand (PC-2026-0092 a); o par de cores do interruptor desligado no tema escuro, hoje 2,80:1 (PC-2026-0092 b); o interruptor × checkbox com botão "Salvar opções" (PC-2026-0071 b); o anel de foco (PC-2026-0071 d). Não há bancada nem peça do aviso de cookies no repositório (medido em 2026-10-18: nenhuma ocorrência de "cookie" em 05-html-de-referencia/ além do domínio youtube-nocookie do vídeo, e em nenhum gerador); a conferência da peça fica para quando ela nascer.