Supabase Data API returns empty sources and signals after news workflow test

[JohnReyes02]

Evidencia

Con las variables públicas disponibles en .env, se consultaron las tablas por REST usando SUPABASE_URL y SUPABASE_PUBLISHABLE_KEY:

/rest/v1/sources?select=name,url&limit=3 -> 200 []
/rest/v1/signals?select=id,title,source_id&limit=3 -> 200 []

La API responde 200, pero no hay datos visibles en sources ni signals para validar que las noticias nuevas se hayan persistido.

Pasos para reproducir

1. Cargar .env con SUPABASE_URL y SUPABASE_PUBLISHABLE_KEY.
2. Consultar GET /rest/v1/sources?select=name,url&limit=3 con headers apikey y Authorization: Bearer <publishable key>.
3. Consultar GET /rest/v1/signals?select=id,title,source_id&limit=3 con los mismos headers.
4. Observar las respuestas.

Resultado esperado

Después de ejecutar el flujo de búsqueda y guardado de noticias, Supabase debe contener filas en sources, daily_snapshots y signals, y debe ser posible verificar los conteos o últimos registros por una vía documentada.

Resultado actual

Las consultas públicas devuelven arrays vacíos. No hay evidencia desde Supabase de que las noticias nuevas hayan sido guardadas.

Archivos probables

• supabase/migrations/0001_ai_radar_persistence.sql
• supabase/migrations/0003_explicit_deny_client_access.sql
• src/persistence/saveSignals.js
• src/persistence/supabaseClient.js
• api/signals/save.js
• scripts/save_daily_signals.js

Criterio de aceptación

• Existe un procedimiento documentado para verificar datos guardados en Supabase sin exponer SUPABASE_SERVICE_ROLE_KEY al frontend.
• Tras guardar un snapshot válido, una consulta server-side o administrativa muestra filas en sources, daily_snapshots y signals.
• El resultado de guardado reporta queryDate, snapshotId, signalsSaved y sourcesUpserted.
• Queda claro si la Data API pública debe devolver datos o permanecer cerrada por RLS.

[JohnReyes02]

Implementado localmente: agregué como vía server-side de lectura y la migración para permisos explícitos de en la Data API, manteniendo la Data API pública cerrada. Documenté que /publishable key no es la vía de verificación. Verificación local: el endpoint responde con fallback declarado cuando falta service role. Pendiente antes de cerrar: aplicar migración/configurar , guardar un snapshot y confirmar que sea .

[JohnReyes02]

Correccion del comentario anterior: estado autoritativo.

Implementado localmente:

• Agregado GET /api/signals/latest como lectura server-side para el dashboard.
• Agregada migracion supabase/migrations/0004_grant_service_role_data_api_access.sql con permisos explicitos para service_role.
• README aclara que la Data API publica con publishable key permanece cerrada; la verificacion de datos debe pasar por endpoint server-side.

Verificacion:

• GET /api/signals/latest responde en local con fallback declarado cuando falta SUPABASE_SERVICE_ROLE_KEY.
• El fallback informa dataSource.type = fixture y la razon de configuracion faltante.

Pendiente antes de cerrar:

• Aplicar la migracion en Supabase, configurar SUPABASE_SERVICE_ROLE_KEY, guardar un snapshot y confirmar dataSource.type = supabase.

[JohnReyes02]

Actualizacion de implementacion Supabase:

Resuelto en remoto:

• La migracion grant_service_role_data_api_access ya aparece aplicada en Supabase.
• Las tablas sources, daily_snapshots y signals tienen RLS activo.
• service_role tiene privilegios select, insert, update, delete.
• Las politicas restrictivas para anon y authenticated siguen activas (using false, with check false).
• Snapshot 2026-07-08 verificado con source_count=3, signal_count=5, has_google_deepmind=true.

Estado local:

• /api/signals/latest funciona y cae a fixture declarado porque falta SUPABASE_SERVICE_ROLE_KEY en .env.
• Cuando ese secreto exista en el entorno server-side, el mismo endpoint debe devolver dataSource.type = supabase.