Informe de inconsistencias · Fase 1 · Modo oscuro LPDI
Auditoría read-only previa a implementar. Cero código tocado (Regla Cero respetada). Es el gate antes de escribir una sola línea.
24 de julio de 2026 · repo lpdi-relacionamiento · fuentes: handoff de diseño + DESIGN.md (§0, §2, §4, §5, §12, §V.2, §15) + app.css + muestra real de componentes.
Magnitud real. Alrededor de 2.373 hex de 4 a 6 dígitos mas ~300 #fff hardcodeados en src/ fuera de app.css. Voltear los tokens NO alcanza: el trabajo de fondo es migrar hex a variables. 10 focos concentran ~70%: los 6 form shells (~681), perks.css (180), eventos.css (91), UserProfileView (144), ecosistema/+page (164), 4 tablas admin y 3 modales de cuenta.
(a) Hex hardcodeados que rompen en dark, por patrón
Patrón
Líneas
Token destino
#fff (fondos)
300
--bg-surface (datos) o vidrio (chrome)
#ffffff
26
ídem
#f4f7fb (fondo página)
24
--bg-base / .app-shell
#003e88 (titular navy)
104
--text-primary
#64748b + #6b7d94
101
--text-muted
#ef4444 + #dc2626
178
--danger (salvo semáforo §5)
#c0392b
39
⚠️ conflicto §15 (ver pregunta 3)
#e2e8f0 (bordes)
87
--border
#f8fafc/#f1f5f9 (hover/thead)
51
--bg-elevated / --bg-base
Slate dark VIEJO (#1e293b/#334155/#94a3b8/#3b82f6)
147
quedaría slate-sobre-navy (ver hallazgo mayor)
Clusters, de mayor a menor impacto
Form shells (~681 hex): los 6 formularios de startup/ICG/usuario/evento. Predomina #fff en cards e inputs, #ef4444 de validación (marco canónico, NO se toca) y overrides dark propios en slate.
CSS compartidos (~271): perks.css (180) y eventos.css (91). Un fix aquí propaga a todos los beneficios y páginas de eventos.
Superficies de marca públicas (~300+): hub /ecosistema (164 hex vs solo 5 variables), landing, registros. Hoy ya reciben dark porque el tema se aplica global, y quedan a medio voltear.
Profile views (~247): usan la gama gray de Tailwind que la tabla del handoff no mapea.
Modales (~200): eliminar cuenta/entidad, transferir, papelera, QR. Hex destructivos por diseño (la tabla del handoff les da equivalentes dark).
Shell del dashboard: sidebar y topbar ya usan variables → voltean solos; el vidrio es una capa adicional.
(b) Contradicciones con DESIGN.md
#
Hallazgo
1
§0.2 fija el acento dark en #3b82f6; el handoff lo cambia a #4E97FF. Hay que actualizar §0.2 también, no solo §2.
2
DESIGN.md §2 no documenta--danger/--shadow dark (hoy dark hereda el rojo claro y una sombra azul invisible, justo lo que el handoff corrige).
3
Acento indigo fuera de familia: admin/legal y auditoría usan #4f46e5 (uno directo en .chan-email). Viola la regla de familia azul.
4
Conflicto real §3 vs §15: la tabla del handoff manda #c0392b → var(--danger), pero §15.1/§15.2 fijan #c0392b por diseño. Migrarlo cambiaría el tema CLARO aprobado. Ver pregunta 3.
5
.pill-btn global en app.css está estilizado solo para dark con hex viejos (no consume tokens, no voltea).
(c) Choques handoff ↔ código existente
⚠️ El mayor (no previsto por el handoff):~12 a 15 archivos ya tienen sus propios bloques [data-theme="dark"] escritos con la paleta slate vieja hardcodeada (incluye los 6 form shells y el propio EventEditModal). Cambiar solo el bloque de tokens deja cards y banners slate flotando sobre navy. Es trabajo adicional al descrito en el handoff: hay que reescribir esos overrides.
Tema
Verificado
--quick-* (quick cards)
Tienen versión dark en app.css y el handoff §2 no las incluye: al reemplazar el bloque perderían su dark. (--bg-elevated sí está cubierto por el handoff.)
.app-shell
Existe solo en el dashboard, no en el hub /ecosistema. El degradado del handoff requeriría introducir la clase ahí.
.sidebar / .topbar
Existen con esos nombres, pero la regla global de vidrio [data-theme="dark"] .sidebarcolisiona con la sidebar de filtros de eventos (misma clase, y es superficie de datos, no chrome).
backdrop-filter en modales
Ya existe blur en 5 overlays (eliminar cuenta/entidad, transferir, papelera, QR), contra la letra del handoff. Matiz: está en el propio overlay fixed, así que no rompe el anclaje de §V.2.
EventEditModal
Existe y es viable como plantilla. Los modales de Convocatorias/Noticias aún no existen (§15.10 los describe a futuro): hoy "adaptar los tres" es adaptar uno.
Gama gray Tailwind, rgba(255,…), chips de categoría, verdes de perks
La tabla §3 no los cubre: cada familia requiere criterio, no búsqueda-y-reemplazo.
(d) Preguntas para Frank gate de decisión
Cada una trae mi recomendación para que puedas aprobar rápido. Ante la duda: no cambio y pregunto.
1. Alcance real de "toda la plataforma"
¿Entran las superficies públicas (landing /, hub /ecosistema, /registro-*, catálogo público de beneficios) o solo el área autenticada (dashboard + formularios internos)? Hoy esas páginas ya reciben dark (el tema se aplica global) pero están casi 100% en hex de marca fijos.
Recomendación: Ola 1 el área autenticada (donde está el bug y el uso real). Las públicas: forzarlas a claro por ahora y migrarlas en una ola 2 dedicada, para no frenar esto.
2. Quick cards del dashboard (--quick-*)
El bloque nuevo de tokens no las trae. ¿Conservamos las 4 variantes dark actuales, las re-derivamos sobre navy, o las eliminamos?
Recomendación: re-derivarlas sobre navy (coherencia con el resto) y sumarlas al bloque de tokens.
3. Colores semánticos fijos §15 (#c0392b y compañía) vs var(--danger)
Migrar #c0392b → var(--danger) cambia también el tema CLARO aprobado (--danger claro es #ef4444).
Recomendación: token nuevo --danger-strong = #c0392b en claro y un rojo elevado en dark. Así el claro no cambia y el dark queda legible. Los demás fijos de §15 se mantienen como el semáforo.
4. backdrop-filter ya presente en 5 modales
¿Se retira para cumplir "nunca vidrio en modales", o se conserva (técnicamente no rompe el anclaje por estar en el propio overlay)?
Recomendación: conservarlo (no rompe nada y ya está aprobado visualmente); solo lo documentamos como excepción tolerada.
5. Selector del vidrio del chrome
[data-theme="dark"] .sidebar global golpearía también la sidebar de filtros de eventos.
Recomendación: acotar el vidrio a una clase dedicada (.chrome-glass) en el layout del dashboard, e introducir .app-shell en el hub solo si apruebas la pregunta 1.
6. Reescribir los ~12 a 15 overrides dark en slate viejo
Incluye los 6 form shells y EventEditModal. Sin esto, cambiar los tokens deja slate sobre navy.
Recomendación: sí, entran en esta misma ola (es lo que de verdad arregla el dark). Es el grueso del trabajo real.