/* dark-theme.css — Modo Oscuro (aditivo) — Tanda 2.1: infraestructura
   Look & feel Mi Trámite Invalidez.

   TODAS las reglas de este archivo van scopeadas bajo
   [data-theme="dark"] (el atributo que app/(publico)/layout.jsx pone
   en <html> cuando el modo está activo). No hay ninguna regla fuera
   de ese scope: en modo Claro o Alto Contraste este archivo no tiene
   ningún efecto.

   ALCANCE DE ESTA TANDA (explícito, no ampliar sin pedirlo): solo la
   base mínima para comprobar que el modo Oscuro funciona de punta a
   punta -- fondo general, texto base, header, launcher/panel,
   superficies principales. Esto NO es el acabado visual completo del
   modo Oscuro: los componentes con color literal que todavía no
   responden (tarjetas de Consulta Estado, acordeones de Oficinas/FAQ,
   formulario de Contacto, Valida DOC, etc.) quedan reportados para
   Tanda 2.2, sin overrides improvisados acá -- mismo criterio que ya
   dejó pendiente high-contrast.css/valida-doc.css/
   FormularioContacto.module.css en su momento, documentado aparte.

   Qué NO está acá: todo lo que ya usa var(--facm-*) (p. ej. los links
   del nav principal vía "#masthead ... a.nav-top-link{color:
   var(--facm-primary)}" en menu.css, o los botones/textos que ya
   citan tokens en facm-tokens.css) responde solo con la redefinición
   de [data-theme="dark"] en facm-tokens.css -- no hace falta
   repetirlo acá. Esto es exclusivamente para selectores con color
   LITERAL (hardcodeado) dentro del alcance mínimo de esta tanda.

   Se carga antes que high-contrast.css (que sigue siendo el ÚLTIMO
   <link>, ver layout.jsx) -- en la práctica nunca compiten: los dos
   modos son mutuamente excluyentes por atributo (ver comentario en
   facm-tokens.css), así que el orden entre ambos archivos es
   irrelevante para la cascada real; se mantiene este orden solo por
   consistencia con "los overrides de tema van después de la base". */

/* ===================================================================
   Base: fondo y texto
   =================================================================== */
/* Vence html{background-color:#800080} (wp-inline.css, sin
   !important, selector compuesto ".absolute-footer, html") --
   [data-theme="dark"] tiene más especificidad (cuenta como clase), no
   hace falta !important. Mismo criterio que high-contrast.css. */
[data-theme="dark"] {
  background: var(--facm-background);
}
/* Vence body{color:#777} (wp-inline.css, sin !important, selector de
   elemento) -- [data-theme="dark"] body tiene más especificidad
   (clase + elemento vs. solo elemento). Este es el override de mayor
   alcance: fija fondo/texto base de <body>; todo texto sin color
   propio (inline o de clase) hereda el texto claro desde acá. */
[data-theme="dark"] body {
  background: var(--facm-background);
  color: var(--facm-text);
}

/* ===================================================================
   Header
   =================================================================== */
/* Refuerzo defensivo, mismo criterio que high-contrast.css: el header
   es blanco por defecto (Flatsome) y no debe quedar así en modo
   Oscuro. Los links del nav (a.nav-top-link) YA responden solos vía
   var(--facm-primary) -- ver menu.css, no se repite acá. */
[data-theme="dark"] #masthead {
  background: var(--facm-surface);
}
/* CORRECCIÓN (Tanda 2.4, hallazgo del inventario CSSOM) --
   content/header.html trae ".header-bg-color.fill", una capa SIEMPRE
   presente (no solo en estado "stuck" al hacer scroll) con
   background-color:rgba(255,255,255,.9) fijo (wp-inline.css) -- en la
   práctica no se veía en las capturas (queda detrás del fondo ya
   oscuro de #masthead de arriba), pero aparece en el inventario de
   superficies claras del CSSOM y depende del stacking exacto, que no
   está garantizado. Se corrige de forma defensiva, mismo criterio de
   ".header-wrapper.stuck" ya resuelto en menu.css (clase exclusiva de
   content/header.html, confirmado, no se usa en ningún otro lugar del
   sitio). */
[data-theme="dark"] .header-bg-color {
  background-color: var(--facm-surface);
}

