⚠️ Memory vs Repo — onde salvar o quê

LEIA COM ATENÇÃO

Essa é uma das regras mais importantes pra quem usa Claude Code na holding. Errar aqui gera 2 problemas:

• Info do time some (salva em memory local e ninguém mais vê)
• Preferências pessoais vazam (tenta commitar no Git o que deveria ser privado)

A regra essencial em 1 frase

Memory local = privado seu. Repo = compartilhado com o time.

Antes de pedir “Claude, salva isso na memória”, pergunta: é privado ou é do time?

Quando usar cada um

✅ Memory local (~/.claude/projects/.../memory/)

Fica só na tua máquina. Ninguém do time vê. Não vai pro Git.

Use pra:

• Feedback pessoal sobre como você gosta de trabalhar
  • “Quando eu pedir pra gerar código, já adiciona testes”
  • “Prefiro respostas em português, tom direto”
• Preferências de UI / ferramentas
  • “Uso rg em vez de grep”
  • “Meu editor favorito é VS Code”
• Experiências pessoais que ajudam futuras conversas suas
  • “Em Janeiro bati cabeça com bug X — lembra”
• Contexto transitório enquanto você aprende
  • “Ainda tô entendendo como funciona Cloudflare Workers”

✅ Repo (vai pro Git, time todo vê)

Use pra:

Tipo de info	Repo	Exemplo
Decisão técnica / arquitetural	knowledge-base/adrs/	”Decidimos usar Vite em vez de Webpack porque…”
Decisão operacional / negócio	knowledge-base/decisions/	”Passamos Skopia pra Cloudflare pra evitar Netlify”
Playbook repetível	knowledge-base/playbooks/	”Como rodar campanha de outbound”
Runbook de incidente	knowledge-base/runbooks/	”Se Apollo parar, fazer X”
Pesquisa de mercado	knowledge (via Issue)	“Landscape de Creator SaaS 2025”
Ficha de pessoa/conta/empresa	registry/	”Quem é o Paulo, que contas temos”
Regra operacional do grupo	operations/	”Como abrir PR, como rodar review”
Contexto específico do repo	<repo>/CLAUDE.md	”O que é o sub-projeto X, como rodar”

Como decidir: fluxograma

Info que quero salvar...
         │
         ▼
   "Isso só me importa?" (preferências, feedback, experiência pessoal)
         │
        SIM → Memory local ("Claude, salva na minha memória")
         │
        NÃO
         ▼
   "Isso é decisão técnica ou de negócio?"
         │
        SIM → knowledge-base (PR em adrs/ ou decisions/)
         │
        NÃO
         ▼
   "Isso é processo/procedimento repetível?"
         │
        SIM → knowledge-base/playbooks/ ou runbooks/ (PR)
         │
        NÃO
         ▼
   "Isso é pesquisa de mercado externa?"
         │
        SIM → knowledge (Issue com label "submission")
         │
        NÃO
         ▼
   "Isso é cadastro (pessoa, conta, empresa, custo)?"
         │
        SIM → registry (PR)
         │
        NÃO
         ▼
   "Isso é contexto do repo específico?"
         │
        SIM → CLAUDE.md do repo (PR)
         │
        NÃO → me chama pra decidirmos juntos

Exemplos práticos do dia-a-dia

Caso 1 — Silas descobriu algo sobre YouTube API

Situação: Silas testando o dashboard descobre que YouTube API tem rate limit de X req/min pra endpoint Y, coisa que não tá na docs oficial.

Para onde vai? Repo. Isso é conhecimento técnico útil pra todo mundo que mexer com YouTube API.

✅ Ação certa:

• PR em knowledge-base/runbooks/2026-04-24-youtube-api-rate-limits.md
• Pode pedir pro Claude Code: “Cria um runbook em knowledge-base sobre o rate limit que a gente descobriu. Abro PR quando terminar.”

❌ Ação errada:

