# 🏗️ Plan de Viabilidad: Módulo Espejo SISER — Gerencia de Mantenimiento

## 1. Resumen Ejecutivo

**Veredicto: ✅ ES VIABLE**, pero el enfoque de implementación importa mucho. A continuación analizo la arquitectura actual, identifico los puntos de acoplamiento, y presento 3 estrategias con su viabilidad, costo y riesgo.

---

## 2. Análisis de la Arquitectura Actual

### 2.1 Componentes del Sistema

```mermaid
graph TD
    subgraph "Capa de Datos (Models)"
        User["User (roles: Admin, Técnico, Jefe de Área, Solicitante)"]
        Solicitud["Solicitud (máquina de estados: I→A→EE→CO→CF→CE)"]
        Asignacion["Asignación (analista_id, departamento_destino_id)"]
        Ejecucion["Ejecución (tipos: SOFTWARE, HARDWARE, RED, etc.)"]
        Departamento["Departamento (gerencia_id)"]
        Gerencia["Gerencia (direccion_id)"]
        Direccion["Dirección"]
        AuditLog["AuditLog (trazabilidad)"]
    end

    subgraph "Capa de Negocio (Controllers)"
        SolicitudCtrl["SolicitudController"]
        AsignacionCtrl["AsignacionController"]
        EjecucionCtrl["EjecucionController"]
        ConformacionCtrl["ConformacionController"]
        DashboardCtrl["DashboardController"]
        ReportesCtrl["ReportesController"]
    end

    subgraph "Módulos de Vista"
        V1["Solicitudes (crear, listar, editar)"]
        V2["Asignaciones/Recepción"]
        V3["Ejecución del Servicio"]
        V4["Conformaciones"]
        V5["Dashboard + KPIs"]
        V6["Reportes (PDF/Excel)"]
        V7["Admin (Usuarios, Departamentos, Áreas)"]
    end
```

### 2.2 Puntos de Acoplamiento Identificados

| Componente | Nivel de Acoplamiento | Detalle |
|---|---|---|
| **Modelo `Solicitud`** | 🔴 Alto | Número consecutivo global (`2026-XXXX`), máquina de estados compartida, `departamento_id` genérico |
| **Modelo `User`** | 🟡 Medio | Roles por `cargo` (string), `departamento_id` y `gerencia_id` directos — NO tiene concepto de "a qué sistema pertenece" |
| **Modelo `Ejecucion`** | 🔴 Alto | `TIPOS_EJECUCION` y `TIPOS_CATEGORIA` hardcodeados para Tecnología (SOFTWARE, HARDWARE, RED DE DATOS, etc.) |
| **Modelo `Departamento`** | 🟢 Bajo | Genérico, solo necesita `gerencia_id` — reutilizable |
| **Modelo `Gerencia`** | 🟢 Bajo | Genérico, ya tiene `cat_gerencias` con dirección |
| **Controllers** | 🟡 Medio | Filtrados por `departamento_id` del usuario — la lógica es reutilizable si se aísla el contexto |
| **Vistas** | 🟡 Medio | Labels y textos orientados a Tecnología, pero la estructura es genérica |
| **Dashboard** | 🟡 Medio | KPIs calculan sobre TODAS las solicitudes sin distinción de gerencia |
| **Reportes** | 🟡 Medio | Generan sobre toda la data sin filtro de gerencia |
| **Sidebar/Navegación** | 🟢 Bajo | Sección única, fácil de duplicar o condicionar |

### 2.3 Hallazgos Clave

> [!IMPORTANT]
> **El sistema NO tiene concepto de "multi-gerencia"**. No existe un campo que separe las solicitudes de Tecnología vs Mantenimiento. El `departamento_id` apunta a departamentos de la jerarquía organizacional, pero las solicitudes de CUALQUIER gerencia comparten la misma tabla, el mismo consecutivo, y los mismos dashboards.

> [!WARNING]
> **Los tipos de ejecución están hardcodeados** directamente en el modelo `Ejecucion.php` como constantes PHP. Mantenimiento necesitaría categorías completamente diferentes (ej: ELECTRICIDAD, PLOMERÍA, AIRES ACONDICIONADOS, INFRAESTRUCTURA CIVIL, etc.).

---

## 3. Estrategias de Implementación

### 3.1 Estrategia A: Multi-Tenant dentro de la Misma Aplicación (⭐ RECOMENDADA)

