/* ==========================================================================
TEMA NUEVO — reglas que USAN los tokens de app.tokens.css
==========================================================================
ESTA HOJA SÓLO CARGA EN LOCAL, a propósito (ver `layouts/app.blade.php`).
Es el borrador del rediseño: acá se prueba cómo queda la plataforma con la
paleta nueva sin que producción se entere. Cuando esté aprobado se saca el
`@if` del layout y pasa a cargar en los dos lados.
POR QUÉ DOS HOJAS Y NO UNA. `app.tokens.css` sólo declara variables y carga
SIEMPRE, también en producción. Si los tokens estuvieran gateados y una
regla de `app.custom.css` usara `var(--cb-marca)`, en producción esa
variable no existiría, **la declaración entera se volvería inválida** y el
color se perdería. Declarar siempre y pintar sólo en local es lo que hace
que esto no pueda romper nada.
CÓMO SE AGREGA UNA REGLA ACÁ. Se copia el selector de `app.custom.css` o del
tema, y se reemplaza el hex por el token. Nada más — como esta hoja carga
última, gana sin necesidad de `!important`.
========================================================================== */
/* Todavía vacía: los tokens están definidos y esta hoja es donde se van a
escribir las reglas que los usen, de a una y comparando contra la actual.
La pantalla de referencia es /config/system/paleta. */
/* --------------------------------------------------------------------------
1) EL ACENTO: de azul a verde
--------------------------------------------------------------------------
El tema comprado pinta `.btn-primary` y los links con `#2949ef`. Acá se
reemplaza por el token, sin tocar el tema — esta hoja carga última, así que
gana sin `!important`.
Los links usan `--cb-marca-oscuro` y no `--cb-marca`: el verde claro sobre
blanco da 3,65:1 y para texto chico hace falta 4,5. El oscuro da 8,42:1 y se
lee como el mismo verde.
-------------------------------------------------------------------------- */
a {
color: var(--cb-marca-oscuro);
}
a:hover,
a:focus {
color: var(--cb-marca-hover);
}
.btn-primary,
.btn-primary:disabled,
.btn-primary.disabled {
color: var(--cb-marca-contraste);
background-color: var(--cb-marca);
border-color: var(--cb-marca);
}
.btn-primary:hover,
.btn-primary:focus,
.btn-primary.focus,
.btn-primary:not(:disabled):not(.disabled):active,
.btn-primary:not(:disabled):not(.disabled).active {
color: var(--cb-marca-contraste);
background-color: var(--cb-marca-hover);
border-color: var(--cb-marca-hover);
}
/* El foco del tema deja un halo azul que delata el color viejo. */
.btn-primary:focus,
.btn-primary.focus {
box-shadow: 0 0 0 .2rem rgba(0, 153, 102, .35);
}
/* Pedido por Miguel el 2026-08-22: los outline en verde por default hacían que
el mismo botón —"Suscribirme", "Cambiar plan"— se viera azul en Cursos (que
ya tenía una regla puntual) y verde en cualquier otra pantalla que no la
tuviera, por ejemplo `subscriptionPlans.blade.php` incluido en `/research` o
el dashboard. `.btn-outline-primary` se usa en unas 80 vistas del panel, así
que en vez de seguir agregando una regla por ruta, el default pasa a azul
—el mismo `--cb-secundario` de `.btn-outline-secondary`— y con eso se
resuelve para todo el panel de una vez. Las reglas puntuales que ya
convertían pantallas sueltas (Cursos, Grupos, Suscripciones) quedan
redundantes pero no rompen nada: dicen lo mismo. */
.btn-outline-primary {
color: var(--cb-secundario);
border-color: var(--cb-secundario);
background-color: transparent;
}
.btn-outline-primary:hover,
.btn-outline-primary:focus,
.btn-outline-primary:not(:disabled):not(.disabled):active {
color: var(--cb-secundario-contraste);
background-color: var(--cb-secundario);
border-color: var(--cb-secundario);
}
.text-primary { color: var(--cb-marca-oscuro) !important; }
.bg-primary { background-color: var(--cb-marca) !important; }
.border-primary { border-color: var(--cb-marca) !important; }
/* --------------------------------------------------------------------------
2) LOS ESTADOS, unificados
--------------------------------------------------------------------------
Acá está la mitad del problema que se midió: el tema pinta `.badge-success`
de TURQUESA (`#06b5b6`) mientras las vistas usan `#28a745` y `#4caf50` a
mano para lo mismo. Tres verdes para un solo significado.
-------------------------------------------------------------------------- */
/* LOS BADGES LLEVAN TEXTO BLANCO, no `-contraste`. Esos tokens están pensados
para el fondo SUAVE, no para el sólido, y acá quedaban ilegibles: el de info
daba **2,35:1** (`#0d47a1` sobre el azul) — literalmente no se leía.
El blanco da 3,68:1 en info, 3,13:1 en ok y 4,53:1 en danger. El de alerta es
el caso incómodo —blanco 1,97:1 contra 3,17:1 del oscuro— pero se decidió el
texto blanco en los alerts por consistencia, así que los badges siguen el
mismo criterio.
El nombre del token es lo que confunde: `-contraste` debería significar
"texto sobre el color sólido" y en alerta e info significa "sobre el suave".
Vale renombrarlo cuando se limpie esto. */
.badge-success, .bg-success { background-color: var(--cb-ok) !important; color: #fff !important; }
.badge-warning, .bg-warning { background-color: var(--cb-alerta) !important; color: #fff !important; }
.badge-danger, .bg-danger { background-color: var(--cb-error) !important; color: #fff !important; }
.badge-info, .bg-info { background-color: var(--cb-info) !important; color: #fff !important; }
.text-success { color: var(--cb-ok) !important; }
.text-warning { color: var(--cb-alerta) !important; }
.text-danger { color: var(--cb-error) !important; }
.text-info { color: var(--cb-info) !important; }
.btn-success { background-color: var(--cb-ok); border-color: var(--cb-ok); color: var(--cb-ok-contraste); }
.btn-danger { background-color: var(--cb-error); border-color: var(--cb-error); color: var(--cb-error-contraste); }
.btn-warning { background-color: var(--cb-alerta); border-color: var(--cb-alerta); color: var(--cb-alerta-contraste); }
/* --------------------------------------------------------------------------
LOS ALERTS: fondo sólido, texto BLANCO — oscureciendo el fondo
--------------------------------------------------------------------------
Decidido por Miguel: **el texto va en blanco y el fondo queda como estaba**,
el sólido del tema. Se probó oscurecer los fondos para alcanzar 4,5:1 y se
volvió atrás — se veían apagados.
Queda anotado el dato, medido: sobre el naranja del tema el blanco da
**1,97:1**, sobre el verde 3,13:1 y sobre el azul 3,68:1. El rojo es el único
que pasa (4,53:1). Es el estado que ya tenía la app desde antes de todo esto;
lo que sí se arregla acá es que **las 24 vistas queden parejas**, traigan o no
`text-white` en el markup.
-------------------------------------------------------------------------- */
.alert-warning, .alert-warning .text-white, .alert-warning.text-white,
.alert-success, .alert-success .text-white, .alert-success.text-white,
.alert-info, .alert-info .text-white, .alert-info.text-white,
.alert-danger, .alert-danger .text-white, .alert-danger.text-white {
color: #ffffff !important;
}
/* Los enlaces dentro de un alert siguen al texto: si no se van al verde de
marca, que sobre estos fondos no se lee. */
.alert-warning a, .alert-success a, .alert-info a, .alert-danger a {
color: inherit;
text-decoration: underline;
}
/* NOTA: el fondo lo maneja el tema tokenizado, con fondo SÓLIDO.
Se probó pasarlos a fondo suave con texto oscuro y quedó ilegible: el tema los
pinta llenos —naranja, rojo, verde— y por eso **5 vistas les agregan
`text-white`** (`home_user`, `allPost`, `cards-video`, los dos `faq` de
Balanz). Ese `text-white` le gana al `color` de la regla, así que el fondo
claro dejaba texto blanco sobre casi-blanco.
Cambiarlos de verdad significa sacar el `text-white` de esas vistas primero.
Mientras tanto, el color sale igual de los tokens: el tema ya dice
`background-color: var(--cb-alerta)`. */
/* --------------------------------------------------------------------------
3) SUPERFICIES
--------------------------------------------------------------------------
El fondo de la página y el de las cards salen de los tokens, así el modo
oscuro no necesita una regla propia: se redefine la variable y listo.
-------------------------------------------------------------------------- */
body {
background-color: var(--cb-fondo);
color: var(--cb-texto);
border-top-color: var(--cb-marca);
}
.card {
background-color: var(--cb-superficie);
border-color: var(--cb-borde);
}
.table th,
.table td { border-color: var(--cb-borde); }
/* EL ENCABEZADO DE TABLA va en el azul de marca con letra blanca. Antes era
`--cb-gris-200` con texto gris —el del tema—, que sobre el fondo claro del
área casi no se separaba de las filas. El azul le da un techo claro a la
tabla, y es coherente con la barra lateral: el azul es la estructura.
Se cubren las tres variantes porque en las vistas sólo se usa `thead-light`
(24 tablas), pero el día que alguien copie un `thead-dark` de la documentación
del tema va a quedar igual. Blanco sobre el azul da 15,97:1. */
.thead-light th,
.thead-dark th,
.thead-primary th,
.table .thead-light th,
.table .thead-dark th,
.table .thead-primary th {
background-color: var(--cb-secundario);
color: var(--cb-secundario-contraste);
border-color: var(--cb-secundario-hover);
}
.text-muted { color: var(--cb-texto-suave) !important; }
/* --------------------------------------------------------------------------
4) LOS ICONOS DECORATIVOS NO SON ADVERTENCIAS
--------------------------------------------------------------------------
El tema usa `.text-warning` como color de adorno, no por su significado: de
los 144 `data-widget-icon` de las vistas, **142 llevan `text-warning`** y
ninguno advierte nada — son el ícono del widget (un carrito, un signo peso,
una gente). Con el naranja del token quedaban gritando en cada dashboard.
Pasan al color de marca, que es lo que son: un adorno con la identidad de la
app.
`.text-warning` NO se toca en general, porque sí hay advertencias de verdad
usándolo — son dos: `ft-alert-triangle` y `fa-exclamation-triangle`. Ésas
tienen que seguir naranjas. De ahí que el selector sea la combinación y no
la clase sola.
-------------------------------------------------------------------------- */
.data-widget-icon.text-warning,
i.font-40.text-warning {
color: var(--cb-marca) !important;
}
/* --------------------------------------------------------------------------
5) EL ÁREA DE CONTENIDO
--------------------------------------------------------------------------
Pedido por Miguel el 2026-08-21: **`#eaedfd`** en modo claro — un lavanda muy
claro, que tiene su propio token (`--cb-area`) porque no pertenece a la
familia del verde.
Y es el mejor ejemplo de para qué sirve todo esto. Hoy ese mismo fondo está
escrito DOS veces en DOS archivos:
app.custom.css:9 → #ebebeb (claro)
app.dark-mode.css:196 → #0f172b (oscuro)
Acá es UNA regla. El modo oscuro sale gratis porque `--cb-area` ya vale
`#0f172b` bajo `body.dark` — el mismo que usa hoy. Cuando esto se apruebe,
las dos reglas viejas se borran.
La transición se conserva: viene del dark mode y suaviza el cambio de tema.
-------------------------------------------------------------------------- */
.content-area {
background-color: var(--cb-area);
-webkit-transition: 0.3s ease all;
transition: 0.3s ease all;
}
/* --------------------------------------------------------------------------
6) UNA SOLA FORMA DE BOTÓN
--------------------------------------------------------------------------
Medido el 2026-08-21: de los 1.105 botones de las vistas, **939 son cuadrados
(radio 0, el del tema) y 166 son píldora** (`.btn-rounded`, radio 50px) — en
94 archivos. No son dos estilos parecidos que chocan: son los dos extremos.
Se unifica desde acá y no borrando la clase de los 94 archivos, por dos
razones: es reversible de una línea, y `.btn-rounded` sigue existiendo por si
algún día se quiere la píldora a propósito en algún lugar puntual.
DECIDIDO: **`.6rem` para todo** (9,6px), el radio que el tema ya le daba a las
cards y los modales. Antes convivían cuatro: cards y modales a `.6rem`,
controles a `.25rem`, botones a 0 y los 166 `.btn-rounded` a 50px.
Con los botones en 0 y los inputs en 4px, un botón al lado de un input en el
mismo formulario se veía desparejo — que es lo que motivó unificarlos.
ES UN SOLO NÚMERO. `.25rem` lo lleva al radio de los controles del tema y `0`
vuelve todo cuadrado. Se prueba y se decide mirando.
-------------------------------------------------------------------------- */
:root {
--cb-radio-boton: .6rem;
}
.btn,
.btn-rounded,
.btn-group > .btn,
.input-group .btn {
border-radius: var(--cb-radio-boton) !important;
}
/* Los grupos de botones pegados no llevan radio en los lados que se tocan, o se
ve una muesca entre uno y otro. */
.btn-group > .btn:not(:last-child),
.btn-group > .btn:not(:last-child) .dropdown-toggle {
border-top-right-radius: 0 !important;
border-bottom-right-radius: 0 !important;
}
.btn-group > .btn:not(:first-child) {
border-top-left-radius: 0 !important;
border-bottom-left-radius: 0 !important;
}
/* Los CONTENEDORES y los CONTROLES comparten el radio, que es lo que pedía el
ojo: una card a `.6rem` con inputs a `.25rem` adentro se lee como dos
sistemas. Se toma el de las cards, que es el más redondeado de los dos. */
.card,
.modal-content,
.form-control,
.custom-select,
.input-group-text,
.badge,
.alert {
border-radius: var(--cb-radio-boton);
}
/* --------------------------------------------------------------------------
7) LA BARRA DE "ESTÁS EN LOCAL"
--------------------------------------------------------------------------
El aviso de entorno era rojo (`#fe4d2e`), que es el mismo tono que la app usa
para errores — leía como "algo se rompió" cuando sólo dice "estás en local".
Pasa al verde de marca.
El color vive INLINE en `partials/navbar.blade.php`, dentro de un
`@env('local')`, así que ese atributo ni se imprime en producción. Acá sólo
se acompaña el modo oscuro, que sí tenía su propia regla (`#741909`, el rojo
apagado) en `app.dark-mode.css:245`.
-------------------------------------------------------------------------- */
body.dark .header.local-env-header {
background-color: var(--cb-marca-suave) !important;
}
/* --------------------------------------------------------------------------
8) EL ÍTEM ACTIVO DEL MENÚ
--------------------------------------------------------------------------
Era `#043263` —un azul marino— tanto en `.mm-active` como en el `:hover` del
menú, así que "dónde estoy" y "dónde tengo el mouse" se veían **igual**.
Ahora el activo lleva el verde de marca y el hover una versión más tenue, que
es lo que hace que se distingan.
El color venía de `app.custom.css:44`, y en `app.dark-mode.css` la misma regla
está escrita DOS veces, idéntica (líneas 257 y 269) — otro caso de lo que los
tokens vienen a evitar.
-------------------------------------------------------------------------- */
/* SE PINTA EL RENGLÓN DEL LINK, NO EL `li`.
Un ítem con submenú es `
`: al
pintar el `li`, se pintaba **el bloque entero con el submenú adentro** y el
menú de Cursos quedaba todo verde al abrirlo. */
.sidebar-menu li.mm-active {
background-color: transparent;
}
.sidebar-menu li.mm-active > a {
background-color: var(--cb-marca);
color: var(--cb-marca-contraste);
}
/* EL PADRE DE UN SUBMENÚ ABIERTO no es "dónde estoy", es "por dónde llegué":
lleva el mismo realce que el hover, no el verde. `metisMenu` le pone
`mm-active` igual que al hijo, y la única forma de distinguirlos es que el
padre contiene un `