• Silas pede “Claude, salva na memória que YouTube API tem rate limit X”
• Fica só na máquina dele. Paulo, João, ninguém aprende.

Caso 2 — Paulo descobriu que prefere rodar testes com pytest -x

Situação: Paulo tá mais produtivo usando pytest -x (para no primeiro erro) em vez do padrão.

Para onde vai? Memory local. É preferência pessoal dele.

✅ Ação certa:

• “Claude, salva na memória que eu prefiro pytest com -x”
• Fica no Claude Code dele, não afeta outros.

❌ Ação errada:

• PR em knowledge-base falando “Paulo prefere pytest -x” — ninguém se importa.

Caso 3 — Time decidiu usar Bun em vez de Node

Situação: Em uma call, Fred + Filipe + Paulo decidem que novos sub-projetos usarão Bun em vez de Node.

Para onde vai? Repo. Decisão técnica que afeta todos.

✅ Ação certa:

• ADR em knowledge-base/adrs/2026-04-24-bun-over-node.md
• Contém: contexto, decisão, alternativas consideradas, consequências
• Todos conseguem consultar

❌ Ação errada:

• Cada um salva na memória local: “a gente decidiu usar Bun”
• Daqui 3 meses, nova pessoa chega e não sabe. Memory local não viaja.

Caso 4 — Convenção de commit message

Situação: A gente adotou usar prefixos tipo feat:, fix:, docs: nos commits.

Para onde vai? Repo, em operations/ ou no handbook.

✅ Ação certa:

• Página no handbook explicando (já existe em Branch, commit, PR)
• OU PR em operations/git-conventions.md

Caso 5 — Descoberta sobre cliente específico

Situação: Silas aprende que cliente Nike prefere briefings com tom informal.

Para onde vai? Depende do escopo:

• Se é da Oinc → CLAUDE.md da Oinc ou em oinc-filmes/clientes/nike/briefing-preferences.md
• Se é só da pesquisa dele ainda → Memory local enquanto confirma
• Se é política do cliente em todas empresas → registry/ (mas esse caso é raro)

Anti-padrões comuns (NÃO faz)

❌ “Claude, salva tudo que a gente conversou na memória”

Vaga. Claude pode salvar info redundante, pessoal, ou contraditória. Seja específico sobre O QUÊ salvar.

❌ Repetir info em memory + repo

Se você já escreveu no repo, não precisa duplicar em memory. Claude lê do repo via CLAUDE.md.

❌ Commitar memory local pra repo

Alguém eventualmente tenta adicionar ~/.claude/ ao Git. Não faça. Inclui:

• Preferências suas que vazam
• Session history com dados transitórios
• Potencialmente conteúdo sensível

❌ Usar memory como lista de TODOs

Memory serve pra fatos e preferências permanentes, não pra “lista de coisas pra fazer depois”. TODO vai pra Jira/Notion (dependendo da tua empresa).

Pra Fred (admin)

Se você descobrir que um teammate tá salvando info do time na memory local dele, corrige em reunião 1:1. Pede pra ele fazer PR no repo equivalente.

Duas vezes por mês, pergunte ao time:

“Nos últimos 15 dias, que info vocês salvaram que deveria estar no repo mas ainda não tá?”

Cria hábito. Evita que conhecimento se perca nas máquinas individuais.

Resumo super compacto

Tipo	Onde
Preferência pessoal, feedback pra você	Memory local
Decisão técnica	knowledge-base/adrs/
Decisão operacional/negócio	knowledge-base/decisions/
Processo repetível	knowledge-base/playbooks/
Procedimento de incidente	knowledge-base/runbooks/
Pesquisa de mercado	knowledge (via Issue)
Pessoa/conta/empresa	registry/
Regra operacional	operations/
Contexto do repo específico	<repo>/CLAUDE.md

Próximos

→ Gerar pesquisa via Knowledge Hub — caso específico de usar o repo knowledge