/* ============================================================================
   DIVERGENCIAS RESPECTO A LA LIBRERÍA DE COMPONENTES
   ----------------------------------------------------------------------------
   Se carga DESPUÉS de componentes.css y home.css.

   Este archivo existe para no editar esas dos hojas: las entrega diseño y ya se
   han reentregado una vez. Cualquier cambio escrito allí desaparecería en la
   siguiente entrega sin que nadie se entere.

   Hay dos clases de bloque, y cada uno dice cuál es:

     · CORRECCIÓN — la librería hace algo que no funciona. Se borra cuando lo
       arreglen aguas arriba.
     · CAMBIO PEDIDO — la librería funciona, pero el diseño acordado pide otra
       cosa. Se borra cuando lo incorporen a la hoja original.

   REGLA: cada bloque dice qué cambia, por qué, y cuándo se puede borrar. Si no
   se puede escribir esa frase, el estilo no va aquí — va en el componente.
   ========================================================================= */

/* ---------------------------------------------------------------------------
   H1 de la portada · tipografía mixta — CAMBIO PEDIDO, no corrección
   ---------------------------------------------------------------------------
   home.css define .c-shout entero en MyPro, peso medio y MAYÚSCULAS. El diseño
   nuevo del H1 pide justo lo contrario, mezclando dos familias en el mismo
   titular:

       bold   → MyPro, MAYÚSCULAS       («CALMA ES SABER»)
       normal → GPro, caja normal        («que hay un centro de…»)
       italic → GPro cursiva             («online»)

   Así que aquí se invierte la base y se define qué hace cada énfasis.

   Se apoya en <strong> y <em> y no en clases sueltas por dos razones:

   · Es lo que genera Ctrl+B y Ctrl+I en el editor, así que la clienta mueve el
     énfasis sin tocar código ni acordarse de ninguna clase.
   · La cadena traducible lleva el marcado dentro, de modo que en inglés o
     catalán el bold puede caer sobre otras palabras: el orden no es el mismo.

   Las mayúsculas van por text-transform y no escritas en el texto: el contenido
   se queda en caja normal para el editor, para el traductor y para los lectores
   de pantalla, que con texto en versales a veces deletrean palabra por palabra.

   ⚠️ EL PESO SE QUEDA EN 400, TAMBIÉN EN EL «BOLD».

   <strong> aquí no quiere decir «más grueso»: quiere decir OTRO TRATAMIENTO
   —otra familia y otra caja—. Subir el peso además de cambiar de familia
   ensuciaría el contraste entre las dos, que es de lo que vive el titular. El
   negrita del editor es solo la forma de marcarlo, no una instrucción sobre el
   grosor de la letra.

   Esto convive con la regla de theme.json `strong, b { font-weight: 500 }`, que
   sigue valiendo para el TEXTO CORRIDO: ahí <strong> sí es énfasis y 500 es el
   único peso más grueso que existe en el sistema. Dentro de un heading manda la
   regla de abajo, que es más específica.

   El mismo trato vale para BLOCKQUOTE: en este sitio un titular y una cita se
   comportan igual, y así una cita destacada puede mezclar las dos familias sin
   necesitar reglas propias.

   La base en GPro aplica a TODOS los .c-shout desde 2026-08-16. Antes estaba
   acotada al H1 porque no había confirmación de si los demás titulares debían
   comportarse igual; las capturas del diseño de servicios («BUSCANDO LA CALMA /
   en cada momento de tu vida») y del primer paso («EL PRIMER PASO, / con calma»)
   lo confirman.

   BORRAR cuando home.css lo incorpore.
   ------------------------------------------------------------------------- */

/* Base de TODOS los titulares de display: invierte lo que hace .c-shout.
   Antes estaba acotado a .c-home-hero__title porque no estaba claro si los demás
   debían comportarse igual. Las capturas del diseño de servicios y del primer
   paso lo confirman: el tratamiento mixto vale para todos. */
.c-shout {
  font-family: var(--wp--preset--font-family--display);
  font-weight: var(--wp--custom--typography--weight--regular);
  letter-spacing: var(--wp--custom--typography--tracking--display);
  text-transform: none;
}

/* Tratamiento de énfasis en CUALQUIER titular, de h1 a h6. No es propio del
   hero: es cómo se comportan los titulares de este sitio. */
/* ⚠ Desde la entrega 2026-09-01 la librería trae su propia versión de esta regla
   (componentes.css, «Regla tipográfica de la casa») CON PESO 500 y acotada a
   .cmp, especificidad (0,1,2). La decisión del cliente es peso 400 —«el strong
   no significa que la font sea bold»—, así que aquí se añade la variante .cmp
   para empatar especificidad: este archivo carga después y gana. La versión sin
   .cmp cubre los titulares fuera de componentes (panel de navegación). */
.cmp :is(h1, h2, h3, h4, h5, h6, blockquote) :is(strong, b),
:is(h1, h2, h3, h4, h5, h6, blockquote) :is(strong, b) {
  font-family: var(--wp--preset--font-family--text);
  font-weight: var(--wp--custom--typography--weight--regular);
  font-style: normal;
  letter-spacing: var(--wp--custom--typography--tracking--upper);
  text-transform: uppercase;
}

:is(h1, h2, h3, h4, h5, h6, blockquote) :is(em, i) {
  font-style: italic;
  font-weight: inherit;
}

/* A5 · Barra CTA fija — RESUELTO AGUAS ARRIBA, corrección retirada 2026-08-15.
   La librería usaba @container sobre .c-ctabar, pero ese elemento lleva .cmp,
   que es quien declara container-type, y una consulta de contenedor se resuelve
   contra un ANTEPASADO: nunca casaba y la barra de móvil salía en escritorio.
   La entrega de las 18:12 lo cambia a @media, así que aquí ya no hace falta. */

/* ---------------------------------------------------------------------------
   Los patrones se componen con bloques del núcleo, y el núcleo trae su propio
   espaciado
   ---------------------------------------------------------------------------
   Un core/group emite `is-layout-flow`, que aplica:

       .is-layout-flow > *       { margin-block: 0 }
       .is-layout-flow > * + *   { margin-block-start: var(--wp--style--block-gap) }

   Es decir: borra los márgenes que traía el elemento y mete blockGap entre
   hermanos. Dentro de un componente eso sobra y además descuadra, porque el
   espaciado ya lo pone el contenedor con `gap` y la librería cuenta con los
   márgenes por defecto del navegador. Medido en .c-split__body: el marcado de
   referencia separa dos párrafos 56px y el mismo patrón con bloques, 52px.

   Se revierte al valor del NAVEGADOR, no a cero: la librería no declara margen
   de párrafo dentro de .cmp, así que el diseño de referencia se apoya en el
   margen por defecto de <p>. Poner 0 aquí cambiaría el diseño en vez de
   reproducirlo.

   Acotado a .cmp a propósito: fuera de los componentes —contenido de artículo,
   por ejemplo— el espaciado del núcleo es justo lo que se quiere.

   ⚠️ TODO en :where(), especificidad 0, y no es un detalle de estilo.

   El núcleo escribe sus reglas como `:where(.is-layout-flow) > *`, que también
   es 0. Al ser de autor le gana al navegador, pero pierde contra cualquier
   regla con algo de especificidad: por eso solo afecta a los elementos que la
   librería NO estiliza, en la práctica los <p> sueltos.

   Si esta corrección se escribe con especificidad normal (.cmp .is-layout-flow
   > *, que es 0-2-0) se pasa de frenada y pisa las reglas propias de la
   librería: `.cmp__title { margin: 0 }` es 0-1-0 y perdía, así que los títulos
   recuperaban el margen del navegador. Verificado: la separación h2→p se iba
   de 38px a 59,6px.

   La regla apunta a etiquetas (p, ul, ol, blockquote) y no a `*`. Eso le da
   especificidad 0-0-1: lo justo para ganar al núcleo pase lo que pase con el
   orden de carga —con `*` ambas valían 0 y ganaba la que se imprimiera después,
   que resultó ser la del núcleo— y sigue por debajo de cualquier regla de la
   librería, que empieza en 0-1-0.

   Son exactamente los elementos cuyo margen la librería deja al navegador.
   ------------------------------------------------------------------------- */
