# 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.