Données et stockage

Où les éléments se trouvent, qui peut lire quoi, et les règles que l'agent suit pour que les pages destinées aux clients ne voient jamais accidentellement les données internes.

Trois endroits où les choses vivent

1. Votre espace de travail (~/workspace/)

Le système de fichiers dans lequel l'agent IA s'exécute. Les brouillons Markdown, les ressources générées, les compétences personnalisées, les tâches, l'espace de travail temporaire et cette documentation se trouvent tous ici.

• Propriétaire : l'utilisateur Linux agent (l'agent lui-même).
• Accessible depuis le chat. NON accessible depuis le processus Console ou le processus du site public.
• Deux chemins conventionnels :
• ~/workspace/uploads/ : les fichiers que vous collez dans le chat arrivent ici.
• ~/workspace/downloads/ : les fichiers que l'agent enregistre pour téléchargement via l'interface de l'espace de travail. Servis par nginx à une URL protégée.

2. PostgreSQL (trois bases de données)

État persistant pour tout ce qui est structuré. Jamais SQLite, jamais de JSON sur disque pour l'état de l'application.

Où va quoi :

• console_db : état interne uniquement. Listes de clients, étapes de transactions, tables de notation internes, journaux d'audit. Le site public ne peut pas y accéder ; la révocation se fait au niveau du rôle de base de données, pas seulement par convention.
• site_db : contenu rendu par le site public. Rapports pré-calculés, pages de documentation, tout ce qui doit être peu coûteux à lire lors du rendu d'une page. La Console y écrit, le site y lit.
• console_site_db : un canal inter-surfaces explicite. La Console y écrit une file d'attente de modération ; le site affiche les entrées approuvées ; le site y écrit les signaux d'interaction ; la Console les lit.

3. Mémoire et progression

Deux fichiers spéciaux dans votre espace de travail :

• ~/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.

Ils sont au format markdown intentionnellement : vous pouvez les rechercher avec grep, les versionner, les modifier manuellement et les rechercher à nouveau avec grep.

Pourquoi trois bases de données au lieu d'une seule

Deux raisons.

1. Séparation des surfaces. Un visiteur d'un site public pourrait, en principe, trouver un moyen d'interroger le rôle de base de données avec lequel le site s'authentifie. Si ce rôle n'a accès qu'à site_db, le rayon d'impact de toute fuite est limité aux données que vous avez déjà décidé de rendre publiques.
2. Clarté de l'intention. Lorsque l'agent écrit une application Console, il sait utiliser console_db. Lorsqu'il écrit une page de site, site_db. Lorsqu'il construit un workflow multi-surfaces, console_site_db. Aucune question accidentelle du type « cette table devrait-elle être publique ? »

L'agent n'essaie pas de contourner ces règles. Si vous demandez « exposez publiquement cette page Console », il vous indiquera qu'il doit déplacer les données via console_site_db et reconstruire le chemin de lecture sur le site, plutôt que d'accéder à console_db depuis le site.

Travailler avec la base de données

Le schéma, à chaque fois :

• Session SQLAlchemy importée depuis src/db.py (module partagé par application).
• Les modèles Pydantic protègent chaque entrée et chaque limite d'API.
• psycopg2 brut uniquement lorsque SQLAlchemy est excessif (recherches en lecture seule protégées par jeton, scripts simples).

Vous verrez des instructions CREATE TABLE IF NOT EXISTS en haut des nouvelles applications. L'agent traite le schéma comme du code : chaque application déclare ses propres tables. Il n'y a pas de système de migration de plateforme ; les nouvelles colonnes sont ajoutées avec ALTER TABLE et l'agent enregistre la modification.

Qu'en est-il de ClickHouse

ClickHouse est disponible localement pour les charges de travail analytiques où PostgreSQL serait lent : agrégations temporelles sur des millions de lignes, agrégations en colonnes, ce genre de choses. L'agent lit la compétence ClickHouse avant de l'utiliser, la choisit délibérément et vous explique pourquoi. PostgreSQL reste l'option par défaut.

Où les choses NE se trouvent PAS

• Pas de stockage d'objets géré par la plateforme. Si vous souhaitez stocker un PDF de 50 Mo ou une vidéo, enregistrez-le comme fichier dans ~/workspace/downloads/ (contrôlé par nginx) ou comme colonne BYTEA dans Postgres (adapté pour les petits artefacts).
• Pas de variables d'environnement pour les secrets. Les identifiants résident dans le magasin de secrets typé, limité aux surfaces et connecteurs. L'agent ne les copie jamais dans un fichier ou une colonne de base de données.
• Pas de page « paramètres de la plateforme » au-delà de ce que l'interface de l'Workspace expose. Les planifications, modes et approbations sont tous des boutons explicites.

Cycle de vie des données

• Les fichiers que vous créez restent jusqu'à ce que vous les supprimiez. L'agent ne nettoie pas automatiquement votre espace de travail.
• Les lignes de base de données restent jusqu'à ce que vous (ou une tâche de nettoyage explicite) les supprimiez. L'agent écrit des tâches de nettoyage lorsque vous le demandez : « supprimer les lignes vsg_runs de plus de 90 jours tous les dimanches ».
• Les fichiers de mémoire et de progression augmentent avec le temps. L'agent suggère occasionnellement un nettoyage lorsque la mémoire devient encombrée.
• Les journaux d'audit des connecteurs sont conservés par la plateforme ; vous pouvez les consulter mais ne pouvez pas les supprimer.

Sous le capot. Chaque rôle Postgres s'authentifie via l'authentification par pair de socket Unix (l'utilisateur du système d'exploitation correspond au nom du rôle). Il n'y a pas de mot de passe à divulguer, pas de chaîne de connexion à mal configurer. Les GRANT et REVOKE sont explicites et visibles. La base de données system_db existe pour les éléments internes de la plateforme (l'api-proxy, le service de connecteurs, le bridge) ; aucune surface ne s'y connecte jamais.