ctx-memory: come ho costruito su Drupal la memoria delle decisioni per Claude
ctx-memory è un esperimento mio: un piccolo grafo delle decisioni di progetto, costruito su Drupal 11 e Typesense, che Claude interroga attraverso un server MCP. È una costola del sistema con cui lavoro con l'AI, e da circa cinque mesi è uno degli strumenti che uso di più. Il codice non è pubblico: è un caso di studio, e lo illustro volentieri a chi è interessato.
Perché un sistema custom, quando ne esistono di pronti?
Ho scelto un sistema custom per avere il controllo e poterlo vedere. Di server MCP che danno memoria a Claude ce ne sono molti, e alcuni sono fatti bene. Volevo invece sperimentare una soluzione mia: usare Typesense per la ricerca, e tenere i dati in un piccolo grafo di cui controllo la struttura, campo per campo.
Il problema da risolvere era concreto. Quando lavoro sullo stesso progetto in più sessioni, ogni sessione nuova parte senza ricordare le scelte fatte nelle precedenti. Con ctx-memory le decisioni restano: le ritrovo interrogando il grafo, invece di rispiegarle o, peggio, di contraddirle.
Come è fatto ctx-memory?
ctx-memory mette insieme pochi componenti, ciascuno con un compito solo:
| Componente | Ruolo |
|---|---|
| Drupal 11 su PostgreSQL | tiene contesti, decisioni, evidenze e relazioni come entità, con revisioni e permessi |
| Typesense, con Search API | indicizza tutto per la ricerca, con l'indice in RAM ricostruibile dal database |
| server MCP | espone a Claude tre strumenti: cerca, leggi, cattura |
| due hook di Claude Code | catturano da soli il proposal.md di ogni change OpenSpec e ogni ADR committato, con il permalink |
| Graph Explorer | una vista 3D del grafo, per guardare come sono organizzati i dati |
| Sablier | accende lo stack alla prima richiesta e lo spegne quando resta inattivo |
Le relazioni sono entità anche loro: oggi sono 645, e legano ogni decisione al contesto e alle evidenze che la provano.
Perché Drupal come database di un grafo?
Perché Drupal dà già quasi tutto quello che serve a un dato che deve durare. Ogni entità ha campi tipizzati, revisioni e permessi. L'interfaccia di amministrazione per correggere un record c'è senza scriverla, e Search API collega Typesense senza codice di indicizzazione. Il lavoro custom si riduce al modello dei dati e alle regole, che è proprio la parte che volevo controllare.
Quali regole tengono affidabile la memoria?
La specifica del progetto fissa quattro regole come principi non negoziabili:
- una decisione catturata nasce sempre «proposta», e la conferma solo una persona, con un permesso che nessun agente ha.
- una decisione si conferma solo con almeno un'evidenza che punta a una fonte stabile.
- il grafo è append-only: una decisione cambia solo con una nuova che sostituisce la vecchia, con la
data.
- ogni record dichiara chi l'ha scritto, una persona o un modello, e in quale esecuzione.
I numeri mostrano la prima regola al lavoro. Tutte le 179 decisioni del grafo le ha catturate un modello; 87 le ho confermate io, 82 aspettano la mia revisione, 6 le ho scartate e 4 sono state sostituite da una decisione più recente.
Come lo uso ogni giorno?
Lo uso da terminale, con Claude. Evoco il progetto, e Claude rintraccia le decisioni collegate e le loro evidenze: così una sessione nuova riparte dal contesto già definito. Le decisioni nuove le scrive nel grafo la skill di ctx-memory, come proposte.
Il Graph Explorer non lo uso per cercare: serve a guardare la struttura dei dati e a capire se il grafo cresce nel modo giusto.
Fonti
Tutte le misure sono state lette il 1 ottobre 2026 sul database di ctx-memory.
- Drupal (si apre in una nuova scheda) e Search API Typesense (si apre in una nuova scheda). Fonte primaria.
- Typesense (si apre in una nuova scheda). Fonte primaria.
- Model Context Protocol (si apre in una nuova scheda). Fonte primaria.
- OpenSpec (si apre in una nuova scheda) e Architecture Decision Records (si apre in una nuova scheda). Fonte primaria.
- Sablier (si apre in una nuova scheda). Fonte primaria.
- Specifica e codice di ctx-memory, conteggi di decisioni, evidenze, contesti e relazioni.
Rilevamento dell'autore.
Questo contenuto è stato prodotto dall'AI e rivisto da una persona.
Come è stata usata l'AI?
Le bozze sono prodotte con l'assistenza dell'AI, poi dirette, rivedute e verificate da una persona. Numeri, date e versioni sono confrontati con le fonti pubbliche prima della pubblicazione, e la data di quel controllo è indicata nel testo.