Fase 2: 04_sanitize.py - scrubbing de secretos de skills/agentes/plans (10 secretos unicos, gate en verde)

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

@@ -0,0 +1,84 @@
+# 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.