Datos y almacenamiento

Dónde están las cosas, quién puede leer qué y las reglas que sigue el agente para que las páginas de cara al cliente nunca vean accidentalmente datos internos.

Tres lugares donde viven las cosas

1. Tu espacio de trabajo (~/workspace/)

El sistema de archivos en el que se ejecuta el agente. Los borradores en Markdown, los recursos generados, las habilidades personalizadas, los trabajos, el espacio de trabajo temporal y estos documentos se encuentran aquí.

• Propietario: el usuario de Linux agent (el propio agente).
• Accesible desde el chat. NO accesible desde el proceso de la consola ni desde el proceso del sitio público.
• Dos rutas convencionales:
• ~/workspace/uploads/: los archivos que pegues en el chat se guardan aquí.
• ~/workspace/downloads/: archivos que el agente registra para descargar a través de la interfaz del espacio de trabajo. Servidos por nginx en una URL protegida.

2. PostgreSQL (tres bases de datos)

Estado persistente para cualquier cosa estructurada. Nunca SQLite, nunca JSON en disco para el estado de la aplicación.

Qué va dónde:

• console_db: estado exclusivamente interno. Listas de clientes, etapas de negociación, tablas de puntuación internas, registros de auditoría. El sitio público no puede acceder a ella; el REVOKE está en la capa de rol de base de datos, no es solo una convención.
• site_db: contenido que renderiza el sitio público. Informes precalculados, páginas de documentación, cualquier cosa que deba ser económica de leer al renderizar una página. La Consola escribe aquí, el sitio lee.
• console_site_db: un canal explícito entre superficies. La Consola escribe una cola de moderación; el sitio renderiza las entradas aprobadas; el sitio escribe señales de interacción; la Consola las lee.

3. Memoria y progreso

Dos archivos especiales en tu espacio de trabajo:

• ~/workspace/.memory.md: read at the start of every chat. Use "remember this: X" to append.
• ~/workspace/progress.md: change log. The agent appends after meaningful changes; you can read it to reconstruct what happened.

Son markdown a propósito: puedes buscarlos con grep, versionarlos, editarlos a mano y volver a buscarlos con grep.

Por qué tres bases de datos en lugar de una

Dos razones.

1. Separación de superficies. Un visitante del sitio público podría, en principio, encontrar una forma de consultar el rol de base de datos con el que se autentica el sitio. Si ese rol solo tiene acceso a site_db, el radio de impacto de cualquier filtración se limita a los datos que ya decidiste que fueran públicos.
2. Claridad de intención. Cuando el agente escribe una aplicación de consola, sabe que debe usar console_db. Cuando escribe una página del sitio, site_db. Cuando construye un flujo de trabajo entre superficies, console_site_db. Sin preguntas accidentales de "¿debería esta tabla ser pública?"

El agente no intenta saltarse estas reglas. Si le pides "exponer esta página de Console públicamente", te dirá que necesita mover los datos a través de console_site_db y reconstruir la ruta de lectura en el sitio, en lugar de acceder a console_db desde el sitio.

Trabajar con la base de datos

El patrón, cada vez:

• Sesión de SQLAlchemy importada desde src/db.py (módulo compartido por aplicación).
• Los modelos de Pydantic protegen cada entrada y cada límite de API.
• psycopg2 sin procesar solo cuando SQLAlchemy es excesivo (búsquedas de solo lectura protegidas por token, scripts simples).

Verás declaraciones CREATE TABLE IF NOT EXISTS en la parte superior de las aplicaciones nuevas. El agente trata el esquema como código: cada aplicación declara sus propias tablas. No hay un sistema de migración de la plataforma; las nuevas columnas se añaden con ALTER TABLE y el agente registra el cambio.

¿Qué pasa con ClickHouse?

ClickHouse está disponible localmente para cargas de trabajo de análisis donde PostgreSQL sería lento: acumulaciones de series temporales sobre millones de filas, agregaciones en columnas, ese tipo de cosas. El agente lee la habilidad de ClickHouse antes de usarla, la elige deliberadamente y te explica por qué. PostgreSQL sigue siendo la opción predeterminada.

Dónde las cosas NO viven

• Sin almacenamiento de objetos gestionado por la plataforma. Si quieres guardar un PDF de 50 MB o un vídeo, guárdalo como archivo en ~/workspace/downloads/ (controlado por nginx) o como columna BYTEA en Postgres (adecuado para artefactos pequeños).
• Sin variables de entorno para secretos. Las credenciales se guardan en el almacén de secretos tipado, con ámbito limitado a superficies y conectores. El agente nunca las copia en un archivo o columna de base de datos.
• Sin página de "configuración de plataforma" más allá de lo que expone la interfaz del espacio de trabajo. Los horarios, modos y aprobaciones son todos interruptores explícitos.

Ciclo de vida de los datos

• Los archivos que creas permanecen hasta que los eliminas. El agente no limpia automáticamente tu espacio de trabajo.
• Las filas de la base de datos permanecen hasta que tú (o un trabajo de limpieza explícito) las eliminas. El agente escribe trabajos de limpieza cuando lo solicitas: "eliminar filas de vsg_runs con más de 90 días cada domingo".
• Los archivos de memoria y progreso crecen con el tiempo. El agente ocasionalmente sugiere una limpieza cuando la memoria se vuelve ruidosa.
• Los registros de auditoría del conector son retenidos por la plataforma; puedes consultarlos pero no puedes eliminarlos.

Bajo el capó. Cada rol de Postgres se autentica mediante autenticación peer de socket Unix (el usuario del sistema operativo coincide con el nombre del rol). No hay contraseña que filtrar, ni cadena de conexión que configurar incorrectamente. Los permisos GRANT y REVOKE son explícitos y visibles. La base de datos system_db existe para los componentes internos de la plataforma (el api-proxy, el servicio de conectores, el puente); ninguna superficie se conecta nunca a ella.