qwen3-6-lora/data/raw/sanitized/plans/quiero-hacer-una-migracion-purrfect-goblet.md

Sincronizar migraciones de Supabase (dev + prod)

Contexto

El repo tiene 37 archivos de migración en supabase/migrations/, el más reciente del 2026-07-22. La última verificación documentada de que ambas bases estaban al día es docs/plans/2026-06-08-supabase-dev-prod-finalization.md, que confirma 9 migraciones aplicadas y verificadas en ambas DBs a esa fecha. Desde entonces se agregaron ~28 migraciones nuevas que probablemente nunca se empujaron a uno o ambos proyectos remotos (streaks, ranking config, bonus settings, admin update policy, etc.). El objetivo es detectar el gap real por ambiente y aplicarlo, sin asumir que "aplicar todo a ambos" es seguro.

Hallazgos clave (ya verificados, solo lectura)

• Supabase CLI no está instalado globalmente, pero npx supabase@latest funciona sin instalación previa (resuelve a la v2.110.0).

• Ya hay sesión autenticada: SUPABASE_ACCESS_TOKEN está exportado en ~/.bashrc, por lo que npx supabase projects list ya respondió sin pedir login.

• Dos proyectos remotos (org vercel_icfg_9zFCFZDSC4E6wody0k7rBxCB):

  Ambiente	Nombre	project-ref
  Production	supabase-gfiber-prod	hwxkegbdnbrzvekrqxbd
  Preview/Dev	supabase-gfiber-dev	vshcimexazocttjmyrqy

• El link local actual (supabase/.temp/project-ref) apunta a prod (hwxkegbdnbrzvekrqxbd, linked: true); dev aparece linked: false. Habrá que re-linkear entre pasos.

• ⚠️ Existen migraciones intencionalmente divergentes entre ambientes — no todas las migraciones deben aplicarse a ambos proyectos:

  • 20260611210000_rollback_attendance_status_prod.sql — deshace una migración anterior solo en prod (prod seguía usando los códigos viejos de asistencia).
  • 20260615120000_simplify_attendance_codes_dev.sql — simplifica los códigos de asistencia solo en dev ("DEV ONLY... Production is NOT touched", literal en el comentario del archivo).

  Un supabase db push ciego a ambos proyectos rompería este estado divergente a propósito. Confirmé por grep que son las únicas dos migraciones con este marcador (_dev/_prod en el nombre o comentario "DEV ONLY/PROD ONLY").

Plan de ejecución

1. Diagnóstico por ambiente (solo lectura, no destructivo):

   • npx supabase link --project-ref hwxkegbdnbrzvekrqxbd (si no sigue linkeado) y npx supabase migration list → lista de migraciones locales vs. aplicadas en prod.
   • npx supabase link --project-ref vshcimexazocttjmyrqy y npx supabase migration list → lo mismo para dev.
   • Esto requiere el password de la DB de cada proyecto (SUPABASE_DB_PASSWORD está en .env para dev; para prod habrá que sacarlo del vault de 1Password "GFiber Pilot Extension" o de vercel env pull --environment=production, como se hizo en el plan de finalización de junio).
   • Registrar qué migraciones aparecen como "pendientes" en cada proyecto.

2. Filtrar las migraciones dev/prod-only del diff genérico:

   • Si 20260611210000_rollback_attendance_status_prod.sql aparece pendiente en dev, no aplicarla ahí (es intencional que dev no la tenga).
   • Si 20260615120000_simplify_attendance_codes_dev.sql aparece pendiente en prod, no aplicarla ahí (es intencional que prod no la tenga).
   • Todas las demás migraciones pendientes (streaks, ranking config, bonus settings, etc.) se tratan como gap real a cerrar en el proyecto donde falten.

3. Aplicar el gap real:

   • npx supabase db push --project-ref <ref> en cada proyecto que tenga migraciones pendientes reales (excluyendo las dev/prod-only según el paso 2).
   • Confirmar con un segundo migration list que ambos remotos quedan con el estado esperado (idéntico salvo las dos migraciones intencionalmente divergentes).

4. Dejar el link local en un estado conocido al terminar (documentar a cuál de los dos quedó linkeado supabase/.temp/project-ref, ya que ambos comandos de push lo van reescribiendo).

Verificación

• npx supabase migration list --project-ref hwxkegbdnbrzvekrqxbd y ... --project-ref vshcimexazocttjmyrqy después del push, comparando que ambas listas coincidan salvo las dos migraciones marcadas como divergentes a propósito.
• Smoke check opcional: revisar en el dashboard de cada proyecto (Table Editor) que las tablas nuevas esperadas (agent_streaks, ranking_config, etc.) existan donde correspondan.

Nota de ejecución

Este trabajo (CLI de Supabase, migraciones de schema) cae dentro del scope del agente vercel-helper según CLAUDE.md. Se recomienda delegarle la ejecución de los pasos 1-4 con este contexto ya resuelto (refs de proyecto, y la lista de migraciones dev/prod-only a excluir), en vez de correr los comandos manualmente en la sesión principal.