El cerebro de Claude: una base de datos en vez de 14 conexiones sueltas

// Mis herramientas:
[lista tus conexiones / MCPs: Gmail, Slack, HubSpot, Calendar...]

// Mi negocio:
[describe qué haces]

// Mi mayor hueco:
[¿qué contexto pierde tu IA entre conversaciones?]

────────────────────────────────
Diseña mi cerebro de Postgres.

1. Esquema (tablas + columnas)
2. Orden de carga
3. Un sync por cada fuente

// Empieza por los clientes.
// Pregúntame primero.

Quiero montar un "cerebro" para ti: una capa de contexto en Postgres donde
mis fuentes vivan juntas, para que dejes de llamar catorce conectores por
turnos y consultes todo en un lugar. No necesito que programes: tú diseñas y
me explicas en lenguaje normal; el SQL lo generas tú.

ANTES de proponer nada, entrevístame — una pregunta a la vez:

1. ¿Qué fuentes quiero conectar? (Gmail, Slack, mi CRM, calendario, Notion,
   facturación...) Pídeme la lista.
2. Por cada fuente: ¿qué preguntas quiero poder responder con ella? (ej.
   "clientes con factura vencida", "reuniones de la semana con su contexto")
3. ¿Cuáles datos consulto todo el tiempo y cruzo entre fuentes, y cuáles
   necesito fresquísimos al segundo? (esto define qué va al cerebro y qué se
   queda como conector vivo)
4. ¿Qué Postgres voy a usar? (Neon, Supabase, Railway, Render)
5. ¿Presupuesto de sync al mes y cada cuánto tolero que se actualice cada
   fuente? (15 min, 1 hora, 1 vez al día)

Con mis respuestas, diséñame el plan completo y EXPLÍCAMELO ANTES de crear
nada:

- INVENTARIO: una tabla con cada fuente, qué trae, cuánto cambia (alta/media/
  baja rotación) y si va al cerebro (lectura) o se queda como conector vivo
  (acción). Sé honesto: lo que necesito al segundo NO va al cerebro.
- MODELO CANÓNICO: un core chico centrado en el cliente — clients, meetings,
  messages, ai_signals — con el DDL propuesto. Cada fila lleva source_app,
  source_id, updated_at y synced_at.
  Debajo, tablas crudas por fuente (bronze), el core conformado (silver) y un
  puñado de vistas para que yo (el agente) consulte (gold).
- ORDEN DE CARGA: en qué orden se llenan las tablas y por qué (primero
  entidades, luego eventos que las referencian, etc.).
- PLAN DE SYNC: por cada fuente, la herramienta (Airbyte, dlt, n8n o Estuary),
  el modo (batch cada X min o CDC) y por qué ese modo. Batch para casi todo;
  CDC solo donde de verdad haga falta.
- TABLA DE COSTO Y FRESCURA: por fuente, costo estimado de sync al mes y qué
  tan fresco quedará el dato. Marca los números como aproximados.
- RESOLUCIÓN DE ENTIDADES: cómo vas a decidir que la misma persona en dos
  fuentes es la misma (llave por correo + tabla de alias para lo que no calce).

Preséntame todo como tu plan, en modo Plan: el inventario, el DDL y el plan de
sync, para leerlo antes de aprobar. No crees ni un archivo sin mi OK.

Ya aprobamos el plan del cerebro. Ahora genera el esquema en SQL de Postgres.
Escríbelo tú entero; yo solo reviso y apruebo. Explícame en lenguaje normal qué
hace cada bloque antes del código.

