BrisaVerse — Roadmap de Produto

Versão 1.0 — Gerado em 2026-06-20 PM/Tech Lead: Claude Sonnet 4.6

1. Visão e Princípios

Declaração de produto

O BrisaVerse é uma segunda mente pessoal com IA — um sistema local-first que roda no servidor do próprio usuário, agrega o contexto real da sua vida (tarefas, notas, projetos, reflexões, eventos, decisões), e oferece uma IA que realmente conhece esse contexto. Ao contrário de ferramentas de PKM que exigem manutenção constante, o BrisaVerse captura com mínimo atrito (chat, voz, Telegram), organiza automaticamente com IA, e apresenta o resultado como um mapa vivo da vida do usuário — não como uma lista de documentos. Os dados são do usuário, ficam no servidor do usuário, e a IA serve o usuário em vez de extrair seus dados para enriquecer um produto de terceiros.

Princípios de design

Captura zero-fricção, organização automática — o usuário nunca deve precisar decidir onde guardar algo na hora em que está com o pensamento em foco. Manda o texto, a voz, a foto. A IA classifica depois.
Local-first é inegociável — dados não saem do VPS do usuário. Integrações com terceiros (Claude API, Google) são read-only ou têm opt-in explícito. Este é o maior diferenciador contra todo concorrente do mercado.
IA como lente, não como destino — a IA não é o produto final. É a camada que transforma dados brutos em entendimento: conecta nós, detecta padrões, sugere, mas não substitui o julgamento do usuário. O usuário sempre vê os dados brutos além das inferências.
Interface que convida, não que exige — o mural deve ser algo que o usuário quer abrir, não um painel de controle que gera culpa. Designs que criam pressão (% de tarefas, streaks) devem ser opcionais. O padrão é calmo.
Evolução sem quebra — o sistema já existe e está em uso diário. Cada feature nova precisa ser aditiva: não pode exigir migração, não pode mudar como o todo.md é editado, não pode tornar o mural mais lento. Backward compatibility é o custo de ter um sistema que já roda.

2. Estado Atual vs. Visão

Feature	Existe?	Gap	Prioridade
Mural visual com mapa de nós	✅ Sim	UI melhorável (plano mural-v2)	Baixa (funcional)
Tasks por domínio de vida	✅ Sim (todo.md + parser)	Sem subitens visíveis no mural	Média
Flows (projetos com etapas)	✅ Sim	Sem timeline visual por flow	Alta
Bot Brisa no Telegram	✅ Sim	Sem captura de voz nativa	Alta
ContextStore (SQLite)	✅ Sim	Schema simples, sem embeddings	Alta
Notas/ideias/gratidão	✅ Sim (log_event)	Sem UI de busca + sem conexões semânticas	Alta
Lores (histórico de concluídas)	✅ Sim	Sem visualização de linha do tempo	Média
MCP server	✅ Sim	Expõe contexto mas sem vector search	Média
Hoje (glance diário + TAPs)	✅ Sim	Gerado externamente, não integrado ao mural	Média
/notas page (feed)	✅ Sim	Feed linear, sem filtros, sem busca	Alta
Chat com contexto no app	❌ Não	Existe só via Telegram/MCP	Crítica
Timeline de vida	❌ Não	Nenhum componente temporal/cronológico	Alta
Nexus/grafo semântico	❌ Não	Links são manuais ou inexistentes	Alta
Captura por voz	❌ Não	Só texto hoje	Alta
Busca semântica	❌ Não	Sem embeddings no ContextStore	Alta
Multi-canal além do Telegram	❌ Não	WhatsApp, email como entrada	Baixa
Notificações proativas	⚠️ Parcial	Briefings diários existem, sem contexto de vida	Média
Multi-usuário	❌ Não	Single-tenant hoje	Muito baixa

3. Fases do Roadmap

Fase 0 — Fundação Sólida (Pré-condição)

Objetivo: Garantir que a base técnica aguenta o que vem a seguir, sem dívida técnica acumulada que bloqueie as próximas fases.

Duração estimada: 1-2 semanas

