AI Radar: aplicar la migración de persistencia antes de habilitar la ingesta

[lisa584]

Evidencia

Durante la prueba del flujo Notion → búsqueda → guardado → frontend del 2026-07-21:

• El proyecto Supabase vvrcwrmghindrbpyxhku respondió con estado ACTIVE_HEALTHY.
• La consulta de migraciones aplicadas devolvió una lista vacía.
• La consulta de tablas del esquema public devolvió una lista vacía.
• No existen las tablas ai_radar_runs ni ai_radar_signals esperadas por la aplicación.
• Dos señales recientes pasaron la validación de contracts/airadar-daily-signals.schema.json y obtuvieron huellas estables, pero no pudieron persistirse.

Pasos para reproducir

1. Consultar el proyecto Supabase vvrcwrmghindrbpyxhku.
2. Listar las migraciones aplicadas.
3. Listar las tablas del esquema public.
4. Verificar que no aparecen ai_radar_runs ni ai_radar_signals.
5. Preparar un lote válido para POST /api/ai-radar/ingest con el contrato airadar.daily-signals.
6. Intentar la ingesta desde un entorno server-side configurado, sin exponer credenciales al cliente.

Resultado esperado

La migración supabase/migrations/20260721162723_create_ai_radar_persistence.sql está aplicada y crea las tablas de ejecuciones y señales con los índices, restricciones y RLS definidos. Un lote válido se persiste de forma idempotente y devuelve run_id y conteos.

Resultado actual

Supabase está disponible, pero no tiene migraciones ni tablas. La ingesta no puede persistir señales nuevas y no existe una base de datos que el frontend pueda consultar.

Archivos probables

• supabase/migrations/20260721162723_create_ai_radar_persistence.sql
• docs/ai-radar-persistence.md
• api/ai-radar/ingest.js
• api/ai-radar/signals.js
• api/_lib/airadar.js
• tests/airadar-persistence.test.mjs

Criterios de aceptación

• La migración de persistencia figura como aplicada en el proyecto Supabase objetivo.
• Existen public.ai_radar_runs y public.ai_radar_signals con el esquema esperado.
• RLS está activado y los roles anon y authenticated no obtienen acceso indebido.
• Una ingesta server-side de un lote válido devuelve run_id, estado y conteos de creadas, actualizadas, omitidas y errores.
• Reingestar el mismo lote actualiza por fingerprint sin duplicar señales.
• Existe una consulta administrativa o server-side documentada para verificar las filas guardadas sin exponer la clave de servicio.
• Las pruebas existentes pasan tras aplicar la migración.