# RECOMENDACIONES.md
**Proyecto:** lostalo.sgecr  
**Fase:** 3 — Respuestas a las decisiones previas  
**Fecha:** 2026-04-09

---

## DECISIÓN 1: ¿Consolidar los ~26 CSS en menos archivos?

### Veredicto: ✅ SÍ CONSOLIDAR — con estrategia en dos capas

**Justificación:**  
12 de los 26 archivos son clones con ~80% de código idéntico (`:root`, `body`, `main`, `.container_report`, `.actions`, `.pagination`, `.message`). Mantener esto separado significa que cualquier cambio de color o tipografía debe aplicarse en 12 lugares.

### Estructura propuesta

```
public/css/
│
├── core.css           ← NUEVO (reemplaza el :root/:body/main duplicado en 12 archivos)
│                         Variables CSS, body, main, .container_report, .inner-container_report,
│                         .actions, .pagination, .message, .button-container
│
├── tablas.css         ← NUEVO (absorbe styles_tablas.css + patrones de tabla repetidos)
│                         table, th, td, tr:hover, .table-container
│
├── buttons.css        ← MANTENER (ya está bien, solo actualizar colores)
│
├── modal.css          ← MANTENER (ya está bien, es pequeño y limpio)
│
├── login.css          ← MANTENER (completamente scoped, no toca nada global)
│
├── auth_forms.css     ← MANTENER (idem)
│
├── estilo_titulos.css ← MANTENER (h1/h2/footer, pequeño)
│
├── fonts.css          ← MANTENER
│
├── [página].css       ← REDUCIDO — solo columnas nth-child específicas de cada tabla
│   empleados.css          (~30 líneas reales de contenido único)
│   usuarios.css           (~35 líneas)
│   feriados.css           (~25 líneas)
│   tipos.css              (~25 líneas)
│   oficinas.css           (~25 líneas)
│   externos.css           (~25 líneas)
│   mantenimiento.css      (~25 líneas)
│   accesoweb.css          (~25 líneas)
│   dialibre.css           (~25 líneas)
│   saldo_vacaciones.css   (~25 líneas)
│   admin_usuarios.css     (~25 líneas)
│   styles_baja.css        (~60 líneas)
│   styles_admin.css       (~60 líneas)
│   estilo_solicitudesbaja.css (~50 líneas)
│   estilo_reportes.css    (por evaluar)
│   estilo_reportebaja.css (por evaluar)
│   estilo_reportemarca.css (por evaluar)
│   styles_marca.css       (por evaluar)
```

### Orden de carga en cada página PHP

```html
<link rel="stylesheet" href="css/core.css">
<link rel="stylesheet" href="css/tablas.css">
<link rel="stylesheet" href="css/buttons.css">
<link rel="stylesheet" href="css/empleados.css">  ← solo el específico de esa página
```

### Riesgo de la consolidación

| Riesgo | Nivel | Mitigación |
|---|---|---|
| `button {}` definido en core.css puede ser sobreescrito por CSS de página | MEDIO | CSS de página no define `button {}` base, solo variantes específicas |
| `input, select` agresivo en algunos archivos | MEDIO | Mover al core solo la versión segura (`width: auto`), no la global (`width: 100%`) |
| Orden de carga entre core.css y página-específica | BAJO | Siempre cargar core.css primero |
| `.container` vs `.container_report` — dos tokens para lo mismo | BAJO | Unificar como `.container_report` (ya es el más usado) |

**Conclusión: consolidar es SEGURO si se hace en este orden:**
1. Crear `core.css` + `tablas.css` 
2. Validar una sola página visualmente
3. Reducir los archivos de página
4. Nunca tocar selectores usados en JS

---

## DECISIÓN 2: ¿Convertir a SCSS/SASS?

### Veredicto: ❌ NO — mantener CSS puro por ahora

**Justificación:**

1. **No existe build pipeline** — no hay `package.json`, `webpack.config.js`, `vite.config.js`, ni `Makefile`. Instalar SCSS requeriría:
   - Node.js + npm/yarn en el servidor
   - Pipeline de compilación
   - Proceso de deploy actualizado
   - Capacitación del equipo

2. **Las variables CSS nativas resuelven el caso de uso principal** — todos los archivos ya usan `var(--primary-color)`. Con `core.css` centralizando las variables en `:root`, se logra el mismo resultado que SCSS `$variables` sin compilación.

