/* ================================================================ TIPOGRAFIA — FrontPageAI Aplicado por letterman. Revisão de direção motivada pelo diretor do projeto: a versão anterior (Inter, referência Linear/Vercel/GitHub) comunicava "SaaS técnico" — não pela cor ou peso escolhidos, mas pelo próprio esqueleto neo-grotesco da fonte (terminais retos, aberturas fechadas, herança Helvetica/Neue Haas). Ajustar só peso ou tracking não muda essa leitura; por isso a família foi trocada. A direção seguinte foi ACESSÍVEL E ACOLHEDORA — vibe mais perto do Notion (hierarquia simples, pesos robustos em título, tamanhos generosos) do que do Duolingo (sem ir para o lado lúdico/infantil). Fonte usada nessa fase: Nunito Sans — humanista, com terminais levemente arredondados. REVISÃO 2 (esta): o usuário pediu explicitamente para usar o site da Apple (apple.com/br/store) como referência de FONTE — não de cor (paleta é do colorman) nem de layout (é do layoutman). O acolhimento "macio" do Nunito Sans (terminais arredondados, humanista) foi trocado por uma leitura mais NEUTRA e PRECISA, no espírito de SF Pro: hierarquia construída por tamanho + peso + tracking, não por "calor" no próprio desenho da letra. SF Pro é proprietária da Apple e não é distribuída para web fora do ecossistema Apple, então a prática aceita (e a que foi adotada aqui) é usar a pilha de fontes de sistema como família principal: -apple-system e BlinkMacSystemFont fazem o texto renderizar em SF Pro automaticamente para quem visita em macOS/iOS/iPadOS/ Safari — exatamente a fonte real da Apple, sem custo de licença nem de carregamento — e cai em 'Segoe UI' (Windows), Roboto (Android/ChromeOS) ou Helvetica/Arial como fallback neutro equivalente em outros sistemas. Isso também elimina a dependência do Google Fonts (nenhum @import de webfont é mais necessário), o que é coerente com a ideia de "nativo do sistema operacional", não "importado". Continua existindo uma única família para título e corpo — não é a família que muda entre os dois (isso reintroduziria a lógica "técnica" de misturar fontes), a hierarquia vem de tamanho, peso e tracking, reforçando a proporção "expressivo no título, neutro no corpo" que a Apple usa em suas páginas de produto: títulos bem maiores e mais confiantes que o corpo (ver --fs-h1, --fs-price), mas com pesos mais contidos (Bold/Semibold, não o mais pesado da faixa) e tracking que aperta conforme o texto cresce — ver notas junto a cada regra abaixo (h1, h2, h3, .plan-card__amount, .badge etc.). Isso é uma evolução de identidade, não uma correção: o tom "amigo especialista" da direção anterior segue valendo na copy e no ritmo das seções — aqui é só a "letra" que fica mais precisa/confiável e menos macia. REVISÃO 3 (esta): a REVISÃO 2 foi feita só com base na documentação (HIG) do sistema Apple, sem ver o site de verdade. O diretor trouxe um print real de apple.com/br/store e pediu comparação olho no olho. O que o print confirma e o que ele corrige: - Pilha de fontes de sistema (-apple-system/BlinkMacSystemFont): CONFIRMADA. É a mesma decisão, só que agora com prova visual — nada muda aqui. - Peso dos títulos: o print mostra pouquíssimos tamanhos de fonte no total, com a hierarquia vindo sobretudo de PESO. O "Loja" (H1) e os nomes de produto em card usam um bold bem assertivo, não um semibold morno — por isso h2 (título de seção) e h3 (título de card) sobem de 600 para 700. O H1 já estava em 700; mantido. - Título de seção + subtítulo na MESMA LINHA/BLOCO: no print, frases como "As novidades. Veja o que acabou de chegar." usam o MESMO tamanho de fonte para as duas partes — só o peso muda (negrito → regular). O sistema anterior tratava o subtítulo como um texto bem menor (--fs-body-lg, 17px) abaixo de um h2 grande (28–38px), o que lia como "título + parágrafo de apoio", não como "uma frase, dois pesos". Ajuste: .section-subtitle passa a usar o mesmo var(--fs-h2) do título, com peso regular (400) e a margem entre os dois quase zerada — sem fundir os elementos (o HTML continua com h2 + p separados, por semântica/acessibilidade), mas visual e ritmicamente lendo como a continuação da mesma frase, não como um subtítulo à parte. - Rótulos pequenos em caixa alta (badge, acrônimo, títulos de rodapé, status de passo): o print mostra esses rótulos com peso mais leve do que o resto do sistema sugeria — não competem com o título do card. .concept-card__acronym desce de 700 para 600, alinhando com o mesmo peso já usado em .badge/.footer-nav__title/ .step-card__status. - Contraste peso título↔legenda em cards (preview-card, plan-card): o print reforça bold no nome + regular na legenda logo abaixo. .preview-card__item-title sobe de 600 para 700; .plan-card__amount sobe de 600 para 700; .plan-card__period desce de 500 para 400 — mais distância de peso entre os dois. - Alinhamento: o print é fortemente alinhado à esquerda, nunca centralizado, nos títulos de página e de seção. Conferido: nenhum título deste arquivo usa text-align: center (só notas/legendas isoladas, como .pricing__note e .demo-notice__text, seguem centralizadas — não são títulos, então ficam como estão). Nenhuma mudança necessária aqui. SUPERADO NA REVISÃO 13 (letterman): pedido explícito e posterior do usuário centralizou o h2 global (ver regra h2 mais abaixo e bloco "REVISÃO 13" logo acima da paleta). A referência à Apple acima descrevia o estado do arquivo e a inspiração da ÉPOCA, não uma regra fixa — mantida aqui só como registro histórico do raciocínio, não como estado atual. Processo: esta revisão passou por 3 ciclos de comparação com o print antes de ser considerada pronta — ver notas de "ciclo 2" e "ciclo 3" junto às regras mais abaixo onde houve ajuste fino adicional. REVISÃO 5 (letterman): pedido explícito do diretor do projeto — o destaque de leitura (.text-highlight, hoje usado em "próximo passo certo" no h1 da home) passa a usar também uma FAMÍLIA DE FONTE diferente do resto do sistema, não só a cor (--color-highlight, já clareada pelo colorman na REVISÃO 4 de paleta, "Azul Névoa", #167AB5). Isso é uma mudança de direção pontual sobre a decisão estrutural da REVISÃO 2/3 acima: título e corpo continuam deliberadamente em UMA ÚNICA família (pilha de sistema, SF Pro/ equivalentes) — a hierarquia entre eles segue vindo só de tamanho/ peso/tracking, nunca de trocar de família, porque misturar fontes "por padrão" reintroduziria a lógica técnica que a REVISÃO 2 explicitamente descartou. A exceção agora aberta é ESTRITAMENTE limitada a .text-highlight (e a qualquer reuso futuro da mesma classe/padrão) — --font-heading e --font-body continuam intocados, e nenhuma segunda família aparece em nenhum outro seletor deste arquivo. Isto NÃO é uma reversão da decisão "uma família só" — é uma exceção nomeada e contida a um único seletor. Fonte escolhida: Source Serif 4 (Adobe, SIL Open Font License, uso comercial livre), peso 700 (Bold) apenas. Escolhida entre 4 opções levantadas pelo researchdude (2 serifadas — Source Serif 4, Lora — e 2 sans com mais caráter que a pilha system-ui — IBM Plex Sans, Public Sans) porque: - O tom da marca é editorial/institucional, "amigo especialista" (ver notas de identidade em todo este arquivo) — uma serifada é o sinal tipográfico mais direto de "confiança/registro editorial" que existe, e cria um contraste de FORMA (serifa vs. sem-serifa) muito mais perceptível para um destaque de 1-3 palavras do que qualquer contraste possível dentro da própria família sans (IBM Plex Sans e Public Sans têm proporções próximas da pilha SF Pro/Segoe UI — as três foram desenhadas para UI —, então o contraste ficaria sutil demais). - Entre as duas serifadas, Source Serif 4 foi preferida a Lora por ter desenho mais contido, pensado para tela (sem o calor editorial-cultural do Lora, cujo itálico tem DNA caligráfico e risco de ler "decorativo" — o pedido foi por "sério mas acessível", nunca playful/infantil). Source Serif 4 tem eixo de Optical Size (8-60), então o corte usado em título vem desenhado para exibição grande, não uma versão de texto de livro esticada. - Só o peso 700 (Bold) é carregado — é o único peso em uso hoje (o destaque herda font-weight:700 do h1 pai) e a fonte variável completa (200-900, com itálico) não precisa ser baixada para um uso de 1-3 palavras. Itálico não é usado. Implementação/performance (orientação do researchdude, aplicada aqui já que este agente não acessa rede): - Google Fonts, URL com peso único e display=swap: https://fonts.googleapis.com/css2?family=Source+Serif+4:wght@700&display=swap — display=swap evita texto invisível durante o carregamento (FOIT): o navegador renderiza no fallback (--font-body, pilha de sistema) até a webfont chegar, depois troca. - e adicionados junto do link de stylesheet, para adiantar a conexão antes do CSS pedir a fonte. - Adicionados nas 7 páginas HTML, não só em index.html (onde o destaque é usado hoje): o custo extra é pequeno (1 família, 1 peso, arquivo já subsetado pelo Google Fonts), e .text-highlight foi desenhado para ser reutilizável em qualquer página do site — deixar o link só em index.html criaria uma dependência silenciosa (a classe funcionaria em outra página só com o fallback, sem erro nem aviso, até alguém lembrar de replicar o link). Preferi pagar o pequeno custo fixo em todas as páginas a arriscar essa inconsistência silenciosa. - Novo token --font-highlight: "Source Serif 4", var(--font-body) — nunca fica sem fallback: se a webfont falhar ao carregar, cai direto na mesma pilha de sistema usada no resto do site, nunca num serifado genérico do navegador. - .text-highlight ganhou letter-spacing:0 (o tracking negativo herdado do h1, -0.02em, foi calibrado para a pilha sans do sistema; um serifado bold neste tamanho não precisa do mesmo aperto óptico) — cor e demais propriedades continuam herdadas do elemento-pai, inalteradas. REVISÃO 6 (letterman): tipografia do novo bloco .next-step (aside de transição de funil entre páginas, adicionado pelo writerman ao fim do
de 6 das 7 páginas — todas exceto lista-de-espera.html, que é o destino final do funil, não uma etapa de transição). O componente ainda não tinha nenhum CSS; a estrutura HTML é idêntica nas 6 páginas (.next-step__eyebrow, .next-step__text, .next-step__link). Espaçamento/padding/caixa deste bloco ficam para o layoutman, que trabalha depois nesta mesma rodada — aqui só o comportamento tipográfico do texto (fonte, tamanho, peso, tracking, cor, alinhamento). Decisões, mapeadas a papéis já existentes no sistema (mesmo raciocínio de "não inventar um componente do zero"): - .next-step__eyebrow segue exatamente o padrão de rótulo curto já usado em .badge/.footer-nav__title/.concept-card__acronym (caixa alta, peso 600, --fs-eyebrow, tracking 0.04em) — mesmo papel de "isto é um rótulo, não uma frase". Cor: --color-brand (Marinho estrutural), não --color-accent nem --color-warning-*. O papel do Marinho no sistema já é marcar "isto é FrontPageAI, estrutura/sequência" (mesmo uso em .step-card__number) — o eyebrow "Próximo passo" é literalmente um marcador de progressão sequencial no funil, o mesmo papel; não é um aviso (--color-warning, reservado para pré-lançamento) nem a própria ação (--color-accent, reservado para o link clicável logo abaixo, para não competir com ele). Contraste: --color-brand sobre --color-bg-page já auditado pelo colorman em ~7,0:1, bem acima do mínimo 4,5:1 — testei a alternativa --color-accent para este rótulo e ela mede ~4,57:1 sobre o mesmo fundo (passa, mas com folga bem mais apertada); prefiro reservar a folga maior para um rótulo que se repete em 6 das 7 páginas. - .next-step__text é comparável em papel a .section-subtitle/ .hero-description (frase corrida legível), mas precisa comunicar convite a continuar, não um parágrafo neutro de apoio — por isso usa --fs-body-lg (o mesmo tamanho de .section-subtitle/ .hero-description, nenhum tamanho novo) com peso 500 (Medium) em vez do 400 regular dessas duas: um degrau de assertividade a mais, sem chegar no 600 usado em títulos de item (.preview-card__item-title, .faq-item__question) e bem abaixo do 600/700 usado em h2/h3 — não compete com um título de verdade. Cor: --color-text-heading (mais escura/alto contraste que --color-text-body ou --color-text-muted), o mesmo tom usado em .preview-card__item-title e .faq-item__question — dois outros casos já existentes de "texto mais assertivo que corpo comum, mas não um h2/h3", então este uso segue precedente, não cria um quarto papel de cor de texto. max-width: 68ch mantém a linha em comprimento legível (mesma lógica de .hero-description 62ch/ .section-subtitle 60ch/.waitlist__text 65ch; um pouco mais longo aqui porque a frase carrega o link inline no final). - .next-step__link segue o mesmo papel de link de ação que .source-card__link: cor --color-text-link (alias de --color-accent, o azul de Ação/CTA), peso 600, hover/focus com --color-accent-hover — mesmo par de estados já usado em .source-card__link:hover e .site-nav__link:hover, nenhuma cor nova. Tamanho e tracking não são redefinidos: como o link é inline dentro de .next-step__text (não um parágrafo próprio, ao contrário de .source-card__link), ele herda o --fs-body-lg/500 do texto ao redor por padrão (font-size/font-weight herdam normalmente em elementos inline sem UA override) — só cor e peso mudam, suficiente para diferenciar o link sem quebrar o fluxo da frase. - Transição final do funil (faq.html → lista-de-espera.html) — a conversão mais importante do site: adicionei o modificador .next-step--final (aplicado só no