/* ============================================================================
v2.css — camada de refino do site. Carrega DEPOIS do expan.css.
Nasceu no clone (lab/site-v2) e virou produção em 01/08/2026, quando o
Matheus mandou o clone tomar o lugar do site. Vale na home, nas cinco
páginas de serviço e onde mais o for incluído.
A troca de tipografia foi feita direto nos estilos inline: pelo
.tools/headless/refinar-tipografia.js na home, e pelo tipografia-site.js
nas páginas de serviço. Aqui ficam as coisas que precisam de REGRA nova,
não de substituição: estados que faltavam, alvo de toque no celular e o
freio na animação que competia com o conteúdo.
`!important` não é preguiça: o site inteiro veio de um compilador de
protótipo e mora em `style=""`, que ganha de qualquer seletor de classe. O
expan.css já usa a mesma saída nas 80 regras `.exph-*`.
============================================================================ */
/* ────────────────────────────────────────────────────────── 1 · estados
Levantado contra docs/fundamentos-design-web.md: dos nove estados que um
elemento interativo deveria ter, a home tinha `hover` em quase tudo e
`active` em exatamente DOIS (.expa-42 e .exsa-33). Sem `active`, o botão não
confirma o toque — e no celular, onde não existe hover, ele é o ÚNICO
retorno visual que a pessoa recebe entre tocar e a página reagir.
100ms a 200ms é a faixa recomendada; abaixo disso não se percebe, acima
parece travamento. */
.exph-10:active, .exph-11:active, .exph-21:active,
.exph-33:active, .exph-0:active,
.ex-vaga:active, .ex-menu-item:active{
transform:translateY(1px) !important;
transition-duration:.1s !important;
}
.exph-10:active, .exph-21:active, .exph-33:active, .exph-0:active{
background:#C85A1E !important;
}
/* O foco visível já existe no expan.css (:focus-visible com 2px laranja), mas
ele encosta no botão preenchido e some contra o próprio laranja. Um segundo
anel escuro por fora resolve nos dois fundos. */
.exph-10:focus-visible, .exph-21:focus-visible,
.exph-33:focus-visible, .exph-0:focus-visible{
outline:2px solid #FFE7C9 !important;
outline-offset:2px !important;
box-shadow:0 0 0 5px rgba(14,10,7,.9) !important;
}
/* ──────────────────────────────────────────────── 2 · alvo de toque (44px)
WCAG 2.2 pede 44×44 como mínimo, e mais da metade do tráfego é celular. As
pílulas e os links de rodapé nasceram como texto de 10px: a área clicável
deles era de uns 20px de altura. Aqui eles ganham altura sem mudar o
desenho, porque o padding cresce pra dentro do que já é vazio. */
@media (max-width:860px){
.ex-footer a{
display:inline-flex !important;
align-items:center !important;
min-height:44px !important;
}
.ex-menu-item{min-height:44px !important;display:flex !important;align-items:center !important}
}
/* ───────────────────────────────────────── 3 · o pulso que nunca descansa
O CTA da barra do topo anima `opacity` de uma auréola em laço infinito, pra
sempre, na tela inteira. Ele funciona: o olho vai nele. O problema é que vai
nele o TEMPO TODO — inclusive enquanto a pessoa está lendo os pilares, o
processo e as perguntas, que é justamente quando ela precisa de sossego pra
se convencer.
Não estou desligando o efeito: a preferência da casa é movimento no máximo.
Estou tirando o pico (1 → .72) e alongando o compasso (2.8s → 4.2s). Continua
respirando, para de gritar. */
.ex-cta-diag::after{
animation-duration:4.2s !important;
}
@keyframes exCtaPulsa{
0%, 100%{opacity:0}
50% {opacity:.72}
}
/* ────────────────────────────────────────── 4 · a régua do texto de apoio
O parágrafo sob a chamada corria até ~78 caracteres por linha em telas
largas. A faixa confortável de leitura é ~65: acima disso o olho perde a
volta da linha e relê a mesma. Não mexo no tamanho, só na largura. */
#topo p[data-ex-reveal]{max-width:37.12em !important}
/* ─────────────────────────────────── 5 · movimento reduzido continua vivo
Regra que já custou caro aqui: quando o motor de animação foi condicionado a
prefers-reduced-motion, a página inteira ficou estática em máquina com
"efeitos de animação" desligado no Windows — e o site parecia quebrado.
O contrato certo: quem pede menos movimento recebe menos MOVIMENTO, nunca
menos CONTEÚDO. Então aqui eu garanto que tudo que o motor revela por
animação esteja visível de qualquer jeito. */
@media (prefers-reduced-motion:reduce){
html:not(.ex-motion-full) [data-ex-reveal],
html:not(.ex-motion-full) [data-ex-split]{
opacity:1 !important;
transform:none !important;
visibility:visible !important;
}
#topo [data-ex-reveal]{animation:none !important}
}
/* ══════════════════════════════════════════ 5b · a entrada do topo, em CSS
O QUE ISTO CONSERTA (20/08/2026)
Os quatro blocos da hero -- inclusive o parágrafo que o Chrome elege como
LCP -- nasciam com `opacity:0` e só acendiam quando o GSAP rodava. Ou seja:
o texto principal da página esperava 138 KB de biblioteca baixar, ser
compilada e executar. O Lighthouse mediu isso como 863 ms de "element render
delay" e um LCP de 4,8 s no celular.
Animação é enfeite; o texto não é. Aqui a mesma entrada é feita em CSS puro,
que já está carregado quando o primeiro pixel aparece. O motor de movimento
passa a ignorar tudo dentro de `#topo` (ver initReveal em expan-motion.js) --
se ele não ignorasse, esconderia de novo o que o CSS acabou de mostrar.
`both` guarda o estado inicial antes de a animação começar, senão haveria um
quadro com o conteúdo já no lugar antes de ele recuar. E o movimento é só
`opacity` + `transform`: os dois rodam no compositor, sem tocar em layout.
Nada aqui desloca a página.
Da hero pra baixo nada mudou: quem rola continua recebendo o reveal amarrado
à rolagem, com o vidro e tudo. */
@keyframes exEntradaTopo{
/* A OPACIDADE CHEGA EM 1 NO PRIMEIRO TERCO; a subida continua ate o fim.
Nao e capricho de curva: o Chrome nao contabiliza como "pintado" um
elemento quase transparente, entao enquanto a opacidade sobe devagar ele
adia o LCP. Medido: com a opacidade acompanhando os 720 ms inteiros, o
paragrafo da hero -- que E o LCP da pagina -- registrava 1187 ms de
"element render delay". Fazendo a opacidade terminar aos 30%, o navegador
conta o elemento cedo e o movimento continua igual: o que o olho segue e a
subida, nao o fade.
Duas propriedades, dois tempos, no mesmo keyframe -- em vez de encurtar a
animacao inteira, que aI sim mudaria o ritmo da abertura. */
from{opacity:0;transform:translateY(26px)}
30% {opacity:1}
to {opacity:1;transform:none}
}
#topo [data-ex-reveal]{animation:exEntradaTopo .72s cubic-bezier(.33,1,.68,1) both}
/* ─────────────────────────────────────────── 6 · cartões que nasceram depois
As classes `.exph-0` a `.exph-41` são sequência do compilador de protótipo
que gerou o site: números, sem significado. Os cartões novos (a jornada de
quatro passos, os vazamentos, as estruturas de oferta) precisam do mesmo
comportamento de hover, mas continuar a sequência numérica ia amarrar
conteúdo escrito à mão numa numeração de máquina que ninguém controla.
Daí uma classe com nome. O efeito é idêntico ao das `.exph-12/13/14`. */
.ex-cartao{transition:all .38s cubic-bezier(.33,1,.68,1)}
.ex-cartao:hover{
border-color:rgba(238,122,46,.5) !important;
box-shadow:inset 0 1px 0 rgba(255,231,201,.2),0 18px 60px -18px rgba(238,122,46,.7) !important;
transform:translateY(-4px) !important;
}
.ex-cartao:active{transform:translateY(1px) !important;transition-duration:.1s !important}
/* O menu ganhou um sétimo item quando a página ganhou as seções de vazamentos
e de oferta. As classes `.exph-2` a `.exph-7` do compilador só cobriam seis,
e a sétima delas é a do Diagnóstico, que tem cor de hover própria. */
.ex-menu-extra:hover{color:#EE7A2E !important}
.ex-menu-extra:active{transform:translateY(1px) !important;transition-duration:.1s !important}
/* ─────────────────────────────────────── 7 · player custom do vídeo do topo
O