Arquitetura
Duas conexões SQLite, ambas somente leitura. Mapa de processos, fronteiras de dados e as duas rotas deliberadas que leem a fonte.
Um scanner escreve o cache. Um servidor lê. O banco de origem nunca fica em estado gravável em nenhum ponto da árvore de processos.
Fonte canônica ↗Processos
| Processo | Entrada | Papel |
|---|---|---|
| Scanner | bun src/scan.ts | Lê a fonte em RO; escreve e reconcilia o cache |
| API | bun run serve | Serve JSON do cache, mais duas rotas que leem a fonte |
| UI | bun run web | Dashboard; faz proxy de /api em desenvolvimento |
Fronteiras de dados
| Armazenamento | Env | Escritor | Leitor |
|---|---|---|---|
| Sessões do OpenCode | OPENCODE_DB | Só o OpenCode | scan + transcrição/ao vivo |
| Métricas derivadas | OPENCODEVIEW_CACHE | Só o scan.ts | API (somente leitura) |
Por que duas rotas ainda tocam a fonte
A maioria dos endpoints lê o cache e nada mais. Duas são exceções deliberadas, porque materializá-las significaria duplicar texto bruto de mensagens em um segundo arquivo — uma troca pior em privacidade do que ler ao vivo.
GET /api/session/:id/transcriptTexto de mensagens e partes propositalmente não é materializado por completo no cache.
GET /api/liveEstado de sessão em andamento só existe na fonte no momento da requisição.
✓ Ambas permanecem somente leitura e redigidas.
Mapa do código
| Caminho | Responsabilidade |
|---|---|
| src/scan.ts | Consolidação de projetos e sessões, sinalizações, métricas de ferramentas, schema do cache |
| src/server.ts | Rotas Hono, guardas de bind e autenticação, conexões query_only |
| src/server-config.ts | Regras de falha fechada para host, porta e token |
| src/redaction.ts | Limpeza de segredos e caminhos nos payloads de saída |
| src/stats.ts | Auxiliares numéricos compartilhados — EWMA, detecção de changepoint |
| web/src/App.tsx | Shell, locale, limites de views lazy |
| web/src/lib/api/ | Clientes tipados para cada rota /api/* |
| web/src/i18n/ | Catálogos de mensagens EN-US e PT-BR |