Base de datos y migraciones

El backend usa Sequelize con dialect mysql y variables DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD.

Motor esperado

Elemento	Valor observado
Driver	`mysql2`
ORM	`sequelize`
Dialect	`mysql`
Conexion	`src/db/Sequelize.connection.js`
Sync	`Sequelize.sync({ force: false })` al arrancar

sync({ force:false }) no reemplaza una estrategia formal de migraciones. No asumas que el arranque del backend aplica todos los cambios productivos necesarios.

Usuario DB de aplicacion

Crear un usuario dedicado, sin permisos administrativos globales:

CREATE USER 'medsync_app'@'%' IDENTIFIED BY '<generated-secret>';
GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE
  ON medsync_prod.*
  TO 'medsync_app'@'%';
FLUSH PRIVILEGES;

Ajusta host y privilegios segun arquitectura real. No uses root ni cuentas personales.

Migraciones existentes

No hay comando npm run migrate observado. Existen scripts SQL manuales en hemia-assistance-back-legacy\Scripts_, por ejemplo:

Archivo	Uso
`business_license_overrides_migration.sql`	Licenciamiento/overrides.
`business_saas_lifecycle_migration.sql`	Estados SaaS/trials.
`create_admin_audit_log.sql`	Auditoria administrativa.
`document_signature_requests_migration.sql`	Solicitudes de firma documental.
`document_signature_requests_rollback.sql`	Rollback de firma documental.

Antes de produccion, DBA/infra debe mantener una bitacora de migraciones aplicadas por ambiente.

Procedimiento de migracion

Congelar version backend/frontend a desplegar.
Leer SQL pendiente y confirmar que aplica al schema actual.
Tomar backup completo antes de tocar DB.
Ejecutar migracion en staging/preproduccion.
Ejecutar smoke tests backend y frontend.
Preparar rollback SQL si aplica.
Ejecutar en produccion durante ventana aprobada.
Registrar fecha, responsable, hash/commit, script aplicado y resultado.

Fixtures QA

Los scripts QA de autenticacion usan fixtures ficticios con prefijo QA_D2_*. Ese prefijo es un nombre tecnico interno de los fixtures. No se deben crear fixtures contra produccion.

Script	Uso seguro
`scripts/qa/d2-browser-qa-fixtures.js`	Solo DB de prueba con flags `ALLOW_D2_QA_DB=1` y `ALLOW_D2_BROWSER_QA_FIXTURES=1`.
`scripts/qa/d2-cookie-auth-db-integration.js`	Integracion DB con cleanup automatico en entorno controlado.
`scripts/qa/auth-final-regression.js`	Regression auth con fixtures ficticios.

No uses datos reales de pacientes, doctores, tenants o credenciales humanas para QA.

Backups DB

Backups minimos:

Full backup diario cifrado.
Binlogs o incremental segun RPO.
Retencion separada por ambiente.
Prueba de restore periodica.
Almacenamiento fuera del mismo host de DB.
Acceso restringido y auditado.

Restore

Checklist post-restore:

Confirmar schema y conteos basicos.
Rotar o revocar sesiones si el restore retrocede estado auth.
Validar session, refresh_token, usuarios y tenants.
Ejecutar smoke tests de login, session, logout y Super Admin close.
Verificar que no se restauraron fixtures QA activos.
Confirmar que backups restaurados no contienen secretos en ubicaciones no cifradas.

Impacto de restore en sesiones

Un restore puede revivir sesiones o refresh tokens que ya habian sido revocados despues del punto de backup. Si hay duda:

Revocar sesiones activas.
Revocar familias refresh afectadas.
Forzar re-login.
Rotar secretos si el incidente involucra exposicion de DB o backups.