:root{
  --azul: #004a93;
  /* Segundo azul do prototipo, amostrado nos pixels do Figma a 02/09: a
     faixa do apelo final (.cta-final::before) usa #015fa4, diferente do
     --azul de soluciones/formulario (#004a94 no Figma, aqui #004a93).
     Sao dois azuis a serio no desenho, nao o mesmo com margem de erro:
     6,62:1 de contraste com branco por cima, contra 8,72:1 do --azul. So
     entra em .cta-final::before. */
  --azul-cta-final: #015fa4;
  --escuro: #15141c;
  --acento: #0495cf;
  --cinza-claro: #c1c1c1;
  --cinza-texto: #434343;
  /* Ronda de QA 1 (03/09): tom mais claro para os paragrafos de introducao
     de beneficios e solucion. Medido nos pixels do fig-full.png: os dois
     blocos de texto (a introducao de beneficios e os tres paragrafos de
     solucion) usam exatamente #808080, nas duas seccoes -- mas #808080
     sobre --claro da so 3,68:1 de contraste (contra --branco, 3,95:1),
     abaixo do minimo AA de 4,5:1 para texto (testes/contraste_teste.php
     mede exatamente isto nas outras cores da pagina). Em vez de copiar o
     pixel a direito e abrir um buraco de acessibilidade que nunca existiu
     nesta pagina, fica no cinzento mais escuro possivel que ainda bate
     4,5:1 sobre --claro, o fundo mais exigente dos dois (#717171,
     4,55:1 sobre --claro e 4,88:1 sobre --branco) -- a mesma logica ja
     aplicada ao --erro do formulario (medido para bater AA, nao copiado
     cegamente). */
  --cinza-texto-claro: #717171;
  --branco: #ffffff;
  --borda: #c4c8cb;
  --claro: #f6f7f8;

  /* Defeito apanhado a olho pelo cliente (02/09): os botoes nao tinham
     ESTADO nenhum -- passar o rato por cima nao fazia absolutamente nada.
     Estas quatro fichas sao os estados de rato/pressao de --azul e
     --escuro, as duas cores de fundo do botao--principal (Tarefa 9): cada
     par (hover mais escuro do que o normal, active mais escuro ainda) da
     ao utilizador uma confirmacao visual clara, discreta -- so cor, nunca
     movimento, como o proprio prefers-reduced-motion desta folha ja exige
     (mais abaixo). Os outros dois contextos do botao--principal reciclam
     fichas que JA EXISTEM (--claro e --cinza-claro, os dois tons claros do
     :root) em vez de inventar mais duas: --branco (fundo do botao no
     heroi) escurece para --claro no hover e --cinza-claro no active, a
     MESMA escala que --claro/--cinza-claro ja servem no resto da pagina.
     Todos os pares medidos com contraste() em testes/comum.php, minimo AA
     4,5:1 de sobra em qualquer estado: ver testes/botoes_estado_teste.php
     para a tabela completa. */
  --azul-hover: #00396f;
  --azul-ativo: #002c56;
  --escuro-hover: #302e3a;
  --escuro-ativo: #3f3d4a;

  /* 1240 e o que o Figma diz e o que o cliente aprovou; 1305 era so a
     grelha da casa. Tarefa 4. */
  --largura: 1240px;
  --goteira: 24px;
  --seccao: 120px;
  --seccao-mobile: 60px;
  /* Tarefa 3 (escala de tipografia e espaco): segundo degrau do ritmo
     vertical. As oito seccoes tinham todas 120px em cima e 120px em baixo
     (240px entre seccoes, mais de um quarto de um ecra de 900px): um
     espaco IGUAL em todo o lado nao diz o que pertence a quê. --seccao-junta
     e para pares de seccoes que sao a MESMA ideia em dois tempos (um
     argumento e a sua prova), nunca duas seccoes sem relacao. 64px e cerca
     de metade de --seccao: continua a ser uma pausa a serio (as seccoes
     nao se colam), so mais curta do que a de uma mudanca de assunto.
     --seccao-junta-mobile usa o mesmo valor de --esp-5 (ja em uso no
     rodape), para nao inventar mais um numero: 40px e a metade de
     --seccao-mobile (60px) arredondada ao degrau mais proximo ja existente
     na escala de espacos. Ver a lista dos pares e a razao de cada um junto
     as regras que usam esta ficha, mais abaixo na folha. */
  --seccao-junta: 64px;
  --seccao-junta-mobile: 40px;

  --corpo: 16px;
  --linha: 28px;

  --botao-altura: 56px;
  --raio: 2px;
  /* raio dos cartoes das grelhas (beneficios, solucoes, demo, bestech).
     Ronda de QA 1 (03/09): media a serio no fig-full.png (cartao de
     beneficios, canto superior esquerdo, tracando a curva pixel a pixel
     em vez de comparar so o antes/depois a olho) da 4px de figma em
     ambos os eixos (deslocamento horizontal e vertical da curva sao
     identicos, um quarto de circulo limpo) -- 4/1,333 = 3px CSS. Fica em
     4px, nao 3, para nao ficar indistinguivel do --raio dos botoes (2px)
     nem inventar um numero fora da grelha de pixels inteiros; o valor
     antigo (10px, nunca medido a serio, so "parecia certo") desce para
     menos de metade. */
  --raio-cartao: 4px;

  /* Ronda de QA 1 (03/09): sombra subtil dos cartoes de beneficios, no
     lugar do contorno cinzento pesado que la estava. Nao ha como medir
     opacidade/blur de uma sombra em pixels soltos de um PNG (a mancha e
     um degrade continuo, nao uma cor unica como um contorno); fica na
     receita habitual de sombra discreta de cartao branco sobre fundo
     claro, com a cor a partir de --escuro em vez de preto puro (o mesmo
     principio ja usado no --hero-texto-sombra, guardar a sombra inteira
     como ficha em vez de a escrever a mao na regra). */
  --sombra-cartao: 0 1px 2px rgba(21, 20, 28, .04), 0 6px 16px rgba(21, 20, 28, .06);

  /* Raio da capsula do selo do heroi. Medido no prototipo: a capsula tem
     40px de altura e as pontas sao semicirculos, ou seja e um "estadio".
     Um valor alto e a forma normal de o pedir sem prender a altura: o
     browser corta no maximo possivel. */
  --raio-capsula: 999px;

  --titulo: 'Titulo', 'PP Telegraf', system-ui, sans-serif;
  --rotulo: 'Rotulo', 'Lato', system-ui, sans-serif;
  --texto: 'Texto', 'Varela', system-ui, sans-serif;

  /* Ronda de QA 1 (03/09): degrau mais pequeno da escala, medido no
     fig-full.png para a etiqueta de secao (ver --etiqueta-letra abaixo) --
     o padding vertical da caixa e o espaco entre o ponto e o texto, os
     dois medidos a ~3-4px CSS, abaixo do --esp-1 (8px) mais proximo que ja
     existia. */
  --esp-0: 4px;
  --esp-1: 8px;
  --esp-2: 12px;
  --esp-3: 16px;
  --esp-4: 20px;
  --esp-5: 40px;
  /* Tarefa 10: o espacamento vertical de cada linha do acordeao, na escala
     8/16/32 do Figma. Nao ha ainda ficha para o 32: as existentes param no
     20 (--esp-4) e saltam para o 40 (--esp-5). */
  --esp-6: 32px;

  /* Havia uma ficha propria so para o corpo do rodape.php e do
     acordeao.php, com o mesmo valor de --corpo (16px): duas fichas para a
     mesma medida. Saiu; os dois passam a usar --corpo, como o resto do
     corpo da pagina (Ronda de correcao das seccoes sem dono). */
  /* Tarefa 4 (escala de tipografia e espaco): a ficha antiga de 15px (um
     degrau intermedio entre este e --corpo) saiu daqui. Nao tinha origem
     no Figma (que so define 14 para rotulos e 16 para texto corrido) e
     fazia quase o mesmo trabalho de --letra-1 e --corpo. Os dois usos que
     tinha (a resposta do acordeao da FAQ e o texto dos cartoes de
     soluciones) desceram para --letra-1 (14px): a resposta do acordeao
     tem de ficar mais pequena que --corpo (design_teste.php), o que ja
     tirava a hipotese de subir para 16. */
  --letra-1: 14px;

  /* Ronda de QA 1 (03/09): a etiqueta de secao ("· BENEFICIOS", "· SOLUCIÓN
     ADAPTADA"...) media no protótipo, nao a olho -- mesmo metodo ja usado
     para a capsula do selo do heroi: caixa clara sobre fundo, contorno,
     ponto. No fig-full.png (1920 de largura, fator 1,333 confirmado de
     novo nesta ronda contra a altura do botao "SOLICITAR DEMOSTRACIÓN",
     que fecha em 56px/--botao-altura sem tocar em nada) a caixa "·
     BENEFICIOS" mede 97×25px de figma, ou seja ~73×19px CSS -- muito mais
     pequena que a caixa atual (14px de letra, 8/12 de padding, ~36px de
     altura). A altura maiuscula do texto mede 7-8px de figma em DUAS
     etiquetas diferentes (beneficios e soluciones), ou seja ~5,5-6px CSS
     de altura-maiuscula; a 0,72 (racio tipico da Lato/--rotulo) isso da
     ~8px de tamanho de letra. --etiqueta-entrelinha fecha a conta da
     altura da caixa: 8 (letra) + 4+4 (--esp-0, padding vertical) + 1+1
     (contorno) = 18, faltam 9 para bater os ~19 medidos -- por isso a
     entrelinha fica em 9px, nao numa escala do --entrelinha-rotulo (18,
     pensada para 14px). Nao ha texto encolhido a este ponto em mais
     nenhum sitio da pagina; fica so aqui. */
  --etiqueta-letra: 8px;
  --etiqueta-entrelinha: 9px;

  /* Escala de titulos (02/09, medida a serio no protótipo): as alturas de
     MAIUSCULA do h1 e do h2 sao 44px e 41px, ou seja praticamente o mesmo
     tamanho. A hierarquia entre eles NAO vem do tamanho: vem do PESO e da
     LETRA. As letras do h2 do Figma sao as mesmas do texto corrido da
     mesma seccao (familia --texto), so maiores e mais escuras, nunca a
     familia ultra-negrita --titulo que o h1 usa. --titulo-2 fica por isso
     um pouco menor que --titulo-1, uma aproximacao a partir do racio de
     alturas de maiuscula medido (41/44 = 0,932) aplicado ao tamanho do h1
     (45 * 0,932 = 41,9, arredondado a 42): nao ha uma medida de racio
     cabecalho-maiuscula para a familia --texto para confirmar o pixel
     exato, mas o valor fica visivelmente diferente de 45 (nunca igual) e
     perto dele, como o protótipo mostra. --titulo-3 (h3) fica com o valor
     antigo, sem medida propria no Figma, mas tem uso visivel a serio: os
     quatro titulos dos cartoes de solucoes e o indicador do acordeao. (A
     marca do cabecalho e do rodape chegou a usar esta ficha, mas os dois
     passaram a logotipos de imagem no alinhamento com o Figma a 02/09.)

     Achado 1 (revisao de telemovel e a11y, 02/09): --titulo-1 passou de
     45px fixo a clamp(). A 45px fixos em qualquer largura, o h1 do heroi
     (uma frase inteira, nao um titulo curto) quebrava em 7 linhas a
     390x844 e empurrava o CTA principal para 832px de topo, so 12px
     visiveis de 56 no primeiro ecra -- ninguem o via sem deslizar. O
     maximo (45px, o valor exato do Figma, INTOCADO: o clamp atinge o teto
     perto de 1024px de largura de janela e o desktop fica pixel a pixel
     como antes) foi escolhido para o h1 continuar claramente maior do que
     --corpo (16px) e continuar a mandar na pagina em qualquer largura
     (regra do achado: nunca encolher ao ponto de deixar de ser o elemento
     dominante).

     Arrumo do primeiro ecra do telemovel (02/09, segunda ronda): a
     primeira correcao do achado 1 tinha ido longe de mais no sentido
     contrario -- clamp(21px, 9.62px + 3.55vw, 45px) dava 23,5px a 390 (so
     1,47 vezes o --corpo, quase do tamanho do texto corrido), so para
     garantir que o CTA cabia. Com o cabecalho reduzido a um so CTA
     (.cabecalho__acoes, mais abaixo) e o selo do heroi a uma linha so
     (.hero__selo, mais abaixo), sobrou orcamento vertical a serio para
     devolver ao h1: o minimo subiu de 21 para 24px e o coeficiente do vw
     de 3,55 para 3,8 (intercepto de 9,62 para 13), dando 26,68/27,82/29,34px
     a 360/390/430 -- 1,67 a 1,83 vezes o --corpo, contra 1,4 a 1,56 antes.
     Nao foi mais alem: a 360x640 (a largura mais estreita das tres, e a
     mais apertada em altura) o h1 quebra em exatamente 4 linhas com estes
     numeros e sobram 54px por baixo do CTA; um coeficiente maior (testado
     a serio, 3,9/13,2) empurra a MESMA frase para 5 linhas a 360, o que
     come de volta quase todo esse folgo (so 24,6px sobravam) para um
     ganho de menos de 1px de tamanho de letra -- nao compensa o risco.
     Confirmado no Chrome de verdade (ferramentas/medir-primeiro-ecra.js)
     contra as tres larguras de telemovel do achado (360, 390, 430), nao
     escolhido a olho.

     Arrumo do primeiro ecra do telemovel (02/09, terceira ronda): --titulo-1
     passou a fluido nesta mesma ronda, mas --titulo-2 ficou fixo em 42px --
     nasceu aqui a hierarquia invertida que a coordenacao apanhou medindo a
     pagina publicada: a 390px o h1 (23,5px, antes desta ronda) ficava mais
     PEQUENO do que qualquer h2 (42px fixo), 1,8 vezes ao contrario. Duas
     passagens que mexeram no mesmo par de fichas sem se olharem uma a
     outra -- uma tornou o h1 fluido para o botao do heroi caber, outra
     fixou o h2 na escala, e nenhuma mediu as duas juntas.
     A correcao fecha essa costura de vez, nao so o sintoma: --titulo-2
     deixa de ser um numero solto e passa a uma FRACCAO de --titulo-1
     (calc, nao clamp proprio), pela mesma razao 14/15 que ja tinha gerado
     o 42 original (41/44 medido no prototipo, arredondado; ver o
     paragrafo "Escala de titulos" acima). Com o h2 amarrado ao h1 por
     formula, e impossivel o h2 voltar a ultrapassar o h1 nalguma largura
     futura sem alguem mudar esta linha a proposito -- ao contrario de dois
     clamp() independentes, que podem divergir outra vez exatamente como
     divergiram desta vez. Ao mesmo tempo o h2 ganha o mesmo beneficio do
     h1: encolhe no telemovel (a 390, por exemplo, os 42px fixos passam a
     ~26px), o que devolveu ainda mais orcamento vertical ao heroi e
     permitiu subir o h1 mais um pouco nesta ronda (ver os numeros no
     relatorio desta tarefa). guardas/hierarquia_titulos_teste.js mede os
     dois a serio no Chrome, em tres larguras (telemovel/tablet/desktop), e
     falha se algum h2 deixar de ser mais pequeno do que o h1 outra vez.
     --entrelinha-titulo (abaixo) fica so para o h1 (ver .hero__titulo, mais
     abaixo, que a sobrepoe para 1 unitario); o h2 ganhou a sua propria
     entrelinha fluida, ver o comentario junto a "h2{" mais abaixo na folha,
     pela mesma razao: um valor fixo de 45px por linha deixava de fazer
     sentido para um h2 que agora pode ir a metade desse tamanho. */
  --titulo-1: clamp(24px, 13px + 3.8vw, 45px);
  /* 14/15: a mesma razao de alturas de maiuscula medida no prototipo
     (41/44 = 0,932, arredondada) que ja tinha gerado o 42 original a
     partir do 45 do h1 (ver o paragrafo "Escala de titulos" acima). Em vez
     de um segundo numero solto, agora e uma fraccao do proprio --titulo-1:
     ao maximo do clamp (45px, o teto do Figma) da exatamente 42px, pixel a
     pixel como antes (45 * 14 / 15 = 42, sem arredondamento); em qualquer
     largura mais estreita encolhe na mesma proporcao do h1, sem poder
     ultrapassa-lo nunca (o fator e sempre < 1). */
  --titulo-2: calc(var(--titulo-1) * 14 / 15);
  --titulo-3: 22px;
  --entrelinha-titulo: 45px;
  --tracking-titulo: -.9px;

  /* RONDA 2 da correcao de espacos (02/09): o coordenador foi medir o
     protótipo a serio depois da primeira tentativa (--esp-3, 16px) --
     uma coluna de pixels a atravessar "Las soluciones JETCAM" e o
     primeiro cartao, no frame do Figma a 1920 de largura (fator 1,333
     para o desenho a 1440): tinta do titulo em y=2867, cartao em y=2953,
     86px Figma / 1,333 = ~64px de fundo azul entre os dois; descontando a
     folga da propria caixa do titulo (meia entrelinha mais o descendente,
     que nao e "espaco", e parte da caixa do proprio h2) o espaco
     CAIXA-A-CARTAO fica perto de 54px. --esp-3 era um terco disso: tirava
     o zero, mas continuava a ler-se apertado a olho.
     O pedido foi um degrau PROPORCIONAL ao tamanho do titulo, nao mais um
     valor pequeno fixo: --titulo-1 e --titulo-2 sao fluidos (clamp), e a
     entrelinha REAL do h2 em pixels, por construcao, e sempre identica a
     --titulo-1 em qualquer largura (--titulo-2 * 15/14 == (--titulo-1 *
     14/15) * 15/14 == --titulo-1: os dois fatores cancelam-se: ver o
     comentario junto a --titulo-2 acima). Por isso este degrau e so
     "1,2 vezes a entrelinha do h2", expresso diretamente a partir de
     --titulo-1: ao maximo do clamp (45px) da exatamente 45 * 1,2 = 54px,
     o numero medido no protótipo, sem arredondar nada; em qualquer largura
     mais estreita encolhe na MESMA proporcao do proprio h1/h2, o que da
     proporcionalidade a serio (nao so um numero maior fixo para desktop).
     Nao foi possivel confirmar os numeros de faq/demo diretamente no
     protótipo nesta ronda (sem acesso ao Figma nesta sessao); aplica-se o
     MESMO degrau as tres seccoes, como pedido -- soluciones e a unica
     amostra confirmada contra o Figma. Ver testes/espacos_titulo_teste.php
     e o relatorio desta ronda. */
  --titulo-espaco-baixo: calc(var(--titulo-1) * 1.2);

  /* etiqueta que abre cinco seccoes, e tambem os rotulos do rodape
     (EMAIL, CONTACTOS, OTRAS INFORMACIONES): e a escala "Rotulo" inteira
     do Figma (14px, entrelinha 18, espacamento -0.28, peso 700). (O selo
     do cabecalho e o lema do rodape chegaram a usar esta escala como
     texto, mas o selo passou a logotipo de imagem e o lema saiu da
     marcacao no alinhamento com o Figma a 02/09.) */
  --entrelinha-rotulo: 18px;
  --tracking-rotulo: -.28px;

  /* Ronda de QA 2 (03/09): a Tarefa 7 tinha extraido este valor (10px) de
     dois tokens do Figma ("width/302_5" e "width/1240") que descreviam a
     grelha ANTIGA, a largura toda da seccao. Essa grelha deixou de existir
     nesta ronda (ver --demo-grelha-largura abaixo: os quatro cartoes
     passam a um conjunto bem mais estreito e centrado). Medido a serio no
     fig-full.png contra a grelha NOVA: os quatro cartoes da demo (rebordo
     branco a rebordo branco) fecham em 314-625/641-952/968-1279/1295-1606px
     de figma -- cada intervalo mede exatamente 16px de figma (982-... 641-
     625, 968-952, 1295-1279, os tres iguais), 16/1,333 = 12px CSS. */
  --intervalo-demo: 12px;

  /* Tarefa 8: proporcao da imagem do bestech na linha com a grelha de
     cartoes, a partir dos 768px. A conta original (500px, a largura
     intrinseca de um ficheiro antigo, a dividir por 1192) ficou presa a
     um ficheiro que ja nao e o atual (bestech-ecra.webp mede hoje 992px
     intrinsecos, conteudo.php) e nunca tinha sido medida contra o proprio
     --bestech-conteudo-largura (ficha nova desta ronda), que e o
     verdadeiro contentor da imagem+grelha, mais estreito que 1192.
     Ronda de QA 3 (03/09): medida a serio no fig-full.png -- imagem
     548px de figma, grelha 604px, intervalo entre as duas 41px, os tres
     dentro do conjunto de 1193px. Fracao da imagem sobre o disponivel
     para imagem+grelha (excluindo o intervalo): 548/(548+604) = 47,6%,
     arredondado a 46% (a fracao aplica-se sobre --bestech-conteudo-
     largura inteiro, INCLUINDO o intervalo, por isso o numero final e
     um pouco mais baixo que a fracao "pura"; conferido a fechar as
     contas: 46% de 900px = 414px, menos 30px do --bestech-conteudo-
     intervalo, sobra grelha em ~456px -- os dois muito perto dos 411/453
     CSS medidos). */
  --bestech-imagem-proporcao: 46%;

  /* Ronda de correcao da Tarefa 8b: opacidade da camada que escurece a
     fotografia do heroi (.hero::before). Nao e um detalhe tecnico, e uma
     decisao de desenho calibrada para bater a meta de contraste AA
     (4,5:1) da media da foto, por isso ganhou ficha propria em vez de
     ficar a mao na regra. 0,45 da 18,81:1 de media — mas a media escondia
     os picos de luz das chispas do laser (ver comentario em .hero__selo,
     .hero__titulo, .hero__paragrafo mais abaixo: a defesa desses pontos
     e o text-shadow, nao mais opacidade aqui, que estragaria a foto
     inteira para tratar menos de 1% da area). */
  --hero-escurecimento: .45;

  /* Sombra do texto do heroi: a blindagem local contra os pontos da foto
     mais claros do que a camada uniforme acima consegue cobrir (as
     chispas do laser, medidas pixel a pixel na zona real de baixo do
     texto: ver tarefa-8b-relatorio.md). Ao contrario da opacidade do
     ::before, que escurece a FOTO inteira, esta sombra escurece só o
     CONTORNO das LETRAS, por isso protege sem lavar a fotografia. */
  --hero-texto-sombra: 0 2px 6px rgba(0, 0, 0, .7);

  /* Tarefa 10: a coluna do acordeao da FAQ e mais estreita do que o
     contentor de --largura (1240px), para ficar confortavel de ler em
     linhas de pergunta e resposta curtas. O valor original (800px) era
     um "bom senso", sem medida propria no briefing.
     Ronda de QA 3 (03/09): medido a serio no fig-full.png -- a linha da
     pergunta (texto+icone) fecha em 1132px de figma, a resposta em
     1131px (praticamente a mesma largura, como o QA pede) e a linha
     divisoria acompanha os dois, 1132px/1,333 = 849px CSS. Fica em 850,
     a largura certa da coluna: e esta largura maior, e nao so o max-width
     do paragrafo da resposta la em baixo, que resolve o QA "a resposta
     fica limitada a uma coluna demasiado pequena quando abre". */
  --acordeao-largura: 850px;

  /* Ronda de correcao das seccoes sem dono: o cta-final e a demo tinham o
     paragrafo a 1192px (a largura do contentor menos as duas goteiras),
     que a 16px de corpo da por volta de 150 caracteres por linha. O
     intervalo confortavel de leitura e 45 a 75 caracteres por linha
     (medida tipografica, nao gosto): 150 e o dobro do limite superior.
     600px foi medido a serio no browser, no texto real das duas seccoes
     (Range.getClientRects, nao a olho): da 59,3 no cta-final e 45,5/60,0
     nos dois paragrafos da demo, os tres dentro do intervalo com folga
     dos dois lados (ver relatorio desta ronda para a tabela completa).
     Ronda de QA 5 (04/09): --largura-leitura SAI do .cta-final__paragrafo,
     pela MESMA razao que ja tinha tirado --demo-paragrafo-largura da demo
     na ronda de QA 2 (ver o comentario junto a essa ficha, mais abaixo): o
     QA final mediu o Figma a serio (fig-full.png, fator 1,3333) e o
     primeiro paragrafo do cta-final fecha numa UNICA linha ("...tu
     fábrica,"), nao em tres como 600px obrigava -- 1160px de figma
     (377-1537px) / 1,3333 = 870px CSS, a largura da PROPRIA linha mais
     comprida, medida a pixel. --largura-leitura (600) e 270px mais
     estreita do que isto: e uma ficha PARTILHADA com a demo, que continua
     correta para os paragrafos da demo (nao mexida aqui), mas nunca foi
     medida para o cta-final -- so herdada por arrasto de quando as duas
     seccoes ainda partilhavam o mesmo numero, na ronda "sem dono".
     --cta-final-paragrafo-largura nasce como ficha propria, pela mesma
     razao que --demo-paragrafo-largura ja tinha nascido: um numero medido
     a serio vale mais do que uma ficha emprestada que por acaso calha
     perto (o valor final NAO fica em 870: ver o comentario junto a essa
     ficha, mais abaixo, para a afinacao contra a fonte real da pagina).
     --largura-leitura continua a servir so a demo a partir de agora. */
  --largura-leitura: 600px;

  /* Ronda de QA 1 (03/09): largura maxima dos dois paragrafos de
     introducao de beneficios. Medida no fig-full.png, nao reaproveitada
     de --largura-leitura (essa ficha serve cta-final/demo, medida para
     45-75 caracteres por linha, um proposito diferente e fora desta
     ronda para mexer): a linha mais comprida da introducao mede 1168px
     de figma, 876px CSS (1168/1,333, fator confirmado outra vez nesta
     ronda contra a altura do botao "SOLICITAR DEMOSTRACIÓN"). Arredondado
     para cima, com uma pequena folga. */
  --beneficios-paragrafo-largura: 880px;

  /* Ronda de QA 2 (03/09): largura maxima da grelha de cartoes de
     soluciones. Medida no fig-full.png (rebordo branco a rebordo branco
     dos dois cartoes de cada fila, incluindo o intervalo entre eles): o
     primeiro cartao comeca em x=372, o segundo acaba em x=1548 -- 1176px
     de figma, 882px CSS (1176/1,333). Arredondado para baixo, a 880 (a
     mesma folga de poucos pixels que --beneficios-paragrafo-largura usa
     para cima): a grelha do QA atual ocupava quase a largura toda da
     seccao (1192px, o contentor real menos as duas goteiras); no Figma
     fica bem mais estreita e centrada, cerca de 74% dessa largura. */
  --soluciones-grelha-largura: 880px;

  /* Ronda de QA 2 (03/09): largura maxima do conjunto dos quatro cartoes
     da demo. Medida no fig-full.png do mesmo modo que a ficha acima:
     primeiro cartao em x=314, ultimo cartao acaba em x=1606 -- 1292px de
     figma, 969px CSS (1292/1,333). O QA atual reclamava a goteira lateral
     da seccao com margin negativo so para chegar aos 1240 inteiros
     (comentario antigo em .demo__grelha); no Figma o conjunto fica bem
     mais estreito do que isso, por isso essa margem negativa sai e entra
     este max-width. */
  --demo-grelha-largura: 970px;

  /* Ronda de QA 2 (03/09): largura maxima dos dois paragrafos de
     introducao da demo. Medida no fig-full.png: a linha do primeiro
     paragrafo ("Antes de tomar...", uma linha so) vai de x=451 a x=1469,
     1018px de figma, 763,5px CSS (1018/1,333) -- a linha mais comprida
     das duas. --largura-leitura (600px) e estreita de mais para isto:
     force o primeiro paragrafo a quebrar em duas linhas, o que o Figma
     nao mostra (so o segundo quebra, em duas). Ficha propria, nao a
     largura-leitura partilhada com cta-final (fora desta ronda para
     mexer): arredondada para cima com folga suficiente para a linha mais
     comprida caber, mas ainda estreita para o segundo paragrafo continuar
     a quebrar exatamente onde quebra no Figma (a proxima palavra depois
     do ponto de quebra medido, "productivo", so caberia a mais de 820px
     CSS, bem acima desta ficha). */
  --demo-paragrafo-largura: 780px;

  /* Tarefa carrosseis-moveis (08/09): largura de cada cartao dentro dos tres
     carrosseis horizontais do telemovel (soluciones, demo, bestech). Medida
     a serio no Figma real (get_metadata): na seccao "Las soluciones JETCAM"
     (no 83:1645/83:1646) o cartao tem 311,23px de largura dentro de um
     artboard de 375px, 82,99%; na "Solicita una demostración gratuita" (no
     83:1678/83:1679) o cartao tem 311px dos mesmos 375px, 82,93% -- a MESMA
     proporcao nas duas seccoes, o proprio Figma ja desenha as duas como
     carrossel, com o cartao seguinte a espreitar cortado pela borda do
     ecra. Arredondado para 83%. Aplica-se tambem ao carrossel do
     Best-Tech, cuja versao mobile no Figma (no 83:1685) tem um defeito
     conhecido desta ronda (grelha de duas colunas com o segundo cartao
     cortado a meio pela borda do ecra, confirmado por captura, nao um
     carrossel) -- por isso nao serve de referencia de medida ali; a mesma
     proporcao dos outros dois carrosseis garante cartoes do mesmo porte
     visual nas tres seccoes, e fica dentro dos 85-90% que a especificacao
     sugere como ponto de partida. */
  --carrossel-cartao-largura: 83%;

  /* Ronda de QA 5 (04/09): tamanho de letra do lema do rodape ("DONDE LA
     INNOVACIÓN ENCUENTRA LA EXCELENCIA.", ver rodape.php e a regra
     .rodape__lema mais abaixo para a medicao completa contra o
     fig-full.png e o teste no browser real). Ficha propria: nao e
     --titulo-1/--titulo-2 (essas duas sao amarradas por formula uma a
     outra, ver o comentario junto a --titulo-2, e o lema nao pode
     arriscar ultrapassar nenhuma das duas por acidente numa largura
     futura) nem nenhum dos --letra-*/--corpo existentes (todos pensados
     para texto corrido, nao para uma assinatura em --titulo). */
  --rodape-lema-letra: 32px;

  /* Ronda de QA 5 (04/09): largura maxima do paragrafo do cta-final. O
     fig-full.png mede a linha "...tu fábrica," (a mais comprida das duas)
     de x=377 a x=1537, 1160px de figma / 1,3333 = 870px CSS -- mas essa
     largura, aplicada a direito, nao reproduz a quebra do Figma: o texto
     do prototipo nao usa a mesma fonte (--texto, 'Texto'/'Varela') do
     resto desta pagina, so uma aproximacao visual da maqueta, e as duas
     tem metricas de caracter diferentes. A 870px CSS a palavra "te" ainda
     cabe na primeira linha (word wrap testado a serio no Chrome,
     Range.getClientRects por palavra, o mesmo metodo ja usado no resto
     desta folha), o que da tres palavras a mais na primeira linha do que
     o Figma mostra. Testado por bissecao no Chrome real: a quebra exata
     do Figma ("...tu fábrica," numa linha, "te ayudamos..." na seguinte)
     só acontece entre 800px (que ja empurra "fábrica," para a segunda
     linha, quebra CEDO de mais) e 825px (que devolve "te" a primeira,
     quebra TARDE de mais) -- janela de 10 a 20px. 815px fica no meio
     dessa janela confirmada, com folga dos dois lados contra pequenas
     diferencas de metrica entre o fallback do browser e o proprio
     ficheiro .woff2 depois de carregado. */
  --cta-final-paragrafo-largura: 815px;

  /* Ronda de QA 1 (03/09): tamanho de letra dos tres blocos de texto da
     solucion (dois paragrafos + tecnologias). Medido no fig-full.png: a
     altura-maiuscula do "S" de "Sea cual sea..." da 18px de figma, ~13,5
     CSS; a 0,72 (racio cap-height tipico da Varela/--texto) isso da
     ~18,75px de letra, arredondado a 18. */
  --solucion-paragrafo-letra: 18px;

  /* Ronda de QA 1 (03/09): quanto a fotografia da solucion desce em
     relacao ao topo da coluna de texto (etiqueta+titulo), a partir do
     breakpoint de desktop pequeno em que a seccao vira duas colunas (ver
     .solucion__imagem). Medido no fig-full.png: o topo da fotografia
     (y=1992) fica 87px de figma abaixo do topo da etiqueta "SOLUCIÓN
     ADAPTADA" (y=1905) -- 87/1,333 = 65px CSS, muito perto do topo do
     proprio titulo (so 13px de figma de diferenca: a etiqueta e a sua
     margem ocupam quase exatamente esse espaco). Nao ha ficha existente
     com este valor; e um deslocamento proprio desta secao, sem uso em
     mais nenhum sitio da pagina. */
  --solucion-imagem-deslocamento: 65px;

  /* Ronda de QA 1 (03/09): a Segunda passagem (02/09, comentario abaixo)
     tinha escolhido 40px por bom senso, sem acesso ao Figma. Agora com o
     fig-full.png em disco, o icone do primeiro cartao de beneficios mede
     40×39px de figma (bounding box do desenho, canto a canto) = ~30px
     CSS, mais contido do que o "tamanho nativo do SVG" tal como o
     comentario antigo presumia. Fica em 34px, nao exatamente 30: o
     icones_demo_teste.php exige --icone-demo (32px, seccao fora desta
     ronda) estritamente MENOR que esta ficha, e nao ha medida do Figma
     para --icone-demo nesta ronda para justificar mexer nele tambem. 34
     preserva essa relacao com a menor distancia possivel do numero
     medido, sem tocar numa seccao que nao e desta ronda.
     Segunda passagem de alinhamento com o Figma (02/09): tamanho do icone
     dos cinco cartoes de beneficios. Sem medida exata do prototipo para
     isto (nao ha como medir um Figma que nao se pode abrir); o bom senso
     aplicado foi "bastante maior que o texto ao lado", como o briefing
     visual pediu: 40px fica quase 2,9 vezes o --letra-1 (14px) do rotulo
     do titulo por baixo, e bate com o proprio desenho de cada SVG (os
     cinco ficheiros de app/icones/ tem viewBox a rondar 40 unidades de
     largura, por isso 40px era o tamanho "nativo" de cada um -- mas o
     protótipo escala-os para baixo). */
  --icone-beneficio: 34px;

  /* Tamanho dos quatro icones da secao demo (Tarefa icones-demo): mais
     pequeno que --icone-beneficio acima, como manda o prototipo. Mesma
     logica de "tamanho nativo do proprio SVG": os tres icones vetoriais de
     app/icones/demo-*.svg tem o viewBox a rondar 32 a 33 unidades de
     largura (contra as ~40 dos icones de beneficios), por isso 32px e o
     tamanho que nao escala nenhum deles nem para cima nem para baixo. O
     quarto icone (mascara PNG do aperto de mao, ver .cartao__icone--aperto
     mais abaixo) segue a mesma ficha, para os quatro saírem do mesmo
     tamanho na grelha. */
  --icone-demo: 32px;

  /* Tarefa icones-bestech: o circulo azul-escuro por tras dos icones de
     tres das quatro provas do "Quien es Best-Tech" (a quarta, o JETCAM,
     ja tem o logotipo e a bandeira, sem circulo). Fundo #122e40: nao
     existia ficha nenhuma para este tom, novo aqui -- e continua certo
     (Ronda de QA 3, 03/09: medida a cor exata no centro do circulo do
     fig-full.png, bate #122e40 ao pixel). Nao e reaproveitamento de uma
     ficha existente: --icone-beneficio (34) e --icone-demo (32) sao
     tamanhos diferentes, e o fundo escuro do circulo nao e nem --escuro
     (#15141c, o texto do resto da pagina) nem o proprio fundo da seccao.

     Ronda de QA 3 (03/09): o TAMANHO (48px/28px) nunca tinha sido medido
     a serio, so "parecia bem". Medido agora no fig-full.png com deteccao
     de bbox pela propria cor de fundo do circulo (nao a olho): o circulo
     do primeiro cartao fecha em 47x47px de figma (um circulo perfeito,
     confirma a medicao), 47/1,333 = ~35px CSS. Fica em 36, o par certo
     mais proximo (multiplo de 4, como o resto da escala de espacos).
     --bestech-icone-tamanho desce na MESMA proporcao (28 * 36/48 = 21),
     para o desenho continuar a preencher a mesma fracao do circulo. */
  --bestech-circulo-tamanho: 36px;
  --bestech-circulo-fundo: #122e40;
  --bestech-icone-tamanho: 21px;

  /* Ronda de QA 3 (03/09): largura maxima dos dois paragrafos de
     introducao do "Quien es Best-Tech". Medida no fig-full.png (Range de
     texto, nao a olho): a linha mais comprida (primeira linha do segundo
     paragrafo) mede 1061px de figma, 796px CSS (1061/1,333) -- os dois
     paragrafos fecham em duas linhas cada no protótipo, o que --largura-
     leitura (600px, largura de OUTRA secao, para 45-75 caracteres/linha)
     nao permitia: forcava mais quebras do que o Figma mostra. Arredondado
     para cima com pequena folga, como --beneficios-paragrafo-largura. */
  --bestech-paragrafo-largura: 800px;

  /* Ronda de QA 3 (03/09): largura maxima do CONJUNTO imagem+grelha do
     "Quien es Best-Tech". Medida no fig-full.png: o conjunto (rebordo
     esquerdo da imagem ao rebordo direito do ultimo cartao) fecha em
     373-1566px de figma, 1193px de figma, 895px CSS (1193/1,333) --
     bem mais estreito do que a largura de conteudo da seccao (1192px),
     nao a largura toda como a implementacao antiga assumia. Arredondado
     para cima. */
  --bestech-conteudo-largura: 900px;

  /* Ronda de QA 3 (03/09): intervalo entre a imagem e a grelha de
     cartoes, medido no fig-full.png (rebordo direito da imagem ao
     rebordo esquerdo do primeiro cartao): 41px de figma, ~31px CSS
     (41/1,333). --esp-5 (40px, a ficha antiga aqui) ficava 9px acima do
     medido; fica uma ficha propria, mais proxima. */
  --bestech-conteudo-intervalo: 30px;

  /* QA2, ronda 2 (08/09): altura fixa da bandeira de Espanha e do
     logotipo JETCAM dentro do cartao "Distribuidor oficial JETCAM en
     España", so no telemovel (ver .bestech__logos img no @media, mais
     abaixo). O cartao media 235px de altura a 390 de largura, contra
     142px dos outros tres da mesma grelha -- quase o dobro, so porque as
     duas imagens repartiam a LARGURA disponivel entre si (flex:1 1 0,
     Defeito 1, 02/09) e a bandeira, mais quadrada (1,5:1) do que o
     logotipo (~4:1), cresce mais em altura do que em largura quando
     ganha espaco: 146px de largura dava 97px de altura so a bandeira.
     24px fica perto do porte visual do circulo de icone dos outros tres
     cartoes (--bestech-circulo-tamanho, 36px, NAO tocado -- contexto
     diferente, duas imagens lado a lado, nao um icone so), medido a
     serio no Chrome (ferramentas/medir-cartoes-bestech.js, script
     dedicado desta ronda) ate a altura do cartao ficar perto da dos
     outros tres. width:auto no seletor que usa esta ficha preserva o
     racio de cada imagem, sem distorcer nenhuma das duas. */
  --bestech-logo-altura: 24px;

  /* Selo de reconhecimento (scoring TOP 5% PME 2023) no rodape: quadrado
     de origem 1024x1024, apresentado bem mais pequeno, tamanho de prova
     sem dominar a coluna de baixo peso visual em que vive. */
  --rodape-selo-tamanho: 120px;

  /* Achado 2 (revisao de telemovel e a11y, 02/09): alvo minimo de toque,
     WCAG 2.5.8 (AA), 44x44px. Medido a 390 de largura no Chrome de
     verdade (ferramentas/medir-alvo-toque.js, modo alvos): tres links de
     texto solto (sem padding proprio, so a altura da propria linha) iam a
     21 ou 28px de altura -- "ver reconocimiento oficial", e as DUAS
     unicas formas de contacto que funcionam nesta pagina (email e
     telefone, o formulario ainda nao existe). display:inline-flex mais
     min-height:var(--alvo-toque) da a cada um a altura minima exigida sem
     tocar no tamanho do proprio texto. */
  --alvo-toque: 44px;

  /* QA2, ronda 2 (08/09): letra dos dois CTA do cabecalho no telemovel,
     para caberem lado a lado numa linha so (ver .cabecalho__acoes .botao,
     mais abaixo). Nenhuma ficha existente serve: --letra-1 (14px) ainda
     dava 338,7px de largura de nav a 390 (cabe) mas so 312px disponiveis
     a 360 (a mais estreita das tres larguras de referencia do projeto) --
     26,7px a mais do que existe. Medido a serio no Chrome
     (ferramentas/medir-primeiro-ecra.js e um script de medida dedicado
     aos dois botoes), reduzindo ATE caber com folga nas tres larguras
     (360/390/430): 12px fecha a soma dos dois textos, padding e bordas em
     ~299px a 360, contra os 312px disponiveis -- folga de ~13px, por isso
     nao fica preso ao limite exato. */
  --cabecalho-botao-letra: 12px;

  /* Formulario (spec 5): usa --raio-cartao (10px, ja em uso nos cartoes
     das grelhas), sem ficha nova. --erro e nova: nenhuma outra seccao da
     pagina tem mensagem de erro, por isso nao havia cor de erro nenhuma
     no :root. #b3261e da 6,54:1 de contraste com --branco, bem acima do
     minimo AA de 4,5:1 para texto -- ver testes/contraste_teste.php.
     Ronda de QA 4 (03/09): esta ficha so serve a MENSAGEM de erro em si
     quando ainda vivia dentro da caixa branca do formulario (Achado da
     mesma ronda: o QA final manda tirar o grande bloco branco e integrar
     o formulario no fundo azul da seccao -- ver --erro-sobre-azul, logo
     abaixo, para a versao que passa a valer). Fica no :root por
     compatibilidade e por nao ter zero usos (ainda protegida por teste),
     mas o campo__erro do formulario deixa de a usar. */
  --erro: #b3261e;
  /* Ronda de QA 4 (03/09): a mesma mensagem de erro, agora sobre o fundo
     azul do formulario (--azul, #004a93) em vez do branco antigo --erro
     nao serve mais: da 1,34:1, muito abaixo do minimo. #ffb4ab e o tom
     de erro claro do Material Design 3 (dark theme error), escolhido por
     ja ser um vermelho testado para fundos escuros/saturados em vez de
     inventado a olho; mede 5,15:1 contra --azul, acima do minimo AA de
     4,5:1 -- ver testes/contraste_teste.php. */
  --erro-sobre-azul: #ffb4ab;
  /* Feedback visual do botao "ENVIAR SOLICITUD" desativado (formulario.js,
     depois do primeiro clique -- ver .botao:disabled mais abaixo). Mesma
     familia de ficha que --hero-escurecimento (opacidade decorativa),
     por isso ganha token proprio em vez de um numero solto na regra. */
  --botao-desativado-opacidade: .6;
  /* Tamanho do proprio quadrado/circulo nativo de um radio ou checkbox no
     formulario: maior do que o normal do browser (cerca de 13px), para
     ficar proporcional ao --alvo-toque (44px) que envolve cada opcao. */
  --controlo-tamanho: 20px;

  /* Ronda de QA 4 (03/09): o formulario deixa de viver dentro de um
     grande bloco branco e passa a integrar-se no proprio fundo azul da
     seccao, com "apenas um contorno fino" a volta (documento QA final,
     seccao 6, "Estrutura geral da seccao"). --formulario-contorno reusa
     --borda (o mesmo cinza claro ja usado nas linhas dos campos): 5,19:1
     de contraste contra --azul, acima do minimo AA de interface (3:1),
     sem inventar ficha nova so para isto -- por isso NAO ganha variavel
     propria, usa-se var(--borda) diretamente na regra.
     --formulario-largura ("container central mais estreito", mesma
     seccao do documento) NAO foi medida a pixel no Figma: esta sessao
     nao tinha acesso ao ficheiro (MCP do Figma por autorizar). Fica por
     JUIZO, a meio caminho entre --largura-leitura (600px, estreito de
     mais para a grelha de duas colunas dos campos) e --largura (1240px,
     a largura cheia que o documento pede para encolher) -- suficiente
     para duas colunas de campo (min 280px cada mais --goteira) nunca
     ficarem apertadas a partir de 768px. Documentado aqui como JUIZO, e
     nao como medida, para nao se confundir com as fichas medidas a serio
     no resto desta folha; a revisão visual contra o Figma real fica
     pendente de uma ronda com acesso ao proprio ficheiro. */
  --formulario-largura: 760px;
}

