/* Nexus · tokens de marca — FUENTE ÚNICA Creado 2026-08-27 (sdd/brand-tokens-single-source). Antes de este archivo, los tokens estaban definidos TRES veces por separado (`main/src/styles.css`, `costeo/index.html`, `portal/src/styles.css`) y `plan/index.html` no los definía: usaba hex literales. Los valores coincidían por suerte, no por diseño — nada los mantenía sincronizados, y esa era la causa estructural de la deriva visual entre módulos (`openspec/system-parity-audit-2026-08-27.md` §2.2). ── CÓMO SE CARGA ────────────────────────────────────────────────────────── Con `` desde los CUATRO `index.html`, hermano de `/fonts/fonts.css` y con el mismo criterio: es el patrón que ya resolvió la tipografía en `47a596b`. No es un `@import` desde el CSS de cada módulo porque Costeo y Plan **no tienen** archivo CSS —su estilo vive inline en el ``— y un `@import` además haría que Vite copiase los tokens dentro de cada bundle, que es justo lo que este archivo viene a evitar. El `` va ANTES de los estilos del módulo. Las propiedades personalizadas de igual especificidad se resuelven por orden de documento, así que si algún módulo necesitara sobrescribir un token algún día, debe poder. Hoy ninguno lo hace. ── REGLA QUE NO HAY QUE RE-DECIDIR ──────────────────────────────────────── NO volver a declarar estos tokens en el `:root` de un módulo. Ganaría la última definición por orden de documento y este archivo quedaría decorativo — el mismo modo de fallo silencioso que `CLAUDE.md` §11.1 describe para un segundo `@font-face` que anula el `size-adjust`. Lo que SÍ es correcto: que un módulo defina tokens PROPIOS, los que solo él usa. Hoy `costeo` conserva `--border` y `--accent-gold`; `portal` conserva `--line-soft` y `--shadow`. */ :root { /* ── Paleta institucional (Brand Book v2.1) ──────────────────────────── */ --deep-navy: #2C3E50; /* titulares y superficies oscuras */ --charcoal: #4A4A4A; /* texto de cuerpo sobre superficie clara */ --brand-blue: #91BDE4; /* acento: líneas, marcadores de sección */ --light-blue: #BEE2FC; /* lavados de fondo, rellenos de gráfico */ --warm-cream: #F9F6F0; /* fondo de página */ --warm-tan: #DCC9A6; /* divisores, bordes de acento */ --warm-tan-dark: #B8894E; /* oro de acción */ --coral: #F5B7A7; /* solo el isotipo */ /* Los dos siguientes ya se usaban, escritos a mano en las hojas de los modulos: `#1A2332` en el hover de `.cta-link` del Connect y como `theme-color` de los cuatro index.html, y `#5B8FB0` en el extremo oscuro de tres degradados de avatar. Se promueven a token el 2026-08-28 por la regla 3.7 -- mismos valores exactos, ningun cambio visual. */ --deep-navy-dark: #1A2332; /* navy del hover y del theme-color del navegador */ --brand-blue-deep: #5B8FB0; /* extremo oscuro de los degradados de acento */ /* ── Primer plano sobre superficie OSCURA ─────────────────────────────── El par que le faltaba al sistema, y el origen de un defecto real: `body` fija `color: var(--charcoal)` para la página crema, y una superficie oscura como `.pl-shell` de Costeo cambia el fondo SIN cambiar el primer plano. Cualquier icono con `stroke="currentColor"` dentro de ella heredaba el color de la superficie equivocada y quedaba invisible (medido: ΔLum 1.1 en el engranaje de la píldora de usuario). `--on-dark-soft` vale exactamente lo que ya usaba a mano el texto vecino del nombre de usuario (`costeo/src/app.jsx`), así que adoptarlo no cambia ningún color existente: solo le da nombre. */ --on-dark: rgba(255, 255, 255, 0.92); --on-dark-soft: rgba(255, 255, 255, 0.7); /* ── Derivados compartidos por dos o más módulos ─────────────────────── */ /* `--soft-cream`, `--warm-tan-soft` y `--muted` se promovieron desde `main/src/styles.css` en sdd/staff-chrome-unification fase A: el chrome compartido (`/brand/chrome.css`) los usa para el borde de la cabecera y del pie, el fondo del pie y su color de texto. Si el chrome es compartido, sus tokens lo son por definicion. */ --soft-cream: #FBF9F4; --warm-tan-soft: rgba(220, 201, 166, 0.45); --muted: #9AA5B1; --line: rgba(220, 201, 166, 0.5); /* `--tan-wash` se promovió desde `main/src/styles.css` en fase C-bis (2026-08-27): lo usa `.header-icon-btn:hover` de `/brand/chrome.css`, que Costeo y Plan enlazan igual que `main`. */ --tan-wash: rgba(220, 201, 166, 0.18); --shadow-lifted: 0 4px 16px rgba(44, 62, 80, 0.06); --ease: cubic-bezier(0.16, 1, 0.3, 1); /* ── Primer plano LEGIBLE sobre superficie clara ─────────────────────────── Promovidos en sdd/staff-chrome-unification fase J (2026-08-27), al medir el contraste real del chrome antes de extenderlo a Plan. Tres colores que el marco usaba como TEXTO no llegaban al 4.5:1 que pide WCAG AA para texto normal, medido sobre el fondo que de verdad se pinta detras: #9AA5B1 (--muted) sobre --soft-cream ... 2.38:1 pie, "Salir" #91BDE4 (--brand-blue) sobre #fff ...... 1.98:1 .user-pill-role #B8894E (--warm-tan-dark) sobre crema .. 2.97:1 .nexus-back-pill #8C8775 literal sobre --soft-cream ..... 3.42:1 .app-version Los cuatro son texto pequeno (0.6-0.75rem), varios en mayusculas, asi que el umbral aplicable es 4.5:1 y no el 3:1 de texto grande. El hallazgo invierte una suposicion que costo verificar: el hero NAVY de Plan estaba a 9.61:1, mejor que el chrome crema al que se estaba migrando. Sin estos tokens, unificar habria cambiado un problema estetico por uno de lectura. Cada valor se obtuvo escalando el ORIGINAL hacia el negro en pasos de 1% hasta cruzar 4.5:1 -- se conserva el matiz de marca, solo baja la luminosidad. Son variantes de texto: `--muted`, `--brand-blue` y `--warm-tan-dark` siguen valiendo tal cual para bordes, rellenos e iconos decorativos, donde el umbral es otro. No sustituirlos a ciegas. Cada valor se calibro contra `--warm-cream` (#F9F6F0), la superficie mas OSCURA de la familia crema, no contra la mas clara: el chrome se pinta sobre las tres (#fff en la pildora, --soft-cream en el pie, --warm-cream en el cuerpo) y el contraste BAJA cuanto mas oscuro es el fondo. Calibrar contra `--soft-cream` daba 4.51:1 ahi y 4.40:1 sobre `--warm-cream`: por debajo del umbral justo en la superficie mas comun de la aplicacion. Los tres ratios, medidos: */ --ink-muted: #6A727A; /* crema 4.53 · soft 4.64 · blanco 4.88 · texto secundario */ --brand-blue-ink: #58738B; /* crema 4.59 · soft 4.71 · blanco 4.95 · acento como TEXTO */ /* #8E693C pasaba contra la superficie crema desnuda (4.60:1), pero el barrido en navegador lo midio a 4.37:1 en su uso REAL: el pill "<- Nexus" tiene su propio fondo tan al 18% compuesto sobre la barra al 92% sobre el crema, y ese apilado es mas oscuro que el crema solo. Se baja al valor que aguanta ese caso -- 5.14:1 sobre crema, 5.27 sobre soft-crema, 5.55 sobre blanco. Es la misma leccion que con `--ink-muted`: calibrar contra la superficie mas oscura donde el color se va a pintar de verdad, no contra la mas clara. */ --warm-tan-ink: #846238; /* crema 5.14 · soft 5.27 · blanco 5.55 · oro como TEXTO */ /* Anillo de foco del chrome. Un solo valor para los cuatro modulos: antes de la fase J, `chrome.css` tenia CERO reglas `:focus-visible` -- ningun control del marco de staff (logo, campana, menu admin, pildora, Salir) mostraba donde estaba el teclado. */ /* Se declara como COLOR y se consume con `outline`, no como `box-shadow` de dos anillos: un `box-shadow` lo recorta cualquier ancestro con `overflow: hidden` (la pildora, el panel del menu admin y la barra de pestanas de Plan lo tienen), y ahi el foco desapareceria justo en los controles que mas lo necesitan. `outline` no participa del recorte ni del layout. 4.60:1 sobre crema -- por encima del 3:1 que WCAG 2.2 pide a un indicador de foco. */ --focus-ring-color: var(--warm-tan-ink); }