/*
  MENÚ + CTA DEL HEADER (16/08/2026, revisado 17/08/2026 dos veces)
  ------------------------------------------------------------
  Añade el menú de navegación y el botón "Cuéntanos" a .hero__nav
  (definido en hero.css) para desktop/tablet. No se toca hero.css
  directamente — todo lo nuevo vive aquí para que el diff sea
  legible y fácil de revertir.

  CONTENIDO CERRADO (16/08): menú = Home + Servicios únicamente.
  /applicate/ no entra mientras siga en "Próximamente" — un ítem
  de menú es una promesa de destino real. Botón = "Cuéntanos",
  enlaza a /cuentanos/. Mismo botón se usa en las tres páginas
  (salvo en /cuentanos/, donde no se repite — ver más abajo).

  ORDEN EN LA FILA (desktop/tablet, >640px): marca | menú | botón |
  toggle. hero__nav ya es flex con justify-content: space-between —
  con 4 hijos en vez de 2, ese space-between dejaría demasiado
  hueco entre marca y el resto. Se envuelve menú+botón+toggle en un
  solo grupo con su propio gap, y ESE grupo es el segundo (y
  último) hijo directo de .hero__nav.

  MÓVIL (≤640px) — TERCERA ITERACIÓN, CERRADA (17/08/2026, noche):
  el header vuelve a ser SOLO marca + toggle, igual que antes de
  añadir el menú (ver hero.css, sin overrides aquí). Servicios y
  Cuéntanos SALEN del header por completo y pasan a vivir en una
  franja nueva, propia, DESPUÉS de la curva de 3 capas — ver bloque
  .menu-movil más abajo. Decisión de Erika tras ver en pantalla dos
  intentos de comprimir el header a una sola fila con todo dentro
  (menú+CTA+toggle): prefiere el header limpio y el menú como pieza
  aparte, con más aire, en vez de competir por espacio ahí arriba.
  Esto solo aplica a MÓVIL — desktop/tablet no cambia, el menú sigue
  en el header como siempre.

  HISTORIAL DE INTENTOS ANTERIORES EN MÓVIL (mismo día, para no
  repetirlos si se retoca esto): primero un intento de una fila
  para los 4 elementos (fracasó, toggle invisible, no cabía);
  después dos filas dentro del header (marca+toggle arriba,
  Servicios+Cuéntanos centrados abajo) — funcionó y se verificó en
  pantalla, pero Erika decidió esta noche que prefiere sacar el
  menú del header directamente. Todo ese código de grid se retira
  de aquí; si hace falta recuperarlo, está en el historial de git
  del commit df29bdf.
*/

.hero__nav-derecha {
  display: flex;
  align-items: center;
  gap: 28px;
}

.hero__menu {
  display: flex;
  align-items: center;
  gap: 22px;
}

.hero__menu-link {
  font-family: var(--font-marca);
  font-weight: 500;
  font-size: 15px;
  letter-spacing: -0.006em;
  color: var(--color-texto-principal);
  opacity: 0.72;
  transition: opacity 0.15s ease, color 0.15s ease;
}

.hero__menu-link:hover {
  color: var(--color-texto-principal);
  opacity: 1;
}

/* Enlace "Home" — solo visible desde tablet hacia arriba. En móvil
   el wordmark ya lleva a "/", así que repetirlo es redundante. En
   móvil, además, todo .hero__nav-derecha se oculta (ver más abajo,
   después de las reglas base del CTA). */
.hero__menu-link--home {
  display: inline;
}

/*
  BOTÓN "CUÉNTANOS" — naranja sólido fijo en ambos modos (16/08,
  ajuste). Antes usaba var(--color-wordmark), el mismo color de
  fondo que el pill del toggle (--color-toggle-pill es el mismo
  token) — ambos se fundían en la misma familia visual y el CTA
  perdía distinción frente a un simple control de ajuste.

  El naranja está reservado en todo el sistema como acento de
  "mira aquí, hay una acción" (filete de la curva, punto del
  eyebrow, guiones de lista) — nunca antes como fondo de una
  superficie, pero es exactamente el rol que necesita un CTA.
  Nunca se invierte entre día/noche, así que el botón queda
  visualmente idéntico en ambos modos — refuerza que es siempre
  el mismo tipo de acción, sin depender del tema.

  Esta clase la reutiliza también .menu-movil__cta más abajo, para
  que el botón de la franja móvil nueva sea visualmente el mismo
  CTA, solo con overrides de tamaño en su propio bloque.
*/
.hero__cta {
  display: inline-flex;
  align-items: center;
  gap: 6px;
  padding: 10px 18px;
  border-radius: 100px;
  font-family: var(--font-marca);
  font-weight: 600;
  font-size: 14px;
  letter-spacing: var(--tracking-cta);
  background-color: var(--color-naranja);
  color: var(--color-blanco);
  white-space: nowrap;
  transition: opacity 0.15s ease;
}