:where(.cmp) :where(.is-layout-flow, .is-layout-constrained) > :is(p, ul, ol, blockquote),
:where(.cmp.is-layout-flow, .cmp.is-layout-constrained) > :is(p, ul, ol, blockquote) {
  margin-block-start: revert;
  margin-block-end: revert;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · Cabecera de la portada sobre el hero
   ---------------------------------------------------------------------------
   La librería pinta la barra en crema siempre. En la portada va montada sobre
   el hero, que es azul de marca, así que:

     scroll 0  → transparente, la barra se funde con el hero
     pegada    → azul de marca, porque ya no hay hero detrás que la sostenga

   El marcado añade .c-header--sobre-hero solo en la portada (ver header.php),
   de modo que el resto de páginas conserva la barra crema de la librería.

   Logo, WhatsApp y hamburguesa pasan a crema: en su color normal —el logo es
   #4967b0, exactamente el azul del fondo— desaparecerían contra el hero.

   La sombra al quedarse pegada se quita a petición: sobre un fondo de color
   plano marca un escalón que no está en el diseño.

   BORRAR cuando la librería contemple la variante sobre fondo oscuro.
   ------------------------------------------------------------------------- */
/* fixed, no sticky. Con sticky la barra OCUPA SITIO EN EL FLUJO, encima del
   hero: la barra transparente quedaba sobre el fondo crema de la página y el
   logo, que también es crema, resultaba invisible. Además el hero empezaba por
   debajo, así que el trazo naranja no podía pasar por detrás de la barra como
   pide el diseño. Fixed la saca del flujo y la monta sobre el hero.

   Solo en la portada: en el resto de páginas la barra debe seguir ocupando su
   sitio, o el contenido se metería debajo y quedaría tapado. */
.c-header--sobre-hero {
  position: fixed;
  inset: 0 0 auto 0;
  /* .cmp declara background-color: base para todos los componentes, así que sin
     esto el <header> sigue siendo crema aunque su barra interior sea
     transparente. Hay que apagarlo en los dos sitios. */
  background-color: transparent;
  /* ⚠️ NO QUITAR. Esto no es un adorno: arregla un fallo de pintado.
     En Chromium —Chrome, Edge y Brave; Safari y Firefox pintan bien— al
     cambiar el sentido del scroll quedaba una franja horizontal sin repintar
     sobre el hero. El fondo saltaba de transparente a azul en un solo
     fotograma y el compositor dejaba rectángulos sin invalidar. Con transición
     el fondo se repinta durante 280ms y la región se invalida entera.

     Va aquí y no en la regla de .is-stuck para que sirva en los DOS sentidos:
     al pegarse y al soltarse. Si fuera en .is-stuck, al soltarse el azul se
     iría de golpe y volvería el fallo.

     El retardo pequeño evita que la barra parpadee con un roce del scroll.

     Solo background-color a propósito: `all` arrastraría el resto.

     Sin excepción para prefers-reduced-motion, a diferencia del trazo del hero:
     apagarla aquí devolvería el fallo de pintado justo a quien pide menos
     movimiento. Y un fundido de color no es lo que esa preferencia evita —habla
     de desplazamiento y parallax, no de cambios de color. */
  transition: background-color 280ms ease 80ms;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · La cabecera deja de ser contenedor
   ---------------------------------------------------------------------------
   En Chrome, al cambiar el sentido del scroll, aparecía una franja horizontal
   sin repintar sobre el hero.

   .cmp declara container-type a todos los componentes, y la cabecera lleva
   .cmp. En la portada es además position:fixed, así que el mismo elemento es
   raíz de contención Y está fija: esa combinación descoloca al compositor de
   Chrome, que deja rectángulos sin invalidar. La maquetación es correcta —el
   header mide y=0 a cualquier scroll—; lo que falla es el pintado.

   La cabecera no gana nada siendo contenedor: es un bloque a todo el ancho, o
   sea que su ancho ES el de la ventana, y la única consulta de su interior
   —.c-header__actions--desktop, en componentes.css— pregunta justo por eso. Se
   pasa a @media, que da la misma respuesta.

   Es el tercer caso igual: .c-drawer y .c-ctabar ya llevan este tratamiento,
   por el mismo motivo. Los elementos fijos a todo el ancho no deben ser
   contenedores.

   BORRAR cuando la librería deje de poner container-type en el chrome fijo.
   ------------------------------------------------------------------------- */
.c-header {
  container-type: normal;
}

@media (min-width: 48rem) {
  .c-header__actions--desktop { gap: var(--wp--preset--spacing--40); }
  .c-header__actions--desktop .c-btn { display: inline-flex; }
  .c-header__actions--desktop .c-whatsapp { display: inline-flex; }
}

/* El hero recupera el alto de la barra por dentro, para que el titular no
   quede por debajo de ella. */
.c-header--sobre-hero + * .c-home-hero__inner,
.c-home-hero__inner {
  padding-top: calc(var(--wp--custom--layout--header) + var(--wp--preset--spacing--50));
}

.c-header--sobre-hero .c-header__bar {
  background-color: transparent;
  border-bottom-color: transparent;
  box-shadow: none;
}

.c-header--sobre-hero.is-stuck .c-header__bar {
  background-color: var(--wp--preset--color--primary);
  border-bottom-color: transparent;
  box-shadow: none;
}

.c-header--sobre-hero .c-whatsapp {
  color: var(--wp--preset--color--on-primary);
}

.c-header--sobre-hero .c-header__burger span {
  background-color: var(--wp--preset--color--on-primary);
}

/* «Cita online» en la cabecera azul: el botón azul sobre el azul solo se
   veía por su filete crema de 1 px. Se invierte —crema con texto azul—, con el
   mismo peso que «Cita presencial» a su lado; al pasar el ratón, filete crema.
   Solo en la barra: el panel del menú tiene su propio fondo claro. 4-10-2026. */
.c-header--sobre-hero .c-header__bar .c-btn.c-btn--primary {
  background-color: var(--wp--preset--color--on-primary);
  color: var(--wp--preset--color--primary);
  border-color: var(--wp--preset--color--on-primary);
}
.c-header--sobre-hero .c-header__bar .c-btn.c-btn--primary:is(:hover, :focus-visible) {
  background-color: transparent;
  color: var(--wp--preset--color--on-primary);
  border-color: var(--wp--preset--color--on-primary);
}
/* El icono del botón es un SVG en línea con trazo currentColor (16-10-2026):
   toma solo el color del texto, también sobre el botón crema. Ya no hace falta
   la máscara que llevaba la imagen icon-online.webp. */

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El panel de navegación cubre la pantalla, su contenido no
   ---------------------------------------------------------------------------
   En escritorio el panel ocupa el viewport entero —el fondo llega de borde a
   borde— pero lo que hay dentro se alinea con la barra de la cabecera cerrada,
   para que el logo del panel caiga exactamente donde estaba el de la barra y no
   haya salto al abrir.

   Va con @media y no con @container a propósito: el panel es position:fixed y
   mide lo que mide la ventana, así que la pregunta es por el ancho del viewport.
   Además .c-drawer lleva .cmp, que es quien declara container-type, y una
   consulta de contenedor no se evalúa contra el elemento que la declara — el
   mismo fallo que tenía .c-ctabar.

   BORRAR cuando la librería alinee el panel con la rejilla.
   ------------------------------------------------------------------------- */
@media (min-width: 48rem) {
  .c-drawer__bar,
  .c-drawer__body,
  .c-drawer__actions {
    width: 100%;
    max-width: var(--wp--custom--layout--wide);
    margin-inline: auto;
  }
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · Hero: la foto sangra por el margen derecho
   ---------------------------------------------------------------------------
   El contenido del sitio se para en 1570px, pero la foto del hero sigue hasta
   1920px y se pega al borde derecho de ese contenedor mayor. Por encima de
   1920px de ventana deja de crecer y se queda centrada con el resto.

   Se saca del flujo con posición absoluta —el hero ya es position:relative— en
   vez de tocar la rejilla, porque el titular y el texto van centrados a todo lo
   ancho y no en una columna: si la foto siguiera en la rejilla de dos columnas,
   arrastraría el texto a la mitad izquierda.

   En móvil no se posiciona: se apila debajo y se pega al borde derecho comiendo
   el margen, que es lo que pide el diseño.

   ⚠️ Los valores de ancho y de posición vertical son un punto de partida
   razonable, no una medida sacada del archivo de diseño. Conviene mirarlos en
   pantalla y ajustar --cds-hero-foto-*.

   BORRAR cuando home.css lo incorpore.
   ------------------------------------------------------------------------- */
.c-home-hero {
  --cds-hero-lienzo: 1920px;
  --cds-hero-foto-ancho: min(22.5vw, 345px);
  --cds-hero-foto-abajo: 8%;
}

/* Móvil: apilada, pegada al borde derecho comiendo el margen del contenedor. */
.c-home-hero__media {
  width: 78%;
  margin-inline: auto calc(-1 * var(--wp--custom--space--gutter-sm));
}

@media (min-width: 56rem) {
  .c-home-hero__grid {
    display: block;
  }

  .c-home-hero__body {
    align-items: center;
    margin-inline: auto;
    text-align: center;
  }

  .c-home-hero__media {
    position: absolute;
    /* Pegada al filo derecho de la ventana. A partir de 1920px deja de
       seguirlo: se queda en el borde de un lienzo de 1920 centrado, que es lo
       más a la derecha que puede llegar. */
    right: max(0px, calc((100% - var(--cds-hero-lienzo)) / 2));
    bottom: var(--cds-hero-foto-abajo);
    z-index: 1;
    width: var(--cds-hero-foto-ancho);
    margin: 0;
  }
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · Los trazos van a plena opacidad
   ---------------------------------------------------------------------------
   home.css los deja al 55 %. En el diseño son color plano: el naranja y el rosa
   son parte de la identidad, no una textura de fondo.

   No se toca .c-home-hero__bg, que sigue al 35 %: ese sí es textura y a plena
   opacidad se comería el contraste del titular en crema.

   BORRAR cuando home.css lo incorpore.
   ------------------------------------------------------------------------- */
.c-home-hero__shape {
  opacity: 1;
}

/* ---------------------------------------------------------------------------
   CORRECCIÓN · Hueco de 32px sobre la cabecera
   ---------------------------------------------------------------------------
   .wp-site-blocks usa el layout de flujo del núcleo, que mete blockGap entre
   sus hijos: cabecera, main y pie quedaban separados 32px, y esa separación
   aparecía también ARRIBA del todo, como un margen que empujaba la página.

   Encima afectaba a la cabecera fija: un elemento position:fixed con top:0
   sigue obedeciendo a su margin-top, así que la barra se quedaba 32px por
   debajo del borde de la ventana en vez de pegada.

   En este diseño ese gap no pinta nada: cada sección trae su propio ritmo
   vertical en .cmp__inner { padding-block: section-y }, y las que sangran a
   todo el ancho tienen que tocarse entre sí.

   Solo el primer nivel: dentro de las secciones el blockGap del núcleo sigue
   haciendo su trabajo.
   ------------------------------------------------------------------------- */
.wp-site-blocks > * {
  margin-block-start: 0;
  margin-block-end: 0;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El azul de la barra llega de borde a borde
   ---------------------------------------------------------------------------
   Al quedarse pegada, el fondo azul debe cubrir el ancho completo de la
   ventana, no solo los 1570px del contenedor. Así que el color se pinta en
   .c-header —que es fija con inset izquierda y derecha a 0, o sea todo el
   ancho— y la barra interior se queda transparente, conservando su max-width
   solo para alinear el contenido con el resto de la página.
   ------------------------------------------------------------------------- */
.c-header--sobre-hero.is-stuck {
  background-color: var(--wp--preset--color--primary);
}

.c-header--sobre-hero.is-stuck .c-header__bar {
  background-color: transparent;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · En móvil la foto del hero va debajo del CTA
   ---------------------------------------------------------------------------
   En el marcado la foto va antes que el texto, porque en escritorio se coloca
   con posición absoluta y el orden del DOM da igual. En móvil sí importa: sin
   esto la foto sale ARRIBA y empuja el titular y el CTA fuera de la primera
   pantalla.

   Se resuelve con `order` y no moviendo el marcado para no alterar el orden de
   lectura por teclado y lector de pantalla, que ya es el correcto: primero el
   titular y su CTA, la foto después.

   Pegada al borde derecho sin margen: el margen negativo se come el padding
   lateral de .cmp__inner, así que la foto llega al filo de la ventana.
   ------------------------------------------------------------------------- */
@media (max-width: 55.999rem) {
  .c-home-hero__body {
    order: 1;
  }

  .c-home-hero__media {
    order: 2;
    margin-inline: auto calc(-1 * var(--wp--custom--space--gutter-sm));
  }
}

/* ---------------------------------------------------------------------------
   CORRECCIÓN · Ajustes por los envoltorios que mete el núcleo
   ---------------------------------------------------------------------------
   Al componer los patrones con bloques del núcleo en vez de HTML fijo —para que
   la clienta pueda editar el texto— aparecen envoltorios que la librería no
   esperaba. Casi todo su CSS usa selectores de descendencia y sobrevive; esto
   es lo que no.

   BORRAR si algún día los patrones vuelven a marcado plano.
   ------------------------------------------------------------------------- */

/* core/image envuelve el <img> en un <figure> y pone ahí la clase. Como
   .c-need__icon dimensiona el <img> y no su envoltorio, el icono salía a tamaño
   natural. Se reparte el tamaño al <img> de dentro.

   Además la caja se fija en 4:3 para TODOS los iconos. Los símbolos de marca
   tienen proporciones muy distintas entre sí —las olas son anchas y bajas, la
   figura es alta y estrecha—, así que cada tarjeta reservaba una altura
   diferente y los titulares no arrancaban a la misma línea. Con una caja de
   proporción fija y object-fit: contain, el dibujo se centra dentro sin
   deformarse y las seis tarjetas quedan alineadas.

   Las dos medidas van en variables: son el número que se va a querer tocar.

   La caja es flex a propósito. Con `display: block` el aspect-ratio se aplicaba
   pero perdía: el <img> con height: 100% no puede resolver un porcentaje contra
   un padre de altura automática, así que caía a su altura intrínseca —173px en
   el símbolo más alargado— y estiraba el <figure> por debajo. Como contenedor
   flex la altura que da la proporción sí es definitiva, y con max-height el
   dibujo se conforma a ella en vez de imponerla.

   Y hacen falta flex: none y min-height: 0 porque .c-need es un flex en columna,
   así que esta caja es a su vez un flex ITEM. Un flex item arranca con
   min-height: auto, que vale el tamaño de su contenido: mientras eso estuvo
   puesto, la caja no podía encoger hasta la altura de la proporción y el símbolo
   más alargado seguía imponiendo sus 231px. */
.c-need__icon {
  --cds-icono-ancho: 6rem;
  --cds-icono-ratio: 4 / 3;

  display: flex;
  flex: none;
  align-items: center;
  justify-content: center;
  min-height: 0;
  width: var(--cds-icono-ancho);
  aspect-ratio: var(--cds-icono-ratio);
}

.c-need__icon img {
  width: auto;
  height: auto;
  max-width: 100%;
  max-height: 100%;
  object-fit: contain;
}

/* «Dibujos Calma»: las ilustraciones que sustituyen a los símbolos. Son escenas
   a color, no iconos de una tinta: a 96px no se leen, y por eso la caja crece
   hasta el ancho de la tarjeta (con tope). Van SIN duotono, que las aplanaría.

   El fondo del dibujo es un blanco roto opaco, no transparente. `multiply` lo
   funde con el fondo de la tarjeta, y el resto de colores casi no cambia. */
.c-need__icon--dibujo {
  --cds-icono-ancho: min(100%, 13rem);
}

.c-need__icon--dibujo img {
  mix-blend-mode: multiply;
}

/* El <figure> del núcleo trae margen propio. Dentro de un componente sobra: el
   espaciado ya lo pone el contenedor con gap. */
.cmp .wp-block-image {
  margin: 0;
}

/* El «¿Para qué sirve?» de la sección del primer paso. En el marcado de la
   librería iba con estilos en línea, que en un bloque del núcleo son editables
   y por tanto rompibles. Pasa a clase. */
.c-firststep__what-title {
  margin: 0;
  font-size: var(--wp--preset--font-size--large);
  line-height: var(--wp--custom--typography--leading--h4);
  color: var(--wp--preset--color--primary);
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El CTA del hero, en contorno claro
   ---------------------------------------------------------------------------
   Sobre el azul del hero el botón va en contorno CLARO, no lima. La librería ya
   resuelve esto en otros sitios —.c-cta--primary vuelve crema su .c-btn--ghost—
   así que se sigue esa misma convención en vez de inventar otra variante.

   (Se retira .c-btn--lime-ghost, que se había añadido por un malentendido sobre
   el color y ya no la usa nadie.)
   ------------------------------------------------------------------------- */
.cmp.c-home-hero .c-btn--ghost {
  color: var(--wp--preset--color--on-primary);
  border-color: var(--wp--preset--color--on-primary);
}

.cmp.c-home-hero .c-btn--ghost:hover {
  background-color: var(--wp--preset--color--on-primary);
  color: var(--wp--preset--color--primary);
}

/* ---------------------------------------------------------------------------
   PUENTE · core/button adopta la apariencia de .c-btn
   ---------------------------------------------------------------------------
   Para que un CTA sea editable con selector de estilo hace falta core/button,
   que emite su propio marcado:

       <div class="wp-block-button"><a class="wp-block-button__link">…</a></div>

   La clase que se pone desde el editor va al <div>, no al <a>, así que no hay
   forma de que el enlace lleve .c-btn escribiéndolo en el patrón: WordPress
   valida el bloque contra lo que produciría save() y lo marcaría como
   contenido inválido.

   ⚠️ ESTO DUPLICA LAS DECLARACIONES DE .c-btn, y es la única duda de esta
   solución. Se usan los mismos tokens, no valores sueltos, así que un cambio de
   escala o de radio se propaga solo; pero si diseño cambia la ESTRUCTURA de
   .c-btn —añade una propiedad, cambia el padding— este puente se queda atrás y
   los botones del editor dejan de parecerse a los del resto del sitio.

   ARREGLO DE VERDAD, para pedir a Cecilia: añadir `.wp-block-button__link` a la
   lista de selectores de .c-btn en componentes.css. Entonces este bloque entero
   se borra y no hay nada que mantener sincronizado.
   ------------------------------------------------------------------------- */
.cmp .wp-block-button__link:not(.c-btn) {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: var(--wp--preset--spacing--30);
  min-height: var(--wp--custom--layout--control);
  padding: var(--wp--preset--spacing--20) var(--wp--custom--space--control-x);
  border: var(--wp--custom--border--width) solid transparent;
  border-radius: var(--wp--custom--radius--pill);
  font-family: inherit;
  font-size: var(--wp--custom--typography--size--button);
  line-height: var(--wp--custom--typography--leading--tight);
  letter-spacing: var(--wp--custom--typography--tracking--text);
  text-align: center;
  text-decoration: none;
  cursor: pointer;
  transition: background-color var(--wp--custom--motion--duration-fast) var(--wp--custom--motion--ease),
              color var(--wp--custom--motion--duration-fast) var(--wp--custom--motion--ease),
              border-color var(--wp--custom--motion--duration-fast) var(--wp--custom--motion--ease);
}

/* ⚠️ `:not(.c-btn)` EN TODO EL PUENTE, A PROPÓSITO. En la web, inc/botones.php
   pone al enlace las clases de la librería —c-btn c-btn--lime…— y con ellas le
   llegan TODAS las reglas de .c-btn, también las que cambian el color según el
   fondo de la sección (cds/color.css). Si el puente se aplicara a la vez,
   empataba o ganaba a esas reglas y los botones salían con los colores base en
   las secciones de color: contorno azul sobre azul, sin borde crema…
   Medido el 2026-09-10. En el editor no corre el filtro, el enlace no lleva
   .c-btn y el puente sí se aplica: es solo la vista previa. */
/* Las variantes, atadas a los estilos de bloque registrados en
   inc/block-styles.php. Los nombres los ve quien edita en la barra lateral. */
.cmp .is-style-contorno-claro .wp-block-button__link:not(.c-btn) {
  background-color: transparent;
  border-width: var(--wp--custom--border--width-strong);
  border-color: var(--wp--preset--color--on-primary);
  color: var(--wp--preset--color--on-primary);
}

.cmp .is-style-contorno-claro .wp-block-button__link:not(.c-btn):hover {
  background-color: var(--wp--preset--color--on-primary);
  color: var(--wp--preset--color--primary);
}

.cmp .is-style-lima .wp-block-button__link:not(.c-btn) {
  background-color: var(--wp--preset--color--secondary);
  color: var(--wp--preset--color--on-secondary);
}

.cmp .is-style-lima .wp-block-button__link:not(.c-btn):hover {
  background-color: var(--wp--preset--color--secondary-hover);
}

.cmp .is-style-azul .wp-block-button__link:not(.c-btn) {
  background-color: var(--wp--preset--color--primary);
  color: var(--wp--preset--color--on-primary);
}

.cmp .is-style-azul .wp-block-button__link:not(.c-btn):hover {
  background-color: var(--wp--preset--color--primary-hover);
}

.cmp .is-style-contorno .wp-block-button__link:not(.c-btn) {
  background-color: transparent;
  border-width: var(--wp--custom--border--width-strong);
  border-color: var(--wp--preset--color--primary);
  color: var(--wp--preset--color--primary);
}

.cmp .is-style-contorno .wp-block-button__link:not(.c-btn):hover {
  background-color: var(--wp--preset--color--primary);
  color: var(--wp--preset--color--on-primary);
}

.cmp .is-style-claro .wp-block-button__link:not(.c-btn) {
  background-color: var(--wp--preset--color--base);
  color: var(--wp--preset--color--primary);
}

.cmp .is-style-claro .wp-block-button__link:not(.c-btn):hover {
  background-color: var(--wp--preset--color--surface);
  color: var(--wp--preset--color--primary-hover);
}

/* El puente, sobre fondo de color. Solo editor (:not(.c-btn)): en la web lo
   hace cds/color.css con las clases de la librería. Sin esto, el botón de
   contorno del hero azul salía azul sobre azul en el editor —invisible— y el
   principal, sin invertir. Mismos valores que cds/color.css. 2026-09-12. */
.cmp.cmp--primary .is-style-contorno .wp-block-button__link:not(.c-btn) {
  border-color: var(--wp--preset--color--on-primary);
  color: var(--wp--preset--color--on-primary);
}
.cmp.cmp--naranja .is-style-contorno .wp-block-button__link:not(.c-btn) {
  border-color: var(--wp--preset--color--contrast);
  color: var(--wp--preset--color--contrast);
}
.cmp.cmp--lima .is-style-contorno .wp-block-button__link:not(.c-btn) {
  border-color: var(--wp--preset--color--on-secondary);
  color: var(--wp--preset--color--on-secondary);
}
.cmp.cmp--primary .is-style-azul .wp-block-button__link:not(.c-btn) {
  background-color: var(--wp--preset--color--on-primary);
  color: var(--wp--preset--color--primary);
}
.cmp.cmp--naranja .is-style-azul .wp-block-button__link:not(.c-btn) {
  background-color: var(--wp--preset--color--contrast);
  color: var(--wp--preset--color--base);
}
/* Fondos amarillos: el principal y el lima, en el azul de siempre (como en
   cds/color.css, 4-10-2026). Incluye el botón sin estilo, que es el azul. */
.cmp:is(.cmp--lima, .cmp--rosa, .has-secondary-background-color, .has-accent-soft-background-color) :is(.is-style-azul, .is-style-lima, .wp-block-button:not([class*="is-style-"])) .wp-block-button__link:not(.c-btn) {
  background-color: var(--wp--preset--color--primary);
  color: var(--wp--preset--color--on-primary);
  border-color: var(--wp--preset--color--primary);
}

/* El estilo «Enlace» del botón, en el editor: se ve como .c-link. En la web
   inc/botones.php lo escribe directamente como <a class="c-link">. */
.cmp .is-style-enlace .wp-block-button__link:not(.c-btn) {
  display: inline-block;
  min-height: 0;
  padding: 0 0 var(--wp--preset--spacing--10);
  border: 0;
  border-bottom: var(--wp--custom--border--width) solid var(--wp--preset--color--border);
  border-radius: 0;
  background: none;
  font-size: var(--wp--custom--typography--size--button);
  line-height: var(--wp--custom--typography--leading--tight);
  color: var(--wp--preset--color--primary);
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El trazo de abajo del hero se sale sobre la sección siguiente
   ---------------------------------------------------------------------------
   El diseño ya lo pedía: .c-home-hero__shape--2 tiene bottom:-6%, o sea que
   está colocado para asomar por debajo del hero. Lo que lo impedía era el
   overflow:hidden del propio hero.

   Hay dos cosas que resolver, no una:

   1. RECORTE. No vale con quitar el overflow: la forma de arriba a la derecha
      llega a -18% por la derecha y provocaría scroll horizontal en toda la
      página. Hace falta seguir recortando en horizontal y soltar solo el
      vertical.

      Eso NO se puede con `hidden`: en cuanto un eje es visible y el otro
      hidden, el navegador convierte el visible en `auto` y aparece la barra de
      scroll. `clip` sí lo permite, que es justo para lo que se añadió.

   2. APILADO. .cmp da fondo a todas las secciones, así que la siguiente pinta
      por encima aunque el trazo ya no se recorte — va después en el DOM. El
      hero necesita subir de capa.

      Ojo: .cmp declara container-type, que implica contain, y eso convierte
      cada sección en su propio contexto de apilado. Por eso el z-index tiene
      que ir en la SECCIÓN y no en la forma: desde dentro no puede competir con
      una sección hermana.

   El z-index es 1, lo justo. La cabecera fija está en 200 y no se ve afectada.
   Las formas ya son pointer-events:none, así que no roban clics a lo que tapan.

   ⚠️ overflow:clip pide Chrome 90+, Firefox 81+ o Safari 16+. En algo anterior
   el trazo se recorta como hasta ahora — se pierde el detalle, no se rompe nada.

   BORRAR cuando home.css lo incorpore.
   ------------------------------------------------------------------------- */
.c-home-hero {
  /* ⚠️ NO unificar los ejes con `overflow: clip` + `overflow-clip-margin`.
     Probado en Chrome 148: el margen se aplica a los CUATRO lados —los
     longhands por lado (overflow-clip-margin-bottom / -block-end) no están
     soportados—, amplía la región de desbordamiento y el documento la propaga:
     con 8rem aparecían 128px de scroll horizontal (scrollWidth 1568 en una
     ventana de 1440). Que es justo lo que este `clip` evita.

     Así que la mezcla de ejes se queda: `clip` en horizontal para matar la
     barra, `visible` en vertical para que el trazo asome por debajo. */
  overflow-x: clip;
  overflow-y: visible;
  z-index: 1;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · Salto de línea después del destacado
   ---------------------------------------------------------------------------
   En el diseño, el trozo en MyPro versaleta va SIEMPRE en su propia línea y el
   resto empieza debajo: «BUSCANDO LA CALMA / en cada momento de tu vida».

   Se resuelve con display:block sobre el <strong>, no metiendo un <br> en el
   texto. La diferencia importa:

   · Un <br> escrito a mano es contenido, así que viaja a la traducción. En otro
     idioma el corte cae en mitad de otra frase, porque el orden de las palabras
     no es el mismo.
   · display:block es presentación: el corte se recalcula solo en cada idioma.

   Va como ESTILO DE BLOQUE y no siempre activo, porque es decisión por titular:
   en el editor aparece como opción en la barra lateral (ver inc/block-styles.php).
   Registrado para core/heading y core/quote, que son los que comparten
   tratamiento tipográfico.

   BORRAR cuando home.css lo incorpore.
   ------------------------------------------------------------------------- */
.is-style-salto :is(strong, b) {
  display: block;
}

/* ---------------------------------------------------------------------------
   CORRECCIÓN · .c-mark no se veía: apuntaba a ficheros inexistentes
   ---------------------------------------------------------------------------
   Las 8 variantes de la librería usan como máscara PNG de ../mystical/thumb/,
   una carpeta de exploración de 328 MB que está excluida de git y que nunca se
   copió al tema. O sea que todas las marcas estaban rotas en producción, sin
   dar ningún error: una máscara que no carga no avisa, simplemente no recorta.

   Se repuntan a los SVG calcados de assets/symbols/svg/, que son el mismo
   dibujo con el mismo número (88 = wave, 96 = spiral…) y además vectoriales.

   Encajan como máscara sin tocarlos: cada uno es un solo <path> sin atributo
   fill —o sea negro por defecto— y sin rectángulo de fondo. Justo lo que
   necesita una máscara: si llevaran un fondo opaco, se vería un cuadrado en
   lugar de la silueta.

   El color NO se toca aquí. Lo pone .c-mark con background-color, que es lo que
   se ve a través de la plantilla, así que el selector de color del editor ya
   controla el color del símbolo sin código adicional.

   ⚠️ Pesan unos 23 KB de media, mucho para un icono decorativo. Es el precio
   del calco: miles de puntos donde un vector dibujado a mano tendría veinte.
   No se arregla con svgo —ya está aplicado y no gana nada—; se arreglaría
   recalcando con menos detalle. Como son máscaras, solo se descarga la que se
   usa.

   ⚠️ DOS VARIANTES CAMBIAN DE DIBUJO respecto a lo que apuntaba la librería,
   porque su número no correspondía a su nombre. Al ver los 169 símbolos:

     .c-mark--sun  apuntaba al 67, que es una PIRÁMIDE de líneas → ahora al 74,
                   que es un sol radiante de verdad.
     .c-mark--bond apuntaba al 154, que es una BARCA con un sol → ahora al 25,
                   el infinito, que se lee como vínculo y aguanta bien en pequeño.

   Alternativas para bond, por si diseño prefiere otra: el 79 son dos manos —más
   humano, pero se emborrona a 48px— y el 166 son dos arcos entrelazados.

   Los otros seis sí correspondían: arco=arcoíris, luna=luna creciente, hoja=hoja
   fina, piedras=tres piedras apiladas, espiral=espiral, y onda=un zigzag, que
   pasa como onda estilizada.

   BORRAR cuando la librería apunte a los SVG correctos.
   ------------------------------------------------------------------------- */
.c-mark--wave   { -webkit-mask-image: url("../symbols/svg/88.svg");  mask-image: url("../symbols/svg/88.svg"); }
.c-mark--spiral { -webkit-mask-image: url("../symbols/svg/96.svg");  mask-image: url("../symbols/svg/96.svg"); }
.c-mark--arch   { -webkit-mask-image: url("../symbols/svg/71.svg");  mask-image: url("../symbols/svg/71.svg"); }
.c-mark--sun    { -webkit-mask-image: url("../symbols/svg/74.svg");  mask-image: url("../symbols/svg/74.svg"); }
.c-mark--moon   { -webkit-mask-image: url("../symbols/svg/103.svg"); mask-image: url("../symbols/svg/103.svg"); }
.c-mark--leaf   { -webkit-mask-image: url("../symbols/svg/68.svg");  mask-image: url("../symbols/svg/68.svg"); }
.c-mark--stones { -webkit-mask-image: url("../symbols/svg/146.svg"); mask-image: url("../symbols/svg/146.svg"); }
.c-mark--bond   { -webkit-mask-image: url("../symbols/svg/25.svg");  mask-image: url("../symbols/svg/25.svg"); }

/* ---------------------------------------------------------------------------
   NUEVO · Notas con símbolo del bloque de mantra
   ---------------------------------------------------------------------------
   Clases que no existen en la librería: las dos notas pequeñas con símbolo que
   van bajo las citas. Si diseño acaba entregando este componente, esto se borra
   y se usa el suyo.

   El tamaño del símbolo se fija en el <figure> y no en el <img>, porque
   core/image envuelve la imagen y es el envoltorio quien manda en el ancho.
   ------------------------------------------------------------------------- */
.c-mantra__notas {
  margin-top: var(--wp--preset--spacing--60);
}

.c-mantra__notas .wp-block-image {
  flex: none;
  width: var(--wp--preset--spacing--60);
  margin: 0;
}

.c-mantra__notas .wp-block-image img {
  width: 100%;
  height: auto;
}

.c-mantra__nota {
  margin: 0;
  font-size: var(--wp--preset--font-size--small);
  line-height: var(--wp--custom--typography--leading--caption);
  color: var(--wp--preset--color--primary);
}

/* Las citas de este bloque no llevan el max-width de .c-mantra__text: viven
   dentro de una columna, que ya las acota. */
.c-mantra .wp-block-quote {
  margin: 0 0 var(--wp--preset--spacing--50);
  padding: 0;
  border: 0;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · En la portada el texto es azul de marca, nunca negro
   ---------------------------------------------------------------------------
   .cmp fija color: contrast, que es #222f35 —azul pizarra, y en pantalla se lee
   como negro—. En la portada el diseño usa el azul de marca para todo el texto.

   Acotado a .home a propósito: es lo que se ha pedido para la portada. Si
   resulta que vale para el sitio entero, se quita el .home y ya está.

   ⚠️ No se toca ninguna sección que fije su propio color. Las que van sobre
   fondo oscuro —el hero y servicios— lo declaran en sus propios elementos
   (.c-home-hero__body, .c-services__lead, .c-shout--on-primary), y una regla
   sobre el elemento gana a un color heredado del antepasado, así que siguen en
   crema sin necesidad de excepciones.
   ------------------------------------------------------------------------- */
.home .cmp {
  color: var(--wp--preset--color--primary);
}

/* ---------------------------------------------------------------------------
   CORRECCIÓN · Franja entre secciones de página
   ---------------------------------------------------------------------------
   El contenedor de contenido usa el layout de flujo del núcleo, que mete
   blockGap entre sus hijos: 32px entre cada sección. Como las secciones sangran
   a todo el ancho y cada una tiene su propio fondo, ese hueco se ve como una
   franja del color de la página entre bloque y bloque — muy visible entre el
   hero azul y el amarillo del mantra.

   Ya se anuló para .wp-site-blocks, pero al pasar la portada a ser una PÁGINA
   las secciones dejaron de colgar de ahí y pasaron a estar dentro del contenido,
   donde la regla no llegaba.

   Acotado a .cmp a propósito. La misma plantilla sirve para artículos del blog,
   y ahí el blockGap entre párrafos es justo lo que se quiere: solo pierden la
   separación los componentes a sangre, que tienen que tocarse entre sí.
   ------------------------------------------------------------------------- */
.wp-block-post-content > .cmp,
.entry-content > .cmp {
  margin-block-start: 0;
  margin-block-end: 0;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El subtítulo del hero es un H2 que no parece un titular
   ---------------------------------------------------------------------------
   Pedido 2026-08-19: el texto de entrada del hero pasa de <p> a <h2>, porque
   detrás del H1 le corresponde ese nivel y así el esquema de encabezados de la
   portada deja de saltar de H1 a H3. Pero tiene que verse EXACTAMENTE igual que
   antes: misma familia, mismo cuerpo, mismo color.

   Al dejar de ser un párrafo hereda tres cosas del tema que hay que deshacer:
   la familia y el tracking de `elements.heading` (GPro, tracking display) y
   el cuerpo y el interlineado de `elements.h2`. Se reponen los valores que tenía
   como párrafo, que son los que hereda del body.

   El <strong> es el caso interesante. En este sitio, dentro de un titular, el
   negrita significa «cambia de familia y ponte en versales» (ver la regla de
   arriba). Aquí no: esto es un párrafo con jerarquía de titular, así que el
   negrita vuelve a significar lo de siempre —el mismo texto, un punto más
   grueso—. 500 es el único peso más grueso que existe en el sistema.

   BORRAR si home.css acaba definiendo .c-home-hero__claim como titular.
   ------------------------------------------------------------------------- */
h2.c-home-hero__claim {
  font-family: var(--wp--preset--font-family--text);
  font-size: var(--wp--preset--font-size--large);
  font-weight: var(--wp--custom--typography--weight--regular);
  line-height: var(--wp--custom--typography--leading--lead);
  letter-spacing: var(--wp--custom--typography--tracking--text);
}

h2.c-home-hero__claim :is(strong, b) {
  font-family: inherit;
  font-size: inherit;
  color: inherit;
  letter-spacing: inherit;
  text-transform: none;
  font-weight: var(--wp--custom--typography--weight--medium);
}

/* ---------------------------------------------------------------------------
   CORRECCIÓN · Las tarjetas de .c-grid salían desalineadas dentro de su fila
   ---------------------------------------------------------------------------
   .c-grid separa con `gap`. Pero al montarla como core/group, el núcleo le pone
   `is-layout-flow`, y esa clase da `margin-block-start: var(--wp--style--block-gap)`
   a todo hijo MENOS al primero. En un contenedor de flujo eso es justo lo que se
   quiere; dentro de una rejilla no separa filas —de eso ya se encarga gap— sino
   que empuja cada tarjeta hacia abajo DENTRO de su celda.

   El resultado era que la tarjeta 1 quedaba 32px más alta que la 2 y la 3
   estando en la misma fila. Se veía como un descuadre, no como un error, que es
   lo que hace que estas cosas lleguen a producción.

   Va sobre .c-grid y no sobre un patrón concreto porque le pasa a toda rejilla
   de tarjetas: en la portada afectaba a las dos que hay.

   BORRAR si los patrones dejan de envolver las rejillas en core/group.
   ------------------------------------------------------------------------- */
.c-grid > * {
  margin-block: 0;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El hover de la tarjeta se veía como si se volviera invisible
   ---------------------------------------------------------------------------
   La librería pone .c-need:hover { background-color: surface-alt }. Eso funciona
   sobre fondo blanco, pero esta sección TIENE surface-alt de fondo: la tarjeta
   pasaba de blanca al mismo color del fondo, y en pantalla no se leía como un
   estado, se leía como si la tarjeta desapareciera.

   Se sustituye por un azul muy diluido. La alternativa —rellenar de azul de
   marca— se descartó porque dos de los seis iconos SON azules y se perderían
   contra el fondo: el duotono es un filtro por bloque y no puede cambiar en
   :hover. Con la mezcla, los seis colores de icono y el texto azul siguen
   legibles, y el cambio se nota igual.

   BORRAR cuando la librería contemple el hover sobre fondo de color.
   ------------------------------------------------------------------------- */
.c-need--icon {
  --cds-need-hover: color-mix(in srgb, var(--wp--preset--color--primary) 10%, var(--wp--preset--color--surface));
}

.c-need--icon:hover {
  background-color: var(--cds-need-hover);
}

/* ---------------------------------------------------------------------------
   CORRECCIÓN · Espaciado doble dentro de la tarjeta
   ---------------------------------------------------------------------------
   Lo mismo que le pasaba a .c-grid, un nivel más abajo: .c-need es un flex en
   columna que separa con gap, pero al montarla como core/group el núcleo le
   añade margin-block-start a todo hijo menos al primero. Resultado: gap + 32px
   entre icono, titular, texto y pista.

   Se deja el margin-top: auto de .c-need__cue, que es lo que empuja la pista al
   fondo de la tarjeta y hace que las seis alineen abajo.

   ⚠️ Esto NO es exclusivo de .c-need. En la portada hay 19 contenedores flex o
   grid con el mismo problema (c-card, c-about__body, c-pillars, c-resource__inner,
   c-firststep__body, c-choose__body, c-home-hero__body…). Arreglarlos todos
   cambia el espaciado de la página entera, así que se hace aparte y a la vista.

   BORRAR si los patrones dejan de envolver los componentes en core/group.
   ------------------------------------------------------------------------- */
.c-need > *:not(.c-need__cue) {
  margin-block: 0;
}

.c-need > .c-need__cue {
  margin-block-start: auto;
  margin-block-end: 0;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El tamaño de .c-shout sigue al nivel del titular
   ---------------------------------------------------------------------------
   .c-shout fija el cuerpo por clase, no por nivel, así que un H2 y un H3 con el
   mismo estilo salían idénticos: en «No sabes por dónde empezar» la jerarquía
   existía en el marcado pero no se veía.

   Se baja un escalón de la escala del tema —de xx-large a x-large—, no un valor
   suelto: así sigue moviéndose con el resto de la tipografía.

   BORRAR cuando home.css contemple la variante de subtitular.
   ------------------------------------------------------------------------- */
h3.c-shout {
  font-size: var(--wp--preset--font-size--x-large);
}

/* ---------------------------------------------------------------------------
   CORRECCIÓN · El cierre dejaba huecos cuando no había cuatro CTA
   ---------------------------------------------------------------------------
   .c-close__grid fija cuatro columnas a partir de 64rem. Las páginas de servicio
   llevan cuatro CTA y encajan, pero FAQs tiene tres, y tarifas, la primera cita,
   reeducación y el podcast tienen dos o tres: la fila quedaba con una o dos
   celdas vacías a la derecha, y el bloque de cierre se leía como si le faltara
   algo.

   La salida no es añadir botones de relleno —serían CTA inventados— sino que la
   rejilla se ajuste a los que hay. Con auto-fit las pistas vacías se colapsan,
   así que dos botones ocupan dos columnas anchas y cuatro siguen en cuatro.

   BORRAR cuando pagina.css contemple un número variable de CTA.
   ------------------------------------------------------------------------- */
@container (min-width: 64rem) {
  .c-close__grid {
    grid-template-columns: repeat(auto-fit, minmax(12rem, 1fr));
  }
}

/* ---------------------------------------------------------------------------
   CORRECCIÓN · «.page» de la librería choca con la clase que pone WordPress
   ---------------------------------------------------------------------------
   pagina.css trae `.page { position: relative; overflow: hidden }` para el
   envoltorio <div class="page"> de las maquetas estáticas. Pero body_class() de
   WordPress añade `page` al <body> de TODA página del sitio, así que esa regla
   cae sobre el body y le pone overflow: hidden.

   El efecto es desagradable de diagnosticar: con overflow oculto en el body, el
   valor se propaga al viewport y la página deja de responder a la rueda del
   ratón, pero window.scrollTo() sigue funcionando y nada parece roto. La página
   se ve entera, con su altura correcta, y simplemente no baja.

   Afectaba a todas las páginas servidas por WordPress desde que se sincronizó
   la librería del 2026-09-01.

   Se neutraliza solo cuando `page` es el body; el envoltorio de las maquetas
   —un div— conserva su recorte.

   BORRAR si la librería renombra ese envoltorio a algo que no colisione, por
   ejemplo `.l-page`.
   ------------------------------------------------------------------------- */
body.page {
  overflow: visible;
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El acordeón de FAQs, según el diseño de Figma
   ---------------------------------------------------------------------------
   Figma: Calma Designs, nodo 1:257. Aplica a TODOS los acordeones del sitio: la
   librería tenía filas separadas por una línea fina, y la portada usaba además
   la variante H46 `.c-accordion--lime`, que pinta todas las filas de lima. El
   diseño nuevo sustituye a las dos con bandas alternas a sangre y un círculo
   grande de +/− a la derecha.

   Se resuelve entero en CSS, sin tocar el marcado ni el JavaScript: el estado ya
   vive en aria-expanded, que es lo que conmuta componentes.js.

   ⚠️ LOS SELECTORES LLEVAN `.c-accordion` DELANTE a propósito. Las reglas de H46
   son `.c-accordion--lime .c-accordion__item`, especificidad (0,2,0): sin ese
   prefijo, estas se quedarían en (0,1,0) y perderían. Con él empatan y ganan por
   orden de carga, que es lo que hace este archivo.

   ⚠️ EL SIGNO SE DIBUJA AQUÍ, no se lee del marcado. El JS conmuta aria-expanded
   y el atributo hidden del panel, pero NO cambia el carácter «+» o «–» del HTML:
   en cuanto alguien abre o cierra una fila, ese carácter miente. Dibujándolo con
   pseudoelementos a partir de aria-expanded, el signo no puede desincronizarse.

   ⚠️ EL AZUL SOBRE LIMA NO PASA AA. El diseño pone #4967b0 sobre #e1e31f, que da
   4,0:1 — por debajo del 4,5:1 que exige una pregunta de 20px. No es una
   suposición: la auditoría del propio design system ya lo señaló y resolvió el
   CTA lima igual, con primary-hover (#35497e). Se aplica ese mismo azul, un
   punto más oscuro, solo en las bandas lima: medido, 6,31:1. Si se prefiere el
   tono exacto de Figma, se cambia --cds-faq-tinta y se asume que no cumple.

   BORRAR cuando la librería incorpore esta variante y retire H46.
   ------------------------------------------------------------------------- */
.c-accordion {
  --cds-faq-boton: clamp(2.75rem, 6vw, 5.5rem);
  --cds-faq-tinta: var(--wp--preset--color--primary);

  display: block;
  gap: 0;
}

/* Las bandas van a sangre: salen del contenedor de contenido hasta el borde de
   la ventana y devuelven el hueco como padding, para que el texto siga alineado
   con el resto de la página. */
.c-accordion .c-accordion__item {
  margin-inline: calc(50% - 50vw);
  padding-inline: calc(50vw - 50%);
  border: 0;
  background-color: transparent;
  color: var(--cds-faq-tinta);
}

/* Impares en lima, pares sin fondo: nunca hay dos bandas seguidas del mismo
   color, así que la línea divisoria de la librería sobra. */
.c-accordion .c-accordion__item:nth-child(odd) {
  --cds-faq-tinta: var(--wp--preset--color--primary);

  background-color: var(--wp--preset--color--secondary);
}

.c-accordion .c-accordion__trigger {
  align-items: center;
  gap: var(--wp--preset--spacing--50);
  min-height: calc(var(--cds-faq-boton) + var(--wp--preset--spacing--60));
  padding-block: var(--wp--preset--spacing--50);
  font-family: var(--wp--preset--font-family--text);
  font-size: var(--wp--preset--font-size--large);
  line-height: var(--wp--custom--typography--leading--h4);
  letter-spacing: var(--wp--custom--typography--tracking--text);
  text-transform: uppercase;
  color: inherit;
}

/* El círculo. El carácter del marcado se oculta con font-size: 0 y las dos
   barras se dibujan aquí, para que el signo no pueda contradecir al estado. */
.c-accordion .c-accordion__sign {
  position: relative;
  flex: none;
  width: var(--cds-faq-boton);
  height: var(--cds-faq-boton);
  border: var(--wp--custom--border--width) solid currentColor;
  border-radius: var(--wp--custom--radius--round);
  font-size: 0;
}

.c-accordion .c-accordion__sign::before,
.c-accordion .c-accordion__sign::after {
  content: "";
  position: absolute;
  top: 50%;
  left: 50%;
  background-color: currentColor;
  transform: translate(-50%, -50%);
  transition: opacity var(--wp--custom--motion--duration-fast) var(--wp--custom--motion--ease);
}

.c-accordion .c-accordion__sign::before { width: 38%; height: var(--wp--custom--border--width); }
.c-accordion .c-accordion__sign::after { width: var(--wp--custom--border--width); height: 38%; }

/* Abierto: se retira la barra vertical y el «+» queda en «−». */
.c-accordion .c-accordion__trigger[aria-expanded="true"] .c-accordion__sign::after { opacity: 0; }

/* El número de orden de H46 hereda la tinta de su banda. */
.c-accordion .c-accordion__panel {
  padding-bottom: var(--wp--preset--spacing--60);
  padding-right: calc(var(--cds-faq-boton) + var(--wp--preset--spacing--50));
  color: inherit;
}

.c-accordion .c-accordion__item .c-accordion__panel p {
  color: inherit;
  font-size: var(--wp--preset--font-size--large);
  line-height: var(--wp--custom--typography--leading--lead);
}

.c-accordion .c-accordion__panel p + p { margin-top: var(--wp--preset--spacing--40); }
.c-accordion .c-accordion__panel a { color: inherit; }

@media (prefers-reduced-motion: reduce) {
  .c-accordion .c-accordion__sign::before,
  .c-accordion .c-accordion__sign::after { transition: none; }
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El trazo de abajo del hero se dibuja al hacer scroll
   ---------------------------------------------------------------------------
   Antes era una webp de fondo. Ahora el SVG va en línea en el patrón, para poder
   animar el <path>: la línea se traza al bajar y se recoge al subir.

   La animación NO lleva duración. Va atada a `view()`, la línea de tiempo de
   scroll: el avance lo marca la posición del elemento en la ventana, no el
   reloj. Por eso es reversible sin escribir nada — al subir, la línea de tiempo
   retrocede y el trazo se deshace.

   pathLength="1" en el SVG normaliza el largo del trazo a 1, así que dibujarlo
   es llevar stroke-dashoffset de 1 a 0, sin medir la curva real.

   ⚠️ SOPORTE. Las líneas de tiempo de scroll piden Chrome/Edge 115+ o Safari 26+;
   Firefox aún las lleva tras una bandera. Sin ellas, el trazo se queda DIBUJADO
   y quieto, que es el estado bueno: la animación es un adorno, no información.
   Por eso el estado base es «dibujado» y solo dentro de @supports se parte de
   «sin dibujar». Escrito al revés, en Firefox el trazo no aparecería nunca.

   El color sale del token: #C694AD del archivo de Figma es exactamente `accent`.

   BORRAR cuando home.css incorpore el trazo animado.
   ------------------------------------------------------------------------- */

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · La forma 1 se sale sobre el texto en móvil
   ---------------------------------------------------------------------------
   `height: 62%` mide contra el hero, y en móvil el hero se hace muy alto porque
   el contenido se apila: 62 % de 1136 px son 704 px de caja para un dibujo de
   1675 × 1164. Con `background-size: contain` el dibujo entra a 285 × 198 y el
   navegador lo CENTRA en esos 704 px, es decir, justo encima del párrafo.

   No sobra dibujo: sobra caja. Atando la altura a la proporción de la imagen,
   la caja mide lo que mide el dibujo y se queda arriba, que es su sitio.

   Mobile-first, como toda la librería: la base es el móvil y a partir de 56rem
   se devuelve el 62 %, que en escritorio sí encuadra bien.

   BORRAR cuando home.css lo incorpore.
   ------------------------------------------------------------------------- */
.c-home-hero__shape--1 {
  height: auto;
  aspect-ratio: 1675 / 1164;
}

@container (min-width: 56rem) {
  .c-home-hero__shape--1 {
    height: 62%;
    aspect-ratio: auto;
  }
}

.c-home-hero__shape--2.c-trazo {
  color: var(--wp--preset--color--accent);
  overflow: visible;
  /* Escala por ANCHO, no por alto. El <div> anterior no tenía proporción propia,
     así que el `inset` le fijaba la caja. Un <svg> sí la tiene: con `height` en
     porcentaje y los dos lados sujetos, la caja queda sobre-restringida, manda
     la proporción del viewBox y el navegador ignora el lado derecho. En 375 px
     el trazo llegaba a medir 1593 px de ancho, cuatro veces la ventana.
     Con el ancho al 76 % del hero y la altura deducida, el dibujo guarda la
     misma medida en escritorio (1090 px en 1440) y encoge a la vez que la
     ventana. */
  right: auto;
  width: 76%;
  height: auto;
  /* Sin fondo de ninguna clase: solo el trazo. home-media.css sigue poniendo
     shape-hero-2.webp a esta clase —sería la imagen vieja pintada detrás— y se
     retira también cualquier color heredado de la sección. */
  background: none;
}

/* ⚠️ Se usa `scroll()` y no `view()`. `view()` mide cuándo el elemento ENTRA en
   la ventana, y este trazo ya se ve al cargar la página: bajando no entra, sale.
   El rango `entry` no llegaba a activarse nunca y la línea se quedaba sin
   dibujar en todo el recorrido. Atado al scroll del documento, el avance es el
   del primer tramo de página, que es justo lo que se quiere. */

/* Estado base, y lo que ve quien no tiene líneas de tiempo de scroll. */
.c-trazo__linea {
  stroke-dasharray: 1 1;
  stroke-dashoffset: 0;
}

/* El offset negativo dibuja desde el extremo CONTRARIO al del positivo: con
   dasharray 1 1 y pathLength 1, ir de -1 a 0 recorre la curva al revés. */
@keyframes cds-trazo-dibujar {
  from { stroke-dashoffset: -1; }
  to { stroke-dashoffset: 0; }
}

@supports (animation-timeline: scroll()) {
  .c-trazo__linea {
    stroke-dashoffset: -1;
    animation: cds-trazo-dibujar linear both;
    animation-timeline: scroll(root block);
    /* Se completa en el primer alto de ventana de scroll: el trazo termina de
       dibujarse justo cuando el hero acaba de salir. */
    animation-range: 0 100vh;
  }
}

/* Quien pide menos movimiento ve el trazo entero y quieto. */
@media (prefers-reduced-motion: reduce) {
  .c-trazo__linea {
    stroke-dashoffset: 0;
    animation: none;
  }
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El trazo arranca solo si ya se ve al cargar
   ---------------------------------------------------------------------------
   La línea de tiempo de scroll deja el trazo sin dibujar mientras nadie mueve
   la página. En escritorio el trazo entra en la primera pantalla, así que quien
   no hace scroll no ve nunca la animación.

   El CSS no sabe si un elemento cae dentro de la primera pantalla, y `view()`
   tampoco sirve: mide la ENTRADA, y este trazo ya está dentro. Lo decide JS
   (assets/js/componentes.js), que añade la clase al cargar.

   Si el trazo queda fuera de la ventana, no se toca nada y sigue mandando el
   scroll, que es el comportamiento de antes.

   BORRAR cuando home.css incorpore el trazo animado.
   ------------------------------------------------------------------------- */
/* Fotogramas propios, no los mismos que usa el scroll. Cambiar solo la línea de
   tiempo sobre una animación que ya existe la cancela: el navegador se queda con
   una animación en estado `idle`, con `currentTime` nulo, y el trazo no llega a
   dibujarse. Con otro nombre nace como animación nueva y sí arranca. */
@keyframes cds-trazo-dibujar-carga {
  from { stroke-dashoffset: -1; }
  to { stroke-dashoffset: 0; }
}

.c-trazo--al-cargar .c-trazo__linea {
  animation: cds-trazo-dibujar-carga 1.6s cubic-bezier(0.33, 0, 0.2, 1) both;
  /* El atajo `animation` ya devuelve la línea de tiempo a `auto`, pero se deja
     escrito: sin esto el trazo seguiría atado al scroll. */
  animation-timeline: auto;
  animation-range: normal;
  animation-delay: 0.15s;
}

/* Va después y con más especificidad: si no, la regla de arriba se saltaría la
   preferencia de menos movimiento. */
@media (prefers-reduced-motion: reduce) {
  .c-trazo--al-cargar .c-trazo__linea {
    stroke-dashoffset: 0;
    animation: none;
  }
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · «Buscando la calma», la rejilla de servicios según Figma
   ---------------------------------------------------------------------------
   Figma: Calma Designs, nodo 15:191. La sección ya existía —mismo copy, mismos
   seis servicios, mismo CTA— pero maquetada como seis tarjetas blancas sobre el
   azul. El diseño no lleva tarjeta: cada servicio es una FORMA GRANDE con el
   texto centrado debajo, directamente sobre el fondo.

   Se resuelve entero en CSS, sin tocar el marcado: la portada ya está sembrada
   en la base de datos y una forma decorativa no debería obligar a resembrarla y
   pisar lo que la clienta haya editado.

   ⚠️ LAS FORMAS SE DIBUJAN, no se importan. Son tres geometrías simples
   —triángulo, círculo y rombo— y con clip-path el color sale del token, escalan
   sin pixelarse y no añaden seis peticiones. Los SVG de Figma son exactamente
   eso: un path de tres o cuatro puntos.

   Colores leídos de los propios archivos de Figma, no a ojo: el círculo de
   «Infancia y adolescencia» es CREMA, y en la vista aislada del diseño —fondo
   crema— resulta invisible. Mirando la captura se habría puesto de otro color.

   El orden de las formas va por :nth-child, que es frágil si alguien reordena
   las tarjetas desde el editor. Es el precio de no tocar el marcado; si algún
   día el orden importa de verdad, hay que pasar la forma a una clase por
   tarjeta y resembrar.

   BORRAR cuando la librería incorpore esta variante.
   ------------------------------------------------------------------------- */

/* Sin caja: forma y texto centrados sobre el azul. */
.c-services .c-card {
  padding: 0;
  background-color: transparent;
  align-items: center;
  text-align: center;
}

.c-services .c-card__title,
.c-services .c-card__text,
.c-services .c-card__link {
  color: var(--wp--preset--color--on-primary);
}

.c-services .c-card__link { align-self: center; }

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · La forma de cada tarjeta la elige quien edita
   ---------------------------------------------------------------------------
   Antes era un ::before: clip-path para la silueta y el color por nth-child.
   Se veía igual, pero un pseudoelemento NO ES UN BLOQUE — no hay nada que
   seleccionar en el editor—, así que ni la forma ni el color se podían cambiar
   sin tocar código. Ahora son bloques de imagen de verdad, con los SVG de
   assets/shapes/ y el duotono de core/image.

   Se igualan por ALTO, no por ancho. El ancho tendría que depender de la
   silueta —en Figma el triángulo ocupa el 87 %, el círculo el 75 % y el rombo
   el 88 %— y eso ya no se puede saber desde CSS: la silueta la decide quien
   edita. Con un alto común, cada forma entra por `object-fit: contain` con su
   propia proporción y la fila queda alineada sea cual sea la elección.

   19rem en escritorio son 304px, que es justo el alto de las formas en el
   archivo de Figma para una tarjeta de ese ancho.

   BORRAR cuando home.css incorpore las formas como bloque.
   ------------------------------------------------------------------------- */
.c-services .c-card__forma {
  display: block;
  width: 100%;
  height: 12rem;
  margin: 0 auto var(--wp--preset--spacing--40);
}

@container (min-width: 56rem) {
  .c-services .c-card__forma { height: 19rem; }
}

.c-services .c-card__forma img {
  display: block;
  width: 100%;
  height: 100%;
  object-fit: contain;
}

.c-services .c-services__shape { display: none; }

/* El CTA final es de contorno, no macizo: en Figma es un trazo crema sin
   relleno. */
.cmp .c-services__foot .c-btn--on-primary {
  background-color: transparent;
  border: var(--wp--custom--border--width-strong) solid var(--wp--preset--color--on-primary);
  color: var(--wp--preset--color--on-primary);
}

.cmp .c-services__foot .c-btn--on-primary:hover {
  background-color: var(--wp--preset--color--on-primary);
  color: var(--wp--preset--color--primary);
}

/* ---------------------------------------------------------------------------
   CORRECCIÓN · Los enlaces de las tarjetas eran INVISIBLES
   ---------------------------------------------------------------------------
   .c-link fija color: primary, y esta sección tiene el fondo primary. Medido en
   la página: enlace rgb(73,103,176) sobre fondo rgb(73,103,176) — contraste
   1.00, o sea invisible. El título y el texto sí se leían porque declaran su
   crema en sus propios elementos; a los enlaces nadie les hizo la variante.

   En el archivo de Figma (nodo 83-21) estos enlaces son #f2f2e8 —`on-primary`—
   y NO llevan subrayado, así que la vora de .c-link se apaga aquí.

   El hover va a lima, que es el color de interacción de la marca y sobre azul
   se ve de lejos: quedarse en crema no daría ninguna señal.

   BORRAR cuando componentes.css traiga una variante .c-link--on-primary.
   ------------------------------------------------------------------------- */
.c-services .c-link {
  color: var(--wp--preset--color--on-primary);
  border-bottom-color: transparent;
}

.c-services .c-link:hover {
  color: var(--wp--preset--color--secondary);
  border-bottom-color: var(--wp--preset--color--secondary);
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · El aire de la rejilla de tarjetas
   ---------------------------------------------------------------------------
   .c-grid separaba con --wp--custom--space--grid-gap, que son 0.625rem: 10px en
   los DOS ejes. Demasiado poco, y el mismo valor para horizontal y vertical
   cuando el diseño pide claramente más aire entre filas que entre columnas.

   Pedido: 40px en horizontal y 70px en vertical.

   El vertical es el preset 70 de la escala del tema, que son 4.5rem = 72px: se
   usa el token, no el número. El horizontal NO está en la escala —el 50 son
   32px y el 60 son 48px—, así que van 2.5rem literales. Si se prefiere no
   salirse de la escala, el candidato es var(--wp--preset--spacing--60).

   Va sobre .c-grid y no sobre una sección concreta: es el componente de rejilla
   de tarjetas, y lo usan «Buscando la calma» y «No sabes por dónde empezar».
   Dos rejillas de tarjetas con aire distinto se leerían como un fallo.

   BORRAR cuando componentes.css separe los dos ejes.
   ------------------------------------------------------------------------- */
.c-grid {
  column-gap: 2.5rem;
  row-gap: var(--wp--preset--spacing--70);
}

/* ---------------------------------------------------------------------------
   CAMBIO PEDIDO · Sobre fondo oscuro, el texto va en light
   ---------------------------------------------------------------------------
   La letra clara sobre fondo oscuro se ve más gruesa de lo que es. El 400 que
   funciona sobre crema pesa demasiado sobre el azul, y el 300 compensa ese
   efecto. Decisión de la clienta, 2026-09-03.

   ⚠️ Esto NO sale del archivo de Figma. Allí estos párrafos son Regular —el
   nodo 83-21 los da con la cara Regular de la familia de texto, o sea 400—. Es
   una decisión posterior, tomada mirando la pantalla. No «corregir» a 400 para
   cuadrar con Figma sin preguntar.

   La cara 300 se declara en fonts.css. Sin ese @font-face el navegador fingiría
   el peso adelgazando el trazo del 400, y se nota.

   Los enlaces y botones se quedan en 400: tienen su propia escala tipográfica y
   heredarían el 300 del párrafo que los envuelve.
   ------------------------------------------------------------------------- */
.c-home-hero :is(p, li),
.c-services :is(p, li),
.cmp--primary :is(p, li) {
  font-weight: var(--wp--custom--typography--weight--light);
}

.c-home-hero :is(.c-link, .c-btn),
.c-services :is(.c-link, .c-btn),
.cmp--primary :is(.c-link, .c-btn) {
  font-weight: var(--wp--custom--typography--weight--regular);
}

/* ============================================================================
   UN SOLO AZUL PARA EL TEXTO (feedback de Bárbara, 8-10-2026)
   ----------------------------------------------------------------------------
   El azul oscuro (#35497e, `primary-hover`) es SOLO el color de :hover. Ningún
   texto en reposo lo lleva. Antes salía en unos 380 elementos de 8 páginas:
   listas, preguntas frecuentes, submenú, tarifas, todo lo de las bandas lima.

   · El token `on-secondary` («texto sobre lima») pasa a ser el azul de marca
     en theme.json. Era el que pintaba casi todo.
   · Las reglas nuestras (cds/*.css) que usaban `primary-hover` en reposo pasan
     a `primary`.
   · Aquí, las tres de la librería (componentes.css), con su :hover detrás para
     que esta regla, que carga después, no se lo lleve.

   ⚠️ Sobre lima el azul de marca da 3,95:1, por debajo del 4,5:1 de AA para
   texto normal (el oscuro daba 6,32). Decisión de Miquel: un solo azul.
   ========================================================================= */
.c-whatsapp,
.cmp .c-whatsapp {
  color: var(--wp--preset--color--primary);
}
.c-whatsapp:hover,
.cmp .c-whatsapp:hover {
  color: var(--wp--preset--color--primary-hover);
}
/* Sobre la cabecera azul el enlace es crema, también al pasar. Se repite aquí
   porque las dos reglas de arriba cargan después que la suya y la igualan. */
.c-header--sobre-hero .c-whatsapp,
.c-header--sobre-hero .c-whatsapp:hover {
  color: var(--wp--preset--color--on-primary);
}
.c-cta__title,
.c-news__title {
  color: var(--wp--preset--color--primary);
}
/* El submenú del panel estaba en azul oscuro y pasaba al de marca al pasar el
   ratón. Ahora está en el de marca, como su padre, así que el :hover va al
   revés: al oscuro, como cualquier otro enlace. */
.c-drawer__sub a:hover,
.c-drawer__sub a:focus-visible {
  color: var(--wp--preset--color--primary-hover);
}

/* ============================================================================
   LISTAS CON CHECK: UN SOLO TAMAÑO (revisión de Bárbara, 8-10-2026, G4)
   ----------------------------------------------------------------------------
   Había tres: 16 px (c-way__list y c-formsec__steps, que la librería pone en
   `small`), 19 px (c-checklist, c-signals) y 22 px («Qué necesitas» de terapia
   online). Todas al tamaño del párrafo de texto, `medium` (19 px), que es el
   de las listas que se leían bien. El interlineado lo heredan del párrafo.
   ========================================================================= */
.cmp :is(.cds-ticks, .c-checklist, .c-way__list, .c-formsec__steps, .c-signals, .c-firststep__what),
.cmp :is(.cds-ticks, .c-checklist, .c-way__list, .c-formsec__steps, .c-signals, .c-firststep__what) > li {
  font-size: var(--wp--preset--font-size--medium);
}

/* ============================================================================
   ESPACIO ENTRE PÁRRAFOS: UNO SOLO EN TODO EL SITIO (revisión de Bárbara,
   8-10-2026, R17; «es una característica global», Miquel)
   ----------------------------------------------------------------------------
   Medido en 27 páginas (674 pares de párrafos seguidos): el hueco iba de 0 a
   64 px según el componente. La librería quita el margen a muchos párrafos
   (`.c-steps__text { margin: 0 }`…) y separa con el `gap` de su contenedor
   flex, casi siempre 20 px. Donde el contenedor NO es flex, los párrafos
   salían pegados: el segundo párrafo de un paso («Si prefieres llamarnos…»,
   «Importante:…») parecía un salto de línea.

   La regla: dos párrafos seguidos, 20 px (spacing--40), el mismo hueco que el
   `gap` de los componentes. Quedan fuera, y con razón:
     · los contenedores flex o grid: ya separan con `gap`, y un margen se
       SUMARÍA (40 px). La lista sale de la medición; si un componente nuevo
       es flex, va aquí.
     · el texto largo (c-prose, artículos): su ritmo de lectura es mayor
       (22–25 px) y está bien.
     · la ficha de autora: nombre y rol son etiquetas, van juntos.
   ========================================================================= */
.cmp :not(
  .is-layout-flex, .is-layout-grid,
  .c-prose, .wp-block-post-content, .c-autora__cuerpo,
  .c-reassure, .c-leer, .c-firststep__actions, .c-firststep__body, .c-post__body,
  .c-episode__body, .c-need, .c-about__body, .c-services__head, .c-card,
  .c-recurso__texto, .c-split__body, .c-formsec__body, .c-way, .c-service,
  .c-rates-group, .c-job, .c-ihero__body, .c-ihero__inner, .c-close__inner,
  .c-choose__body, .cmp__head
) > p + p {
  margin-block-start: var(--wp--preset--spacing--40);
}

/* Los dos contenedores flex con un `gap` más corto que el resto (8 y 12 px). */
.cmp .c-reassure,
.cmp .c-leer {
  row-gap: var(--wp--preset--spacing--40);
}