/* ===================================================================
   Launcher de Accesibilidad + panel (app/(publico)/layout.jsx)
   El borde/texto de .facm-a11y-launcher__circle, .facm-a11y-panel,
   .facm-a11y-panel__title, .facm-a11y-panel__group-label y
   .facm-a11y-option YA usan var(--facm-primary)/var(--facm-text)/
   var(--facm-text-muted)/var(--facm-border) (menu.css) y responden
   solos -- lo que sigue es SOLO lo que ahí queda hardcodeado a
   "#fff"/blanco literal (fondo del círculo/panel/opciones, y el color
   de texto de los estados "rellenos").
   =================================================================== */
[data-theme="dark"] .facm-a11y-launcher__circle {
  background: var(--facm-surface);
}
/* Hover del círculo: en modo Claro es un lila muy pálido (#f7effd)
   pensado para fondo blanco -- sobre fondo oscuro se vería como un
   destello claro fuera de lugar. Un paso de superficie más claro que
   --facm-surface, mismo criterio de "estado hover ligeramente más
   claro que el reposo" que ya usa el modo Claro, sin token dedicado
   para esto todavía (no se agrega uno nuevo en esta tanda). */
[data-theme="dark"] .facm-a11y-launcher:hover .facm-a11y-launcher__circle {
  background: #443653;
}
[data-theme="dark"] .facm-a11y-panel {
  background: var(--facm-surface);
}
/* :not([aria-pressed="true"]) -- SIN esto, esta regla (0-2-0:
   [data-theme="dark"] + .facm-a11y-option) empata en especificidad
   con ".facm-a11y-option[aria-pressed="true"]{background:
   var(--facm-primary)}" de menu.css (0-2-0 también: .facm-a11y-option
   + [aria-pressed="true"]) y GANA por cargar después en el <head> --
   detectado al validar: la opción seleccionada (p. ej. "Oscuro" con
   Oscuro activo) perdía su relleno y quedaba con el mismo fondo que
   las no seleccionadas, distinguiéndose solo por el borde (contradice
   "relleno, no solo contorno", mismo criterio de accesibilidad que ya
   usa el resto del proyecto -- 4.1.2 + 1.4.1). Con :not(...) esta
   regla ya no compite: la opción pulsada sigue resolviendo su fondo
   por la regla de menu.css, sin necesitar repetirla acá. */
[data-theme="dark"] .facm-a11y-option:not([aria-pressed="true"]) {
  background: var(--facm-surface);
}
/* Tanda 2.2: los estados "relleno" (círculo con panel abierto, opción
   seleccionada) ya NO necesitan override acá -- migrados a
   var(--facm-primary-solid) directo en menu.css (token nuevo, ver
   facm-tokens.css), que ya da el contraste correcto con color:#fff
   fijo en los 3 modos. La Tanda 2.1 resolvía esto con dos reglas acá
   forzando color:var(--facm-background) -- quedan eliminadas: el
   nuevo token reduce overrides, que era justamente el objetivo. */

/* ===================================================================
   #wrapper / #main — Tanda 2.2, hallazgo de alto impacto: wp-inline.css
   define "#main, #wrapper{background-color:#fff}" SIN scope, global a
   TODO el sitio (confirmado con CSS.getMatchedStylesForNode, no
   supuesto) -- es el contenedor que envuelve el <main> de cada página,
   por encima de <body>. El fix de <body> (arriba, Tanda 2.1) nunca
   llegaba a cubrir esto: cualquier zona de una página sin su propia
   sección con fondo propio (los "espacios entre secciones") seguía
   blanca encima del <body> oscuro. Selector con atributo + id
   (1-1-0) vence a "#main, #wrapper" (1-0-0 cada uno) sin !important. */
[data-theme="dark"] #main,
[data-theme="dark"] #wrapper {
  background-color: var(--facm-background);
}

/* ===================================================================
   Home (content/index.html) — Tanda 2.2
   =================================================================== */
/* Hero "Consulta Estado Trámite" (#carousel-lg desktop / #carousel-sm
   mobile): fondo lila fijo vía style="" inline (pegado desde el page
   builder) -- mismo patrón que high-contrast.css ya resuelve para
   Alto Contraste (!important documentado ahí, único recurso real
   contra un estilo inline sin tocar el HTML, fuera de alcance de esta
   tanda). Un morado oscuro con tinte (no el --facm-background plano)
   para conservar algo del carácter "hero decorativo" que tiene en
   Claro, en vez de que se funda con el resto de la página. */
