/* MICHEMICALDATALAB — FACTURACIÓN V2 (preview) — shell V2 sobre la aplicación real intacta
   ------------------------------------------------------------------------
   DECISIÓN DE ARQUITECTURA (documentada, no silenciosa): a diferencia de Home/Catálogo/
   APIs V2, esta página SÍ sigue cargando /styles.css sin tocar — facturacion.js (300KB,
   no reescrito ni releído en su totalidad) maneja auth/sesión/6 módulos/POS/certificados/
   tokens/comprobantes/usuarios, y depende de un volumen enorme de clases .fe-*/.panel-card/
   .form-control/.btn/tablas/modales ya definidas y funcionando en styles.css. Reconstruir
   todo eso desde cero (como sí se hizo en Home/Catálogo/APIs) sería exactamente "reescribir
   la aplicación", prohibido explícitamente en el brief. En su lugar: se AÑADE un shell V2
   (header/grid/fluid/tech bar/WhatsApp/fondo) alrededor de la app real SIN TOCARLA, más dos
   ajustes de color puntuales fuera de POS (ver abajo) — todo lo demás (formularios, tablas,
   POS, modales, chips de estado, certificado, tokens) queda con su apariencia EXACTA actual.

   COLISIÓN DE VARIABLES CSS (documentada): home-v2.css y styles.css declaran ambos --ink/
   --muted/--line/--accent-2 con valores distintos en :root. Para que TODA la app real
   (.fe-*, .btn, .form-control, etc.) conserve su apariencia EXACTA de hoy, /styles.css se
   carga DESPUÉS de /home-v2.css (su propio :root gana para todo el documento). Los
   componentes nuevos del shell (header/grid/techbar/WhatsApp) vuelven a declarar los
   tokens V2 LOCALMENTE, scopeados solo a sí mismos — nunca sobre un ancestro de #feAppArea/
   .fe-panel-shell, así que no pueden alterar ni un color de la app real. */
.pf-header,
.pf-techbar,
.pf-wa-float,
#pf-grid,
#pf-glow {
  --ink: #0a0e14;
  --muted: rgba(10,14,20,.62);
  --line: rgba(10,14,20,.10);
  --accent-2: #00a6d6;
}

/* ============ FONDO V2 — mismo gradiente/reset de body.pf (home-v2.css), body conserva
   fe-auth-mode/fe-session-checking exactos (gate de auth intacto, ver <style> inline en el
   <head> del preview, copiado byte a byte del productivo). ============ */
body.pf { min-height: 100vh; }

/* ============ SEGURIDAD 320px — mismo fix ya aprobado (defensivo, sin tocar home-v2.css). ============ */
@media (max-width: 400px) {
  .pf-brandname { display: none; }
}

/* ============ FIX ESTRUCTURAL — overflow horizontal a 1024px (Parte "OVERFLOW 1024") ============
   Causa real identificada leyendo styles.css (líneas 2901-2913, 2962-2966): .fe-welcome-
   character (burbuja/personaje Lottie del login) usa position:absolute + right:-210px +
   width:210px dentro de @media(max-width:1120px) — el elemento se posiciona ÍNTEGRAMENTE
   FUERA del borde derecho de su contenedor (#feLoginNotice), extendiéndose ~210px más allá.
   styles.css YA tiene el mecanismo correcto para esto (display:none) pero solo lo aplica
   por debajo de 900px (@media max-width:900px) — el hueco entre 901-1024px es exactamente
   donde la auditoría midió los 45px de overflow real. Se usa el MISMO mecanismo ya existente
   en styles.css (extender su propio umbral), sin overflow-x:hidden y sin inventar ninguna
   dimensión nueva — no se toca styles.css, el override vive aislado aquí. */
@media (max-width: 1024px) {
  .fe-welcome-character { display: none; }
}

/* ============ BOTONES GENERALES — lima V2, EXCLUYE POS por construcción ============
   Verificado leyendo el HTML real de #fe-tab-pos completo: NINGÚN botón del POS (keypad,
   métodos de pago, categorías, acciones CAJA/CANCELAR/BOLETA/NOTA VENTA/FACTURA, carrito)
   usa la clase genérica .btn — todos usan clases propias (.fe-pos-btn, .caja, .cancelar,
   .boleta, .nota, .factura, .danger, .mic, .price, etc.), definidas aparte en styles.css y
   NO tocadas aquí. Este override solo alcanza botones reales fuera de POS: "Entrar al
   panel", "Guardar configuración", "Probar SUNAT" (secondary, sin cambio), "Nuevo token",
   "Buscar" (comprobantes), "Nuevo usuario", "Guardar usuario", etc. */
