/*
Checkout, mesma decisão do carrinho: NÃO reescrevemos form-checkout.php.
O checkout clássico do WooCommerce é obrigatório aqui (3 plugins BR:
ViaCEP, CPF/CNPJ, PagSeguro transparente, dependem dos IDs padrão
#billing_*_field que só existem nesse modelo). Testado ao vivo (pedido de
teste completo) antes desta fase: o mecanismo de submit funciona
corretamente. Só CSS por cima das classes/IDs que o Woo já gera.
*/

/* ATENÇÃO: o WooCommerce aplica a classe "woocommerce-checkout" tanto no
   <body> (via body_class) QUANTO no <form> do checkout: usar só
   ".woocommerce-checkout" bate no body inteiro e quebra a página inteira
   (virou grid de 2 colunas incluindo header/footer). Sempre qualificar
   com "form." pra acertar só o formulário. */
form.woocommerce-checkout{
    display: grid;
    /* Achado real (21/08/2026, Ricardo testou ao vivo com print: "passou
       muito", as 2 colunas precisam ser SIMETRICAMENTE da mesma largura).
       A proporção 1.25fr/1.15fr da correção anterior (pra caber a linha
       de frete numa linha só) deixou visivelmente desigual — o fix real
       do frete não dependia da proporção da coluna, dependia da largura
       mínima do NOME do produto (ver .eqms-resumo-item__nome), então dá
       pra voltar pra 1fr/1fr sem reabrir o problema da linha de frete. */
    grid-template-columns: 1fr 1fr;
    gap: var(--espaco-2xl);
    /* Achado real (21/08/2026, Ricardo testou ao vivo): "align-items:start"
       deixava os 2 cartões (Detalhes de cobrança x Seu pedido) com altura
       cada um do seu próprio conteúdo, sem nenhuma relação entre si —
       Ricardo pediu simetria explícita. "stretch" (o padrão do grid) faz
       os 2 esticarem pra altura da linha inteira; o cartão do resumo virou
       flex-column (ver .eqms-coluna-resumo) pra sobra de espaço nao
       quebrar o layout interno. */
    align-items: stretch;
}
/* Posicionamento explícito dos filhos diretos que o Woo renderiza aqui
   (confirmado ao vivo via inspeção do HTML renderizado em staging,
   01/08/2026): #customer_details.col2-set (campos de cobrança/endereço) e
   .eqms-coluna-resumo (heading "Seu pedido" + resumo + cupom, agrupados
   num cartão único via JS desde 21/08/2026 — ver checkout-wizard.js). Sem
   posicionamento explícito, o auto-placement do grid espalha os filhos de
   forma imprevisível. Fixado: coluna 1 = .col2-set do topo ao fim (2
   linhas); coluna 2 = .eqms-coluna-resumo do topo ao fim também (mesma
   altura da coluna 1, silhueta de cartão único). */
/* CORRIGIDO 21/08/2026 (achado real, reproduzido ao vivo via Playwright em
   375-414px: overflow horizontal medido de 318px, form.woocommerce-checkout
   com grid-template-columns computado em "644.125px" fixo em vez de 100%
   da tela). Causa raiz: itens de CSS Grid têm min-width:auto por padrão,
   que usa o min-content do conteúdo (aqui, a linha de frete com
   radio+nome+prazo forçados em nowrap, ver ul#shipping_method abaixo) como
   piso — a coluna "1fr" do grid mobile não conseguia encolher abaixo
   desse piso, e o form inteiro passava do viewport. min-width:0 remove
   esse piso (padrão conhecido pra esse bug de grid), deixando a coluna
   encolher de verdade pro tamanho real da tela; o conteúdo que ainda for
   largo demais dentro dela vira scroll interno da PRÓPRIA linha (ver
   overflow-x:auto na linha de frete), nunca estoura a página inteira. */
form.woocommerce-checkout > .col2-set{
    grid-column: 1;
    grid-row: 1 / 3;
    min-width: 0;
}
form.woocommerce-checkout > .eqms-coluna-resumo{
    grid-column: 2;
    grid-row: 1 / 3;
    min-width: 0;
}
@media (max-width: 900px){
    form.woocommerce-checkout{
        grid-template-columns: 1fr;
    }
    /* Reset do posicionamento explícito acima: com 1 coluna só, manter
       grid-column:2 criaria uma coluna implícita extra e quebraria o
       empilhamento mobile que já funciona hoje. Volta pro auto-placement
       (ordem natural do DOM = mesma ordem visual desejada no mobile). */
    form.woocommerce-checkout > .col2-set,
    form.woocommerce-checkout > .eqms-coluna-resumo{
        grid-column: auto;
        grid-row: auto;
    }
}