Critério de sucesso: ContextStore tem suporte a embeddings, mural carrega em < 500ms, suite de testes cobre os módulos core.

Features a construir

F0.1 — Migração do ContextStore para suporte a embeddings - Descrição: Adicionar coluna embedding (BLOB) e tabela notes dedicada (separada de events) no SQLite. Instalar sqlite-vec ou usar faiss local para busca por similaridade. Sem isso, a Fase 2 (nexus semântico) não existe. - Arquivos: brisa/context/store.py, nova migration store_v2.py - Esforço: M - Dependências: Nenhuma - Risco técnico: sqlite-vec é relativamente novo; alternativa é tabela de embeddings em arquivo separado (.npy ou faiss.index). Não usar PostgreSQL — quebra o local-first.

F0.2 — Modelo de embedding local ou via API - Descrição: Escolher e integrar um modelo de embedding. Opção A: sentence-transformers rodando local (custo zero, 500MB RAM extra). Opção B: text-embedding-3-small da OpenAI (já tem client no bot). Recomendação: Opção B no curto prazo (já existe infra de API), planejar Opção A para versão "totalmente offline". - Arquivos: brisa/context/embeddings.py (novo), brisa/context/store.py - Esforço: P - Dependências: F0.1

F0.3 — Extrair CSS e estabilizar templates - Descrição: Implementar o plano de mural-v2 já documentado em mural-v2-plano.md (quick wins: CSS em arquivo separado com variáveis, <details> para colapso, timestamp no topo). Isso não é cosmético — é pré-condição para adicionar componentes de chat e timeline sem virar espaguete. - Arquivos: brisa/mural/templates/index.html, novo static/mural.css - Esforço: P - Dependências: Nenhuma

F0.4 — Testes de integração para server.py - Descrição: tests/test_mural_server.py existe mas cobertura dos endpoints de flow e notas é baixa. Adicionar testes para os endpoints críticos antes de modificar o servidor. - Arquivos: tests/test_mural_server.py - Esforço: P - Dependências: Nenhuma

Desafios técnicos: - sqlite-vec pode não ter binários prontos para ARM se o VPS usa essa arquitetura. Verificar antes de comprometer. - Migração do schema SQLite precisa ser feita sem perder dados de context.db existente.

Desafios de produto: - Fase 0 não entrega nada visível. É fácil pular e pagar o preço depois. Não pular.

Fase 1 — Chat com Contexto Real (MVP Diferenciador)

Objetivo: Ter um chat dentro do mural web onde a Brisa responde usando o contexto real armazenado — notas, tasks, flows, eventos — com busca semântica. Este é o diferenciador central: nenhum concorrente faz isso com dados locais.

Duração estimada: 2-3 semanas

Critério de sucesso: Usuário consegue perguntar "o que eu estava pensando sobre X?" e a Brisa encontra a nota relevante mesmo sem a palavra exata. Respostas incluem citações dos contextos usados.

Features a construir

F1.1 — Endpoint de chat no server.py - Descrição: Novo endpoint POST /api/chat que recebe mensagem do usuário, busca contexto relevante via embeddings (F0.1/F0.2), monta prompt com contexto injetado e chama a API do Claude. Retorna resposta + lista de fontes usadas (para citação). - Arquivos: brisa/mural/server.py, novo brisa/mural/chat.py, novo brisa/context/retriever.py - Esforço: M - Dependências: F0.1, F0.2

F1.2 — Componente de chat no mural - Descrição: Painel lateral ou tela dedicada /chat com interface de chat (input + histórico da sessão). JS vanilla, sem framework. Estilo consistente com o mural. Suporte a Markdown na resposta (já existe no bot, replicar lógica). - Arquivos: brisa/mural/templates/chat.html (novo), static/chat.js (novo), brisa/mural/server.py - Esforço: M - Dependências: F1.1, F0.3

F1.3 — Histórico de sessões de chat - Descrição: Persistir conversas de chat no ContextStore (tabela chat_sessions). Não precisa ser infinito — últimas 30 sessões. Permite o usuário voltar a uma conversa e permite que a Brisa referencie conversas anteriores. - Arquivos: brisa/context/store.py, brisa/mural/chat.py - Esforço: P - Dependências: F1.1