[data-theme="dark"] #carousel-lg,
[data-theme="dark"] #carousel-sm {
  background-color: #2a2233 !important;
}
/* CORRECCIÓN (validación visual real, no detectada por la Tanda 2.2
   anterior): el subtítulo "Consulta el estado de tu trámite de
   Calificación de Invalidez" es un <span style="color:#1f215c"> --
   inline, DENTRO de .h-large pero con un color PROPIO, distinto del
   título ("Consulta Estado" #662382 / "Trámite" #d13456). La Tanda
   2.2 solo cambió el FONDO de #carousel-lg/-sm, nunca este texto --
   #1f215c (navy oscuro) sobre el nuevo fondo #2a2233 quedaba casi
   invisible (confirmado con getComputedStyle en un navegador real,
   no una captura). Selector por VALOR del propio style inline
   (span[style*="#1f215c"]), igual técnica que high-contrast.css ya
   usa para el span[style*="d13456"] de al lado -- targetea SOLO el
   subtítulo, sin tocar los dos spans del título (colores distintos,
   no matchean este selector), que el usuario confirmó que ya se ven
   bien. !important: necesario para vencer el style="" inline, mismo
   criterio que el fondo de arriba. */
[data-theme="dark"] #carousel-lg .h-large span[style*="#1f215c"],
[data-theme="dark"] #carousel-sm .h-large span[style*="#1f215c"] {
  color: var(--facm-text) !important;
}
/* Ecosistema (#section_1343119426, "Links de nuestro ecosistema"):
   selectores por ID DE SECCIÓN + clase de la curva -- NO por nombre
   de entidad ni cantidad, así que responde igual sin importar cuántos
   logos/entidades administre el mantenedor arriba (COMPIN, AACH, etc.
   son contenido estático de este fragmento hoy, no vía API -- de
   todos modos el selector no depende de eso). Nombres/teléfonos de
   entidades no tienen color propio (heredan var(--facm-text) desde
   <body>, Tanda 2.1) y los links heredan var(--fs-color-primary) ->
   var(--facm-primary) (facm-tokens.css) -- ambos ya responden solos,
   sin necesitar nada acá. Logos (<img>) NO se tocan (sin filter, sin
   invertir) -- piden expresamente mantener su color propio. */
[data-theme="dark"] #section_1343119426 {
  background-color: var(--facm-surface);
}
/* La curva (.ux-shape-fill, fill:#fff en Flatsome) "emerge" desde la
   zona de arriba (fondo general de la página, no el propio
   --facm-surface de esta sección) -- mismo tono que --facm-background
   para que la transición siga leyéndose fluida, igual criterio visual
   que en Claro (blanco = mismo tono que el fondo general de arriba). */
[data-theme="dark"] #section_1343119426 .ux-shape-fill {
  fill: var(--facm-background);
}
/* CORRECCIÓN -- logos de entidades (COMPIN, AACH, etc.): los PNG
   tienen fondo TRANSPARENTE (colorType RGBA, confirmado leyendo el
   IHDR de los archivos, no supuesto) con trazo propio oscuro (azul/
   rojo institucional) -- pensados para verse sobre blanco. Sobre el
   nuevo fondo oscuro de la sección quedan casi ilegibles (reportado
   y confirmado). NO se tocan los assets (sin invert/filter/opacity):
   se les da una superficie clara detrás, igual que tendrían en
   Claro, SOLO dentro de este scope. .img-inner es el wrapper directo
   que Flatsome pone alrededor de cada <img> (".img-inner" adentro de
   ".img.has-hover") -- selector genérico dentro de la sección, no por
   nombre/cantidad de entidad, así que sigue funcionando igual si el
   mantenedor agrega o quita logos. Sin padding (no se cambian
   dimensiones): el parche claro queda exactamente del tamaño de cada
   imagen. */