.btn:not(.secondary) {
  background: rgb(192, 254, 4);
  color: rgb(0, 0, 0);
  border-radius: 6px;
}
.btn:not(.secondary):hover {
  background: rgb(170, 238, 0);
  transform: translateY(-1px);
}

/* ============ NAV DE MÓDULOS (sidebar) — mismo criterio: no es POS, es navegación de
   panel administrativo. Reemplaza el gradiente azul antiguo del tab activo. ============ */
.fe-side-menu .fe-tab.active,
.fe-module-menu .fe-tab.active {
  background: rgb(192, 254, 4);
  color: rgb(0, 0, 0);
  box-shadow: none;
}
.fe-side-menu .fe-tab.active .fe-tab-icon {
  background: rgba(0,0,0,.12);
  border-color: rgba(0,0,0,.18);
}

/* ============ CHIPS DE ESTADO — NO TOCADOS a propósito ============
   .fe-chip-soft/.fe-chip-ok/.fe-chip-danger son semáforos reales (éxito/error/estado del
   badge de entorno) — se conservan exactamente, sin convertir a lima (brief: "Lima es
   identidad primaria V2, no reemplazo de semáforos"). */

/* ============ ETAPA 2B — CORRECCIÓN VISUAL DEL LOGIN, SCOPE body.fe-auth-mode ============
   TODO lo de este bloque vive bajo el selector body.fe-auth-mode — la MISMA clase que el
   gate de autenticación usa para ocultar #feAppArea. Como fe-auth-mode NUNCA está presente
   a la vez que #feAppArea es visible (se excluyen mutuamente por el propio gate, sin tocar),
   este scope es estructuralmente incapaz de afectar el panel autenticado — no hace falta
   ninguna exclusión manual adicional. Cero cambios en facturacion.js, cero cambios en
   styles.css/home-v2.css: todo resuelto aquí, con override de especificidad normal (misma
   cascada, facturacion-v2.css ya carga después de styles.css). */

/* --- 1) Colisión --ink: restaurar el valor V2 solo mientras el login está visible --- */
body.fe-auth-mode {
  --ink: #0a0e14;
}

/* --- 2) Nav activo azul: la clase .nav-links se QUITÓ del HTML (confirmado por grep: 0
   referencias a "nav-links" en facturacion.js — no es un hook real en esta página, así que
   no hacía falta neutralizar con !important, se eliminó en la fuente). Sin esa clase, la
   regla vieja .nav-links a.active de styles.css deja de aplicar por completo — .pf-nav a
   (home-v2.css) gobierna solo, igual que en Home/Catálogo/APIs V2. También resuelve la
   diferencia de ~6px de alto (venía del padding/border de .nav-links a superpuesto). --- */

/* --- 3) Título del login — equivalente real más cercano en home-v2.css: .pf-story-title
   (encabezado de sección "Nuestra historia"). Se usan sus valores EXACTOS, sin aproximar —
   no existe un h1/hero en home-v2.css que sea apropiado aquí (demasiado grande para una
   card de login), .pf-story-title es el heading real de menor jerarquía disponible. */
body.fe-auth-mode .fe-login-brand h2 {
  font-family: var(--font-display);
  font-size: 25.6px;
  font-weight: 800;
  line-height: normal;
  letter-spacing: -.64px;
  color: var(--ink);
}

/* --- 4) Labels — equivalente real en home-v2.css: .pf-scroll-hint (única etiqueta/eyebrow
   técnica pequeña que existe en ese archivo). Reemplaza el font-weight:1000 heredado de
   .fe-login-form--compact .form-label span (styles.css). --- */
body.fe-auth-mode .fe-login-form--compact .form-label span {
  font-family: var(--font-label);
  font-size: 11px;
  font-weight: 400;
  letter-spacing: .1em;
  text-transform: uppercase;
  color: var(--muted);
}

/* --- 5) Inputs — home-v2.css no tiene <input> (es una landing sin formularios); se aplica
   el MISMO patrón V2 ya usado dos veces en el sitio (catalogo-v2.css .cv2-search / apis-v2.css
   .form-control), derivado de los mismos tokens de home-v2.css (--font-mono/--line/--ink),
   no inventado de cero para esta página. --- */
body.fe-auth-mode .fe-login-form--compact .form-control {
  font-family: var(--font-mono);
  font-weight: 500;
  background: rgba(255,255,255,.7);
  border-color: var(--line);
  border-radius: 10px;
  box-shadow: none;
}
body.fe-auth-mode .fe-login-form--compact .form-control:focus {
  background: rgba(255,255,255,.9);
  border-color: rgb(192, 254, 4);
  box-shadow: 0 0 0 3px rgba(192, 254, 4, .35);
}

