SOP — Deploy de Patio Abierto (Vercel)

Tipo: procedimiento operativo estándar. Estado: prep deploy-ready. 🔴 Boundary: este SOP NO se ejecuta en autonomía. Provisionar infra, crear el proyecto Vercel, conectar dominio o desplegar a producción es outward-facing / CEO-gated (ver .context/VERIFICATION-LOOP.md y AUTONOMY-RULES.md). Este documento describe el cómo; el CEO/G autoriza el cuándo.

0. Contexto del stack

• App: Next.js 16 (App Router, Turbopack) + TS + Tailwind v4 + shadcn.
• Runtime: Node (Fluid Compute). Sin Edge runtime obligatorio.
• Datos: Postgres opcional vía lib/platform (Prisma 7 + @prisma/adapter-pg). DB-ready, inactiva sin DATABASE_URL → la app corre con el repo in-memory de lib/patio. Ver docs/platform/database.md.
• Gate de calidad: CI (.github/workflows/ci.yml) — 4 jobs (lint, typecheck, build, test) verdes son precondición de merge y, por tanto, de cualquier deploy.

1. Modelo de entornos

Entorno	Trigger	URL	DB
Preview	cada push a una rama con PR	URL única por deploy (*.vercel.app)	sin DATABASE_URL ⇒ in-memory (o DB de preview si se decide)
Production	merge/promote a main	dominio de producción	DATABASE_URL de prod (solo si DB activada)

Regla: nada llega a prod sin pasar por Preview + CI verde + audit de G.

2. Pre-requisitos (una sola vez, CEO/G)

1. Proyecto en Vercel ligado al repo MarxCha/patio-abierto (framework: Next.js, autodetectado).
2. Production Branch = main. Preview = todas las demás ramas.
3. Build & Output (defaults de Next):
   • Install: npm ci (corre postinstall: prisma generate).
   • Build: next build.
   • Output: .next (gestionado por el preset Next de Vercel).
4. Variables de entorno (Project → Settings → Environment Variables): ver §4.
5. (Opcional) vercel.json/vercel.ts solo si se necesitan crons/headers/rewrites; hoy no es necesario.

3. Procedimiento de deploy (flujo normal)

1. Rama + PR. Trabajo en rama corta → PR a main.
2. Preview automático. Vercel publica un Preview Deployment por cada push del PR. Verificar la URL de preview (UI real, no solo CI).
3. Gate. CI 4 jobs verdes + verificación independiente (ROL 1) + audit de G.
4. Promoción a prod. Al mergear a main, Vercel construye y despliega producción.
   • Alternativa controlada: Promote un deployment de preview ya validado a production desde el dashboard (evita rebuild) — preferible para releases.
5. Verificación post-deploy. Abrir la URL de prod, smoke test de las 3 vistas (inventario / malla / garita), revisar logs (vercel → Runtime Logs) sin errores.
6. Registro. Anotar el deployment (commit, URL, hora) en STATUS.md.

4. Variables de entorno

Variable	Entorno	Cuándo	Notas
DATABASE_URL	Production (y Preview si se quiere DB)	solo al activar Postgres	Inyectada por la integración del Marketplace; nunca en el repo. Ver §5 + rollback.sop.md.
CUSTOMS_API_BASE_URL	Prod/Preview	cuando exista la fachada real (aduanamx#61/#69)	hoy el cliente usa mocks
CUSTOMS_SERVICE_TOKEN	Prod/Preview	con la fachada real	bearer de servicio que lee getServiceToken (components/patio/customs.ts). Con CUSTOMS_API_BASE_URL pero sin este, el cliente degrada a solo físico

• Plantilla: .env.example. Sin DATABASE_URL, la ruta Postgres queda inactiva por diseño.

5. Activación de Postgres (DB-ready → activo) — CEO-gated

Detalle completo en docs/platform/database.md. Resumen:

1. Aprovisionar Postgres desde Vercel Marketplace (Neon o Supabase). La integración inyecta DATABASE_URL (Production + Preview) automáticamente — no se commitea.
2. Migrar el esquema con la variable presente: npm run db:deploy (prisma migrate deploy). Requiere haber creado la migración inicial (prisma migrate dev --name init) en un entorno con DB.
3. Cablear getPostgresInventarioRepository() en el PatioService + async-ificar lib/patio (paso explícito del seam; coordina G/B). Hasta ese paso, aunque exista DATABASE_URL, el dominio puede seguir usando in-memory.
4. Pooling serverless: usar URL con pooler (PgBouncer/Neon pooled) en DATABASE_URL.

6. Checklist de deploy (copiar al PR de release)

• CI 4 jobs verdes
• Preview revisado (3 vistas, light/dark/móvil) — ROL 1 PASS
• Audit de frontera + contrato (G)
• Variables de entorno correctas en el entorno destino
• (si DB activa) migraciones aplicadas db:deploy
• Smoke test post-deploy en prod + logs limpios
• Deployment registrado en STATUS.md
• Plan de rollback a mano (ver rollback.sop.md)

7. Qué NO hacer

• ❌ Desplegar a prod sin CI verde / sin audit de G.
• ❌ Poner credenciales reales en el repo o en .env versionado.
• ❌ Aprovisionar DB o crear el proyecto Vercel en autonomía (CEO-gated).
• ❌ Saltarse el Preview (todo cambio se ve primero en una URL de preview).