# PROMPT MAESTRO PARA ANTIGRAVITY — PULSOCORP

## INSTRUCCIÓN PRINCIPAL
Vas a trabajar sobre un proyecto existente llamado **PULSOCORP**, actualmente en producción.

Antes de modificar cualquier archivo debes leer completamente el archivo `SPEC_PULSOCORP.md`. Este archivo es el contrato técnico principal del proyecto. También debes analizar el código real existente antes de realizar cambios.

## OBJETIVO
Implementar una ampliación del sistema que permita:
1. Gestionar Redes.
2. Asociar las sedes existentes a una Red.
3. Configurar múltiples horarios por sede.
4. Configurar diferentes horarios según el día de la semana.
5. Clasificar las pulsaciones existentes según Red, Sede, Día y Horario.
6. Generar reportes por horario.
7. Generar totales consolidados por Red.
8. Identificar pulsaciones fuera de horario.
9. Permitir a los administradores gestionar Redes, asociaciones entre Redes y Sedes, y horarios por sede.

## REGLA CRÍTICA: SISTEMA EN PRODUCCIÓN
Este proyecto utiliza una base de datos que ya se encuentra en producción y que puede ser utilizada simultáneamente por otras aplicaciones.

Las siguientes tablas son consideradas **LEGACY Y PROTEGIDAS**:
- `usuarios`
- `contadores`
- `pulsaciones`

### ESTÁ PROHIBIDO
No puedes:
- Eliminar, renombrar o recrear tablas existentes.
- Renombrar, eliminar o cambiar el tipo de columnas existentes.
- Modificar o eliminar datos históricos.
- Vaciar tablas o reiniciar AUTO_INCREMENT.
- Cambiar claves primarias existentes.
- Eliminar índices existentes.
- Ejecutar migraciones destructivas.

Todas las columnas de `usuarios`, `contadores` y `pulsaciones` deben tratarse como protegidas.

## PRINCIPIO ARQUITECTÓNICO OBLIGATORIO
La estrategia será:

TABLAS EXISTENTES
├── usuarios
├── contadores
└── pulsaciones
        │
        │ SOLO LECTURA PARA LA NUEVA FUNCIONALIDAD
        ▼
NUEVAS TABLAS DE PULSOCORP
├── redes
├── sedes_red
├── horarios_sede
└── schema_migrations

No agregues campos a `contadores` como primera opción. La relación entre Redes y sedes existentes debe realizarse mediante `sedes_red`.

Relación:
`contadores.id` → `sedes_red.contador_id`
`sedes_red.red_id` → `redes.id`

La tabla `pulsaciones` no debe modificarse. La clasificación por Red, Sede y Horario debe realizarse dinámicamente mediante consultas SQL y JOINs.

## EJEMPLO FUNCIONAL
Red: Lima Centro
Sede: Central

Domingo:
- Horario 1: 06:00 a 10:59
- Horario 2: 11:00 a 14:00

Una pulsación de Central a las 08:30 se clasifica como Horario 1.
Una pulsación a las 12:30 se clasifica como Horario 2.
Si ocurre fuera de todos los horarios configurados: `Fuera de horario`.
Si la sede no tiene horarios configurados: `Sin horario configurado`.

Nunca modificar físicamente un registro de `pulsaciones`.

# SISTEMA OBLIGATORIO DE SEGURIDAD DE MIGRACIONES

Crear:

scripts/
├── migration-safety-check.js
├── migration.js
├── verify-integrity.js
└── utils/
    └── database-protection.js

## PASO 1 — BASELINE
Antes de cualquier migración ejecutar:

`node scripts/migration-safety-check.js`

Debe generar:
`storage/integrity/baseline-before.json`

Debe registrar para las tablas protegidas:
- Estructura.
- Columnas.
- Tipos.
- Nullability.
- Defaults.
- Índices.
- Claves.
- Número de registros.
- ID mínimo y máximo.
- Hashes de integridad.

Usar:
```javascript
const PROTECTED_TABLES = [
  'usuarios',
  'contadores',
  'pulsaciones'
];
```

Para tablas grandes como `pulsaciones`, calcular hashes por lotes para no cargar todos los registros en memoria.

## PASO 2 — DRY RUN
Ejecutar:
`node scripts/migration.js --dry-run`

Debe mostrar exactamente qué existía antes y qué se va a crear o modificar.

Ejemplo:
TABLAS EXISTENTES
usuarios → SIN CAMBIOS
contadores → SIN CAMBIOS
pulsaciones → SIN CAMBIOS

NUEVAS TABLAS
+ redes
+ sedes_red
+ horarios_sede
+ schema_migrations

