El agente puede ver la base de la sala: estructura y filas

[ErickUser1]

Qué pasaba

La única tool de la base era sql, que cambia la estructura y contesta "listo" (ejecutarSql descartaba la respuesta). El agente no podía ver qué tablas, columnas o políticas había, así que las adivinaba y escribía código contra columnas que quizá no existían. Pasa sobre todo con proyectos adoptados (#98), donde migraciones/ está vacía aunque la base no. Tampoco podía comprobar si algo se guardó.

Cambios

• Tool nueva ver_base (server/src/agent/tools/ver-base.ts), solo lectura, como en Lovable:
  • Sin argumentos: tablas de public con columnas (tipo, not null, default), llaves, si tienen RLS activo o forzado, y sus políticas. Sale del catálogo, no lee filas.
  • Con consulta: un SELECT, hasta 50 filas y unos 8000 caracteres, con aviso si hay más.
  • La garantía de que no escribe es de Supabase (read_only: true en /database/query). Además, se rechaza antes de llamar lo que no empieza como lectura, y los SELECT de una sola sentencia viajan envueltos con limit 51.
• ejecutarSql devuelve lo que responde Supabase y acepta soloLectura. Los que la llaman hoy ignoran el retorno, así que el cambio es compatible.
• sqlDeLaSala y la nueva lecturaDeLaSala comparten conLaBaseDeLaSala: el token se sigue renovando en cada llamada y la credencial sigue sin entrar al contenedor.
• sql y ver_base devuelven el error de Postgres como error de la tool, no como error inesperado, que parecía una falla de Multi.
• El prompt pide mirar la base antes de crear tablas o escribir código contra ellas, y no copiar datos de personas al chat si no hace falta.
• La línea de actividad dice "Revisando la base de datos" / "Looking at the database".
• demo:ver-base (28 casos) entra al CI.

Lo que no toca

OAuth, callback, preparación del proyecto, las reglas de políticas abiertas y las migraciones de sql. El candado por sala de sql y el resumen de cambios a la base para otros agentes van aparte.

Cómo se probó

• npm run typecheck, npm run build y las demos del CI (providers, back, politicas, actividad, modo-de-sala, ver-base).
• De punta a punta, con el server y el loop del agente reales, simulando solo la API de Anthropic (un modelo que llama a ver_base) y la de Supabase:
  • El modelo recibe ver_base entre sus tools, y la actividad llega como verBase.
  • "¿qué tablas hay?" devuelve la estructura con RLS, llaves y políticas.
  • select * from tareas devuelve 50 filas y avisa que hay más.
  • count(*) devuelve 1 fila. {"total":7}.
  • delete from tareas se rechaza sin llamar a la base.
  • Una columna inexistente devuelve el error 42703 de Postgres, limpio.
  • Supabase recibió todas las lecturas con read_only: true y envueltas en limit 51. La única escritura fue la de armarRls al preparar el proyecto.

Falta confirmarlo contra un Supabase real (el proxy de esta sesión lo bloquea). En producción: pedirle al agente que liste las tablas, que cuente registros, y que intente un delete con ver_base, que debe fallar.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HJ5oT2Xm3VZMvbPAcgKbz4

---

Generated by Claude Code