Dados e armazenamento

Onde as coisas ficam, quem pode ler o quê e as regras que o agente de IA segue para que as páginas voltadas ao cliente nunca vejam acidentalmente dados internos.

Três lugares onde as coisas ficam

1. Sua área de trabalho (~/workspace/)

O sistema de arquivos no qual o agente é executado. Rascunhos em Markdown, recursos gerados, habilidades personalizadas, trabalhos, espaço de rascunho e estes documentos ficam todos aqui.

• Proprietário: o usuário Linux agent (o próprio agente).
• Acessível pelo chat. NÃO acessível pelo processo do Console ou pelo processo do site público.
• Dois caminhos convencionais:
• ~/workspace/uploads/: os arquivos que você cola no chat ficam aqui.
• ~/workspace/downloads/: arquivos que o agente registra para download pela interface da área de trabalho. Servidos pelo nginx em uma URL protegida.

2. PostgreSQL (três bancos de dados)

Estado persistente para qualquer coisa estruturada. Nunca SQLite, nunca JSON em disco para estado da aplicação.

O que vai onde:

• console_db: estado exclusivamente interno. Listas de clientes, estágios de negócios, tabelas de pontuação internas, registros de auditoria. O site público não pode acessá-lo; o REVOKE está na camada de função do banco de dados, não apenas por convenção.
• site_db: conteúdo que o site público renderiza. Relatórios pré-computados, páginas de documentação, qualquer coisa que deva ser barata de ler em uma renderização de página. O Console escreve aqui, o site lê.
• console_site_db: um canal explícito entre superfícies. O Console escreve uma fila de moderação; o site renderiza entradas aprovadas; o site escreve de volta sinais de interação; o Console os lê.

3. Memória e progresso

Dois arquivos especiais na sua área de trabalho:

• ~/workspace/.memory.md: lido no início de cada conversa. Use "lembre-se disso: X" para adicionar.
• ~/workspace/progress.md: registro de alterações. O agente anexa após mudanças significativas; você pode lê-lo para reconstruir o que aconteceu entre as sessões.

Eles são markdown de propósito: você pode fazer grep neles, versioná-los, editá-los manualmente e fazer grep neles novamente.

Por que três bancos de dados em vez de um

Dois motivos.

1. Separação de superfície. Um visitante de um site público poderia, em princípio, encontrar uma forma de consultar a função de banco de dados com a qual o site se autentica. Se essa função tiver acesso apenas ao site_db, o raio de impacto de qualquer vazamento fica limitado aos dados que você já decidiu que eram públicos.
2. Clareza de intenção. Quando o agente escreve um aplicativo do Console, ele sabe usar o console_db. Quando escreve uma página do site, site_db. Quando cria um fluxo de trabalho entre superfícies, console_site_db. Sem a dúvida acidental de "essa tabela deveria ser pública?"

O agente não tenta contornar essas regras. Se você pedir "exponha esta página do Console publicamente", ele dirá que precisa mover os dados por meio de console_site_db e reconstruir o caminho de leitura no site, em vez de acessar console_db a partir do site.

Como trabalhar com o banco de dados

O padrão, todas as vezes:

• Sessão do SQLAlchemy importada de src/db.py (módulo compartilhado por aplicativo).
• Modelos Pydantic protegem cada entrada e cada limite de API.
• psycopg2 bruto apenas quando o SQLAlchemy é excessivo (consultas somente leitura protegidas por token, scripts simples).

Você verá instruções CREATE TABLE IF NOT EXISTS no topo de novos aplicativos. O agente de IA trata o esquema como código: cada aplicativo declara suas próprias tabelas. Não há sistema de migração de plataforma; novas colunas são adicionadas com ALTER TABLE e o agente de IA registra a alteração.

E o ClickHouse

O ClickHouse está disponível localmente para cargas de trabalho de análise em que o PostgreSQL seria lento: acumulações de séries temporais em milhões de linhas, agregações colunares, esse tipo de coisa. O agente lê a habilidade do ClickHouse antes de usá-la, escolhe deliberadamente e informa o motivo. O padrão continua sendo o PostgreSQL.

Onde as coisas NÃO vivem

• Sem armazenamento de objetos gerenciado pela plataforma. Se você quiser armazenar um PDF de 50 MB ou um vídeo, salve-o como um arquivo em ~/workspace/downloads/ (controlado pelo nginx) ou como uma coluna BYTEA no Postgres (adequado para artefatos pequenos).
• Sem variáveis de ambiente para segredos. As credenciais ficam no armazenamento de segredos tipado, com escopo para superfícies e conectores. O agente nunca as copia para um arquivo ou uma coluna de banco de dados.
• Sem página de "configurações da plataforma" além do que a interface da área de trabalho expõe. Agendamentos, modos e aprovações são todos alternadores explícitos.

Ciclo de vida dos dados

• Os arquivos que você cria permanecem até você excluí-los. O agente não coleta lixo da sua área de trabalho.
• As linhas do banco de dados permanecem até você (ou um trabalho de limpeza explícito) removê-las. O agente grava trabalhos de limpeza quando você solicita: "excluir linhas de vsg_runs com mais de 90 dias todos os domingos."
• A memória e os arquivos de progresso crescem com o tempo. O agente ocasionalmente sugere a remoção quando a memória fica confusa.
• Os registros de auditoria do conector são retidos pela plataforma; você pode navegar por eles, mas não pode excluí-los.

Nos bastidores. Cada função do Postgres autentica via autenticação de pares de soquete Unix (o usuário do SO corresponde ao nome da função). Não há senha para vazar, nem string de conexão para configurar incorretamente. As concessões e revogações são explícitas e visíveis. O banco de dados system_db existe para recursos internos da plataforma (o api-proxy, o serviço de conectores, a ponte); nenhuma superfície se conecta a ele.