/* Achado real (Swarm Checkout Conversion UX, 13/08/2026, inspecao ao vivo
   da cadeia de ancestrais de form.checkout): nao existe page-checkout.php
   dedicado, o checkout cai no page.php generico, que embrulha o conteudo
   em ".conteudo-pagina" (institutional.css), travada em 800px de largura
   de leitura -- certo pra texto institucional (Sobre, blog), errado pro
   formulario de 2 colunas com widget de pagamento embutido. Confirmado:
   form.checkout ficava preso a 800px dentro de um article.container de
   1240px (--largura-container), sobrando ~440px vazios em 1440px de
   viewport e espremendo o payment_box do Mercado Pago pra 228px de
   largura quando selecionado -- essa e a causa raiz do "espremido"
   reportado, nao a proporcao entre as colunas (1.4fr:1fr ja estava
   correta). Libera so aqui via classe de body que o WooCommerce ja
   aplica na pagina de checkout, sem tocar no page.php (compartilhado com
   Politica de Privacidade e outras paginas institucionais que precisam
   continuar limitadas a 800px). */
body.woocommerce-checkout .conteudo-pagina{
    max-width: none;
}

/* Peso visual dos avisos do topo (Swarm Checkout Conversion UX,
   13/08/2026): ".woocommerce-message" (produto adicionado) e
   ".woocommerce-info" (toggles "ja e cliente"/"tem um cupom") vem
   estilizados em woocommerce-notices.css com padding generoso + sombra,
   pensados pra Loja/Carrinho, onde a notice aparece sozinha flutuando
   sobre a grade de produtos. No Checkout as 3 aparecem empilhadas antes
   do formulario e competem em peso visual com o proprio formulario.
   Reduzimos aqui, so no Checkout (nao mexe em woocommerce-notices.css,
   Carrinho continua com o tratamento original): menos padding vertical,
   sem sombra, menos espaco entre elas. Mantido: cor, borda esquerda,
   icone, link, area clicavel de 44px dos toggles (showlogin/showcoupon),
   nada de funcionalidade muda. */
body.woocommerce-checkout .woocommerce-message,
body.woocommerce-checkout .woocommerce-info{
    padding-top: var(--espaco-sm);
    padding-bottom: var(--espaco-sm);
    margin-bottom: var(--espaco-sm);
    box-shadow: none;
}

.woocommerce-checkout h3{
    margin-bottom: var(--espaco-md);
}

/* Campos de formulário: form-row/form-row-first/last/wide são classes
   nativas do Woo (inclusive as adicionadas pelo Extra Checkout Fields BR) */
.woocommerce-checkout .form-row{
    margin-bottom: var(--espaco-md);
}
.woocommerce-checkout .form-row label{
    display: block;
    font-size: var(--texto-xs);
    font-weight: 700;
    text-transform: uppercase;
    letter-spacing: 0.03em;
    color: var(--cor-cacau-70);
    margin-bottom: var(--espaco-2xs);
}
.woocommerce-checkout .form-row .required{
    color: var(--cor-terracota);
}
/* 21/08/2026 (achado real do Ricardo, testando o checkout ao vivo com
   itens de verdade no carrinho): a label acima já tinha o tratamento certo
   (uppercase, pequena, negrito) desde 13/08, mas o CAMPO em si nunca
   ganhou nenhuma regra de fundo/borda/raio/padding — só "width:100%" e
   "min-height:44px" (alvo de toque, item 8 abaixo). Resultado: campo de
   input renderizava com a caixa branca padrão do navegador, cantos retos,
   sem nenhum contato visual com o resto do site. Corrigido seguindo o
   mesmo vocabulário já usado no resto do tema (raio/borda/foco dos
   componentes de vidro e do buttons.css), não inventado do zero. */