/* --- 6) Botón — ya cubierto por el override general .btn:not(.secondary) de más arriba
   (lima/hover/radius/translateY ya aplican a #feLoginBtn, que SÍ tiene class="btn"). Sin
   cambios adicionales aquí; solo se anula el ancho fijo heredado (180px) para que respire
   con el nuevo radius/tipografía, sin tocar min-height/posición. --- */
body.fe-auth-mode .fe-login-form--compact .fe-login-actions .btn {
  font-family: var(--font-label);
  letter-spacing: .06em;
  text-transform: uppercase;
}

/* --- 7) Checkbox "Recordar correo" — mismo #feRememberEmail real, sin tocar comportamiento
   ni reemplazar por div. Solo se aligera el look de sub-card vieja (radius 22px + fondo
   opaco de styles.css) a lenguaje V2 plano (borde var(--line), radius 10px, fondo sutil). --- */
body.fe-auth-mode .fe-login-form--compact .fe-login-remember {
  background: rgba(255,255,255,.5);
  border: 1px solid var(--line);
  border-radius: 10px;
  box-shadow: none;
}
body.fe-auth-mode .fe-login-form--compact .fe-login-remember span {
  font-family: var(--font-mono);
  font-size: 13px;
  color: var(--ink);
}

/* --- 8) Card del login — mismo panel plano ya usado 2 veces en el sitio (.panel-card.api-card
   de apis-v2.css / .product-card de catalogo-v2.css: fondo blanco sólido, borde var(--line),
   radius 18px, sin sombra) en vez del gradiente radial + radius:34px de styles.css. --- */
body.fe-auth-mode .fe-auth-card {
  background: #fff;
  border: 1px solid var(--line);
  border-radius: 18px;
  box-shadow: none;
}

/* --- 9) Burbuja Lottie — solo tipografía/color de borde a lenguaje V2 técnico, SIN tocar
   texto/tamaño/posición (auditoría no midió una reposición justificada; brief Parte 12/13
   prohíbe inventar tamaño/posición). --- */
body.fe-auth-mode .fe-welcome-bubble {
  font-family: var(--font-mono);
  font-weight: 500;
  color: var(--ink);
  border-color: var(--line);
  box-shadow: none;
}
body.fe-auth-mode .fe-welcome-bubble::before {
  border-color: var(--line);
}

/* ============ LOGIN MOBILE — FIX DE CENTRADO BAJO EL HEADER ============
   Causa real confirmada en styles.css:2871-2875 — dentro de @media(max-width:620px), el
   override `body.fe-auth-mode .fe-dashboard-section { align-items:flex-start; padding-
   top:28px; }` reemplaza por completo el centrado real de escritorio (styles.css:2771-2776,
   `min-height:calc(100vh - 82px); display:flex; align-items:center;`) — no se toca esa
   regla base (aprobada, intocable) ni el propio bloque de styles.css (compartido con
   panel.html, que usa la MISMA combinación body.fe-auth-mode + .fe-dashboard-section para
   su propio login — tocar styles.css afectaría también ese panel, fuera de alcance de esta
   página). El fix vive aquí, en facturacion-v2.css (se enlaza DESPUÉS de styles.css en
   facturacion.html), sobrescribiendo solo las 2 propiedades reales del problema para este
   documento.

   Por qué la fórmula base (min-height:calc(100vh-82px) partiendo de y=0) no basta tal cual
   en mobile: .pf-header es position:fixed (no ocupa espacio de flujo) — en desktop el hueco
   de centrado que resulta ya excede por pura geometría los ~82px del header (auditoría:
   ~97.5px arriba/abajo), así que nunca se nota el solape; en un viewport corto ese mismo
   hueco se reduce por debajo de la altura real del header (~76-82px, medidos), y ahí
   aparece el solapamiento (~48px medidos) — el override roto de 620px además cambiaba a
   flex-start con solo 28px, mucho menos que el header.

   Fix: en vez de solo encoger el alto del box y centrar (lo que no garantiza despejar el
   header en viewports cortos), se empuja el contenido hacia abajo con padding-top real del
   header y se centra el espacio RESTANTE — usando 100dvh (viewport dinámico, seguro en
   mobile con barra de direcciones cambiante, sugerido explícitamente en el brief) en vez de
   100vh. El valor 82px NO es nuevo/inventado: es el MISMO número real que ya usa la propia
   regla base de escritorio (styles.css:2772) para esta misma compensación de header, dentro
   del rango medido real de esta etapa (76–82px) — se reutiliza el extremo ya existente en
   el código en vez de introducir un número distinto. `box-sizing:border-box` no se declara
   aparte porque `* { box-sizing:border-box }` (home-v2.css:39, cargado en esta página) ya
   lo aplica globalmente. padding-bottom queda tal cual lo definía el clamp() de la regla
   base (36-80px según viewport) — no se fuerza una igualdad matemática perfecta con el top
   (el brief no la exige), solo que ambos lados queden razonablemente equilibrados dentro
   del área bajo el header, y que nunca se solape con él. Si el card es más alto que el
   área disponible, min-height (no height) permite que la sección crezca y el documento
   haga scroll vertical normal — sin overflow:hidden en ningún punto. */
