Daten & Speicherung

Wo Dinge gespeichert sind, wer was lesen kann und die Regeln, denen der Agent folgt, damit kundenorientierte Seiten niemals versehentlich interne Daten sehen.

Drei Orte, an denen Dinge leben

1. Dein Workspace (`~/workspace/`)

Das Dateisystem, in dem der Agent läuft. Markdown-Entwürfe, generierte Assets, eigene Skills, Jobs, Scratch-Space und diese Dokumentation befinden sich alle hier.

Eigentümer: der Linux-Benutzer agent (der Agent selbst).
Erreichbar vom Chat aus. NICHT erreichbar vom Console-Prozess oder dem öffentlichen Site-Prozess.
Zwei konventionelle Pfade:
~/workspace/uploads/: Dateien, die du in den Chat einfügst, landen hier.
~/workspace/downloads/: Dateien, die der Agent zum Download über die Workspace-Benutzeroberfläche registriert. Werden von nginx unter einer geschützten URL bereitgestellt.

2. PostgreSQL (drei Datenbanken)

Persistenter Zustand für alles Strukturierte. Niemals SQLite, niemals JSON-auf-Festplatte für Anwendungszustand.

Datenbank	Wem gehört sie	Agent	Console	Öffentliche Website
`console_db`	console	R/W	R/W	(blockiert)
`site_db`	site	R/W	R/W	R/W
`console_site_db`	shared	R/W	R/W	R/W

Wo was hingehört:

console_db: Nur interner Status. Kundenlisten, Deal-Phasen, interne Bewertungstabellen, Audit-Logs. Die öffentliche Website kann nicht darauf zugreifen; das REVOKE erfolgt auf der Datenbankrollenebene, nicht nur per Konvention.
site_db: Inhalte, die die öffentliche Website rendert. Vorberechnete Reports, Dokumentationsseiten, alles, was beim Rendern einer Seite günstig zu lesen sein sollte. Die Console schreibt hierhin, die Website liest.
console_site_db: Ein expliziter oberflächenübergreifender Kanal. Console schreibt eine Moderationswarteschlange; Website rendert genehmigte Einträge; Website schreibt Interaktionssignale zurück; Console liest sie.

3. Speicher und Fortschritt

Zwei spezielle Dateien in deinem Workspace:

~/workspace/.memory.md: Wird zu Beginn jedes Chats gelesen. Verwende "remember this: X", um etwas anzuhängen.
~/workspace/progress.md: Änderungsprotokoll. Der Agent hängt nach wichtigen Änderungen etwas an; du kannst es lesen, um nachzuvollziehen, was passiert ist.

Diese sind absichtlich Markdown: Du kannst sie greppen, versionieren, von Hand bearbeiten und erneut greppen.

Warum drei Datenbanken statt einer

Zwei Gründe.

Oberflächentrennung. Ein Besucher der öffentlichen Website könnte theoretisch einen Weg finden, die Datenbankrolle abzufragen, mit der sich die Website authentifiziert. Wenn diese Rolle nur Zugriff auf site_db hat, ist der Explosionsradius eines möglichen Lecks auf Daten beschränkt, die du bereits als öffentlich eingestuft hast.
Klarheit der Absicht. Wenn der Agent eine Console-App schreibt, weiß er, dass er console_db verwenden muss. Wenn er eine Website-Seite schreibt, site_db. Wenn er einen oberflächenübergreifenden Workflow erstellt, console_site_db. Kein versehentliches „Sollte diese Tabelle öffentlich sein?"

Der Agent versucht nicht, diese Regeln zu umgehen. Wenn du fragst „mache diese Console-Seite öffentlich zugänglich", wird er dir sagen, dass er die Daten durch console_site_db verschieben und den Lesepfad auf der Website neu aufbauen muss, anstatt von der Website aus auf console_db zuzugreifen.

Arbeiten mit der Datenbank

Das Muster, jedes Mal:

SQLAlchemy-Session aus src/db.py importiert (gemeinsames Modul pro App).
Pydantic-Modelle schützen jeden Input und jede API-Grenze.
Rohes psycopg2 nur wenn SQLAlchemy übertrieben ist (schreibgeschützte Token-geschützte Lookups, einfache Skripte).

Du wirst CREATE TABLE IF NOT EXISTS-Anweisungen am Anfang neuer Apps sehen. Der Agent behandelt das Schema als Code: Jede App deklariert ihre eigenen Tabellen. Es gibt kein Plattform-Migrationssystem; neue Spalten werden mit ALTER TABLE hinzugefügt und der Agent protokolliert die Änderung.

Was ist mit ClickHouse

ClickHouse ist lokal für Analyse-Workloads verfügbar, bei denen PostgreSQL langsam wäre: Zeitreihen-Rollups über Millionen von Zeilen, spaltenbasierte Aggregationen und dergleichen. Der Agent liest die ClickHouse-Fähigkeit, bevor er sie verwendet, wählt sie bewusst aus und erklärt dir, warum. Standard bleibt PostgreSQL.

Wo Dinge NICHT leben

Kein plattformverwalteter Objektspeicher. Wenn du eine 50 MB große PDF oder ein Video speichern möchtest, speichere es als Datei in ~/workspace/downloads/ (durch nginx geschützt) oder als BYTEA-Spalte in Postgres (geeignet für kleine Artefakte).
Keine Umgebungsvariablen für Secrets. Zugangsdaten werden im typisierten Secret Store gespeichert, der auf Oberflächen und Connectoren beschränkt ist. Der Agent kopiert sie niemals in eine Datei oder eine Datenbankspalte.
Keine „Plattformeinstellungen"-Seite über das hinaus, was die Workspace-Benutzeroberfläche bereitstellt. Zeitpläne, Modi und Genehmigungen sind alles explizite Schalter.

Datenlebenszyklus

Dateien, die du erstellst, bleiben bestehen, bis du sie löschst. Der Agent räumt deinen Workspace nicht automatisch auf.
Datenbankzeilen bleiben bestehen, bis du (oder ein expliziter Cleanup-Job) sie entfernst. Der Agent schreibt Cleanup-Jobs, wenn du darum bittest: „Lösche vsg_runs-Zeilen, die älter als 90 Tage sind, jeden Sonntag."
Speicher- und Fortschrittsdateien wachsen mit der Zeit. Der Agent schlägt gelegentlich eine Bereinigung vor, wenn der Speicher unübersichtlich wird.
Connector-Audit-Logs werden von der Plattform aufbewahrt; du kannst sie durchsuchen, aber nicht löschen.

Unter der Haube. Jede Postgres-Rolle authentifiziert sich über Unix-Socket-Peer-Authentifizierung (der OS-Benutzer entspricht dem Rollennamen). Es gibt kein Passwort, das geleakt werden kann, keinen Connection-String, der falsch konfiguriert werden kann. Grants und REVOKEs sind explizit und sichtbar. Die system_db-Datenbank existiert für Plattform-Interna (der api-proxy, der Connectors-Service, die Bridge); keine Oberfläche verbindet sich jemals damit.