Checklist Production-Ready

Checklist production-ready

No marcar produccion lista hasta completar esta lista con evidencia.

Usa este checklist al final de la validacion production-like. Cada item debe tener responsable, fecha y evidencia. Si un punto no aplica, documenta por que. Si un punto falla, no se compensa con otro: se corrige, se acepta formalmente el riesgo o se detiene el rollout.

Si eres nuevo en el proyecto, lee tambien D2 production para juniors antes de ejecutar esta checklist.

Checklist de produccion para junior

Esta tabla explica cada paso en lenguaje operativo. No reemplaza las casillas formales de abajo: ayuda a entender que evidencia debe existir.

Paso	Que se hace	Por que se hace	Como se valida	Error comun
1. Dominio	Definir dominio real.	Cookies, CORS y CSRF dependen del dominio final.	Dominio aprobado por producto/infra.	Cambiar dominio despues sin repetir QA.
2. DNS	Crear app.<dominio> y api.<dominio>.	Frontend y API necesitan origenes claros.	Ambos resuelven al destino correcto.	Probar con IP directa y creer que equivale a dominio.
3. TLS/HTTPS	Configurar certificados validos.	Cookies Secure=true requieren HTTPS.	Browser muestra HTTPS valido.	Ejecutar production-like en HTTP.
4. Backend env	Configurar D2, cookies, CSRF, CORS y sesiones.	Backend setea y valida cookies.	Arranque y QA de config D2 pasan.	Copiar .env.local a staging/produccion.
5. Frontend env	Compilar con D2 y API HTTPS.	El build decide si usa cookies o legacy.	VUE_APP_BROWSER_AUTH_TRANSPORT=cookie y API HTTPS.	Publicar build viejo con Authorization.
6. CORS origins	Allowlist exacta del frontend.	Credenciales con cookies no aceptan wildcard seguro.	Origen permitido funciona; externo falla.	Usar * con credentials.
7. CSRF origins	Permitir solo origenes frontend reales.	Mutaciones con cookies necesitan CSRF.	Sin CSRF falla 403; con CSRF pasa.	Apagar CSRF para evitar errores.
8. Secrets	Usar secretos fuertes desde mecanismo seguro.	JWT, refresh, CSRF, reset y DB dependen de secretos.	No hay placeholders/defaults.	Pegar secretos en docs o chats.
9. SMTP	Configurar correo real o sandbox.	Reset password debe probarse end-to-end.	OTP/reset funciona sin imprimir secretos.	Saltarse reset password por falta de SMTP.
10. Backups	Activar backup DB/storage.	Se necesita recuperacion ante fallo.	Restore probado en ambiente controlado.	Tener backup sin restore probado.
11. Logs/alertas	Activar monitoreo auth y errores.	Detecta CSRF, CORS, refresh reuse, 401/403/500.	Alertas reciben eventos de prueba.	Loguear cookies completas.
12. Deploy backend	Desplegar API con env aprobado.	La API debe estar lista antes del frontend.	Health y smoke API OK.	AUTH_COOKIE_SECURE=false en HTTPS.
13. Deploy frontend	Publicar build D2.	Usuarios entran por https://app.<dominio>.	App carga y usa https://api.<dominio>/.	Build apunta a HTTP.
14. Smoke test	Probar login, session, refresh y logout.	Confirma flujo minimo de auth.	Login tokenless, refresh cookie-only y logout OK.	Probar solo login.
15. Validar cookies	Revisar nombres y flags.	Es el control central de D2.	HttpOnly, Secure, SameSite, Path correctos.	Access/refresh visibles en document.cookie.
16. Validar storage	Revisar local/session storage.	No debe persistir secretos ni contexto sensible.	Sin tokens, permisos, business ni tenantOperational.	No limpiar residuos antes de probar.
17. Validar network	Revisar requests API.	D2 navegador no usa auth por header legacy.	No existe Authorization.	Revisar una pestana vieja.
18. Reset password	Probar invalidacion de sesiones viejas.	Cambio de password debe cortar access/refresh previos.	Sesion vieja queda 401; password vieja falla.	Marcar listo sin esta prueba.
19. Rollback	Ensayar salida segura.	Si algo falla, se necesita volver sin abrir huecos.	Smoke post-rollback documentado.	Apagar CSRF con cookies activas.
20. Go/no-go	Revisar evidencia y riesgos.	Produccion requiere decision formal.	Checklist completo y riesgos aceptados.	Aprobar con critical/high abierto sin excepcion formal.