F1.4 — Indexação automática de novas notas - Descrição: Quando uma nota/evento é adicionado ao ContextStore (via bot Telegram ou via mural), gerar embedding automaticamente e armazenar. Sem indexação em tempo real, a busca semântica fica desatualizada. - Arquivos: brisa/context/store.py (hook em log_event), brisa/context/embeddings.py - Esforço: P - Dependências: F0.1, F0.2

F1.5 — Re-indexação do histórico existente - Descrição: Script one-shot para gerar embeddings de todos os eventos já existentes no context.db. Isso garante que o chat já funciona bem no dia 1 com dados históricos. - Arquivos: scripts/reindex_embeddings.py (novo) - Esforço: P - Dependências: F0.1, F0.2

Desafios técnicos: - Janela de contexto vs. relevância: Não dá para jogar tudo no prompt. O retriever precisa selecionar bem os N chunks mais relevantes. Começar com top-10 por similaridade + re-ranking por data recente. - Latência: Chamada de embedding + busca + chamada de LLM pode somar 3-5 segundos. Usar streaming SSE para o chat não parecer travado. - Custo de API: Se o usuário chatear muito, o custo de embeddings e de chamadas Claude sobe. Monitorar. Usar cache de embedding (nunca re-embedar o mesmo texto).

Desafios de produto: - O chat vai ser bom na medida em que as notas forem ricas. Se o ContextStore tem poucos dados, as respostas vão parecer genéricas. O usuário pode se decepcionar antes de ter dados suficientes para o sistema brilhar. Mitigação: mostrar claramente "baseado em X notas" nas respostas. - Risco de o usuário substituir o Telegram pelo chat do mural e o bot ficar ocioso. Isso não é necessariamente ruim, mas é uma mudança de comportamento a monitorar.

Fase 2 — Captura Multi-Canal e Frictionless

Objetivo: Remover as últimas barreiras de captura. Voz no Telegram, captura rápida no mural, processamento automático de "dumps" de texto.

Duração estimada: 2 semanas

Critério de sucesso: Usuário consegue mandar um áudio de 1 minuto no Telegram com 5 coisas misturadas (tarefa, ideia, reflexão, evento, compra) e a Brisa classifica tudo corretamente, sem intervenção manual.

Features a construir

F2.1 — Transcrição de áudio no bot Telegram - Descrição: Quando o usuário manda um áudio/voice note no Telegram, o bot chama Whisper API (OpenAI) para transcrever, depois passa o texto transcrito pelo pipeline de classificação existente (o mesmo que processa mensagens de texto). Retorna confirmação com o que foi capturado. - Arquivos: brisa/bot/handler.py, novo brisa/integrations/whisper.py - Esforço: P - Dependências: Nenhuma (Whisper API já tem client via openai)

F2.2 — Classificação automática de dumps - Descrição: Formalizar o pipeline já documentado no WORKFLOW.md (mensagem "bagunça" → tarefa/ideia/reflexão/evento). Criar função classify_and_dispatch(text) -> list[CapturedItem] testável e reutilizável, que pode ser chamada pelo bot E pelo chat do mural. - Arquivos: novo brisa/context/classifier.py, brisa/bot/handler.py - Esforço: M - Dependências: Nenhuma (o comportamento já existe, é formalização)

F2.3 — Quick capture no mural - Descrição: Input flutuante no mural (botão "+" ou atalho de teclado) que abre um modal simples para digitar uma nota rápida. Sem categorização manual — a IA classifica. Funciona offline (salva local, sincroniza quando há rede). Alternativa ao Telegram para quem está na tela do computador. - Arquivos: brisa/mural/templates/index.html, static/mural.js, brisa/mural/server.py (endpoint POST /api/capture) - Esforço: M - Dependências: F2.2