.woocommerce-checkout .form-row input.input-text,
.woocommerce-checkout .form-row select,
.woocommerce-checkout .form-row textarea{
    width: 100%;
    /* Item 8 (mapeamento Fase 2): campos medidos ao vivo com 37-40px de
       altura, levemente abaixo do mínimo de 44px recomendado pra alvo de
       toque. min-height só estabelece um piso, não acha nenhum campo que
       já seja maior (textarea de observações do pedido, por exemplo). */
    min-height: 44px;
    padding: var(--espaco-sm) var(--espaco-md);
    background: var(--cor-branco);
    border: 1px solid rgba(51, 41, 31, 0.18);
    border-radius: var(--raio-sm);
    font-family: var(--fonte-corpo);
    font-size: var(--texto-base);
    color: var(--cor-cacau);
    transition: border-color 0.2s ease, box-shadow 0.2s ease;
}
.woocommerce-checkout .form-row textarea{
    min-height: 90px;
    resize: vertical;
}
/* Foco só na borda, sem anel (achado do transplante estrutural do
   Ourigen, 21/08/2026, pedido do Ricardo — clone rigoroso: referência usa
   "focus:border-[cor] focus:outline-none", sem box-shadow nenhum). */
.woocommerce-checkout .form-row input.input-text:focus,
.woocommerce-checkout .form-row select:focus,
.woocommerce-checkout .form-row textarea:focus{
    outline: none;
    border-color: var(--cor-mata);
}
.woocommerce-checkout .form-row input.input-text::placeholder,
.woocommerce-checkout .form-row textarea::placeholder{
    color: var(--cor-cacau-45);
}
/* Select2 (WooCommerce carrega por padrão no campo País — Extra Checkout
   Fields Brazil troca Estado por <select> nativo, já coberto acima, mas
   País continua sendo o widget enriquecido do próprio Woo core). Mesma
   caixa visual do input nativo, pra não ter 2 linguagens de campo na
   mesma tela. */
.woocommerce-checkout .select2-container .select2-selection--single{
    height: 44px;
    padding: var(--espaco-sm) var(--espaco-md);
    background: var(--cor-branco);
    border: 1px solid rgba(51, 41, 31, 0.18);
    border-radius: var(--raio-sm);
}
.woocommerce-checkout .select2-container .select2-selection__rendered{
    padding: 0;
    line-height: 26px;
    font-family: var(--fonte-corpo);
    font-size: var(--texto-base);
    color: var(--cor-cacau);
}
.woocommerce-checkout .select2-container .select2-selection__arrow{
    height: 42px;
}
.woocommerce-checkout .select2-container--focus .select2-selection--single,
.woocommerce-checkout .select2-container--open .select2-selection--single{
    border-color: var(--cor-mata);
}
/* Dropdown do Select2 (achado real, 21/08/2026, Ricardo testou ao vivo e
   reportou "menu arcaico"): a caixa fechada já tinha estilo da marca desde
   13/08, mas a LISTA que abre (Select2 anexa fora do formulário, style
   próprio) nunca tinha sido tocada — ficava com o azul padrão do
   navegador/plugin, sem nenhuma relação visual com o resto do site. */
.select2-dropdown{
    border-color: rgba(51, 41, 31, 0.18);
    border-radius: var(--raio-sm);
    box-shadow: var(--sombra-md);
    overflow: hidden;
}
.select2-search--dropdown{
    padding: var(--espaco-xs);
    background: var(--cor-branco);
}
.select2-search--dropdown .select2-search__field{
    border: 1px solid rgba(51, 41, 31, 0.18);
    border-radius: var(--raio-sm);
    padding: 6px var(--espaco-sm);
    font-family: var(--fonte-corpo);
    outline: none;
}
.select2-search--dropdown .select2-search__field:focus{
    border-color: var(--cor-mata);
}
.select2-results__option{
    padding: var(--espaco-xs) var(--espaco-sm);
    font-family: var(--fonte-corpo);
    font-size: var(--texto-base);
    color: var(--cor-cacau);
}
.select2-container--default .select2-results__option--highlighted[aria-selected]{
    background: var(--cor-mata) !important;
    color: var(--cor-branco) !important;
}
.select2-container--default .select2-results__option[aria-selected="true"]{
    background: var(--cor-linho-2);
    color: var(--cor-cacau);
}

/* Grid de campos do endereço (achado real, 21/08/2026, Ricardo testou ao
   vivo com print e reportou "desalinhado" e "muito grande"): o
   .col2-set/.form-row-first/.form-row-last é flex-wrap com TODOS os pares
   disputando a mesma largura mínima (240px) — CEP/Número (que deveriam
   ser estreitos) competiam de igual pra igual com Endereço/Complemento
   (que precisam ser largos), então o wrap dependia da largura exata do
   container e as linhas cascateavam torto, cada uma quebrando num ponto
   diferente. Trocado por CSS Grid de 12 colunas com largura PROPORCIONAL
   real por campo (CEP 4/12, Endereço 8/12 etc.), usando seletor por
   sufixo de ID pra cobrir billing_* e shipping_* de uma vez só (mesmos
   campos, prefixo diferente). Isso substitui form-row-first/last/wide
   SÓ dentro do wrapper de campos do endereço — não mexe no restante do
   checkout (resumo, pagamento). */
