SOP — Rollback de Patio Abierto (Vercel)

Tipo: procedimiento de respuesta a incidente. Estado: prep deploy-ready. 🔴 Boundary: ejecutar un rollback en producción es outward-facing / CEO-gated. Este SOP describe el cómo para reaccionar rápido cuando el CEO/G lo autorice (o según un runbook de incidentes que el CEO apruebe). No se ejecuta en autonomía.

0. Cuándo hacer rollback

Disparadores típicos tras un deploy a prod:

• Error 500 / pantalla en blanco en alguna de las 3 vistas (inventario/malla/garita).
• Regresión funcional (toggle de tema roto, garita no registra, datos no cargan).
• Pico de errores en Runtime Logs.
• Regresión visual/accesibilidad grave (contraste, layout roto en móvil).

Principio: revertir primero, diagnosticar después. El estado bueno conocido es el deployment de producción inmediatamente anterior.

1. Rollback rápido (recomendado) — Instant Rollback / Promote anterior

Vercel conserva los deployments inmutables. El camino más rápido y seguro:

1. Dashboard → proyecto → Deployments.
2. Localizar el último deployment de producción que funcionaba (Ready, previo al malo).
3. Promote to Production (o "Instant Rollback") sobre ese deployment.
   • No requiere rebuild: re-apunta el alias de producción al build anterior.
4. Verificar la URL de prod (smoke test de las 3 vistas) + Runtime Logs limpios.
5. Tiempo objetivo: < 2 min (no hay build de por medio).

Equivalente CLI (cuando el CEO autorice ejecutar): vercel rollback <deployment-url|id> o vercel promote <deployment-url> apuntando al build bueno. Requiere sesión vercel login.

2. Rollback por git (si el malo ya está en main)

Si el código defectuoso se mergeó a main y debe salir del historial de la rama de prod:

1. git revert <sha-del-merge> (revert, NO reset/force-push sobre main).
2. PR del revert → CI verde → merge → Vercel redeploya prod con el código revertido.
3. Es más lento que §1 (pasa por build/CI); usar §1 para mitigar ya, y §2 para dejar main limpio después.

3. Rollback con base de datos (solo si Postgres está activo)

⚠️ Crítico: el rollback de código es instantáneo; el de datos/esquema no.

• Si el deploy malo NO tocó el esquema → §1 basta (el código viejo habla con el mismo esquema).
• Si el deploy malo aplicó una migración (db:deploy):
  1. Revertir el código primero (§1) si el esquema viejo es compatible (migraciones aditivas suelen serlo: columnas nuevas que el código viejo ignora).
  2. Si la migración fue destructiva (drop/rename), un rollback de esquema requiere una migración de reversa dedicada + restore desde backup del proveedor (Neon/Supabase: point-in-time recovery). Esto es CEO-gated y se coordina con G.
  3. Regla de diseño: preferir migraciones aditivas y expand/contract para que el rollback de código nunca dependa de tocar datos. (Patio Abierto aún no tiene migraciones versionadas; se crean al activar DB — ver deploy.sop.md §5.)
• Nunca correr migrate reset/migrate dev contra producción.

4. Procedimiento de incidente (resumen)

1. Detectar (alertas / logs / reporte).
2. Mitigar: Instant Rollback al último build bueno (§1).
3. Confirmar: smoke test prod + logs limpios.
4. Comunicar: avisar a G/CEO (qué falló, qué se revirtió, URL del build bueno).
5. Diagnosticar en una rama (reproducir, fix + test que cubra la regresión).
6. Re-desplegar por el flujo normal (deploy.sop.md) una vez verificado.
7. Post-mortem breve: causa raíz, cómo lo atrapó (o no) el CI/ROL 1, acción preventiva.

5. Checklist de rollback

• Identificado el último deployment de prod bueno (Ready, previo)
• Instant Rollback / Promote ejecutado (§1) — autorizado por CEO/G
• Smoke test prod OK (3 vistas) + Runtime Logs limpios
• ¿Hubo migración de DB? evaluado §3
• Incidente comunicado a G/CEO
• main limpiado con revert si aplica (§2)
• Registrado en STATUS.md / BLOCKERS.md

6. Qué NO hacer

• ❌ git push --force ni reset sobre main para "deshacer" (usar revert).
• ❌ prisma migrate reset / db push contra producción.
• ❌ Ejecutar el rollback sin autorización del CEO/G (outward-facing).
• ❌ Diagnosticar en prod con el sistema caído: revertir primero, investigar después.