> Agregar un campo discriminador `gerencia_destino` a las solicitudes para separar los flujos sin duplicar código.

#### Concepto

```mermaid
graph LR
    subgraph "SISER Unificado"
        direction TB
        A["Solicitud.gerencia_destino = 'TEC'"] --> B["Flujo Tecnología"]
        C["Solicitud.gerencia_destino = 'MAN'"] --> D["Flujo Mantenimiento"]
        E["Modelo User con departamento de Mantenimiento"] --> D
        F["Modelo User con departamento de Tecnología"] --> B
    end
```

#### Cambios Necesarios

| Área | Cambio | Esfuerzo |
|---|---|---|
| **Migración BD** | Agregar `gerencia_destino` (ENUM: 'TEC', 'MAN') a `solicitudes` | 🟢 Bajo |
| **Modelo Solicitud** | Scope global o scope por gerencia destino | 🟢 Bajo |
| **Modelo Ejecución** | Hacer dinámicos `TIPOS_EJECUCION` y `TIPOS_CATEGORIA` según gerencia | 🟡 Medio |
| **Numeración** | Prefijo diferenciado: `TEC-2026-0001` vs `MAN-2026-0001` | 🟢 Bajo |
| **Controllers** | Agregar filtro `gerencia_destino` en todas las queries | 🟡 Medio |
| **Dashboard** | Separar KPIs por gerencia o agregar toggle | 🟡 Medio |
| **Sidebar** | Duplicar secciones o agregar switcher de contexto | 🟡 Medio |
| **Vistas** | Condicionar labels (ej: "Tipo de Ejecución" → "Tipo de Mantenimiento") | 🟡 Medio |
| **Admin** | Gestión de departamentos/técnicos de Mantenimiento (ya funciona por gerencia) | 🟢 Bajo |
| **Reportes** | Filtrar por gerencia_destino | 🟢 Bajo |

#### Pros
- ✅ **Menor esfuerzo** (~40-60 horas de desarrollo)
- ✅ **Cero duplicación de código** — mantenimiento futuro más fácil
- ✅ **Base de datos unificada** — reportes cruzados posibles
- ✅ **Usuarios compartidos** — un solicitante puede pedir servicio a ambas gerencias
- ✅ **Una sola instalación** — sin overhead operativo

#### Contras
- ❌ **Riesgo de regresión** — cambios tocan el sistema existente en producción
- ❌ **Complejidad incremental** — cada controller/vista necesita condicionales
- ❌ **Posible confusión UX** — si no se maneja bien la separación visual

---

### 3.2 Estrategia B: Aplicación Laravel Separada (Clon Completo)

> Copiar el proyecto SISER completo, renombrar a "SIMER" (o similar), y adaptarlo para Mantenimiento con BD separada.

#### Cambios Necesarios

| Área | Cambio | Esfuerzo |
|---|---|---|
| **Infraestructura** | Clonar repo, nueva BD PostgreSQL, nuevo virtual host | 🟡 Medio |
| **Modelo Ejecución** | Reemplazar TIPOS por los de mantenimiento | 🟢 Bajo |
| **Branding** | Cambiar nombre, colores, logos | 🟢 Bajo |
| **Usuarios** | Crear nuevos usuarios, roles, departamentos | 🟢 Bajo |
| **Toda la app** | Funciona tal cual — solo adaptar catálogos | 🟢 Bajo |

#### Pros
- ✅ **Aislamiento total** — cero riesgo de afectar Tecnología
- ✅ **Implementación más rápida** (~20-30 horas iniciales)
- ✅ **Independencia operativa** — cada gerencia controla su sistema

#### Contras
- ❌ **Doble mantenimiento** — cada bugfix o feature debe replicarse en 2 apps
- ❌ **Usuarios duplicados** — si alguien solicita a ambas gerencias, tiene 2 cuentas
- ❌ **Divergencia inevitable** — con el tiempo, los sistemas se volverán incompatibles
- ❌ **Doble infraestructura** — 2 bases de datos, 2 deployments, 2 backups
- ❌ **Sin reportes cruzados** — imposible ver métricas consolidadas

---

### 3.3 Estrategia C: Híbrida — Rutas Prefijadas con Controllers Heredados

> Mantener la misma app pero con rutas separadas (`/mantenimiento/solicitudes`, `/tecnologia/solicitudes`) y controllers que heredan de una base común.