.woocommerce-billing-fields__field-wrapper,
.woocommerce-shipping-fields__field-wrapper{
    display: grid;
    grid-template-columns: repeat(12, 1fr);
    gap: 0 var(--espaco-md);
}
.woocommerce-billing-fields__field-wrapper > .form-row,
.woocommerce-shipping-fields__field-wrapper > .form-row{
    grid-column: span 12;
    /* Achado real (21/08/2026, Ricardo testou ao vivo e mediu com
       getBoundingClientRect: vão de ~120-180px sobrando entre campos que
       deveriam estar coladas, tipo Nome/Sobrenome e CEP/Endereço). Causa
       raiz: o WooCommerce core aplica ".form-row-first,.form-row-last{
       width:47%}" nesses mesmos elementos — width em porcentagem sobre um
       item de grid encolhe ele DENTRO da própria célula (47% da célula, não
       47% da linha inteira), sobrando espaço vazio do lado. Campos que
       nasceram "form-row-wide" (Tipo de Pessoa, CPF, Celular, E-mail) não
       tinham esse width herdado, por isso só ELES ficavam do tamanho certo
       antes desta correção. Reset explícito pra 100% da célula do grid em
       TODOS os campos, sem exceção. */
    width: 100% !important;
}
.woocommerce-billing-fields__field-wrapper > [id$="_first_name_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_last_name_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_persontype_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_cpf_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_phone_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_email_field"],
.woocommerce-shipping-fields__field-wrapper > [id$="_first_name_field"],
.woocommerce-shipping-fields__field-wrapper > [id$="_last_name_field"]{
    grid-column: span 6;
}
.woocommerce-billing-fields__field-wrapper > [id$="_postcode_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_number_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_neighborhood_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_city_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_state_field"],
.woocommerce-shipping-fields__field-wrapper > [id$="_postcode_field"],
.woocommerce-shipping-fields__field-wrapper > [id$="_number_field"],
.woocommerce-shipping-fields__field-wrapper > [id$="_neighborhood_field"],
.woocommerce-shipping-fields__field-wrapper > [id$="_city_field"],
.woocommerce-shipping-fields__field-wrapper > [id$="_state_field"]{
    grid-column: span 4;
}
.woocommerce-billing-fields__field-wrapper > [id$="_address_1_field"],
.woocommerce-billing-fields__field-wrapper > [id$="_address_2_field"],
.woocommerce-shipping-fields__field-wrapper > [id$="_address_1_field"],
.woocommerce-shipping-fields__field-wrapper > [id$="_address_2_field"]{
    grid-column: span 8;
}
@media (max-width: 600px){
    .woocommerce-billing-fields__field-wrapper > .form-row,
    .woocommerce-shipping-fields__field-wrapper > .form-row{
        grid-column: span 12 !important;
    }
}

.woocommerce-checkout .col2-set{
    display: flex;
    flex-wrap: wrap;
    align-content: flex-start;
    gap: 0 var(--espaco-md);
}
/* Achado real (auditoria de responsividade, 01/08/2026): o WooCommerce
   core da a .col-1 (campos de cobranca) e .col-2 (checkbox "endereco
   diferente" + observacoes) uma largura de ~47% cada com float proprio.
   Como aqui .col2-set virou flex, float nao tem efeito nos filhos diretos,
   mas a largura em % continua valendo — e exatamente na faixa 850-900px
   (onde o grid externo do checkout esta em modo 1 coluna e .col2-set fica
   com quase largura total do formulario), 47%+47%+gap cabe lado a lado
   sem quebrar linha, jogando .col-2 (observacoes) pra cima, antes de
   "Criar uma conta?" que fica mais abaixo dentro de .col-1 — quebra a
   ordem de leitura numa etapa de pagamento. Fora dessa faixa estreita o
   wrap acontecia por sorte (container mais estreito). Fixado: .col-1/.col-2
   sempre 100% de largura, nunca lado a lado, em qualquer largura de tela. */
.woocommerce-checkout .col2-set .col-1,
.woocommerce-checkout .col2-set .col-2{
    flex: 1 1 100%;
    width: 100% !important;
}