Auth y QA

• Refresh cookie-only probado localmente.
• Browser real/DevTools o Playwright probado localmente.
• Plan de rollout/rollback aprobado.
• Validacion production-like o release candidate aprobada.
• Manual de infraestructura revisado por infraestructura.
• Browser real/DevTools o Playwright validado en production-like.
• Refresh cookie-only funciona.
• Reset password invalidation end-to-end probado.
• Tenant restricted hard-block CTO/Product probado: sin sesion, sin access cookie, sin refresh cookie, sin datos clinicos y con error generico.
• /tenant-restricted probado solo para sesion existente que detecta tenantOperational.allowed=false.
• FINAL Auth/Login/Forgot Password Regression QA repetida.

TLS, dominios y proxy

• https://app.<dominio> activo.
• https://api.<dominio> activo.
• HTTP redirige a HTTPS.
• Certificados con renovacion automatica.
• HSTS evaluado.
• Proxy no loguea cookies completas ni Authorization.
• EXPRESS_TRUST_PROXY configurado con alcance correcto.

Cookies, CORS y CSRF

• AUTH_COOKIE_MODE=d2.
• BROWSER_AUTH_TRANSPORT=cookie.
• Cookies access/refresh HttpOnly.
• Cookies production-like Secure=true.
• Cookies __Host-* evaluadas y usadas si la topologia lo permite.
• SameSite justificado.
• Path=/.
• Sin Domain si se usa __Host-.
• CSRF activo.
• CSRF_TOKEN_SECRET fuerte.
• CORS allowlist exacta.
• CORS_CREDENTIALS=true.
• Sin wildcard con credentials.
• Vary: Origin.

Frontend

• Build con VUE_APP_AUTH_COOKIE_MODE=d2.
• Build con VUE_APP_BROWSER_AUTH_TRANSPORT=cookie.
• Build con VUE_APP_CSRF_ENABLED=true.
• VUE_APP_CORE_URL_API=https://api.<dominio>/.
• No Authorization navegador.
• localStorage sin tokens.
• sessionStorage sin tokens.
• Solo medsync.auth.rememberedIdentifier.v1 como persistencia auth-related.

Backend y secretos

• NODE_ENV/APP_ENV production-like.
• REQUIRE_ACTIVE_SESSION=true.
• JWT_SECRET fuerte.
• REFRESH_TOKEN_SECRET fuerte.
• PASSWORD_RESET_CODE_SECRET fuerte.
• CSRF_TOKEN_SECRET fuerte.
• DB usuario minimo privilegio.
• SMTP probado.
• Secretos en secret manager.
• No secretos default.
• .env.example saneado o riesgo aceptado con rotacion.

Operacion

• Logs centralizados.
• Alertas 401/403/429/500.
• Alertas CSRF failures.
• Alertas CORS rejected origins.
• Alertas refresh reuse.
• Alertas reset password masivo.
• Alertas cierre masivo sesiones.
• Backups cifrados.
• Restore probado.
• Runbook incident response revisado.

Flujos funcionales

• Login.
• /api/auth/csrf.
• /api/auth/session.
• Logout.
• Refresh.
• Usuario bloqueado/inactivo.
• Tenant restringido hard-block.
• /tenant-restricted por cambio de estado durante sesion existente.
• Super Admin close individual.
• Super Admin close masivo.
• Reset password.
• Flujo clinico minimo.