# Checklist de Preproduccion

## Objetivo

Dejar el backend listo para pasar de desarrollo local a pruebas reales sobre infraestructura real, con una lista clara de validaciones tecnicas, operativas y funcionales.

Este checklist complementa [STAGING_PRODUCCION.md](C:/Users/sacha/Desktop/ODONTOLOGIA/backend/STAGING_PRODUCCION.md).

## Estado actual del backend

- Suite automatizada de integracion: `30/30` pruebas OK
- Validacion de tipos: `npm run typecheck` OK
- Cobertura funcional automatizada actual:
  - salud del backend
  - autenticacion interna y recuperacion de contrasena
  - citas, conflictos, reprogramacion y auditoria
  - portal paciente y portal doctor
  - notificaciones y comunicaciones
  - pacientes, tratamientos y odontograma
  - presupuestos
  - finanzas
  - inventario
  - recetas
  - settings, usuarios y horarios
  - AgenteDental con versionado y restauracion

## Fase 1: Infraestructura base

- `PostgreSQL` real provisionado para `staging`.
- Base de datos accesible desde el backend.
- Credenciales reales cargadas en `backend/.env`.
- `APP_ENV=staging`.
- `ALLOW_LOCAL_FALLBACK=false`.
- Puerto y firewall revisados.
- Reloj y zona horaria del servidor confirmados.

## Fase 2: Variables de entorno

Revisar y completar como minimo:

```env
PORT=3000
APP_ENV=staging
ALLOW_LOCAL_FALLBACK=false
DATABASE_URL=postgresql://...
RESEND_API_KEY=...
EMAIL_FROM=...
EMAIL_REPLY_TO=...
TWILIO_ACCOUNT_SID=...
TWILIO_AUTH_TOKEN=...
TWILIO_SMS_FROM_NUMBER=...
WHATSAPP_ACCESS_TOKEN=...
WHATSAPP_PHONE_NUMBER_ID=...
WHATSAPP_TEMPLATE_NAME=...
WHATSAPP_TEMPLATE_LANGUAGE=es_PE
COMMUNICATION_DEFAULT_COUNTRY_CODE=+51
```

Checklist:

- `DATABASE_URL` apunta a la base real correcta.
- Las credenciales no usan valores demo.
- El dominio/remitente de correo esta validado en Resend.
- El numero emisor de Twilio esta habilitado.
- La plantilla de WhatsApp ya esta aprobada.
- Los secretos quedan fuera del repo y de capturas de pantalla.

## Fase 3: Base de datos y Prisma

Ejecutar en `backend`:

```bash
npm run db:generate
npm run db:validate
npm run db:migrate:status
npm run db:migrate:deploy
```

Checklist:

- Prisma genera sin errores.
- El schema valida sin errores.
- No hay migraciones pendientes inesperadas.
- Las migraciones aplican correctamente en `staging`.
- Se puede conectar a la base sin fallback local.

Si hace falta data inicial:

```bash
npm run db:seed
```

Validar despues:

- existe al menos un usuario administrador operativo;
- existe catalogo/tratamientos base si el sistema lo necesita;
- existe data minima para probar portales, agenda y caja.

## Fase 4: Verificacion tecnica previa al arranque

Ejecutar en `backend`:

```bash
npm test
npm run typecheck
```

Checklist:

- todos los tests pasan;
- typecheck pasa;
- no hay errores de importacion o runtime;
- no aparece dependencia silenciosa de JSON fallback.

## Fase 5: Arranque en staging

Levantar backend y validar:

```bash
npm run dev
```

Healthchecks obligatorios:

- `GET /health`
- `GET /health/ready`

Criterios:

- `/health` responde `200`
- `/health/ready` responde `200`
- la respuesta muestra `fallbackPolicy: disabled`
- la base de datos reporta `ok: true`

Si `/health/ready` devuelve `503`, no avanzar a QA funcional.

## Fase 6: Smoke test manual minimo

Hacer estas pruebas reales en staging:

1. Login de administrador.
2. Crear paciente nuevo.
3. Crear cita.
4. Reprogramar cita.
5. Validar conflicto de horario.
6. Crear acceso de portal paciente.
7. Ingresar al portal paciente y reservar cita.
8. Revisar agenda del doctor.
9. Crear presupuesto.
10. Registrar ingreso en caja.
11. Crear receta.
12. Editar articulo de AgenteDental y restaurar una version.

Debe verificarse manualmente:

- los cambios se persisten en DB real;
- las fechas y horas se ven correctas;
- no aparecen errores 500;
- los portales leen informacion consistente;
- las notificaciones in-app aparecen.

## Fase 7: Comunicaciones reales

Probar en staging con destinos controlados:

- correo real de prueba;
- telefono real de prueba para SMS;
- telefono real de prueba para WhatsApp.

Checklist:

- correo llega con remitente correcto;
- SMS llega con texto correcto;
- WhatsApp usa la plantilla aprobada;
- los logs de comunicaciones registran `SENT`, `SIMULATED`, `SKIPPED` o `FAILED` coherentemente;
- si falta un secreto, el sistema no revienta y queda trazabilidad en logs.

## Fase 8: Datos, seguridad y operacion

- confirmar backup de la base antes de abrir pruebas reales;
- definir responsable de restauracion;
- revisar accesos de administrador;
- cambiar credenciales demo o cuentas heredadas;
- confirmar que no se usa `ALLOW_LOCAL_FALLBACK=true` en staging/produccion;
- confirmar que los `.json` locales no son la fuente esperada de operacion real;
- revisar logs del backend al menos 1 vez despues del smoke test.

## Fase 9: Criterio de salida a pruebas reales

Se puede pasar a QA real cuando todo esto sea verdadero:

- infraestructura real disponible;
- variables reales cargadas;
- migraciones aplicadas;
- `npm test` OK;
- `npm run typecheck` OK;
- `/health` y `/health/ready` OK;
- smoke test manual completo OK;
- comunicaciones reales probadas al menos en entorno controlado;
- no hay errores bloqueantes en logs;
- existe plan de backup/restore.

## Pendientes que aun conviene cerrar

Esto no bloquea un primer `staging`, pero si conviene agendarlo:

- cobertura automatizada de `documents`, `dashboard`, `reports` y `treatment-catalog`;
- CI automatica para correr tests y typecheck en cada cambio;
- monitoreo y alertas;
- estrategia formal de backups;
- despliegue reproducible del frontend con smoke test conjunto frontend/backend;
- checklist de salida a produccion separado del de staging.

## Comandos recomendados

```bash
npm test
npm run typecheck
npm run db:generate
npm run db:validate
npm run db:migrate:status
npm run db:migrate:deploy
npm run db:seed
```

## Decision final

Si quieres moverte ya a pruebas reales, la secuencia recomendada es:

1. preparar `backend/.env` real;
2. levantar PostgreSQL real;
3. aplicar migraciones;
4. correr `npm test` y `npm run typecheck`;
5. arrancar backend;
6. validar `/health` y `/health/ready`;
7. ejecutar el smoke test manual;
8. abrir QA real.