/* Cartão único "Seu pedido" (heading + resumo + cupom, agrupados via JS
   em .eqms-coluna-resumo desde 21/08/2026 — achado real do Ricardo: os 2
   cartões da tela, "Detalhes de cobrança" e "Seu pedido", não tinham o
   mesmo tratamento visual nem a mesma altura, pareciam de sistemas
   diferentes). Fundo em degradê sutil (não plano) + sombra real (--sombra-lg)
   dão profundidade sem depender de blur sobre fundo liso (blur só funciona
   visualmente sobre foto/cor viva, nunca sobre --cor-linho — regra já
   documentada em vidro.css). Faixa de terracota no topo é o mesmo acento
   raro do Brand Book, não decoração nova inventada. flex-column + altura
   100% deixam o cartão esticar até a altura do formulário ao lado
   (align-items:stretch no grid pai) sem quebrar o conteúdo interno. */
.eqms-coluna-resumo{
    display: flex;
    flex-direction: column;
    height: 100%;
    background: linear-gradient(165deg, var(--cor-linho-2) 0%, var(--cor-linho) 100%);
    border-radius: var(--raio-md);
    border: 1px solid var(--vidro-borda-escura);
    border-top: 3px solid var(--cor-terracota);
    box-shadow: var(--sombra-lg);
    padding: var(--espaco-lg);
}
.eqms-coluna-resumo #order_review_heading{
    margin: 0 0 var(--espaco-md);
}
#order_review{
    display: flex;
    flex-direction: column;
    flex: 1;
}
/* Achado real (21/08/2026, Ricardo testou ao vivo com produto de nome
   longo real: "Creme Dental Natural com Extratos de Camomila, Melissa e
   Uva", 2 rodadas de ajuste): tentativas de mexer na LARGURA da coluna
   (width:1%, depois table-layout:fixed) sempre acabavam espremendo TAMBÉM
   a linha "Envio" por tabela sem table-layout:fixed compartilhar largura
   de coluna entre todas as linhas — a linha de frete precisa ficar larga
   (nome+preço+prazo numa linha só, pedido à parte do Ricardo), então
   qualquer regra de largura de coluna nesta tabela sempre ia brigar com
   ela. Causa raiz de verdade do aperto (achada depois, na seção
   ".eqms-resumo-item__nome" abaixo): não era a tabela, era o
   "min-width:0" no nome do produto. Aqui só sobra o alinhamento à
   direita + nowrap no preço, sem nenhuma largura forçada. */
.woocommerce-checkout-review-order-table{
    width: 100%;
    margin-bottom: var(--espaco-lg);
}
.woocommerce-checkout-review-order-table td.product-total,
.woocommerce-checkout-review-order-table th.product-total{
    white-space: nowrap;
    text-align: right;
}
/* Ricardo pediu explicitamente: só o nome do produto fica à esquerda,
   TODO valor (subtotal, total) fica à direita — antes "text-align:left"
   valia pra tabela inteira sem exceção. Exclui a linha "Envio"
   (tr.shipping): o conteúdo dela é o bloco de rádio+nome+prazo do frete,
   que precisa continuar à esquerda (ver regras de ul#shipping_method
   acima), não é um valor único pra jogar pra direita. */
.woocommerce-checkout-review-order-table tfoot td:not(.eqms-rodape-confianca-linha td):not(.shipping td){
    text-align: right;
}
.woocommerce-checkout-review-order-table tr.shipping td{
    text-align: left;
}
/* CORRIGIDO 26/08/2026 (achado real, Ricardo reportou ao vivo "colunas
   fora de posicionamento" no checkout, screenshot mostrando o texto de
   "Envio: nao existem metodos de entrega..." colado na borda direita da
   coluna, com um vao enorme antes dele). Causa raiz: bug de especificidade
   CSS, nao erro de logica. A regra acima ja tentava excluir a linha de
   frete do alinhamento a direita, mas ":not(.eqms-rodape-confianca-linha
   td)" tem mais elementos na propria especificidade (o argumento do :not
   soma "classe+elemento" ao seletor todo) do que ".shipping td" sozinho,
   entao a regra de baixo ("text-align:left") SEMPRE perdia pra de cima,
   mesmo vindo depois no arquivo. Corrigido igualando a exclusao: agora o
   :not() de cima tambem exclui ".shipping td" explicitamente, entao a
   linha de frete nunca mais compete contra a propria regra que deveria
   mante-la a esquerda. */