#### Arquitectura

```
routes/web.php
├── /solicitudes          → SolicitudController (actual, Tecnología)
├── /mant/solicitudes     → Mant\SolicitudController extends BaseSolicitudController
├── /mant/asignaciones    → Mant\AsignacionController extends BaseAsignacionController
└── ...
```

#### Pros
- ✅ **Separación clara de UX** — URLs distintas, vistas separadas
- ✅ **Código base compartido** — herencia OOP evita duplicación
- ✅ **BD unificada** con discriminador

#### Contras
- ❌ **Mayor complejidad arquitectónica** (~80-100 horas)
- ❌ **Over-engineering** para el tamaño actual del sistema
- ❌ **Curva de aprendizaje** para el equipo de mantenimiento del código

---

## 4. Comparativa de Estrategias

| Criterio | A: Multi-Tenant | B: Clon Separado | C: Híbrida |
|---|---|---|---|
| **Esfuerzo inicial** | 🟡 40-60h | 🟢 20-30h | 🔴 80-100h |
| **Mantenimiento futuro** | 🟢 Bajo | 🔴 Doble | 🟡 Medio |
| **Riesgo de regresión** | 🟡 Medio | 🟢 Nulo | 🟡 Medio |
| **Experiencia de usuario** | 🟡 Buena | 🟢 Excelente | 🟢 Excelente |
| **Escalabilidad** | 🟢 Alta | 🔴 Baja | 🟢 Alta |
| **Reportes consolidados** | 🟢 Sí | 🔴 No | 🟢 Sí |
| **Complejidad operativa** | 🟢 Baja | 🟡 Media | 🟡 Media |

---

## 5. ⭐ Recomendación: Estrategia A (Multi-Tenant)

La Estrategia A es la más equilibrada para el contexto actual de SISER:

1. **El sistema ya usa `departamento_id`** como eje de filtrado — solo falta un nivel jerárquico superior para discriminar la gerencia.
2. **La tabla `cat_gerencias`** ya existe con la jerarquía Dirección → Gerencia → Departamento.
3. **Los roles (`cargo`) son genéricos** — "Técnico", "Jefe de Área" aplican igual para ambas gerencias.
4. **Las vistas Blade son reutilizables** — solo cambian labels y opciones de catálogos.

---

## 6. Plan de Implementación Detallado (Estrategia A)

### Fase 1: Fundación de Datos (Semana 1)

#### 1.1 Migración de BD
```php
// Agregar campo discriminador a solicitudes
Schema::table('solicitudes', function (Blueprint $table) {
    $table->string('modulo', 10)->default('TEC')->after('numero');
    // 'TEC' = Tecnología (existente), 'MAN' = Mantenimiento
    $table->index('modulo');
});
```

#### 1.2 Catálogos de Mantenimiento
- Crear registros en `cat_gerencias` para la Gerencia de Mantenimiento
- Crear departamentos de Mantenimiento (Electricidad, Plomería, A/C, Infraestructura, etc.)
- Registrar usuarios técnicos y jefes de Mantenimiento

#### 1.3 Tipos de Ejecución Dinámicos
```php
// En Ejecucion.php — Hacer los tipos configurables por módulo
public const TIPOS_POR_MODULO = [
    'TEC' => [
        'tipos_ejecucion' => ['SOFTWARE', 'HARDWARE', ...],
        'tipos_categoria' => ['SOFTWARE' => [...], ...],
    ],
    'MAN' => [
        'tipos_ejecucion' => ['ELECTRICIDAD', 'PLOMERÍA', 'AIRES ACONDICIONADOS', 'INFRAESTRUCTURA CIVIL', 'PINTURA', 'CERRAJERÍA', 'JARDINERÍA'],
        'tipos_categoria' => [
            'ELECTRICIDAD' => ['MANTENIMIENTO PREVENTIVO', 'MANTENIMIENTO CORRECTIVO', 'INSTALACIÓN NUEVA', 'EMERGENCIA'],
            'PLOMERÍA' => ['FUGA DE AGUA', 'DESAGÜE', 'INSTALACIÓN', 'MANTENIMIENTO'],
            // ... definir con la Gerencia de Mantenimiento
        ],
    ],
];
```

### Fase 2: Lógica de Negocio (Semana 2)

#### 2.1 Scope Global en Solicitud
```php
// En Solicitud.php — Scope reutilizable
public function scopeModulo($query, string $modulo)
{
    return $query->where('modulo', $modulo);
}
```