@font-face{
  font-family:'Titulo';
  src:url('/ativos/tipos/titulo-800.woff2') format('woff2');
  font-weight: 800;
  font-style: normal;
  font-display: swap;
}
@font-face{
  font-family:'Rotulo';
  src:url('/ativos/tipos/rotulo-700.woff2') format('woff2');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}
@font-face{
  font-family:'Texto';
  src:url('/ativos/tipos/texto-400.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

*,*::before,*::after{box-sizing:border-box}
[hidden]{display:none!important}

body{
  margin:0;
  overflow-x:hidden;
  /* Tarefa 11: torna o body um container de query, so para dar aos fundos
     "full bleed" (main>section::before, .hero__imagem) uma unidade cqw
     que meça a largura REAL de conteudo (a de body, igual a document.
     documentElement.clientWidth) em vez de 100vw, que inclui a barra de
     scroll da janela e por isso media sempre uns pixeis a mais do que
     havia realmente para desenhar. Ver o comentario junto a essas
     regras. */
  container-type:inline-size;
  font-family:var(--texto);
  font-size:var(--corpo);
  line-height:var(--linha);
  color:var(--cinza-texto);
  background:var(--branco);
}

h1,h2,h3{
  margin:0;
  /* Tarefa 11: a uma largura de janela de 320 uma palavra isolada (ex.:
     "demostración" no h2 do .demo, em --titulo-2) pode ficar mais larga
     do que a coluna disponivel; sem onde quebrar, sai visivelmente da
     pagina em vez de ficar dentro da coluna. Isto so age quando uma
     palavra SOZINHA nao cabe: nas quatro larguras de referencia nunca
     acontece. */
  overflow-wrap:break-word;
}
/* Escala de titulos (02/09, ver o comentario junto a --titulo-2 no :root):
   o h1 e o h3 continuam na familia ultra-negrita dos titulos. O h2 sai
   deste grupo de proposito e usa a familia --texto, em peso normal (400,
   o unico que essa familia declara): e o peso e a letra, nao o tamanho,
   que separam o h1 do h2 no protótipo.
   Ronda de QA 2 do peso de letra (08/09): apanhado ao medir com
   getComputedStyle(h1).fontWeight no browser real -- sem font-weight
   proprio aqui, o h1 (e qualquer h3 que nao tivesse a sua propria regra
   mais especifica) herdava o "bold" da folha de estilo por omissao do
   proprio browser para titulos, que resolve a 700, nao a 800. Isto nunca
   se via a olho nu (--titulo so declara UMA cara, 800: o browser usa-a
   de qualquer forma, por ser a unica que existe para a familia, e nao
   sintetiza PARA BAIXO), mas deixava o peso computado a mentir sobre o
   peso real do ficheiro, e fora do alcance do teste "nenhuma regra pede
   um peso que a familia usada nao declara" (esse teste so olha para
   blocos com font-weight escrito a serio). font-weight:800 explicito
   fecha essa lacuna, sem mudar nada visualmente: o hero (h1) nao tem
   overlay de texto proprio no ficheiro do Figma desta ronda (a foto de
   fundo esgota o quadro), por isso o peso 800 aqui fica pela decisao ja
   tomada e medida em rondas anteriores (ver o comentario acima), nao por
   uma nova medicao. */
h1,h3{ font-family:var(--titulo); font-weight:800; }
h1{ font-size:var(--titulo-1); }
h3{ font-size:var(--titulo-3); }
h2{
  font-family:var(--texto);
  font-weight:400;
  font-size:var(--titulo-2);
  /* Arrumo do primeiro ecra do telemovel (02/09, terceira ronda): a
     entrelinha do h2 saiu do grupo "h1,h2" partilhado (abaixo) e ganhou
     esta regra propria, unitaria (sem "px"), por isso escala SEMPRE na
     mesma proporcao do proprio tamanho de letra do h2 -- exatamente o
     mesmo problema que ja tinha sido resolvido para o h1 (.hero__titulo,
     mais abaixo), agora que --titulo-2 tambem e fluido (ver a ficha no
     :root). Um valor fixo de 45px (var(--entrelinha-titulo), a antiga
     regra unica) deixava de fazer sentido para um h2 que no telemovel
     pode ir a pouco mais de metade desse tamanho: cada linha continuava a
     gastar os mesmos 45px de sempre, devolvendo zero do espaco vertical
     que o proprio --titulo-2 fluido tinha acabado de libertar (a mesma
     categoria de defeito do achado 1, agora na costura h1/h2).
     15/14 e o inverso exato da fraccao 14/15 usada em --titulo-2: ao
     tamanho maximo do h2 (42px, o desktop, intocado) da exatamente os
     mesmos 45px de sempre (42 * 15/14 = 45, sem arredondamento) -- so
     muda a partir dai, encolhendo com o h2. */
  line-height:calc(15 / 14);
}
h1,h2{
  letter-spacing:var(--tracking-titulo);
}
/* A entrelinha do h1 fica aqui, so para ele: o h2 ganhou a sua propria
   regra fluida acima. Ha um unico h1 na pagina (.hero__titulo, mais
   abaixo) e essa classe sobrepoe este valor com line-height:1 (unitario,
   pela mesma razao do h2 acima); esta regra fica so como base generica do
   elemento, para nao ficar um h1 sem entrelinha declarada nenhuma se
   algum dia aparecer outro. */
h1{
  line-height:var(--entrelinha-titulo);
}

/* Os h2 abrem centrados em todas as seccoes, EXCETO a solucion: e a unica
   a duas colunas (texto a esquerda, fotografia a direita, ver .solucion
   mais abaixo), por isso o proprio h2 fica a esquerda tambem, alinhado ao
   resto do texto da coluna, e nao centrado sobre a coluna inteira. Essa
   excecao esteve ausente entre o Defeito 2 (relatorio de 02/09, que tirou
   a fotografia errada e reduziu a seccao a uma coluna centrada) e a
   fotografia certa chegar; volta agora com .solucion__titulo, mais
   especifico do que este seletor por classe (ver bloco da solucion).

   Defeito apanhado a olho pelo cliente (02/09): o titulo (h2) de soluciones
   e de faq ficava COLADO ao que vinha a seguir (a grelha de cartoes, o
   acordeao), 0px de distancia, medido a 1780 e a 390 por igual. A causa e
   "h1,h2,h3{margin:0}" (acima): nunca existiu espaco definido por baixo de
   um titulo, so o acidente da entrelinha/tipo de letra antigos do h2 (que
   desapareceu quando o h2 passou para o tipo do texto corrido, na escala de
   titulos deste 02/09).

   RONDA 2, mesmo dia: a primeira correcao usava margin-bottom:var(--esp-3)
   (16px, o mesmo valor que ja dava o gap titulo->paragrafo em beneficios/
   bestech/solucion/cta-final via margin-top no proprio paragrafo, com as
   margens a colapsar). Tirava o zero, mas o coordenador foi medir o
   protótipo a serio (coluna de pixels em soluciones, ver o comentario
   junto a --titulo-espaco-baixo no :root) e o numero real e ~54px: --esp-3
   era so um terco disso, um valor PEQUENO FIXO onde era preciso um degrau
   PROPORCIONAL ao tamanho do proprio titulo. margin-bottom:
   var(--titulo-espaco-baixo) substitui-o: 54px no maximo do clamp do h1/h2
   (o numero medido), encolhendo na mesma proporcao do proprio titulo em
   qualquer largura mais estreita -- nunca mais um numero solto.
   Margens verticais entre irmaos de bloco continuam a COLAPSAR: em
   beneficios/bestech/solucion/cta-final o proprio paragrafo que se segue
   ja tem margin-top (--esp-3, mais pequeno), por isso o resultado nessas
   quatro seccoes passa a ser o MAIOR dos dois, --titulo-espaco-baixo -- o
   mesmo degrau agora tambem visivel ali, de proposito: o pedido foi um so
   degrau a servir qualquer titulo de seccao, nao um valor por seccao.
   guarda a serio, no Chrome: ferramentas/medir-espacos.js (ligado a
   verificar.sh), que mede o gap final em pixels e nao so a regra; o piso
   de 4px desse guarda fica intocado de proposito -- e para apanhar zeros,
   nao para garantir o numero exato, que e o proprio teste em PHP que
   exige (testes/espacos_titulo_teste.php). */
main>section h2{
  text-align:center;
  margin-bottom:var(--titulo-espaco-baixo);
}

main>section{
  position:relative;
  z-index:0;
  max-width:var(--largura);
  margin:0 auto;
  padding:var(--seccao-mobile) var(--goteira);
}
@media (min-width: 768px){
  main>section{
    padding-top:var(--seccao);
    padding-bottom:var(--seccao);
  }
}

/* Tarefa 3 (escala de tipografia e espaco): ritmo vertical por proximidade,
   metade 1 de 2. Esta regra tem especificidade maior do que "main>section"
   (classe bate elemento+combinador, em qualquer largura), por isso ganha
   sempre a essa e so muda o padding-bottom de quem apanha, nunca os quatro
   lados. So dois pares de seccoes ficam mais apertados, cada um
   justificado (ver a lista completa e a razao de cada par no comentario
   junto a --seccao-junta no :root); esta metade cobre so o LADO DE CIMA de
   cada par (.solucion e .faq, as primeiras seccoes de cada dupla). O lado
   de baixo (.soluciones e .cta-final) NAO entra aqui: cada uma ja tem uma
   regra propria mais abaixo na folha (.soluciones: color, separada do
   grupo .hero,.bestech por esta mesma tarefa; .cta-final: color+text-align,
   Ronda de correcao das seccoes sem dono), e o padding-top entra la, na
   mesma regra, tanto a versao mobile como a desktop (@media logo a
   seguir a cada uma) — para nao haver duas regras separadas com o mesmo
   seletor sozinho na folha (a mesma razao que ja levou o text-align do
   cta-final para dentro da regra dele). Juntar as duas metades aqui
   colocaria ".soluciones,.cta-final{...}" DENTRO de um @media que vem
   ANTES das regras reais dessas duas seccoes na folha: qualquer teste que
   leia "a regra de .soluciones" ou "a regra de .cta-final" (bloco_do_seletor,
   so devolve a primeira que encontra) acertava neste bloco em vez do bloco
   real, sem a cor nem o text-align. */
.solucion,
.faq{
  padding-bottom:var(--seccao-junta-mobile);
}
@media (min-width: 768px){
  .solucion,
  .faq{
    padding-bottom:var(--seccao-junta);
  }
}

/* Ronda de QA 1 (03/09): o espaco ACIMA do identificador de beneficios (a
   seguir ao heroi) e de solucion (a seguir aos cartoes de beneficios)
   estava a usar o --seccao generico (120px), quase o dobro do medido no
   fig-full.png. Medido a serio: hero->BENEFICIOS da 68px de figma (51px
   CSS) e beneficios->SOLUCIÓN ADAPTADA da 154px de figma (115px CSS,
   ~154/1,333), os dois muito mais perto de --seccao-junta (64px) do que
   de --seccao (120px) -- por isso reutiliza-se a ficha que ja existe, em
   vez de inventar uma terceira. O padding-bottom de .solucion nao muda
   (fica no bloco acima, ja --seccao-junta): esta regra so acrescenta o
   padding-top que faltava nas duas seccoes desta ronda. As outras
   seccoes (soluciones, demo, bestech, caso, formulario, faq, cta-final)
   ficam de fora, por nao terem sido medidas nesta ronda -- corrigem-se
   quando a sua propria ronda de QA chegar. */
.beneficios,
.solucion{
  padding-top:var(--seccao-junta-mobile);
}
@media (min-width: 768px){
  .beneficios,
  .solucion{
    padding-top:var(--seccao-junta);
  }
}

/* Correcao a ronda de QA 1: faltava o outro lado do par. O comentario
   acima so mudou o padding-TOP de .solucion (o espaco antes do
   identificador SOLUCIÓN ADAPTADA), mas deixou o padding-bottom de
   .beneficios no --seccao generico (120px). O par ficava com 120+64=184px
   de vao, quase o dobro do medido no fig-full.png (154px figma, ~115px
   CSS). O padrao ja estabelecido para um par apertado (ver .soluciones,
   que tambem tem o seu padding-top proprio a seguir a .solucion) e os
   DOIS lados que se tocam ganharem --seccao-junta, nunca um so; beneficios
   e solucion sao a mesma familia de par (um bloco de argumentos seguido
   do que o mostra na pratica). 64+64=128px, mais perto do medido do que
   os 184 que ficavam. */
.beneficios{
  padding-bottom:var(--seccao-junta-mobile);
}
@media (min-width: 768px){
  .beneficios{
    padding-bottom:var(--seccao-junta);
  }
}

/* O ritmo dos fundos: cada seccao pinta a toda a largura da janela, com o
   conteudo a continuar limitado a --largura (1240), sem mexer na
   marcacao. O ::before e absoluto a 100cqw (Tarefa 11: era 100vw, ver o
   comentario no body sobre container-type), centrado com left:50% mais a
   translacao de -50%, e fica atras do conteudo com z-index:-1 dentro do
   proprio contexto de empilhamento da seccao (por isso o z-index:0 acima). */
main>section::before{
  content:'';
  position:absolute;
  top:0;
  bottom:0;
  left:50%;
  width:100cqw;
  transform:translateX(-50%);
  z-index:-1;
}
.hero::before,
.bestech::before{
  background:var(--escuro);
}
/* Tarefa 8b: sobre a fotografia do heroi (.hero__imagem, mais atras ainda)
   o ::before deixa de ser um fundo solido para passar a camada que
   escurece a foto o suficiente para o texto branco continuar legivel.
   Fica a mesma ficha --escuro do fundo solido das outras seccoes (o
   contraste_teste.php le exatamente essa cor, sem saber que por cima ha
   uma fotografia), so que agora semi-transparente com --hero-escurecimento
   (ficha, ronda de correcao), para a foto continuar visivel por baixo.
   Contraste medido manualmente (nao ha teste automatico para texto sobre
   fotografia): branco sobre a MEDIA da zona onde o texto assenta, com
   esta camada por cima, da cerca de 18,8:1, bem acima do minimo AA de
   4,5:1 — mas a media escondia os picos de luz das chispas do laser (ver
   tarefa-8b-relatorio.md, ronda de correcao): pixel a pixel, ha pontos
   dentro da zona real de baixo do texto que ficam abaixo de 4,5:1. Nao se
   resolve aumentando esta opacidade (estragava a foto para tratar menos
   de 1% da area): a defesa desses pontos e o text-shadow no proprio
   texto, mais abaixo. */
.hero::before{
  opacity:var(--hero-escurecimento);
}
.beneficios::before,
.demo::before,
.caso::before,
.faq::before{
  background:var(--claro);
}
.solucion::before{
  background:var(--branco);
}
.soluciones::before,
.formulario::before{
  background:var(--azul);
}
/* --azul-cta-final, nao --azul: os dois azuis do prototipo, medidos nos
   pixels do Figma a 02/09 (ver o comentario junto a ficha, no :root). */
.cta-final::before{
  background:var(--azul-cta-final);
}

/* Sobre fundo escuro ou azul, o texto normal (herdado do body em cinza)
   inverte para branco. No heroi o fundo escuro e a fotografia (Tarefa 8b,
   .hero__imagem mais abaixo); nas outras duas o fundo solido chega pelo
   ::before acima. */
.hero{
  color:var(--branco);
}
/* .bestech sai do grupo ".hero,.bestech" (a mesma razao do .soluciones
   logo abaixo: dar-lhe um padding-top proprio sem criar uma segunda
   regra ".bestech{...}" solta na folha, que deixaria bloco_do_seletor
   (so devolve a primeira que encontra) cego a esta cor nalgum teste).
   Ronda de QA 3 (03/09): o padding-TOP do bestech (o espaco entre o
   fundo escuro comecar e o identificador "QUIÉNES BEST-TECH") media
   100px de figma no fig-full.png, 75px CSS (100/1,333) -- perto de
   --seccao-junta (64px, 11px de diferenca) e longe de --seccao (120px,
   45px de diferenca), apesar de o demo->bestech NAO ser um dos pares
   apertados da lista (esse lado ja estava resolvido: .demo{padding-
   bottom:var(--esp-5)}, medido na ronda anterior). Fica --seccao-junta,
   a ficha existente mais proxima, sem inventar um numero novo so para
   este lado. O padding-BOTTOM fica no --seccao generico (nao entra
   aqui): o fig-full.png mede 157px de figma / 118px CSS ate ao fim do
   fundo escuro, muito perto do default (120px) -- sem correcao a fazer. */
.bestech{
  color:var(--branco);
  padding-top:var(--seccao-junta-mobile);
}
@media (min-width: 768px){
  .bestech{
    padding-top:var(--seccao-junta);
  }
}
/* .soluciones sai do grupo acima e ganha regra propria (com a mesma cor,
   repetida) porque a Tarefa 3 (escala de tipografia e espaco) precisa de
   lhe dar um padding-top proprio, e duas regras separadas com o mesmo
   seletor sozinho na folha tornam os testes que leem "a regra de
   .soluciones" ambiguos (bloco_do_seletor devolve so a primeira que
   encontra). Ver o comentario junto a --seccao-junta no :root para a
   razao do padding: a soluciones e a prova da solucion logo acima, ficam
   mais proximas do que duas seccoes sem relacao. */
.soluciones{
  color:var(--branco);
  padding-top:var(--seccao-junta-mobile);
}
@media (min-width: 768px){
  .soluciones{
    padding-top:var(--seccao-junta);
  }
}

/* A seccao do formulario (spec 5): titulo e paragrafo introdutorio a
   branco e centrados sobre o fundo azul (.formulario::before, acima),
   igual ao padrao ja usado em soluciones/cta-final. O conteudo em si
   fica dentro da caixa branca (.formulario__caixa, mais abaixo), que
   troca a cor de volta para o texto normal da pagina -- e por isso esta
   regra fica so no proprio elemento .formulario, nunca com !important
   nem repetida, a caixa e que sobrepoe por especificidade. */
.formulario{
  color:var(--branco);
  text-align:center;
}

/* Ronda de correcao das seccoes sem dono: cta_final.php nunca foi aberto
   pelos 22 commits desta ronda, e o que la estava tinha vindo por arrasto
   de outras tarefas (fundo azul da Tarefa 4, cor do botao da Tarefa 9,
   anel de foco da Tarefa 11): o h2 saia centrado so por apanhar a regra
   global "main>section h2", mas o paragrafo e o botao saiam encostados a
   esquerda, ninguem tinha decidido isso. E o ultimo apelo a acao da
   pagina: compoe-se centrada por inteiro. text-align entra na mesma regra
   da cor (herdada, tal como as outras tres seccoes acima) para nao haver
   duas regras separadas com o mesmo seletor sozinho na folha. Tarefa 3
   (escala de tipografia e espaco): padding-top entra aqui tambem, pela
   mesma razao: e o segundo degrau do ritmo vertical (ver o comentario
   junto a --seccao-junta no :root e junto a regra de proximidade logo
   depois de main>section): a faq e o cta-final sao o mesmo gesto de
   venda em dois tempos, ficam mais proximas do que duas seccoes sem
   relacao. */
.cta-final{
  color:var(--branco);
  text-align:center;
  padding-top:var(--seccao-junta-mobile);
}
@media (min-width: 768px){
  .cta-final{
    padding-top:var(--seccao-junta);
  }
}
/* Ronda de QA 5 (04/09): --cta-final-paragrafo-largura (ficha no :root)
   no lugar de --largura-leitura, pela mesma razao que ja tinha tirado a
   demo dessa ficha partilhada na ronda de QA 2 -- ver o comentario junto
   a ficha para a medicao completa. */
.cta-final__paragrafo{
  max-width:var(--cta-final-paragrafo-largura);
  margin:var(--esp-3) auto;
}

:focus-visible{
  outline:3px solid var(--acento);
  outline-offset:2px;
}

/* Achado 3 (revisao de telemovel e a11y, 02/09): quem pede menos movimento
   pede MENOS movimento, nao NENHUMA resposta. O corte antigo
   ("*{animation-duration:.01ms!important;transition-duration:.01ms!important}")
   travava toda e qualquer transicao pela DURACAO, sem olhar a que
   PROPRIEDADE estava a animar: apagava por igual uma transformacao que
   desloca ou redimensiona (a causa real de nausea/desorientacao que esta
   media query existe para evitar) e uma simples mudanca de cor ou de
   opacidade ao passar o rato, que nao desloca nada e serve so de
   confirmacao visual.
   animation-duration continua cortada: uma animacao contínua por
   keyframes (ex.: um spinner) e a mesma categoria de problema que um
   deslocamento, reduzida a praticamente zero como antes.
   transition-property, em vez de transition-duration, e o que faz a
   distincao: aplicada a `*`, restringe TODAS as transicoes da pagina a
   esta lista curta. Uma transicao declarada nalgum sitio para transform,
   width, height, top ou left deixa de correr (a propriedade fica de fora
   da lista, muda de imediato, sem transicao nenhuma, o mesmo resultado do
   corte antigo para essas propriedades); color, background-color,
   border-color e opacity continuam a animar, com a duracao que ja
   tinham. scroll-behavior:auto trava tambem um scroll-behavior:smooth que
   venha a existir (nao ha nenhum na folha hoje; entra aqui de qualquer
   forma, por seguranca, porque um scroll animado grande e a mesma
   categoria de deslocamento que a media query existe para evitar). */
@media (prefers-reduced-motion: reduce){
  *,
  *::before,
  *::after{
    animation-duration:.01ms!important;
    animation-iteration-count:1!important;
    transition-property:color,background-color,border-color,opacity!important;
    scroll-behavior:auto!important;
  }
}

.saltar{
  position:absolute;
  left:-9999px;
  top:0;
  z-index:100;
  background:var(--branco);
  color:var(--escuro);
  padding:var(--esp-2) var(--esp-4);
  border-radius:var(--raio);
}
.saltar:focus{
  left:var(--goteira);
  top:var(--goteira);
}

.cabecalho{
  background:var(--branco);
  border-bottom:1px solid var(--cinza-claro);
}
/* Tarefa 11: o nav (.cabecalho__acoes) tem dois CTA com white-space:nowrap
   (Tarefa 9) e a 375 de largura de janela precisam de 444 de largura so os
   dois, mais o gap: nunca coube ao lado da marca. flex-wrap:wrap deixa o
   nav cair para uma linha propria quando nao ha espaco ao lado da marca, e
   o padding vertical (ausente antes, so havia min-height) da folga as duas
   linhas quando isso acontece. min-height fica: continua a ser a altura
   minima de UMA linha, com um so botao por linha ou os dois lado a lado em
   ecras largos. */
.cabecalho__caixa{
  max-width:var(--largura);
  margin:0 auto;
  padding:var(--esp-2) var(--goteira);
  display:flex;
  flex-wrap:wrap;
  align-items:center;
  justify-content:space-between;
  gap:var(--goteira);
  min-height:calc(var(--botao-altura) * 1.6);
}
/* Ambos os logotipos, Best-Tech e JETCAM, sao <img> desde 02/09: o
   protototipo mostra os dois lado a lado sobre fundo branco, e nenhum
   dos dois e texto que se estile. align-items:center (nao baseline,
   nao ha texto para alinhar pela linha de base) porque o JETCAM
   aparece com uma altura de apresentacao menor do que o Best-Tech no
   prototipo (as duas alturas, escolhidas e justificadas, vivem no
   width/height de cada <img> em cabecalho.php, nao aqui). */
.cabecalho__marcas{
  display:flex;
  align-items:center;
  gap:var(--esp-2);
}
.cabecalho__marca,
.cabecalho__selo{
  display:block;
}
/* Os dois botoes (nowrap cada um) tambem quebram entre si quando o nav
   inteiro, sozinho, nao cabe na largura disponivel (entre a marca e a
   goteira direita): fica um por baixo do outro em vez de forcar a pagina
   inteira a alargar. */
.cabecalho__acoes{
  display:flex;
  flex-wrap:wrap;
  align-items:center;
  justify-content:flex-end;
  gap:var(--esp-2);
}
/* Arrumo do primeiro ecra do telemovel (02/09): a 390px os dois CTA
   ("Solicitar demostración" e "Pedir presupuesto") nao cabiam lado a
   lado com o padding/letra da regra base do .botao (--goteira/24px e
   --corpo/16px, os mesmos do botao "ENVIAR SOLICITUD" do formulario) e
   quebravam para duas linhas, com o proprio nav a cair para uma linha
   propria debaixo da marca (flex-wrap acima): o cabecalho inteiro ia a
   207px, um quarto do ecra de 844, antes de a pagina sequer comecar. A
   correcao de 02/09 escondia o CTA secundario no telemovel por inteiro.

   QA2, ronda 2 (08/09): o Figma real (nó 83:1596, "Navbar-7", quadro
   movel medido pixel a pixel a 375px de largura) mostra os DOIS botoes
   lado a lado, numa unica linha -- so que muito mais estreitos e mais
   baixos do que a implementacao anterior: ~160px o secundario e ~145px
   o principal (medidos no PNG nativo do no), contra os ~330/~300px que
   o padding/letra da regra base do .botao davam aqui. A causa do
   problema de 02/09 nunca foi TER dois botoes: foi te-los tao largos
   quanto no resto da pagina. Esta regra reduz o padding lateral e a
   letra destes DOIS botoes especificos do cabecalho (nunca a regra base
   .botao, que continua a servir o resto da pagina com --goteira/--corpo)
   -- --esp-1 (8px) no lugar de --goteira (24px), --cabecalho-botao-letra
   (12px, ficha nova, ver a justificacao junto a ela no :root) no lugar
   de --corpo (16px, herdado) -- medido a serio no Chrome
   (ferramentas/medir-primeiro-ecra.js e um script de medida dedicado aos
   dois botoes) nas tres larguras de referencia do projeto (360/390/430)
   ate os dois caberem numa linha so sem quebrar, com o botao do heroi a
   continuar dentro do primeiro ecra.

   min-height fica em --alvo-toque (44px), NAO nos 36-38px que o Figma
   desenha para estes botoes: WCAG 2.5.8 nao se negocia (excecao ja
   conhecida deste projeto, ver o comentario junto a --alvo-toque no
   :root) -- o Figma manda no desenho, a acessibilidade manda no alvo de
   toque. line-height:1 acompanha o min-height: a regra base do .botao
   herda --linha (28px, pensado para paragrafos, nao para um botao de uma
   linha so) do body, e SEM este ajuste o min-height:44px fica letra
   morta -- a caixa de linha de 28px, mais os --esp-2 (12px) de padding
   vertical de cada lado e os 2px de borda de cada lado, ja fecha em 56px
   por si so, sempre acima do minimo, nunca limitado por ele. Com
   line-height:1 a caixa de linha volta a ser do tamanho da propria letra
   (~12px), e o min-height:44px passa a ser quem decide a serio. Ver o
   relatorio desta ronda para os numeros finais medidos.

   O texto continua intocado em cabecalho.php: e so a apresentacao que
   muda, por CSS. 767px, nao 768: o resto da folha usa min-width:768px
   para "a partir do tablet"; max-width:767px e o espelho exato desse
   limite, sem sobrepor nem deixar um pixel por cobrir entre os dois. */
@media (max-width: 767px){
  .cabecalho__acoes .botao{
    padding-left:var(--esp-1);
    padding-right:var(--esp-1);
    min-height:var(--alvo-toque);
    font-size:var(--cabecalho-botao-letra);
    line-height:1;
  }
}

/* Branco sobre var(--acento) da 3,38:1 e o minimo AA para texto e 4,5:1.
   var(--azul) da 8,75:1, por isso e a cor de fundo do botao principal e do
   selo JETCAM. var(--acento) fica para acentos decorativos e para o anel de
   foco. A familia e a --titulo (PP Telegraf UltraBold), que so tem UM peso
   a serio, o 800: pedir outro peso a ela, ou pedir 700 a --texto, obriga o
   browser a sintetizar o negrito. */
/* Tarefa 11: height fixo mais white-space:nowrap prendiam o texto a uma so
   linha e OBRIGAVAM o botao a ficar tao largo quanto o texto mais comprido
   da pagina ("CONTACTAR CON UN ESPECIALISTA"), que a 320-360px nao cabe na
   coluna da seccao e alargava a pagina inteira. min-height (em vez de
   height) deixa o botao crescer para uma segunda linha quando precisa, e a
   remocao do nowrap e o que permite essa segunda linha existir; o padding
   vertical (--esp-2, novo aqui — antes so havia padding horizontal) da
   folga as duas linhas quando isso acontece. Em qualquer largura onde o
   texto cabe numa linha (a esmagadora maioria dos casos) o resultado
   visual nao muda nada. */
/* Defeito apanhado a olho pelo cliente (02/09): nao havia UMA SO regra
   :hover para .botao em toda a folha -- passar o rato por cima nao fazia
   absolutamente nada. transition-property (background-color, color,
   border-color) e exatamente a lista que o prefers-reduced-motion desta
   folha ja deixa passar (ver o bloco @media mais abaixo): cor, nunca
   movimento, por isso nao precisa de nenhuma excecao nova ali. .2s ease e
   discreto de proposito -- pagina industrial B2B, nao um produto de
   consumo; ver os estados por contexto em .botao--principal/--secundario
   mais abaixo, e a tabela de contraste de cada um em
   testes/botoes_estado_teste.php. */
.botao{
  display:inline-flex;
  align-items:center;
  justify-content:center;
  min-height:var(--botao-altura);
  padding:var(--esp-2) var(--goteira);
  border-radius:var(--raio);
  font-family:var(--titulo);
  font-weight:800;
  text-decoration:none;
  text-align:center;
  border:2px solid transparent;
  transition:background-color .2s ease, color .2s ease, border-color .2s ease;
}
.botao--principal{
  background:var(--azul);
  color:var(--branco);
}
/* Ronda de QA 4 (03/09): feedback visual do botao "ENVIAR SOLICITUD"
   apos o clique (formulario.js desativa o botao no 'submit', so para
   impedir um SEGUNDO clique -- NUNCA a primeira submissao, que ja segue
   para o servidor antes deste script correr). opacity, nao mais nada:
   a mesma familia de mudanca "so cor/opacidade, nunca movimento" que o
   resto dos estados de botao ja segue (Achado do cliente, 02/09), por
   isso nao precisa de excecao nova no bloco de prefers-reduced-motion.
   cursor:not-allowed e universal, sem ficha propria (nao e cor nem
   medida da marca). */
.botao:disabled{
  opacity:var(--botao-desativado-opacidade);
  cursor:not-allowed;
}
.botao--secundario{
  background:transparent;
  color:var(--azul);
  border-color:var(--azul);
}

/* Tarefa 9: o botao--principal inverte-se pelo CONTEXTO da seccao onde
   vive, nunca por uma classe nova na marcacao. Sobre fundo claro (a regra
   acima, cabecalho e demo) fica azul com texto branco. Sobre a foto
   escura do heroi, azul-sobre-azul deixa de fazer sentido como
   "invisivel numa foto escura": fica branco com texto escuro. Sobre o azul
   solido do cta-final, azul-sobre-azul E LITERALMENTE invisivel (o botao
   desaparece dentro da seccao, borda transparente incluida); fica escuro
   com texto branco, a mesma ficha --escuro do fundo do heroi e do
   bestech. Os tres pares medidos com contraste() em testes/comum.php: ver
   testes/contraste_teste.php. */
.hero .botao--principal{
  background:var(--branco);
  /* AMOSTRADO NOS PIXELS DO PROTOTIPO (Figma) a 02/09: o texto do botao
     sobre a foto do heroi e #004a94, ou seja var(--azul), e NAO
     var(--escuro). Esta linha ja foi trocada uma vez ao contrario (para
     --escuro, a dizer que era o que o protótipo mostrava): estava errado.
     O Figma manda em tudo. Nao voltar a trocar sem medir os pixels de
     novo. */
  color:var(--azul);
}
.cta-final .botao--principal{
  background:var(--escuro);
  color:var(--branco);
}

/* Defeito apanhado a olho pelo cliente (02/09): estado de rato e de
   pressao, um par por CONTEXTO (a mesma logica de por-contexto da Tarefa
   9 acima, nunca uma classe nova na marcacao). :hover primeiro, :active
   depois na folha: mesma especificidade (um pseudo-classe cada), por isso
   quando as duas se aplicam ao mesmo tempo (rato pousado E botao premido)
   ganha a que vem depois na fonte -- :active, o estado mais "fundo" dos
   dois, tem de ganhar ao :hover.

   Contexto 1 (azul sobre fundo claro, cabecalho): --azul-hover/--azul-ativo,
   duas fichas novas (ver :root), cada uma mais escura do que a anterior.
   Contexto 2 (branco sobre a foto do heroi): recicla --claro e
   --cinza-claro, que ja existem no :root para outra coisa -- a MESMA
   escala de "branco -> cinza claro -> cinza mais escuro" que o resto da
   pagina ja usa, sem inventar fichas novas so para isto.
   Contexto 3 (escuro sobre o azul do cta-final): --escuro-hover/
   --escuro-ativo, fichas novas (--escuro em si e quase preto; escurecer
   ainda mais nao dava nenhuma diferenca visivel, por isso as duas CLAREIAM
   um pouco em vez de escurecer, na mesma direcao das outras duas -- "mais
   afastado do extremo" e o gesto comum aos tres contextos).
   Todos os pares medidos com contraste(), minimo AA 4,5:1: ver a tabela
   completa em testes/botoes_estado_teste.php. */
.botao--principal:hover{
  background:var(--azul-hover);
}
.botao--principal:active{
  background:var(--azul-ativo);
}
.hero .botao--principal:hover{
  background:var(--claro);
}
.hero .botao--principal:active{
  background:var(--cinza-claro);
}
.cta-final .botao--principal:hover{
  background:var(--escuro-hover);
}
.cta-final .botao--principal:active{
  background:var(--escuro-ativo);
}
/* botao--secundario (contorno azul, fundo transparente): o estado de rato
   PREENCHE o fundo com --azul e troca o texto para --branco -- o mesmo
   par de cores ja usado (e ja medido) no botao--principal desta mesma
   seccao clara, por isso nao precisa de um contraste novo para justificar.
   O active fica mais escuro ainda (--azul-ativo), o mesmo gesto "mais um
   passo na mesma direcao" dos outros tres contextos. border-color fica
   sempre --azul (nunca muda): com o fundo preenchido a bordo deixa de se
   notar, e ao sair do hover a borda ja esta na cor certa para o estado
   normal, sem salto. */
.botao--secundario:hover{
  background:var(--azul);
  color:var(--branco);
}
.botao--secundario:active{
  background:var(--azul-ativo);
  color:var(--branco);
}

/* Tarefa 11: o anel de foco global (:focus-visible, --acento) da so
   2,58:1 sobre o azul do cta-final, abaixo do minimo AA de interface
   (3:1). Mesmo padrao da Tarefa 9 para os botoes: troca-se por CONTEXTO
   de seccao, nunca mudando a ficha --acento (que continua a servir de
   acento decorativo e de anel de foco em todo o resto da pagina). O
   unico elemento focavel do cta-final e o proprio botao--principal, por
   isso o seletor aponta so a ele (nao ha aqui um :focus-visible
   generico da seccao a proteger). var(--branco) da 8,75:1 sobre o azul,
   a mesma conta ja usada para o titulo da seccao. Medido em
   testes/contraste_teste.php. */
.cta-final .botao--principal:focus-visible{
  outline-color:var(--branco);
}

.rodape{
  background:var(--escuro);
  color:var(--branco);
}
.rodape__caixa{
  max-width:var(--largura);
  margin:0 auto;
  /* Ronda de QA 5 (04/09): o padding-bottom sai daqui (era 0 nesta
     shorthand de 3 valores, TOPO/LADOS/BASE) e passa a viver so em
     .rodape__base, mais abaixo -- ver o comentario junto a essa regra
     para a razao (o par de paddings empilhados dava 140px de folga onde
     o Figma mede ~68px). */
  padding:var(--seccao-mobile) var(--goteira) 0;
  display:grid;
  grid-template-columns:1fr;
  gap:var(--esp-5);
}
/* Alinhado ao prototipo do Figma a 02/09: duas colunas, nao tres. A
   grelha antiga (2fr 1fr 1fr) era para a coluna do logotipo que saiu do
   rodape (ver o comentario em rodape.php). */
@media (min-width: 768px){
  .rodape__caixa{
    grid-template-columns:1fr 1fr;
    padding-top:var(--seccao);
    padding-bottom:0;
  }
}
.rodape__coluna{
  display:flex;
  flex-direction:column;
  gap:var(--esp-5);
}
/* Ronda de QA 5 (04/09): o lema de marca que faltava no rodape ("Onde a
   inovação encontra a excelência" no Figma, mantido em castelhano nesta
   pagina -- ver a razao completa no comentario de rodape.php). Mesma
   familia tipografica do h1/h3 (--titulo, peso 800): visualmente e o
   mesmo tipo de frase de assinatura, nao um rotulo pequeno como
   --rotulo. Tamanho medido no fig-full.png por altura de maiuscula sem
   acentos (a letra "E" de "ENCONTRA", segunda linha, sem diacritico):
   31px de figma / 1,3333 = 23,3px CSS de altura-maiuscula; --titulo-1 no
   maximo do clamp (45px) da uma altura de maiuscula de 44px medida
   (comentario junto a --titulo-2 no :root), racio 44/45 = 0,978 --
   aplicado ao alvo (23,3 / 0,978 = 23,8) fica pequeno de mais para um
   texto de assinatura a esta escala; conferido a serio no browser
   (Range.getClientRects) contra a largura disponivel da coluna (576px a
   1240 de largura de pagina) escolheu-se 32px, que fecha "DONDE LA
   INNOVACIÓN" (a linha mais comprida das duas em castelhano) numa unica
   linha com folga, sem se aproximar do tamanho do h1 da pagina (ver
   guardas/hierarquia_titulos_teste.js: o lema NAO e um titulo, fica bem
   abaixo de --titulo-2 em qualquer largura). line-height 1.05: a mesma
   entrelinha apertada que o Figma mostra entre as duas linhas (3px de
   figma, quase colado). margin-bottom fecha a conta do espaco medido
   ate ao rotulo EMAIL (~53px CSS no Figma): o gap do flex .rodape__coluna
   ja da --esp-5 (40px), falta a diferenca ate --titulo-espaco-baixo
   (54px no maximo do clamp, o numero medido mais proximo -- a mesma
   ficha que ja serve de "titulo para o que vem a seguir" no resto da
   pagina), sem inventar mais uma ficha nova so para este gap. */
.rodape__lema{
  margin:0 0 calc(var(--titulo-espaco-baixo) - var(--esp-5));
  font-family:var(--titulo);
  font-weight:800;
  font-size:var(--rodape-lema-letra);
  line-height:1.05;
  letter-spacing:var(--tracking-titulo);
  color:var(--branco);
}
.rodape__rotulo{
  /* Ronda de QA 5 (04/09): --esp-2 (12px) dava 12px entre o rotulo e o
     valor abaixo; o fig-full.png mede ~23px CSS nos dois casos (EMAIL->
     email, CONTACTOS->telefone). --esp-4 (20px) e o degrau mais proximo
     da escala existente. */
  margin:0 0 var(--esp-4);
  color:var(--cinza-claro);
  font-family:var(--rotulo);
  font-size:var(--letra-1);
  line-height:var(--entrelinha-rotulo);
  letter-spacing:var(--tracking-rotulo);
  font-weight:700;
  text-transform:uppercase;
}
.rodape__endereco{
  margin:0;
  padding:0;
  font-style:normal;
}
.rodape__grupo p:not(.rodape__rotulo){
  margin:0 0 var(--esp-1);
}
/* Ronda de QA 5 (04/09): o telefone e a morada sao dois PARAGRAFOS
   distintos no Figma (nao duas linhas do mesmo bloco) -- a nota da
   ANACOM que antes preenchia esse espaco saiu (rodape.php), mas o gap
   maior entre os dois paragrafos continua a existir no design: medido a
   serio no fig-full.png, ~36px CSS entre o fim do telefone e o inicio da
   morada, contra os 8px (--esp-1) que a regra partilhada acima da a
   qualquer paragrafo do grupo. --esp-5 (40px) e o degrau mais proximo.
   Fica num seletor mais especifico do que a regra partilhada (tres
   classes/pseudo contra duas), so para este par -- nao mexe no resto dos
   paragrafos do rodape. */
.rodape__grupo .rodape__endereco p:first-child{
  margin-bottom:var(--esp-5);
}
/* Achado 2: email e telefone sao as duas UNICAS formas de contacto que
   funcionam nesta pagina (o formulario ainda nao existe) e eram tambem os
   alvos de toque mais dificeis de acertar (21px de altura a 390, ver a
   ficha --alvo-toque no :root). inline-flex + align-items:center crescem
   a area clicavel para o minimo sem mudar o tamanho do texto; o alvo
   continua alinhado a esquerda (justify-content nao muda, so o eixo
   vertical cresce). */
.rodape__grupo a{
  display:inline-flex;
  align-items:center;
  min-height:var(--alvo-toque);
  color:var(--cinza-claro);
  text-decoration:none;
}
.rodape__grupo a:hover{
  color:var(--branco);
}
/* As tres ligacoes legais (09/09): herdam de ".rodape__grupo a" o
   min-height:44px do alvo de toque, mas empilhadas por <br> isso juntava
   tres caixas de 44px encostadas, 0px de folga entre alvos vizinhos
   (medir-espacos.js apanhou). display:flex (bloco, e nao inline-flex)
   tira a necessidade do <br> e devolve o box model normal, onde
   margin-bottom cria folga a serio entre alvos de toque consecutivos. */
.rodape__legal a{
  display:flex;
  margin-bottom:var(--esp-1);
}
.rodape__legal a:last-child{
  margin-bottom:0;
}
/* Ronda de QA 5 (04/09): as duas ligacoes legais pedidas pelo documento
   de QA (Política de Privacidad & Cookies, Términos & Condiciones) nao
   tem pagina nenhuma por tras -- nunca um <a> para uma rota que da 404
   (ver rotas.php e o comentario em rodape.php). Ficam como texto simples,
   na MESMA cor herdada (branco) que a morada usa (nunca um azul/sublinhado
   de link, para nao parecerem clicaveis e nao ser): so a nota mais
   pequena abaixo e que muda de tom, a dizer que ainda nao estao
   disponiveis. */
.rodape__legal-nota{
  margin:0 0 var(--esp-3);
  font-size:var(--letra-1);
  font-style:italic;
  color:var(--cinza-claro);
}
.rodape__selo{
  width:var(--rodape-selo-tamanho);
  height:var(--rodape-selo-tamanho);
}
/* Ronda de QA 5 (04/09): o "Desarrollado por Dash Digital" passa de uma
   faixa separada (div com border-top e padding proprios, ver o
   relatorio desta ronda) a um paragrafo INTEGRADO no proprio rodape,
   como o Figma mostra -- sem linha divisoria nenhuma. margin:0 porque o
   elemento passou de <div> a <p> em rodape.php (o <p> solto que la
   estava dentro do div): sem isto herdava a margem por omissao do
   browser (1em) por cima do padding que ja aqui esta.
   padding-top (--seccao-junta, 64px) e padding-bottom (--esp-4, 20px)
   medidos a serio no fig-full.png: ~68px do fim da morada ate ao inicio
   do texto do credito, ~22,5px do fim do texto ate ao fundo do rodape --
   os dois graus mais proximos ja existentes na escala, nenhum numero
   novo. Este padding-top e que agora faz sozinho o trabalho que antes
   estava a dobrar com .rodape__caixa (120px + 20px = 140px, quase o
   dobro do medido). */
.rodape__base{
  margin:0;
  padding:var(--seccao-junta-mobile) var(--goteira) var(--esp-2);
  text-align:left;
  font-size:var(--letra-1);
  color:var(--cinza-claro);
}
@media (min-width: 768px){
  .rodape__base{
    padding:var(--seccao-junta) var(--goteira) var(--esp-4);
  }
}

/* Etiqueta que abre cinco seccoes (beneficios, solucion, soluciones, bestech,
   faq): rotulo pequeno em caixa de contorno fino, encostado a esquerda, com
   um filete a estender-se dela ate a margem direita da seccao. O filete e o
   ::after do proprio .etiqueta, nunca um elemento vazio na marcacao. */
.etiqueta{
  display:flex;
  align-items:center;
  gap:var(--esp-3);
  margin-bottom:var(--esp-5);
}
/* Ronda de QA 1 (03/09): filete azul, nao cinzento -- medido no
   fig-full.png, a mesma cor do contorno da caixa (ver .etiqueta__texto). */
.etiqueta::after{
  content:'';
  flex:1 1 auto;
  height:1px;
  background:var(--acento);
}
/* Ronda de QA 1 (03/09): caixa mais pequena e mais leve, medida a serio
   no fig-full.png (ver --etiqueta-letra/--etiqueta-entrelinha/--esp-0 no
   :root para os numeros e o metodo). Duas cores diferentes de proposito:
   o contorno bate o pixel exato do Figma (--acento, 3,15:1 sobre
   --claro e 3,38:1 sobre --branco -- 3:1 chega para um elemento de
   interface, WCAG 1.4.11) mas esse mesmo --acento sobre --claro/--branco
   fica ABAIXO do minimo AA de 4,5:1 que testes/contraste_teste.php exige
   do proprio TEXTO da etiqueta (ve-se em "a etiqueta de beneficios/
   solucion/faq nao invertida tem contraste AA"). --azul (8,15:1 sobre
   --claro, 8,75:1 sobre --branco) fica so no texto; o contorno e o filete
   ficam no tom exato medido, --acento.
   Ronda de QA 2 do peso de letra (08/09): medido a serio no Figma real
   (get_design_context, no' "· beneficios"/"· solucion adaptada"/
   "· soluciones jetcam"/"06 · quem somos"/"· faq", as cinco instancias
   da mesma ficha) -- o texto da etiqueta e Telegraf:Regular, nao
   UltraBold nem Bold. Era var(--rotulo)/700 (a familia Lato, so declara
   700 a serio): pedia negrito a uma caixa que no protótipo e peso normal,
   o "titulos mais pesados do que no Figma" que o cliente apanhou. Troca
   para var(--texto) (a familia Varela, so declara 400): o peso agora vem
   do MATCH exato com a familia, nunca sintetizado (ver testes/
   design_teste.php, "nenhuma regra pede um peso que a familia usada nao
   declara"). Tamanho, entrelinha, tracking, cor e contorno ficam tal e
   qual -- so a familia/peso mudam. */
.etiqueta__texto{
  flex:0 0 auto;
  font-family:var(--texto);
  font-size:var(--etiqueta-letra);
  line-height:var(--etiqueta-entrelinha);
  letter-spacing:var(--tracking-rotulo);
  font-weight:400;
  text-transform:uppercase;
  color:var(--azul);
  border:1px solid var(--acento);
  padding:var(--esp-0) var(--esp-1);
  white-space:nowrap;
}
/* O pequeno ponto antes do texto ("· BENEFICIOS"): pseudo-elemento, nunca
   um caractere escrito em conteudo.php -- a copy continua so "BENEFICIOS",
   o ponto e desenho, nao texto (ver a nota da Tarefa/etiqueta.php sobre o
   filete nascer da propria caixa, mesma logica). */
.etiqueta__texto::before{
  content:'·';
  margin-right:var(--esp-0);
}

/* Sobre fundo escuro (as seccoes .soluciones e .bestech) a etiqueta
   inverte: contorno e texto passam a branco, para continuar legivel. */
.soluciones .etiqueta__texto,
.bestech .etiqueta__texto{
  color:var(--branco);
  border-color:var(--branco);
}
.soluciones .etiqueta::after,
.bestech .etiqueta::after{
  background:var(--branco);
}

/* Tarefa 5: os cinco cartoes de beneficios, em tres-mais-dois centrados.
   cartao.php emite a mesma marcacao em todas as seccoes; o aspeto vem so
   daqui, do contexto ".beneficios .cartao", nunca de uma variante nova no
   componente.

   A grelha e flex, nao grid: com cinco itens em filas de tres, a ultima
   fila fica com dois, e display:grid so centra FILAS INTEIRAS, nao o resto
   de uma fila incompleta. Com flex-wrap e justify-content:center, o espaco
   sobrante da ultima fila reparte-se nas pontas dos proprios cartoes, e o
   par fica centrado sozinho. Em ecra estreito, sem @media, cada cartao
   ocupa 100% da linha: um por linha, sem precisar de regra propria. */
/* Tarefa 2 (escala de tipografia e espaco): medido a 1440, os dois
   paragrafos de introducao iam aos 1192px do contentor (149 caracteres por
   linha). O h2 desta seccao abre centrado (regra global "main>section h2");
   margin:auto centra o bloco mais estreito por baixo dele, como
   .demo__paragrafo mais abaixo faz na sua propria seccao centrada.
   Ronda de QA 1 (03/09): no fig-full.png os dois paragrafos ficam
   CENTRADOS (nao a esquerda) numa coluna bem mais larga -- a linha mais
   comprida da introducao mede 1168px de figma, 876px CSS (1168/1,333).
   --largura-leitura (600px) e uma ficha partilhada com --cta-final e
   --demo, medida para OUTRO proposito (45-75 caracteres por linha); em
   vez de a alargar para todos (mexeria em duas seccoes fora desta ronda),
   fica uma ficha propria so para este bloco. --cinza-texto-claro
   substitui a cor herdada de --cinza-texto (demasiado escura): ver a
   ficha no :root para a conta de contraste. */
/* Ronda de QA 1 (03/09): o h2 nao tinha cor propria, herdava --cinza-texto
   do body (a mesma queixa do QA: "o titulo apresenta um tom mais
   cinzento"). --escuro e o preto/cinza-escuro do resto dos titulos da
   pagina (h1, cartoes). */
.beneficios__titulo{
  color:var(--escuro);
}
.beneficios__paragrafo{
  max-width:var(--beneficios-paragrafo-largura);
  margin:var(--esp-3) auto;
  text-align:center;
  color:var(--cinza-texto-claro);
}
/* Ronda de QA 1 (03/09): o gap entre cartoes media 18px de figma (13,5px
   CSS) no fig-full.png, bem menos que a goteira geral (24px) que a
   grelha reutilizava. --esp-3 (16px) e o degrau existente mais proximo,
   preferido a inventar uma ficha nova so para este valor. */
.beneficios__grelha{
  display:flex;
  flex-wrap:wrap;
  justify-content:center;
  gap:var(--esp-3);
}
/* Ronda de QA 1 (03/09): o cartao media 320×90px CSS no fig-full.png (o
   atual passava dos 110px de altura, mais de metade a mais). Sem
   contorno cinzento (a duvida do QA: "impercetivel" ou ausente -- ausente
   e mais simples e mede zero) e com --sombra-cartao no lugar (ver a
   ficha no :root); padding desce de --esp-4 (20px) para --esp-3 (16px),
   medido a ~15px nos quatro lados do cartao (topo e esquerda batem quase
   ao pixel).
   QA2, ronda 4 (09/09): o cartao nao tinha ESTADO nenhum -- passar o
   rato nao fazia diferenca visual. border:1px solid transparent entra
   aqui, no estado normal, so para RESERVAR o espaco que o :hover vai
   colorir (o mesmo padrao ja usado em .botao, border:2px solid
   transparent mais abaixo na folha): sem isto, o cartao ficaria 2px mais
   estreito ao passar o rato, um empurrao que o documento proibe
   explicitamente ("sem mover"). transition so em border-color, a unica
   propriedade que muda. */
.beneficios .cartao{
  flex:1 1 100%;
  background:var(--branco);
  border:1px solid transparent;
  border-radius:var(--raio-cartao);
  box-shadow:var(--sombra-cartao);
  padding:var(--esp-3);
  transition:border-color .2s ease;
}
/* QA2, ronda 4: cartao "so informativo" (sem link nenhum la dentro), mas
   o documento pede o efeito de destaque para toda a grelha de beneficios
   como EXEMPLO concreto -- e um efeito de VIDA VISUAL, nao uma promessa
   de clique (nao ha cursor:pointer nem nada que sugira acao). --acento e
   a mesma ficha ja usada no anel de :focus-visible global e nos acentos
   decorativos da pagina (ver :root); 3,38:1 contra --branco, acima do
   minimo de 3:1 para elementos graficos (WCAG 1.4.11, testes/
   cartoes_estado_teste.php). */
.beneficios .cartao:hover{
  border-color:var(--acento);
}
@media (min-width: 768px){
  .beneficios .cartao{
    flex:0 1 calc((100% - 2 * var(--goteira)) / 3);
  }
}
/* Segunda passagem de alinhamento com o Figma (02/09): o icone de cada
   cartao, acima do titulo e alinhado a esquerda (ver a ficha
   --icone-beneficio no :root para a justificacao do tamanho). display:block
   tira o <span> do fluxo inline (cartao.php embute o SVG dentro de um
   <span class="cartao__icone">); sem isto ficava colado ao h3 na mesma
   linha, em vez de empilhado por cima. currentColor (ja vem assim de cada
   SVG, ver app/icones/) faz o desenho herdar a cor daqui.
   Ronda de QA 1 (03/09): os cinco SVG de app/icones/ chegaram com
   fill="#15141C" (--escuro) antes de serem trocados para currentColor;
   o fig-full.png confirma outra vez essa cor a olho nu (os icones sao
   escuros, nao azuis) e ao medir um pixel do proprio desenho no
   prototipo (21,20,28 -- --escuro ao pixel exato). --azul era a cor
   herdada errada, nunca a intencao do desenho. */
.beneficios .cartao__icone{
  display:block;
  width:var(--icone-beneficio);
  height:auto;
  margin-bottom:var(--esp-3);
  color:var(--escuro);
}
/* O titulo fica em maiusculas na ficha --rotulo, como o resto do desenho
   (o icone acima, ver .beneficios .cartao__icone, e que agora carrega o
   significado visual que antes so o rotulo tinha).
   Ronda de QA 1 (03/09): line-height nunca tinha sido definido aqui, por
   isso o h3 herdava os 28px (--linha) do body -- exagerado para um
   rotulo de 14px, e uma causa direta do cartao ficar mais alto do que
   devia. --entrelinha-rotulo (18px) e a mesma ficha ja usada na propria
   etiqueta de secao, ao mesmo tamanho de letra (--letra-1).
   Ronda de QA 2 do peso de letra (08/09): medido a serio no Figma real
   (get_design_context no cartao "Menos desperdicio de chapa" e nos
   outros quatro da mesma seccao) -- o titulo do cartao de beneficios E
   Telegraf:UltraBold, o oposto do que --rotulo (Lato, so declara 700)
   dava: o elemento ficava mais LEVE do que o prototipo pede, nao mais
   pesado (o cartao de beneficios nao entra no "titulos mais pesados"
   apanhado pelo cliente -- esse era outros papeis, ver etiqueta__texto e
   .soluciones/.campo__rotulo). Troca para var(--titulo) (Telegraf/PP
   Telegraf UltraBold, so declara 800): o mesmo <h3> ja usa esta familia
   por omissao (regra "h1,h3{font-family:var(--titulo)}" mais acima), por
   isso esta regra deixa agora de contrariar essa base -- fica so
   explicita, para nao depender da ordem das regras na folha. Tamanho,
   entrelinha, tracking e cor ficam tal e qual. */
.beneficios .cartao__titulo{
  font-family:var(--titulo);
  font-size:var(--letra-1);
  line-height:var(--entrelinha-rotulo);
  letter-spacing:var(--tracking-rotulo);
  font-weight:800;
  text-transform:uppercase;
  color:var(--escuro);
}
/* beneficios.php passa 'texto' vazio a todos os cartoes (a copy so tem
   titulo); o <p> fica vazio no HTML e nao deve ocupar espaco visual. */
.beneficios .cartao__texto:empty{
  display:none;
}

/* Tarefa 6: os quatro cartoes de solucoes, dois por dois sobre o fundo
   azul. Ao contrario dos de beneficios, esta grelha e sempre completa (um
   numero par de itens, sem fila incompleta para centrar), por isso e
   grid a serio: uma coluna em ecra estreito, duas a partir do breakpoint
   de tablet. */
/* Ronda de QA 2 (03/09): a grelha ganha max-width proprio (ficha medida no
   :root) e fica centrada -- deixa de ocupar a largura toda da seccao. O
   gap tambem deixa de ser uma so ficha (--goteira, 24px nos dois eixos):
   medido no fig-full.png, o intervalo HORIZONTAL entre as duas colunas
   (982-938, 1548-1938 iguais) da 44px de figma, 33px CSS, muito perto de
   --esp-6 (32px) ja existente; o intervalo VERTICAL entre as duas filas
   pediu-se maior do que o horizontal (o proprio QA marca essa diferenca),
   por isso fica em --esp-5 (40px) em vez de repetir a mesma ficha nos dois
   eixos. */
.soluciones__grelha{
  display:grid;
  grid-template-columns:1fr;
  max-width:var(--soluciones-grelha-largura);
  margin:0 auto;
  row-gap:var(--esp-5);
  column-gap:var(--esp-6);
}
@media (min-width: 768px){
  .soluciones__grelha{
    grid-template-columns:repeat(2, 1fr);
  }
}
/* Ronda de QA 2 (03/09): o cartao passa a CONTAINER BRANCO com padding a
   volta da imagem (--esp-3, medido a seguir), em vez da imagem encostada
   as quatro extremidades. overflow:hidden sai -- deixou de fazer falta
   sem a imagem a tocar nos cantos arredondados do cartao, e a propria
   imagem ganha o seu border-radius (ver .soluciones .cartao__imagem
   abaixo). Medido no fig-full.png (cartao "JETCAM EXPERT", o unico com
   fundo de imagem solido o suficiente para medir ao pixel): do rebordo
   branco do cartao ate a imagem la dentro sao 20px de figma nos lados e
   19px no topo (392-372 e 2973-2954), 15px CSS nos tres -- --esp-3 (16px)
   e o degrau mais proximo ja existente. */
/* QA2, ronda 4 (09/09): border transparente no normal, so para reservar
   a largura que o :hover colore -- ver o comentario completo junto a
   .beneficios .cartao, primeiro sitio da folha a usar este padrao nesta
   ronda. */
.soluciones .cartao{
  background:var(--branco);
  color:var(--cinza-texto);
  border:1px solid transparent;
  border-radius:var(--raio-cartao);
  padding:var(--esp-3);
  transition:border-color .2s ease;
}
/* QA2, ronda 4: cartao so informativo (sem link), mesmo criterio de
   .beneficios .cartao:hover -- efeito de vida visual, --acento, 3,38:1
   contra --branco. */
.soluciones .cartao:hover{
  border-color:var(--acento);
}
/* aspect-ratio 16/9: a proporcao nativa das quatro fotografias (1208x680
   em conteudo.php, 1208/680 = 1,776, praticamente 16/9 = 1,778) e tambem a
   proporcao medida no fig-full.png (526x296 de figma no primeiro cartao,
   mesma conta). object-fit:cover mantem o enquadramento exato mesmo que
   a largura do cartao mude num breakpoint diferente, sem deformar a
   fotografia. border-radius proprio: a imagem ja nao encosta aos cantos
   do cartao (o padding acima recuou-a), por isso overflow:hidden no
   cartao ja nao a arredonda -- precisa do seu proprio raio, o mesmo dos
   cantos do cartao. height:auto e OBRIGATORIO aqui, apesar de parecer
   redundante com aspect-ratio: testado a serio no browser (nao a olho),
   um <img> com os atributos HTML width/height (cartao.php imprime-os
   sempre, para reservar o espaco antes da imagem carregar) ignora o
   aspect-ratio do CSS sem esta linha e usa o atributo height tal e qual
   (680px, a foto inteira, nao os ~220px esperados a esta largura de
   cartao) -- um cartao três vezes mais alto do que devia. Com height:auto
   explicito o aspect-ratio volta a mandar, confirmado no mesmo teste. */
.soluciones .cartao__imagem{
  display:block;
  width:100%;
  height:auto;
  aspect-ratio:16 / 9;
  object-fit:cover;
  border-radius:var(--raio-cartao);
}
/* Ronda de QA 2 (03/09): o titulo do cartao trocou a familia --titulo
   (PP Telegraf UltraBold, so declara o peso 800 -- o browser tinha de
   sintetizar negrito para o peso 700 que um h3 pede por omissao, dai o
   "peso excessivo" que o QA apanhou) pela mesma receita ja usada nos
   titulos de cartao de beneficios e demo: --rotulo (Lato), --letra-1
   (14px, medido no fig-full.png: a caixa "JETCAM EXPERT" tem ~15px de
   figma de altura-maiuscula, ~11px CSS, compativel com --letra-1 a este
   racio de fonte), --entrelinha-rotulo e --tracking-rotulo, a mesma ficha
   que a etiqueta de seccao ja usa. --escuro fica explicito (antes herdava
   --cinza-texto do proprio .cartao, mais claro do que o titulo mede no
   protótipo). padding vira margin: o alinhamento lateral com a imagem
   agora vem do padding UNICO do cartao (acima), nao de um padding proprio
   do titulo -- e o "mesmo alinhamento lateral para imagem, titulo e
   descricao" que o QA pede. */
/* Ronda de QA 2 do peso de letra (08/09): medido a serio no Figma real
   (get_design_context nos quatro cartoes, "JETCAM Expert"/"JETCAM Orders
   Controller"/"CrossTrack"/"Planificación 3D") -- ao contrario do cartao
   de beneficios (icone+titulo so, ver .beneficios .cartao__titulo), o
   titulo do cartao de solucoes (imagem+titulo+descricao) E
   Telegraf:Regular no protótipo, nao UltraBold nem Bold. --rotulo (Lato,
   so declara 700) pedia negrito onde o Figma mostra peso normal: o
   "cartões mais pesados do que no Figma" que o cliente apanhou. Troca
   para var(--texto) (Varela, so declara 400): o mesmo peso do proprio
   .soluciones .cartao__texto logo a seguir, sem inventar ficha nova.
   Tamanho, entrelinha, tracking e cor ficam tal e qual. */
.soluciones .cartao__titulo{
  font-family:var(--texto);
  font-size:var(--letra-1);
  line-height:var(--entrelinha-rotulo);
  letter-spacing:var(--tracking-rotulo);
  font-weight:400;
  text-transform:uppercase;
  color:var(--escuro);
  margin:var(--esp-3) 0 0;
}
/* Ronda de QA 2 (03/09): cinzento mais claro (--cinza-texto-claro, a
   mesma ficha ja usada nos paragrafos de beneficios/cta-final/demo) no
   lugar do --cinza-texto herdado do .cartao, mais escuro do que a
   descricao mede no protótipo. font-size ja estava em --letra-1 (14px),
   sem alteracao. padding vira margin, mesma razao do titulo acima. */
.soluciones .cartao__texto{
  font-size:var(--letra-1);
  color:var(--cinza-texto-claro);
  margin:var(--esp-1) 0 0;
}

/* Tarefa carrosseis-moveis (08/09): no telemovel os quatro cartoes deixam
   de empilhar (a grelha de 1 coluna que a regra base ja dava, mais acima)
   e passam a carrossel horizontal por scroll NATIVO, sem JavaScript nenhum
   -- a pagina continua a funcionar por inteiro com o JavaScript desligado.
   O proprio Figma mobile ja desenha esta seccao assim (ver a ficha
   --carrossel-cartao-largura no :root para a medida exata e a fonte).
   display:flex troca a grelha (grid) por uma fila so; overflow-x:auto da o
   scroll nativo; scroll-snap-type:x mandatory encaixa cada cartao ao ecra
   ao soltar o dedo. gap proprio (--esp-3, mais perto do medido no Figma do
   que o --esp-6/32px que a regra base usa para o espaco ENTRE FILAS do
   grid de desktop, que aqui deixa de fazer sentido). scrollbar-width:none
   + a pseudo-classe WebKit a seguir tornam a barra de deslize discreta,
   NAO desligam o scroll: continua a deslizar por dedo ou por teclado.
   Fora deste @media (768px ou mais) a grelha original nao muda nada. */
@media (max-width: 767px){
  .soluciones__grelha{
    display:flex;
    flex-wrap:nowrap;
    overflow-x:auto;
    scroll-snap-type:x mandatory;
    -webkit-overflow-scrolling:touch;
    gap:var(--esp-3);
    scrollbar-width:none;
  }
  .soluciones__grelha::-webkit-scrollbar{
    display:none;
  }
  /* flex:0 0 (nao encolhe, nao cresce, base fixa) e o oposto do min-width:0
     que outras grelhas desta pagina usam para EVITAR overflow (ver
     .bestech__imagem mais abaixo): aqui o objetivo E o cartao nao encolher
     para caber, para o seguinte ficar sempre a espreitar. */
  .soluciones .cartao{
    flex:0 0 var(--carrossel-cartao-largura);
    scroll-snap-align:start;
  }
}

/* Ronda de correcao das seccoes sem dono: a Tarefa 7 desenhou so a grelha
   dos cartoes (o bloco a seguir), e o resto da seccao ficou por conta da
   propria sorte. O h2 ja saia centrado (regra global "main>section h2"),
   os cartoes ja saiam centrados (".demo .cartao" abaixo), mas os dois
   paragrafos de introducao saiam a esquerda, largura do contentor
   inteiro, e o CTA secundario ficava encostado a essa mesma esquerda: a
   mesma seccao com tres alinhamentos diferentes. text-align:center na
   propria .demo resolve o CTA (um <a> inline-flex segue o alinhamento do
   pai) sem tocar em nada da grelha, que e flex/justify-content e nao
   depende de text-align. */
/* Ronda de QA 2 (03/09): padding-top e padding-bottom proprios, medidos no
   fig-full.png a partir da mudanca de fundo (.demo::before, --claro):
   a seccao azul de soluciones acaba e a cinzenta da demo comeca em
   y=4042; o topo do titulo "Solicita..." fica em y=4117 (75px de figma,
   56px CSS ate ao topo do titulo -- por isso o padding-top fica em
   --seccao-junta, 64px, o degrau existente mais proximo, o mesmo criterio
   ja usado para hero->beneficios na ronda anterior). Em baixo, o botao
   "SOLICITAR DEMOSTRACIÓN" acaba em y=4671 e a seccao (fundo escuro do
   bestech a seguir) comeca em y=4739: 68px de figma, 51px CSS -- mais
   perto de --esp-5 (40px) do que de --seccao-junta (64px), por isso
   --esp-5 fica no padding-bottom. Os dois substituem o --seccao generico
   (120px) que a regra global "main>section" dava por omissao, o "demasiado
   espaco em branco antes do titulo" que o QA apanhou. */
.demo{
  text-align:center;
  padding-top:var(--seccao-junta-mobile);
  padding-bottom:var(--esp-5);
}
@media (min-width: 768px){
  .demo{
    padding-top:var(--seccao-junta);
  }
}
/* Ronda de QA 2 (03/09): o h2 nao tinha cor propria, herdava --cinza-texto
   do body -- a mesma queixa do QA ja corrigida em beneficios/solucion
   nesta ronda e na anterior ("cor demasiado cinzenta"). --escuro e o
   preto/cinza-escuro do resto dos titulos da pagina. */
.demo__titulo{
  color:var(--escuro);
}
/* Ronda de QA 2 (03/09): --demo-paragrafo-largura (ficha no :root) no
   lugar de --largura-leitura -- essa ficha (600px) obrigava o primeiro
   paragrafo a quebrar em duas linhas, o que o Figma nao mostra (so o
   segundo quebra). --cinza-texto-claro (a mesma ficha ja usada em
   beneficios/cta-final) no lugar do --cinza-texto herdado do body, mais
   escuro do que o Figma mostra para este texto. */
.demo__paragrafo{
  max-width:var(--demo-paragrafo-largura);
  margin:var(--esp-3) auto;
  color:var(--cinza-texto-claro);
}

/* Ronda de QA 2 (03/09): o conjunto dos quatro cartoes deixa de tentar
   chegar aos 1240 inteiros da seccao (a margin negativa que reclamava a
   goteira lateral, comentario antigo) e passa a um max-width proprio,
   bem mais estreito (--demo-grelha-largura, ficha no :root, medida no
   fig-full.png) e centrado -- exatamente o oposto do que a regra antiga
   fazia. margin-top proprio tambem: entre o ultimo paragrafo e a grelha
   o Figma mede 70px de figma (fim do texto em y=4298, topo dos cartoes em
   y=4368), 52px CSS -- calc(--esp-5 + --esp-3) fecha em 56px, 1px do
   medido, mais perto do que qualquer ficha unica existente. margin-bottom
   sobe pela mesma razao (o QA: "os cards começam demasiado próximos do
   texto" e "o botão está demasiado próximo dos cards" sao a mesma queixa
   dos dois lados desta grelha): fim dos cartoes em y=4523, topo do botao
   em y=4599, 76px de figma, 57px CSS -- a mesma conta calc(--esp-5 +
   --esp-3) fecha em 56px, 1px do medido outra vez. */
.demo__grelha{
  display:flex;
  flex-wrap:wrap;
  justify-content:center;
  max-width:var(--demo-grelha-largura);
  margin:calc(var(--esp-5) + var(--esp-3)) auto calc(var(--esp-5) + var(--esp-3));
  gap:var(--intervalo-demo);
}
/* Ronda de QA 2 (03/09): sombra subtil (--sombra-cartao, a mesma ficha ja
   usada nos cartoes de beneficios) no lugar do contorno cinzento
   (--borda) que o QA apanhou como "aspeto mais pesado". border-radius
   ja estava em --raio-cartao (4px), sem alteracao -- o QA confirma
   "cantos mais discretos", ja e o que a ficha da. */
/* QA2, ronda 4 (09/09): border transparente no normal, mesmo padrao do
   resto da folha nesta ronda (ver .beneficios .cartao para a explicacao
   completa). */
.demo .cartao{
  flex:1 1 100%;
  background:var(--branco);
  border:1px solid transparent;
  border-radius:var(--raio-cartao);
  box-shadow:var(--sombra-cartao);
  padding:var(--esp-4);
  text-align:center;
  transition:border-color .2s ease;
}
/* QA2, ronda 4: cartao so informativo (sem link), mesmo criterio das
   outras tres grelhas -- efeito de vida visual, --acento. */
.demo .cartao:hover{
  border-color:var(--acento);
}
@media (min-width: 768px){
  .demo .cartao{
    flex:0 1 calc((100% - var(--intervalo-demo)) / 2);
  }
}
@media (min-width: 1024px){
  .demo .cartao{
    flex:0 1 calc((100% - 3 * var(--intervalo-demo)) / 4);
  }
}
/* Ao contrario de beneficios e solucoes (rotulo/icone a esquerda), na demo
   o rotulo e o espaco do icone ficam ambos centrados: o text-align:center
   do proprio .cartao acima ja centra tudo o que e inline/texto la dentro. */
/* Ronda de QA 2 do peso de letra (08/09): medido a serio no Figma real
   (get_design_context nos quatro cartoes, "Demostración personalizada"/
   "Sin compromiso"/"Adaptada a tus máquinas y procesos"/"Acompañamiento
   de especialistas") -- o mesmo padrao do cartao de beneficios (icone+
   titulo so): Telegraf:UltraBold. Era var(--rotulo)/700 (Lato, mais
   leve do que o protótipo pede aqui); troca para var(--titulo) (PP
   Telegraf UltraBold, so declara 800), o mesmo <h3> que ja usa esta
   familia por omissao. Tamanho, tracking e cor ficam tal e qual. */
.demo .cartao__titulo{
  font-family:var(--titulo);
  font-size:var(--letra-1);
  letter-spacing:var(--tracking-rotulo);
  font-weight:800;
  text-transform:uppercase;
  color:var(--escuro);
  text-align:center;
}
/* demo.php passa 'texto' vazio a todos os cartoes (a copy so tem titulo);
   o <p> fica vazio no HTML e nao deve ocupar espaco visual. */
.demo .cartao__texto:empty{
  display:none;
}

/* Tarefa icones-demo: o icone de cada cartao da demo, acima do rotulo.
   Ao contrario de beneficios (icone a esquerda), aqui fica CENTRADO: o
   ".demo .cartao" ja tem text-align:center, mas isso so alinha TEXTO
   inline; um <span> a que se da largura propria (--icone-demo) e um
   elemento de bloco, e um bloco so centra a si mesmo com margin lateral
   automatica. display:block continua necessario pela mesma razao que em
   beneficios: sem ele o <span> ficava colado ao h3 na mesma linha, em vez
   de empilhado por cima. Esta regra serve os TRES icones SVG (embutidos
   por cartao.php, ver .demo .cartao__icone svg mais abaixo nao existe:
   currentColor ja vem do proprio ficheiro) e tambem o quarto, a mascara,
   que herda esta largura e so acrescenta o mask-image nas regras
   seguintes. */
/* Ronda de QA 2 (03/09): --escuro no lugar de --azul -- o mesmo engano ja
   corrigido nos icones de beneficios na ronda anterior (a cor herdada
   nunca foi a intencao do desenho). O fig-full.png confirma outra vez a
   olho nu: os quatro icones da demo (aperto de mao, ecra+utilizador,
   robo+caixa, auscultador+utilizador) sao escuros, nao azuis. */
.demo .cartao__icone{
  display:block;
  width:var(--icone-demo);
  height:auto;
  margin:0 auto var(--esp-3);
  color:var(--escuro);
}

/* Tarefa carrosseis-moveis (08/09): no telemovel os quatro cartoes deixam
   de empilhar (a regra base ".demo .cartao{flex:1 1 100%}" mais acima) e
   passam a carrossel horizontal por scroll nativo, sem JavaScript nenhum.
   Confirmado no Figma (no 83:1678/83:1679, "Solicita una demostración
   gratuita"): o proprio prototipo mobile ja desenha isto como carrossel
   (ver --carrossel-cartao-largura no :root para a medida e a fonte, a
   MESMA proporcao do carrossel de soluciones). flex-wrap:nowrap poe os
   quatro cartoes numa fila so; overflow-x:auto da o scroll nativo;
   scroll-snap-type:x mandatory encaixa cada cartao ao ecra.
   justify-content:flex-start substitui o "center" da regra base: um
   flex container CENTRADO com conteudo mais largo do que ele (o caso aqui,
   de proposito) esconde o inicio do primeiro cartao atras da borda
   esquerda em vez de o mostrar logo ao abrir a seccao -- so alinhar ao
   INICIO evita essa armadilha. O gap (--intervalo-demo, ja definido na
   regra base) fica tal e qual, e bate perto do medido no Figma. Fora
   deste @media (768px ou mais) a fila de cartoes nao muda nada. */
@media (max-width: 767px){
  .demo__grelha{
    flex-wrap:nowrap;
    justify-content:flex-start;
    overflow-x:auto;
    scroll-snap-type:x mandatory;
    -webkit-overflow-scrolling:touch;
    scrollbar-width:none;
  }
  .demo__grelha::-webkit-scrollbar{
    display:none;
  }
  .demo .cartao{
    flex:0 0 var(--carrossel-cartao-largura);
    scroll-snap-align:start;
  }
}

/* Ronda de QA 2 (03/09): so o CTA secundario desta seccao fica mais largo
   -- medido no fig-full.png, o botao "SOLICITAR DEMOSTRACIÓN" fecha em
   435px de figma, 326px CSS (326,3), contra os ~283px que o padding
   horizontal partilhado por TODOS os botoes do site (--goteira, 24px de
   cada lado, ver .botao no :root/regras gerais) dava aqui. O ponto 10 do
   documento de QA pede fundo azul solido para este botao; essa parte fica
   DELIBERADAMENTE REJEITADA (decisao ja tomada e comunicada ao cliente: a
   especificacao do projeto manda este CTA sempre secundario, contorno,
   porque ha cinco apelos a acao para o mesmo destino na pagina e tres
   estilos diferentes diluem a conversao -- ver o relatorio desta ronda).
   So a MEDIDA muda, nunca a cor: continua .botao--secundario, fundo
   transparente, contorno e texto azuis. A regra fica presa a .demo (nao
   em .botao--secundario global) para nao alargar nenhum outro botao
   secundario do site, como o do cabecalho. */
.demo .botao--secundario{
  padding-left:calc(var(--goteira) + var(--esp-4));
  padding-right:calc(var(--goteira) + var(--esp-4));
}

/* A EXCECAO: o icone de "Sin compromiso" (aperto de mao) e, desde a Tarefa
   icones-bestech, tambem o do "Implantación..." (auscultador) so existem
   em raster, nao em vetor. O Figma so entrega vinte recursos por pedido e
   os dois ficaram de fora do corte; foram tirados da propria imagem do
   prototipo, por isso sao PNG minusculos (378 e 344 bytes) que sao so um
   canal alfa, sem cor nenhuma la dentro — nao fotografias a cores.
   Por isso NAO sao <img> (cartao.php nem gera um: ver 'icone_mascara' no
   componente, e bestech.php, que duplica a mesma logica para a segunda):
   sao usados como MASCARA CSS. mask-image recorta a forma do PNG e
   background-color:currentColor pinta essa forma com a cor do texto a
   volta, exatamente como o fill="currentColor" faz nos SVG. Isto mantem a
   cor a vir sempre do CSS, igual aos outros icones da pagina, e no dia em
   que o vetor chegar troca-se so a chave 'icone_mascara' por 'icone' em
   conteudo.php, sem mexer em mais nada aqui.
   -webkit-mask-* e o par que ainda faz falta nalguns browsers baseados em
   WebKit sem a propriedade mask-* sem prefixo.
   aspect-ratio NAO fica aqui: os dois icones raster tem proporcoes
   diferentes (45x27 o aperto, 28x28 o auscultador), por isso cada um leva
   a sua propria regra, mais abaixo. */
.cartao__icone--mascara{
  background-color:currentColor;
  -webkit-mask-repeat:no-repeat;
  mask-repeat:no-repeat;
  -webkit-mask-position:center;
  mask-position:center;
  -webkit-mask-size:contain;
  mask-size:contain;
}
.cartao__icone--aperto{
  aspect-ratio:45 / 27; /* proporcao nativa do icone-aperto.png */
  -webkit-mask-image:url('/ativos/imagens/icone-aperto.png');
  mask-image:url('/ativos/imagens/icone-aperto.png');
}
.cartao__icone--auscultador{
  aspect-ratio:1 / 1; /* proporcao nativa do icone-auscultador.png, 28x28 */
  -webkit-mask-image:url('/ativos/imagens/icone-auscultador.png');
  mask-image:url('/ativos/imagens/icone-auscultador.png');
}

/* Ronda de QA 3 (03/09): o titulo estava a herdar --titulo-espaco-baixo
   da regra global "main>section h2" (54px no maximo do clamp), mas o
   fig-full.png mede so 32px de figma / 24px CSS entre o fim do "?" e o
   topo do primeiro paragrafo -- a propria secao pediu explicitamente
   "reduzir o espaco vertical entre o identificador, o titulo e os
   textos seguintes". Classe mais especifica do que o seletor de
   elementos global, ganha sempre. --esp-4 (20px) fica a 4px do medido,
   o degrau existente mais proximo (o paragrafo por baixo mantem o seu
   proprio margin-top de --esp-3/16px; os dois colapsam no maior, 20). */
.bestech__titulo{
  margin-bottom:var(--esp-4);
}
/* Ronda de QA 3 (03/09): --bestech-paragrafo-largura (ficha nova) no
   lugar de --largura-leitura (essa ficha e de OUTRAS seccoes, calibrada
   a 45-75 caracteres/linha a --corpo, nao ao que o Figma mostra aqui:
   os dois paragrafos do bestech fecham em DUAS linhas cada, e 600px
   forcava mais quebras do que isso). text-align:center: o QA apanhou os
   paragrafos alinhados a esquerda dentro de um bloco so centrado (o
   bloco ja usava margin:auto, mas nunca o texto la dentro). */
.bestech__paragrafo{
  max-width:var(--bestech-paragrafo-largura);
  margin:var(--esp-3) auto;
  text-align:center;
}

/* Tarefa 8: o bestech, imagem a esquerda e os quatro cartoes de prova em
   dois por dois a direita, sobre o fundo escuro (".bestech{color:var(--branco)}",
   ja definido na Tarefa 4). Em ecra estreito a imagem fica em cima (e a
   primeira no HTML) e os cartoes em baixo, numa coluna so.
   Ronda de QA 3 (03/09): duas correcoes de fundo, medidas no fig-full.png.
   Primeiro, o conjunto imagem+grelha nao e a largura toda da seccao (1192
   px): fecha em 895px CSS, por isso --bestech-conteudo-largura (900px,
   ficha nova) com margin:auto -- sem isto, alargar a percentagem da
   imagem (ver --bestech-imagem-proporcao) so a fazia crescer a mais,
   nunca aproximava do medido. Segundo, o intervalo entre imagem e
   grelha (--esp-5, 40px) media na realidade 30px CSS: --bestech-
   conteudo-intervalo (ficha nova) entra so no media query de baixo, a
   1 coluna empilhada em ecra estreito fica com o espacamento vertical
   antigo (--esp-5), que nunca foi medido para essa disposicao e nao
   faz parte desta ronda. */
.bestech__conteudo{
  display:flex;
  flex-direction:column;
  gap:var(--esp-5);
  max-width:var(--bestech-conteudo-largura);
  /* margin-top faz o espaco entre o ultimo paragrafo e a imagem/grelha:
     medido no fig-full.png, 94px de figma / 70,5px CSS. O paragrafo por
     cima ja tem margin-bottom (--esp-3, 16px) que colapsa com este (o
     MAIOR dos dois vence, nunca a soma) -- por isso o valor tem de ir
     aqui inteiro, nao dividido pelos dois lados. calc(--esp-6 + --esp-5)
     fecha em 72px, 1,5px do medido, mais perto do que qualquer ficha
     unica existente. */
  margin:calc(var(--esp-6) + var(--esp-5)) auto 0;
}
@media (min-width: 768px){
  .bestech__conteudo{
    flex-direction:row;
    align-items:flex-start;
    gap:var(--bestech-conteudo-intervalo);
  }
}
/* Ronda de QA 3 (03/09): a imagem estava a escalar por height:auto, ao
   proprio racio do ficheiro (992x674, 1,47:1) -- mas o Figma recorta a
   foto a um racio mais quadrado (548x425 de figma medidos no fig-full.png,
   1,29:1), nao o racio nativo do ficheiro. aspect-ratio mais object-fit:
   cover reproduz esse enquadramento sem distorcer a foto (a mesma tecnica
   ja usada em .cartao__icone--aperto/--auscultador, so que aqui e uma
   fotografia, nao uma mascara). */
.bestech__imagem{
  display:block;
  width:100%;
  /* height:auto tem de ficar explicito, mesmo com aspect-ratio a seguir:
     provado a serio no browser (Ronda de QA 3, 03/09) que sem ele o
     <img>, como flex item de ".bestech__conteudo" (flex-direction:row),
     ignora o aspect-ratio e usa o height="674" do proprio atributo HTML
     (Tarefa 2, para o CLS) como altura fixa -- a imagem saia a 674px em
     vez dos ~321px do racio medido. Com height:auto o aspect-ratio volta
     a mandar, como devia desde o principio. */
  height:auto;
  /* 548/425 (o racio medido no fig-full.png) dava 321px de altura aos
     414px de largura desta implementacao -- mas a grelha ao lado (com o
     texto REAL, que nao quebra exatamente como no Figma) mede 400,5px,
     nao os ~390px medidos no protótipo. Reajustado para bater a grelha
     REAL desta implementacao (o pedido explicito do QA: "fazer com que a
     altura da imagem fique aproximadamente alinhada com a altura total
     das duas filas de blocos"), medido a serio no browser depois das
     restantes correcoes desta seccao, nao mantido preso ao racio exato
     do recorte do Figma. 207/200 (414/400 simplificado) fecha a 400,6px. */
  aspect-ratio:207 / 200;
  object-fit:cover;
  border-radius:var(--raio-cartao);
}
@media (min-width: 768px){
  /* min-width:0 tira o minimo automatico dos elementos substituidos (a
     imagem, pelo width/height do proprio ficheiro) que impede um item
     flex de encolher abaixo do seu tamanho intrinseco: sem isto a imagem
     ficava com 500px fixos e empurrava a grelha para fora da seccao. */
  .bestech__imagem{
    flex:0 1 var(--bestech-imagem-proporcao);
    min-width:0;
  }
}
/* Ronda de QA 3 (03/09): gap unico (--goteira, 24px) media na realidade
   17px CSS na horizontal e so 10px na vertical no fig-full.png -- duas
   medidas bem diferentes que uma so ficha nao conseguia dar. column-gap
   fica em --esp-3 (16px, 1px do medido) e row-gap em --esp-1 (8px, 1,75px
   do medido, mais perto do que --esp-2/12px). Em ecra estreito (grelha a
   1 coluna) so o "gap" base conta, como row-gap entre os quatro cartoes
   empilhados -- fica em --esp-3, um meio-termo razoavel para essa
   disposicao que o Figma (so desktop) nao mostra. */
.bestech__grelha{
  display:grid;
  grid-template-columns:1fr;
  gap:var(--esp-3);
  flex:1 1 auto;
}
@media (min-width: 768px){
  .bestech__grelha{
    grid-template-columns:repeat(2, 1fr);
    column-gap:var(--esp-3);
    row-gap:var(--esp-1);
    flex:1 1 0%;
  }
}
/* Contorno claro (--borda, a mesma ficha dos outros cartoes) para se ver
   sobre o fundo escuro; o texto NAO fixa cor propria, herda o branco de
   .bestech (ja provado em contraste_teste.php) em vez de repetir a ficha,
   para nunca poder divergir dela.
   Ronda de QA 3 (03/09): padding desce de --esp-4 (20px) para --esp-3
   (16px) -- medido no fig-full.png (topo do cartao ao topo do circulo do
   icone), 23px de figma / 17,3px CSS, mais perto de --esp-3 (1,3px de
   diferenca) do que de --esp-4 (2,7px). */
.bestech .cartao{
  border:1px solid var(--borda);
  border-radius:var(--raio-cartao);
  padding:var(--esp-3);
  transition:border-color .2s ease;
}
/* QA2, ronda 4 (09/09): ao contrario dos outros tres grupos, este cartao
   JA tinha border:1px solid var(--borda) -- so a COR muda no :hover,
   nunca a largura (a mesma que o estado normal). --acento contra
   --escuro (o fundo real desta seccao) da 5,40:1, bem acima do minimo
   grafico de 3:1. Este grupo tem UM bloco com link a serio
   ("Distribuidor oficial JETCAM en España"): o efeito e o mesmo nos
   quatro, porque e so cor, nunca uma promessa de clique -- o link em si
   ja tem a sua propria affordance (sublinhado/cor), independente disto.
   Ver testes/cartoes_estado_teste.php. */
.bestech .cartao:hover{
  border-color:var(--acento);
}
/* Ronda de QA 2 do peso de letra (08/09): medido a serio no Figma real
   (get_design_context nas quatro provas, "Más de 20 años de
   experiencia..."/"Distribuidor oficial JETCAM en España"/etc, o
   "div.wire-label" por baixo do circulo do icone) -- ao contrario do
   resto do texto corrido da pagina, este papel E Telegraf:UltraBold no
   protótipo (uma frase curta e afirmativa dentro de um cartao de prova,
   nao uma descricao). Antes desta ronda nao havia ficha nenhuma aqui
   (herdava var(--texto)/400 do body): fica agora explicito, var(--titulo)
   com peso 800 -- ATENCAO, e o UNICO papel desta ronda em que a correcao
   vai no sentido inverso ao resto da pagina (mais pesado, nao mais leve);
   confirmar a olho na captura antes de publicar. Tamanho e cor ficam tal
   e qual (ver contraste_teste.php: a cor continua a herdar --branco de
   .bestech). */
.bestech .cartao__texto{
  margin:0;
  font-family:var(--titulo);
  font-weight:800;
}
/* Tarefa icones-bestech: o circulo por cima do texto, nas tres provas que
   tem icone (ver as fichas --bestech-circulo-* e --bestech-icone-tamanho
   no :root, com a justificacao das medidas). display:flex mais
   align-items/justify-content:center centra o desenho (SVG ou o span da
   mascara) dentro do circulo, qualquer que seja o rácio de cada um. */
.bestech .cartao__icone--circulo{
  display:flex;
  align-items:center;
  justify-content:center;
  width:var(--bestech-circulo-tamanho);
  height:var(--bestech-circulo-tamanho);
  border-radius:50%;
  background-color:var(--bestech-circulo-fundo);
  margin-bottom:var(--esp-3);
}
/* O desenho SVG (bestech-experiencia, bestech-solucoes) tem a propria cor
   presa no ficheiro (stroke="#0498D1", nao currentColor: ver o comentario
   em cartao.php sobre porque esta seccao nao usa esse componente), por
   isso so o TAMANHO precisa de vir daqui. */
.bestech .cartao__icone--circulo svg{
  width:var(--bestech-icone-tamanho);
  height:var(--bestech-icone-tamanho);
}
/* O icone raster (mascara CSS do auscultador) NAO tem cor propria: pinta-
   se com currentColor (ver .cartao__icone--mascara mais abaixo), por isso
   aqui tambem se fixa a cor, alem do tamanho. --acento e a mesma ficha
   azul do resto da pagina (0495CF), a mais proxima do 0498D1 medido no
   prototipo: 4,16:1 de contraste contra --bestech-circulo-fundo, acima do
   minimo de 3:1 para elementos graficos (ver contraste_teste.php). */
.bestech .cartao__icone--circulo .cartao__icone{
  width:var(--bestech-icone-tamanho);
  height:var(--bestech-icone-tamanho);
  color:var(--acento);
}
.bestech__logos{
  display:flex;
  align-items:center;
  gap:var(--esp-3);
  margin-top:var(--esp-3);
}
/* Defeito 1 (relatorio de 02/09): a bandeira e o logotipo JETCAM sao flex
   items sem width propria, so com max-width:100%. Nao basta: max-width:
   100% mede-se contra a largura do FLEX CONTAINER inteiro, nao contra o
   espaco que sobra depois do outro item, e o min-width automatico dos
   flex items (min-width:auto) nao deixa nenhum dos dois encolher abaixo
   disso. Resultado medido no Chrome a largura de desktop: os DOIS
   ficavam com a largura inteira do container cada, lado a lado, o dobro
   do espaco disponivel, e o segundo saia inteiramente para fora do
   cartao e da secao, bem passado da borda direita do ecra - escondido do
   scrollWidth pelo overflow-x:hidden do body (ver esse comentario).
   flex:1 1 0 reparte o espaco a meio entre os dois; min-width:0 anula o
   minimo automatico e deixa cada um encolher a serio; max-width:100%
   continua a impedir que qualquer um cresca acima do que sobra. height:
   auto preserva o proprio racio de cada imagem (a bandeira mais alta, o
   logotipo mais largo e baixo). */
.bestech__logos img{
  display:block;
  flex:1 1 0;
  min-width:0;
  max-width:100%;
  height:auto;
}
/* Achado 2: media 28px de altura a 390 (ver a ficha --alvo-toque no
   :root), abaixo do minimo de 44 do WCAG 2.5.8. inline-flex substitui o
   inline-block so para poder centrar o texto no eixo vertical dentro do
   min-height novo, sem tocar no tamanho do proprio texto. */
/* Ronda de QA 3 (03/09): font-size:var(--letra-1) (14px, no lugar do
   --corpo/16px herdado) -- o QA pede o link mais compacto. min-height
   continua em --alvo-toque (44px, Achado 2): reduzir o TEXTO nao pode
   reduzir a AREA DE CLIQUE, as duas coisas sao independentes com
   inline-flex/align-items:center. */
.bestech__link{
  display:inline-flex;
  align-items:center;
  min-height:var(--alvo-toque);
  margin-top:var(--esp-3);
  font-size:var(--letra-1);
  color:var(--branco);
}

/* QA2, ronda 2 (08/09): o cartao "Distribuidor oficial JETCAM en
   España" (a segunda prova, a unica com bandeira+logotipo+link em vez de
   icone+texto) media 235px de altura a 390 de largura, contra 142px dos
   outros tres cartoes da MESMA grelha -- quase o dobro, so no telemovel
   (a 1 coluna, sem a grelha CSS a esticar as caixas por igual como
   acontece no desktop em 2 colunas, ver .bestech__grelha mais acima).
   Duas correcoes, as duas so aqui dentro do @media: a ALTURA das duas
   imagens passa a fixa (--bestech-logo-altura, ficha nova, justificada
   no :root) em vez de repartir a LARGURA disponivel (flex:1 1 0, Defeito
   1 de 02/09) -- height:auto tirado, width:auto entra, cada imagem
   mantem o proprio racio sem esticar; e os dois espacos verticais a
   volta (antes e depois das imagens) descem de --esp-3 (16px) para
   --esp-1 (8px), o mesmo gesto de "compactar" pedido para o cartao
   inteiro. O desktop fica INTOCADO: o flex:1 1 0 de la ja resolvia um
   defeito real medido contra o Chrome (nao contra o Figma, mas testado a
   serio), e mexer nele agora arriscava um pixel ja dado como resolvido
   numa ronda anterior sem nenhum pedido novo para o desktop. */
@media (max-width: 767px){
  .bestech__logos{
    margin-top:var(--esp-1);
    gap:var(--esp-1);
  }
  .bestech__logos img{
    flex:0 0 auto;
    height:var(--bestech-logo-altura);
    width:auto;
  }
  .bestech__link{
    margin-top:var(--esp-1);
  }
}

/* Tarefa carrosseis-moveis (08/09): no telemovel os quatro cartoes de
   prova deixam de empilhar (a grelha de 1 coluna que a regra base
   ".bestech__grelha" mais acima ja dava) e passam a carrossel horizontal
   por scroll nativo, sem JavaScript. Ao contrario de soluciones e demo,
   o Figma NAO serve de medida aqui: a versao mobile desta seccao (no
   83:1685) tem um defeito conhecido desta ronda -- uma grelha de duas
   colunas com o segundo cartao ("Distribuidor oficial JETCAM en España")
   cortado a meio pela borda do proprio ecra, confirmado por captura, nao
   um carrossel desenhado de proposito. Por isso usa-se a MESMA
   --carrossel-cartao-largura dos outros dois carrosseis desta ronda (83%,
   medida a serio nos outros dois), para os cartoes ficarem do mesmo porte
   visual nas tres seccoes, em vez de inventar um numero novo so para
   compensar um desenho que o proprio Figma nao mostra direito.
   display:flex troca a grelha (grid) por uma fila so; gap proprio
   (--esp-3, o mesmo que a regra base ja usa no eixo horizontal do grid de
   desktop) fica sem alteracao. Fora deste @media a grelha original (1
   coluna sem JavaScript nenhum, ou duas a partir de 768px) nao muda
   nada. */
@media (max-width: 767px){
  .bestech__grelha{
    display:flex;
    flex-wrap:nowrap;
    overflow-x:auto;
    scroll-snap-type:x mandatory;
    -webkit-overflow-scrolling:touch;
    scrollbar-width:none;
  }
  .bestech__grelha::-webkit-scrollbar{
    display:none;
  }
  .bestech .cartao{
    flex:0 0 var(--carrossel-cartao-largura);
    scroll-snap-align:start;
  }
}

/* Tarefa 8b: a fotografia do heroi, a fundo da seccao. Usa a mesma tecnica
   de "full bleed" do main>section::before (left:50% + width:100cqw +
   translateX(-50%), Tarefa 4; era vw, trocado por cqw na Tarefa 11, ver o
   comentario no body). z-index:-2 poe a foto atras do ::before
   (z-index:-1, a camada escura logo acima) e atras do texto (z-index
   automatico, no topo). object-fit:cover recorta a foto sem a distorcer,
   qualquer que seja a altura real da seccao.
   height:100% (excecao aceite, nao precisa de ficha) e obrigatorio: um
   <img> com width/height no HTML (aqui 2480x1655, exigidos para o CLS)
   ganha do proprio browser um rácio intrinseco que, com height:auto,
   ganha SEMPRE a top/bottom para calcular a altura column a partir da
   largura (100vw dividido pelo racio 2480:1655), transbordando a seccao
   inteira em vez de caber nela. Um height explicito corta essa conta.
   Ao contrario de todas as outras imagens da pagina, esta NAO leva
   loading="lazy": e a primeira coisa que se ve. */
.hero__imagem{
  position:absolute;
  top:0;
  left:50%;
  width:100cqw;
  height:100%;
  transform:translateX(-50%);
  z-index:-2;
  object-fit:cover;
}

/* Ronda de correcao da Tarefa 8b: a camada uniforme do ::before (acima)
   resolve o contraste NA MEDIA da foto, mas nao os picos de luz locais
   (as chispas do laser), medidos pixel a pixel na zona real de baixo do
   texto (ver tarefa-8b-relatorio.md). Uma media nunca revela um pico, e
   escurecer a foto inteira para tratar um ponto local estragava-a para
   tratar menos de 1% da area. O text-shadow e a blindagem certa porque
   atua so no CONTORNO das letras, exatamente onde o contraste importa,
   em vez de na foto inteira. Aplica-se aos tres elementos de texto
   corrido sobre a foto (nao ao CTA: desde a Tarefa 9 o botao--principal
   do heroi tem fundo solido --branco com texto --escuro, por isso nunca
   perde contraste contra a foto, seja a foto o que for; testado em
   contraste_teste.php, 18,28:1). */
.hero__selo,
.hero__titulo{
  text-shadow:var(--hero-texto-sombra);
}
/* Achado 1 (revisao de telemovel e a11y, 02/09): --titulo-1 (:root) passou a
   clamp() para o h1 nao ocupar sozinho o primeiro ecra de um telemovel (a
   390x844 o CTA nascia a 832px de topo, 12px visiveis de 56 -- ver o
   relatorio desta ronda). entrelinha-titulo continua fixa em 45px E
   continua a servir o h2 tal como antes (essa ficha nao mudou, o h2 nao
   fica mais apertado nem mais solto em lado nenhum); esta regra so cobre
   .hero__titulo (o UNICO h1 da pagina), com a MESMA razao 1:1 que o Figma
   ja tinha entre --titulo-1 e --entrelinha-titulo a 45px (45/45). Sem esta
   linha, um h1 encolhido pelo clamp continuava a reservar 45px de
   entrelinha fixos por linha (o valor herdado do h1,h2 acima), o que
   desperdicava de volta grande parte do espaco vertical que o proprio
   clamp tinha acabado de libertar. */
.hero__titulo{
  line-height:1;
}
/* Achado 1, continuacao: mesmo com o h1 fluido e a capsula do selo mais
   compacta (.hero__selo acima), um telemovel pequeno (360x640) ainda
   deixava o CTA a nascer fora do primeiro ecra. Este @media reduz so o
   padding-top do PROPRIO .hero (nunca --seccao-mobile, que continua a
   valer 60px em todas as outras sete seccoes: nao e a escala de espaco
   que muda, e uma excecao pontual desta seccao) para --esp-5 (40px) nos
   telemoveis mais estreitos, medido e confirmado no Chrome de verdade
   (ferramentas/medir-alvo-toque.js, modo heroi) contra as tres larguras
   do achado. 480px e o primeiro multiplo redondo acima dos 430 do iPhone
   grande do achado, para nao apanhar telemoveis maiores por engano. */
@media (max-width: 479px){
  .hero{
    padding-top:var(--esp-5);
  }
}
/* Tarefa 2 (escala de tipografia e espaco): medido a 1440, o paragrafo do
   heroi ia aos 1192px do contentor (149 caracteres por linha, o dobro do
   limite de 75). O heroi nao e centrado (selo, h1 e botao ficam todos
   encostados a esquerda sobre a foto, ver o resto desta seccao); por isso
   a margem lateral fica so em baixo (0), sem auto, para a coluna mais
   estreita continuar alinhada ao mesmo lado esquerdo do resto do conteudo,
   como .solucion__paragrafo mais abaixo. O text-shadow sai do grupo acima
   e entra aqui, na mesma regra, para o paragrafo continuar com a mesma
   blindagem do texto sobre a fotografia (ver o comentario dela acima),
   sem precisar de duas regras separadas para o mesmo elemento. */
.hero__paragrafo{
  text-shadow:var(--hero-texto-sombra);
  max-width:var(--largura-leitura);
  margin:var(--esp-3) 0;
}
/* Achado 1, mesma largura do @media junto a .hero__titulo acima: --esp-3
   (16px) e a mesma ficha do .demo__paragrafo/.cta-final__paragrafo (Ronda
   de correcao das seccoes sem dono); aqui, e so aqui, estreita para
   --esp-2 (12px) para devolver 8px ao orcamento vertical do primeiro ecra
   de um telemovel pequeno, sem tocar na ficha partilhada nem nas outras
   duas seccoes que a usam. Fica DEPOIS da regra acima (mesma
   especificidade de classe): uma regra tao especifica quanto a outra so
   ganha por vir depois na folha, nao por @media nenhum. */
@media (max-width: 479px){
  .hero__paragrafo{
    margin-top:var(--esp-2);
    margin-bottom:var(--esp-2);
  }
}

/* Terceira passagem de alinhamento com o Figma (02/09): no prototipo o selo
   do heroi NAO e texto solto, e uma capsula com contorno branco e um ponto
   antes do texto. Medido pixel a pixel na captura do prototipo: 507x40px,
   contorno de 1px, e a altura dos tracos das letras da 12px, que para esta
   familia corresponde ao --corpo de 16px.
   O inline-flex e para a capsula abracar o texto em vez de esticar a
   largura toda do heroi, e o align-self:start impede que uma coluna flex
   pai a estique na mesma. O ponto entra por ::before para nao mexer na
   copy aprovada em conteudo.php. */
.hero__selo{
  display:inline-flex;
  align-self:flex-start;
  align-items:center;
  gap:var(--esp-1);
  padding:var(--esp-1) var(--esp-4);
  border:1px solid var(--branco);
  border-radius:var(--raio-capsula);
  font-size:var(--corpo);
  /* Achado 1: o <p> nao tinha margin propria (ficava com o 1em de topo e
     de baixo que o browser da a qualquer <p> por omissao, 16px a --corpo)
     nem line-height proprio (herdava os 28px de --linha, pensados para
     texto corrido, nao para um rotulo curto de uma capsula). A 390 e a
     360 de largura a frase da capsula ("Distribuidor oficial JETCAM en
     España") nao cabe numa linha so e a capsula passa a duas linhas: com
     a entrelinha de --linha isso custa 56px so de texto, mais o dobro do
     que uma capsula de rotulo precisa. --esp-1 nas margens (em vez do 1em
     por omissao) e 1.3 de entrelinha (perto do --letra-1/--entrelinha-
     rotulo, sem inventar uma ficha nova para 16px) devolvem parte desse
     espaco ao orcamento vertical do heroi, sem mudar a capsula numa
     largura onde ela cabe numa linha so (o desenho continua identico). */
  margin:var(--esp-1) 0;
  line-height:1.3;
}
.hero__selo::before{
  content:"·";
}
/* Arrumo do primeiro ecra do telemovel (02/09): a --corpo (16px) a frase
   inteira ("Distribuidor oficial JETCAM en España") mede cerca de 292px
   sem quebra (Range.getBoundingClientRect, o mesmo metodo ja usado na
   ficha --largura-leitura), mais a bala, o espaco entre ela e o texto e o
   padding da propria capsula: perto de 348px de largura total. A coluna
   do heroi so tem 342px livres a 390 e 312px a 360 (largura da janela
   menos as duas goteiras) -- falha por pouco a 390, por mais a 360 -- e o
   texto quebra para duas linhas, o que estica a capsula de um "estadio"
   para um retangulo alto de cantos redondos: deixa de parecer a mesma
   forma do prototipo.
   --letra-1 (14px) e o mesmo tamanho ja usado nos outros rotulos pequenos
   da pagina (rodape, etiquetas das seccoes: nunca ilegivel, e o tamanho de
   texto mais pequeno que este desenho ja usa por toda a parte), reduz o
   texto para cerca de 256px sem quebra -- cabe de sobra nas duas larguras.
   --esp-3 no padding horizontal (em vez de --esp-4) aperta mais 8px a
   capsula a volta do texto mais pequeno, sem apertar tanto que a capsula
   pareca espremida. Confirmado no Chrome de verdade (ferramentas/
   medir-primeiro-ecra.js): uma linha so a 360 e a 390. Mesmo breakpoint
   (max-width:479px) das outras excecoes pontuais desta seccao no achado 1,
   para nao inventar um limite novo so para isto. */
@media (max-width: 479px){
  .hero__selo{
    padding-left:var(--esp-3);
    padding-right:var(--esp-3);
    font-size:var(--letra-1);
  }
}

/* Segunda passagem de alinhamento com o Figma (02/09): a fotografia certa
   do operador chegou (Defeito 2 corrigido, ver o comentario em
   solucion.php) e a seccao volta a duas colunas do prototipo: texto a
   esquerda, fotografia a direita. Mesmo padrao flex-column -> flex-row do
   .bestech__conteudo (Tarefa 8) - uma coluna em ecra estreito com a
   imagem por baixo do texto (e a segunda no HTML) - com DUAS diferencas:
   as colunas dividem o espaco a meio (flex:1 1 0 nas duas, min-width:0
   para nenhuma ficar presa ao tamanho intrinseco), porque nao ha uma
   grelha de cartoes do lado do texto a definir a proporcao sozinha como
   havia no bestech; e o breakpoint e o do desktop pequeno, nao o de
   tablet que o resto da pagina usa (ver a ficha --largura no :root, o
   mesmo valor deste breakpoint). Medido a serio no browser
   (Range.getClientRects, o mesmo metodo da ficha --largura-leitura): no
   breakpoint de tablet, meia coluna dava menos de metade da largura de
   --largura-leitura, cerca de 33 caracteres por linha, bem abaixo do
   intervalo confortavel de 45 a 75. So no breakpoint do desktop pequeno a
   coluna de texto volta a ficar dentro do intervalo (ver o relatorio
   desta ronda para a tabela completa). Abaixo dele fica em coluna unica,
   com a mesma ficha --largura-leitura da demo/cta-final a limitar a
   leitura. */
.solucion{
  display:flex;
  flex-direction:column;
  gap:var(--esp-5);
}
@media (min-width: 1024px){
  .solucion{
    flex-direction:row;
    /* Ronda de QA 1 (03/09): no fig-full.png o topo da fotografia (y=1992)
       fica quase ao mesmo nivel do topo do titulo (y=2005, 13px de figma
       de diferenca -- praticamente alinhados), nao a meio da coluna de
       texto como align-items:center desenhava. flex-start reproduz esse
       alinhamento pelo topo. */
    align-items:flex-start;
  }
}
.solucion__texto{
  flex:1 1 auto;
}
@media (min-width: 1024px){
  .solucion__texto{
    flex:1 1 0%;
    min-width:0;
  }
}
/* Unica seccao com o h2 a esquerda (ver o comentario em "main>section h2",
   mais acima): aqui o texto todo corre alinhado a esquerda, nao centrado
   como o resto da pagina.
   Ronda de QA 1 (03/09): sem cor propria, herdava --cinza-texto do body
   (titulo cinzento demais); --escuro bate o preto/cinza-escuro do Figma,
   igual ao resto dos titulos da pagina (ver .beneficios__titulo acima). */
.solucion__titulo{
  text-align:left;
  color:var(--escuro);
}
/* Ronda de QA 1 (03/09): os tres blocos de texto media #808080 no
   fig-full.png (--cinza-texto-claro, ver a ficha no :root para a conta
   de contraste) e a tipografia maior -- o "S" de "Sea cual sea..." mede
   18px de figma de altura-maiuscula, ~13,5px CSS, o que da ~18-19px de
   tamanho de letra (13,5/0,72). Fica em --solucion-paragrafo-letra
   (18px), o line-height herdado do body (--linha, 28px) ja fecha muito
   perto do espacamento entre linhas medido (34px de figma, ~25,5px CSS)
   e nao precisa de ficha propria. Contei as linhas do primeiro paragrafo
   no protótipo antes de aceitar o "aproximadamente tres linhas" do
   documento: sao mesmo tres ("Sea cual sea el tamaño..." / "JETCAM puede
   configurarse según..." / "proceso productivo."), o numero bate. */
.solucion__paragrafo,
.solucion__tecnologias{
  max-width:var(--largura-leitura);
  margin:var(--esp-3) 0;
  font-size:var(--solucion-paragrafo-letra);
  color:var(--cinza-texto-claro);
}
/* Ronda de QA 1 (03/09): cantos quase retos no fig-full.png -- a curva do
   canto superior esquerdo da fotografia nao regista NENHUMA transicao
   pixel a pixel (salto direto de fundo a foto, contra os 4px de curva
   real medidos no cartao de beneficios). --raio (2px, ja usado nos
   botoes) e o token mais proximo de zero que ja existe no :root, em vez
   de introduzir um "0" avulso ou uma ficha nova so para isto. */
.solucion__imagem{
  display:block;
  width:100%;
  height:auto;
  border-radius:var(--raio);
}
@media (min-width: 1024px){
  .solucion__imagem{
    flex:1 1 0%;
    min-width:0;
    /* Ronda de QA 1 (03/09): com align-items:flex-start (acima) as duas
       colunas arrancam no mesmo Y do topo da seccao -- mas no
       fig-full.png o topo da fotografia fica ~87px de figma (65px CSS)
       ABAIXO do topo da etiqueta "SOLUCIÓN ADAPTADA", muito perto do
       topo do proprio titulo (13px de figma de diferenca, ver o
       comentario junto a align-items). Este deslocamento e so a
       etiqueta+margem que a fotografia nao tem. */
    margin-top:var(--solucion-imagem-deslocamento);
  }
}

/* Ronda de QA 3 (03/09): o titulo "Preguntas frecuentes" herdava
   --cinza-texto do body -- a mesma queixa ja corrigida em beneficios/
   solucion/demo ("titulo mais cinzento do que o Figma"). --escuro e o
   preto/cinza-escuro do resto dos titulos da pagina. */
.faq__titulo{
  color:var(--escuro);
}

/* Tarefa 10: o acordeao da FAQ. Coluna estreita e centrada (--acordeao-largura,
   menor que --largura), pergunta a esquerda com um sinal de mais a direita
   que passa a cruz ao abrir, filete --borda a separar as linhas, resposta
   em texto mais pequeno que o corpo. Peca de SEO/GEO (ver comentario em
   app/componentes/acordeao.php): o indicador e so pseudo-elemento sobre o
   estado nativo [open] do <details>, sem uma linha de JavaScript. Se
   falhar, o pior que acontece e o sinal nao mudar de + para ×; o details
   continua a abrir e fechar por si so.

   list-style:none tira o triangulo nativo do <summary> (Firefox trata-o
   como item de lista) e ::-webkit-details-marker tira o equivalente do
   Chrome/Safari. Nenhum dos dois tira o <summary> do mapa do teclado: e um
   elemento interativo por definicao do proprio HTML, focavel e ativavel
   por Enter e barra de espaco independentemente do list-style ou do
   display, e o anel de :focus-visible (ja definido acima) continua a
   aparecer a volta dele. Provado a serio no browser, com Tab e o rato
   desligado: ver tarefa-10-relatorio.md. */
.acordeao{
  max-width:var(--acordeao-largura);
  margin:0 auto;
}
.acordeao__item{
  border-bottom:1px solid var(--borda);
}
/* Ronda de QA 3 (03/09): padding desce de --esp-6 (32px) para --esp-4
   (20px) -- medido no fig-full.png pela distancia entre divisorias de
   duas perguntas FECHADAS consecutivas (78px de figma / 58,5px CSS por
   linha inteira, texto+padding dos dois lados); com o line-height mais
   apertado do texto da pergunta (ver .acordeao__pergunta-texto abaixo)
   20+20+~19 de caixa de linha fecha perto do medido, o que --esp-6
   (32+32+28, ~92px) nunca batia. */
.acordeao__pergunta{
  display:flex;
  align-items:center;
  justify-content:space-between;
  gap:var(--esp-3);
  padding:var(--esp-4) 0;
  list-style:none;
  cursor:pointer;
}
.acordeao__pergunta::-webkit-details-marker{
  display:none;
}
/* Ronda de QA 3 (03/09): a pergunta e um <h3> dentro do <summary>
   (acordeao.php), e "h1,h3{font-family:var(--titulo)}" (a escala de
   titulos, mais acima na folha) da-lhe de fabrica a familia ultra-negrita
   (800, a unica que --titulo declara) -- o "peso excessivo" que o QA
   aponta. font-family:var(--texto) mais font-weight:400 tira-a desse
   grupo, a mesma familia/peso do corpo da pagina; line-height:1.3 aperta
   a caixa da linha (o --linha herdado do body, 28px, era o que sobrava
   de espaco por preencher em cada linha fechada, ver o comentario acima). */
.acordeao__pergunta-texto{
  font-size:var(--corpo);
  font-family:var(--texto);
  font-weight:400;
  line-height:1.3;
}
/* Ronda de QA 3 (03/09): tamanho e cor nunca tinham sido medidos a
   serio. No fig-full.png o "+"/"×" fecham em 8x9px de figma (~6-7px CSS
   de tracos, um simbolo bem mais discreto do que os 22px/--titulo-3
   antigos) e a cor amostrada no centro do traco e (110,114,118) --
   --cinza-texto-claro (#717171 = (113,113,113)) e o tom mais proximo
   ja existente, a MESMA cor nos dois estados (fechado e aberto: o Figma
   nao usa --azul em nenhum dos dois, ao contrario do que a implementacao
   antiga fazia). --letra-1 (14px) fica perto do tamanho medido sem
   encolher ao ponto de ficar ilegivel. */
.acordeao__pergunta::after{
  content:'+';
  flex:0 0 auto;
  font-family:var(--titulo);
  font-size:var(--letra-1);
  color:var(--cinza-texto-claro);
}
.acordeao__item[open] .acordeao__pergunta::after{
  content:'×';
}
/* Ronda de QA 3 (03/09): mesma razao do padding da pergunta acima --
   --esp-6 (32px) desce a --esp-4 (20px), medido no bloco da pergunta 1
   (a unica aberta no fig-full.png): o espaco entre o fim da resposta e a
   proxima divisoria fecha bem mais apertado do que 32px. */
.acordeao__resposta{
  padding-bottom:var(--esp-4);
}
/* Ronda de QA 3 (03/09): o max-width antigo (calc(--largura-leitura*14/16)
   = 525px) era o QA em pessoa -- "a resposta fica limitada a uma coluna
   demasiado pequena quando abre". O calculo de 45-75 caracteres/linha
   nunca foi o criterio do Figma para este bloco: medido no fig-full.png,
   a resposta usa PRATICAMENTE A MESMA largura da propria pergunta (1131px
   de figma contra 1132px da linha pergunta+icone, a diferenca e ruido de
   medicao) -- ou seja, a largura toda do acordeao (--acordeao-largura,
   ja corrigida acima), nao uma fracao dela. Sem max-width proprio a
   resposta preenche o container (100% do <div class="acordeao__resposta">,
   que por sua vez preenche o <details>, que preenche --acordeao-largura):
   e essa largura MAIOR, nao um ajuste de tipografia, que resolve as
   "quebras de linha excessivas" do QA (ponto 6, ligado ao ponto 4).
   --cinza-texto-claro no lugar do --cinza-texto herdado (mais escuro do
   que o Figma mostra, a mesma troca ja feita nos paragrafos de
   beneficios/demo/cta-final); line-height:1.6 aperta o herdado do body
   (28px a 14px de letra e um racio 2:1 solto de mais). */
.acordeao__resposta p{
  margin:0;
  font-size:var(--letra-1);
  line-height:1.6;
  color:var(--cinza-texto-claro);
}

/* ==========================================================================
   Formulario (spec 5): a razao de ser da pagina. Fundo azul da seccao
   (.formulario::before, ja agrupado la em cima com .soluciones::before) e
   titulo/intro a branco (.formulario, tambem la em cima).

   Ronda de QA 4 (03/09), documento QA final secao 6 "Estrutura geral da
   seccao": o grande bloco branco de fundo SAI. O formulario integra-se
   no proprio azul da seccao (.formulario__caixa deixa de pintar fundo
   proprio, fica transparente, o azul de baixo continua a aparecer),
   ganha "apenas um contorno fino" (border:1px solid var(--borda), o
   mesmo cinza claro dos campos, 5,19:1 de contraste contra o azul -- ver
   a ficha --formulario-largura no :root para a razao de nao ter medida a
   pixel do Figma nesta ronda), fica mais estreito e centrado
   (max-width:var(--formulario-largura) + margin:auto) e o padding
   encolhe (--esp-5 fixo em vez de --esp-5/calc(--esp-5*1.5) por
   viewport, "conteudo mais compacto"). Todo o texto que vivia sobre
   branco (--cinza-texto, --azul, --erro) troca para as versoes claras
   que leem sobre azul: branco para os valores/titulos, --cinza-claro
   para os rotulos e avisos secundarios (4,86:1 contra o azul, ainda AA),
   --erro-sobre-azul para a mensagem de erro (ver as duas fichas no
   :root). O anel de :focus-visible global (--acento) falha o minimo de
   interface contra este azul (2,58:1, a mesma conta ja feita para o
   cta-final): troca-se por contexto, mais abaixo.

   Os campos continuam linhas simples com sublinhado (--borda em
   repouso), NUNCA caixas com contorno: e o desenho do prototipo, e
   distingue o formulario dos cartoes da pagina, que sim tem contorno.
   Duas colunas a partir de 768px (.formulario__grelha), uma coluna no
   telemovel. Todos os alvos de toque (campos de texto, cada opcao de
   radio/checkbox) usam --alvo-toque (44px), a mesma ficha que ja protege
   os links do rodape (Achado 2, revisao de telemovel e a11y). */

.formulario__caixa{
  background:transparent;
  color:var(--branco);
  text-align:left;
  border:1px solid var(--borda);
  border-radius:var(--raio-cartao);
  max-width:var(--formulario-largura);
  margin-left:auto;
  margin-right:auto;
  padding:var(--esp-4) var(--goteira);
  margin-top:var(--titulo-espaco-baixo);
}
@media (min-width: 768px){
  .formulario__caixa{
    padding:var(--esp-5);
  }
}

/* O anel de foco global (--acento) da 2,58:1 sobre este azul, abaixo do
   minimo AA de interface -- a MESMA conta ja feita para o cta-final
   (ver o comentario junto a essa regra, mais acima na folha). branco da
   8,75:1. Aponta a TODOS os elementos focaveis do formulario (campos,
   opcoes, botao, link do aviso se algum dia existir), nao so ao botao
   como no cta-final, porque aqui ha muitos alvos focaveis diferentes.
   ".formulario *:focus-visible", nao ".formulario :focus-visible": as
   duas selecionam o mesmo (qualquer descendente focado), mas o "*"
   explicito evita que o normalizador de testes/comum.php (que tira o
   espaco a volta de ":", para nao separar pseudo-classes coladas a um
   elemento) apague por engano o espaco do combinador descendente aqui,
   que fica IMEDIATAMENTE antes de um ":". */
.formulario *:focus-visible{
  outline-color:var(--branco);
}

.formulario__intro{
  max-width:var(--largura-leitura);
  margin:var(--esp-3) auto 0;
}

/* Era var(--azul): sobre o branco antigo isso lia-se bem, sobre o azul
   integrado desta ronda ficava azul-sobre-azul, quase invisivel (a mesma
   familia de erro ja corrigida no botao--principal do cta-final). branco
   da 8,75:1. */
.formulario__subtitulo{
  margin:0 0 var(--esp-3);
  font-family:var(--titulo);
  font-size:var(--titulo-3);
  color:var(--branco);
}

.formulario fieldset{
  border:none;
  margin:0;
  padding:0;
}
.formulario__passo + .formulario__passo{
  margin-top:var(--esp-6);
}
/* Ronda de QA 4 (03/09): "reduzir significativamente os espacamentos
   verticais entre os campos" -- era var(--esp-5) (40px), o MESMO
   intervalo que ja separava dois PASSOS inteiros (--esp-6, 32px, ficava
   mais apertado do que isto, o degrau errado). --esp-4 (20px) fica
   visivelmente mais compacto entre dois fieldsets do mesmo passo, sem
   descer abaixo do piso de 4px que ferramentas/medir-espacos.js exige. */
.formulario__fieldset + .formulario__fieldset{
  margin-top:var(--esp-4);
}

/* Os filhos do fieldset empilham com o MESMO intervalo que a grelha usa
   entre linhas, e por gap e nao por margens. Sem isto, um campo largo
   seguido de uma grelha ficava com espaco ZERO entre os dois, porque a
   grelha so espaca por dentro e nada espacava por fora: apanhado pelo
   ferramentas/medir-espacos.js na primeira vez que ele correu contra o
   formulario, que e exatamente para o que esse guarda foi escrito.
   Ronda de QA 4: desce de --esp-4 (20px) para --esp-3 (16px), o mesmo
   pedido de compactacao aplicado ao par de acima. */
.formulario__fieldset{
  display:flex;
  flex-direction:column;
  gap:var(--esp-3);
}

.formulario__grelha{
  display:grid;
  grid-template-columns:1fr;
  gap:var(--esp-3) var(--goteira);
}
@media (min-width: 768px){
  .formulario__grelha{
    grid-template-columns:1fr 1fr;
  }
}
/* Um campo pode ocupar as duas colunas (textarea, grupos de opcoes, o
   proprio campo "Pais" logo a seguir a "Provincia"): grid-column:1/-1
   funciona tanto com uma coluna (telemovel, onde ja e a largura toda)
   como com duas (desktop), sem precisar de uma regra por largura. */
.campo--largo{
  grid-column:1 / -1;
}

/* Era --cinza-texto (quase preto): invisivel sobre o azul integrado
   desta ronda. --cinza-claro da 4,86:1 contra --azul, ainda acima do
   minimo AA de 4,5:1 para texto -- e e mesmo o tom "cinza claro" que o
   documento pede para o texto secundario do formulario (o rotulo nao e
   o valor em si, e a etiqueta por cima dele). */
/* Ronda de QA 2 do peso de letra (08/09): medido a serio no Figma real
   (get_design_context, "Nombre y apellidos*") -- o rotulo do campo e
   Telegraf:Regular, nao Bold. Era var(--rotulo) (Lato, so declara 700 a
   serio): sem font-weight proprio aqui, o browser usava essa unica cara
   de qualquer forma (nearest match, sem sintetizar, mas visualmente a
   negrito) -- o "cartões/formulário mais pesados do que no Figma" que o
   cliente apanhou. Troca para var(--texto) (Varela, 400) com peso
   explicito, para nunca mais depender do match por omissao. Tamanho,
   entrelinha, tracking e cor ficam tal e qual. */
.campo__rotulo{
  display:block;
  margin-bottom:var(--esp-1);
  font-family:var(--texto);
  font-size:var(--letra-1);
  line-height:var(--entrelinha-rotulo);
  letter-spacing:var(--tracking-rotulo);
  font-weight:400;
  color:var(--cinza-claro);
}

/* A linha sublinhada: sem contorno nenhum, so a borda de baixo, sempre
   var(--borda) (5,19:1 contra o azul integrado desta ronda, nao precisa
   de trocar). Em foco/hover a borda troca para --branco: era --azul, que
   sobre o proprio fundo azul da seccao ficava invisivel (a mesma familia
   de erro do --formulario__subtitulo acima) -- esta troca de cor e so um
   reforço visual extra, nunca substitui o anel de :focus-visible (que
   tambem ja troca para branco aqui, ver a regra ".formulario
   :focus-visible" mais acima), por isso NUNCA se define outline aqui.
   min-height usa --alvo-toque (44px): o alvo de toque tem de incluir a
   area clicavel do proprio campo. color:var(--branco) e o valor que a
   pessoa escreve -- era --cinza-texto, tambem invisivel sobre azul. */
.campo__input,
.campo__select,
.campo__textarea{
  display:block;
  width:100%;
  min-height:var(--alvo-toque);
  padding:var(--esp-1) 0;
  border:none;
  border-bottom:2px solid var(--borda);
  border-radius:0;
  background:transparent;
  font-family:var(--texto);
  font-size:var(--corpo);
  color:var(--branco);
  transition:border-color .2s ease;
}
.campo__textarea{
  min-height:calc(var(--alvo-toque) * 2);
  resize:vertical;
}
.campo__input:hover,
.campo__select:hover,
.campo__textarea:hover,
.campo__input:focus,
.campo__select:focus,
.campo__textarea:focus{
  border-bottom-color:var(--branco);
}

.campo__opcoes{
  display:flex;
  flex-direction:column;
  gap:var(--esp-1);
}
/* Variante para os dois grupos compridos (tecnologias: 7 opcoes,
   objetivos: 9 opcoes): duas colunas a partir de 600px, para nao
   alongarem a caixa em demasia no ecra largo. 600px (nao 768, o resto da
   folha) porque estas listas cabem numa largura mais estreita do que a
   grelha principal de dois campos. */
@media (min-width: 600px){
  .campo__opcoes--grelha{
    display:grid;
    grid-template-columns:1fr 1fr;
    gap:var(--esp-1) var(--goteira);
  }
}
/* Variante para grupos curtos de duas ou tres opcoes (Pais, ERP): em
   linha a partir de 480px, para nao gastarem uma coluna inteira de altura
   por um par de opcoes curtas. */
@media (min-width: 480px){
  .campo__opcoes--linha{
    flex-direction:row;
    flex-wrap:wrap;
    gap:var(--esp-1) var(--esp-5);
  }
}

/* Cada opcao (radio ou checkbox) e o proprio alvo de toque inteiro, nao
   so a caixinha nativa: min-height:var(--alvo-toque) mais
   align-items:center da aos 44px minimos a etiqueta de texto ao lado
   tambem, nao so ao quadrado/circulo. accent-color pinta a caixa/circulo
   nativos com --branco (era --azul: sobre o proprio fundo azul da seccao
   um controlo marcado a azul lia-se mal contra o azul a volta -- branco
   destaca-se do fundo em qualquer estado, marcado ou nao). */
.campo__opcao{
  display:flex;
  align-items:center;
  gap:var(--esp-2);
  min-height:var(--alvo-toque);
  cursor:pointer;
}
.campo__opcao input[type="radio"],
.campo__opcao input[type="checkbox"]{
  width:var(--controlo-tamanho);
  height:var(--controlo-tamanho);
  flex-shrink:0;
  accent-color:var(--branco);
}

/* Era var(--erro) (#b3261e, pensado para o branco antigo): 1,34:1 contra
   o azul integrado desta ronda, praticamente invisivel. --erro-sobre-azul
   e a versao clara da mesma cor, calibrada para o novo fundo (ver a
   ficha no :root). */
.campo__erro{
  margin:var(--esp-1) 0 0;
  color:var(--erro-sobre-azul);
  font-size:var(--letra-1);
}

/* Ambos eram --cinza-texto (quase preto, pensados para o branco antigo):
   --cinza-claro da 4,86:1 contra o azul integrado desta ronda, a mesma
   troca ja feita em .campo__rotulo acima, pela mesma razao. */
.formulario__nota{
  margin:0 0 var(--esp-3);
  font-size:var(--letra-1);
  color:var(--cinza-claro);
}

.formulario__aviso{
  margin:0 0 var(--esp-3);
  font-size:var(--letra-1);
  color:var(--cinza-claro);
}

/* O honeypot (spec 5.4): nunca visivel, tambem nao a quem usa leitor de
   ecra (aria-hidden="true" no template, e este bloco tira-o do ecra por
   completo). tabindex="-1" (no template) tira-o da ordem de tabulacao:
   ninguem que navegue por teclado alguma vez o alcanca. width/height de
   1px (nao display:none nem visibility:hidden) e de proposito: alguns
   bots de preenchimento automatico ignoram campos com display:none, mas
   nao ignoram um campo "visivel" fora do ecra. */
.formulario__armadilha{
  position:absolute;
  left:-9999px;
  width:1px;
  height:1px;
  overflow:hidden;
}

/* O botao--principal (Tarefa 9) inverte-se por CONTEXTO de seccao: sobre
   este azul integrado, azul-sobre-azul repetia o mesmo erro ja corrigido
   no cta-final (invisivel, borda transparente incluida). Fica branco com
   texto azul, o MESMO par ja usado no heroi (foto escura) -- e o unico
   dos tres contextos existentes cujo fundo tambem e solido e saturado
   como este, por isso reutiliza-se o par em vez de inventar um quarto.
   8,75:1 de contraste, ver testes/contraste_teste.php; hover/active
   reutilizam --claro/--cinza-claro, a mesma escala que o contexto do
   heroi ja usa (ver o comentario junto a essas duas fichas no :root). */
.formulario .botao--principal{
  background:var(--branco);
  color:var(--azul);
}
.formulario .botao--principal:hover{
  background:var(--claro);
}
.formulario .botao--principal:active{
  background:var(--cinza-claro);
}

.formulario__acoes{
  margin-top:var(--esp-5);
  text-align:center;
}
.formulario__nota-envio{
  margin:var(--esp-2) 0 0;
  text-align:center;
  font-size:var(--letra-1);
  color:var(--cinza-claro);
}

/* Etapa 5 (spec 5.5): o campo de anexos. Mesma linha sublinhada dos
   outros campos (nao um botao pesado nem uma caixa de arrastar-e-largar,
   que o desenho do formulario nao usa em nenhum outro campo); o proprio
   <input type="file"> desenha o botao nativo do browser ("Escolher
   ficheiros") a frente da linha. cursor:pointer no campo inteiro, nao so
   no botao nativo, para o alvo de toque acompanhar min-height. */
.campo__ficheiro{
  cursor:pointer;
}
.campo__ajuda{
  margin:var(--esp-1) 0 0;
  font-size:var(--letra-1);
  color:var(--cinza-claro);
}

/* Etapa 3 (spec do documento QA final, "Si has respondido 'Sí', indica
   cuál"): #grupo-erp_cual e so o ALVO que o formulario.js (progressive
   enhancement) usa para esconder/mostrar via a propriedade .hidden do
   DOM -- sem JavaScript o servidor NUNCA escreve o atributo [hidden]
   neste bloco (ver app/paginas/seccoes/formulario.php), por isso o campo
   fica sempre visivel por omissao, a regra exata do documento. Esconder
   usa o mesmo "[hidden]{display:none!important}" ja global nesta folha
   (mais acima, Achado 3): nao precisa de regra propria. */

/* Pagina de agradecimento (/gracias/): centrada, sem seccao propria com
   fundo (herda o branco do body), porque nao vive dentro de main>section
   com o mesmo desenho das nove seccoes da landing -- e uma pagina curta,
   de saida, nao mais uma seccao de venda. */
.obrigado{
  max-width:var(--largura-leitura);
  margin:0 auto;
  padding:var(--seccao) var(--goteira);
  text-align:center;
}
.obrigado__titulo{
  margin-bottom:var(--esp-3);
}

/* As tres paginas legais (/politica-de-privacidad/, /politica-de-cookies/,
   /aviso-legal/): texto corrido, alinhado a esquerda (ao contrario do
   .obrigado centrado, que e uma pagina de saida curta e nao um documento
   para ler). Mesma largura de leitura e mesma folga vertical da secao. */
.legal{
  max-width:var(--largura-leitura);
  margin:0 auto;
  padding:var(--seccao) var(--goteira);
}
.legal__titulo{
  margin-bottom:var(--esp-2);
}
.legal__actualizacion{
  margin-bottom:var(--esp-4);
  color:var(--cinza-claro);
}
.legal h2{
  margin-top:var(--esp-4);
  margin-bottom:var(--esp-2);
}
.legal p{
  margin-bottom:var(--esp-2);
}