/*
Theme Name: Pazpazini
Theme URI: https://pazpazini.com.br
Description: Tema da loja Pazpazini Cutelaria. Tema filho de blocos sobre o Twenty Twenty-Five. Direção "ficha do cuteleiro": branco de bancada, fio de régua, medida tabulada. Paleta extraída das próprias fotos do catálogo.
Author: Pazpazini
Template: twentytwentyfive
Version: 0.1.0
Requires at least: 6.7
Tested up to: 7.0
Requires PHP: 8.0
Text Domain: pazpazini
*/

/* -------------------------------------------------------------------------
   As cores, tamanhos e espaçamentos vivem no theme.json — não repetir aqui.
   Este arquivo trata só do que o theme.json não alcança: as telas do
   WooCommerce, que vêm com CSS próprio de fábrica.
   ---------------------------------------------------------------------- */

:root {
  /* ⚠️ O slug da tinta é `ink`, não `text`, e isso NÃO é cosmético.
     Achado medido em 2026-08-08 ao montar a home: o WordPress gera uma regra
     de preset por slug (`.has-{slug}-color`), e `.has-text-color` é AO MESMO
     TEMPO a classe-marcador que todo bloco com cor de texto personalizada
     recebe. Com um slug chamado `text`, o site ganhava
     `.has-text-color{color:var(--wp--preset--color--text)!important}` —
     ou seja, QUALQUER bloco com cor de texto era forçado para a tinta,
     porque a regra vinha depois e as duas eram `!important` de mesma
     especificidade. Na prática: era impossível pôr texto branco sobre a
     faixa nogueira (2,86 de contraste, reprova AA). Renomear o slug remove
     a colisão. Não use os slugs reservados `text`, `background`, `link` nem
     `border` na paleta. */
  --pz-ink: var(--wp--preset--color--ink);
  --pz-accent: var(--wp--preset--color--accent);
  --pz-rule: var(--wp--preset--color--rule);
  --pz-muted: var(--wp--preset--color--text-secondary);
  --pz-mono: var(--wp--preset--font-family--spec);
  --pz-cond: var(--wp--preset--font-family--display);
}

/* --- Botões ------------------------------------------------------------
   Um só desenho pra todos os botões do WooCommerce. O texto sobre o accent
   é branco POR MEDIDA, não por gosto: #ffffff sobre #7f5b31 dá 6,10 de
   contraste; a tinta #1a1a18 no mesmo fundo dá 2,86 e reprovaria AA.
   (No sistema escuro antigo era o inverso — ver o histórico da direção.) */
.woocommerce a.button,
.woocommerce button.button,
.woocommerce input.button,
.woocommerce #respond input#submit,
.wc-block-components-button {
  background: var(--pz-accent);
  color: #fff;
  border: 1px solid var(--pz-accent);
  border-radius: 2px;
  font-family: var(--pz-cond);
  font-weight: 600;
  letter-spacing: .04em;
  text-transform: uppercase;
  padding: .85em 1.6em;
  transition: background .2s ease, border-color .2s ease;
}

.woocommerce a.button:hover,
.woocommerce button.button:hover,
.woocommerce input.button:hover,
.woocommerce #respond input#submit:hover,
.wc-block-components-button:hover {
  background: var(--wp--preset--color--accent-hover);
  border-color: var(--wp--preset--color--accent-hover);
  color: #fff;
}

/* Secundário: só o fio, pra não competir com o "Comprar". */
.woocommerce a.button.alt-outline,
.woocommerce button.button.alt-outline {
  background: transparent;
  color: var(--pz-accent);
}

/* Foco sempre visível pra quem navega por TECLADO — vale pra todo
   elemento, não só botão.
   `html.pz-kbd` em vez de só `:focus-visible`: achado de João em
   2026-08-12, o `:focus-visible` nativo do Chrome estava acendendo em
   clique de mouse/toque normal (não só Tab) — provável navegação
   client-side reaplicando foco via script depois do clique, que a
   heurística nativa conta como "visível". `html.pz-kbd` é ligada/desligada
   manualmente por JS em functions.php (Tab liga, ponteiro desliga) —
   não depende dessa heurística.
   ⚠️ A primeira regra zera o contorno padrão do navegador em QUALQUER
   `:focus` (não só `:focus-visible`) — achado depois, no menu mobile
   (submenu "Loja" no Safari/iOS): ali o "quadrado" era um selo
   arredondado + sublinhado, diferente do contorno reto medido antes no
   Chrome desktop. Suspeita: o suporte/heurística de `:focus-visible` do
   WebKit é mais permissivo (toque em link conta como foco "visível" ali,
   e o estilo nativo de foco do Safari inclui `text-decoration`, não só
   contorno) — por isso a regra de baixo mira `:focus` puro, que existe em
   qualquer navegador sempre que o elemento tem foco, independente de
   `:focus-visible` bater ou não. `text-decoration: none` cobre o
   sublinhado nativo que o `outline: none` sozinho não tira. A regra de
   `html.pz-kbd`, mais específica, continua religando os dois só pra
   quem navegou de verdade por teclado. */
:where(a, button, input, select, textarea, [tabindex]):focus {
  outline: none;
  text-decoration: none;
}

html.pz-kbd :where(a, button, input, select, textarea, [tabindex]):focus-visible {
  outline: 2px solid var(--pz-accent);
  outline-offset: 2px;
}

/* Quadrado branco/azul ao tocar no celular (achado de João, 2026-08-12) —
   NÃO é o :focus-visible nogueira acima (esse é outra cor e some no
   teclado normalmente). É o realce de toque PADRÃO do navegador
   (`-webkit-tap-highlight-color`), que nunca foi definido neste tema
   (confirmado: zero ocorrências antes desta regra). Medido ao vivo: o
   valor computado em qualquer botão/link é `rgba(0,0,0,.18)` — o padrão do
   Chrome/Safari mobile, um retângulo semitransparente do tamanho exato do
   alvo tocado, batendo com o formato "quadrado" relatado.
   ⚠️ Só afeta o FLASH de toque — propriedade `-webkit-` própria, sem
   nenhuma relação com `:focus`/`:focus-visible`. Não remove foco de
   teclado nem de leitor de tela; mesmo seletor do contorno nogueira acima,
   só pra manter os dois em sincronia caso a lista de elementos mude. */
:where(a, button, input, select, textarea, [tabindex]) {
  -webkit-tap-highlight-color: transparent;
}

/* Dentro de uma faixa nogueira, o contorno nogueira desaparece.
   Medido em 2026-08-08 na home: o `outline-offset: 2px` põe o contorno FORA
   do botão, ou seja, sobre o fundo da faixa — nogueira sobre nogueira dá
   **1,00 de contraste**, um foco invisível para quem navega por teclado
   (WCAG 1.4.11 / 2.4.11). Em branco dá 6,10 contra a mesma faixa.
   ⚠️ Medir contorno pelo fundo do PRÓPRIO elemento engana: o que importa é o
   fundo do pai, porque é lá que o contorno é desenhado. */
html.pz-kbd .has-accent-background-color :where(a, button, .wp-block-button__link):focus-visible {
  outline-color: var(--wp--preset--color--base);
}

/* Alvo de toque dos itens de navegação (cabeçalho e rodapé, do tema pai).
   Medido em 2026-08-08: 26 px de altura no desktop, mas **23 px a 375 px** —
   1 px abaixo do mínimo de 24×24 da WCAG 2.5.8, e vale nas 5 telas porque o
   rodapé é o mesmo. O padding resolve sem mover nada de lugar. */
.wp-block-navigation-item__content { padding-block: 2px; }

/* Mesmo caso, em links pequenos que o WooCommerce emite fora de frase:
   trilha de navegação (`Início / Loja`) e a linha de categoria da ficha do
   produto. Medidos em 2026-08-08: 18 px de altura nas duas.

   ⚠️ QUINTA aparição da armadilha bloco × clássico: a linha de categoria da
   página de produto NÃO é `.product_meta` (clássico) — é
   `.wp-block-woocommerce-product-meta .wp-block-post-terms` (bloco). Mirar só
   no clássico não pegava nada, exatamente como já aconteceu com o preço e com
   o cartão da vitrine. Os dois seletores ficam. */