F2.4 — Feedback de captura no Telegram - Descrição: Após classificar uma mensagem, o bot responde com um resumo estruturado do que foi capturado e onde foi guardado. Hoje a resposta é genérica. Com F2.2, pode ser precisa: "Adicionei 2 tasks em Projetos, 1 ideia e salvei 1 reflexão." - Arquivos: brisa/bot/handler.py - Esforço: P - Dependências: F2.2

Desafios técnicos: - Whisper tem custo por minuto de áudio. Para uso pessoal é negligenciável (< $0.01/minuto), mas é uma dependência nova. - Alternativa gratuita: faster-whisper rodando local (modelo small = ~500MB, ~2x tempo real em CPU). Vale como plano B se o custo de API incomodar.

Desafios de produto: - Classificação errada é pior que nenhuma classificação. O usuário precisa de um mecanismo fácil de correção ("isso não era uma task, era uma ideia"). Implementar botão de correção inline no Telegram (inline keyboard com opções de re-classificação). - Voz pode capturar coisas que o usuário não queria registrar (contexto, ruído, fala pra outra pessoa). Avisar que áudios são transcritos antes de ativar a feature.

Fase 3 — Timeline de Vida

Objetivo: Dar ao usuário uma visualização cronológica de sua vida: eventos, decisões, conclusões, reflexões — tudo em uma linha do tempo navegável. Este é o componente de "retenção" que diferencia de um simples app de notas.

Duração estimada: 3-4 semanas

Critério de sucesso: Usuário consegue navegar mês a mês e ver o que aconteceu, o que decidiu, o que concluiu. Sente que o sistema "lembra" de sua vida.

Features a construir

F3.1 — Schema de eventos enriquecido - Descrição: A tabela events atual tem source, kind, payload, created_at. Para timeline, precisa de: event_date (data do evento, diferente da data de criação), title (resumo para exibição), importance (0-3, para filtrar o que aparece na timeline), tags (JSON array). Adicionar via migration sem quebrar dados existentes. - Arquivos: brisa/context/store.py, scripts/migrate_events_v2.py (novo) - Esforço: P - Dependências: F0.1

F3.2 — Endpoint de timeline - Descrição: GET /api/timeline?from=YYYY-MM&to=YYYY-MM retorna eventos do período, agrupados por semana. Inclui: notas, conclusões de tasks (do Lores), conclusões de flows, eventos do Google Calendar (se integrado), reflexões. - Arquivos: brisa/mural/server.py, novo brisa/mural/timeline.py - Esforço: M - Dependências: F3.1

F3.3 — Página /timeline no mural - Descrição: Visualização tipo "scroll vertical" com meses como âncoras. Cada evento tem ícone por tipo (task concluída, nota, reflexão, evento), data e título. Clique expande o detalhe. Navegação por mês via sidebar ou botões prev/next. JS vanilla, sem biblioteca de timeline. - Arquivos: brisa/mural/templates/timeline.html (novo), static/timeline.js (novo), brisa/mural/server.py - Esforço: G - Dependências: F3.2

F3.4 — Auto-categorização de importância - Descrição: Quando um evento é registrado, a IA avalia importância (0=ruído, 1=cotidiano, 2=relevante, 3=marco). A timeline por padrão mostra importância >= 2. Isso evita que a timeline fique poluída com microtasks. O usuário pode editar a importância manualmente. - Arquivos: brisa/context/classifier.py, brisa/context/store.py - Esforço: M - Dependências: F2.2, F3.1

F3.5 — "Este dia, um ano atrás" - Descrição: Widget no mural (ou mensagem proativa no Telegram) que mostra eventos marcantes de datas equivalentes em anos anteriores. Só faz sentido após 6-12 meses de dados, mas a lógica pode ser implementada antes. - Arquivos: brisa/mural/templates/index.html, brisa/mural/server.py - Esforço: P - Dependências: F3.2

Desafios técnicos: - Performance: timeline com muitos eventos precisa de paginação. Implementar paginação por mês desde o início (não carregar tudo de uma vez). - "Lores" (tarefas concluídas históricas) não têm data de conclusão armazenada estruturadamente hoje — só data no cabeçalho da seção do todo.md. Precisar parsear o todo.md retroativamente para extrair datas de conclusão.