1. CORE (silver): las cuatro tablas del cerebro — clients, meetings, messages y
   ai_signals.
   - clients: quién es cada cliente (name, company, last_contact, deal_status).
     Es el centro; todo lo demás apunta aquí con un client_id.
   - meetings: reuniones (date, summary, action_items[]) con su client_id.
   - messages: correos y chats (channel, content, sent_at) con su client_id.
   - ai_signals: patrones detectados (pattern, sources[], flagged_at) con su
     client_id — recuerda que esta tabla la escribe la capa de análisis, no la
     conexión de Claude.
   - CADA tabla lleva estas columnas de rastreo, sin excepción:
     source_app (gmail/slack/hubspot...), source_id (id en la fuente),
     updated_at (cuándo cambió allá), synced_at (cuándo lo copiamos).
   - Una restricción unique (source_app, source_id) por tabla, para no
     duplicar al re-sincronizar.

2. BRONZE: una tabla cruda por fuente (gmail_raw, hubspot_raw, ...) que guarde el
   payload tal como llega, sin transformar. Es la red de seguridad.

3. GOLD: 2 o 3 vistas ya cruzadas, con nombres que expliquen qué son, pensadas
   para que YO (el agente) las consulte directo. Por ejemplo una vista
   "client_activity" que junte por cliente su último correo, su etapa de trato,
   su última reunión y su último mensaje de Slack. Estas vistas son las que voy
   a leer; nada más.

4. RESOLUCIÓN DE ENTIDADES: la lógica para unir al mismo cliente entre fuentes.
   Empieza por el correo como llave; crea una tabla client_alias para los casos
   que no calcen por correo, y explícame cómo la lleno.

Reglas: comenta cada tabla y cada vista con una línea de para qué sirve. No
inventes columnas que no salgan de mis fuentes. Al final, dame el orden exacto
en que debo correr el SQL (primero core, luego bronze, luego vistas gold) y
recuérdame que el agente solo debería tener permiso de lectura sobre las vistas
gold — eso lo endurecemos en el siguiente paso.

A partir de hoy llevas la salud del cerebro. Esta es la rutina que corremos una
vez por semana cuando yo te diga "re-sync semanal":

1. REFRESCA: dispara el sync de cada fuente según su plan (batch de Airbyte/dlt/
   n8n). Recuérdame cuáles son batch y cuáles CDC continuo. No re-sincronices
   lo que no cambió: usa updated_at para traer solo lo nuevo.
2. FRESCURA: por cada tabla del core, dime el synced_at más viejo y el más
   nuevo. Marca en rojo cualquier fuente cuyo dato más viejo pase el umbral que
   acordamos (ej. más de 24 h en algo que debería refrescarse cada hora).
3. INTEGRIDAD: revisa que la resolución de entidades no se haya roto — clientes
   duplicados nuevos, correos que aparecen en dos clientes, filas huérfanas en
   messages sin su client_id. Dame la lista para que yo decida, no la arregles
   sola.
4. COSTO: dime cuánto llevo gastado del presupuesto de sync este mes y qué
   fuente se está comiendo la mayor parte. Si alguna tabla de alta rotación está
   disparando el costo, propónme bajarle la frecuencia o pasarla a conector
   vivo.
5. RESUMEN: cierra con 5 líneas — qué se refrescó, qué quedó viejo y por qué,
   qué revisar a mano, y si algo debería salir del cerebro (o entrar).

Guarda esta rutina para que "re-sync semanal" siempre signifique estos 5 pasos.
Y recuérdame la regla de oro: un cerebro que se ve fresco pero está viejo es
peor que uno que admite su fecha de corte.

Vamos a conectar mi Postgres a Claude por MCP, en modo solo-lectura. Guíame
paso a paso y explícame qué hace cada comando antes de que lo corra.

1. INSTALA el servidor: crystaldba/postgres-mcp (Postgres MCP Pro, MIT, en
   Python). Dame el comando exacto para mi sistema (pipx o uv) y qué revisar si
   falla.
2. CONÉCTALO a Claude Code con claude mcp add, pasando mi DATABASE_URI como
   variable de entorno y con --access-mode=restricted (modo restringido de
   solo-lectura con topes de recursos). Explícame por qué restricted y no el
   modo sin restricción.