[data-theme="dark"] #section_1343119426 .img-inner {
  /* CORRECCIÓN (Microajuste Ecosistema) -- #ddd6e3 (Tanda 2.4) + borde
     propio se leía como "sticker"/badge pegado sobre la sección, no
     como parte del logo. Diagnóstico con getBoundingClientRect antes
     de tocar nada: .img-inner YA se ajusta al ancho del <img>
     (~101x42px medido en 6 logos distintos) y NO se estira a la
     columna completa (~131px) -- no era un problema de ancho/padding,
     era el COLOR (demasiado claro/saturado) + el BORDE (remarca el
     rectángulo) lo que producía el efecto tarjeta.

     Tinta real de los logos extraída pixel a pixel de los PNG (no
     estimada): AACH tiene su trazo sólido más oscuro en rgb(0,9,136)
     (luminancia relativa 0.0197), COMPIN en azul rgb(27,64,154) /
     franja roja rgb(200,0,45). #847a91 es el tono MÁS OSCURO posible
     que todavía da >=3:1 contra la tinta más exigente encontrada
     (3.71:1 contra el azul sólido de AACH) -- gris-lila apagado, no
     pastel, mucho menos protagónico que #ddd6e3 (que llegaba a
     10.61:1, muy por encima de lo necesario). Sin borde (ya no hace
     falta: el salto de color entre #847a91 y --facm-surface del fondo
     de la sección ya es perceptible por sí solo). border-radius
     bajado a 4px (antes 6px) -- ver captura. */
  background: #847a91;
  border-radius: 4px;
}
/* Las 16 tarjetas "Estado de Trámite" (8 desktop + 8 mobile,
   .col-inner.box-shadow-2) -- CORRECCIÓN: esta regla NUNCA tuvo
   efecto real. Hay una regla en public/core/style/app.css,
   "#section_1951452129 .col-inner.box-shadow-2, #section_1592154430
   .col-inner.box-shadow-2 { background:#fff; }" (Tanda 1 de look &
   feel, anterior a todo el trabajo de modo oscuro), con selector por
   ID DE SECCIÓN + 2 clases (especificidad 1-2-0) -- un ID le gana a
   cualquier cantidad de clases o atributos, así que le ganaba a este
   selector de acá (0-3-0) sin importar el orden de carga. Confirmado
   con CSS.getMatchedStylesForNode en un navegador real, no supuesto.
   El fix real vive ahora en public/core/style/app.css, junto a esa
   regla (mismo criterio que ya usa ese archivo para su propio bloque
   de Alto Contraste, líneas más abajo de la regla base) -- acá no
   queda nada, para no dejar una regla muerta que confunda a futuro. */
/* Separadores <hr> (p. ej. bajo "Estado de Trámite", #text-1057575971):
   Flatsome no les da color propio via variable -- heredan el gris
   por defecto del navegador (currentColor en algunos, o un gris fijo
   según UA), apenas visible contra el fondo ahora oscuro. Selector
   universal SOLO dentro de este scope, sin arriesgar otras páginas:
   ya se validó que ninguna otra usa <hr> con una apariencia especial
   que dependa de heredar el color de texto. */
[data-theme="dark"] hr {
  border-color: var(--facm-border);
}

/* ===================================================================
   Preguntas Frecuentes (content/preguntas-frecuentes.html) — CORRECCIÓN
   (validación visual real detectó "Preguntas Frecuentes" y las
   preguntas del accordion casi invisibles -- no era el texto: título
   y accordion-title/-inner YA usaban var(--facm-primary)/
   var(--facm-text) y responden solos, confirmado con
   getComputedStyle). La causa real es la SUPERFICIE detrás: esta
   página envuelve el título+accordion en DOS capas claras que la
   Tanda 2.2 nunca tocó (no se había auditado este archivo puntual):
     - #section_1288673044 .section-bg-overlay: fondo gris claro
       (rgb(237,237,237)) vía <style> embebido en el propio HTML.
     - Dos niveles anidados de .col-inner con fondo blanco -- el
       exterior puesto DIRECTO como atributo style="" inline
       (máxima especificidad, ver content/preguntas-frecuentes.html
       línea ~26), el interior vía otro <style> embebido con ID de
       fila + ." col > .col-inner".
   En vez de perseguir cada ID de fila (frágil si el mantenedor
   regenera el fragmento), se targetea con .col-inner genérico
   DESCENDIENTE de la sección (#section_1288673044 .col-inner) --
   alcanza los dos niveles anidados por igual, sin depender de cuántas
   preguntas administre el mantenedor ni de IDs de fila específicos.
   !important en .col-inner: obligatorio para vencer el style="" inline
   del nivel exterior (nada más lo consigue). */
[data-theme="dark"] #section_1288673044 .section-bg-overlay {
  background-color: var(--facm-background);
}
[data-theme="dark"] #section_1288673044 .col-inner {
  background-color: var(--facm-surface) !important;
}