.woocommerce-checkout-review-order-table th,
.woocommerce-checkout-review-order-table td{
    padding: var(--espaco-sm) 0;
    border-bottom: 1px solid rgba(51,41,31,0.12);
    text-align: left;
}
/* Hierarquia do TOTAL reforcada (Swarm Checkout Conversion UX,
   13/08/2026): antes so tamanho/cor/negrito distinguiam o TOTAL de
   Subtotal/Frete, pouco contraste numa lista de linhas parecidas. Soma-se
   uma divisoria acima (borda mais forte que a rgba(0.12) usada entre as
   outras linhas) e sobe de --texto-lg pra --texto-xl, mesmos tokens do
   sistema, sem criar cor ou espacamento novo. */
.woocommerce-checkout-review-order-table tfoot tr:last-child th,
.woocommerce-checkout-review-order-table tfoot tr:last-child td{
    font-weight: 700;
    color: var(--cor-mata);
    font-size: var(--texto-xl);
    border-top: 2px solid var(--vidro-borda-escura);
    border-bottom: none;
    padding-top: var(--espaco-md);
}

/* Linha "Envio" (achado real, 21/08/2026, Ricardo testou ao vivo com 2
   opções reais de frete calculadas e reportou "tumultuado", "criou uma
   coluna invisível", "linha feia"): o "th Envio" vertical-align padrão de
   tabela (middle) flutuava no meio de uma célula bem mais alta quando
   havia 2 métodos de frete, e o "<p><small>Entrega em até X dias</small>
   </p>" que o plugin WooCommerce Correios injeta (woocommerce_after_
   shipping_rate, sem NENHUMA classe/estilo) herdava margem padrão de
   parágrafo do navegador — dava a sensação de bloco solto/empurrado pra
   direita. Corrigido: radio+nome+preço numa linha, prazo de entrega
   embaixo alinhado com o TEXTO do nome (não com o radio), sem margem de
   parágrafo sobrando. */
.woocommerce-checkout-review-order-table tr.shipping th,
.woocommerce-checkout-review-order-table tr.shipping td{
    vertical-align: top;
}
ul#shipping_method{
    list-style: none;
    margin: 0;
    padding: 0;
    /* Rede de seguranca (21/08/2026): radio+nome+prazo ficam em nowrap de
       proposito (pedido do Ricardo, ver achado abaixo), entao em telas bem
       estreitas essa linha pode nao caber. Preferimos rolagem horizontal
       CONTIDA so nesta lista (nunca afeta o resto da pagina) a quebrar o
       "tudo numa linha so" ja decidido, ou a deixar o layout inteiro
       estourar de novo (mesma causa raiz do achado logo acima, em
       form.woocommerce-checkout > .col2-set/.eqms-coluna-resumo). */
    overflow-x: auto;
}
/* Achado real 2 (21/08/2026, mesma sessão: Ricardo viu o resultado da
   primeira correção ao vivo e pediu ajuste na hora): "linha embaixo" não
   ficou bom — queria tudo numa linha só (nome+preço+prazo), bloco mais
   LARGO (horizontal) e mais FINO (vertical). E o rádio nativo sem
   width/height explícito ficava com tamanho intrínseco inconsistente,
   parecendo "em cima da palavra" ao lado do texto — resolvido com
   width/height fixos + align-items:center (baseline não é confiável com
   um elemento replaced tipo radio). */
ul#shipping_method li{
    display: flex;
    flex-wrap: nowrap;
    align-items: center;
    column-gap: var(--espaco-sm);
    padding-block: 6px;
}
ul#shipping_method li + li{
    border-top: 1px solid rgba(51, 41, 31, 0.1);
}
ul#shipping_method li input[type="radio"]{
    width: 16px;
    height: 16px;
    margin: 0;
    flex-shrink: 0;
    accent-color: var(--cor-mata);
}
ul#shipping_method li label{
    font-family: var(--fonte-corpo);
    font-weight: 700;
    font-size: var(--texto-sm);
    color: var(--cor-cacau);
    white-space: nowrap;
}
ul#shipping_method li p{
    margin: 0;
}
ul#shipping_method li p small{
    font-size: var(--texto-xs);
    color: var(--cor-cacau-70);
    white-space: nowrap;
}

/* Miniatura de produto no resumo (20/08/2026, redesign referenciando
   QuanQton/Ourigen — resumo do pedido sempre com foto real, nunca só
   texto). Foto vem de get_image('thumbnail'), sempre real do catálogo,
   nunca gerada/inventada. */
/* Reduzido de 48px pra 36px (achado real, 21/08/2026: Ricardo testou com
   produto de nome longo e reportou "quadradões gigantes", pediu pra
   diminuir). */