.woocommerce-breadcrumb a,
.wc-block-breadcrumbs a,
.woocommerce div.product .product_meta a,
.wp-block-woocommerce-product-meta .wp-block-post-terms a {
  display: inline-block;
  padding-block: 4px;
}

/* --- Link "Pular para o conteúdo" --------------------------------------
   Achado da auditoria de 2026-08-07: o link existe e recebe foco, mas fica
   1×1 px com `clip-path: inset(50%)` MESMO no foco — quem navega por teclado
   tabula e não vê onde está. Um pulo de conteúdo invisível é pior que
   nenhum: o foco some da tela. Aqui ele volta a aparecer, só no foco. */
.skip-link:focus,
.skip-link:focus-visible {
  clip: auto !important;
  clip-path: none !important;
  width: auto !important;
  height: auto !important;
  margin: 0 !important;
  top: var(--wp--preset--spacing--20, 1rem) !important;
  left: var(--wp--preset--spacing--20, 1rem) !important;
  z-index: 100000;
  display: block;
  padding: .8em 1.2em;
  background: var(--wp--preset--color--base, #fff);
  color: var(--pz-ink);
  border: 2px solid var(--pz-accent);
  border-radius: 2px;
  font-family: var(--pz-cond);
  font-weight: 600;
  text-decoration: none;
}

/* --- Campos de formulário ----------------------------------------------
   Achado da auditoria de 2026-08-07: os campos de gravação (.wapf-input) e a
   quantidade saíam com o estilo de fábrica do NAVEGADOR — borda
   `2px inset #767676`, corpo 13,3 px e **21 px de altura**. Dois problemas
   somados: quebra visual no meio de uma página tipografada com cuidado, e
   alvo de toque abaixo do mínimo de 24×24 do WCAG 2.5.8. O corpo em 16 px
   também evita o zoom automático do iOS ao focar o campo.
   O plugin de campos não estiliza nada — quem veste é o tema. */
.wapf-input,
.woocommerce .quantity input.qty,
.woocommerce div.product form.cart input[type="text"],
.woocommerce div.product form.cart input[type="number"],
.woocommerce div.product form.cart textarea {
  min-height: 44px;
  padding: .55em .7em;
  font-family: inherit;
  font-size: 16px;
  line-height: 1.4;
  color: var(--pz-ink);
  background: var(--wp--preset--color--base, #fff);
  border: 1px solid var(--pz-rule);
  border-radius: 2px;
  box-shadow: none;
  max-width: 100%;
}

.wapf-input:hover,
.woocommerce .quantity input.qty:hover {
  border-color: var(--pz-muted);
}

.wapf-input::placeholder { color: var(--pz-muted); opacity: 1; }

/* O rótulo do campo de gravação com o mesmo peso dos rótulos da ficha:
   é a mesma família de informação (o que vai gravado na peça). */
.wapf-field-label label {
  font-family: var(--pz-cond);
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: .05em;
  font-size: var(--wp--preset--font-size--small);
  color: var(--pz-muted);
  display: block;
  margin-bottom: .35em;
}

.wapf-field-container { margin-bottom: var(--wp--preset--spacing--30); }

/* --- Alvo de toque: paginação e ordenação ------------------------------
   Achado medido em 2026-08-07: os números da paginação da loja eram links de
   **9×20 px**. Com 101 produtos em 9 páginas, a paginação É a navegação
   principal do catálogo — e estava abaixo do mínimo de 24×24 do WCAG 2.5.8.
   O `select` de ordenação saía com 20 px de altura pelo mesmo motivo. */
.woocommerce nav.woocommerce-pagination a.page-numbers,
.woocommerce nav.woocommerce-pagination span.page-numbers,
.wp-block-query-pagination a.page-numbers,
.wp-block-query-pagination span.page-numbers,
.wp-block-query-pagination-next,
.wp-block-query-pagination-previous,
.wc-block-pagination a,
.wc-block-pagination button {
  min-width: 44px;
  min-height: 44px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 0 .5em;
  font-family: var(--pz-mono);
  font-variant-numeric: tabular-nums;
  text-decoration: none;
  border-radius: 2px;
}

.woocommerce nav.woocommerce-pagination span.page-numbers.current,
.wp-block-query-pagination .page-numbers.current {
  color: var(--pz-ink);
  border-bottom: 2px solid var(--pz-accent);
}

.woocommerce .woocommerce-ordering select,
select.orderby {
  min-height: 44px;
  padding: .4em .6em;
  font-family: inherit;
  font-size: 16px;
  color: var(--pz-ink);
  background: var(--wp--preset--color--base, #fff);
  border: 1px solid var(--pz-rule);
  border-radius: 2px;
  max-width: 100%;
}

/* ⚠️ Regressão do PRÓPRIO tema, achada em 2026-08-08 medindo a /loja/ a
   375 px: o `font-size: 16px` que a auditoria anterior pôs neste `select`
   (para evitar o zoom automático do iOS) fez ele crescer até **306 px** —
   e, como ele é item de um flex row com `min-width: auto`, não encolhia.
   Resultado: `scrollWidth` 414 contra `clientWidth` 375, ou seja, **a loja
   rolava na horizontal no celular**. O `min-width: 0` devolve o direito de
   encolher; `max-width` sozinho não resolve, porque a largura do pai também
   é ditada pelo conteúdo. */
.wc-block-catalog-sorting,
.wc-block-catalog-sorting form,
.woocommerce .woocommerce-ordering {
  min-width: 0;
  max-width: 100%;
}

/* Título do cartão: alvo de toque maior sem mudar o desenho.
   O link tinha 22 px de altura; o padding vertical leva ao mínimo sem
   deslocar nada visualmente (o texto continua onde estava). */
.wc-block-product-template li.wc-block-product .wp-block-post-title a,
.woocommerce ul.products li.product a.woocommerce-loop-product__link {
  display: inline-block;
  padding-block: .35em;
}

/* --- Cartão de produto -------------------------------------------------
   A foto é fundo branco puro (98% do catálogo). Por isso o cartão NÃO tem
   fundo nem borda: a peça pousa direto no papel da página, sem moldura
   visível. O que separa um produto do outro é o fio de baixo, não uma caixa. */
.woocommerce ul.products li.product {
  background: none;
  border: 0;
  padding-bottom: var(--wp--preset--spacing--40);
  border-bottom: 1px solid var(--pz-rule);
  text-align: left;
}

.woocommerce ul.products li.product img {
  mix-blend-mode: multiply; /* mata qualquer resto de branco sujo da foto */
  margin-bottom: var(--wp--preset--spacing--30);
}

.woocommerce ul.products li.product .woocommerce-loop-product__title {
  font-family: var(--pz-cond);
  font-weight: 600;
  font-size: var(--wp--preset--font-size--medium);
  line-height: 1.2;
  color: var(--pz-ink);
}

/* --- Listagem em BLOCO -------------------------------------------------
   A página /loja/ não usa o markup clássico `ul.products li.product`: o
   arquivo é montado pelo bloco Product Collection, que gera
   `ul.wc-block-product-template > li.wc-block-product`. Sem estes seletores
   o cartão fica sem fio separador, a foto sem `multiply` e o preço fora da
   monoespaçada — foi exatamente o que a auditoria de 2026-08-07 pegou.
   Alinhamento NÃO é forçado aqui de propósito: quem define é o bloco
   (`has-text-align-*`), e sobrescrever por CSS faria o editor mentir. */
.wc-block-product-template li.wc-block-product {
  padding-bottom: var(--wp--preset--spacing--40);
  border-bottom: 1px solid var(--pz-rule);
}

.wc-block-product-template li.wc-block-product img {
  mix-blend-mode: multiply;
}

/* --- Cartão de produto: hover premium (2026-08-12) -----------------------
   Elevação + sombra + segunda foto da galeria em fade, só em telas com
   mouse de verdade. `hover:hover` + `pointer:fine` é a mesma condição que
   distingue touch de desktop no resto do projeto — primeira vez usada
   pra isto. Em touch a imagem extra fica `display:none`: nem chega a ser
   renderizada, então o navegador não a baixa.
   Duração .25s ease bate com o resto do hover do site (botões, miniaturas
   da galeria) — não é valor novo. `prefers-reduced-motion` já está coberto
   pela regra global (linha ~986) — nenhuma regra nova precisa disso. */
.wc-block-product-template li.wc-block-product {
  transition: transform .25s ease, box-shadow .25s ease;
}

/* Fundo opaco atrás das duas fotos empilhadas do hover: a foto principal
   (paisagem, ~1024×964) e a de hover (retrato, ~825×1024) têm proporções
   diferentes, e as duas usam `object-fit: contain` (a de hover por CSS
   nossa, a principal por `style=` inline do próprio WooCommerce — não dá
   pra trocar essa, ver armadilha #3). `contain` deixa sobra transparente
   nas bordas quando a proporção não bate com o quadrado 1:1 do contêiner;
   sem fundo aqui, essa sobra deixava a foto de BAIXO (a original) aparecer
   em tiras nas laterais da foto de cima durante o hover — medido ao vivo em
   2026-08-12/13 (foto de hover 825×1024 = ~19px de sobra transparente de
   cada lado dentro do quadrado de ~198px). */
.wc-block-components-product-image {
  position: relative;
  overflow: hidden;
  background: var(--wp--preset--color--base, #fff);
}

.pz-hover-img {
  display: none;
}

/* `mix-blend-mode: multiply` acima existe pra limpar fundo branco sujo
   de UMA foto contra a página — com as duas fotos empilhadas, a de cima
   "multiplicava" com a de baixo em vez de cobri-la, e as duas apareciam
   juntas (efeito fantasma em X). A foto de hover precisa pintar normal
   pra esconder a primeira de verdade quando chega em opacity:1.
   Especificidade maior que a regra de multiply acima de propósito. */
.wc-block-product-template li.wc-block-product .pz-hover-img {
  mix-blend-mode: normal;
}

@media (hover: hover) and (pointer: fine) {
  .wc-block-product-template li.wc-block-product:hover,
  .wc-block-product-template li.wc-block-product:focus-within {
    transform: translateY(-5px);
    box-shadow: 0 16px 28px -18px rgba(26, 26, 24, .35);
  }

  .pz-hover-img {
    display: block;
    position: absolute;
    inset: 0;
    width: 100%;
    aspect-ratio: 1 / 1;
    object-fit: contain;
    opacity: 0;
    transition: opacity .25s ease;
  }

  .wc-block-components-product-image a:hover .pz-hover-img,
  .wc-block-components-product-image a:focus-visible .pz-hover-img {
    opacity: 1;
  }

  /* Pedido de João em 2026-08-13: a foto original tem que SUMIR de
     verdade durante a animação, não só ficar coberta por baixo. Antes só
     a foto de hover ganhava transição de opacidade; a original ficava
     opacity:1 o tempo todo, só escondida por cima — correto no resultado
     final (opacity:1 da foto de hover), mas ela nunca "desaparecia" de
     fato, e qualquer diferença de enquadramento entre as duas fotos podia
     dar a impressão de resíduo. Agora as duas trocam de opacidade juntas
     (crossfade real), não uma cobrindo a outra. */
  .wc-block-components-product-image img:not(.pz-hover-img) {
    transition: opacity .25s ease;
  }

  .wc-block-components-product-image a:hover img:not(.pz-hover-img),
  .wc-block-components-product-image a:focus-visible img:not(.pz-hover-img) {
    opacity: 0;
  }
}

.wc-block-product .wp-block-woocommerce-product-price,
.wc-block-product .woocommerce-Price-amount {
  font-family: var(--pz-mono);
  font-variant-numeric: tabular-nums;
}

/* Preço em algarismo tabular: as colunas de preço alinham na vertical
   quando você corre o olho pela grade.

   ⚠️ Terceira aparição da mesma armadilha (registrada na MEMORIA): existem
   TRÊS markups de preço neste site, e cada um precisa do seu seletor.
   1. clássico  — `p.price` na página de produto antiga;
   2. bloco de cartão — `.wc-block-components-product-price` na /loja/;
   3. bloco de produto/carrinho — `.wp-block-woocommerce-product-price` e
      `.wc-block-components-totals-item__value`, que saíam em Plex Sans com
      algarismo proporcional. Medido em 2026-08-07: o preço da página de
      produto e o total do carrinho estavam FORA da monoespaçada enquanto o
      da vitrine estava dentro — a mesma cifra em duas vozes. */
.woocommerce ul.products li.product .price,
.woocommerce div.product p.price,
.wc-block-components-product-price,
.wp-block-woocommerce-product-price,
.wp-block-woocommerce-product-price .woocommerce-Price-amount,
.wc-block-components-totals-item__value,
.wc-block-components-order-summary-item__total-price,
.wc-block-formatted-money-amount {
  font-family: var(--pz-mono);
  font-variant-numeric: tabular-nums;
  color: var(--pz-ink);
  font-weight: 400;
}

/* --- Loja: grid de 4 colunas no desktop, 2 no mobile --------------------
   `archive-product.html` linha 28 tinha `columns:2` fixo no bloco Product
   Collection — 2 colunas em QUALQUER largura, mesmo no desktop. Mudado pra
   4. Medido ao vivo (2026-08-12): apesar do atributo do bloco dizer
   `"type":"flex"`, o WooCommerce renderiza como CSS GRID nativo
   (`display:grid`), com a contagem de colunas vindo de uma classe estática
   `.wc-block-product-template__responsive.columns-N` — `auto-fill`/`minmax`
   dá alguma responsividade sozinho, mas não o suficiente pra cair a 2
   colunas exatas abaixo do breakpoint de 600px do projeto (ainda mostrava
   3). Por isso o override abaixo é necessário, não redundante.
   Confirmado por inspeção do DOM ao vivo que `pazpazini-style.css` (link)
   carrega DEPOIS do `<style id="woocommerce-product-template-style-inline-
   css">` que o bloco gera — a regra abaixo vence por ordem de cascata, sem
   precisar de `!important`. */
@media (max-width: 600px) {
  .wc-block-product-template__responsive.columns-4 {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

/* --- Produtos relacionados (ficha de produto) ----------------------------
   `templates/single-product.html` (customizado no banco, sem arquivo no
   tema) NÃO usa o markup clássico `.related.products ul.products` — usa o
   MESMO bloco Product Collection da loja, com
   `"collection":"woocommerce/product-collection/related"` e
   `displayLayout:{"type":"flex","columns":5,"shrinkColumns":false}`.
   Confirmado ao vivo (2026-08-12) em `/produto/pedra-de-afiar-carborundum/`:
   `shrinkColumns:false` faz o WooCommerce renderizar como `display:flex`
   PURO (classe `is-flex-container`, não `__responsive` como a grade da
   loja) — cada `<li>` recebe uma LARGURA FIXA em porcentagem
   (`.columns-5 > li{width:calc(20% - 1em)}`), sem `minmax`/piso mínimo e
   sem breakpoint nenhum. Em telas estreitas os 5 cartões de ~20% ficam
   pequenos demais para o conteúdo (foto, título, preço, botão), que
   estoura/quebra visualmente — é isso que aparece como "grande demais" no
   mobile.
   Fix: reaproveita as PRÓPRIAS fórmulas que o WooCommerce já define para
   `columns-3`/`columns-2` (mesmo `calc()`, mesmo gap visual dos outros
   grids do site) e as aplica à configuração de 5 colunas por breakpoint —
   sem inventar valor novo. Repete `.is-flex-container` na especificidade
   pra empatar com a regra de fábrica e vencer por ordem de carregamento
   (confirmado: `pazpazini-style.css` carrega depois do CSS de bloco do
   WooCommerce, mesmo padrão já medido na correção do grid da loja acima). */
@media (max-width: 900px) {
  .wc-block-product-template.is-flex-container.is-flex-container.columns-5 > li {
    width: calc(33.3333% - 0.83333em);
  }
}

@media (max-width: 600px) {
  .wc-block-product-template.is-flex-container.is-flex-container.columns-5 > li {
    width: calc(50% - 0.625em);
  }
}

/* --- A ficha técnica ---------------------------------------------------
   É a assinatura da loja. As concorrentes enterram medida em prosa; aqui
   ela é tabela: rótulo à esquerda em condensada, valor à direita em
   monoespaçada tabular, fio fino entre as linhas. Lê-se como ficha de
   oficina, que é o que é. */
.woocommerce table.shop_attributes {
  border: 0;
  border-top: 2px solid var(--pz-ink);
  margin-top: var(--wp--preset--spacing--30);
}

.woocommerce table.shop_attributes th,
.woocommerce table.shop_attributes td {
  border: 0;
  border-bottom: 1px solid var(--pz-rule);
  padding: .7em 0;
  background: none;
  font-style: normal;
}

.woocommerce table.shop_attributes th {
  font-family: var(--pz-cond);
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: .05em;
  font-size: var(--wp--preset--font-size--small);
  color: var(--pz-muted);
  width: 55%;
}

.woocommerce table.shop_attributes td,
.woocommerce table.shop_attributes td p {
  font-family: var(--pz-mono);
  font-variant-numeric: tabular-nums;
  color: var(--pz-ink);
  text-align: right;
  margin: 0;
}

/* Conjunto lista medida por peça, separada por "·". Quebra em linhas
   próprias no celular pra não virar uma tira ilegível. */
@media (max-width: 600px) {
  .woocommerce table.shop_attributes th,
  .woocommerce table.shop_attributes td {
    display: block;
    width: auto;
    text-align: left;
  }
  .woocommerce table.shop_attributes th { border-bottom: 0; padding-bottom: 0; }
}

/* --- Abas --------------------------------------------------------------
   Sem cara de pasta de arquivo: só rótulo e o fio que marca a ativa. */
.woocommerce div.product .woocommerce-tabs ul.tabs {
  padding: 0;
  margin: 0 0 var(--wp--preset--spacing--30);
  border-bottom: 1px solid var(--pz-rule);
}

.woocommerce div.product .woocommerce-tabs ul.tabs::before { border: 0; }

.woocommerce div.product .woocommerce-tabs ul.tabs li {
  background: none;
  border: 0;
  border-radius: 0;
  margin: 0 var(--wp--preset--spacing--30) 0 0;
  padding: 0;
}

.woocommerce div.product .woocommerce-tabs ul.tabs li::before,
.woocommerce div.product .woocommerce-tabs ul.tabs li::after { display: none; }

.woocommerce div.product .woocommerce-tabs ul.tabs li a {
  font-family: var(--pz-cond);
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: .05em;
  font-size: var(--wp--preset--font-size--small);
  color: var(--pz-muted);
  padding: .6em 0;
  display: block;
  border-bottom: 2px solid transparent;
}

.woocommerce div.product .woocommerce-tabs ul.tabs li.active a {
  color: var(--pz-ink);
  border-bottom-color: var(--pz-accent);
}

/* --- Avisos ------------------------------------------------------------
   Fio grosso à esquerda em vez de caixa colorida: informa sem gritar. */
.woocommerce-message,
.woocommerce-info,
.woocommerce-error {
  background: var(--wp--preset--color--surface);
  border-top: 0;
  border-radius: 0;
  padding: var(--wp--preset--spacing--30);
}

.woocommerce-message { border-left: 3px solid var(--wp--preset--color--success); }
.woocommerce-info    { border-left: 3px solid var(--wp--preset--color--info); }
.woocommerce-error   { border-left: 3px solid var(--wp--preset--color--danger); }

.woocommerce-message::before,
.woocommerce-info::before,
.woocommerce-error::before { display: none; }

/* Miniaturas da galeria: faixa de uma linha, rolável ---------------------
   A imagem principal JÁ é carrossel — o `wc-product-gallery-slider` está
   ligado e o FlexSlider monta os slides. O que estava "solto" era a
   NAVEGAÇÃO: o WooCommerce renderiza as miniaturas como grade de 4 colunas
   flutuadas (`li{width:25%;float:left}`, com `overflow:hidden` na lista).
   Num produto de 19 fotos isso vira um paredão embaixo da peça.

   Medido em `/produto/canivete-nobre/` (19 fotos): **5 linhas, 640 px de
   altura**, `overflow-x: hidden` — a lista crescia para baixo e empurrava a
   ficha técnica para fora da primeira tela.
   Depois, na reprodução fiel a 375 px (mesmas regras de fábrica, container
   de 343 px): **1 linha, 96 px** — `scrollWidth` 1816 contra `clientWidth`
   343, ou seja, a faixa é que rola.

   Três cuidados que a regra resolve de propósito:

   1. `overscroll-behavior-x: contain` — sem isso, chegar ao fim da faixa
      encadeia a rolagem para o documento. Conferido depois de levar a faixa
      ao fim: `scrollX` continua **0** e o documento fica em `scrollWidth` =
      `clientWidth` = **375**. É a mesma classe de defeito que a `/loja/` já
      teve, e por isso `min-width: 0` também entra aqui: `max-width` sozinho
      não segura, porque a largura do pai é ditada pelo conteúdo.

   2. Alvo de toque — a miniatura vira o alvo inteiro, **88×88 px** a 375 px
      (antes 128×128 no desktop, mas espremidas a 86 px em 4 colunas no
      celular). Bem acima do mínimo de 24×24 da WCAG 2.5.8, e a 4ª miniatura
      fica cortada pela metade, que é o sinal de que a faixa rola.

   3. A miniatura ativa **não pode perder a marca**. O FlexSlider põe
      `.flex-active` no `<img>` (não no `<li>` — o controle dele para
      `controlNav: "thumbnails"` é a própria imagem), e de fábrica a marca é
      só `opacity: 1` contra `.5`. Opacidade sozinha é um sinal fraco, então
      entra também um fio accent de 2 px: `rgb(127,91,49)` sobre o branco da
      foto = **6,10 de contraste**. O `outline-offset` é **negativo** de
      propósito — desenha o fio DENTRO da miniatura, sobre o branco da foto;
      positivo ele cairia no vão entre as miniaturas e mudaria a largura da
      faixa.

   ⚠️ A especificidade não é enfeite: as regras de fábrica são
   `.woocommerce div.product div.images .flex-control-thumbs li` (0,4,3) e
   `…--columns-4 .flex-control-thumbs li:nth-child(4n+1)` (0,5,2). Somar
   `.flex-control-nav` ao seletor leva o nosso a **0,5,3** e ganha das duas
   sem depender da ordem de carregamento das folhas.
   (`float` e `clear` das regras de fábrica não são combatidos porque são
   **inertes em item de flex** — o navegador já os ignora.) */
.woocommerce div.product div.images .flex-control-nav.flex-control-thumbs {
  display: flex;
  flex-wrap: nowrap;
  gap: var(--wp--preset--spacing--20, .5rem);
  margin: var(--wp--preset--spacing--20, .5rem) 0 0;
  padding: 0 0 .5rem;
  max-width: 100%;
  min-width: 0;
  overflow-x: auto;
  overflow-y: hidden;
  overscroll-behavior-x: contain;
  scroll-snap-type: x mandatory;
  scrollbar-width: thin;
  scrollbar-color: var(--pz-rule) transparent;
}

.woocommerce div.product div.images .flex-control-nav.flex-control-thumbs li {
  flex: 0 0 auto;
  width: 88px;
  margin: 0;
  scroll-snap-align: start;
}

.woocommerce div.product div.images .flex-control-nav.flex-control-thumbs li img {
  width: 100%;
  min-width: 44px;
  min-height: 44px;
  outline: 2px solid transparent; /* reserva o fio: a ativa só troca a cor */
  outline-offset: -2px;
  transition: opacity .2s ease, outline-color .2s ease;
}

.woocommerce div.product div.images .flex-control-nav.flex-control-thumbs li img.flex-active,
.woocommerce div.product div.images .flex-control-nav.flex-control-thumbs li img:hover {
  opacity: 1;
  outline-color: var(--pz-accent);
}

/* --- Home: índice de categorias ----------------------------------------
   O bloco `woocommerce/product-categories` é a fonte da verdade das 9
   categorias — ele lê a taxonomia, então o catálogo pode mudar sem ninguém
   editar a home. Só que ele sai como uma lista corrida, e a lista corrida não
   é o que a página pede.

   Aqui ela vira índice: três colunas, fio entre as linhas, contagem em
   monoespaçada tabular à direita. É a mesma voz da ficha técnica da página de
   produto — rótulo à esquerda, número à direita, alinhado em coluna.

   O bloco não oferece controle de coluna nenhum (as opções são só contagem,
   imagem, vazias, dropdown e hierarquia), então CSS é o único caminho — não é
   sobrescrita de valor de bloco. */
.pz-categorias ul.wc-block-product-categories-list {
  list-style: none;
  margin: 0;
  padding: 0;
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  column-gap: var(--wp--preset--spacing--50);
  border-top: 1px solid var(--pz-rule);
}

@media (max-width: 900px) { .pz-categorias ul.wc-block-product-categories-list { grid-template-columns: repeat(2, minmax(0, 1fr)); } }
@media (max-width: 600px) { .pz-categorias ul.wc-block-product-categories-list { grid-template-columns: 1fr; } }

/* ⚠️ A contagem é IRMÃ do <a>, não filha — conferido no HTML renderizado:
   `<li><a><span class="…__name">Canivetes</span></a><span class="…-count">…`.
   Por isso quem faz o alinhamento nome-à-esquerda/número-à-direita é o <li>,
   não o link. (E é melhor assim para o leitor de tela: o texto do link fica
   sendo só o nome da categoria.) */
.pz-categorias li.wc-block-product-categories-list-item {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: .75em;
  margin: 0;
  border-bottom: 1px solid var(--pz-rule);
}

.pz-categorias li.wc-block-product-categories-list-item > a {
  flex: 1 1 auto;
  display: flex;
  align-items: center;
  min-height: 44px;
  padding: .7em 0;
  font-family: var(--pz-cond);
  font-weight: 600;
  color: var(--pz-ink);
  text-decoration: none;
}

.pz-categorias li.wc-block-product-categories-list-item > a:hover {
  color: var(--pz-accent);
  text-decoration: underline;
}

.pz-categorias .wc-block-product-categories-list-item-count {
  font-family: var(--pz-mono);
  font-variant-numeric: tabular-nums;
  color: var(--pz-muted);
  font-size: var(--wp--preset--font-size--small);
}

/* --- Loja: sidebar de categorias (archive-product.html) -----------------
   Mesmo bloco `woocommerce/product-categories` da home (".pz-categorias"
   acima), aqui é navegação entre páginas de categoria, não índice — por
   isso sem contagem e em coluna única. A classe `pz-categorias-sidebar` já
   vinha gravada no bloco (templates/archive-product.html), sem CSS.

   O título "Categorias" é um <h3> irmão do bloco dentro da mesma coluna de
   25%, não filho de `.pz-categorias-sidebar` — o card usa `:has()` pra
   pegar a coluna inteira (título + lista) sem editar o template. */
.wp-block-column:has(> .pz-categorias-sidebar) {
  background: var(--wp--preset--color--base, #fff);
  border: 1px solid var(--pz-rule);
  border-radius: 6px;
  padding: 1.35em 1.5em 1.15em;
  align-self: flex-start;
}

.wp-block-column:has(> .pz-categorias-sidebar) > .wp-block-heading {
  margin: 0 0 .75em;
  font-family: var(--pz-cond);
  font-size: var(--wp--preset--font-size--small);
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: .08em;
  color: var(--pz-muted);
}

.pz-categorias-sidebar ul.wc-block-product-categories-list {
  list-style: none;
  margin: 0;
  padding: 0;
}

.pz-categorias-sidebar li.wc-block-product-categories-list-item {
  margin: 0;
  border-bottom: 1px solid var(--pz-rule);
}

.pz-categorias-sidebar li.wc-block-product-categories-list-item:last-child {
  border-bottom: none;
}

.pz-categorias-sidebar li.wc-block-product-categories-list-item > a {
  display: flex;
  align-items: center;
  min-height: 44px;
  padding: .5em 0;
  font-family: var(--pz-cond);
  font-weight: 500;
  color: var(--pz-ink);
  text-decoration: none;
  line-height: 1.3;
}

.pz-categorias-sidebar li.wc-block-product-categories-list-item > a:hover {
  color: var(--pz-accent);
}

/* Navegação entre páginas, não filtro — a contagem some, só o nome fica. */
.pz-categorias-sidebar .wc-block-product-categories-list-item-count {
  display: none;
}

/* Categoria ativa: body-class nativa `term-<slug>` que o WordPress gera em
   toda página de taxonomia (body_class()) — zero JS, zero PHP novo. Cor +
   peso juntos, não só o fio de baixo contraste (--pz-rule). */
body.term-canivetes .pz-categorias-sidebar a[href$="/canivetes/"],
body.term-conjuntos .pz-categorias-sidebar a[href$="/conjuntos/"],
body.term-diversos .pz-categorias-sidebar a[href$="/diversos/"],
body.term-encartelados .pz-categorias-sidebar a[href$="/encartelados/"],
body.term-estojos .pz-categorias-sidebar a[href$="/estojos/"],
body.term-facas-em-bainha .pz-categorias-sidebar a[href$="/facas-em-bainha/"],
body.term-grelhas-espetos .pz-categorias-sidebar a[href$="/grelhas-espetos/"],
body.term-linha-nobre .pz-categorias-sidebar a[href$="/linha-nobre/"],
body.term-tabuas .pz-categorias-sidebar a[href$="/tabuas/"] {
  color: var(--pz-accent);
  font-weight: 700;
}

/* --- Loja: sidebar de categorias — mobile/tablet -------------------------
   781px é o breakpoint REAL onde o `wp:columns` de 25/75 empilha (regra
   nativa do core: `.wp-block-columns:not(.is-not-stacked-on-mobile) >
   .wp-block-column { flex-basis:100% }` em `max-width:781px`, conferido ao
   vivo em 2026-08-11 — não é o breakpoint de 900px do projeto, que não
   governa este bloco). Abaixo dele a coluna da sidebar já fica sozinha
   acima da grade, então é aqui que a lista vertical vira faixa horizontal —
   mesmo padrão já usado nas miniaturas da galeria de produto (`overflow-x:
   auto` + `scroll-snap` + `scrollbar-color`, ver `.flex-control-thumbs`
   acima), inclusive o `min-width:0` que evita o mesmo vazamento horizontal
   documentado no <select> da ordenação. */
@media (max-width: 781px) {
  .wp-block-column:has(> .pz-categorias-sidebar) {
    padding: 1em 1.25em .9em;
  }

  .pz-categorias-sidebar ul.wc-block-product-categories-list {
    display: flex;
    flex-wrap: nowrap;
    gap: 1.5em;
    max-width: 100%;
    min-width: 0;
    overflow-x: auto;
    overflow-y: hidden;
    overscroll-behavior-x: contain;
    scroll-snap-type: x proximity;
    scrollbar-width: thin;
    scrollbar-color: var(--pz-rule) transparent;
    padding-bottom: .35em;
  }

  .pz-categorias-sidebar li.wc-block-product-categories-list-item {
    flex: 0 0 auto;
    border-bottom: none;
    scroll-snap-align: start;
  }

  .pz-categorias-sidebar li.wc-block-product-categories-list-item > a {
    white-space: nowrap;
    padding: .5em 0;
  }
}

/* Link que é o único conteúdo do parágrafo — não vale a exceção "inline" da
   WCAG 2.5.8, porque não está dentro de uma frase. Medido: 105×20 px, abaixo
   do mínimo de 24×24. O padding vertical resolve sem deslocar o texto. */
.pz-link-alvo a {
  display: inline-block;
  padding-block: .35em;
}

/* Botão invertido da faixa nogueira (fundo papel, texto nogueira).
   As classes de preset do WordPress carregam `!important`, então o hover de
   cor do theme.json não vence — sem isto o botão não daria retorno nenhum ao
   passar o mouse. O sublinhado resolve sem inventar par de cor novo. */
.wp-block-button__link.has-base-background-color:hover,
.wp-block-button__link.has-base-background-color:focus-visible {
  text-decoration: underline;
}

/* --- Mercado Pago: contraste do link de privacidade --------------------
   Achado da auditoria de 2026-08-07 e reconfirmado hoje com valor computado:
   o link "como cuidamos da sua privacidade" sai em `rgb(52,131,250)` sobre
   branco a 12 px = **3,64 de contraste**, abaixo do mínimo de 4,5 (WCAG
   1.4.3). O accent do tema dá **6,10** no mesmo fundo.

   O sublinhado NÃO é enfeite e entra junto por necessidade: sem ele, o único
   sinal de que ali há um link é a cor — e o accent contra o texto ao redor
   (`rgba(0,0,0,.898)`) dá só **2,86**, abaixo dos 3,0 que a WCAG 1.4.1 exige
   quando a cor é o único sinal. Trocar a cor sem sublinhar consertaria 1.4.3
   e quebraria 1.4.1.

   Isto é CSS de aparência dentro do painel do Mercado Pago. Não toca
   credencial, conta, webhook, modo teste nem nenhum campo de pagamento.

   ⚠️ O `!important` aqui é necessário, não preguiça — medido no navegador: a
   regra do Mercado Pago vem de uma folha EXTERNA
   (`http2.mlstatic.com/.../super-token.bundle.min.css`) e já usa
   `!important`. Testado na página: seletor com id (`#mp-checkout-custom-root
   …`, especificidade maior) **perde**; só `!important` vence. Como a folha é
   de outro domínio, não dá nem pra ler a regra — é o único caminho. */
.mp-checkout-container .mp-privacy-policy-footer a {
  color: var(--pz-accent) !important;
  text-decoration: underline !important;
}

/* --- Mercado Pago: ícone do banner "Modo Teste" (achado novo da Fase 7,
   2026-08-08) -------------------------------------------------------------
   Medido no checkout: div.mp-test-mode-badge (círculo laranja com "!") sai em
   texto branco sobre rgb(255,119,51) = 2,65 de contraste, abaixo do mínimo
   (4,5 texto / 3,0 ícone, WCAG 1.4.3/1.4.11). O fundo laranja é mantido — é o
   sinal visual de "Modo Teste" do próprio Mercado Pago; só o glifo muda para a
   tinta do tema, testada ao vivo em ~6,6:1.

   ⚠️ !important necessário pelo mesmo motivo do link de privacidade acima: a
   regra de origem (mp-plugins-components.min.css) já usa !important em toda
   propriedade; testado ao vivo, sem !important perde. */
.mp-checkout-container .mp-test-mode-badge {
  color: var(--pz-ink) !important;
}

/* --- Mercado Pago: asterisco de campo obrigatório (achado novo da Fase 7,
   2026-08-08) -------------------------------------------------------------
   Os 7 <b style="color:red">*</b> do formulário de cartão (Número do cartão,
   Nome do titular, Vencimento, Código de segurança, Documento do titular,
   Banco emissor, Parcelas) saem em rgb(255,0,0) sobre branco = 4,00, abaixo do
   mínimo 4,5 (WCAG 1.4.3). Conferido: são os ÚNICOS <b> dentro do container, o
   seletor não pega nada além dos asteriscos.

   ⚠️ !important necessário: o vermelho vem de style="color:red" inline em cada
   <b>, que vence qualquer regra de folha sem !important — testado ao vivo. */
.mp-checkout-container b {
  color: var(--wp--preset--color--danger) !important;
}

/* --- Calculadora de Frete BR: checkbox "S/N" (achado novo da Fase 7,
   2026-08-08) -------------------------------------------------------------
   O rótulo que envolve #wc-shipping-better-checkbox mede 45×19 px de alvo de
   toque, abaixo do mínimo 24×24 (WCAG 2.5.8). Ele fica centralizado
   (position:absolute + translate(-50%,-50%)) dentro de um overlay 84×50 —
   sobra de espaço confirmada, o crescimento não colide com nada ao lado. */
.wc-better-number-sn-label {
  min-width: 24px;
  min-height: 24px;
}

/* --- Checkout: botão remover cupom (achado novo da Fase 7, 2026-08-08) ---
   No Carrinho o mesmo botão já mede 24×24 (passa); no Checkout mede 16×16,
   abaixo do mínimo (WCAG 2.5.8). Escopado só ao Checkout pra não arriscar
   mudar o que já está certo no Carrinho. */
.woocommerce-checkout .wc-block-components-chip__remove {
  min-width: 24px;
  min-height: 24px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

/* --- Rodapé: links de Instagram e WhatsApp ------------------------------
   Vivem lado a lado dentro do template part `pazpazini//footer`, mesma
   classe compartilhada — alvo de toque de 44px (WCAG 2.5.8), cor de hover
   herdada do accent do tema. O ícone é sempre decorativo (aria-hidden); o
   texto visível ao lado carrega o nome acessível. */
.pz-social-link {
  display: inline-flex;
  align-items: center;
  gap: .4em;
  min-height: 44px;
  color: var(--pz-muted);
  font-size: var(--wp--preset--font-size--small);
  text-decoration: underline;
}

.pz-social-link:hover,
.pz-social-link:focus-visible {
  color: var(--pz-accent);
}

.pz-social-icon {
  flex: none;
}

/* Cor de marca só no ícone do WhatsApp, que é decorativo (aria-hidden) — ver
   a nota de contraste no template part sobre por que o texto não usa este
   verde. */
.pz-whatsapp-icon {
  color: var(--wp--preset--color--whatsapp);
}

/* --- Rodapé: redesign de 4 colunas (2026-08-11) -------------------------
   Institucional / Políticas / Atendimento / Compra, reaproveitando
   .pz-social-link/.pz-social-icon já existentes (WhatsApp/Instagram/
   Facebook/E-mail) — só o layout de colunas e o título de coluna são
   novos. Breakpoints seguem o padrão já usado no arquivo (900px/600px). */
.pz-footer-tagline {
  max-width: 40ch;
}

.pz-footer-columns {
  gap: var(--wp--preset--spacing--60, 40px) var(--wp--preset--spacing--40, 24px);
}

.pz-footer-col {
  flex: 1 1 180px;
  min-width: 160px;
}

.pz-footer-heading {
  margin: 0 0 var(--wp--preset--spacing--10, 8px);
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: 0.04em;
  color: var(--pz-ink);
}

.pz-footer-col a {
  color: var(--pz-muted);
  text-decoration: none;
  transition: color var(--transition-fast, .2s);
}

.pz-footer-col a:hover,
.pz-footer-col a:focus-visible {
  color: var(--pz-accent);
  text-decoration: underline;
}

/* Divisor discreto separando a barra inferior da área principal — mesma
   cor de "fio de régua" já usada no drawer do menu mobile. */
.pz-footer-bottom {
  margin-top: var(--wp--preset--spacing--40, 24px);
  padding-top: var(--wp--preset--spacing--20, 16px);
  border-top: 1px solid var(--wp--preset--color--rule, #e5e3df);
  color: var(--pz-muted);
}

/* Tablet: evita coluna comprimida numa linha só — reflui pra 2x2. */
@media (max-width: 900px) {
  .pz-footer-col {
    flex: 1 1 45%;
  }
}

/* Mobile: pilha vertical, ordem de leitura já é a do DOM (logo → frase →
   Institucional → Políticas → Atendimento → Compra → barra inferior). */
@media (max-width: 600px) {
  .pz-footer-columns {
    flex-direction: column;
  }

  .pz-footer-col {
    flex: 1 1 100%;
    min-width: 0;
  }

  .pz-footer-bottom {
    flex-direction: column;
    align-items: flex-start;
  }
}

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: .01ms !important;
    transition-duration: .01ms !important;
    scroll-behavior: auto !important;
  }
}

/* --- Topo da home: logo do header + faixa branca antes do hero
   (2026-08-09) -------------------------------------------------------------
   Medido ao vivo: logo com 24,96px de altura num header de 72px (alinhamento
   vertical já correto, só o tamanho é discreto) e uma faixa branca de 24px
   entre o cabeçalho e o hero, causada pelo `margin-block-start` que o
   `theme.json` (`styles.spacing.blockGap`) aplica a todo bloco de nível raiz
   depois do primeiro — `<main>` é o segundo filho de `.wp-site-blocks` e
   herda esse respiro. Zerado só em `main.pz-home` (só a home usa essa
   classe) pra não mexer no blockGap global, usado em outras páginas. */
.pz-header-brown .wp-block-site-logo img {
  height: 40px;
  width: auto;
}
@media (max-width: 600px) {
  .pz-header-brown .wp-block-site-logo img {
    height: 32px;
  }
}

main.pz-home {
  margin-block-start: 0;
}

/* --- Faixa branca acima do cabeçalho, em QUALQUER página (2026-08-12) ---
   Causa DIFERENTE da faixa entre header/hero na home acima, embora mesma
   família (blockGap). Medido ao vivo via `getBoundingClientRect`: o próprio
   `<header>` tem `margin-block-start: 0` — quem recebe os 24px do blockGap
   (`:root :where(.is-layout-flow) > *`) é o `<div class="wp-block-group…">`
   DENTRO de `.pz-header-brown` que carrega o conteúdo real (logo, menu,
   carrinho). A regra que zera o primeiro filho
   (`:root :where(.is-layout-flow) > :first-child`) não pega esse `<div>`
   porque o WordPress imprime um `<style>` (CSS de escopo do próprio bloco)
   como IRMÃO ANTERIOR dele dentro de `.pz-header-brown` — invisível
   (`display:none`), mas ainda assim conta para `:first-child` em CSS, que
   olha a árvore do DOM, não o que é renderizado. Resultado: o `<div>` de
   conteúdo perde a isenção e ganha 24px de `margin-block-start`, que colapsa
   através de `.pz-header-brown`/`header`/`.wp-site-blocks`/`<body>` — todos
   sem padding/borda — até encostar no topo real da página.
   Confirmado que NÃO é exclusivo de admin logado: a folha
   `admin-bar-inline-css` (que soma os 32px da barra) só é enfileirada
   quando a admin bar aparece, mas o colapso do `<div>` interno independe
   disso — o mesmo vão de 24px aparece para qualquer visitante, deslogado
   inclusive, só que medido a partir do topo real (y=0) em vez de y=32.
   Escopado só ao `<div>` de dentro do cabeçalho — não mexe no blockGap
   global (`:root :where(.is-layout-flow) > *`), que segue certo em
   qualquer outro lugar do site. */
.pz-header-brown > .wp-block-group {
  margin-block-start: 0;
}

/* --- Menu mobile: hierarquia visual entre "Loja" e as 9 categorias
   (2026-08-09) -------------------------------------------------------------
   Medido ao vivo: no drawer (`.wp-block-navigation__responsive-container`),
   "Loja", as 9 categorias filhas e "Quem Somos" saem com o mesmo
   `font-size`/`font-weight` — só 16px de recuo separa pai de filho,
   insuficiente sozinho. Reaproveita o mesmo padrão "eyebrow" (uppercase,
   letter-spacing, cor text-secondary) já usado no resto do site, em vez de
   inventar um novo.

   ⚠️ Achado em 2026-08-09, depois de aplicar: `.wp-block-navigation__
   responsive-container` NÃO é exclusivo do drawer mobile — é o wrapper que
   existe no DOM em qualquer largura, também por trás do "Loja" inline do
   desktop. Sem escopo, a borda/negrito vazava pro desktop (achado por João,
   "LOJA" com um traço embaixo que não deveria estar ali). O que distingue de
   fato o drawer mobile ABERTO é a classe `.is-menu-open`, que o próprio bloco
   de Navegação só adiciona quando o hambúrguer é clicado — por isso o escopo
   correto exige essa classe, não só o container. */
.wp-block-navigation__responsive-container.is-menu-open
  li.wp-block-navigation-item.has-child > a.wp-block-navigation-item__content {
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: 0.04em;
  font-size: 0.875rem;
}

.wp-block-navigation__responsive-container.is-menu-open
  .wp-block-navigation-submenu .wp-block-navigation__submenu-container
  a.wp-block-navigation-item__content {
  font-size: 0.9375rem;
  color: var(--wp--preset--color--text-secondary, #5c5a54);
  padding-left: 32px;
}

.wp-block-navigation__responsive-container.is-menu-open
  li.wp-block-navigation-item.has-child {
  border-bottom: 1px solid var(--wp--preset--color--rule, #e5e3df);
  padding-bottom: 8px;
  margin-bottom: 8px;
}

/* --- "Navegue por categoria": corte na rolagem horizontal (2026-08-12) ---
   Esta seção (`.pz-cat-nav`) não existe no repo — foi customizada direto no
   banco pelo Editor do Site (ver armadilha #17), então a regra abaixo tem
   que ganhar por especificidade (duas classes), não por ordem no arquivo.
   Medido ao vivo em tela estreita: `.pz-cat-nav__list` tem `scrollWidth`
   918px contra `clientWidth` 737px — os últimos círculos ficam fora da
   área visível. A barra de rolagem está escondida de propósito
   (`scrollbar-width:none`), então o corte parecia quebrado, sem nenhum
   sinal de que dá pra arrastar.
   ⚠️ Achado em 2026-08-13: sem `mask-repeat:no-repeat`, a propriedade
   fica no padrão do navegador (`repeat`) e o degradê não renderiza como
   uma faixa lisa — medido ao vivo numa janela de 500px, corte quase seco
   na borda. Ver armadilha #26.
   ⚠️ Segundo achado em 2026-08-13, corrigindo a frase "que já funciona
   (scroll-snap)" acima: **não existia scroll-snap nenhum na lista viva**
   (`getComputedStyle`/CSSOM conferidos ao vivo, nem `scroll-snap-type` no
   `__list` nem `scroll-snap-align` no `__item`). Sem isso, a rolagem para
   em qualquer posição, inclusive no meio de um círculo — a MOLDURA inteira
   fica cortada pela metade, não só a foto dentro dela (João corrigiu o
   diagnóstico: não é a foto que precisa encolher, é o círculo que não pode
   parar cortado). Corrigido abaixo com `scroll-snap-type`/`-align`.
   ⚠️ 2026-08-13 (sessão mobile/frete): o `mask-image` de degradê na borda
   direita foi removido a pedido do João — borrava o último ícone visível.
   O `scroll-snap` sozinho já resolve o corte de verdade. */
@media (max-width: 900px) {
  .pz-cat-nav .pz-cat-nav__list {
    scroll-snap-type: x mandatory;
  }

  .pz-cat-nav__item {
    scroll-snap-align: start;
  }
}

/* --- Barra de busca no header (2026-08-13) -------------------------------
   Bloco nativo do WooCommerce "Pesquisar produto" (serializa como
   `core/search` com `query.post_type=product`) inserido entre a logo e o
   grupo de Navegação/conta/carrinho. Vem por padrão em formato pílula
   (border-radius:50px) com botão dimensionado pra texto — grande demais
   depois de virar ícone-only (`buttonUseIcon`, a pedido de João). Reestilizado
   seguindo a mesma convenção de campo já usada no tema (ver `.wapf-input`
   acima): altura, padding, borda, radius, cores `--pz-*`.
   O espaçamento entre logo/campo e campo/menu já sai equilibrado do
   `justify-content:space-between` nativo do grupo flex de 3 filhos do
   header — não precisa de centralização manual. */
.pz-header-brown .wp-block-search__input {
  min-height: 44px;
  padding: .55em .7em;
  font-family: inherit;
  font-size: 16px;
  color: var(--pz-ink);
  background: var(--wp--preset--color--base, #fff);
  border: 1px solid var(--pz-rule);
  border-radius: 2px;
  box-shadow: none;
}

.pz-header-brown .wp-block-search__input::placeholder {
  color: var(--pz-muted);
  opacity: 1;
}

.pz-header-brown .wp-block-search__button {
  min-height: 44px;
  min-width: 44px;
  padding: 0 .7em;
  border-radius: 2px;
}

.pz-header-brown .wp-block-search__button svg {
  width: 20px;
  height: 20px;
}

/* Mobile (mesmo corte de 600px do logo, acima): a barra colapsa num ícone
   de lupa — campo de texto zera largura/opacidade/borda, só o botão fica
   visível. Tocar/focar no botão expande (classe `.pz-search-expanded` no
   `form.wp-block-search`, alternada pelo JS em `functions.php`); perder o
   foco com o campo vazio recolhe de novo.

   2026-08-13 — Correção de bug: a expansão original crescia *dentro do
   próprio fluxo flex* do header (`width:0→40vw`, espremida entre logo e
   menu), sem espaço sobrando, sobrepondo a logo. Ao expandir, o
   `.wp-block-search__inside-wrapper` (que contém input E botão — os dois se
   movem juntos, não é bug) sai do fluxo e vira um painel ancorado à
   direita, abaixo do header, sem disputar espaço com a logo.

   2026-08-13 — Segunda correção: a primeira tentativa usava
   `position:absolute; top:100%`, contando com o `<header>` (já
   `position:sticky`) como "ancestral posicionado". Funciona parado, mas
   João reportou ao vivo que ao rolar a página o painel não acompanha o
   header grudado — inconsistência real de motor de renderização (nem
   todo navegador atualiza o *containing block* de um `position:absolute`
   junto com o offset "grudado" de um ancestral `sticky`). Troca:
   `position:fixed` (sempre relativo à viewport, imune a esse problema —
   é exatamente por isso que o header em si consegue ficar "grudado" com
   `position:sticky`), com `top: var(--pz-header-h)`, uma variável CSS
   que o JS abaixo mede da altura REAL do header (`getBoundingClientRect
   ().bottom`, já inclui padding, conteúdo mais alto da linha e o offset
   da admin bar do WordPress quando presente — sem precisar cravar nenhum
   valor à mão). Fallback de 76px (16px de padding + 44px do alvo de
   toque do botão + 16px de padding, ver `--wp--preset--spacing--30` e
   `.wp-block-search__button{min-height:44px}` acima) só para o instante
   entre o CSS carregar e o JS rodar — na prática nunca chega a aparecer,
   porque expandir o painel já depende do mesmo JS ter carregado.

   2026-08-13 — Terceira correção: João reportou "bug no header" ao abrir a
   busca. Causa 1, achada inspecionando ao vivo (Claude in Chrome, viewport
   mobile): mover o `.wp-block-search__inside-wrapper` inteiro pro painel
   `position:fixed` tira TANTO o input QUANTO o botão do fluxo do header de
   uma vez — a lupa simplesmente some do lugar de sempre por um instante
   (o `justify-content:space-between` não fecha o buraco, só deixa um vão
   vazio ali), o que lê como algo quebrado, não como uma transição. Causa
   2: o `width` do input tentava fazer transição (`0→100%`) no MESMO
   instante em que a posição do ancestral virava `fixed` — `position` não
   anima suavemente entre navegadores, e a combinação com a transição de
   `width` produzia um salto visível.
   Correção: só o `.wp-block-search__input` vira `position:fixed` ao
   expandir — o botão (lupa) e o `inside-wrapper` NUNCA saem do fluxo,
   ficam exatamente onde sempre estiveram, visíveis o tempo todo (resolve
   a causa 1). A transição do estado colapsado passa a animar só
   `opacity` (não mais `width`/`padding`) — o salto de posição/largura
   agora acontece "escondido" atrás do fade, em vez de tentar (e falhar)
   animar os dois ao mesmo tempo (resolve a causa 2). O campo, já sem o
   botão dentro do painel, ganha a própria borda/fundo/sombra (antes
   vinham do wrapper). */
@media (max-width: 600px) {
  .pz-header-brown .wp-block-search__inside-wrapper {
    display: flex;
    align-items: center;
  }

  .pz-header-brown .wp-block-search__input {
    width: 0;
    min-width: 0;
    padding: 0;
    border: none;
    opacity: 0;
    transition: opacity .15s ease;
  }

  .pz-header-brown .wp-block-search.pz-search-expanded .wp-block-search__input {
    position: fixed;
    top: var(--pz-header-h, 76px);
    right: 0;
    width: min(85vw, 360px);
    min-width: 0;
    max-width: none;
    z-index: 60;
    opacity: 1;
    padding: .55em .7em;
    border: 1px solid var(--pz-rule);
    background: var(--wp--preset--color--base, #fff);
    box-shadow: 0 4px 12px rgba(0, 0, 0, .15);
    animation: pz-search-panel-in .2s ease-out;
  }

  @keyframes pz-search-panel-in {
    from { opacity: 0; transform: translateX(16px); }
    to   { opacity: 1; transform: translateX(0); }
  }
}

/* --- Item 4 do plano de 2026-08-13 (passada geral de mobile) -----------
   Varredura via Playwright em 375px e 414px (home, /loja/, produto,
   carrinho): sem overflow horizontal em nenhuma página (`scrollWidth`
   bateu com `innerWidth` nos 8 casos — as listas de categoria/produto que
   "vazam" da tela são carrosséis com `overflow-x` próprio, de propósito,
   não bug). Achado real: alvos de toque abaixo de 44px (WCAG 2.5.8) em
   ícones acionáveis que o tema ainda não tinha estilizado — o padrão de
   44px já existia pro botão de busca e campos de formulário, só não tinha
   chegado nesses. Texto corrido (rodapé, breadcrumb) fica de fora — link
   dentro de frase é isento da mesma regra.

   ⚠️ Correção 2026-08-13, achada por João no desktop (ícones do cabeçalho
   desalinhados). Duas rodadas de correção nesta mesma sessão, a segunda
   corrigindo o diagnóstico da primeira — histórico abaixo porque explica
   por que o CSS ficou do jeito que ficou.

   (1) Causa real nº 1: faltava `box-sizing:border-box` no ícone de conta.
   O `.wc-block-customer-account__link` (link `<a>`, não passa pelo reset
   do WooCommerce) usa `content-box` por padrão — o `min-height/min-
   width:44px` virou só o miolo, e os ~15,7px de padding (7,86px por lado)
   somaram POR CIMA, inchando a caixa real pra ~59,7×59,7px. Hambúrguer e
   carrinho já eram `border-box` de fábrica (blocos nativos do Woo/
   Gutenberg resetam isso), por isso só o ícone de conta destoava. Medido
   ao vivo: hambúrguer/carrinho em 44×44px exatos, conta em 59,68×59,68px,
   antes da correção. Essa parte do fix (regra abaixo, sem media query)
   está correta e vale em qualquer largura.

   (2) Causa real nº 2 (achada só depois, numa 2ª rodada — a 1ª tentativa
   de correção tentou reposicionar o ☰ com `position:absolute` dentro do
   `<nav>`, e foi revertida): João esclareceu que o ☰ é **exclusivo do
   mobile** — não deveria aparecer no desktop de jeito nenhum, já que o
   desktop já mostra o menu inline "Loja / Quem Somos / Contato / Brindes
   Corporativos" por extenso. O WordPress core já esconde esse botão acima
   do breakpoint responsivo do bloco de Navegação (`display:none` embutido
   no `<style>` que o próprio bloco imprime) — a regra de alvo de toque
   abaixo, ao aplicar `display:inline-flex` SEM media query, sobrescrevia
   esse `display:none` do core e fazia o ☰ aparecer também no desktop,
   onde ele brigava por espaço com o menu inline (o menu quebrava pra uma
   segunda linha por baixo do botão, ver histórico do commit anterior se
   precisar dos detalhes de medição). Correção final: o alvo de toque do
   ☰ só se aplica dentro de `@media (max-width:600px)` (mesmo corte de
   mobile usado no resto do arquivo) — no desktop o `display:none` nativo
   do core volta a valer, e o ☰ simplesmente não aparece lá, resolvendo o
   desalinhamento na raiz (não tem mais os dois elementos disputando a
   mesma linha). */
.pz-header-brown .wc-block-customer-account__link,
.pz-header-brown .wc-block-mini-cart__button {
  box-sizing: border-box;
  min-width: 44px;
  min-height: 44px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

@media (max-width: 600px) {
  .pz-header-brown .wp-block-navigation__responsive-container-open {
    box-sizing: border-box;
    min-width: 44px;
    min-height: 44px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
  }
}

.woocommerce-product-gallery__trigger {
  box-sizing: border-box;
  min-width: 44px;
  min-height: 44px;
}

.wc-block-components-quantity-selector__button,
.wc-block-cart-item__remove-link {
  /* Só min-height: em 375px o carrinho é uma tabela apertada
     (imagem+nome+preço); dar min-width:44px também empurrava a tabela
     10px pra fora da tela (achado ao rodar a varredura de novo depois do
     primeiro ajuste). Sem largura mínima extra o toque vertical já
     melhora bastante nessa linha compacta, sem quebrar layout. */
  box-sizing: border-box;
  min-height: 44px;
}