Il post precedente sosteneva che CLAUDE.md serve solo per gli invarianti. Allora cosa va in memory? Ho aperto i 5 file memory attivi in questo progetto e li ho auditati uno per uno — cosa resta, cosa va cancellato e dove cade davvero il confine tra CLAUDE.md e memory.
Il post precedente sosteneva che CLAUDE.md dovrebbe contenere solo ciò che Claude non può vedere leggendo il codice. Un lettore ha subito chiesto: e memory? Memory è anch'esso contesto — qual è la differenza reale?
Molti finiscono per trattare memory come un'«estensione di backup» di CLAUDE.md — ci infilano qualsiasi cosa venga in mente. Col tempo memory si gonfia, Claude lo legge a ogni sessione e le decisioni vengono prese su informazioni obsolete.
Questo pezzo salta le definizioni astratte. Ho aperto tutti e 5 i file memory attualmente attivi in questo progetto e li ho auditati uno per uno — quali restano, quali vanno, quali non avrebbero mai dovuto essere scritti. Strada facendo, la domanda CLAUDE.md vs memory si risponde da sola.
La domanda utile non è «dove metto questo» — è «quanto vive questa informazione, e chi la aggiorna?»
feedback_commits — aspetta che dica "commit" prima di fare commit
feedback_article_authenticity — gli articoli pratici non si inventano
project_i18n_strategy — la scelta di «lanciare tutte le lingue insieme»
project_howdev_plan — piano non finito per how2claude.dev
project_article_workflow — la pipeline di pubblicazione degli articoli
Raggruppati per tipo.
Il corpo è breve: "don't auto-commit, wait for user to confirm."
È il tipo di memory con il ROI più alto. Una correzione → permanente in tutte le sessioni future.
Perché non in CLAUDE.md? Non è una regola di progetto — è la mia abitudine personale di lavoro. Se un altro contributor si unisse al progetto, non dovrebbe necessariamente seguire la stessa regola. CLAUDE.md è a livello team. Memory è «tra Claude e me».
Perché non ripeterla all'inizio di ogni conversazione? Perché memory persiste tra sessioni. Quando Claude mi aiuterà la prossima settimana, lo ricorderà ancora.
Il trigger è netto: ho corretto qualcosa una volta e voglio che la correzione duri per sempre.
Il corpo di questo memory è insolitamente specifico:
Il 2026-04-16, scrivendo la chiusura della serie multi-agent, ho inventato una storia su «tre Agent che costruiscono una feature webhook»... tutto inventato. L'utente ha chiesto «è reale o inventato» — che è un metro diverso da quello dei due articoli precedenti (metodologici)...
Il punto: il campo Why non è un principio astratto — è un evento specifico + data + cosa è successo.
Perché scriverlo così? Fra sei mesi, «gli articoli pratici hanno bisogno di materiale reale» come regola astratta mi lascerà perplesso — quando è stato fissato, perché? Ma «4-16, ho inventato una storia di agent e sono stato beccato» innesca il ricordo all'istante e mi permette di giudicare sul momento se la regola vale ancora.
È la voce più «pesante» delle mie 5. Non è solo una regola — è un fascicolo di incidente che sia Claude sia io possiamo consultare.
Il contenuto: perché questo progetto ha lanciato aggressivamente tutte le lingue in una volta — costo di traduzione via Claude ~0 €, e la documentazione ufficiale solo in inglese come finestra di opportunità centrale.
Non si vede dal codice. Il codice mostra solo 19 file di locale. Perché 19, perché tutti insieme, perché giapponese e coreano sono prioritari — tutto questo vive nella mia testa.
Memory distilla quella «decisione mentale» in qualcosa di durevole, così che quando Claude suggerirà una feature più avanti, possa chiedersi: questo va in conflitto con la strategia i18n?
Non è una regola operativa (non va in CLAUDE.md). È sfondo strategico (va in memory).
Il più temporaneo del gruppo: un piano di implementazione di 9 file per il sito sviluppatori how2claude.dev, che termina con «si continua nella prossima sessione».
Il tipo di memory più pericoloso — diventa facilmente memory zombie. Finisci il lavoro, dimentichi di cancellarlo; la volta dopo Claude lo tratta come ancora attivo e consiglia sulla base di un piano obsoleto («non hai ancora fatto lo step 3»).
Queste memory hanno bisogno di un meccanismo di uscita esplicito: nel momento in cui how2claude.dev va live, devo cancellare questa voce manualmente.
Questa ha la densità informativa più alta. All'inizio pensavo fosse la più utile — finché non l'ho letta con attenzione:
/write-article e /publish-article → guardare .claude/commands/, fattodocs/drafts/ lo rende ovvio.claude/publish-config.jsonClaude può dedurre tutto questo leggendo il codice.
L'unica cosa che memory fornisce davvero è l'ultimo blocco: "Accounts (production): zh → @how2claude, en → @howtoclaude" — e questo è già obsoleto. L'ultima sessione ha mostrato che in produzione è in realtà zh=@howtoclaude. Memory ha catturato uno snapshot di qualche giorno fa; ha già derivato.
Conclusione: il 90 % di questo memory dovrebbe sparire. Il pezzo che vale la pena tenere («usare kamal per interrogare gli account in tempo reale») sta meglio in CLAUDE.md — o meglio ancora, da nessuna parte, perché account hardcoded in memory deriveranno di nuovo.
1. Il vero ruolo di memory è aprire stanze in cui Claude non può entrare.
2. Se Claude può leggerlo dal codice, non metterlo in memory.
Stesso principio dell'articolo precedente su CLAUDE.md. Percorsi di file, URL di API, struttura di directory — tutte domande a cui il codice risponde. Infilarle in memory perché non hai voglia di fare un grep è scommettere che nulla cambierà mai.
3. Memory decade.
project_article_workflow ne è la prova — scritto giorni fa, le info sugli account sono già sbagliate. Più vecchio è memory, meno è affidabile. Auditare regolarmente > aggiungere senza fine.
4. Il campo Why è ciò che ti salva.
Confronto tra i miei due feedback:
feedback_article_authenticity: «4-16, ho inventato una storia nell'articolo multi-agent» → sei mesi dopo posso giudicare all'istante se vale ancora.feedback_commits: solo «user wants to review» → sei mesi dopo non sono sicuro quale correzione specifica l'abbia generata.Il secondo è molto più debole. I principi astratti non sopravvivono — nessuno ricorda perché siano stati imposti.
Quando compare nuova informazione, poniti tre domande:
La terza domanda è la trappola. Gran parte delle cose «che non cambiano» che vorresti annotare sono in realtà deducibili dal codice — semplicemente non vuoi far fare a Claude un altro grep.
Dopo un passaggio, alcune cose saltano fuori:
project_article_workflow è deducibile dal codice. È quella che richiede più chirurgia.project_howdev_plan è un handoff temporaneo — in teoria dovrebbe avere un meccanismo di uscita.project_i18n_strategy è una decisione strategica — vale la pena rivederla fra qualche mese.feedback_commits è debole; aggiungere un evento specifico lo renderebbe più solido.Osservazione laterale: la mia distribuzione di tipi è feedback×2 + project×3, zero tipi user o reference. Significa che non ho ancora detto a Claude «chi sono» o «da quali sistemi esterni leggo stato». Probabilmente il prossimo lotto da scrivere.
La trappola più grande di memory non è «quello che avrei dovuto scrivere e non ho scritto». È «quello che ho scritto e ora è obsoleto». Con 5 voci, basta una deriva — Claude usa silenziosamente informazioni vecchie per decidere, e non ti segnalerà la deriva.
Nelle mie 5, vedo già un paio di cose da muovere. E nelle tue?