.eqms-resumo-item{
    display: flex;
    align-items: center;
    gap: var(--espaco-xs);
}
.eqms-resumo-item__miniatura{
    flex-shrink: 0;
    width: 48px;
    height: 48px;
    border-radius: var(--raio-sm);
    overflow: hidden;
    background: var(--cor-linho);
}
.eqms-resumo-item__miniatura img{
    width: 100%;
    height: 100%;
    object-fit: cover;
}
/* Causa raiz REAL do texto "uma palavra por linha" que o Ricardo reportou
   (21/08/2026, testado ao vivo com produto de nome longo): não era a
   largura da tabela (2 tentativas anteriores nessa linha de raciocínio
   falharam, ver comentário na tabela acima) — era este "min-width:0"
   aqui. Item flex sem min-width definido usa "auto" por padrão, que
   PROTEGE o texto de encolher além da palavra mais longa; "min-width:0"
   remove essa proteção de propósito (padrão comum pra texto+ícone não
   estourar um container apertado), mas aqui a proteção fazia falta:
   sem ela, a célula da tabela "convidava" o texto a encolher até virar
   uma coluna de 1 palavra. Removido — a tabela agora recebe a largura
   mínima real do texto, sem precisar forçar nada na tabela em si.
   AJUSTE: "min-content" sozinho não bastou (o flex dentro da célula da
   tabela não repassa o tamanho real pro algoritmo de largura da tabela de
   forma confiável entre navegadores) — min-width fixo em px é mais
   previsível aqui e não conflita com a linha "Envio" (que não usa esse
   flex, tem sua própria regra de largura livre). */
.eqms-resumo-item__nome{
    min-width: 220px;
}
/* CORRIGIDO 26/08/2026 (achado real, Ricardo testou no mobile de 390px e
   reportou a pagina inteira "fora de posicionamento"): os 220px fixos
   acima (necessarios no desktop pra nome de produto longo nao virar 1
   palavra por linha) somados a miniatura de 48px + gap + padding do
   cartao ".eqms-coluna-resumo" ultrapassam a largura disponivel numa tela
   de 390px, e a tabela inteira estoura ~49px pra fora da viewport (medido
   ao vivo via getBoundingClientRect). Abaixo de 480px o min-width cai pra
   um valor que ainda evita a quebra em 1 palavra por linha, mas cabe no
   espaco real disponivel; a rede de seguranca overflow-x abaixo (mesmo
   padrao ja usado em ul#shipping_method acima) garante que, se algum nome
   de produto real ainda for largo demais, o estouro vira rolagem CONTIDA
   só da tabela, nunca da pagina inteira de novo. */
@media (max-width: 480px){
    .eqms-resumo-item__nome{
        min-width: 140px;
    }
    .woocommerce-checkout-review-order-table{
        display: block;
        overflow-x: auto;
    }
}

/* Rodapé de confiança abaixo do total (selo + "bandeiras" em texto, sem
   logo licenciado — mesmo padrão visto nos checkouts de referência). */
.eqms-rodape-confianca-linha td{
    border-bottom: none !important;
    padding-top: var(--espaco-md) !important;
}
/* Empilhado em 2 linhas (selo+texto, depois as bandeiras), centralizado —
   mesmo padrão da referência (Ourigen, checkout/page.tsx: flex-col
   items-center gap-3, nunca tudo numa linha só). */
.eqms-rodape-confianca{
    display: flex;
    flex-direction: column;
    align-items: center;
    justify-content: center;
    gap: var(--espaco-sm);
    padding-top: var(--espaco-md);
    margin-top: var(--espaco-xs);
    border-top: 1px solid rgba(51, 41, 31, 0.12);
    font-size: var(--texto-xs);
    color: var(--cor-cacau-70);
    text-align: center;
}
.eqms-rodape-confianca__selo{
    display: inline-flex;
    align-items: center;
    gap: var(--espaco-xs);
    font-weight: 700;
    text-transform: uppercase;
    letter-spacing: 0.06em;
    color: var(--cor-mata);
}
.eqms-rodape-confianca__icone{
    width: 16px;
    height: 16px;
    color: var(--cor-mata);
}
.eqms-rodape-confianca__selos{
    display: flex;
    gap: var(--espaco-2xs);
}
.eqms-rodape-confianca__selos span{
    padding: 2px 8px;
    background: var(--cor-linho-2);
    border-radius: var(--raio-sm);
    font-size: 10.5px;
    font-weight: 700;
    letter-spacing: 0.03em;
    color: var(--cor-cacau-70);
}

