Percurso guiado · inspirado no caso Xavier

O que uma IA deve poder lembrar?

Antes de escolher Claude, Obsidian, Notion, pastas ou prompts, decide o que conta como memória, fonte, decisão, tarefa, procedimento e arquivo.

Este site não te pede para copiares o Xavier. Usa o Xavier como caso trabalhado para desenhares a tua própria ontologia, epistemologia e governação de dados.

Um second brain não é um sítio para guardar coisas. É um sistema para decidir que estatuto uma coisa pode ganhar.

A pergunta central não é “onde meto isto?”. É: “o que é isto agora — e o que tem direito a tornar-se?”

01 · As três perguntas fundacionais

Começa pela teoria do sistema, não pela ferramenta

Claude pode ser excelente. Mas sem estas três respostas, a qualidade das conversas não se transforma em continuidade.

Ontologia

Que tipos de coisas existem?

Fonte, conceito, projeto, decisão, tarefa, procedimento, log, memória, arquivo. Não precisas destes nomes todos, mas precisas dos teus.

Epistemologia

Como algo ganha estatuto?

Quando uma ideia deixa de ser hipótese? Quando uma resposta vira regra? Quando uma preferência merece memória global?

Governo

Onde vive e como envelhece?

Quem é dono? Como se liga a outros usos? Quando se revê? Quando se arquiva? Quando se apaga?

02 · O caso Xavier em 90 segundos

Não é um template. É um caso trabalhado.

No nosso caso, o problema era fazer o trabalho com IA compor ao longo do tempo sem transformar memória, notas e tarefas num depósito.

Paulo

  • Define direção, gosto e risco.
  • Fecha decisões estratégicas.
  • Corrige o sistema quando fica pesado.

Xavier/Hermes

  • Executa, pesquisa, escreve e verifica.
  • Encaminha inputs para o destino certo.
  • Melhora skills, runbooks e watchdogs.

Obsidian

  • Guarda estado durável em Markdown.
  • Expõe decisões, fontes, tarefas e operações.
  • Permite auditoria humana.
03 · Glossário antes do jargão

As palavras só ajudam quando resolvem um problema

Estas não são modas. São instrumentos para dar estatuto e responsabilidade às coisas.

VaultWorkspace durável em notas Markdown. Não é só arquivo: é onde o estado pode ser lido, auditado e retomado.
Johnny.Decimal / JDSistema de endereços numéricos. Exemplo: `33.12` aponta para uma nota específica. Dá localização; não substitui pensamento.
Decision RegisterRegisto de decisões com rationale, implicações, estado e opções rejeitadas. Serve para não rediscutir tudo.
Runtime memoryMemória curta do agente que influencia sessões futuras. Por isso deve ser compacta e estável.
Skill / runbookProcedimento reutilizável com passos, comandos, riscos e verificação. Não deve ficar perdido em chat.
Owner noteNota canónica que “manda” naquele objeto. Outras notas podem ligar para ela, mas não duplicar tudo.
OKF-liteMetadados mínimos para notas críticas: tipo, estado, atualização, revisão e freshness. Usado só onde data rot importa.
Master KanbanCockpit visual do trabalho vivo. Tarefas não são memória; resultados duráveis devem ser promovidos para o sítio certo.
04 · A viagem de uma entrada

O ensino está nas transições, não nos nomes

Um exemplo real: Paulo partilhou um vídeo sobre sistemas agentic. O valor não foi “guardar o vídeo”. Foi transformar o que interessava em decisões e regras.

1
Vídeo recebidoAinda não é conhecimento. É material externo.
Estatuto Fonte/proveniência. Guardar ou resumir só se tiver valor recorrente.
2
Ideias extraídasWork queue, routing, melhoria de harness, multi-agentes.
Critério Ideias ficam provisórias até mudarem uma decisão ou prática.
3
Decisão tomadaNão copiar Watson/Sherlock/Harry; aproveitar incrementalmente.
Estatuto Decisão: fecha opção e define direção.
4
Work queue implementadaA ideia virou Master Kanban com domínios e filtros.
Governança Trabalho vivo vai para cockpit, não para memória global.
5
Routing matrix formalizadaCada input passa a ter destino previsível.
Aprendizagem Uma boa ideia torna-se regra operacional quando reduz fricção futura.
6
Skill/log atualizadosA regra sobrevive à conversa e pode ser aplicada em sessões futuras.
Princípio O sistema aprende quando a melhoria entra no procedimento, não só na resposta.
05 · Decisões arquiteturais como trade-offs

O que podes adaptar para Claude

Cada decisão Xavier responde a um problema. A tua decisão pode ser diferente, mas deves responder à mesma tensão.

Memória curta

ProblemaMemória global envelhece e condiciona tudo.

XavierSó factos estáveis e preferências compactas.

Para ClaudeO que entra em Project Instructions e o que fica fora?

