05 — Memória & personas

Memória que dura. Personas que mudam sem deploy.

Quatro camadas com propósito distinto. Nove personas em Markdown puro. Hot-reload em milissegundos. Memória pós-merge enriquece o agente a cada PR fechada.

Memória em camadas

Quatro propósitos. Quatro TTLs. Um único gerenciador.

Cada camada tem um propósito distinto e um backend apropriado. Nada de armazenar tudo em RAM e esquecer ao reiniciar, nada de enfiar TLS keys no SQLite. Sem segredos em nenhuma camada — toda escrita é assíncrona.

Working

em memória, TTL curto

Estado transitório do turno corrente. Variáveis derivadas, fragmentos parciais de raciocínio, contexto efêmero.

Episodic

SQLite (aiosqlite)

Histórico da sessão. Mensagens, ações, eventos. Persiste entre restarts do CLI e alimenta o contexto do próximo turno.

Semantic

SQLite

Fatos de longa duração. Decisões já tomadas, vocabulário próprio do projeto, preferências do operador.

Procedural

SQLite

Padrões aprendidos. Sequências de tools que funcionaram para tipos específicos de tarefa, heurísticas de debugging.

Catálogo de personas

Nove personas, todas em Markdown puro. Hot-reload.

Personas não são código — são instruções em Markdown com capacidades declaradas em YAML. Você ajusta comportamento sem tocar Python. Toca o arquivo, o watchdog recarrega em milissegundos, o próximo turno já reflete.

núcleo do pipeline

analyst

refina intent — entende o que o usuário realmente quer

architect

refina feature/refactor; decompõe intent em entregáveis

debugger

refina bug — pede repro, isola, propõe hipóteses

developer

executa: edita, testa, comita, empurra

reviewer

audita PR contra critérios reais — SOLID, segurança, completude

auxiliares

discord_developer

executor one-shot disparado por menção em canal Discord

monitor

supervisor 24/7 do cluster — vigias determinísticas, escala para LLM só quando há candidato

monitor_qa

responde perguntas read-only sobre estado do cluster, sem ações

fallback

persona padrão quando nenhuma específica encaixa

Memória pós-merge

Cada PR mergeada vira contexto para a próxima.

Quando o reviewer aprova e merga uma PR, um callback dedicado coleta o que aconteceu — decisões, trade-offs, follow-ups que apareceram — e injeta na memória episódica. O próximo turno do agente, em qualquer estágio, já tem esse contexto disponível.

PR mergeada
   │
   ▼  post-merge callback
collect:
   ├─ resumo do que mudou
   ├─ argumentos do review (o que foi aceito / rejeitado)
   ├─ follow-ups detectados (TODOs, débitos)
   └─ vínculo issue ↔ PR ↔ commits
   │
   ▼  inject
episodic memory  (próximo turno enriquecido)
   │
   ├─ se follow-up actionable  →  nova issue derivada
   └─ se padrão repetível      →  promoção p/ procedural memory