.hero__cta:hover {
  color: var(--color-blanco);
  opacity: 0.86;
}

.hero__cta .cta__flecha {
  transition: transform 0.15s ease;
}

.hero__cta:hover .cta__flecha {
  transform: translateX(2px);
}

/* En móvil, el grupo menú+CTA+toggle desaparece del header entero
   — el toggle se recupera por separado más abajo (con su propio
   contenedor de nuevo), porque SÍ debe seguir en el header
   (decisión de Erika: el toggle se queda junto al logo, solo el
   menú+CTA bajan a la franja nueva). Este bloque va DESPUÉS de las
   reglas base de .hero__cta A PROPÓSITO: con la misma especificidad
   (0,1,0 ambas), CSS aplica la regla que aparece más tarde en el
   archivo — si este override quedara antes de la regla base
   (como en un primer intento fallido), la base la pisaría por
   orden de aparición aunque la media query estuviera activa.
   VERIFICADO EN PANTALLA tras corregir el orden — antes de este
   ajuste el CTA seguía visible en el header incluso en 402px. */
@media (max-width: 640px) {
  .hero__menu,
  .hero__cta {
    display: none;
  }

  /* El toggle vuelve a ser el único contenido real de
     .hero__nav-derecha en móvil — se resetea el gap ya que no hay
     nada más con quien compartirlo. */
  .hero__nav-derecha {
    gap: 0;
  }
}

/* ============================================================
   FRANJA DE MENÚ MÓVIL — nueva (17/08/2026, noche)
   ============================================================
   Vive FUERA de <section class="hero">, inmediatamente después de
   su cierre en el HTML (hermana del hero, no hija) — el hero tiene
   position:relative con hijos en position:absolute (la curva) y
   un padding-bottom calibrado con precisión (132px desktop / 148px
   móvil, ligado al alto exacto de la curva de 3 capas); meter
   contenido nuevo DENTRO del hero arriesga desajustar esa relación.
   Como hermana, no interfiere con nada de eso — simplemente ocupa
   el espacio de documento que le corresponde justo después.

   Solo visible en móvil (display:none por defecto, flex en la
   media query) — en desktop/tablet el menú sigue en el header,
   esta franja no existe visualmente ahí.

   CONTENIDO CONDICIONADO POR PÁGINA, vía HTML (no CSS): cada página
   incluye solo los enlaces que le tocan.
     - Home: Servicios + Cuéntanos
     - /services/: solo Cuéntanos (Servicios no se repite, ya estás
       ahí)
     - /cuentanos/: solo Servicios (Cuéntanos no se repite, mismo
       motivo)
   Esto sigue el mismo patrón que ya usa el CTA de la barra sticky y
   del header en desktop para /cuentanos/ — no es un caso nuevo.

   ESPACIADO: separación clara respecto a la curva de arriba y al
   contenido de abajo (decisión explícita de Erika, no "pegado").
   padding-top empuja el contenido lejos de la curva; margin-bottom
   final asegura que el siguiente bloque (tarjeta de producto o
   ficha) no quede pegado tampoco.
*/
.menu-movil {
  display: none;
}

