Uma coisa, um dono canónico
Cada objeto durável tem uma nota/local que manda nele. Outros contextos ligam para o dono e registam apenas a implicação local.
01 · Princípios operacionais
As regras que impedem o sistema de virar depósito
Antes de implementar qualquer ferramenta, fixa estes princípios. São técnicos porque governam comportamento, não porque dependem de software.
Memória global é exceção
O que entra na memória do agente influencia conversas futuras. Só entra se for estável, compacto e reduzir repetição.
Decisão não é resumo
Resumo conta o que foi dito. Decisão conta o que mudou: escolha, rationale, implicação, estado e alternativas rejeitadas.
Tarefa não é conhecimento
Task cockpit mostra trabalho vivo. Quando há resultado durável, promove-se para decisão, fonte, output, nota de projeto ou runbook.
Procedimento vive fora do chat
Se um processo se repete, vira runbook, prompt operacional, script, snippet ou instrução de projeto.
O sistema deve saber esquecer
Nem tudo é capturado. Ideias sem função clara podem ficar fora, estacionadas ou arquivadas.
02 · Arquitetura mínima
Uma estrutura de referência
Esta estrutura é inspirada no Xavier, mas pode ser implementada com Obsidian, pastas Markdown, Notion ou outro sistema.
Camadas recomendadas
00 System # constituição, schema, templates, logs 10 Dashboard # home, cockpit, decisões abertas, visão atual 20 Inbox # capturas temporárias e material por processar 30 Projects # projetos, dashboards, decisões, outputs, tarefas situadas 40 Knowledge # conceitos, sínteses e frameworks reutilizáveis 50 Operations # runbooks, automações, backups, integrações, agentes 60 Sources # fontes/proveniência: artigos, vídeos, documentos, transcrições 70 Assets # imagens, PDFs, anexos e media de suporte 90 Archive # material antigo, superseded ou fechado
Se não quiser Johnny.Decimal
- System
- Dashboard
- Inbox
- Projects
- Knowledge
- Operations
- Sources
- Archive
Johnny.Decimal como endereço
Usa JD se quiseres referir notas rapidamente em conversa: “volta à 33.12”, “a regra está na 02.05”. JD é endereço e governo de propriedade, não taxonomia total.
Regra importante: folders dizem quem é dono. Links dizem onde é útil. Metadados dizem se ainda está fiável.
03 · Routing matrix
O que acontece quando entra material novo?
Esta é a peça mais prática. A pessoa fala normalmente; o sistema decide o destino com base no estatuto.
Entrada
Destino padrão
Regra
Pergunta simples
Resposta direta
Não capturar salvo se fechar uma decisão.
Fonte externa
Sources / Source Box
Guardar proveniência, autor, URL/data e utilidade. Não confundir com conclusão.
Ideia reutilizável
Knowledge / Concepts
Promover só se servir vários usos futuros.
Decisão fechada
Decision Register
Registar decisão, rationale, implicação, estado e opções rejeitadas.
Tarefa com próxima ação
Task cockpit / projeto
Precisa de ação, estado, contexto e dono/owner se aplicável.
Procedimento repetível
Operations / runbook
Guardar passos, pitfalls e verificação.
Evento operacional
Vault/System Log
Registar só se muda estado ou é útil para auditoria.
Preferência estável
Memória do agente
Compacta, durável, sem segredos, útil para futuras conversas.
Ambíguo/sensível
Opções numeradas
Propor destinos e esperar decisão.
04 · Templates mínimos
Começa com poucos formatos
Templates demais criam burocracia. Estes quatro chegam para começar.
Decision Register entry
### YYYY-MM-DD — Título da decisão - Decision: - Rationale: - Implication: - Status: active | proposed | superseded | deferred - Options rejected: - Alternative A — rejected because [reason] - Source: - Related:
Source note
--- type: source status: active captured: YYYY-MM-DD source_url: --- # Título ## Proveniência - Autor: - URL: - Data: ## Porque pode interessar ## Conteúdo / excerto ## Possíveis usos - Projeto: - Conceito: - Tarefa:
Project dashboard
# Projeto ## Estado atual ## Decisões-chave ## Próximas ações ## Fontes / evidência ## Outputs ## Questões abertas ## Links canónicos
Runbook
# Runbook: Nome ## Quando usar ## Pré-requisitos ## Passos 1. 2. 3. ## Pitfalls ## Verificação ## Rollback / alternativa
05 · Memória do Claude/agente
O que deve influenciar todas as conversas?
Trata a memória global como uma superfície de alto impacto. Ela deve ser curta, declarativa e curada.
Entram bem
- preferências estáveis de comunicação;
- papéis/projetos duráveis;
- regras de routing realmente recorrentes;
- factos de ambiente que poupam steering;
- correções que não queres repetir.
Não entram
- task progress;
- logs de trabalho concluído;
- números de PR/commits/issues;
- fontes longas;
- procedimentos;
- segredos, tokens, passwords, dados sensíveis.
Teste de admissão
Guardar isto em memória global? 1. Ainda será verdade em 7 dias? 2. Reduz steering futuro? 3. É estável e compacto? 4. Não pertence melhor a uma nota, decisão ou runbook? 5. Está livre de segredos/dados sensíveis?
06 · Task cockpit
Trabalho vivo precisa de estado, não de arquivo eterno
Podes usar Kanban, Notion database, Markdown tasks ou outra vista. O importante é separar tarefa de memória.
Campos mínimos
- título acionável;
- estado: inbox, next, doing, blocked, review, parked;
- área/projeto;
- próxima ação;
- bloqueio, se existir;
- link para nota owner.
Regra de done
Uma tarefa concluída não é automaticamente conhecimento. Se gerou uma decisão, fonte, output ou procedimento, promove. Se não, pode desaparecer após revisão.
Exemplo Markdown
- [ ] Rever artigo X para decidir se entra no mapa de literatura #area/phd #status/next - Próxima ação: ler abstract + método - Owner: 37.04 Literature Map - Output: decisão source-only vs concept note
07 · Revisão e anti-bloat
O sistema precisa de manutenção, mas pouca
A revisão não deve virar projeto. Deve impedir sedimentação.
Revisão semanal leve
Ver inbox, tarefas bloqueadas, decisões novas, fontes não processadas e notas que entraram sem owner claro.
Revisão mensal de memória
Perguntar o que a memória global deve esquecer, compactar ou transformar em nota/runbook.
Revisão de freshness
Só em notas críticas: dashboards, decision registers, runbooks, trackers e sínteses ativas.
Regra de limpeza
Se uma coisa não tem dono, uso, estado ou caminho de promoção, provavelmente não merece ficar ativa.
08 · Checklist de implementação
Pronto para começar
Quando estes pontos estão decididos, a pessoa pode escolher a metodologia com muito menos risco.
Decisões mínimas
- propósito do sistema escrito;
- 5-9 tipos de objeto definidos;
- critério de memória global definido;
- decision register criado;
- regras de fontes definidas;
- task cockpit criado;
- 2 templates operacionais criados;
- regra de revisão semanal definida.
Primeira semana
- não migrar tudo;
- capturar só material real;
- testar routing em 10 entradas;
- ver onde há ambiguidade;
- ajustar constituição;
- só depois sofisticar ferramentas.
Regra final: se o sistema ainda não sabe decidir se algo é fonte, decisão, tarefa, memória ou procedimento, ainda não precisa de mais automação.