/* Métodos de pagamento */
#payment{
    background: transparent;
}
ul.wc_payment_methods{
    list-style: none;
}
ul.wc_payment_methods li.wc_payment_method{
    border: 1px solid rgba(51,41,31,0.15);
    border-radius: var(--raio-sm);
    padding: var(--espaco-md);
    margin-bottom: var(--espaco-sm);
}
/* Achado real (20/08/2026, causa raiz confirmada lendo o CSS core do
   WooCommerce): o lilas (#dcd7e2) vem de uma regra do proprio
   woocommerce.css --
   ".woocommerce-checkout #payment div.payment_box{background-color:#dcd7e2}"
   -- com um seletor de ID (#payment) que vence qualquer combinacao de
   classes, por isso a tentativa anterior (so classes) nao bateu. Repete a
   MESMA forma de seletor (classe + ID + elemento + classe) pra igualar a
   especificidade e vencer por ordem de carga (este arquivo carrega depois
   do woocommerce.css). */
ul.wc_payment_methods .payment_box{
    margin-top: var(--espaco-sm);
    padding: var(--espaco-sm) var(--espaco-md);
    font-size: var(--texto-sm);
    color: var(--cor-cacau-70);
    border-radius: var(--raio-sm);
}
.woocommerce-checkout #payment div.payment_box{
    background-color: var(--cor-linho);
    border: 1px solid rgba(51, 41, 31, 0.12);
}
.woocommerce-checkout #payment div.payment_box::before{
    display: none;
}
#place_order{
    width: 100%;
    text-align: center;
    padding: var(--espaco-md) var(--espaco-lg);
    font-size: var(--texto-base);
}

/* Validação (Extra Checkout Fields Brazil injeta/esconde campos aqui) */
.woocommerce-checkout .validate-required.woocommerce-invalid input.input-text{
    border-color: var(--cor-terracota);
}

/* Item 2 (mapeamento Fase 2): a label do checkbox "Entregar em um endereço
   diferente?" saía gigante (Spectral ~32px, quebrando em 3 linhas),
   destoando do checkbox "CRIAR UMA CONTA?" logo acima (13px, normal).
   Causa raiz confirmada ao vivo inspecionando o DOM: o WooCommerce core
   (templates/checkout/form-shipping.php) embrulha SÓ esse checkbox num
   <h3 id="ship-to-different-address">, que cai na regra genérica
   "h1, h2, h3, h4, h5, h6" do 02-base.css (fonte Spectral, tamanho de
   título). O checkbox de criar conta não tem esse wrapper de heading, por
   isso nunca teve o problema. Resetamos aqui só esse h3 específico pro
   mesmo padrão visual do outro checkbox, sem tocar no 02-base.css (fora do
   território) nem em nenhum outro h3 do site. Confirmado ao vivo: font-size
   caiu de 32px pra 13px, sem nenhum efeito colateral no resto da página. */
h3#ship-to-different-address{
    font-family: var(--fonte-corpo);
    font-size: var(--texto-xs);
    font-weight: 700;
    text-transform: uppercase;
    letter-spacing: 0.03em;
    color: var(--cor-cacau-70);
    margin: 0 0 var(--espaco-sm);
}
h3#ship-to-different-address label{
    font-family: inherit;
    font-size: inherit;
    font-weight: inherit;
    text-transform: inherit;
    color: inherit;
}

/* ===== Borda sutil no card de endereço da Minha Conta (Auditoria de Design
   Visual, item "Paineis de resumo", EQMS-AUDITORIA-DESIGN-VISUAL.md,
   24/07/2026) =====
   ".woocommerce-Address" mora fisicamente em my-account.css (fundo
   --cor-linho-2 + raio + padding, sem borda), fora do território deste
   agente. Como TODOS os CSS do tema carregam em toda página (functions.php,
   eqms_enqueue_assets()), a regra abaixo escrita aqui em checkout.css
   também vale em Minha Conta, sem precisar tocar em my-account.css (ver
   EQMS-TEMA-GUIA-TECNICO.md, seção 3). Só adiciona a borda; não redeclara
   background/border-radius/padding, então não conflita com a regra de
   my-account.css independente da ordem de carregamento. Mesmo token de
   borda do sistema de vidro, sem blur, mesma lógica do #order_review e do
   .cart_totals acima/em cart.css. */
.woocommerce-Address{
    border: 1px solid var(--vidro-borda-escura);
}