Workspace durável

ProblemaChat não é fonte de verdade.

XavierObsidian guarda decisões, fontes, projetos, logs e operações.

Para ClaudeOnde vive o estado que Claude consulta sem inventar?

Endereços JD

ProblemaSem endereços, contexto fica difícil de retomar.

XavierJohnny.Decimal dá IDs como `33.12` e `02.05`.

Para ClaudeComo vais apontar para regras e notas sem ambiguidade?

Owner-first

ProblemaA mesma ideia aparece em cinco sítios.

XavierUma nota tem dono; outras ligam e registam implicações locais.

Para ClaudeQual é a nota canónica antes de criares outra?

Decisões como objetos

ProblemaResumos não preservam opções fechadas.

XavierDecision Register com decisão, rationale, implicação e status.

Para ClaudeOnde ficam alternativas rejeitadas?

Procedimentos fora do chat

ProblemaResolver o mesmo problema várias vezes.

XavierSkills/runbooks guardam passos e verificação.

Para ClaudeQue rotinas viram instruções, snippets ou playbooks?

Um cockpit de tarefas

ProblemaMúltiplas boards aumentam carga cognitiva.

XavierMaster Kanban único com filtros por domínio.

Para ClaudeComo separas trabalho vivo de conhecimento durável?

Watchdogs silenciosos

ProblemaAutomação técnica pode criar ruído.

XavierAlertas só quando há ação/ponto de atenção.

Para ClaudeQue verificações ajudam sem virar ansiedade?

06 · Laboratório de estatuto

Treina a pergunta: “o que isto ganhou o direito de ser?”

Antes de guardar, decide o estatuto. A mesma frase pode seguir caminhos diferentes.

Exemplo

“Este artigo pode ser útil para mim mais tarde.”

Esta frase ainda não decide nada. O sistema tem de perguntar: útil como quê?

FonteGuardar URL/proveniência porque pode ser relido ou citado.
ConceitoExtrair uma ideia reutilizável que serve vários contextos.
Evidência de projetoLigar a PhD, ensino, Voice Lab ou escrita pública com uma implicação local.
TarefaCriar próxima ação: ler, resumir, comparar, citar, enviar.
DecisãoSe fecha uma opção: “vamos usar isto como referência X”.
IgnorarSe é interessante mas sem função clara. Nem tudo merece entrar.
07 · A saída concreta

Escreve a constituição do teu second brain

Não é metodologia ainda. É o documento mínimo que governa a metodologia que escolheres depois.

# Constituição do meu Second Brain

## 1. Propósito
Este sistema existe para: [escrever o trabalho que deve compor ao longo do tempo]

## 2. Tipos de objetos
No meu sistema existem: fontes, conceitos, decisões, tarefas, procedimentos, logs, memória, arquivo.
Risco principal: [o que tende a virar depósito no meu caso]

## 3. Regras de estatuto
Uma ideia vira decisão quando: [critério]
Uma intenção vira tarefa quando: [critério]
Uma resposta vira procedimento quando: [critério]
Uma preferência vira memória quando: [critério]

## 4. Regras de memória do agente
Claude deve lembrar sempre: [preferências/factos estáveis]
Claude nunca deve guardar como memória: [sensível, transitório, project log, etc.]

## 5. Regras de fontes
Uma fonte vive em: [local canónico]
Uma fonte só é promovida quando: [critério de valor recorrente]

## 6. Regras de decisões
Uma decisão deve conter: escolha, rationale, implicação, estado, alternativas rejeitadas.

## 7. Regras de tarefas
Uma tarefa precisa de próxima ação, dono/contexto e estado.

## 8. Regras de procedimentos
Procedimentos repetíveis vivem em: [runbook, prompt, snippet, script ou Project Instructions]

## 9. Revisão, arquivo e esquecimento
Uma nota fica stale quando: [critério]
Uma tarefa concluída desaparece quando: [critério]
Uma ideia é apagada quando: [critério]

## 10. Ferramentas
Só agora escolho: Claude, Obsidian, Notion, Markdown, Git, pastas, templates, automações.
08 · Plano de arranque em 7 dias

Pequeno o suficiente para começar

A metodologia vem depois. Primeiro põe o sistema a distinguir estatutos.

Dia 1Define o propósito e os 5 objetos mínimos.
Dia 2Define o que Claude deve e não deve lembrar.
Dia 3Cria o primeiro decision register.
Dia 4Define regra de fontes e proveniência.
Dia 5Cria um cockpit simples de tarefas vivas.
Dia 6Transforma 2 procedimentos em runbooks.
Dia 7Faz uma revisão anti-bloat: o que entrou sem merecer?

O objetivo não é copiar o Xavier.

O objetivo é seres capaz de dizer, antes de abrir o Claude: que tipos de coisas existem no meu sistema, como ganham estatuto, onde vivem, e quando devem desaparecer.