@media (max-width: 620px) {
  body.fe-auth-mode .fe-dashboard-section {
    align-items: center;
    min-height: 100dvh;
    padding-top: 82px;
  }
}

/* AJUSTE PUNTUAL "fondo blanco en login" (background:#fff + display:none sobre #pf-glow/
   #pf-grid/#pf-fluid) RETIRADO tras auditoría local en navegador real: esas reglas
   suprimían el sistema visual V2 real (body.pf de home-v2.css + los 3 componentes) en vez
   de solo aislar un problema puntual — Catálogo usa ese mismo fondo/sistema con normalidad.
   La causa real del "fondo azul sucio" reportada antes era la AUSENCIA de home-v2-fluid.js
   en este preview (Catálogo sí lo carga) — corregida abajo reutilizando el archivo real,
   sin crear colores/fondos/glows nuevos. */

/* ============ LOGIN LIMPIO SOBRE BLANCO, SIN WHATSAPP (tech bar RESTAURADA) ============
   Auditoría previa (markup real, C:\...\facturacion-v2-preview.html):
   - Fondo celeste: body.pf { background: linear-gradient(160deg,#cfe8f8,#e5f4fc,#f1f9ff); }
     (home-v2.css línea 46) — aplica a CUALQUIER body.pf, incluida esta página.
   - "Glow" azul de fondo: #pf-glow (home-v2.css), resplandor radial que sigue al mouse.
   - Botón flotante: <a class="pf-wa-float"> (markup DIRECTO, no inyectado por JS
     compartido, no es un include) — el usuario NO quiere WhatsApp en Facturación.
   La regla que ocultaba .pf-techbar fue RETIRADA en esta etapa (la barra V2 correcta ya
   existía en el DOM, solo estaba oculta) — ahora vuelve a mostrarse normalmente, poblada
   por home-v2-bottom-meta.js (agregado en esta misma etapa, ver facturacion-v2-preview.html).

   Scopear a body.fe-auth-mode aquí NO afecta Home/Catálogo/APIs — esa combinación de clase
   de body no existe en ninguna de esas páginas (markup propio de esta página).

   #pf-grid y #pf-fluid NO se tocan (ninguno es "celeste"/"azulado" por sí mismo). */
body.fe-auth-mode {
  background: #fff;
}
body.fe-auth-mode #pf-glow {
  display: none;
}
body.fe-auth-mode .pf-wa-float {
  display: none;
}

/* ============ STICKERS QUE CAEN — CONTENEDOR #pfFooter (SOLO login) ============
   home-v2-footer-decor.js exige DOS elementos reales para no retornar temprano (líneas
   71-73 del script): #pfFooter (fuente de showCnt vía getBoundingClientRect().top +
   clientWidth/clientHeight) y el canvas #pf-footer-decor dentro de él. En Home, #pfFooter
   es una sección de scroll (class="pf-footer", min-height:100dvh, position:relative) que
   se revela progresivamente. Facturación login es una sola pantalla SIN scroll (por
   diseño, ver corrección de "scroll sobrante" de otra etapa) — no hay una sección que
   "entre a la vista" haciendo scroll. Para que la MISMA fórmula (sin tocar el script)
   evalúe showCnt≈1 desde el primer frame, #pfFooter se posiciona aquí como overlay fijo de
   viewport completo — mismo patrón position:fixed;inset:0 ya usado por #pf-grid/#pf-glow/
   #pf-fluid, SIN z-index propio (pinta detrás del contenido por orden de DOM, ya que se
   inserta junto a esos 3 al inicio del body). Oculto por defecto (fuera del estado de
   login) para cumplir "stickers solo en login, nunca en el panel autenticado". */
.pf-footer-decor-wrap {
  display: none;
}
body.fe-auth-mode .pf-footer-decor-wrap {
  display: block;
  position: fixed;
  inset: 0;
  pointer-events: none;
}
/* .pf-footer-decor (canvas) reutiliza la clase real de home-v2.css sin overrides: ya trae
   position:absolute;inset:0;pointer-events:none;sin z-index propio — no se repite aquí. */