Desafios de produto: - Uma timeline vazia é deprimante. Nos primeiros 2 meses, o usuário vai ter pouco dado. Mostrar uma "timeline de arranque" que inclui as tasks concluídas históricas do todo.md para que não pareça vazio desde o início. - Privacidade emocional: a timeline vai ter reflexões pessoais. Garantir que não há compartilhamento acidental e que o login está sempre ativo.

Fase 4 — Nexus Semântico (Grafo de Contexto)

Objetivo: Construir o componente mais diferenciador do produto: conexões entre contextos inferidas por IA, não links manuais. O usuário escreve sobre "ansiedade com mudança de casa" e o sistema conecta automaticamente com a nota sobre "organizar casa" e o flow "Mudança Julho".

Duração estimada: 4-5 semanas

Critério de sucesso: Ao abrir o nexus de qualquer nota, o usuário vê pelo menos 3 conexões relevantes que ele não teria feito manualmente. Taxa de "essa conexão faz sentido" > 70% nas primeiras interações.

Features a construir

F4.1 — Engine de conexões semânticas - Descrição: Job periódico (ou trigger em nova nota) que calcula similaridade de embedding entre itens do ContextStore. Armazena conexões acima de threshold (ex: cosine > 0.75) em tabela connections(source_id, target_id, score, created_at). Não mostrar todas as conexões — só as top-K mais fortes. - Arquivos: novo brisa/context/nexus.py, brisa/context/store.py - Esforço: M - Dependências: F0.1, F0.2, F1.4 (embeddings dos itens)

F4.2 — Conexões cross-type - Descrição: O nexus não deve conectar só nota-nota. Deve conectar: nota ↔ task, task ↔ flow, reflexão ↔ evento, etc. Implementar score ponderado que leva em conta tipo (uma conexão nota↔flow vale mais do que nota↔nota trivialmente parecida). - Arquivos: brisa/context/nexus.py - Esforço: M - Dependências: F4.1

F4.3 — Página /nexus e visualização de grafo - Descrição: Visualização de grafo interativo. Opção A: D3.js force-directed (poderoso, 80KB gzip). Opção B: biblioteca mais leve como vis-network. Recomendação: D3.js — é o padrão, bem documentado, sem dependência de serviço externo. Nós com ícone por tipo, arestas com espessura proporcional ao score de similaridade. Click num nó abre o detalhe. - Arquivos: brisa/mural/templates/nexus.html (novo), static/nexus.js (novo), brisa/mural/server.py - Esforço: G - Dependências: F4.1, F4.2

F4.4 — "Por que estão conectados?" - Descrição: Quando o usuário clica em uma conexão no grafo, a IA explica em 1-2 frases por que aqueles dois itens estão relacionados. Isso transforma uma abstração matemática (score de similaridade) em insight humano. - Arquivos: brisa/mural/server.py (endpoint /api/nexus/explain), static/nexus.js - Esforço: P - Dependências: F4.3, F1.1 (infra de chamada Claude)

F4.5 — Nexus por nó do mural - Descrição: Cada nó do mural (Saúde, Projetos, Casa, etc.) ganha um mini-nexus: ao abrir o painel inline, mostra as top-5 conexões com outros domínios. Ex: nó "Casa" conectado com "Planejamento de vida" via nota sobre mudança de julho. - Arquivos: brisa/mural/templates/index.html, brisa/mural/server.py - Esforço: M - Dependências: F4.1, F4.2

Desafios técnicos: - Grafo com muitos nós (> 500 itens) fica ilegível. Implementar filtros obrigatórios: por período, por tipo, por domínio. Nunca mostrar o grafo completo sem filtro. - Threshold de similaridade é crítico: muito baixo = grafo com lixo; muito alto = grafo vazio. Começar com 0.75, expor como configuração para ajuste. - Custo de CPU: calcular todos os pares de N itens é O(N²). Com 1000 notas, são 500K cálculos. Usar índice HNSW (via faiss ou sqlite-vec) para aproximação.