#### 2.2 Actualizar Controllers
- Agregar parámetro `modulo` en las queries de todos los controllers
- El módulo se determina por el contexto del usuario (su gerencia/departamento)
- Numeración separada: `TEC-2026-0001` vs `MAN-2026-0001`

#### 2.3 Middleware de Contexto
```php
// Nuevo middleware que inyecta el módulo activo en la sesión
class SetModuloContext
{
    public function handle($request, Closure $next)
    {
        $user = auth()->user();
        $moduloActivo = session('modulo_activo');
        
        if (!$moduloActivo) {
            // Determinar por la gerencia del usuario
            $gerencia = $user->gerencia;
            $moduloActivo = $gerencia && $gerencia->modulo 
                ? $gerencia->modulo 
                : 'TEC';
            session(['modulo_activo' => $moduloActivo]);
        }
        
        // Compartir con todas las vistas
        view()->share('moduloActivo', $moduloActivo);
        
        return $next($request);
    }
}
```

### Fase 3: Interfaz de Usuario (Semana 3)

#### 3.1 Switcher de Módulo en Sidebar
- Agregar un selector visual (ej: tabs o dropdown) para cambiar entre "Tecnología" y "Mantenimiento"
- Solo visible para usuarios con acceso a ambos módulos (ej: Admin)
- Los usuarios de Mantenimiento solo ven su módulo y viceversa

#### 3.2 Branding por Módulo
- Color primario diferente para Mantenimiento (ej: naranja/ámbar vs azul actual)
- Icono diferente en el sidebar
- Label dinámico: "SISER — Tecnología" / "SISER — Mantenimiento"

#### 3.3 Adaptar Formularios
- Selects de tipo de ejecución y categoría dinámicos según el módulo
- Labels contextuales donde aplique

### Fase 4: Dashboard y Reportes (Semana 4)

#### 4.1 Dashboard
- KPIs filtrados por módulo activo
- Gráficos separados por departamentos de cada gerencia
- Actividad reciente filtrada por módulo

#### 4.2 Reportes
- Filtro de módulo en la interfaz de reportes
- PDFs y Excels con header del módulo correspondiente

### Fase 5: Testing y Despliegue (Semana 5)

- Migración con backfill de `modulo = 'TEC'` para todas las solicitudes existentes
- Pruebas de regresión del módulo de Tecnología (no debe cambiar nada)
- UAT con el equipo de Mantenimiento
- Despliegue gradual

---

## 7. Riesgos y Mitigaciones

| Riesgo | Probabilidad | Impacto | Mitigación |
|---|---|---|---|
| Regresión en módulo Tecnología | 🟡 Media | 🔴 Alto | Backfill con default 'TEC', pruebas exhaustivas |
| Categorías de mantenimiento incompletas | 🟡 Media | 🟡 Medio | Reunión con Gerencia de Mantenimiento ANTES de codificar |
| Usuarios que solicitan a ambas gerencias | 🟢 Baja | 🟡 Medio | El formulario de solicitud permite elegir gerencia destino |
| Rendimiento con más data | 🟢 Baja | 🟢 Bajo | Índice en `modulo` + queries ya filtradas por departamento |

---

## 8. Decisiones Pendientes (Requieren Input)

> [!IMPORTANT]
> Antes de comenzar la implementación, necesito que confirmes lo siguiente:

1. **¿Qué estrategia prefieres?** ¿A (Multi-Tenant recomendada), B (Clon separado), o C (Híbrida)?

2. **¿Cuáles son los departamentos de Mantenimiento?** Necesito la lista real (ej: Electricidad, Plomería, A/C, Obras Civiles, etc.)

3. **¿Cuáles serían los Tipos de Ejecución y Categorías de Mantenimiento?** Equivalentes a los actuales SOFTWARE/HARDWARE/RED pero para mantenimiento.

4. **¿Los usuarios de Mantenimiento ya existen en la BD?** ¿O hay que crearlos desde cero?

5. **¿Algún solicitante necesita poder crear solicitudes dirigidas a AMBAS gerencias?** Esto afecta el diseño del formulario de creación.

6. **¿El admin actual de Tecnología también administraría Mantenimiento?** ¿O habrá un admin separado por gerencia?

7. **¿Desean un branding visual diferente** (color distinto) para distinguir qué módulo se está usando?