O post anterior defendeu que CLAUDE.md só guarda invariantes. Então o que vai no memory? Abri os 5 arquivos de memory que rodam hoje neste projeto e auditei um por um — o que fica, o que deve sumir e onde realmente está a linha entre CLAUDE.md e memory.
O post anterior defendeu que o CLAUDE.md só deveria conter o que o Claude não consegue ver lendo o código. Um leitor perguntou na hora: e o memory? Memory também é contexto — qual é a diferença de verdade?
Muita gente acaba tratando o memory como uma "extensão de backup" do CLAUDE.md — joga lá qualquer coisa que lembrar. Com o tempo, o memory incha, o Claude lê tudo a cada sessão e decisões acabam sendo tomadas com base em informação desatualizada.
Este post pula as definições abstratas. Abri os 5 arquivos de memory que estão rodando agora neste projeto e auditei um por um — o que fica, o que sai, o que nunca deveria ter sido escrito. No caminho, a pergunta CLAUDE.md vs memory se responde sozinha.
A pergunta útil não é "onde isso vai" — é "quanto tempo essa informação vive e quem atualiza."
feedback_commits — esperar eu dizer "commit" antes de commitar
feedback_article_authenticity — artigos práticos não podem ser inventados
project_i18n_strategy — a decisão de "lançar todos os idiomas de uma vez"
project_howdev_plan — plano inacabado para how2claude.dev
project_article_workflow — o pipeline de publicação de artigos
Agrupando por tipo.
O corpo é curto: "don't auto-commit, wait for user to confirm."
É o tipo de memory com maior ROI. Uma correção → permanente em todas as sessões futuras.
Por que não no CLAUDE.md? Não é uma regra do projeto — é meu hábito pessoal de trabalho. Se outro colaborador entrar no projeto, não precisa seguir a mesma regra. CLAUDE.md é nível de time. Memory é "entre Claude e eu."
Por que não repetir no início de cada conversa? Porque o memory persiste entre sessões. Quando o Claude me ajudar semana que vem, ele ainda vai lembrar.
O gatilho é limpo: corrigi algo uma vez e quero que a correção dure para sempre.
O corpo desse memory é incomumente específico:
Em 2026-04-16, enquanto escrevia o fechamento da série multi-agent, inventei uma história sobre "três Agents construindo uma feature de webhook"... tudo inventado. O usuário perguntou "isso é real ou foi inventado?" — que é um critério diferente dos dois posts anteriores (metodológicos)...
O ponto: o campo Why não é um princípio abstrato — é um evento específico + data + o que aconteceu.
Por que escrever assim? Daqui a seis meses, "artigos práticos precisam de material real" como regra abstrata vai me deixar sem entender — quando isso foi definido, por quê? Mas "4-16, inventei uma história de agent e fui pego" aciona a memória imediata e me deixa julgar na hora se a regra ainda se aplica.
É a entrada mais "pesada" dos meus 5. Não é só uma regra — é uma ficha de incidente que tanto o Claude quanto eu podemos consultar.
O conteúdo: por que este projeto lançou agressivamente todos os idiomas de uma vez — custo de tradução via Claude é ~$0, e documentação oficial só em inglês é a janela de oportunidade central.
Isso não dá pra ver no código. O código só mostra 19 arquivos de locale. Por que 19, por que todos de uma vez, por que japonês e coreano são prioritários — tudo isso vive na minha cabeça.
O memory destila essa "decisão mental" em algo durável, pra que quando o Claude sugerir uma feature mais tarde, ele possa se perguntar: isso conflita com a estratégia de i18n?
Não é uma regra operacional (não vai no CLAUDE.md). É pano de fundo estratégico (vai no memory).
O mais temporário do grupo: um plano de implementação de 9 arquivos para o site de desenvolvedores how2claude.dev, terminando com "continua na próxima sessão."
É o tipo de memory mais perigoso — vira memory zumbi facilmente. Você termina o trabalho, esquece de apagar; na próxima, o Claude trata como ainda ativo e aconselha com base num plano desatualizado ("você ainda não fez o step 3").
Esses memories precisam de um mecanismo de saída explícito: no momento em que o how2claude.dev for ao ar, eu tenho que apagar essa entrada manualmente.
Essa tem a maior densidade de informação. No começo achei que fosse a mais útil — até ler com atenção:
/write-article e /publish-article → olhar .claude/commands/, prontodocs/drafts/ deixa óbvio.claude/publish-config.jsonO Claude consegue deduzir tudo isso lendo o código.
A única coisa que o memory realmente fornece é o último bloco: "Accounts (production): zh → @how2claude, en → @howtoclaude" — e isso já está desatualizado. Na última sessão descobrimos que em produção é zh=@howtoclaude. O memory capturou um snapshot de alguns dias atrás; já desalinhou.
Conclusão: 90% desse memory deveria ir embora. O pedaço que vale manter ("usar kamal pra consultar contas em tempo real") cabe melhor no CLAUDE.md — ou, melhor ainda, em lugar nenhum, já que contas hardcoded no memory vão desalinhar de novo.
1. O verdadeiro papel do memory é abrir salas em que o Claude não consegue entrar.
2. Se o Claude consegue ler pelo código, não coloque no memory.
Mesmo princípio do artigo anterior sobre CLAUDE.md. Caminhos de arquivo, URLs de API, estrutura de diretórios — tudo o código responde. Jogar no memory porque você não quer fazer um grep é apostar que nada vai mudar nunca.
3. Memory degrada.
project_article_workflow é a prova — escrito dias atrás, a informação de contas já está errada. Quanto mais velha a memory, menos confiável. Auditar regularmente > adicionar sem parar.
4. O campo Why é o que te salva.
Comparando meus dois feedbacks:
feedback_article_authenticity: "4-16, inventei uma história no artigo multi-agent" → seis meses depois, consigo julgar na hora se ainda se aplica.feedback_commits: "user wants to review" — seis meses depois, não sei qual correção específica deu origem.O segundo é muito mais fraco. Princípios abstratos não sobrevivem — ninguém lembra por que foram impostos.
Quando uma nova informação aparece, faça três perguntas:
A terceira pergunta é a armadilha. A maior parte do material "que não muda" que você quer anotar na verdade é dedutível pelo código — você só não quer que o Claude faça grep de novo.
Algumas coisas ficaram evidentes:
project_article_workflow é dedutível pelo código. Essa é a que precisa de mais cirurgia.project_howdev_plan é um handoff temporário — em teoria deveria ter um mecanismo de saída.project_i18n_strategy é uma decisão estratégica — vale revisitar em alguns meses.feedback_commits é fraco; anexar um evento específico deixaria mais robusto.Observação lateral: minha distribuição de tipos é feedback×2 + project×3, com zero tipos user ou reference. Isso quer dizer que ainda não contei para o Claude "quem eu sou" ou "de que sistemas externos eu leio estado". Provavelmente é o próximo lote a escrever.
A armadilha maior do memory não é "o que eu deveria ter escrito e não escrevi." É "o que escrevi e já ficou desatualizado." Com 5 entradas, um desalinhamento já basta — o Claude usa silenciosamente informação velha para decidir, e não vai te avisar do desajuste.
Nos meus 5, já vejo algumas coisas pra mexer. E nos seus?