Desafios de produto: - Este é o "momento uau" — mas também o que mais pode decepcionar se as conexões forem ruins. Não lançar sem validação prévia: gerar 20-30 conexões manualmente e pedir ao usuário para avaliar antes de abrir a feature. - O grafo pode virar um brinquedo bonito que ninguém usa de verdade. A ancoragem deve ser nos casos de uso reais: "encontrar uma nota que sei que escrevi mas não lembro onde", "ver o que está conectado com esse projeto", não "explorar o grafo por explorar".

4. Decisões Arquiteturais Críticas

4.1 — Embedding local vs. API (decisão urgente)

Trade-off: text-embedding-3-small (OpenAI) é conveniente (já tem client), mas cria dependência de API para uma feature core. sentence-transformers local é zero-custo e offline, mas exige 500MB+ de RAM e download de modelo.

Recomendação: Iniciar com API OpenAI para velocidade de desenvolvimento. Abstrair o provider em brisa/context/embeddings.py com interface embed(text) -> list[float]. Quando o produto estiver estável, trocar para local sem mudar o restante do código.

Impacto de errar: Se não abstrair agora, trocar depois exige mudança em 10+ lugares. Abstrair é 2 horas de trabalho que economiza dias.

4.2 — SQLite vs. outro banco para escala

Trade-off: SQLite é perfeito para single-user local-first. Mas com embeddings (vetores de 1536 dimensões), a busca por similaridade em SQLite puro é O(N) — varrimento completo. Com 10K notas, isso é lento.

Recomendação: Usar sqlite-vec extension para busca vetorial ANN. Se não funcionar no ambiente do VPS, usar arquivo faiss.index separado ao lado do context.db. Não migrar para PostgreSQL ou outro banco — quebra o princípio local-first e adiciona complexidade operacional que não faz sentido para single-user.

Impacto de errar: Busca lenta no chat = produto que parece ruim. Indexar desde o início.

4.3 — Onde fica o chat: mural web vs. Telegram vs. ambos

Trade-off: O bot Telegram já tem chat com contexto (via MCP + ferramentas). Construir chat no mural web é duplicar esforço? Não — são canais diferentes. Telegram = captura rápida, mobile, assíncrono. Mural = sessão longa, desktop, referência.

Recomendação: Ambos, mas o backend de retrieval é compartilhado (brisa/context/retriever.py). O bot chama via Python direto. O mural chama via endpoint HTTP. Sem duplicar lógica de busca.

Impacto de errar: Se tentar eliminar o Telegram em favor do mural, perde o canal de captura mais natural. Se ignorar o chat no mural, perde o caso de uso de sessão longa/reflexão.

4.4 — Todo.md como fonte de verdade vs. banco de dados

Trade-off: O todo.md é um arquivo texto editável manualmente, compartilhado entre Claude e Brisa, com formato regex-based. É frágil para features avançadas (subtasks complexas, metadados ricos, histórico de edições). Mas é o que existe, funciona, e o usuário edita diretamente.

Recomendação: Não migrar. O todo.md continua sendo a fonte de verdade para tasks. O que precisa de metadados ricos (ex: data de conclusão para timeline) deve ser capturado como evento no ContextStore no momento da conclusão, não como campo novo no todo.md. Isso preserva o formato sem adicionar fragilidade.

Impacto de errar: Quebrar o parser do todo.md invalida o mural inteiro. Tocar no formato do arquivo só com PRs revisados e suite de testes verde.

4.5 — Autenticação: token único vs. sistema de usuários

Hoje: Login por token único em cookie de sessão (90 dias). Simples, funciona para single-user.

Impacto futuro: Se o produto crescer para multi-usuário (Fase 5+), vai ser necessário reescrever auth do zero. A boa notícia é que a abstração is_authed() em server.py já isola a lógica — trocar a implementação não muda as rotas.

Recomendação: Não investir em auth sofisticado agora. Documentar o ponto de extensão. Só atacar quando houver um segundo usuário real.

5. Próximos 3 Passos Imediatos (próximas 48h)

Passo 1 — Validar viabilidade do sqlite-vec no VPS (2h)