@media (max-width: 640px) {
  .menu-movil {
    display: flex;
    justify-content: flex-end;
    align-items: center;
    gap: 16px;
    /* padding-top de 6px y margin-bottom de -26px son el ajuste
       genérico ya validado en Home y /services/ (ambas comparten
       padding-top:44px en su sección siguiente). /cuentanos/ usa
       cuentanos.css con padding-top:40px en .contacto — parecido
       pero no igual, y Erika vio en pantalla que el resultado ahí
       quedaba con demasiado aire hacia abajo y "Servicios" pegado
       al borde derecho. Ver override específico de /cuentanos/ más
       abajo en este mismo archivo, que corrige ambas cosas sin
       tocar este valor genérico (que sigue sirviendo a Home y
       /services/, ya confirmados en pantalla). */
    padding: 6px 20px 0;
    background-color: var(--color-fondo-productos);
    /* Fix de bug real detectado por Erika: al cambiar de tema
       (clic en el toggle), esta franja pasaba de un color a otro
       de forma INSTANTÁNEA mientras el resto de bloques (.hero,
       .productos, .soluciones, .contacto) hacen un fundido de
       0.3s — la falta de transition aquí hacía que, durante esos
       0.3s, .menu-movil ya mostrara el color final del tema nuevo
       mientras el fondo de alrededor seguía a medio fundir,
       percibido como una franja o "carga" visible en mitad del
       cambio. Con la misma transición que el resto del sistema,
       el color de fondo se funde en sincronía y la franja deja de
       notarse como una capa aparte. */
    transition: background-color 0.3s ease;
    margin-bottom: -26px;
  }

  .menu-movil__link {
    font-family: var(--font-marca);
    font-weight: 500;
    font-size: 15px;
    letter-spacing: -0.006em;
    color: var(--color-texto-principal);
    opacity: 0.72;
    line-height: 1;
    transition: opacity 0.15s ease, color 0.15s ease;
  }

  .menu-movil__link:hover {
    opacity: 1;
  }

  /* Mismo look que .hero__cta (naranja sólido, nunca se invierte)
     pero con su propia clase para no arrastrar overrides futuros
     de .hero__cta que no tengan sentido aquí. */
  .menu-movil__cta {
    display: inline-flex;
    align-items: center;
    gap: 6px;
    padding: 10px 18px;
    border-radius: 100px;
    font-family: var(--font-marca);
    font-weight: 600;
    font-size: 14px;
    letter-spacing: var(--tracking-cta);
    background-color: var(--color-naranja);
    color: var(--color-blanco);
    white-space: nowrap;
    transition: opacity 0.15s ease;
  }

  .menu-movil__cta:hover {
    opacity: 0.86;
    /* Fix de bug real: sin esto, el :hover global de <a> en
       base.css (a:hover { color: var(--color-naranja) }) pintaba
       el texto en naranja sobre el propio fondo naranja del botón
       — invisible. Se fija el color explícitamente en el propio
       :hover para que nunca dependa de qué regla gane por
       especificidad con el estilo global de enlaces. Menta en
       ambos modos (no se invierte, igual que el fondo naranja) —
       decisión de Erika: buen contraste sobre naranja en día y
       noche sin necesitar dos valores distintos por tema. */
    color: var(--color-menta);
  }

  /* AJUSTE ESPECÍFICO DE /cuentanos/ — esta página no tiene CTA en
     la franja (solo el link "Servicios", porque el propio CTA
     "Cuéntanos" no se repite en su propia página), así que
     .menu-movil tiene un único hijo ahí. :has() lo detecta sin
     necesitar una clase de página nueva en el HTML ni JS: cuando
     .menu-movil contiene el link pero NO contiene el cta, es
     /cuentanos/. Corrige dos cosas que Erika vio en pantalla y que
     el ajuste genérico (calibrado sobre .productos/.soluciones,
     padding-top:44px) no resolvía bien para esta página, cuya
     sección .contacto tiene un padding-top distinto (40px, ver
     cuentanos.css): (1) demasiado aire hacia abajo — margin-bottom
     más negativo; (2) "Servicios" pegado al borde derecho, muy
     alejado del ancho real del formulario (.contacto__form tiene
     max-width:640px centrado, más estrecho que el ancho completo
     de la pantalla) — se mueve el padding-right para acercarlo
     visualmente al borde derecho de la tarjeta de abajo en vez del
     borde de la pantalla. */
  .menu-movil:has(.menu-movil__link):not(:has(.menu-movil__cta)) {
    /* Sin padding-right adicional: el padding-right base de
       .menu-movil (20px, heredado de la regla general) ya coincide
       exactamente con el padding lateral de .contacto en móvil —
       alineando el borde derecho de "Servicios" con el borde
       derecho real de la tarjeta de abajo (.contacto__bloque).
       El padding-right:60px de los intentos anteriores desplazaba
       de más hacia la izquierda, más allá de ese borde. */
    margin-bottom: -20px;
  }
}