3. **El nesting de SCSS ayudaría** en nav.php específicamente (que tiene 530+ líneas de CSS anidado), pero ese CSS está en un `<style>` inline que no pasa por ningún pipeline.

### Si en el futuro se quiere SCSS

Prerequisitos mínimos:
```bash
npm init -y
npm install --save-dev sass
# Agregar script: "build:css": "sass src/scss:public/css --no-source-map"
```

Los archivos CSS refactorizados son directamente migrables a SCSS con mínimo esfuerzo (solo renombrar `.css` → `.scss` y aprovechar variables/nesting).

---

## DECISIÓN 3: Nivel de refactorización

### Veredicto: 🟡 MODERADO — con la siguiente secuencia

#### Fase 4a — CONSERVADOR (hacer ahora)
Cambios solo de valores, cero riesgo de romper funcionalidad:

- Actualizar variables de color en todos los `:root` → nuevo sistema
- Cambiar `font-family: sans-serif` → `'Inter', system-ui, sans-serif`
- Actualizar `th { color }` a `#3F7CDB`
- Cambiar `td border-bottom` a `dashed`
- Ajustar `td { padding }` a `12px 8px`
- Actualizar hover de botones a `#2B4EC8`
- Ajustar paginación activa a `#2B4EC8`

**Tiempo estimado:** 2–3 horas  
**Riesgo:** MUY BAJO — solo valores, nunca selectores

#### Fase 4b — MODERADO (hacer después de validar 4a)
Consolidación del código duplicado:

- Crear `core.css` extrayendo el bloque idéntico de los 12 archivos
- Crear `tablas.css` consolidando estilos de tabla
- Reducir archivos de página a solo sus diferencias reales

**Tiempo estimado:** 4–6 horas  
**Riesgo:** BAJO si se sigue el orden de carga documentado

#### Fase 4c — AGRESIVO (evaluar después de 4b)
No recomendado en este momento por:
- Renombrar clases requiere actualizar TODOS los archivos PHP de vistas
- BEM nominación no aporta valor si JS no usa los nombres nuevos
- El equipo necesitaría aprender la nueva nomenclatura

---

## RESUMEN DE DECISIONES

| Decisión | Veredicto | Riesgo | Prioridad |
|---|---|---|---|
| Consolidar CSS | ✅ SÍ (en 2 capas) | BAJO-MEDIO | Alta |
| SCSS/SASS | ❌ NO (por ahora) | N/A | Baja |
| Nivel conservador | ✅ Aplicar ahora | MUY BAJO | Inmediata |
| Nivel moderado | ✅ Tras validación | BAJO | Alta |
| Nivel agresivo | ❌ No recomendado | ALTO | — |

---

## CAMBIOS CONCRETOS APROBADOS PARA FASE 4

### Variables del nuevo sistema de diseño

```css
/* NUEVO :root unificado — va en core.css */
:root {
  /* Colores principales */
  --clr-primary:           #2B4EC8;
  --clr-primary-hover:     #1D3A9E;
  --clr-accent:            #3F7CDB;
  --clr-body-bg:           #F5F6FA;
  --clr-surface:           #FFFFFF;
  --clr-text:              #111827;
  --clr-text-muted:        #6B7280;
  --clr-border:            #E5E7EB;
  --clr-delete:            #EF4444;
  
  /* Badges */
  --clr-badge-pending-bg:  #FFF8E1;
  --clr-badge-pending-txt: #D97706;
  --clr-badge-active-bg:   #ECFDF5;
  --clr-badge-active-txt:  #059669;
  
  /* Tipografía */
  --font-base:   'Inter', system-ui, -apple-system, sans-serif;
  --font-size-sm: 12px;
  --font-size-md: 14px;
  --font-size-lg: 16px;
  
  /* Espaciado */
  --radius-sm:   4px;
  --radius-md:   8px;
  --radius-full: 9999px;
  --shadow-sm:   0 1px 3px rgba(0,0,0,.08);
  --shadow-md:   0 4px 12px rgba(0,0,0,.1);

  /* Compatibilidad con código existente */
  --primary-color:    var(--clr-primary);
  --text-color:       var(--clr-text);
  --background-color: var(--clr-body-bg);
  --border-color:     var(--clr-border);
}
```

Los aliases de compatibilidad (`--primary-color`, `--text-color`, etc.) garantizan que el código PHP existente que usa estas variables sigue funcionando **sin tocar una sola vista**.

---

*Ver VALIDACIÓN_RESULTADOS.md para el checklist de testing post-refactorización.*