# Verificar arquitetura e testar instalação
uname -m  # se x86_64, sqlite-vec tem binários prontos
pip install sqlite-vec
python -c "import sqlite_vec; print('ok')"

Se falhar, testar faiss-cpu como alternativa. Esta decisão desbloqueia toda a Fase 0 e é o maior risco técnico não validado.

Passo 2 — Implementar F0.1 (migração do schema) e F0.2 (embeddings) (4-6h)

Criar brisa/context/embeddings.py com provider abstracto e implementação via OpenAI. Adicionar tabela notes e coluna embedding no ContextStore. Escrever teste unitário que insere uma nota, gera embedding e recupera por similaridade. Se isso funcionar, a Fase 1 está desbloqueada.

Passo 3 — Criar /api/chat e testar via curl (2-3h)

Com F0.1 e F0.2 prontos, implementar o endpoint de chat mínimo: recebe texto, busca top-3 notas por similaridade, monta prompt, chama Claude API, retorna resposta JSON. Sem UI ainda — só o endpoint. Testar com curl usando perguntas sobre notas reais do ContextStore. Se a qualidade das respostas for boa, a Fase 1 tem MVP técnico validado.

Por que essa ordem: Valida o risco técnico mais alto (embeddings locais) antes de investir semanas de trabalho. Se falhar, o plano se ajusta antes de comprometer esforço de UI.

6. Métricas de Sucesso

O produto é para uso pessoal intensivo — as métricas tradicionais de produto (DAU, MAU, churn) não se aplicam. As métricas relevantes são de qualidade de uso e redução de fricção.

Métricas de captura

Notas por semana — baseline atual vs. após Fase 2. Meta: crescimento de 2x após captura por voz.
Tempo entre pensar e registrar — proxy: quantas notas são capturadas em contexto mobile (Telegram) vs. desktop (mural). Proxy de fricção.

Métricas de recuperação

Taxa de "encontrei o que procurava" — implementar botão de feedback (👍/👎) no chat do mural. Meta: > 80% de respostas úteis.
Buscas sem resultado — quantas vezes o chat retorna "não encontrei contexto relevante". Meta: < 20% das consultas.

Métricas de engajamento com memória

Abertura da timeline por semana — se o usuário nunca abre, a feature não está entregando valor.
Conexões no nexus exploradas por sessão — se fica em 0, o nexus é decorativo. Meta: > 3 por sessão nas primeiras 4 semanas pós-lançamento da fase.

Métricas de saúde técnica

Latência do chat — P95 < 3 segundos (incluindo embedding + busca + LLM).
Uptime do mural — meta: 99.5% (o usuário precisa poder confiar que está disponível).
Tamanho do context.db — monitorar crescimento mensal. Com embeddings, pode crescer rápido.

A métrica qualitativa que mais importa

Uma vez por mês: o usuário consegue responder "o que eu estava pensando sobre X há 3 meses?" com o BrisaVerse em menos de 30 segundos? Se sim, o produto está funcionando como segunda mente.

Apêndice — Riscos e Mitigações

Risco	Probabilidade	Impacto	Mitigação
sqlite-vec não funciona no VPS	Média	Alto	Usar faiss-cpu como fallback; validar no Passo 1
Qualidade de busca semântica decepcionante	Média	Alto	Testar com 20+ queries antes de lançar; ajustar threshold
Custo de API (embeddings + Claude) sobe	Baixa	Médio	Cache de embeddings; monitorar custo semanal desde Fase 1
Classificação automática errada demais	Média	Médio	Implementar mecanismo de correção antes de lançar Fase 2
Mural fica lento com novos componentes	Baixa	Alto	Benchmark de carga antes de cada fase; lazy loading de grafo
TODO.md parser quebra com mudanças	Baixa	Crítico	Suite de testes; nunca mudar formato sem PR revisado
Escopo creep (querer fazer tudo de uma vez)	Alta	Alto	Cada fase tem critério de sucesso claro; só avançar quando aprovado
Dados pessoais sensíveis no nexus	Baixa	Alto	Garantir que acesso ao mural exige auth; nunca logar conteúdo de notas