OPERACIONES DESTRUCTIVAS: NINGUNA
MODIFICACIÓN DE DATOS EXISTENTES: NINGUNA

Si se detecta cualquier intento de modificar una tabla protegida, detener inmediatamente el proceso.

## PASO 3 — DETECTOR DE SQL PELIGROSO
Bloquear sobre las tablas protegidas:
- DROP
- TRUNCATE
- DELETE
- UPDATE
- RENAME
- ALTER TABLE usuarios
- ALTER TABLE contadores
- ALTER TABLE pulsaciones

Detectar variantes equivalentes cuando sea razonablemente posible.

## PASO 4 — APLICACIÓN
Solo si el dry-run es satisfactorio:
`node scripts/migration.js --apply`

## PASO 5 — VERIFICACIÓN POSTERIOR
Ejecutar:
`node scripts/verify-integrity.js`

Comparar baseline-before y baseline-after.

Verificar:
- Estructura de tablas protegidas sin cambios.
- Cantidad de registros preservada.
- Hash de integridad preservado.
- Nuevas tablas creadas correctamente.

Si existe cualquier diferencia inesperada, generar:
`storage/integrity/integrity-failure-report.json`

y detener cualquier proceso posterior.

# FLUJO DE TRABAJO OBLIGATORIO

## FASE 1 — AUDITORÍA
No modifiques nada.

Analiza:
- Estructura real del proyecto.
- Base de datos.
- `server.js`.
- `config/db.js`.
- Rutas.
- Frontend.
- Relación real entre `contadores` y `pulsaciones`.

Presenta:
1. Archivos encontrados.
2. Tablas encontradas.
3. Relación actual entre datos.
4. Riesgos.
5. Diferencias entre código real y SPEC.

## FASE 2 — PLAN
Antes de programar presenta:
- Archivos a modificar.
- Archivos nuevos.
- Tablas nuevas.
- Endpoints nuevos.
- Riesgos.
- Plan de migración.
- Plan de rollback.

## FASE 3 — SEGURIDAD
Implementar primero:
- migration-safety-check.js
- migration.js
- verify-integrity.js
- database-protection.js

Ejecutar baseline. No continuar si la validación falla.

## FASE 4 — BASE DE DATOS
Crear únicamente:
- redes
- sedes_red
- horarios_sede
- schema_migrations

No modificar las tablas protegidas.

## FASE 5 — BACKEND

### Redes
- GET `/api/redes`
- GET `/api/redes/:id`
- POST `/api/redes`
- PUT `/api/redes/:id`
- DELETE `/api/redes/:id`

### Relación Red-Sede
- GET `/api/sedes-red`
- POST `/api/sedes-red`
- PUT `/api/sedes-red/:id`
- DELETE `/api/sedes-red/:id`

### Horarios
- GET `/api/sedes/:id/horarios`
- POST `/api/sedes/:id/horarios`
- PUT `/api/horarios/:id`
- DELETE `/api/horarios/:id`

### Reportes
- GET `/api/reports/horarios`
- GET `/api/reports/redes`
- GET `/api/reports/fuera-horario`
- GET `/api/reports/resumen-horarios`

## FASE 6 — FRONTEND
Mantener:
- Vanilla JavaScript
- HTML
- CSS
- Chart.js

Crear:
- Gestión de Redes.
- Asociación de Sedes a Redes.
- Gestión de Horarios.
- Reporte por Horarios.
- Consolidado por Red.
- Filtros.
- KPIs.
- Gráficos.

## VALIDACIÓN DE HORARIOS
No permitir:
- Horarios superpuestos.
- Hora inicial mayor o igual a hora final.
- Horario sin sede.
- Horario sin día.
- Duplicados.

Inválido:
- 08:00 - 11:00
- 10:00 - 13:00

Válido:
- 06:00 - 10:59
- 11:00 - 14:00

## PRUEBAS OBLIGATORIAS
Probar:
1. Pulsación dentro del Horario 1.
2. Pulsación dentro del Horario 2.
3. Pulsación fuera de horario.
4. Sede sin horario.
5. Varias sedes en una Red.
6. Horarios superpuestos.
7. Filtros por fecha.
8. Filtros por Red.
9. Filtros por Sede.
10. Integridad de tablas protegidas antes y después.

## REGLA FINAL
No asumas que el SPEC reemplaza al código real.

Orden de prioridad:
1. Integridad de la base de datos en producción.
2. Compatibilidad con aplicaciones existentes.
3. Código real existente.
4. SPEC_PULSOCORP.md.
5. Nueva funcionalidad.

Si existe cualquier conflicto entre una nueva funcionalidad y la integridad de los datos existentes, prioriza siempre la integridad y detén la implementación para informar el conflicto.

Trabaja de forma incremental, verificable y segura.