/* ===================================================================
   Menú móvil off-canvas (#main-menu, content/after-footer.html) —
   MICROFIX (validación en dispositivo físico real): superficie que
   ninguna tanda de Modo Oscuro había cubierto hasta ahora.
   Causa exacta, confirmada con CDP (no supuesta): el panel visible NO
   es #main-menu (que es transparente) sino ".mfp-content" -- el
   contenedor propio de Magnific Popup para el off-canvas. Confirmado
   con la cadena de ancestros real: #main-menu vive DENTRO de
   .mfp-content, que trae background-color:rgba(255,255,255,.95) sin
   ningún override. Se reutiliza el mismo selector que YA usa
   wp-inline.css para este mismo panel (".off-canvas-left .mfp-content,
   .off-canvas-right .mfp-content", ahí solo para --drawer-width) --
   confirmado que .mfp-content NO se usa en ningún otro modal/popup del
   proyecto (Valida DOC y el login no usan Magnific Popup), así que este
   selector no alcanza a nada más.
   Enlaces: color literal rgba(102,102,102,.85) (Flatsome) -> texto
   claro. Separador entre ítems: border-top #ececec (Flatsome) -> tono
   de borde oscuro. Hover: velo negro rgba(0,0,0,.05) (Flatsome,
   invisible sobre fondo oscuro) -> velo claro equivalente, mismo
   criterio "sin token dedicado todavía" ya usado arriba para el hover
   del launcher (#443653). El botón cerrar (.mfp-close) ya es blanco
   sobre fondo transparente -- sobre el nuevo panel oscuro queda visible
   sin tocarlo. Tamaño Normal/Grande/Muy Grande (menu.css) y la condición
   Activo/Inactivo de Valida DOC (layout.jsx/quitarItemMenu(), NO
   tocados) siguen funcionando igual: esto es solo color, no toca
   ninguna clase ni estructura que esos mecanismos dependan. */
[data-theme="dark"] .off-canvas-left .mfp-content,
[data-theme="dark"] .off-canvas-right .mfp-content {
  background-color: var(--facm-surface);
}
[data-theme="dark"] #main-menu .nav-sidebar > li > a {
  color: var(--facm-text);
}
[data-theme="dark"] #main-menu .nav-sidebar.nav-vertical > li + li {
  border-top-color: var(--facm-border);
}
[data-theme="dark"] #main-menu .nav-sidebar.nav-vertical > li.menu-item:hover,
[data-theme="dark"] #main-menu .nav-sidebar.nav-vertical > li.menu-item.active {
  background-color: rgba(255, 255, 255, 0.08);
}

/* ===================================================================
   Carrusel mobile (#carousel-sm) — velo sutil en Modo Oscuro.
   HECHO confirmado en la auditoría previa (inspección de píxeles del
   archivo, no de una captura): public/img/header_1_sm.png y
   header_2_sm.png son RGBA 337x482 / 338x482 con alfa 255 (OPACO) en
   las 4 esquinas y color RGB(230,216,236) = #E6D8EC -- el rosado está
   RASTERIZADO dentro del PNG, no es un fondo CSS. El fondo propio de
   #carousel-sm ya responde correctamente al Modo Oscuro (#2a2233,
   medido) y NINGÚN contenedor intermedio (.carousel-inner,
   .carousel-item, el wrapper position:relative) aporta superficie
   clara: todos transparentes. La imagen ocupa 536 de los 583px de alto
   de la sección (92% del área visible), de ahí que domine la pantalla.
   Solución aprobada: velo oscuro translúcido POR ENCIMA de la imagen,
   sin tocar el archivo, sin filter/invert/brightness sobre el <img>
   (que alteraría la fotografía y los colores de marca) y sin cambiar
   el tamaño del carrusel. Es 100% reversible: si se retira esta regla,
   todo vuelve al estado anterior.
   - Se aplica al wrapper interno de cada slide (único <div> hijo
     directo de .carousel-item, ya position:relative;overflow:hidden por
     estilo inline del propio HTML -- no hace falta tocarlo).
   - pointer-events:none: el velo NUNCA intercepta clics; el botón
     "Consultar Estado" sigue siendo clickeable exactamente igual.
   - z-index 1 en el velo: queda SOBRE la imagen pero DEBAJO del CTA,
     que YA trae z-index:2 propio de app.css (".carousel-item
     .btn-floating", regla preexistente, verificada -- no hace falta
     agregar nada para el botón), así que el CTA no se atenúa. Los
     indicadores y las flechas prev/next cuelgan de
     #carouselExampleIndicators_sm (fuera de este wrapper), así que
     quedan fuera del velo por estructura, sin necesitar nada.
   - Color por token del propio Modo Oscuro (--facm-background) con
     opacity 0.22 (rango pedido 20-25%): oscurece lo suficiente para
     integrarse sin volver irreconocible la ilustración.
   Solo bajo [data-theme="dark"]: en Claro, Alto Contraste y Escala de
   grises esta regla no matchea y no tiene ningún efecto. */
[data-theme="dark"] #carousel-sm .carousel-item > div::after {
  content: "";
  position: absolute;
  inset: 0;
  background: var(--facm-background);
  opacity: 0.22;
  pointer-events: none;
  z-index: 1;
}