— nunca vaza pro header/rodapé/marquee, que ficam fora dele). */ :root { --or-fs-display: clamp(2.6rem, 1.6rem + 5vw, 5.5rem); /* hero comercial — mesmo clamp do .or-hero-interno__title, agora token */ --or-fs-display-hero: clamp(2.4rem, 1.5rem + 3.4vw, 4.25rem); /* SÓ .or-home-hero__title — teto 68px (era 88px via --or-fs-display): a frase-âncora + complemento rotativo cabe em 3 linhas em vez de 4, evitando que o hero estoure a viewport em notebooks baixos (achado 26/08/2026, print 2560×919) */ --or-fs-h1: clamp(2.1rem, 1.4rem + 3.2vw, 4rem); /* hero editorial/listagem */ --or-fs-secao: clamp(1.9rem, 1.2rem + 2.4vw, 4rem); /* conserta .title / h3 de seção — teto 4rem (era 3.25rem, truncava 35% da rampa) */ --or-fs-secao-compacta: clamp(1.9rem, 1.2rem + 2.4vw, 3.25rem); /* teto ANTIGO de --or-fs-secao — pra quem não deve crescer (.or-hero-interno--doc, .or-funfacts) */ --or-fs-h3: clamp(1.5rem, 1.15rem + 1.2vw, 2rem); /* subtítulos internos */ --or-fs-card: clamp(1.2rem, 1.05rem + .7vw, 1.5rem); /* conserta h4 de card (era 60px cru) */ --or-fs-lead: clamp(1.05rem, 1rem + .4vw, 1.25rem); --or-fs-small: .875rem; --or-fs-eyebrow: .78rem; /* Prosa de leitura longa (artigo do blog, legais) — promovendo a token o valor que já estava em uso: 72ch já era o teto de linha real de .or-doc-body (achado de 27/08/2026, ver o comentário da regra de max-width abaixo) e 1.7 já era o line-height do próprio seletor. Não é escala nova — é o mesmo número, nomeado, pra parar de repetir o literal a cada regra. */ --or-medida-prosa: 72ch; --or-lh-prosa: 1.7; } /* Tracking PROPORCIONAL (não em px fixo). O vendor prende letter-spacing à TAG em px (h3 −2px@80px, h4 −1,5px@60px — ambos −0,025em); toda regra que REESCALA um heading sem reescalar o tracking herda um valor absoluto calibrado pra outro corpo — era -1,5px sobre um h4 de 16,8px = -8,9% do corpo (letras colidindo, achado real em .or-prova-card). Os valores abaixo são os do PRÓPRIO vendor na escala equivalente: -.01em é literalmente o -0,24px@24px do h6 (style.css:151-153). .or-pg h3.move-anim:not(.title) agora joga no MESMO seletor que .title — antes só herdava font-size e ficava com -2,00px crus do vendor (quase o dobro do -1,04px dos irmãos). */ /* h2.title entrou em 28/08/2026 (auditoria A-08): os títulos de seção eram

, com a página saltando de h1 direto para h3 — 19 h3 contra 3 h2. Leitor de tela navegando por heading percebia as seções como subordinadas a algo inexistente, e é sinal de estrutura para o crawler, que é justamente o que este site vende. A tag mudou para h2; o VISUAL não muda, porque o tamanho vem desta regra (não da tag), e é por isso que h2 e h3 dividem o mesmo seletor. / .or-pg h2.title, .or-pg h3.title, .or-pg .quanto__header .title, .or-pg h3.move-anim:not(.title) { font-size: var(--or-fs-secao); line-height: 1.12; letter-spacing: -.02em; / text-wrap:balance (27/08/2026) — conserta a ÓRFÃ. Achado ao vivo em #dor: "Se sua empresa não aparece, ela / não existe." deixa "ela" pendurada no fim da linha 1; com col-8 a linha fica ainda mais longa e a chance de órfã sobe. Balance reparte as linhas em larguras parecidas — cálculo que o vendor nunca fez. Progressive enhancement puro (Chrome 114+, Safari 17.4+, Firefox 121+): onde não existe, o navegador descarta a declaração e nada muda. SOBREVIVE ao SplitText (main.js:442 fatia .move-anim em
por LINHA): o split LÊ o layout já balanceado e congela essas linhas — CSS pinta primeiro, JS lê depois. Entra no seletor global do sistema tipográfico, não escopado a #dor: órfã em título de seção é problema de TODA página, mesma lógica do tracking proporcional documentado acima. / text-wrap: balance; } .or-pg :is(.quanto-service-box3, .quanto-service-box4, .quanto-service-box5, .quanto-service-box6) h4, .or-pg .or-prova-card :is(h3, h4) { font-size: var(--or-fs-card); / O peso vinha da TAG: h4 do vendor é 700, h3 é 600. Ao promover o card de prova para h3 o título emagreceu — diferença que a medição pegou e o olho não pegaria. Declarado aqui, a regra deixa de depender da tag também nisso. / font-weight: 700; line-height: 1.25; letter-spacing: -.01em; } / Utilitários t-* — promovidos de "só dentro de .or-doc-body" pra globais em .or-pg. Achado real: t-medium/t-bold NÃO EXISTEM em CSS nenhum (nem aqui, nem no vendor) e t-large/-small/-muted só valiam dentro de .or-doc-body — ~40 usos em 21 arquivos (todo empty-state de listagem, as legendas de estatística de /planos, a frase-manifesto de /sobre) renderizavam sem nenhum estilo. t-muted usa var(--or-text-muted) — achado extra: a versão antiga usava var(--color-4) (#313131, cru, nunca flipado pro dark), texto quase invisível em fundo escuro (~mesma família do achado de contraste da F9). Substituída aqui — não há mais declaração own de --color-4 pra t-muted. / .or-pg .t-large { font-size: var(--or-fs-lead); } .or-pg .t-small { font-size: var(--or-fs-small); } .or-pg .t-muted { color: var(--or-text-muted); } .or-pg .t-medium { font-weight: 500; } .or-pg .t-bold { font-weight: 700; } / ── RITMO TIPOGRÁFICO DE FALLBACK — o par heading→parágrafo (05/09/2026) ─────────────────── CAUSA RAIZ (CLAUDE.md §Padrão de Espaçamento): o vendor zera h1-h6{margin-bottom:0} E p{margin-bottom:0}. Um
logo abaixo de um heading, sem classe que traga margem, fica COLADO — sem erro, sem aviso. Achado ao vivo em /planos (h2.title + p.t-muted dentro de .text-center.mb-4: o .mb-4 separa o WRAPPER do form abaixo, nunca os dois filhos entre si — pagina-planos.php, bloco do formulário de contato). Varredura dos arquivos .php de site/_template/pages/: 43 pares h+p adjacentes; 19 já têm classe com margem própria (.or-lead, .or-blog-resumo, .or-hero-internosubtitle…), ~15 estavam colados (pagina-busca.php, 404.php, home.php, pagina-planos.php entre eles). ⚠️ A ESPECIFICIDADE É O DESENHO, não um detalhe. Os DOIS :where() zeram a contribuição do escopo e dos headings: o seletor inteiro pesa (0,0,1) — o mesmo de um `p` cru. Consequências, todas desejadas: · QUALQUER regra com uma classe (0,1,0+) vence sem esforço e sem !important — .or-lead, .or-blog-resumo, .or-hero-internosubtitle, e também os utilitários mt-* / my-* do Bootstrap. Zero regressão nos pares que já têm margem própria. · Componente cujo PAI é flex/grid com gap (Regime A do CLAUDE.md) neutraliza com uma linha trivial de classe — o respiro nunca dobra por acidente, e a correção é local: `.componente :is(h1,h2,h3,h4,h5,h6) + p { margin-top: 0 }` (0,1,2 > 0,0,1). · Só perde para outro seletor de peso (0,0,1) que venha DEPOIS no arquivo — não existe nenhum seletor de elemento puro `p{}` no custom.css. O único concorrente é o `p{margin-bottom:0}` do vendor (style.css), que carrega ANTES — vencemos por ordem. `+` (irmão ADJACENTE), nunca `~`: só o parágrafo que abre logo abaixo do título. Comentário HTML e bloco entre os dois não são elementos e não quebram a adjacência. --or-esp-5 é o PISO documentado entre blocos irmãos (24px), não um valor escolhido aqui. / :where(.or-pg) :where(h1, h2, h3, h4, h5, h6) + p { margin-top: var(--or-esp-5); } :where(.or-pg) :where(h1, h2, h3, h4, h5, h6) + :where(ul, ol, blockquote, dl) { margin-top: var(--or-esp-5); } / --- Padding de seção mais denso na HOME (F6 da reestruturação — orçamento de rolagem; reduzido de novo em 27/08/2026 — pedido do dono ao ver o hiato #superficies→#dor: "este espaçamento entre sessões pode ser menor"). A home tem 12+ seções (contra 1-3 de página interna); os 130px do vendor (style.css:340-343) em cada uma somam ~1,5x mais respiro do que uma home com tantos blocos precisa. Primeira rodada (F6) foi 130→96; esta caiu mais 24px (96→72, -25%, mesma proporção do corte anterior) — é a alavanca que aperta o espaço entre TODAS as seções de uma vez, não só a que apareceu no print. Só ≥1200px — as reduções do vendor pra tablet/mobile (80px/65px) já são proporcionalmente menores e ficam intocadas (o seletor teria especificidade maior e as sobrescreveria se não escopado à mesma media query). FURO ACHADO NA AUDITORIA (28/08/2026, CLAUDE.md §Padrão de Espaçamento): o seletor só cobria `.section-padding-top-bottom`. #portfolio e a faixa de parceiros usam `.section-padding-bottom` SOZINHA (sem a top) — escapavam do corte e ficavam nos 130px do vendor. Resultado medido: #portfolio→#servicos e parceiros→#blog somavam 202px (130 do topo da seção seguinte + 72 daqui), 40% ACIMA do padrão de 144px (72+72) — exatamente o oposto do que este bloco existe pra fazer. As 3 classes do vendor (style.css:332-343) são cada uma DONA de UMA propriedade só (top-only, bottom-only, ambas) — cada regra abaixo toca só a que a classe original já tinha. Dar padding-top a `.section-padding-bottom` seria inventar um respiro no TOPO que o vendor nunca declarou (ex.: #portfolio encosta em #lgpd de propósito, sem gap — é o próximo padding-bottom que faltava, não um padding-top que nunca existiu). DOIS ACHADOS MEDIDOS AO VIVO em 29/08/2026 (Playwright, offsetTop — imune ao transform do ScrollSmoother/GSAP, que distorce getBoundingClientRect() em tudo com fade-anim/move-anim): 1) O override só cobria ≥1200px — a faixa 992-1199px (tablet) ficava com os 80px do vendor, MAIS respiro entre seções (160px) que o DESKTOP (144px). Inversão de hierarquia por acidente de breakpoint, não por design. Corrigido subindo a media query pro breakpoint `lg` do próprio Bootstrap (992px), onde as colunas ainda ficam lado a lado — abaixo disso tudo empilha e a proporção já é outra por natureza. 2) `row-padding-top` (60px, classe do vendor que separa ROWS irmãs dentro de uma seção — ver CLAUDE.md §Padrão de Espaçamento) nunca foi reescalado junto do corte 130→72 do PADDING de seção. Vão entre seções 144px contra degrau interno de 60px = razão 2,4× — perto demais: "nova seção" e "nova row" liam quase igual. --or-esp-7 (48px) é literalmente o token da escala pra "sub-bloco↔sub-bloco dentro da mesma seção" (custom.css :root) e devolve a razão pra 3,0× (144/48), o mesmo tipo de proporção que já existia antes do corte de padding. / / --- RITMO GLOBAL (02/09/2026) — o corte deixou de ser exclusivo da home. Ele nasceu escopado em `.or-pg--home` porque foi lá que o problema apareceu, e ficou assim. O efeito colateral so ficou visivel quando as paginas internas de servico cresceram para 9+ secoes: a home respirava 144px entre secoes e a interna 260px — 80% a mais, na pagina que MAIS precisa de leitura continua. Nao era decisao de design, era o alcance de um seletor. Medido antes de mexer (1440px, offsetTop): home 72+72 com degrau de 48px; qualquer `.or-pg--` que nao fosse a home caia nos 130+130/60 do vendor. Tirar o `.or-pg--home` iguala o site inteiro ao ritmo que ja tinha sido calibrado e aprovado — nao inventa um terceiro valor. A media query continua em 992px (breakpoint `lg` do Bootstrap, onde as colunas ainda ficam lado a lado). Abaixo disso tudo empilha e valem os 65/45 do vendor, que ja sao proporcionais. O `.or-pg` no seletor mantem o escopo dentro do
— o header/rodape do vendor nao entram. --- / @media (min-width: 992px) { .or-pg .section-padding-top-bottom { padding-top: 72px; padding-bottom: 72px; } .or-pg .section-padding-top { padding-top: 72px; } .or-pg .section-padding-bottom { padding-bottom: 72px; } .or-pg .row-padding-top { padding-top: var(--or-esp-7); } .or-pg .row-padding-bottom { padding-bottom: var(--or-esp-7); } } /* --- Respiro do empilhamento mobile — rows que trocaram g-* por gx-* (achado do "gutter come padding-top da seção" — ver o comentário de cada row em home.php) perderam o gutter VERTICAL nativo do Bootstrap, que era quem separava as 2 colunas quando empilham (<992px). Mesmo remédio já usado em #geo/#lgpd (classe marcadora na row + margin-top no 2º filho). Valores da escala --or-esp-* conforme o peso do par: blocos grandes (devices/swiper) usam --or-esp-6 (32px); título+link mais leve usa --or-esp-5 (o piso). .or-faqs-stack SAIU (29/08/2026) — #faqs deixou de usar gx-: agora é g-4 g-xl-5, um grid de 2 colunas de verdade (4 grupos, não mais 1 título estreito + 1 acordeão largo), e o gutter VERTICAL nativo do g-4 já resolve o empilhamento mobile sozinho — nenhuma compensação extra precisa. --- / @media (max-width: 991.98px) { .or-painel-stack > :nth-child(2) { margin-top: var(--or-esp-6); } .or-depoimentos-stack > :nth-child(2) { margin-top: var(--or-esp-6); } } /* .or-blog-header-stack REMOVIDA em 09/09/2026: o cabeçalho de #blog virou coluna única (col-lg-10) e o link "Ver todos os artigos" desceu para uma row própria depois dos cards. A regra dava respiro entre a 1ª e a 2ª coluna no empilhamento mobile — sem 2ª coluna, o seletor :nth-child(2) não tem mais o que atingir. CSS sem markup não quebra nada, mas mente para quem lê depois: sugere um componente vivo que nenhuma tela renderiza. / / .quanto-about__content.style-2 .price-info tinha override aqui (achado 28/08/2026) porque #sobre-onerank (home) media o "9 recursos de acessibilidade" com o odômetro. A seção SAIU da home em 29/08/2026 (só os diferenciais migraram, para /sobre — o odômetro não, /sobre já tem bloco próprio de indicadores) e este era o ÚNICO uso de .price-info na home — regra removida por não ter mais seletor a atingir. / / ================================================================ BLOCO 2 — TEMA · CHASSI (cursor/preloader/menu mobile/header/rodapé/hero interno — comum a TODA página do tema, não só a home). ================================================================ / / Rede de segurança documentada (docs/layout-tema.md): bundle Envato minificado de Swiper pode trazer CSS nesting corrompido (&:only-child vira :only-child GLOBAL após a minificação) — como é estruturalmente filho único do document, a página inteira fica display:none, sem erro de servidor/console. Já aconteceu de verdade com o swiper-bundle do Azurio; o do Quanto é outro arquivo/versão, mas a mesma classe de bug do minificador pode se repetir. Custo: 1 linha. / html:only-child { display: block !important; } / --- Logo (header + menu mobile) — dimensiona qualquer logo enviada no admin (o vendor não define altura própria: .header-logo/.mobile-logo só limitam largura, style.css:1050/1389). --- / .header-logo img, .header-logo .or-logo-swap img, .header-logo .or-logo-swap { max-height: 42px; width: auto; } .header-logo .or-logo-swap { display: inline-flex; align-items: center; } .quanto-menu-wrapper .mobile-logo img, .quanto-menu-wrapper .mobile-logo .or-logo-swap img { max-height: 34px; width: auto; } .quanto-menu-wrapper .mobile-logo .or-logo-swap { display: inline-flex; align-items: center; } / --- Acento de marca (mín. 3 pontos — o resto do template é monocromático de propósito): 1) :focus-visible global já usa var(--marca-primaria) via site/assets/css/or-a11y.css (core, carregado em toda página, !important) — nenhum CSS extra necessário aqui. 2) CTAs principais (header/hero/pricing) ganham a cor real da marca em vez do neutro --color-primary. 3) Hover-overlay (painel que desliza atrás de pricing-box/process-box no hover, injetado por main.js) troca de neutro pra marca. --- / .quanto-header .quanto-link-btn.btn-pill, .quanto-pricing-box .quanto-link-btn.btn-pill { background-color: var(--marca-primaria); border-color: var(--marca-primaria); } .quanto-header .quanto-link-btn.btn-pill:hover, .quanto-pricing-box .quanto-link-btn.btn-pill:hover { background-color: var(--marca-secundaria, var(--marca-primaria)); border-color: var(--marca-secundaria, var(--marca-primaria)); } / Hover-overlay: PAR de tokens por componente (painel + tinta), não um azul único. Os dois cards partem de superfícies OPOSTAS — .process-box é card escuro (vendor deu overlay claro, style.css:5679-5687) · .quanto-pricing-box é card claro (vendor deu overlay escuro, style.css:5178) — daí terem cores de TEXTO opostas no :hover (style.css:5727-5733 usa var(--color-primary), escuro; style.css:5284-5290 usa var(--color-white), claro). Um único azul de marca aqui deixou a cor de texto do vendor "desencontrada": 1,57:1 no .process-box (claro) e 1,78:1 no .quanto-pricing-box (escuro) — medido ao vivo. A correção da TINTA fica no bloco 3.5, depois do bloco DARK de propósito (ver comentário lá). / .process-box { --or-hover-painel: color-mix(in srgb, var(--marca-primaria) 12%, #fff); --or-hover-tinta: var(--marca-primaria); } .quanto-pricing-box { --or-hover-painel: var(--marca-primaria); --or-hover-tinta: #fff; } .quanto-pricing-box .hover-overlay, .process-box .hover-overlay { background: var(--or-hover-painel); } .or-header-actions { gap: 14px; } / --- Breadcrumb (_hero-interno.php) — o Quanto não tem componente nativo (zero uso de "breadcrumb" em qualquer página HTML do vendor; só existe CSS órfão .breadcrumb-area, sem markup correspondente). Componente novo, mínimo, no vocabulário visual do template (mesma fonte/peso das listas .custom-ul). --- / .or-breadcrumb { margin-bottom: 18px; } .or-breadcrumb ol { display: flex; flex-wrap: wrap; align-items: center; gap: 6px; margin: 0; padding: 0; list-style: none; font-size: 14px; font-weight: 500; color: var(--color-1); } .or-breadcrumb li:not(:last-child)::after { content: '/'; margin-left: 6px; color: var(--color-1); } .or-breadcrumb a { color: var(--color-primary); text-decoration: underline; text-underline-offset: 3px; } .or-breadcrumb a:hover { color: var(--marca-primaria); } .or-breadcrumb li[aria-current] { color: var(--color-1); } / --- Hero interno (_hero-interno.php) — 4 variantes visuais (evolução F2), decididas por página em $orHero['variante']. Até aqui TODA página interna usava o mesmo hero vazio de ~330px em branco (padding-top:200px do vendor + section-padding-bottom 130px) com só título — 13 das 27 nem tinham subtítulo. clamp() escopado a .or-pg (nunca vaza pra outro contexto — a marquee da home usa seletor inteiramente diferente). O h1{font-size:140px} cru do vendor foi pensado pra títulos curtos em inglês; títulos em PT-BR são ~40% mais longos e estourariam a viewport em telas estreitas (mesmo achado já registrado na migração Azurio). --- / .or-pg .or-hero-internotitle { font-size: var(--or-fs-h1); letter-spacing: -0.02em; } .or-hero-internosubtitle { margin-top: 16px; / Sem teto próprio (era 640px), mesma razão do title logo abaixo: a coluna do hero já é o limite desde que ela passou a col-lg-10/col-xl-8. Com os dois, o subtítulo quebrava numa medida bem menor que a do título acima, deixando um degrau de largura entre os dois. / max-width: 100%; font-size: 18px; line-height: 1.6; color: var(--color-primary); opacity: .72; } .or-hero-internostat { margin: 0; font-size: var(--or-fs-card); font-weight: 700; color: var(--marca-primaria); text-align: right; } [data-bs-theme="dark"] .or-hero-internostat { color: var(--or-brand-accent); } / ═══════════════════════════════════════════════════════════════════════════════════════════════ SUPERFÍCIE COMUM DAS 4 VARIANTES DE HERO INTERNO — 08/09/2026 ═══════════════════════════════════════════════════════════════════════════════════════════════ Pedido do dono, por print: o hero de /presenca-em-ia (variante `comercial`) é o EXEMPLO, e /acessibilidade (`doc`, cinza chapado) "precisa seguir a padronização" dele. A varredura mostrou que o problema era maior que uma página: `doc` tinha fundo `var(--color-2)` e `listagem` NÃO TINHA UMA ÚNICA REGRA PRÓPRIA no arquivo inteiro — herdava fundo branco, título grafite e eyebrow azul do padrão. Metade das páginas internas estava numa família visual e metade na oposta, sem nenhum critério que o visitante percebesse. POR QUE LISTA DE SELETORES E NÃO CÓPIA: `comercial` e `editorial` já repetiam, cada uma, as MESMAS tintas (título branco, subtítulo .82, breadcrumb .55/.85, hover dourado). Acrescentar `doc` e `listagem` copiando de novo daria QUATRO cópias da mesma regra — e a próxima correção de contraste seria feita em uma só. Aqui fica o que é comum; abaixo, só o que distingue cada uma. O QUE CONTINUA DISTINGUINDO AS QUATRO é a ESCALA DO TÍTULO (decisão do dono nesta sessão: "mesma família visual, tamanho de título próprio"): comercial → --or-fs-display (até 88px) · frase-âncora curta de página de venda listagem → --or-fs-h1 (até 64px) · herda a base, sem regra própria editorial → --or-fs-h1 + max-width:900px · medida de prosa, título de artigo real doc → --or-fs-secao-compacta (52px)· documento legal não é campanha INCONDICIONAL, nunca escopado a [data-bs-theme="dark"]: o gradiente da marca não muda com o tema (mesmo raciocínio de .or-home-hero). Regra de tinta que fosse só-dark deixaria o tema claro — que é o default — com texto escuro sobre fundo escuro. / .or-hero-interno--comercial, .or-hero-interno--listagem, .or-hero-interno--editorial, .or-hero-interno--doc { background: var(--or-grad-marca); position: relative; isolation: isolate; } / !important no título: [data-bs-theme="dark"] :is(h1..h6){color:var(--or-text)!important} (linha ~508) venceria por !important mesmo com especificidade menor (0,1,1 contra 0,2,0 daqui) — achado ao vivo (título saía cinza --or-text em vez de branco no dark). / .or-hero-interno--comercial .or-hero-internotitle, .or-hero-interno--listagem .or-hero-internotitle, .or-hero-interno--editorial .or-hero-internotitle, .or-hero-interno--doc .or-hero-internotitle { color: #fff !important; } .or-hero-interno--comercial .or-hero-internosubtitle, .or-hero-interno--listagem .or-hero-internosubtitle, .or-hero-interno--editorial .or-hero-internosubtitle, .or-hero-interno--doc .or-hero-internosubtitle { color: #fff; opacity: .82; } .or-hero-interno--comercial .or-breadcrumb ol, .or-hero-interno--comercial .or-breadcrumb li:not(:last-child)::after, .or-hero-interno--comercial .or-breadcrumb li[aria-current], .or-hero-interno--listagem .or-breadcrumb ol, .or-hero-interno--listagem .or-breadcrumb li:not(:last-child)::after, .or-hero-interno--listagem .or-breadcrumb li[aria-current], .or-hero-interno--editorial .or-breadcrumb ol, .or-hero-interno--editorial .or-breadcrumb li:not(:last-child)::after, .or-hero-interno--editorial .or-breadcrumb li[aria-current], .or-hero-interno--doc .or-breadcrumb ol, .or-hero-interno--doc .or-breadcrumb li:not(:last-child)::after, .or-hero-interno--doc .or-breadcrumb li[aria-current] { color: rgba(255, 255, 255, .55); } .or-hero-interno--comercial .or-breadcrumb a, .or-hero-interno--listagem .or-breadcrumb a, .or-hero-interno--editorial .or-breadcrumb a, .or-hero-interno--doc .or-breadcrumb a { color: rgba(255, 255, 255, .85); } .or-hero-interno--comercial .or-breadcrumb a:hover, .or-hero-interno--listagem .or-breadcrumb a:hover, .or-hero-interno--editorial .or-breadcrumb a:hover, .or-hero-interno--doc .or-breadcrumb a:hover { color: var(--or-dourado); } / Eyebrow dourado nas três "etiqueta"; a `editorial` sobrescreve logo abaixo com o tom discreto que a caracteriza (lá é metadado do artigo, não etiqueta de campanha). / .or-hero-interno--comercial .or-eyebrow, .or-hero-interno--listagem .or-eyebrow, .or-hero-interno--doc .or-eyebrow { color: var(--or-dourado); } / .or-tag nasce var(--color-primary) — texto grafite sobre o gradiente escuro da marca é quase invisível (achado real: presenca-em-ia/sobre/planos usam 'tags' com frase-âncora longa no hero; /faq/ usa 'tags' para o nome do grupo). Mesmos valores de .or-tag--invert, mas por ESCOPO DE DESCENDÊNCIA (não modificador): página nova com hero + tags herda o contraste certo sem lembrar de aplicar a classe --invert no PHP. / .or-hero-interno--comercial .or-tag, .or-hero-interno--listagem .or-tag, .or-hero-interno--editorial .or-tag, .or-hero-interno--doc .or-tag { border-color: rgba(var(--color-white-rgb), .3); color: var(--color-white); } .or-hero-interno--comercial .or-tag:hover, .or-hero-interno--listagem .or-tag:hover, .or-hero-interno--editorial .or-tag:hover, .or-hero-interno--doc .or-tag:hover { border-color: var(--color-white); background: rgba(var(--color-white-rgb), .08); color: var(--color-white); } / Mesmo caso do .or-tag, para o contador ("N artigos" em /blog, "N perguntas" em /faq): .or-hero-internostat nasce var(--marca-primaria), que sobre o gradiente feito DA PRÓPRIA MARCA é ilegível. A única regra que existia era [data-bs-theme="dark"] (linha ~472) — override de TEMA, não de VARIANTE: no tema claro (default) o stat ficava azul-sobre-azul. ⚠️ `listagem` é quem usa `stat` em /faq — esquecê-la aqui apagaria o número da tela. NÃO usar --or-brand-accent: no claro essa variável É var(--marca-primaria) pura (or-dark.css:22) — a mesma cor do problema. / .or-hero-interno--comercial .or-hero-internostat, .or-hero-interno--listagem .or-hero-internostat, .or-hero-interno--editorial .or-hero-internostat, .or-hero-interno--doc .or-hero-internostat { color: var(--color-white); } / ── O que é EXCLUSIVO de cada variante ──────────────────────────────────────────────────────── / / --comercial: título em display — frase-âncora curta das páginas do funil (serviços/sobre/planos/ contato/presença em IA/detalhe de serviço). / .or-hero-interno--comercial .or-hero-internotitle { font-size: var(--or-fs-display); } .or-home-heroglow, .or-hero-internoglow { position: absolute; inset: 0; z-index: -1; background: radial-gradient(60% 60% at 82% 22%, rgba(232, 181, 61, .16) 0%, transparent 70%); pointer-events: none; } / --editorial: título com largura de PROSA (não estica a linha até a borda em telas largas) — post/artigo do blog. O resto (fundo, tintas, breadcrumb) já vem do bloco comum acima; aqui fica só o que é exclusivo: a medida de leitura e o tom discreto do eyebrow (metadado do artigo — categoria · data · tempo de leitura —, não etiqueta de campanha como nas outras três). NÃO virou `--comercial`: aquela variante usa `--or-fs-display` (até 88px), calibrado para frase-âncora curta de página de venda — um título de artigo real ("O que muda quando seu negócio aparece nas respostas de IA") em 88px ocuparia a tela inteira. A tipografia de prosa é o que distingue as duas, não mais a superfície (unificada em 08/09/2026). / .or-hero-interno--editorial .or-hero-internotitle { max-width: 900px; } .or-hero-interno--editorial .or-eyebrow { color: rgba(255, 255, 255, .78); opacity: 1; text-transform: none; letter-spacing: 0; font-weight: 500; } .or-hero-interno--editorial .or-eyebrow::before { background: var(--or-dourado); } / --doc: título compacto — políticas/acessibilidade/FAQ-detalhe/página CMS genérica. Documento legal não é campanha; o degradê entrou em 08/09/2026 (pedido do dono, "seguir a padronização do hero de /presenca-em-ia"), mas o título continua menor que o das páginas de venda — é a única coisa que ainda distingue esta variante das demais. `--or-fs-secao-compacta` (não `--or-fs-secao`): não deve herdar o teto de 64px do D3. / .or-hero-interno--doc .or-hero-interno__title { font-size: var(--or-fs-secao-compacta); } / --- Tag list (usada por _hero-interno.php E pela seção "Para quem é" da home) — o Quanto não tem componente de chip/tag nativo (nenhuma ocorrência de .tag/.chip/.badge em style.css). --- / .or-tag-list { display: flex; flex-wrap: wrap; gap: 12px; list-style: none; margin: 0; padding: 0; } .or-tag-list--center { justify-content: center; } .or-tag { display: inline-flex; align-items: center; padding: 10px 22px; border-radius: 40px; border: 1px solid var(--color-1); font-size: 15px; font-weight: 600; color: var(--color-primary); transition: all .3s ease; } .or-tag:hover { border-color: var(--marca-primaria); color: var(--marca-primaria); } .or-tag--invert { border-color: rgba(var(--color-white-rgb), .3); color: var(--color-white); } .or-tag--invert:hover { border-color: var(--color-white); background: rgba(var(--color-white-rgb), .08); color: var(--color-white); } / --- Estado .active do filtro (evolução F7, achado: portfolio.php/produtos.php alternam a classe .active via JS — data-filter — mas ela nunca teve CSS; o chip "selecionado" ficava visualmente idêntico aos demais, nenhuma pista de qual filtro estava ativo). Reusa .or-tag/.or-portfolio- filtro em ambas as páginas (mesmo componente, nomeado só uma vez). / .or-tag.active, .or-portfolio-filtro.active { background: var(--marca-primaria); border-color: var(--marca-primaria); color: var(--color-white); } .or-tag.active:hover, .or-portfolio-filtro.active:hover { border-color: var(--marca-secundaria, var(--marca-primaria)); background: var(--marca-secundaria, var(--marca-primaria)); color: var(--color-white); } / --- .or-social-links/.or-social-link (Social::render()/::shareButtons(), includes/Social.php) — evolução F7, achado: 0% de CSS em 3 usos reais (compartilhar do post, redes de equipe-membro, redes de parceiro) — os apareciam como link cru, ícone SVG do tamanho que Icon::render() emitir, sem alinhamento. Botões circulares 40px (mesmo vocabulário de .or-tag: borda neutra, hover preenche com a marca). --- / .or-social-links { display: flex; flex-wrap: wrap; align-items: center; gap: 10px; } .or-social-link { display: inline-flex; align-items: center; justify-content: center; width: 40px; height: 40px; border-radius: 50%; border: 1px solid var(--color-1); color: var(--color-primary); transition: all .3s ease; } .or-social-link svg { width: 18px; height: 18px; } .or-social-link:hover { background: var(--marca-primaria); border-color: var(--marca-primaria); color: var(--color-white); } [data-bs-theme="dark"] .or-social-link { border-color: var(--or-border); } / --- Filtro de /portfolio e /produtos — transição suave no show/hide (evolução F7; MixItUp tentado e revertido por bug real no build do vendor, ver docblock de or-tema-motion.js). Não colapsa o espaço do item no grid ao esconder — isso exigiria recalcular o layout via JS (o que é literalmente o que o MixItUp faria se funcionasse); troca visível é opacidade+escala, não um reflow perfeito, mas já é muito melhor que o display:none instantâneo anterior. visibility com transition-delay: ao esconder, primeiro perde opacidade, só sai da árvore de acessibilidade DEPOIS da animação; ao reaparecer, visibility volta na hora e a opacidade some com ela. / .or-portfolio-filter-item { transition: opacity .35s ease, transform .35s ease; } .or-portfolio-filter-item--oculto { opacity: 0; transform: scale(.92); pointer-events: none; visibility: hidden; transition: opacity .35s ease, transform .35s ease, visibility 0s .35s; } / Compartilhar do post (post.php) — label + botões na mesma linha. / .or-blog-share { display: flex; align-items: center; flex-wrap: wrap; gap: 14px; } / --- .or-empty — estado vazio padrão (evolução F7, achado: 9 listagens usavam só um
cru, sem peso visual nenhum). var(--or-text-muted) já é dark-safe (mesmo token de .t-muted) — sem override extra necessário. --- / .or-empty { text-align: center; padding: 60px 20px; } .or-emptyicon { display: inline-flex; align-items: center; justify-content: center; width: 48px; height: 48px; margin-bottom: 18px; color: var(--or-text-muted); } .or-emptyicon svg { width: 100%; height: 100%; } .or-empty__titulo { color: var(--color-primary); margin-bottom: 0; } / ================================================================ MEGA-RODAPÉ EDITORIAL (_rodape.php) — F3 do plano de alinhamento de layout/estrutura (26/08/2026). Substitui as ~290 linhas de CSS de rodapé do vendor que nunca tiveram markup correspondente (style.css 5877-5879, 5884-5933, 5996-6010, 6046-6109, 6150-6236, 6238-6345) e as classes vivas que embutiam a armadilha de flip abaixo. REGRA DE COR — o rodapé é a ÚNICA superfície PERMANENTEMENTE ESCURA nos dois temas (a regra dark mais abaixo força footer.bg-color-primary → --or-surface-2, pra impedir a inversão fotográfica que trataria isto como "card claro"). Nesse contexto var(--color-white)/ var(--color-primary) são ARMADILHA — os dois FLIPAM no dark (bloco de tokens acima) e viram quase-preto sobre fundo escuro. Bug VIVO achado nesta fase: style.css:5963 (.footer-widgets .widget-links{color:var(--color-white)}) media ~1,05:1 de contraste no dark. Por isso os tokens abaixo são LITERAIS rgba() — imunes ao flip, um único ponto de ajuste. Mesmo raciocínio já usado em .or-llms-file (janela de terminal) e no bezel de .or-device--phone. Contraste medido sobre o fundo real do rodapé (bg-color-primary claro / --or-surface-2 dark): --or-rd-tinta (#fff) ≈ 15:1 → títulos --or-rd-tinta-2 (rgba(255,255,255,.78)) ≈ 9,5:1 → corpo de texto e links (AA normal ✔) --or-rd-tinta-3 (rgba(255,255,255,.58)) ≈ 5,8:1 → texto auxiliar/copyright (AA normal ✔ — PISO) --or-rd-borda (rgba(255,255,255,.14)) ≈ 3,2:1 → fronteira de componente (1.4.11 ✔) Nada abaixo de .58 pode carregar texto. ================================================================ / .or-rd { --or-rd-tinta: #fff; --or-rd-tinta-2: rgba(255, 255, 255, .78); --or-rd-tinta-3: rgba(255, 255, 255, .58); --or-rd-camada: rgba(255, 255, 255, .05); --or-rd-camada-2: rgba(255, 255, 255, .09); --or-rd-borda: rgba(255, 255, 255, .14); / Default real (não só o fallback do var()): _rodape.php sempre sobrescreve por instância via style="--or-rd-cols:N" no
(3 ou 4 colunas conforme o banco — PHP conta em runtime, nunca auto-fit, pra não esticar 2 colunas a 50% cada ao lado da coluna de marca). Mesmo padrão de --or-fab-lift (fab-stack.php:116 declara :root com default, lgpd-banner.js sobrescreve depois via setProperty) — aqui é local ao componente, não ao documento. / --or-rd-cols: 3; color: var(--or-rd-tinta-2); } / .or-pg (sistema tipográfico) termina no mainClose(), ANTES do
— todo h2..h4 aqui cai no CRU do vendor (h2=100px, h3=80px, style.css:120-152) com color:var(--color-black) (#000, nunca flipado → invisível no rodapé escuro). Cada heading precisa de font-size E color explícitos por isso — é a causa raiz de o rodapé antigo usar
(24px) com .text-color-white: não era escolha semântica, era o único par que "funcionava". / .or-rd :is(h2, h3, h4) { color: var(--or-rd-tinta); } / --- Andar 1: faixa de CTA (condicional — só home/404, ver _rodape.php) --- / .or-rd-cta { position: relative; isolation: isolate; overflow: hidden; padding-block: clamp(56px, 6vw, 88px); / −32px de ar puro: abre espaço para a escada de atrito sem crescer a faixa. / background: var(--or-grad-marca); text-align: center; } .or-rd-ctaglow { position: absolute; inset: 0; z-index: 0; pointer-events: none; background: radial-gradient(55% 65% at 50% 30%, rgba(232, 181, 61, .18) 0%, transparent 70%); } / Marquee decorativo — era .or-rd-ctamarquee, só aqui. Virou componente compartilhado (05/09/2026, F2 do alinhamento de layout): .or-marquee-fundo, BLOCO 21 mais abaixo neste arquivo — usado também por .or-secao-cta e pagina-planos.php. / .or-rd-ctaconteudo { position: relative; z-index: 1; } / !important obrigatório — achado ao vivo de 29/08/2026 (print do dono, eyebrow "PRÓXIMO PASSO" literalmente invisível): esta regra sempre tentou color:var(--or-dourado), mas .or-eyebrow base (~linha 1043, color:var(--marca-primaria)) empata em especificidade (0,1,0 cada) e vem DEPOIS no arquivo — a base vencia. Medido: texto var(--marca-primaria) sobre var(--or-grad-marca), a MESMA cor de marca como fundo, 1,00:1. .or-rd-cta nunca muda no escuro (fundo fixo, ver comentário do bloco acima) — dourado é seguro nos dois temas, sem variante. / .or-rd-ctaeyebrow { justify-content: center; color: var(--or-dourado) !important; } .or-rd-ctatitulo { font-size: var(--or-fs-secao); line-height: 1.1; letter-spacing: -.02em; margin-bottom: 12px; } .or-rd-ctasub { max-width: 560px; margin: 0 auto 32px; font-size: var(--or-fs-lead); color: var(--or-rd-tinta-2); } / Botão dourado: MESMO papel do .or-secao-ctabtn (ponto nº3 da lista fechada do dourado) — as duas faixas nunca coexistem na mesma página ($orCtaEmitido), então não há 2º ponto dourado. / .or-rd-ctabtn.quanto-link-btn.btn-pill, .or-rd-ctabtn.quanto-link-btn.btn-pill span .arry1, .or-rd-ctabtn.quanto-link-btn.btn-pill span .arry2 { color: var(--or-ink-deep); } .or-rd-ctabtn.quanto-link-btn.btn-pill { background-color: var(--or-dourado); border-color: var(--or-dourado); } / --- Andar 2: corpo (marca + colunas de links) --- / .or-rd-corpo { padding-block: clamp(56px, 6vw, 88px); } / 1fr|2.15fr desde 28/08/2026 (era 1.1fr|2.6fr): com a coluna "Links" removida sobraram 3 colunas, e a proporção antiga deixava a zona de links larga demais enquanto a marca continuava com buraco. Medido a 1580px: marca ≈481px, links ≈1035px → 3 colunas de ~329px (eram 248px). / .or-rd-topo { display: grid; grid-template-columns: minmax(0, 1fr) minmax(0, 2.15fr); gap: 48px 64px; padding-bottom: 56px; border-bottom: 1px solid var(--or-rd-borda); } / Casos degenerados — fork sem serviços e/ou sem contato cadastrados. Sem isto, 1 coluna solitária esticaria por toda a zona B. Mesma doutrina da contagem server-side: grade determinística. / .or-rd-topo--cols-1, .or-rd-topo--cols-2 { grid-template-columns: minmax(0, 1fr) minmax(0, 1.4fr); } @media (max-width: 991.98px) { .or-rd-topo, .or-rd-topo--cols-1, .or-rd-topo--cols-2 { grid-template-columns: 1fr; gap: 40px; padding-bottom: 40px; } } / 440px (era 380px): a zona da marca ficou mais larga com a nova proporção, e o texto precisa de teto de medida de leitura — sem ele a descrição estica além do confortável. / .or-rd-marca { max-width: 440px; } .or-rd-marcalogo { display: inline-block; margin-bottom: 24px; } .or-rd-marcalogo img { max-height: 40px; width: auto; display: block; } .or-rd-marcanome { font-size: 1.375rem; font-weight: 700; color: var(--or-rd-tinta); margin-bottom: 16px; } .or-rd-marcatexto { font-size: .95rem; line-height: 1.65; color: var(--or-rd-tinta-2); margin-bottom: 0; overflow-wrap: anywhere; } .or-rd-social { margin-top: 28px; } .or-rd-sociallista { display: flex; flex-wrap: wrap; gap: 10px; list-style: none; margin: 0; padding: 0; } .or-rd-sociallink { display: inline-flex; align-items: center; justify-content: center; width: 42px; height: 42px; border-radius: 50%; border: 1px solid var(--or-rd-borda); color: var(--or-rd-tinta); transition: background-color .15s ease, border-color .15s ease, transform .15s ease; } .or-rd-sociallink svg { width: 18px; height: 18px; } / `color` reafirmado no :hover pela MESMA razão do .or-secao-ctacanal (ver a nota longa no BLOCO 11): a regra global `a:hover` deste arquivo pinta todo com --marca-secundaria, e sobre o rodapé (--or-rd-camada, permanentemente escuro) isso derrubava o ícone social de branco para #082C6A — contraste medido de 1,19:1, praticamente invisível. A regra local já vencia por especificidade, mas declarava só background/border-color, e propriedade não declarada não é herdada da regra mais específica. / .or-rd-sociallink:hover { background: var(--or-rd-camada-2); border-color: var(--or-rd-tinta); color: var(--or-rd-tinta); transform: translateY(-2px); } / Colunas: N vem de PHP via --or-rd-cols (custom property inline no
). Com auto-fit, 2 colunas restantes esticariam a 50% cada ao lado da coluna de marca — contagem server-side deixa a grade determinística nos 3 estados reais (3/4/5 colunas conforme banco). / .or-rd-links { display: grid; grid-template-columns: repeat(var(--or-rd-cols, 3), minmax(0, 1fr)); gap: 40px 24px; } @media (max-width: 991.98px) { .or-rd-links { grid-template-columns: repeat(2, minmax(0, 1fr)); } } @media (max-width: 479.98px) { .or-rd-links { grid-template-columns: 1fr; gap: 32px; } } / minmax(0,1fr) no TRACK não basta — o ITEM de grid ainda nasce com min-width:auto por padrão (a "gotcha" clássica do CSS Grid), então um link/e-mail longo sem espaço pra quebrar podia estourar a coluna mesmo com o track corretamente limitado. / .or-rd-col { min-width: 0; } .or-rd-col__titulo { font-size: .8125rem; font-weight: 600; letter-spacing: .1em; text-transform: uppercase; color: var(--or-rd-tinta); margin-bottom: 20px; } .or-rd-lista { list-style: none; margin: 0; padding: 0; display: flex; flex-direction: column; gap: 12px; } / Sublinhado deslizante — mesma técnica do vendor (style.css:5983-5995), reescrita com tinta imune a flip. .or-rd-link serve e
. --- / .or-lead { / 18px→var(--or-esp-5) em 05/09/2026: era o único valor da família de margem que ficava abaixo do PISO de 24px que o próprio CLAUDE.md declara entre blocos irmãos — alinha os ~11 usos ao mesmo piso do fallback global logo acima, sem mudar o valor de baixo. / margin-top: var(--or-esp-5); margin-bottom: var(--or-esp-5); max-width: 640px; font-size: var(--or-fs-lead); / era 18px fixo, ignorava o token (D2 — mesma família) / line-height: 1.6; color: var(--color-primary); opacity: .75; } .or-lead:last-child { margin-bottom: 0; } / --- Diferenciais (seção "Por que OneRank", #painel + /sobre) — lista title+descrição, não chip (BLC_TEXTO tem conteúdo real por item, diferente dos segmentos de "Para quem é", que são só um rótulo). margin-top era 28px — valor solto, fora da escala --or-esp-* (4/8/12/16/24/32/48/64, custom.css :root). --or-esp-6 é o degrau de "bloco↔bloco com troca de assunto" (texto→lista), exatamente o papel aqui — achado na auditoria de 29/08/2026. --- / .or-diferenciais-list { list-style: none; margin: var(--or-esp-6) 0 0; padding: 0; display: flex; flex-direction: column; gap: 18px; } .or-diferenciais-list li { padding-top: 18px; border-top: 1px solid var(--color-1); } .or-diferenciais-list li:first-child { border-top: none; padding-top: 0; } .or-diferenciais-list strong { display: block; font-size: 17px; font-weight: 600; color: var(--color-primary); margin-bottom: 4px; } .or-diferenciais-list span { display: block; font-size: 15px; color: var(--color-primary); opacity: .68; } / --- Planos: selo do tier recomendado + sufixo de periodicidade no preço --- / .or-pricing-tag { position: absolute; top: 24px; right: 24px; z-index: 1; background: var(--marca-primaria); color: var(--color-white); font-size: 11px; font-weight: 700; letter-spacing: .02em; text-transform: uppercase; padding: 6px 14px; border-radius: 40px; } .or-pricing-periodo { font-size: 16px; font-weight: 500; opacity: .55; margin-left: 2px; } / .pricing (h3, o preço em si) não tem font-size próprio no vendor (style.css:5221 só define margin/transition) — cai no h3 CRU de 80px. Medido: "R$1.499/mês" preenche os 403px disponíveis do card por inteiro; um preço de 5 dígitos estouraria (D3/A3). --or-fs-secao-compacta (não a --or-fs-secao de 64px) porque o card tem largura fixa, não deve crescer com a viewport. / .quanto-pricing-box .pricing { font-size: var(--or-fs-secao-compacta); letter-spacing: -.02em; } / --- Card do tier recomendado (evolução F4, plano "borda superior dourada + elevação") — 1 dos 6 pontos fechados de uso do dourado (BLOCO 0.5). border-top segue o raio do próprio box por padrão do CSS (mesma técnica de .or-planos-tablerecomendada, BLOCO 4). --- / .quanto-pricing-box.or-card--recomendado { border-top: 3px solid var(--or-dourado); box-shadow: var(--or-shadow-brand); } / --- Hierarquia de ação (D.5) — antes os 3 CTAs de #planos competiam igual (mesmo pill sólido). O card RECOMENDADO mantém o pill sólido; os outros 2 viram outline — mesma forma/tamanho, sem disputar destaque com o card que a própria OneRank usa. Escopado pela AUSÊNCIA de .or-card--recomendado — zero classe nova no markup dos 2 CTAs. No :hover, a regra existente (~acima, "botão CONTINUA invertendo") já cobre os 3 igual: outline também vira preenchido. / .quanto-pricing-box:not(.or-card--recomendado) .quanto-link-btn.btn-pill { background-color: transparent; border-color: var(--color-primary); } .quanto-pricing-box:not(.or-card--recomendado) .quanto-link-btn.btn-pill, .quanto-pricing-box:not(.or-card--recomendado) .quanto-link-btn.btn-pill span, .quanto-pricing-box:not(.or-card--recomendado) .quanto-link-btn.btn-pill span .arry1, .quanto-pricing-box:not(.or-card--recomendado) .quanto-link-btn.btn-pill span .arry2 { color: var(--color-primary); } / --- Bloco de ativação (D.4, 29/08/2026) — a home nunca mencionava a ativação de R$ 1.199 nem como o processo funciona (só /planos tinha); "quanto custa pra começar" ficava sem resposta no ponto exato da decisão. Superfície --color-2 (mesmo token de .or-planos-addonsitem — precedente de "card sobre section branca"), 4 passos em grid (2 no tablet, 1 no mobile — nunca 3, que quebraria a leitura par/ímpar), número em círculo espelhando .or-etapas-acordeaonum (mesma forma, cor de marca em vez de branco-sobre-escuro porque aqui o fundo é claro). / .or-ativacao { background: var(--color-2); border-radius: var(--or-radius-l); padding: var(--or-esp-7) var(--or-esp-6); } .or-ativacaopassos { list-style: none; margin: 0 0 var(--or-esp-6); padding: 0; display: grid; grid-template-columns: repeat(4, 1fr); gap: var(--or-esp-6); } .or-ativacaonum { display: inline-flex; align-items: center; justify-content: center; width: 32px; height: 32px; margin-bottom: var(--or-esp-3); border-radius: 50%; background: var(--marca-primaria); color: #fff; font-size: .9rem; font-weight: 700; } .or-ativacaopassos strong { display: block; font-size: 16px; font-weight: 600; color: var(--color-primary); margin-bottom: 4px; } .or-ativacaopassos p { font-size: var(--or-fs-small); color: var(--color-primary); opacity: .68; margin: 0; } .or-ativacaoaviso { padding-top: var(--or-esp-6); border-top: 1px solid var(--color-1); font-size: var(--or-fs-lead); color: var(--color-primary); margin: 0 0 var(--or-esp-3); } .or-ativacaoreforco { font-size: var(--or-fs-small); color: var(--color-primary); opacity: .6; margin: 0; } @media (max-width: 991.98px) { .or-ativacaopassos { grid-template-columns: repeat(2, 1fr); } } @media (max-width: 575.98px) { .or-ativacao { padding: var(--or-esp-6) var(--or-esp-5); } .or-ativacao__passos { grid-template-columns: 1fr; } } / ================================================================ DARK MODE — Camada 3 do adapter (Quanto). Equivalente ao bloco "ADAPTER do template atual" que normalmente vive em site/assets/css/or-dark.css (core) — mas esse arquivo é CORE e tests/site_dark_test.php trava os seletores do Canvas 7 que já estão lá. O adapter do Quanto mora aqui, no fork. Usa os tokens --or-* (Camada 2, core, template-agnóstica — já ativa globalmente assim que or-dark.css carrega) e var(--marca-primaria) (já remapeada por Colors::toCssVars()) — nunca cor hardcoded. ATIVADO — F9 (25/08/2026): `site_dark_ativo=true`, as 29 páginas do site já são Quanto (migração Azurio→Quanto completa), então o flip abaixo se aplica ao site inteiro sem risco de quebrar página em template antigo. ================================================================ / [data-bs-theme="dark"] { / Par de tintas duplas do Quanto: --color-white é usado como TEXTO (h1..h6 sobre fundo escuro, .text-color-white) e como FUNDO (cards claros); --color-primary é usado como FUNDO (footer, process-box, menu escuro do próprio design claro) e como TEXTO (body/headings/.main-menu a). Os dois papéis trocam de lugar no escuro. / --color-white: var(--or-surface); --color-primary: var(--or-text); / --color-2 é usado SÓ como FUNDO de card sutil (form-control, sidebar de candidatura, card de filial, add-on de planos) — papel único, sem par a trocar, então flipa direto pra superfície escura secundária. Achado F9: sem isto, esses cards ficavam claros (#f5f5f5) e o texto var(--color-primary) dentro deles virava --or-text (quase branco) — texto quase invisível sobre fundo quase branco (contraste ~1.03:1, medido ao vivo). / --color-2: var(--or-surface-2); } / Títulos: --color-black NUNCA é flipado globalmente (ver nota abaixo) — cobertos por seletor, com o token de TEXTO (não a marca — títulos usam neutro, a marca fica pros acentos). / [data-bs-theme="dark"] :is(h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6) { color: var(--or-text); } / Blocos JÁ escuros no claro (fundo --color-primary/--color-3 + texto branco fixo via .text-color-white) — sem isto, ficariam CLAROS no escuro (inversão fotográfica errada: o footer e os cards de processo, que já são a superfície mais escura do design CLARO, teriam fundo clareado bem no momento em que o resto da página escurece). / [data-bs-theme="dark"] footer.bg-color-primary, [data-bs-theme="dark"] section.bg-color-primary, [data-bs-theme="dark"] div.bg-color-primary, [data-bs-theme="dark"] .process-box, [data-bs-theme="dark"] .quanto-mobile-menu-btn .social-btn a { background-color: var(--or-surface-2) !important; } [data-bs-theme="dark"] .text-color-white { color: var(--or-text) !important; } / Header (bg-color-white + sticky) e dropdown do menu principal — sem isto o header "claro" fica invisível contra o resto da página escurecida. / [data-bs-theme="dark"] .quanto-header.bg-color-white .sticky-active { background-color: var(--or-surface) !important; } [data-bs-theme="dark"] .main-menu ul.sub-menu { background-color: var(--or-surface) !important; box-shadow: var(--or-elev); } / Menu mobile: painel branco fixo (.quanto-menu-area) vira superfície escura; o backdrop preto (rgba(var(--color-black-rgb),.6)) continua preto — --color-black NÃO É FLIPADO acima de propósito: tem 5 usos que se contradizem (h1..h6{color:var(--color-black)} quereria inverter, mas o MESMO token faz o overlay do menu mobile — flipá-lo globalmente afundaria um overlay BRANCO cobrindo a tela inteira ao abrir o menu). Cobrimos só os pontos que precisam mesmo flipar, por seletor — nunca a variável inteira. / [data-bs-theme="dark"] .quanto-menu-wrapper .quanto-menu-area, [data-bs-theme="dark"] .quanto-menu-wrapper .mobile-logo { background-color: var(--or-surface) !important; } / #blog trocou bg-color-2→bg-color-white (29/08/2026, achado ao vivo na reordenação #faqs/#blog: #planos(branco)→#faqs ficaria colado se #faqs continuasse branco — #faqs virou o cinza livre, #blog assumiu o branco). .quanto-blog-content perdeu o contraste natural do cinza atrás dele; sombra própria substitui. var(--or-shadow-1) já é dark-mode-aware (vira `none` no escuro, linha ~116 — o card já ganha diferenciação por cor de fundo lá, sombra seria redundante). / .quanto-blog-content.bg-color-white { box-shadow: var(--or-shadow-1); } / Cards com fundo claro fixo (bg-color-2/bg-color-white) — flipam pra superfície escura / [data-bs-theme="dark"] .quanto-pricing-box, [data-bs-theme="dark"] .quanto-service-box3.bg-color-white, [data-bs-theme="dark"] .testimonial3-content { background-color: var(--or-surface) !important; color: var(--or-text); } [data-bs-theme="dark"] section.bg-color-2, [data-bs-theme="dark"] .bg-color-2:not(.slider-arrow-left):not(.slide-btn) { background-color: var(--or-surface-2) !important; } / .quanto-blog-content.bg-color-white SAIU do grupo acima (29/08/2026, achado ao vivo na troca de fundo #blog: bg-color-2→bg-color-white — ver comentário na abertura da seção, home.php) — a SEÇÃO também é .bg-color-white, e --color-white flipa pra --or-surface (linha ~1874). Ficando no grupo acima, o CARD flipava pro MESMO --or-surface da seção — mesclava, invisível, com a sombra desligada de propósito no escuro (--or-shadow-1:none). --or-surface-2 (1 degrau mais claro, o mesmo token que .quanto-pricing-box usa contra a seção branca de #planos — ver o .bg-color-2 acima) devolve a distinção sem depender de sombra. / [data-bs-theme="dark"] .quanto-blog-content.bg-color-white { background-color: var(--or-surface-2) !important; color: var(--or-text); } / Acento da marca clareado no escuro (mesmo tratamento do Canvas em or-dark.css). Achado F9: todo uso de var(--marca-primaria) como COR DE TEXTO/ícone (não fundo) precisa entrar aqui — o azul cru (#0B3D91) tem só ~1,7:1 de contraste contra as superfícies escuras (--or-surface/-2), var(--or-brand-accent) é a MESMA marca clareada (color-mix c/ branco, já usada por Locale/links). / [data-bs-theme="dark"] .accordion-button:not(.collapsed), [data-bs-theme="dark"] .or-tag:hover, [data-bs-theme="dark"] .or-breadcrumb a:hover, [data-bs-theme="dark"] .or-secao-ctalink:hover .title, [data-bs-theme="dark"] .or-servico-icon svg { color: var(--or-brand-accent) !important; } / Componentes que já nasciam ESCUROS no claro (texto var(--color-white) sobre fundo próprio escuro OU sobre var(--marca-primaria), que nunca flipa — newsletter do rodapé, chips invertidos de "Para quem é", selo de plano recomendado, CTA azul do header): sem isto, o flip global de --color-white (linha acima) escurece o TEXTO, resultado quase ilegível (~1:1 a ~1,8:1, medido ao vivo). O CTA do header é o mais grave dos achados — está em TODAS as 29 páginas, acima da dobra. Mesmo raciocínio de .text-color-white (linha 487), só que aplicado a regras que fixam a cor direto (não usam a classe utilitária do vendor). / [data-bs-theme="dark"] .or-tag--invert, [data-bs-theme="dark"] .or-tag--invert:hover, [data-bs-theme="dark"] .or-tag.active, [data-bs-theme="dark"] .or-tag.active:hover, [data-bs-theme="dark"] .or-portfolio-filtro.active, [data-bs-theme="dark"] .or-portfolio-filtro.active:hover, [data-bs-theme="dark"] .or-social-link:hover, [data-bs-theme="dark"] .or-pricing-tag, [data-bs-theme="dark"] .quanto-header .quanto-link-btn.btn-pill, [data-bs-theme="dark"] .quanto-header .quanto-link-btn.btn-pill span .arry1, [data-bs-theme="dark"] .quanto-header .quanto-link-btn.btn-pill span .arry2, [data-bs-theme="dark"] .or-secao-cta--soft .or-secao-ctabtn.quanto-link-btn.btn-pill, [data-bs-theme="dark"] .or-secao-cta--soft .or-secao-ctabtn.quanto-link-btn.btn-pill span .arry1, [data-bs-theme="dark"] .or-secao-cta--soft .or-secao-ctabtn.quanto-link-btn.btn-pill span .arry2 { color: var(--or-text) !important; } / Form-control do vendor (.quanto-contactform — contato.php/pagina-planos.php): a cor de texto é #6b6b6b HARDCODED no style.css (style.css:5837, não é var()), calibrada pro fundo claro original — o flip de --color-2 acima (que corrige o FUNDO) não alcança essa declaração. Sem este pin o texto digitado ficaria cinza-médio sobre o novo fundo escuro (~3,4:1, abaixo do 4.5:1 exigido). / [data-bs-theme="dark"] .quanto-contactform .form-control { color: var(--or-text) !important; } / ================================================================ BLOCO 3.5 — HOVER-OVERLAY: tinta imune ao flip de tema Posicionado DEPOIS do bloco DARK acima de propósito: [data-bs-theme="dark"] .process-box (0,2,0) empata em especificidade com .process-box:hover (0,2,0) — quem vence é a ORDEM no arquivo. Os tokens --or-hover-painel/--or-hover-tinta (bloco 0.5, ~linha 261) resolvem o par painel/texto do #dor; aqui consumimos --or-hover-tinta no seletor que o vendor deixou de pé (style.css:5727-5733 calibrou a cor de texto pro overlay ORIGINAL, não pro azul de marca único que passou a ser injetado). --- / / !important obrigatório: o markup traz .text-color-white em .process-title/p (home.php) e a regra de ~linha 487 força [data-bs-theme=dark] .text-color-white{color:var(--or-text) !important}. Sem !important aqui, no ESCURO o título do hover ficaria var(--or-text) sobre --or-hover-painel (que é quase branco) — a correção criaria um bug PIOR que o original (medido: ~1:1). / .process-box:hover .process-number::before, .process-box:hover .process-info .process-title, .process-box:hover .process-info p { color: var(--or-hover-tinta) !important; } / Card de PREÇO (#planos + /planos) — a inversão de cor no hover foi DESLIGADA em 29/08/2026, achado ao vivo do dono ("Autoridade" apagado no print): o overlay que deveria dar contraste ao texto branco é injetado por JS (main.js:254-267) e animado pelo GSAP em 0,5s, DESSINCRONIZADO da troca instantânea de cor via CSS puro (esta era a regra .quanto-pricing-box:hover{color:var( --or-hover-tinta)} que existia aqui). Resultado medido em qualquer frame da transição — e sempre que o overlay simplesmente não existe (achado secundário: main.js só o injeta dentro de um DOMContentLoaded aninhado; se disparar tarde, o overlay NUNCA existe): texto branco sobre bg-color-2 (#f5f5f5), 1,09:1 — WCAG AA exige 4,5:1. Num card de PREÇO o visitante está lendo comparativamente; apagar o que ele está lendo no hover é hostil à própria tarefa. O overlay sai (display:none — .process-box do #dor continua com o efeito, seletor não o alcança) e o card passa a se destacar só por elevação/sombra, nunca por troca de paleta — os valores abaixo são os MESMOS tokens que o vendor usa em repouso (style.css:97-104 h1-h6→var(--color-black); o corpo do card herda var(--color-primary) do body/section, sem regra própria), só re-declarados para vencer o .quanto-pricing-box:hover{color:var(--color-white)} do vendor (style.css:5284-5290). / .quanto-pricing-box .hover-overlay { display: none; } .quanto-pricing-box:hover, .quanto-pricing-box:hover .pricing-info, .quanto-pricing-box:hover .pricing-list ul li { color: var(--color-primary); } .quanto-pricing-box:hover .pricing-title, .quanto-pricing-box:hover .pricing { color: var(--color-black); } .quanto-pricing-box:hover { / SÓ sombra, sem translateY — achado ao vivo: os 3 cards carregam .fade-anim (entrada data-direction="right"), e main.js:464-528 nunca chama clearProps depois do tween. GSAP deixa `transform` como estilo INLINE (mesmo resolvendo pra translate(0,0)) — inline sempre vence regra externa na mesma propriedade, :hover ou não, sem !important. Testado ao vivo: um translateY aqui não se manifestava depois do card entrar em cena. box-shadow não é tocado pelo GSAP, então funciona sempre, sem essa disputa. / box-shadow: var(--or-shadow-brand); transition: box-shadow .3s ease-in-out; } / Rótulo do CTA do card de plano EM REPOUSO — o bloco de acento de marca (~linha 261) trocou o FUNDO do botão pra marca e deixou o color:var(--color-primary) do vendor (style.css:5270) de pé: 1,57:1 medido ao vivo, SEM hover, na home E em /planos — "Solicitar diagnóstico" ilegível no estado padrão, no ponto exato de conversão, em 6 cards. #fff literal porque o fundo é var(--marca-primaria), que não flipa. / .quanto-pricing-box .quanto-link-btn.btn-pill, .quanto-pricing-box .quanto-link-btn.btn-pill span, .quanto-pricing-box .quanto-link-btn.btn-pill span .arry1, .quanto-pricing-box .quanto-link-btn.btn-pill span .arry2 { color: #fff; } / O botão CONTINUA invertendo no hover (fundo branco / texto marca) — é CSS puro, sem dependência de JS/timing, e o contraste em QUALQUER ponto da transição de 0,5s já foi medido legível (a troca de bg e de texto correm juntas, no mesmo transition). Diferente do bug acima: não é a mesma família de defeito, é uma affordance de botão que funciona. Não tocar. / .quanto-pricing-box:hover .quanto-link-btn.btn-pill { background-color: #fff; border-color: #fff; } .quanto-pricing-box:hover .quanto-link-btn.btn-pill, .quanto-pricing-box:hover .quanto-link-btn.btn-pill span, .quanto-pricing-box:hover .quanto-link-btn.btn-pill span .arry1, .quanto-pricing-box:hover .quanto-link-btn.btn-pill span .arry2 { color: var(--marca-primaria); } / O selo ("⭐ Escolha da própria OneRank") NÃO precisa mais de tratamento de hover — a versão anterior invertia bg:#fff/texto:marca porque o CARD inteiro virava marca-primária sob o overlay (o selo "sumia como forma" sobre o próprio tom). Sem overlay, o fundo do card nunca muda no hover — o selo permanece com o MESMO bg:var(--marca-primaria) do repouso (:1743-1756 + o ajuste de cor no escuro, :1883), que já tem contraste correto nos dois temas. Uma regra de hover aqui voltaria a inverter o selo sobre um fundo que não mudou — bug novo, não correção. / / --- #geo — arquivo /llms.txt REAL exibido como "arquivo" (evolução F5). Fundo fixo escuro nos dois temas de propósito — é uma janela de código/terminal, não uma superfície do site (mesmo raciocínio do bezel do .or-device--phone: não flipa). --- / .or-llms-file { border-radius: var(--or-radius-l); overflow: hidden; box-shadow: var(--or-shadow-2); background: var(--or-ink-deep); } .or-llms-filebar { display: flex; align-items: center; gap: 6px; padding: 12px 16px; background: rgba(255, 255, 255, .06); } .or-llms-filenome { margin-left: 10px; font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-size: .82rem; color: rgba(255, 255, 255, .55); } .or-llms-fileconteudo { margin: 0; padding: 22px 20px; font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-size: .8rem; line-height: 1.65; color: rgba(255, 255, 255, .82); white-space: pre-wrap; word-break: break-word; max-height: 300px; overflow: hidden; / Fade em vez de corte seco — o conteúdo real varia de tamanho por instalação (nome/descrição/ nº de páginas), um max-height fixo cortaria no meio da palavra em vez de sinalizar "tem mais". / mask-image: linear-gradient(to bottom, #000 70%, transparent 100%); -webkit-mask-image: linear-gradient(to bottom, #000 70%, transparent 100%); } / --- #prova — cards de dogfooding (F5.4 da reestruturação: grid auto-fit no lugar de 3 breakpoints fixos — comporta 4 ou 5 cards sem regra nova). Reusa .or-card/.or-card--claro/.or-card--hover (BLOCO 0.5) em vez de repetir borda/raio/dark-pin — era a 4ª cópia do mesmo estilo escrito à mão. --- / .or-prova-grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); gap: 24px; } .or-prova-card { display: flex; flex-direction: column; gap: 12px; } .or-prova-cardico { color: var(--marca-primaria); } [data-bs-theme="dark"] .or-prova-cardico { color: var(--or-brand-accent); } / Chip de estado — tinta de marca a 12% sobre fundo, cor de marca no texto. (A receita nasceu em .or-economia-itembadge, removida em 03/09/2026 com a seção #economia; a documentação dela passa a viver aqui.) "Mostra estado, não afirma" (F5.4): só aparece quando há dado real por trás (ver($orLlmsDisponivel)/$indicadores[3]/contagem de controles — nunca texto fixo). POSIÇÃO (mudou em 09/09/2026): o chip desceu no markup — era ícone→CHIP→h3→p→botão, virou ícone→h3→p→CHIP→botão (home.php, pedido do dono sobre o "9 controles"). NENHUMA regra de margem foi acrescentada aqui, e isso é deliberado: .or-prova-card é flex column com gap:12px, ou seja REGIME A do CLAUDE.md (§Padrão de Espaçamento) — o filho não traz margem própria na direção do gap, senão margem + gap somam dobrado. Quem encosta o chip no botão é o `flex-grow:1` do
logo abaixo, que empurra tudo o que vem depois dele para o rodapé do card — o mesmo mecanismo que já alinhava os botões dos quatro cards entre si. / .or-prova-cardchip { display: inline-flex; align-self: flex-start; padding: 4px 12px; border-radius: 40px; background: color-mix(in srgb, var(--marca-primaria) 12%, transparent); color: var(--marca-primaria); font-size: .75rem; font-weight: 700; text-transform: uppercase; letter-spacing: .04em; } [data-bs-theme="dark"] .or-prova-cardchip { color: var(--or-brand-accent); } / font-size/line-height/letter-spacing do h4 vêm do bloco tipográfico (.or-pg .or-prova-card h4, ~linha 207) — aqui só peso e cor. ERA font-size:1.05rem FIXO (ignorava --or-fs-card, que daria 24px) + herdava letter-spacing:-1.5px do h4 cru do vendor (-8,9% do corpo — D2). / .or-prova-card h4 { font-weight: 700; color: var(--color-primary); margin: 0; } .or-prova-card p { font-size: 1rem; line-height: 1.6; color: var(--color-primary); opacity: .75; margin: 0; flex-grow: 1; } .or-prova-card .quanto-link-btn.btn-pill { align-self: flex-start; } / --- #painel "O painel é seu" — par de .or-device em escadinha (evolução F5; recomposto em 29/08/2026, achado ao vivo: a legenda do 1º device sumia sob o 2º). CAUSA: a escadinha era VERTICAL (margin-top:-70px). Entre os dois devices mora a legenda1 (F5.3) — 10px de margem + 1 linha de 14px = ~32px, e ela ocupa 100% do espaço entre os dois. .or-device tem fundo OPACO (--color-white) + z-index:2, então QUALQUER sobreposição vertical > 0 já cobria a legenda inteira — não era questão de calibrar o número do pull-up, a legenda é todo o espaço disponível. E o número nem era estável: com data-speed divergente nos dois devices (0.97 / 1.04) e o ScrollSmoother rodando com effects:true acima de 1025px (main.js:234), a distância real entre os dois oscilava durante o scroll. CORREÇÃO: a escadinha passou a ser só HORIZONTAL (72% alinhado à direita — já era o que dava a leitura de camada; o eixo Y é que sobrava problema). E o data-speed migrou do .or-device para o WRAPPER .or-painel-device (home.php), que envolve device+legenda como uma unidade só — antes só o device tinha data-speed e a legenda ficava para trás, então o device chegava a descer sobre a PRÓPRIA legenda nas posições em que o efeito o atrasava. --- / .or-device--secundario { max-width: 72%; margin: var(--or-esp-6) 0 0 auto; } @media (max-width: 991.98px) { .or-device--secundario { margin: var(--or-esp-6) 0 0; max-width: 100%; } } / Wrapper do par device+legenda em #painel — alvo do data-speed (home.php). Sem propriedades de layout de propósito: largura/alinhamento do recuo continuam em .or-device--secundario. / .or-painel-device { position: relative; } / Legenda sob cada device (F5.3) — hoje o visitante via 2 retângulos sem saber o que eram. / / color explícito, não --or-text-muted (auditoria A-12, 28/08/2026): o token resolvia para #6c757d, que sobre o #f5f5f5 de bg-color-2 dá 4,3:1 — reprova o mínimo AA de 4,5:1 para texto de 14px. Foi a ÚNICA falha real de contraste em 276 elementos medidos. #5a6268 dá 5,2:1. O dark tem token próprio logo abaixo, então só o claro precisa do override. / .or-devicelegenda { margin: 10px 0 0; font-size: var(--or-fs-small); color: #5a6268; } [data-bs-theme="dark"] .or-devicelegenda { color: var(--or-text-muted); } / A legenda do device recuado acompanha largura/alinhamento dele. Seletor de irmão adjacente ancorado em .or-device--secundario (1 uso no site, home.php) — as 3 legendas de #lgpd (que não têm esse modificador) ficam intocadas. / .or-device--secundario + .or-devicelegenda { max-width: 72%; margin-left: auto; } @media (max-width: 991.98px) { .or-device--secundario + .or-devicelegenda { max-width: 100%; margin-left: 0; } } / --- .or-pilar (/sobre, bloco "O que nos diferencia") — os 4 pilares da marca. SUBSTITUIU .or-selos em 03/09/2026: a página tinha DOIS blocos de 4 itens (diferenciais + selos de capacidade), repetição estrutural em que o leitor não distinguia um do outro e "IA" aparecia nos dois. Os pilares absorveram ambos; o conteúdo dos selos virou a linha de LINKS DE VERIFICAÇÃO do bloco "Este site é a demonstração" — mais forte que o texto que substituiu ("Acessibilidade real" é promessa; "veja a declaração" é prova). Só três propriedades, e todas existem por um motivo: os cards vivem numa .row g-4 (regime A do §Padrão de Espaçamento — quem espaça é o gap do pai, então NENHUMA margem própria aqui), e o texto é editável pelo painel, logo vai crescer. height:100% + flex-column é o que mantém os 4 cards da mesma linha com a mesma altura independentemente do tamanho do texto cadastrado — o mesmo mecanismo de .or-faq-atalho e .or-segmento-card. Fundo, raio, padding e o pin de dark vêm de .or-card/.or-card--claro; nada é redeclarado. --- / .or-pilar { display: flex; flex-direction: column; height: 100%; } / --- .or-nivel (/sobre, bloco "O que você contrata") — card ilustrado de cada nível. SUBSTITUIU o .process-box do vendor em 03/09/2026, por dois defeitos medidos em tela: o componente traz `gap: 208px` (cards de 518px com um vazio enorme no meio, texto espremido na base) e o título herdava o h3 CRU do vendor — 80px numa caixa de 334px, com os TRÊS nomes transbordando. Aqui o tamanho é declarado, não herdado: é a regra de ouro do BLOCO 1 (~linha 224) — reescalar heading exige redeclarar tamanho E tracking. Como o .or-pilar, só declara o que precisa; fundo, raio, padding e o pin de dark vêm de .or-card/.or-card--claro. height:100% mantém os 3 cards da mesma linha com a mesma altura por mais que o texto cadastrado cresça, e o padding do .or-card é zerado no topo porque a arte sangra até a borda (moldura interna seria uma segunda borda dentro do card). --- / .or-nivel { display: flex; flex-direction: column; height: 100%; padding-top: 0; overflow: hidden; } .or-nivelarte { margin: 0 -28px var(--or-esp-6); / -28px = o padding lateral de .or-card: a arte sangra / / aspect-ratio reservado ANTES do load: sem isto o card cresce quando a imagem chega e empurra tudo abaixo dele (CLS). 16/10 é a proporção nativa das artes (1600×1000). / aspect-ratio: 16 / 10; background: var(--or-surface-2, var(--color-2)); line-height: 0; overflow: hidden; } .or-nivelimg { width: 100%; height: 100%; object-fit: cover; display: block; } .or-nivelnum { margin: 0 0 var(--or-esp-2); font-size: .8125rem; font-weight: 700; letter-spacing: .1em; color: var(--marca-primaria); } [data-bs-theme="dark"] .or-nivelnum { color: var(--or-brand-accent); } .or-niveltitulo { margin: 0 0 var(--or-esp-3); font-size: var(--or-fs-h3); letter-spacing: -.015em; line-height: 1.15; color: var(--color-primary); } .or-niveltagline { margin: 0; font-size: .9375rem; line-height: 1.6; color: var(--texto-secundario); } / --- .or-comparativo (/presenca-em-ia) — matriz "busca tradicional × busca com IA". É DE VERDADE, e isso é decisão de acessibilidade: uma matriz de comparação precisa que o leitor de tela navegue por linha e coluna anunciando o cabeçalho de cada célula.
com aparência de tabela perde isso. ⚠️ POR QUE NÃO REUSAR .or-planos-table: aquela resolve o mobile com `overflow-x: auto` + `white-space: nowrap` na primeira coluna — ou seja, ROLAGEM HORIZONTAL por projeto. Numa matriz de 3 colunas de texto corrido isso obriga a arrastar para ler metade do conteúdo, e o briefing desta página proíbe explicitamente. Aqui a linha EMPILHA. ⚠️ E POR QUE O MARKUP TRAZ role="table"/"row"/"cell" APARENTEMENTE REDUNDANTES: trocar o `display` de um elemento de tabela (que é o que o breakpoint faz para empilhar) APAGA a semântica nativa de tabela no leitor de tela — comportamento conhecido do CSS, não bug de navegador. Os papéis explícitos são o que devolve a semântica; sem eles, o ganho visual do mobile custaria a acessibilidade que motivou usar
. Zero token novo: raio, sombra, espaçamento e cor saem do Bloco 0. --- / .or-comparativo { width: 100%; border-collapse: collapse; background: var(--color-white); border-radius: var(--or-radius-m); box-shadow: var(--or-shadow-1); overflow: hidden; } [data-bs-theme="dark"] .or-comparativo { background: var(--or-surface-2); box-shadow: none; border: 1px solid var(--or-border); } .or-comparativo th, .or-comparativo td { padding: var(--or-esp-4) var(--or-esp-5); border-bottom: 1px solid var(--color-1); text-align: left; vertical-align: top; } [data-bs-theme="dark"] .or-comparativo th, [data-bs-theme="dark"] .or-comparativo td { border-bottom-color: var(--or-border); } .or-comparativo tbody tr:last-child th, .or-comparativo tbody tr:last-child td { border-bottom: 0; } .or-comparativo thead th { font-size: .8125rem; font-weight: 700; letter-spacing: .06em; text-transform: uppercase; color: var(--texto-secundario); } .or-comparativo tbody th { font-size: .9375rem; font-weight: 600; / Tracking proporcional — ver a nota do BLOCO 1 (~linha 224):
não é heading, mas herda a escala do corpo; declarar aqui mantém a coluna previsível se a fonte base mudar. / letter-spacing: -.005em; color: var(--color-primary); } .or-comparativo tbody td { font-size: .9375rem; line-height: 1.55; color: var(--texto-secundario); } / A coluna da IA é o lado que a página defende — recebe o tom da marca, não um fundo colorido (que brigaria com o zebrado do tema e com o dark). / .or-comparativo .or-comparativodestaque { color: var(--color-primary); font-weight: 600; } [data-bs-theme="dark"] .or-comparativo tbody th, [data-bs-theme="dark"] .or-comparativo .or-comparativodestaque { color: var(--or-text); } @media (max-width: 767.98px) { / Cada linha vira um cartão empilhado: o rótulo da linha é o título, e cada célula ganha o nome da sua coluna pelo data-label — sem isso, empilhado, ninguém sabe qual valor é de qual lado. O thead some porque seus rótulos passam a viver dentro das células. / .or-comparativo, .or-comparativo tbody, .or-comparativo tr, .or-comparativo th, .or-comparativo td { display: block; width: 100%; } .or-comparativo thead { display: none; } .or-comparativo tbody tr { padding: var(--or-esp-4) 0; border-bottom: 1px solid var(--color-1); } [data-bs-theme="dark"] .or-comparativo tbody tr { border-bottom-color: var(--or-border); } .or-comparativo tbody tr:last-child { border-bottom: 0; } .or-comparativo th, .or-comparativo td { border-bottom: 0; padding: var(--or-esp-2) var(--or-esp-5); } .or-comparativo tbody th { font-size: 1rem; padding-bottom: var(--or-esp-3); } .or-comparativo tbody td::before { content: attr(data-label); display: block; margin-bottom: 2px; font-size: .75rem; font-weight: 700; letter-spacing: .06em; text-transform: uppercase; color: var(--texto-secundario); } } / --- .or-trabalhonum — o índice de cada frente de trabalho (/presenca-em-ia). Classe própria, e não reuso de .or-nivelnum, porque aquele pertence ao card de PLANO: mudar o visual de um arrastaria o outro sem relação de causa. Mesma escala, papel diferente. --- / .or-trabalhonum { margin: 0 0 var(--or-esp-2); font-size: .8125rem; font-weight: 700; letter-spacing: .1em; color: var(--marca-primaria); } [data-bs-theme="dark"] .or-trabalhonum { color: var(--or-brand-accent); } / --- .or-plano-fronteiratitulo — o "em qual plano isso entra" dentro de um .or-card. Só reescala:
cru herdaria os 80px do vendor (regra de ouro do BLOCO 1, ~linha 224). --- / .or-plano-fronteiratitulo { margin: 0 0 var(--or-esp-4); font-size: var(--or-fs-h3); letter-spacing: -.015em; line-height: 1.2; color: var(--color-primary); } / --- .or-faq-sobre — o acordeão do vendor virando cartão (/sobre). O molde do vendor desenha LINHAS soltas (border-top, padding lateral ZERO). Numa coluna estreita isso lê bem; na /sobre o acordeão herdava col-12 dentro do .custom-container, que passa de 1500px no desktop — uma pergunta de 40 caracteres sozinha numa linha de 1536px, com o chevron perdido na borda oposta. O markup já foi para col-lg-10 (metade do problema); esta regra resolve a outra metade dando ao conjunto uma superfície com respiro interno, em vez de traços colados na margem. Zero valor novo: raio, sombra e espaçamento saem dos tokens. No escuro a sombra vira borda — mesmo precedente de .or-card (~linha 1128), porque sombra não lê sobre fundo escuro. --- / .or-faq-sobre { background: var(--color-white); border-radius: var(--or-radius-m); box-shadow: var(--or-shadow-1); padding: 0 var(--or-esp-6); overflow: hidden; } [data-bs-theme="dark"] .or-faq-sobre { background: var(--or-surface-2); box-shadow: none; border: 1px solid var(--or-border); } / O vendor fecha a última linha com border-bottom: dentro de um cartão isso desenha um traço colado na borda inferior. Aqui a régua separa APENAS item de item. / .or-faq-sobre .accordion-item:first-child { border-top: 0; } .or-faq-sobre .accordion-item:last-child { border-bottom: 0; } .or-faq-sobre .accordion-button { padding-inline: 0; } .or-faq-sobre .accordion-body { padding-inline: 0; } @media (max-width: 575.98px) { .or-faq-sobre { padding: 0 var(--or-esp-4); } } .or-pilartitulo { / Tracking proporcional — ver a nota do BLOCO 1 (~linha 224). Sem isto herdaria os -2px que o vendor calibrou para o h3 cru de 80px, e as letras colariam neste corpo de ~20px. / margin-bottom: var(--or-esp-3); font-size: 1.125rem; font-weight: 600; letter-spacing: -.01em; line-height: 1.35; color: var(--color-primary); } .or-pilartexto { margin-bottom: 0; font-size: .9375rem; line-height: 1.65; color: var(--texto-secundario); } / ================================================================ BLOCO 4 — TEMA · PÁGINAS COMUNS (serviços, contato, planos — compartilhado entre várias páginas do funil comercial, não só a home). ================================================================ / / --- Ícone de serviço (\OneRank\Icon::render(), SVG inline) — o slot .quanto-iconbox-icon do vendor nasceu pra uma de tamanho fixo do vendor; o SVG do catálogo próprio da plataforma herda currentColor, então dimensionamos e coloramos aqui. / .or-servico-icon svg { width: 40px; height: 40px; color: var(--marca-primaria); } .or-servico-icon--detalhe svg { width: 56px; height: 56px; } / --- Mídia por serviço (evolução F5) — largura própria menor que a coluna de prosa (col-lg-9/8): o par .or-device com sobreposição foi desenhado pra coluna de metade de página (home #painel), aqui é fluxo único mais estreito. --- / .or-servico-midia { max-width: 560px; } / --- Composição browser + phone flutuante (aba "Presença digital em plataforma própria", evolução "primeira dobra", 26/08/2026) — moldura --browser (tela de login) com a moldura --phone (dashboard em viewport de celular) sobreposta no canto inferior direito, reforçando visualmente a tag "Responsivo em qualquer tela". position:relative no wrapper porque aqui o --phone é position:absolute (diferente do uso em #painel, onde --secundario empilha em fluxo normal, deslocado só por margin negativa). --- / .or-servico-midia--composto { position: relative; } .or-servico-midia--composto .or-device--phone-flutuante { position: absolute; right: -18px; bottom: -28px; max-width: 130px; margin: 0; z-index: 2; } @media (max-width: 575.98px) { .or-servico-midia--composto .or-device--phone-flutuante { right: -8px; bottom: -18px; max-width: 96px; } } / --- #servicos "O que você contrata" — mostruário com abas (F5.2 da reestruturação da home). Mecânica 100% Bootstrap 5.3 (já carregado, _head.php) — .or-servicos-tab é só a PELE do botão; tab-content/tab-pane/fade/show/active continuam do Bootstrap, nunca reescritos. Sem .nav/.nav-link/.nav-tabs de propósito: o Tab do Bootstrap só exige role="tab"+data-bs-toggle, nav-link traria o cromo padrão brigando com o Quanto. / .or-servicos-showcaselista { display: flex; flex-direction: column; gap: 4px; } .or-servicos-tab { display: flex; align-items: center; gap: 14px; width: 100%; padding: 16px 18px; background: transparent; border: none; border-left: 3px solid transparent; border-radius: 0 var(--or-radius-m) var(--or-radius-m) 0; text-align: left; cursor: pointer; transition: background-color .2s ease, border-color .2s ease; } .or-servicos-tab:hover { background: color-mix(in srgb, var(--marca-primaria) 6%, transparent); } .or-servicos-tab.active { background: var(--color-white); border-left-color: var(--marca-primaria); box-shadow: var(--or-shadow-1); } [data-bs-theme="dark"] .or-servicos-tab.active { background: var(--or-surface); } .or-servicos-tabico { flex-shrink: 0; } .or-servicos-tabico svg { width: 28px; height: 28px; color: var(--marca-primaria); } [data-bs-theme="dark"] .or-servicos-tabico svg { color: var(--or-brand-accent); } .or-servicos-tabtxt { display: flex; flex-direction: column; gap: 2px; min-width: 0; } .or-servicos-tabtitulo { font-size: var(--or-fs-card); font-weight: 600; letter-spacing: -.01em; color: var(--color-primary); } .or-servicos-tab.active .or-servicos-tabtitulo { color: var(--marca-primaria); } [data-bs-theme="dark"] .or-servicos-tab.active .or-servicos-tabtitulo { color: var(--or-brand-accent); } / .or-servicos-tabsub — SAIU o par white-space:nowrap + text-overflow:ellipsis (29/08/2026). Motivo: com a lista de abas em col-lg-7 (era col-5) a coluna de texto ficou larga o bastante pros 6 subtítulos reais do seed caberem sem cortar. -webkit-line-clamp:2 fica como TETO de segurança pro que o operador digitar no admin, não como corte de rotina. / .or-servicos-tabsub { font-size: var(--or-fs-small); color: var(--or-text-muted); display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; line-clamp: 2; overflow: hidden; } / min-height só ≥992px (era 420px incondicional) — abaixo disso o palco é col-12 e a mídia sozinha já passa dos 470px; o piso ficaria inerte. RECALIBRADO 01/09/2026 — CAUSA RAIZ de "a tela sobe e volta" ao clicar nas 6 abas em sequência (achado do dono). Os 620px antigos foram escolhidos pra "casar visualmente com a lista de abas ao lado", NUNCA medidos contra o maior painel real — mesmo raciocínio de design, resultado estrutural diferente do irmão .or-iapalco (custom.css, ~linha 2989), que desde 28/08/2026 é calibrado pelo maior conteúdo MEDIDO ao vivo e por isso nunca precisou de refresh() reativo pra evitar salto (ver home.php:1885-1899). Aqui a altura SEMPRE variou por aba — o comentário antigo já admitia isso ("continua variando, só varia menos") — e cada troca de aba fazia o ScrollTrigger.refresh() do listener shown.bs.tab recalcular uma altura de documento GENUINAMENTE diferente, e essa mudança real de altura é o que o ScrollSmoother sentia como salto. Não era o refresh() em si (a causa do bug de 29/08, dois listeners simultâneos, não se repetia aqui — confirmado, só existe um). MEDIDO AO VIVO via Playwright (01/09/2026), as 6 abas em várias larguras: o comportamento NÃO É monotônico com a viewport (a imagem do device mockup cresce livre até o .custom-container saturar em 1604px — `.or-servicos-showcasepalco .or-servico-midia{max-width:none}` abaixo — e o layout de 2 colunas das tags muda de forma discreta em algum ponto entre ~1150-1600px, produzindo picos em faixas diferentes: 671,3px em 992-1150px (aba "SEO e presença em IA"), 620px flat em 1200-1440px, até 699,41px em ≥1604px (aba "Manutenção, monitoramento e segurança" — estável e idêntico em 1604/1920/2560px, confirmando que é o teto real de vez que o container para de crescer). 700px = 699,41 arredondado pra cima, mesmo critério do .or-iapalco ("teto arredondado pra cima zera o shift residual"). Consequência aceita: o palco fica ~60px mais alto que a lista de abas ao lado (que mede 640px em 1440px) — abrir mão do "casar visualmente" é o preço de eliminar o salto de verdade; ver comparação visual antes de aceitar como definitivo. / @media (min-width: 992px) { .or-servicos-showcasepalco { min-height: 700px; } } / .or-servico-midia nasceu com max-width:560px pensando em /servicos/ (coluna de prosa larga, col-lg-9) — no palco a coluna é a própria col-lg-5 (era col-7): o teto de 560px sobrava como vão morto à direita da imagem em telas grandes. Escopado ao palco: /servicos/ continua com os 560px. / .or-servicos-showcasepalco .or-servico-midia { max-width: none; } .or-servicos-showcaselegenda { max-width: none; } / --- Bloco de info da aba: legenda + tags + CTA (evolução "primeira dobra", 26/08/2026; teto de 560px removido em 29/08/2026 pelo mesmo motivo do .or-servico-midia acima — a coluna já é a medida certa, o teto só sobrava vão morto em telas grandes). --- / .or-servicos-showcase__info { max-width: none; display: flex; flex-direction: column; gap: 14px; margin-top: 18px; } / --- Tags do palco em grade 2×N (o "col-6" pedido pelo dono, 29/08/2026) ----------------------- ESCOPO POR DESCENDÊNCIA, não modificador: .or-tag é o chip compartilhado por _hero-interno, portfolio, produtos e servico.php — mexer na regra base mudaria os 4 contextos. (#para-quem-e usava .or-tag/.or-tag-list até 29/08/2026 — migrou pra .or-segmento-card na reestruturação de conversão, ver abaixo; os outros 4 usos continuam intocados.) .or-servicos-showcase__info (1 uso no site) vence por especificidade sem !important e sem classe .or-* nova. GRID, não .row/.col: uma row do Bootstrap aqui dentro reintroduziria a família de bug do gutter negativo (row-padding-top + g-) dentro de uma coluna que já vive numa row assim. minmax(0,1fr) e não 1fr: 1fr tem min-width:auto e uma palavra longa esticaria a trilha. As 2 exceções de 1 coluna vêm da conta de largura, não de gosto (col-lg-5 interno menos o gap de 8px, dividido por 2, menos ~30px de cromo da pílula compacta, a ~7,37px/caractere): 1920px → 38 chars/tag · 1440px → 33 · 1200px → 27 ⇒ 2 colunas cabem 992-1199px → 21 chars ← o vendor trava .custom-container em 970px FIXOS nessa faixa ≤575,98px → 19 chars ← container de 540px Nas duas o orçamento de copy (25 caracteres, ver _servicos-midia.php) não cabe ⇒ 1 coluna. --- / .or-servicos-showcaseinfo .or-tag-list { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: var(--or-esp-2); } @media (max-width: 575.98px), (min-width: 992px) and (max-width: 1199.98px) { .or-servicos-showcaseinfo .or-tag-list { grid-template-columns: minmax(0, 1fr); } } /* Pílula compacta SÓ aqui: a 15px/padding 22px (tamanho base de .or-tag) o orçamento no gargalo de 1200px cairia de 27 pra ~22 caracteres — curto demais pra "Relatório de conformidade" sem virar telegrama. Como item de grid o .or-tag (inline-flex) recebe justify-self:stretch, então as 2 pílulas de cada linha saem com a MESMA largura — é o que dá a leitura de "col-6". / .or-servicos-showcaseinfo .or-tag { padding: 8px 14px; font-size: var(--or-fs-small); line-height: 1.4; } / --- #para-quem-e — 12 cards de segmento + fundo em 3 camadas (reestruturação de conversão, 29/08/2026). SEÇÃO NÃO FLIPA no dark — mesmo molde de .or-ia (#geo, ~linha 2643): background fixo próprio (não .bg-color-primary, que flipa pra --or-surface-2), então .text-color-white é PROIBIDA aqui (mesma razão documentada no bloco de .or-ia) — cor literal escopada abaixo. / .or-segmentos-bg { position: absolute; inset: 0; z-index: 0; overflow: hidden; pointer-events: none; } #para-quem-e { position: relative; background: var(--or-grad-marca); } #para-quem-e > .container { position: relative; z-index: 1; } #para-quem-e .title { color: #fff; } #para-quem-e .or-lead { color: rgba(255, 255, 255, .78); opacity: 1; } / .or-lead nasce --color-primary + opacity .75 / / Camada 2 — malha de pontos, CSS puro (radial-gradient repetido), zero byte de rede. / .or-segmentos-bgmalha { position: absolute; inset: -10%; background-image: radial-gradient(rgba(255, 255, 255, .14) 1px, transparent 1.5px); background-size: 26px 26px; } / Camada 3 — 2 orbes de luz difusa em cantos opostos, profundidade em 3 planos com a malha e o gradiente de base. Blur via filter (não box-shadow) pra não pesar no compositing do parallax. / .or-segmentos-bgorbe { position: absolute; width: 46vw; height: 46vw; max-width: 560px; max-height: 560px; border-radius: 50%; filter: blur(70px); opacity: .35; } / var(--marca-primaria)/var(--marca-secundaria) nos dois orbes, NUNCA var(--or-dourado) — o dourado é lista FECHADA de 6 pontos (BLOCO 0.5, ~linha 71): "deixa de significar destaque no instante em que aparece em toda parte". Um orbe decorativo de fundo não entra na lista. / .or-segmentos-bgorbe--1 { top: -14%; left: -10%; background: var(--marca-primaria); } .or-segmentos-bgorbe--2 { bottom: -18%; right: -8%; background: var(--marca-secundaria, #082C6A); } / Cards — "vidro" translúcido sobre o gradiente (nenhum card claro funcionaria aqui: o fundo é sempre escuro, ver acima). Ícone em branco a 85% — nem literal #fff (mais forte que precisa pro papel de suporte do título) nem var(--or-brand-accent) (token SÓ definido dentro de [data-bs-theme=dark] no core — indefinido no claro, que é o tema default; ver comentário em .or-ia mais abaixo pro mesmo raciocínio aplicado a texto). / .or-segmento-card { height: 100%; padding: 22px; border-radius: var(--or-radius-m); background: rgba(255, 255, 255, .06); border: 1px solid rgba(255, 255, 255, .12); transition: background-color .25s ease, border-color .25s ease; } .or-segmento-card:hover { background: rgba(255, 255, 255, .1); border-color: rgba(255, 255, 255, .22); } .or-segmento-cardico { display: inline-flex; color: rgba(255, 255, 255, .85); font-size: 28px; margin-bottom: 14px; } .or-segmento-card :is(h3, h4) { color: #fff; font-size: 17px; font-weight: 600; / DEFEITO MEDIDO em 03/09/2026: a regra declarava tamanho e esquecia o tracking, então o heading herdava os -1.5px que o vendor calibrou para 60px. Em 17px isso é -8,8% do corpo — as letras encostavam umas nas outras. É a armadilha documentada no BLOCO 1 (~linha 224), e já era a terceira vez neste arquivo (.or-servico-cardtitulo e .or-faq-atalhotitulo foram as anteriores). Declarar tamanho SEM declarar tracking é meio conserto. / letter-spacing: -.01em; margin-bottom: 6px; } .or-segmento-card p { color: rgba(255, 255, 255, .7); font-size: var(--or-fs-small); line-height: 1.5; margin: 0; } @media (max-width: 991.98px) { .or-segmentos-bgorbe { width: 70vw; height: 70vw; } } / --- Lista compacta de frentes adicionais (evolução "primeira dobra", 26/08/2026; ampliada de 5 pra 15 itens e movida pra row própria col-lg-10 centralizada em 29/08/2026 — ver home.php). margin-top SAIU: quem separa esta row da row das abas agora é o row-padding-top da PRÓPRIA row (CLAUDE.md §Padrão de Espaçamento: "nunca os dois no mesmo ponto" — manter os dois somaria). padding-top + border-top FICAM: não são espaçamento entre rows, são a fronteira interna que faz o bloco ler como rodapé da seção. Conteúdo centralizado (não só a coluna): num bloco col-10 centrado, texto encostado à esquerda lê como desalinho acidental. --- / .or-frentes-extra { padding-top: 20px; border-top: 1px solid var(--or-border); display: flex; flex-direction: column; align-items: center; gap: 10px; text-align: center; } .or-frentes-extratitulo { font-size: var(--or-fs-small); font-weight: 600; color: var(--or-text-muted); text-transform: uppercase; letter-spacing: .04em; } .or-frentes-extralista { display: flex; flex-wrap: wrap; justify-content: center; gap: 8px; list-style: none; margin: 0; padding: 0; } .or-frentes-extraitem { display: inline-flex; align-items: center; gap: 6px; padding: 6px 12px; border-radius: var(--or-radius-pill); background: color-mix(in srgb, var(--marca-primaria) 6%, transparent); font-size: var(--or-fs-small); color: var(--color-primary); } .or-frentes-extraitem svg { width: 16px; height: 16px; color: var(--marca-primaria); } [data-bs-theme="dark"] .or-frentes-extraitem { background: color-mix(in srgb, var(--or-brand-accent) 12%, transparent); color: var(--or-text); } [data-bs-theme="dark"] .or-frentes-extraitem svg { color: var(--or-brand-accent); } / Nota de plano abaixo da lista — a lista passou a citar capacidades gateadas por tier (app instalável/crawlers de IA/estrelas = Autoridade; 301/canônica = Destaque). t-small/t-muted já têm regra própria (BLOCO 1.5); esta classe só carrega medida e respiro. / .or-frentes-extranota { margin: 6px 0 0; max-width: 62ch; } .or-frentes-extranota a { text-decoration: underline; } @media (max-width: 991.98px) { / Respiro do EMPILHAMENTO entre a row das abas/palco e a row das frentes: agora que a primeira é g-4 g-xl-5 (não gx-), o gutter vertical nativo já separa abas↔palco quando empilham — mas a row 3 (frentes) é row-padding-top sozinha (60/45px), que já é suficiente entre ROWS. O que falta é o respiro entre o PALCO (fim da row 2) e a lista de abas quando ela aparece DEPOIS dele no fluxo empilhado — mesmo remédio de .or-ialinha-resposta. / .or-servicos-showcasepalco { margin-top: var(--or-esp-5); } .or-servicos-showcaselista { flex-direction: row; overflow-x: auto; gap: 8px; padding-bottom: 4px; -webkit-overflow-scrolling: touch; } .or-servicos-tab { flex-direction: column; align-items: flex-start; gap: 8px; width: auto; min-width: 200px; max-width: 260px; border-left: none; border-bottom: 3px solid transparent; border-radius: var(--or-radius-m) var(--or-radius-m) 0 0; } .or-servicos-tab.active { border-bottom-color: var(--marca-primaria); } / SUBTÍTULO SOME NO TRILHO (29/08/2026) — não é economia de espaço, é DUPLICATA: o palco renderiza $serDescr, que É o próprio SER_SUBTITULO (home.php) quando cadastrado, a poucos pixels abaixo. Manter os dois obrigaria caber ~100 caracteres numa aba de 260px (2 linhas cortando) pra repetir o que a legenda do palco já diz inteiro. Em ≥992px o subtítulo volta (é a coluna larga que fez o line-clamp:2 acima nunca precisar cortar de verdade). / .or-servicos-tabsub { display: none; } } / Celular estreito: a 375px a col-12 dá ~351px e um chip de frente-extra de ~28 caracteres já ocupa a linha toda — 15 chips virariam ~15 linhas empilhadas. Encolher o chip devolve pelo menos 2 por linha nos aparelhos mais curtos. / @media (max-width: 575.98px) { .or-frentes-extraitem { padding: 5px 10px; font-size: .8125rem; } .or-frentes-extraitem svg { width: 14px; height: 14px; } } / --- Acordeão de etapas "Como funciona" — Bootstrap nativo (F5.5 da reestruturação; era .horizontal-scroll, pin GSAP com scroll-jacking, main.js:405-418 end:"+=3000px" — remover a classe mata o pin com segurança, ambos os pontos de uso já têm guarda `if (!hs) return`). MIGROU da home (#como-funciona) para /servicos em 29/08/2026 — a classe .or-etapas-acordeao é a mesma, só o markup que a usa mudou de arquivo (ver pages/servicos.php). Reusa .quanto-faq-accordion (mesmo CSS de #faqs) — este bloco só existe pra fazer o accordion funcionar sobre bg-color-primary, que é PERMANENTEMENTE escuro nos 2 temas (não flipa) — tokens literais, mesma doutrina do rodapé. Sobrescreve as custom properties do próprio Bootstrap (--bs-accordion-) em vez de brigar com especificidade regra a regra. / .or-etapas-acordeao { --bs-accordion-bg: transparent; --bs-accordion-color: #fff; --bs-accordion-btn-color: #fff; --bs-accordion-btn-bg: transparent; --bs-accordion-active-color: #fff; --bs-accordion-active-bg: transparent; --bs-accordion-border-color: rgba(255, 255, 255, .16); --bs-accordion-btn-icon: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16' fill='%23ffffff'%3e%3cpath fill-rule='evenodd' d='M1.646 4.646a.5.5 0 0 1 .708 0L8 10.293l5.646-5.647a.5.5 0 0 1 .708.708l-6 6a.5.5 0 0 1-.708 0l-6-6a.5.5 0 0 1 0-.708z'/%3e%3c/svg%3e"); --bs-accordion-btn-active-icon: var(--bs-accordion-btn-icon); } .or-etapas-acordeao .accordion-button { font-weight: 600; } /* --bs-accordion-bg cobre o FUNDO (.accordion-item usava var(--bs-body-bg), branco cru — as "caixas brancas" medidas ao vivo). O TEXTO do item expandido é outro achado: o vendor tem .quanto-faq-accordion .accordion-button:not(.collapsed){color:initial} (style.css) — 3 classes/ pseudo = especificidade (0,3,0), maior que a var(--bs-accordion-btn-color) da regra base do Bootstrap (0,1,0) E que a nossa primeira tentativa aqui (0,2,0). Precisa iguakar a especificidade (mesma cadeia .quanto-faq-accordion .accordion-button:not(.collapsed)) pra vencer por ordem de arquivo (custom.css carrega depois do style.css). / .quanto-faq-accordion.or-etapas-acordeao .accordion-button:not(.collapsed) { color: #fff; } .or-etapas-acordeao .accordion-body { color: rgba(255, 255, 255, .78); } .or-etapas-acordeaonum { display: inline-flex; align-items: center; justify-content: center; flex-shrink: 0; width: 32px; height: 32px; margin-right: 16px; border: 1px solid rgba(255, 255, 255, .3); border-radius: 50%; font-size: .9rem; font-weight: 700; } / --- #faqs: 4 grupos temáticos lado a lado (reestruturação de conversão, 29/08/2026 — largura total, pedido do dono). Cards com o componente .or-card/.or-card--claro (padronização de espaçamento, 29/08/2026, achado ao vivo do dono) — antes .or-faq-grupo era uma coluna sem fundo/borda/padding, e o único respiro próprio da seção (título→acordeão) ficava em 16px, abaixo do piso de 24px do CLAUDE.md. Ícone segue o padrão de .or-prova-cardico (marca no claro, --or-brand-accent no escuro). height:auto (não 100%): os 4 grupos têm quantidades desiguais de pergunta (5/5/5/4) — esticar o par pra mesma altura sobrava ~134px de área vazia no card mais curto, só visível depois que o card ganhou fundo/sombra. Decisão do dono: altura própria por card (topos alinhados pela .row, rodapés podem divergir). / .or-faq-grupo { display: flex; flex-direction: column; height: auto; } / letter-spacing explícito obrigatório (mesmo padrão D2 já registrado em .or-prova-card h4 e .or-lgpd-bastidortitulo): o vendor prende letter-spacing à TAG em px (h4 -1,5px calibrado pra 60px cru) — sem override, um
de 17px herdava a mesma -1,5px (-8,8% do corpo, letras coladas). / .or-faq-grupotitulo { display: flex; align-items: center; gap: 10px; font-size: 17px; font-weight: 600; letter-spacing: -.01em; color: var(--color-primary); margin-bottom: var(--or-esp-5); } .or-faq-grupoico { display: inline-flex; color: var(--marca-primaria); font-size: 22px; } [data-bs-theme="dark"] .or-faq-grupoico { color: var(--or-brand-accent); } / último item do accordion sem a borda inferior do vendor (style.css:5044) — dentro do .or-card ela ficava órfã, flutuando 28px acima do canto arredondado sem nada abaixo pra separar. / .or-faq-grupo .quanto-faq-accordion .accordion-item:last-child { border-bottom: none; } / --- Formulário (contato + planos) — sobre .quanto-contactform .form-control já estilizado pelo vendor (style.css:5834+); aqui só o que falta: label visível (o vendor usa só placeholder, mas a plataforma exige label pra a11y), consentimento LGPD e alerta de resultado (sem componente equivalente no vendor). / .or-formfield { margin-bottom: 0; } .or-formfield label { display: block; font-size: .85rem; font-weight: 600; color: var(--color-primary); margin-bottom: 6px; } .or-form-alert { padding: 14px 18px; border-radius: 8px; font-size: .92rem; margin-bottom: 20px; } / ── CAMPOS DO FORMULÁRIO — borda, foco e altura (05/09/2026) ──────────────────────────────── Print 2 do dono: "o form de contato nem tem padronização de campos, está totalmente desalinhado, sem bordas entre campos". Medido: o vendor (style.css:5834-5846) define `border: none` no `.form-control` E `box-shadow: none` no `:hover, :focus`. Duas consequências: 1. Campo sem contorno — o único sinal de "aqui se digita" era um cinza levemente diferente do fundo do card, que praticamente some quando o formulário está DENTRO de um card (é o caso desde a F4). Campos adjacentes viram uma mancha só. 2. O `box-shadow:none` no `:focus` apaga o anel do Bootstrap sem colocar nada no lugar — quem navega por teclado perdia o campo ativo de vista. Isso é WCAG 2.4.7 (foco visível), não preferência de estilo. Altura: 22px de padding vertical sobre 18px de fonte dava 70px de campo — desproporcional ao rótulo de 13,6px acima dele e a causa da sensação de "desalinhado" quando dois campos pareiam na mesma linha. 15px/18px devolve ~58px, alinhado à escala do resto do site. Especificidade: `.quanto-contactform .form-control` do vendor pesa (0,2,0); repetimos o MESMO peso e vencemos por ordem de carregamento (custom.css vem depois de style.css). / .quanto-contactform .form-control { border: 1px solid var(--or-border, rgba(0, 0, 0, .12)); background: var(--or-surface, #fff); padding: 15px 18px; font-size: 1rem; color: var(--color-primary); transition: border-color .15s ease, box-shadow .15s ease; } .quanto-contactform .form-control::placeholder { color: var(--or-text-muted); opacity: 1; } / Hover escurece a borda por color-mix sobre o MESMO token do repouso — sem inventar um segundo token de borda que teria de ser mantido em sincronia com --or-border nos dois temas. / .quanto-contactform .form-control:hover { border-color: color-mix(in srgb, var(--or-border, rgba(0, 0, 0, .12)) 100%, var(--color-primary) 25%); } / Foco: anel da marca reconstruído (o vendor zera o do Bootstrap). box-shadow em vez de outline para acompanhar o border-radius do campo sem o "canto quadrado" que o outline produz. / .quanto-contactform .form-control:focus { border-color: var(--marca-primaria); box-shadow: 0 0 0 3px color-mix(in srgb, var(--marca-primaria) 18%, transparent); outline: none; } / Erro (or-form.js marca aria-invalid) — a borda existe, então ela mesma carrega o estado; sem isto o único sinal de campo inválido seria a mensagem abaixo, longe do olhar de quem digita. / .quanto-contactform .form-control[aria-invalid="true"] { border-color: #A23B2C; } .quanto-contactform .form-control[aria-invalid="true"]:focus { box-shadow: 0 0 0 3px color-mix(in srgb, #A23B2C 18%, transparent); } [data-bs-theme="dark"] .quanto-contactform .form-control { background: var(--or-surface-2); border-color: var(--or-border); color: var(--or-text); } .or-form-alert--success { background: color-mix(in srgb, #1F7A4D 15%, transparent); color: #1F7A4D; } .or-form-alert--error { background: color-mix(in srgb, #A23B2C 15%, transparent); color: #A23B2C; } / ═══════════════════════════════════════════════════════════════════════════════════════════ BLOCO 20 — CONSENTIMENTO LGPD (.or-consent) — 05/09/2026 ═══════════════════════════════════════════════════════════════════════════════════════════ Substitui .or-formconsent, que somava quatro defeitos: font-size:.82rem FORA da escala tipográfica do projeto (--or-fs-small é .875rem), opacity:.75 por cima disso, checkbox de ~14px (1em herdado do .82rem — regra base do Bootstrap), muito abaixo de qualquer alvo de toque razoável e do piso de 24px do WCAG 2.5.8, e :checked no azul #0d6efd fixo do Bootstrap, estranho à marca nos dois temas. O aceite é a peça que dá VALIDADE JURÍDICA ao dado captado — tratá-lo como letra miúda é o oposto do que a LGPD pede (art. 8º §4º: consentimento destacado das demais cláusulas). Usado por TODOS os formulários do tema que incluem site/includes/consent-checkbox.php (CORE — markup intocável pelo fork): contato, planos, candidatura a vaga — a única alavanca do fork é a classe passada em $consentDivCls. Markup do CORE (fixo, não editável aqui):
texto + link
Input e label são IRMÃOS — não é um envolvendo tudo. Por isso o "alvo de clique" cresce pelo tamanho real do checkbox (20px) + a área do texto (que já é clicável via `for`), não por um wrapper universal — o markup não permite outra coisa sem tocar o core. / .or-consent { display: flex; align-items: flex-start; gap: var(--or-esp-3, 12px); margin-top: var(--or-esp-3, 12px); padding: var(--or-esp-4, 16px); border-radius: var(--or-radius-s, 8px); background: var(--or-surface-2, rgba(0, 0, 0, .025)); border: 1px solid var(--or-border, rgba(0, 0, 0, .08)); } / Checkbox — 20px reais (o piso de toque de 24px vem da soma com o padding do wrapper, não de inflar o próprio quadrado, que ficaria desproporcional ao texto). accent-color assume a cor da marca nos navegadores que suportam (Chromium/Firefox atuais); onde não suporta, cai no azul nativo do SO — degrada sem quebrar função. / .or-consent .form-check-input { flex: 0 0 auto; width: 20px; height: 20px; margin: 1px 0 0; accent-color: var(--marca-primaria); cursor: pointer; } .or-consent .form-check-input:focus-visible { outline: 2px solid var(--marca-primaria); outline-offset: 2px; } / Texto — sai da escala fora-do-padrão (.82rem) pra --or-fs-small (.875rem, a MESMA de .or-pg .t-small); (0,2,0) já vence o `.small`/`small{font-size:.875em}` do Bootstrap (0,1,0/0,0,1) sem precisar de !important. opacity:.75 SAI — texto de consentimento não é nota de rodapé. / .or-consent .form-check-label { margin: 0; font-size: var(--or-fs-small, .875rem); line-height: 1.5; color: var(--color-primary); cursor: pointer; } .or-consent .form-check-label a { color: var(--texto-link, var(--marca-primaria)); text-decoration: underline; text-underline-offset: 2px; font-weight: 600; } .or-consent .form-check-label a:hover { color: var(--marca-secundaria, var(--marca-primaria)); } / Realce da caixa inteira quando o checkbox está focado — só progressive enhancement (:has()), sem função nenhuma dependendo dele: quem não suporta vê só o outline do próprio input acima. / .or-consent:has(.form-check-input:focus-visible) { border-color: var(--marca-primaria); } / dark-safe: --or-surface-2/--or-border já flipam sozinhos (contrato em site/CLAUDE.md) — regra aqui só pra deixar explícito que o componente foi verificado nos dois temas, não uma exceção. / [data-bs-theme="dark"] .or-consent { background: var(--or-surface-2); border-color: var(--or-border); } / ═══════════════════════════════════════════════════════════════════════════════════════════ BLOCO 21 — MARQUEE DE FUNDO PADRONIZADO (.or-marquee-fundo) — 05/09/2026 ═══════════════════════════════════════════════════════════════════════════════════════════ Faixa de texto passando ao fundo, como TEXTURA (aria-hidden, opacity baixa, sem link dentro — elemento focável em aria-hidden reprovaria aria-hidden-focus do axe). Existia só no CTA do rodapé (era .or-rd-ctamarquee, visível em 4 das ~30 páginas). O dono pediu que a faixa existisse em TODO CTA (print 4: "esta section é o exemplo de como todas essas sessões devem se manter") — fatorada em partial compartilhado (_marquee-fundo.php) + este bloco único de CSS, usado por .or-rd-cta (rodapé), .or-secao-cta (26 páginas) e pagina-planos.php. Mesma mecânica do vendor (.marquee-container/.marquee/@keyframes scroll_x, style.css) — reaproveitada, não reimplementada; o reduced-motion de .marquee-container .marquee (~linha 1020/1058 deste arquivo) já cobre esta faixa de graça, por reusar as MESMAS classes do vendor. Tinta por VARIANTE, nunca fixa: dourado (fundo escuro/gradiente de marca) usa branco translúcido — a mesma tinta já medida e aprovada no rodapé. soft (fundo claro — páginas documentais, ou uma seção comum como a de /planos) usa a cor de TEXTO do próprio tema em opacidade baixa; branco a .08 seria invisível sobre fundo claro. / .or-marquee-fundo { position: absolute; inset: 0; z-index: 0; padding: 0 !important; display: flex; align-items: center; pointer-events: none; user-select: none; opacity: var(--or-mq-opacidade, .08); } .or-marquee-fundo .marquee-item { gap: 28px; / teto 128px→88px (achado de 28/08/2026, herdado do .or-rd-ctamarquee original): a 128px as palavras viravam borrão abstrato e roubavam peso visual da linha de ações. Textura, não protagonista — vale nas 3 superfícies que usam este componente. / font-size: clamp(2.5rem, 6vw, 5.5rem); font-weight: 600; letter-spacing: -.03em; text-transform: lowercase; color: var(--or-mq-tinta, #fff); white-space: nowrap; } .or-marquee-fundosep { opacity: .5; } / dourado = default explícito (fundo escuro/gradiente de marca — .or-rd-cta, .or-secao-cta sem --soft). Branco fixo: essas superfícies nunca flipam no dark (fundo já é escuro nos dois temas). Declaração em linhas separadas (não `{ --a: x; --b: y; }` compacto) — é o formato que tests/tema_quanto_test.php reconhece como "definição" de var(--x) (regex ^\s--token:). / .or-marquee-fundo--dourado { --or-mq-tinta: #fff; --or-mq-opacidade: .08; } /* soft = fundo claro. --color-primary já flipa sozinho no dark (contrato do design system), mas nesse caso o FUNDO também flipa pra escuro — então a tinta clara certa é branco, não a cor de texto (que ficaria escura sobre escuro). Opacidade um pouco maior no dark: telas escuras comprimem contraste de camadas translúcidas mais que telas claras. / .or-marquee-fundo--soft { --or-mq-tinta: var(--color-primary); --or-mq-opacidade: .05; } [data-bs-theme="dark"] .or-marquee-fundo--soft { --or-mq-tinta: #fff; --or-mq-opacidade: .07; } / Hospedeiro da faixa fora de .or-rd-cta/.or-secao-cta: a seção-formulário de /planos não tem componente próprio (é a única página cujo fecho é o form, não _secao-cta.php/_rodape.php), e o id #contato-planos já é âncora estável no markup — vira o hook de posicionamento aqui. Mesmo contrato de `.or-secao-cta .container { position:relative; z-index:1 }`: sem isto, o conteúdo pintaria ATRÁS da camada absoluta do marquee (mesmo a .05 de opacidade, o glifo pintaria por cima do texto do form em vez de ficar sob ele). / / GRADIENTE DE MARCA (05/09/2026) — a seção de fecho de /planos era a única do site que fechava em branco; ver o docblock no markup (pagina-planos.php, seção #contato-planos) para o porquê. O formulário fica num .or-card--claro por cima, então só título e lead precisam de tinta clara. `isolation: isolate` cria contexto de empilhamento próprio: sem ele, o glow/marquee poderia competir com o z-index de elementos de outras seções. / / `.or-planos-fecho` é a classe SEMÂNTICA do componente; o `#contato-planos` do mesmo elemento é uma ÂNCORA de navegação (os botões dos cards de plano apontam para ela) e continua existindo só para isso. Estilizar pela classe mantém o padrão do projeto — id vira alvo de link, não gancho de CSS. / .or-planos-fecho { position: relative; overflow: hidden; isolation: isolate; background: var(--or-grad-marca); } .or-planos-fecho > .container { position: relative; z-index: 1; } / !important pelo mesmo motivo já registrado em .or-hero-interno--comercial: a regra [data-bs-theme="dark"] :is(h1..h6){color:var(--or-text)!important} venceria por !important mesmo com especificidade menor, e o título sairia cinza no tema escuro. O gradiente da marca não muda com o tema, então o branco aqui é incondicional. / .or-planos-fecho .title { color: #fff !important; } .or-planos-fecholead { max-width: 620px; margin-inline: auto; font-size: var(--or-fs-lead); line-height: 1.6; color: rgba(255, 255, 255, .82); } / --- BUG achado ao vivo em 04/09/2026 (print do dono: botão do CTA final sem rótulo, só a seta). O vendor define .quanto-link-btn span { width:16px; height:14px; overflow:hidden } pensado só pro do ÍCONE (duas setas absolutamente posicionadas, alternadas no hover — a caixa pequena com overflow escondido É a receita do efeito). Os botões de FORM (contato + planos) também embrulham o TEXTO num — necessário pro JS trocar "Enviando..." no submit —, e esse span cai na MESMA regra do vendor: o texto fica espremido numa caixa de 16×14px, invisível (só o ícone aparece). Os outros botões da página escapam porque o texto ali é nó de texto solto, não embrulhado em . Fix: uma classe própria SÓ no span do texto, resetando a caixa herdada — o span do ícone continua sem ela. --- / / Especificidade: .quanto-link-btn span (vendor) é (0,1,1) — mais específica que uma classe só (0,1,0). .quanto-link-btnlabel sozinha perdia a cascata e o bug persistia mesmo com a regra carregada (confirmado ao vivo: cssText presente em document.styleSheets, computed style igual ao do vendor). Escopando ao pai (.quanto-link-btn .quanto-link-btnlabel, especificidade 0,2,0) a regra nova vence sem precisar de !important. `color: inherit` é a SEGUNDA metade do mesmo bug, achada só depois de corrigir a primeira: o vendor também fixa `color: var(--color-primary)` neste mesmo seletor `.quanto-link-btn span` — inofensivo pro span do ÍCONE (vazio, sem texto direto; quem pinta são os .arry1/.arry2 filhos, com override próprio pro contexto .btn-pill), mas o span do RÓTULO tem texto direto e herdava a cor escura — texto escuro sobre o MESMO fundo escuro do .btn-pill (branco só é aplicado a .arry1/.arry2, nunca ao span em si). Confirmado ao vivo: rect correto (172×26, overflow visible), texto simplesmente invisível por contraste zero. `inherit` acompanha a variante do botão que embrulha o rótulo (branco no .btn-pill, escuro no .btn-pill.btn-light) em vez de fixar uma cor. / .quanto-link-btn .quanto-link-btnlabel { width: auto; height: auto; overflow: visible; display: inline; color: inherit; } / --- Coluna de informações de contato (endereço/telefone/e-mail/horário/redes) --- / .or-contato-info { display: flex; flex-direction: column; gap: 22px; } .or-contato-infoitem a { color: inherit; text-decoration: underline; text-underline-offset: 2px; } .or-contato-infoitem ul.custom-ul { list-style: none; padding: 0; margin: 0; display: flex; flex-direction: column; gap: 6px; } / ── Os rótulos viraram HEADINGS em 03/09/2026 ──────────────────────────────────────────────── Antes:
para a coluna e
para cada rótulo, estilizados por POSIÇÃO (p:first-child = rótulo, p:last-child = valor). Era texto no tamanho de título, com peso de título, cumprindo papel de título — e completamente invisível para quem navega por heading. Agora são
e
reais. Duas consequências que ESTA regra existe para tratar, e nenhuma delas é opcional: 1. Seletor por posição não sobrevive à mudança. Com o rótulo virando
, o único
restante passaria a ser first-child E last-child ao mesmo tempo, acumulando as duas regras (peso 600 do rótulo + opacidade .7 do valor). Por isso a estilização passa a ser por TAG, não por ordem — o que também deixa de quebrar quando alguém acrescenta uma linha ao item. 2. Heading promovido HERDA a escala do vendor. Um
sem font-size declarado nasce com os ~60px que o tema calibrou para título de seção — dentro de uma coluna lateral de 4/12. É a armadilha documentada no BLOCO 1 (~linha 224), e o tracking em px absolutos vem junto: por isso font-size E letter-spacing são declarados aqui, não só o primeiro. / .or-contato-infotitulo { font-size: var(--or-fs-card, 1.25rem); line-height: 1.25; letter-spacing: -.01em; font-weight: 700; color: var(--color-primary); margin: 0 0 var(--or-esp-2, 8px); } .or-contato-infoitem h3 { font-size: 1rem; line-height: 1.35; letter-spacing: 0; font-weight: 600; color: var(--color-primary); margin: 0 0 2px; } .or-contato-info__item p { color: var(--color-primary); opacity: .7; margin: 0; } / Horário por dia da semana (tbl_empresa_horarios).
porque é literalmente par termo→valor; a grade de duas colunas alinha os horários entre si, que é o que torna a lista escaneável. / .or-contato-horarios { display: grid; grid-template-columns: auto 1fr; gap: 2px var(--or-esp-4, 16px); margin: 0; } .or-contato-horarios dt { font-weight: 500; color: var(--color-primary); opacity: .7; } .or-contato-horarios dd { margin: 0; color: var(--color-primary); opacity: .7; } / Nome da área ("Comercial", "SAC") antes do contato dela — pílula discreta, não outro heading: são muitos itens curtos e um h4 por linha inflaria o outline sem informar nada a mais. / .or-contato-setor { display: inline-block; margin-right: 6px; font-weight: 600; color: var(--color-primary); } / Título do formulário. Mesmo raciocínio do .or-contato-infotitulo:
novo precisa de escala própria — aqui na medida de subtítulo interno, não de título de seção, porque ele divide a linha visual com a coluna de canais ao lado e não pode dominá-la. / .or-contato-formtitulo { font-size: var(--or-fs-h3, 1.5rem); line-height: 1.2; letter-spacing: -.01em; margin: 0 0 var(--or-esp-5, 24px); } / Mapa (EMP_MAPS_URL). Proporção fixa em vez de altura fixa: em 360px uma altura de 450px come a tela inteira, e no desktop uma de 300px vira uma faixa sem contexto. O iframe do Google Maps não traz proporção intrínseca, então ela é declarada aqui. / / ⚠️ margin-inline:auto é LOAD-BEARING (09/09/2026) — sem ele o mapa fica encostado à esquerda mesmo dentro de uma coluna centralizada, e essa era a metade do desalinhamento que o dono apontou em "Onde estamos" (a outra metade era o text-center no lugar errado — ver contato.php). A causa não é óbvia à leitura: `aspect-ratio: 16/9` combinado com `max-height: 520px` limita a LARGURA a 924px. Medido em 1440px: a coluna dá 1171px e o mapa ocupa 924 — sobram 247px, e como um bloco sem margem automática encosta no início do fluxo, os 247 iam todos para a direita. O título centralizado terminava em 1303 e o mapa em 1056, a 247px de distância um do outro. Alargar a coluna não resolve; centralizar a row não resolve. Só a margem automática resolve. / .or-contato-mapa { position: relative; margin-inline: auto; aspect-ratio: 16 / 9; max-height: 520px; border-radius: var(--or-radius-m); overflow: hidden; border: 1px solid var(--or-border, rgba(0, 0, 0, .08)); } .or-contato-mapa iframe { position: absolute; inset: 0; width: 100%; height: 100%; border: 0; } @media (max-width: 575.98px) { .or-contato-mapa { aspect-ratio: 4 / 3; } } / --- Protocolo de teste da /presenca-em-ia (redesenhado 03/09/2026 — achado real): o markup anterior reaproveitava .or-inclusos-lista--coluna, que NUNCA teve efeito — é declarada ANTES de .or-inclusos-lista (linha ~2864) no arquivo, então a regra base (grid auto-fit de 2+ colunas, pensada pra itens curtos tipo "SSL grátis") sempre vencia por ordem de cascata, mesma especificidade. Cada passo (frase longa + link inline) ficava espremido numa coluna de ~300px, quebrando de forma ilegível. Componente PRÓPRIO (só esta página usa) —
numerado, 1 coluna sempre, sem depender de nenhuma outra classe pra vencer a cascata. / .or-protocolo-lista { list-style: none; margin: 0 0 28px; padding: 0; max-width: 640px; display: flex; flex-direction: column; gap: 16px; } .or-protocolo-lista li { display: flex; align-items: flex-start; gap: 14px; } .or-protocolo-listanum { flex-shrink: 0; display: flex; align-items: center; justify-content: center; width: 28px; height: 28px; border-radius: 50%; background: var(--marca-primaria); color: #fff; font-size: .8rem; font-weight: 700; } [data-bs-theme="dark"] .or-protocolo-listanum { background: var(--or-brand-accent); color: var(--or-ink-deep, #05132b); } .or-protocolo-listatexto { padding-top: 3px; font-size: .98rem; color: var(--color-primary); } / A nota de fecho acompanha a MESMA medida de leitura da lista (640px). Com o card alinhado à esquerda (03/09/2026), sem isto ela esticaria pela largura inteira do card (~900px em col-lg-9) — ~110 caracteres por linha, bem acima do confortável, e desalinhada do bloco acima. / .or-protocolo-nota { max-width: 640px; margin-inline: auto; } / --- /planos: dois rótulos que eram style="" inline no PHP. O nome do add-on e a linha de nomes comerciais das estatísticas (que substituiu o "T1 ⊂ T2 ⊂ T3" técnico) agora são texto vindo do banco — o peso e o tamanho não podem depender de alguém lembrar do inline ao editar. --- / .or-planos-addonsnome { font-weight: 600; } / O nome do avulso virou link para /servicos/ em 04/09/2026 (o item passou a vir de tbl_servicos, que tem a página de detalhe). Herda a cor do texto em repouso — um bloco de seis nomes todos na cor de link viraria uma parede azul dentro de uma seção que é, antes de tudo, uma tabela de preços. / .or-planos-addonsnome a { color: inherit; text-decoration: none; } .or-planos-addonsnome a:hover, .or-planos-addons__nome a:focus-visible { color: var(--texto-link); text-decoration: underline; } .or-stat-nomes { font-size: clamp(1.15rem, 0.9rem + 1vw, 1.75rem); line-height: 1.25; } / --- .or-planos-table REMOVIDA em 04/09/2026: a /planos passou a usar .or-comparativo, o mesmo componente da /presenca-em-ia. O motivo é a regra de mobile — aquela resolvia telas pequenas com `overflow-x: auto` PURO, sem coluna fixa, e numa tabela de quatro colunas isso faz o leitor perder a referência da linha assim que arrasta: ele vê "2 por mês" sem saber se é artigo, publicação ou e-mail. .or-comparativo EMPILHA cada linha como um cartão e injeta o nome da coluna via `data-label`, que é o regime correto aqui. O grid de add-ons (.or-planos-addons, logo abaixo) CONTINUA — só a fonte dos dados mudou, de tbl_textos para tbl_servicos. COLUNAS EXPLÍCITAS por breakpoint (04/09/2026), não mais auto-fit: com 6 itens, minmax(260px,1fr) media pra exatamente 5 colunas de 262px em 1440px de largura (medido ao vivo) — 5 numa linha, o 6º sozinho na de baixo. Print do dono pediu "4 por linha, padronizado" — mesmo espírito de .or-base-lista (BLOCO 2), que já usa colunas fixas por breakpoint nesta mesma página em vez de auto-fit. .or-planos-addons__price REMOVIDA junto do
que ela estilizava — preço saiu da vitrine (pedido do dono: "não vamos colocar preço, são blocos que apenas serão consultados"), segue existindo em tbl_servicos e na página de detalhe do serviço. --- / .or-planos-addons { display: grid; grid-template-columns: 1fr; gap: var(--or-esp-5); } @media (min-width: 576px) { .or-planos-addons { grid-template-columns: repeat(2, 1fr); } } @media (min-width: 992px) { .or-planos-addons { grid-template-columns: repeat(4, 1fr); } } / ── REMODELAÇÃO DO CARD (05/09/2026) ───────────────────────────────────────────────────────── Era `background: var(--color-2)` — o MESMO token do fundo da seção (#avulsos é .bg-color-2). Card cinza sobre fundo cinza: não existia card, só texto solto em 4 colunas, que é exatamente o que o print 6 do dono mostra. Superfície branca + borda dão o contraste que faltava; no escuro, --or-surface (um degrau acima de --or-surface-2, o fundo da seção lá) faz o mesmo trabalho — mesma doutrina já usada por .quanto-blog-content.bg-color-white contra a seção branca do blog. `position: relative` ancora o .stretched-link do título; `height: 100%` iguala a altura dos cards da mesma linha (subtítulos de serviço têm comprimentos bem diferentes). / .or-planos-addonsitem { position: relative; display: flex; flex-direction: column; height: 100%; padding: var(--or-esp-6) var(--or-esp-5); border-radius: var(--or-radius-m); background: var(--color-white); border: 1px solid var(--or-border, rgba(0, 0, 0, .08)); transition: border-color .2s ease, box-shadow .2s ease; } .or-planos-addonsitem:hover, .or-planos-addonsitem:focus-within { border-color: var(--marca-primaria); box-shadow: var(--or-shadow-1); } [data-bs-theme="dark"] .or-planos-addonsitem { background: var(--or-surface); border-color: var(--or-border); } / Ícone: mesmo tamanho e tratamento do .or-servico-cardico da grade de /servicos — os dois listam o MESMO tipo de coisa (serviço), e divergir aqui criaria dois vocabulários visuais para uma entidade só. / .or-planos-addonsico { display: inline-flex; margin-bottom: var(--or-esp-4); color: var(--marca-primaria); font-size: 26px; } [data-bs-theme="dark"] .or-planos-addonsico { color: var(--or-brand-accent); } .or-planos-addonsico svg { width: 26px; height: 26px; } /
real (era
com peso de título). font-size explícito: um h3 "cru" herda os 80px do vendor — a armadilha já registrada no BLOCO 1.5 para todo heading promovido. / .or-planos-addonsnome { font-size: 1.0625rem; line-height: 1.35; letter-spacing: -.01em; font-weight: 600; color: var(--color-primary); margin: 0 0 var(--or-esp-3); } .or-planos-addonsnome a { color: inherit; text-decoration: none; } .or-planos-addonsitem:hover .or-planos-addonsnome a { color: var(--texto-link, var(--marca-primaria)); } / margin-top:auto encosta o texto no rodapé do card quando o título ocupa 1 linha e o vizinho ocupa 2 — sem isso os subtítulos "flutuam" em alturas diferentes na mesma linha da grade. / .or-planos-addonstexto { margin: 0; font-size: var(--or-fs-small); line-height: 1.6; color: var(--or-text-muted); } @media (prefers-reduced-motion: reduce) { .or-planos-addonsitem { transition: none !important; } } html[data-or-rm="reduce"] .or-planos-addons__item { transition: none !important; } / Sub-bloco↔sub-bloco dentro da mesma seção (grade de avulsos → nota de fecho) — antes era um mt-4 inline (24px) direto no
; print do dono: "não tem o devido espaçamento". Medido ao vivo: o gap real hoje é só 24px entre o fim da grade e a nota, bem abaixo do que os outros blocos da página usam pra essa mesma transição. / .or-avulsos-nota { margin-top: var(--or-esp-7); } / Segunda nota (multi-idioma, D6) colada na primeira: as duas são RESSALVAS da mesma grade, e --or-esp-7 (48px) é o token de "sub-bloco↔sub-bloco" — separa a primeira nota da grade de cards, que é uma troca real de assunto. Entre as duas notas não há troca de assunto nenhuma, e 48px lê como se fossem blocos independentes, cada uma órfã da outra (print do dono, 09/09/2026). Cai para --or-esp-5, que é o PISO documentado entre blocos irmãos — mais perto que isso violaria a regra de espaçamento do CLAUDE.md. Regime B: quem traz a margem é o bloco de baixo. / .or-avulsos-nota + .or-avulsos-nota { margin-top: var(--or-esp-5); } / Segundo achado ao vivo (mesmo print, olhar de novo depois do primeiro fix): os 72px de padding-bottom do próprio #avulsos (bg-color-2) são a ÚNICA fonte de respiro antes de "Antes de assinar" — #contratacao usa section-padding-bottom (só a margem DELE mesmo é zero no topo). Um respiro que vem inteiro de UM lado só lê como insuficiente numa transição de cor (cinza→branco): o olho espera folga dos dois lados do corte, não só de um. Escopado à página (o componente #contratacao é só daqui) — sem tocar a classe global do vendor. / .or-pg--planos #contratacao { padding-top: var(--or-esp-7); } / --- Funfacts (evolução F4, generalizado na F6 — /planos E /sobre) — o h2 cru do vendor é 70-100px (style.css:2851-2867), desenhado pra numeral curto ("10K+"); "T1 ⊂ T2 ⊂ T3" e "R$ 1.199" nessa escala estourariam a coluna. Reescala pro token de seção; --color-1 vira --or-border no dark (a divisória some no escuro sem isto — --color-1 nunca é flipado, ver nota da F9 em site_dark_test). Nasceu .or-funfacts-planos (só /planos); renomeado .or-funfacts quando /sobre passou a usar o mesmo componente — era o MESMO fix, evitando 2 regras quase-idênticas. --- / / --or-fs-secao-compacta (não --or-fs-secao): coluna estreita, conteúdo tipo "T1 ⊂ T2 ⊂ T3" — não deve herdar o teto novo de 64px do D3 (estouraria a coluna mais cedo). / / ANCORADO EM .counter-item, NÃO no seletor h2 (03/09/2026). O odômetro contém APENAS o número — o rótulo real vive no
ao lado —, então marcá-lo como heading inventava títulos que não titulam nada: a /sobre chegava a emitir 4
vazios de significado, quebrando a hierarquia da página inteira. A /sobre passou a
(mesmo precedente já adotado no hero da home, .or-home-heronum) e /planos segue com
— este seletor cobre os dois. Por isso peso, margem e line-height agora são EXPLÍCITOS: eram herdados do h2 do vendor (600 / 0 / 110%), e um
herdaria os do corpo — as duas páginas renderizariam o mesmo número em tamanhos diferentes. / .or-funfacts .quanto-funfact-box .counter-item { margin-bottom: 0; font-size: var(--or-fs-secao-compacta); font-weight: 600; line-height: 1.1; letter-spacing: -0.02em; color: var(--color-primary); } .or-funfacts .quanto-funfact-box { border-left-color: var(--color-1); } [data-bs-theme="dark"] .or-funfacts .quanto-funfact-box { border-left-color: var(--or-border); } / Os blocos .or-economia-* ("A conta de contratar avulso", #economia) e .or-inclusos-* ("Tudo que o Presença já inclui") foram REMOVIDOS em 03/09/2026 junto das duas seções de pagina-planos.php que os usavam — decisão do dono. CSS sem markup não quebra nada, mas mente para quem lê depois: sugere um componente vivo que nenhuma tela renderiza. A receita do chip (tinta de marca a 12% sobre fundo) sobrevive em .or-prova-cardchip, que a documenta. / / O destaque da coluna recomendada mudou de nome junto com a tabela: virou .or-comparativorecomendada, definido no BLOCO 18 ao final deste arquivo. / / O bloco de FAQ de /planos (acordeão + Schema::setFaqs correspondente) foi REMOVIDO em 04/09/2026, decisão do dono — junto com ele saem .or-planos-faq (regras acima) e .or-planos-faqgrid (BLOCO 8.1, mais abaixo). CSS sem markup não quebra nada, mas mente pra quem lê depois: sugere um componente vivo que nenhuma tela renderiza. Mesmo precedente de .or-economia-* e .or-inclusos-* (nota logo acima). ⚠️ Nunca escreva "-" seguido de "/" num comentário — a sequência fecha o comentário ali mesmo (achado ao vivo pelo guard C do bin/cliente/auditar-espacamento.php, nesta própria frase, na primeira tentativa de escrevê-la). / /* ================================================================ PRELOADER — marca embutida inline (evolução "identidade visual", 26/08/2026). Substitui o spinner genérico do vendor (anel branco/laranja em torno do raster) quando o cliente tem símbolo em SVG (EMP_LOGO_SIMBOLO — or_preloader_simbolo_inline(), _helpers.php). Fundo reusa var(--or-grad-marca) — o MESMO gradiente do hero — então o preloader deixa de ser uma tela preta genérica e vira a primeira metade do reveal do hero: some sem costura visual. Sem gate de prefers-reduced-motion / data-or-rm de propósito, mesma decisão já registrada acima pro .spinner do vendor (BLOCO de reduced-motion, ~linha 797): feedback de carregamento é movimento ESSENCIAL — WCAG 2.3.3 trata de movimento NÃO essencial, não deste caso. Sem strobe/flash (só rotação e opacidade suaves em ciclo > 1s), então também não esbarra no limiar de 2.3.1 mesmo fora do gate. O dead-man switch (_head.php, inline) continua intocado: mira .preloader (classe-base, sempre presente), não .or-preloader. ================================================================ / .or-preloader { background: var(--or-grad-marca); } .or-preloader__mark { position: relative; width: 132px; height: 132px; color: #fff; / traço dos brackets (currentColor via or_preloader_simbolo_inline()) / } .or-preloadermark svg { position: relative; z-index: 1; display: block; width: 100%; height: 100%; } .or-preloadermark::before { content: ''; position: absolute; inset: -55%; border-radius: 50%; background: radial-gradient(circle, color-mix(in srgb, var(--or-dourado) 40%, transparent) 0%, transparent 72%); filter: blur(18px); animation: or-preloader-glow 2.4s ease-in-out infinite; } / transform-box:view-box ancora a rotação/pulso no CENTRO REAL do símbolo (48,48 no viewBox 96x96) — sem isso, o navegador gira em torno do bounding-box do próprio do arco (uma forma assimétrica), produzindo uma órbita torta em vez de girar no eixo do círculo. / .or-preloaderarc { transform-box: view-box; transform-origin: 48px 48px; animation: or-preloader-spin 1.15s linear infinite; } .or-preloaderdot { transform-box: view-box; transform-origin: 48px 48px; animation: or-preloader-pulse 1.15s ease-in-out infinite; } @keyframes or-preloader-spin { to { transform: rotate(360deg); } } @keyframes or-preloader-pulse { 0%, 100% { transform: scale(1); opacity: 1; } 50% { transform: scale(1.4); opacity: .7; } } @keyframes or-preloader-glow { 0%, 100% { opacity: .45; } 50% { opacity: 1; } } @media (max-width: 575.98px) { .or-preloadermark { width: 104px; height: 104px; } } / ================================================================ BLOCO 4.5 — SEÇÃO PRESENÇA EM IA (#geo) · simulador de perguntas (28/08/2026) ================================================================ #geo era uma
pendurada no fim de
(fusão F5.1, 26/08/2026). Vira SEÇÃO PRÓPRIA com fundo escuro: a página passa a alternar claro (#dor) → escuro (#geo) → claro (#lgpd) → cinza (#servicos), e o painel de vidro .or-hero-resposta só funciona sobre escuro. O
que separava dor/geo saiu junto — com fundos diferentes, a troca de fundo É o divisor. Efeito colateral bem-vindo: some o traço dourado central do .or-divisor, ou seja, esta evolução deixa a página com MENOS dourado, não mais. DOURADO — ZERO ponto novo (lista fechada de 6, BLOCO 0.5): · .or-eyebrow dourada aqui = o MESMO ponto nº6 (eyebrow sobre fundo escuro), já autorizado em .or-home-hero .or-eyebrow e .or-hero-interno--comercial: --marca-primaria sobre fundo de marca é invisível, não é escolha estética. · caret = .or-hero-caret reusado (ponto nº1), zero regra nova. · chip selecionado é BRANCO, não dourado — o vocabulário de "primário sobre escuro" desta base já é a pílula branca (.or-home-herocta). ================================================================ / .or-ia { position: relative; background: var(--or-ink-deep); } / Profundidade sem markup extra — ::before, e não uma
como no hero: lá o glow carrega data-speed (parallax do ScrollSmoother), aqui não há o que pendurar. / .or-ia::before { content: ''; position: absolute; inset: 0; background: radial-gradient(72% 90% at 12% 0%, rgba(var(--marca-primaria-rgb, 11, 61, 145), .5) 0%, transparent 68%); pointer-events: none; } .or-ia > .container { position: relative; z-index: 1; } / .text-color-white é PROIBIDA nesta seção, pelo mesmo motivo do hero: o bloco dark reescreve .text-color-white → var(--or-text) !important, e esta superfície NÃO flipa — a classe "branca" do vendor deixaria de ser branca no escuro. Branco literal, escopado. / .or-ia .or-eyebrow { color: var(--or-dourado); } .or-ia .or-lead { color: rgba(255, 255, 255, .78); opacity: 1; } / .or-lead nasce --color-primary + opacity .75 / .or-iatitulo { color: #fff; } / margin-top SAIU daqui (28/08/2026, CLAUDE.md §Padrão de Espaçamento): quem separava a row do título da row da instrução era este filho (36px, abaixo do piso --or-esp-5) — agora é a PRÓPRIA row (row-padding-top, 60px, home.php), Regime B corretamente aplicado no nível certo. / .or-iainstrucao { margin: 0 0 16px; font-size: var(--or-fs-small); font-weight: 600; text-transform: uppercase; letter-spacing: .08em; color: rgba(255, 255, 255, .62); } / --- .or-iachips/.or-iachip — SEGUNDA VIDA do CSS órfão de .or-superficies__entrega, escrito em 26/08/2026 para uma 2ª linha de pílulas-link que foi removida do markup no MESMO dia (o CSS ficou no arquivo, sem nenhum usuário, até aqui). Borda, raio pill, wash de hover e o rail com scroll-snap no mobile são o MESMO código, MOVIDO — não copiado. O que mudou no transporte: a) TOKENS — lá as cores vinham de --or-sup-tinta/--or-sup-borda, custom properties declaradas DENTRO do bloco .or-superficies; fora dali elas não resolvem. Aqui são literais (mesma escolha de .or-hero-resposta, que também vive sobre escuro fixo). b) ELEMENTO — lá eram (navegação), aqui são

` caía no h3 CRU do vendor (80px) e todo `

e

reais. Duas consequências que ESTA regra existe para tratar, e nenhuma delas é opcional: 1. Seletor por posição não sobrevive à mudança. Com o rótulo virando

vazios de significado, quebrando a hierarquia da página inteira. A /sobre passou a
(mesmo precedente já adotado no hero da home, .or-home-hero__num) e /planos segue com

` isso são 80px (style.css:128) — as perguntas saíam em escala de display, duas linhas cada. A home escapava usando `

`, o que conserta o tamanho e quebra a hierarquia de headings (h2 → h6, pulando dois níveis). Aqui o componente tem tamanho PRÓPRIO, o que libera o `

` caía no h3 CRU do vendor (80px) e todo `

e

reais. Duas consequências que ESTA regra existe para tratar, e nenhuma delas é opcional: 1. Seletor por posição não sobrevive à mudança. Com o rótulo virando

vazios de significado, quebrando a hierarquia da página inteira. A /sobre passou a (mesmo precedente já adotado no hero da home, .or-home-hero__num) e /planos segue com

` isso são 80px (style.css:128) — as perguntas saíam em escala de display, duas linhas cada. A home escapava usando `

`, o que conserta o tamanho e quebra a hierarquia de headings (h2 → h6, pulando dois níveis). Aqui o componente tem tamanho PRÓPRIO, o que libera o `

vazios de significado, quebrando a hierarquia da página inteira. A /sobre passou a
(mesmo precedente já adotado no hero da home, .or-home-hero__num) e /planos segue com