47. Página institucional — esqueleto, camada de máquina e blocos de conteúdo

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.md serve como inventário de conteúdo e diagnóstico de padrão a não repetir — não como lista de correções.

Base (3 rodadas encadeadas, 2026-08-12): R1 canon interno — o §46 inteiro (SH2 landmarks nomeados, SH5 ativo que sobrevive ao grayscale, SH7 foco na troca de rota, SH8 skip link) migra sem alteração; MN1 (navegação é disclosure de links, nunca role="menu"); DF4 (grayscale como gate estrutural); o pacote mobile v1.2; e o estudo-site-atual.md v1.0 (canônico de referência, ancorado no MANIFESTO.md v2.6), que forneceu a linha de base medida citada nas decisões abaixo. R2 mercado — corpus de página de conversão B2B de 2026: essencial acima da dobra em desktop e mobile, cada seção como mini-ponto de conversão, prova junto do CTA, e o dado incômodo de que página sem barra de navegação converte até 2× mais em teste controlado. R3 normas — schema.org (Organization, LocalBusiness e subtipos, Service com serviceType/areaServed/provider, BreadcrumbList, FAQPage), a regra do Google de nunca marcar o que não está visível ao usuário, o orçamento de peso de referência para mobile e as metas de campo de Core Web Vitals. Consolidado aprovado pelo Rafael em 2026-08-12.

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.

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#

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.md colocava 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, robots para 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#

Escrito em 2026-08-12, depois do lote 1 (MK1–MK12) e com o mesmo princípio: contrato por bloco, composição livre. O que cada bloco diz é do projeto do site; o que ele é está aqui.

Base adicional deste lote (R2/R3, 2026-08-12): corpus de prova social em página de conversão B2B; documentação do Lighthouse e do web.dev sobre o padrão fachada para incorporação de terceiros; comparações de peso de incorporação de vídeo; e a deprecação dos resultados ricos de FAQ pelo Google em 7 de maio de 2026, que trocou o racional de uma decisão do lote 1 (ver a errata no fim desta seção).

ERRATA MK-E1 — contra o racional do MK10, no lote 1. O MK10 mandou marcar FAQPage sem 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).

ERRATA MK-E2 — capacidade AFIRMADA e não VERIFICADA, contra a 1ª redação do MK19. A primeira versão mandava "vídeos relacionados desligados ao fim", com o racional de que a grade final poderia levar o cliente a um concorrente dentro da própria página de case. A capacidade não existe no YouTube: desde 2018 o parâmetro que servia para desligar passou a apenas restringir as sugestões ao mesmo canal — não há como removê-las. O risco real é, portanto, muito menor do que o racional supunha (as sugestões são do canal da SEED, não de concorrentes), mas a spec afirmava um controle que o meio não entrega. O MK19 passou a exigir a restrição ao próprio canal e, onde nem isso for possível, a declaração explícita da limitação. Classe de defeito: capacidade afirmada e não verificada — prima da MK-E1 (decisão certa pelo motivo errado), com a diferença de que aqui o motivo estava certo e o mecanismo é que não existia. Como foi pega: pergunta do Rafael — "por que não podemos usar o YouTube?" — sobre uma proibição que a spec nunca fez, mas que a redação sugeria.

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.

Origem do vídeo do Viver de IA — lacuna FECHADA em 2026-08-12. O estudo-viver-de-ia.md descrevia o player daquela plataforma apenas como interface (§3.19), e a medição de código da v1.2 mirou tokens, tipografia e movimento — nenhum dos dois olhou de onde o vídeo vinha. A lacuna ficou declarada como não respondida, e o Rafael a fechou por medição direta: o menu de contexto do player identifica Panda Video, hospedagem brasileira voltada a plataforma de curso. Isso explica o player com marca própria e sem grade de sugestões ao fim. Consequência para o DS: nenhuma — o MK19 é neutro em fornecedor de propósito. O achado vale como referência do que uma hospedagem dedicada entrega, e está registrado no estudo-viver-de-ia.md.

47.4 Os 7 testes#

1. Nenhum par de cor novo neste lote; a medição de contraste tem objeto no lote 2.
2. Escada de mecanismos: item ativo do cabeçalho por marca + peso + aria-current, nunca só cor (herda o SH5).
3. Grayscale: cabeçalho, trilha e estado ativo permanecem legíveis (DF4 como gate estrutural).
4. 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.
5. Landmarks: todas as navegações com nome único, nenhum contendo a palavra "navegação" (MK5/SH2).
6. 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).
7. 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-deep como 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 é consumir text-link para texto de marca (4,60 no claro · 10,16 no escuro) e text-brand para a barra do depoimento (4,23 · 9,32; surface-brand media 2,50 no claro). Classe de defeito: token usado fora do papel declarado — o nome brand-deep sugere "a versão escura da marca", e a leitura natural é que sirva para texto; o papel dele é superfície. Parente do SH15 do §46, onde surface-inverse invertia com o tema.

---