3. VERIFICA la conexión sin cambiar nada de la base:
   - Lista las tablas y vistas que ve el MCP.
   - Muéstrame las vistas gold que definimos y confirma que las encuentra.
   - Corre el chequeo de salud de la base que trae el servidor (índices, cache,
     vacuum) y resúmemelo en lenguaje normal.
   - Haz UNA consulta de lectura de ejemplo contra una vista gold (por ejemplo,
     cuántos clientes hay por source_app) para confirmar que puede leer.
4. Si algo falla — no encuentra el MCP, no conecta a la base, o el modo no
   quedó en restricted — dímelo claro y en qué paso, antes de seguir.

Importante: en este paso NO se escribe ni se modifica nada en la base. Si en
algún momento necesitas permiso de escritura para "verificar", detente y
avísame: no lo tienes ni lo vas a tener.

Quiero endurecer la seguridad del cerebro a nivel de la base, no solo confiar
en el modo del MCP. Genérame el SQL de Postgres para un rol de mínimo
privilegio, y explícame cada línea antes.

1. Crea un rol nuevo, por ejemplo claude_readonly, SIN permiso de login de
   superusuario y sin poder crear ni borrar objetos.
2. QUÍTALE todo por defecto y dale de vuelta SOLO lo mínimo:
   - Permiso de conexión a la base.
   - USAGE sobre el esquema.
   - SELECT únicamente sobre las vistas gold (no sobre las tablas crudas bronze
     ni sobre el core silver, si se puede evitar).
   - Nada de INSERT, UPDATE, DELETE, TRUNCATE ni DDL. Revócalos explícitamente.
3. Asegúrate de que los objetos que se creen en el futuro NO le den permiso
   automático a este rol (ALTER DEFAULT PRIVILEGES para que no herede SELECT en
   tablas nuevas sin que yo lo decida).
4. Dame la cadena de conexión (DATABASE_URI) que debo usar con ESTE rol en el
   MCP, en vez de la de mi usuario dueño.

Al final, dame una lista de verificación de 5 puntos para confirmar que el rol
quedó de solo-lectura — incluyendo una consulta que YO pueda correr para probar
que un INSERT o un UPDATE con ese rol es rechazado. Recuérdame que este rol es
el que va en el MCP, y que mi usuario dueño (el que puede escribir) nunca se
conecta a Claude.

Usa el MCP de Postgres para responderme esto consultando el cerebro — no los
conectores en vivo. Todo debe salir de la base; si un dato no está ahí, dímelo
en vez de inventarlo o de ir a buscarlo a la fuente.

La pregunta: de los clientes que me escribieron por correo en los últimos 7
días, dime cuáles además tienen una factura vencida en el CRM y ninguna
respuesta mía en Slack sobre ese tema. Para cada uno:

- Nombre y empresa (de clients).
- Fecha del último correo que me mandó y de qué trataba (de messages).
- Etapa del trato y monto (de clients / la vista gold del CRM).
- Si hay o no un hilo de Slack relacionado y cuándo fue el último mensaje.
- Una prioridad sugerida (alta/media/baja) según monto vencido y silencio.

Cómo quiero que trabajes:

1. Primero dime qué vistas gold vas a consultar y con qué llaves las vas a
   cruzar (probablemente el correo o el client_id). Enséñame el SQL antes de
   correrlo.
2. Corre solo lecturas (SELECT). Nada de escribir.
3. Marca cada fila con su synced_at más reciente entre las fuentes que usaste,
   para que yo sepa qué tan fresco es cada dato.
4. Si una fuente está desactualizada (synced_at viejo) o falta, dímelo claro:
   "esto es de hace 3 horas" es información, no un detalle.
5. Cierra con una tabla ordenada por prioridad y una línea de qué NO se puede
   responder solo con el cerebro (por ejemplo, si hace falta el correo del
   último minuto, eso se pide en vivo, no aquí).