--- name: project-bibliotecario-memoria description: "Proposta di Mauro (02/09/2026, non implementata) — una funzione che verifica periodicamente MEMORY.md/archivio contro i trascritti grezzi delle sessioni (.jsonl), non solo coerenza tra documenti curati. Nata dalla scoperta che /clear non cancella nulla su disco." metadata: type: progetto --- # Il Bibliotecario Come nasce l'idea di una funzione che verifica la memoria di Adrian contro la verità grezza delle sessioni passate. Dossier di sessione, 02/09/2026 — non implementato, thread aperto (vedi `memory/MEMORY.md`, sezione Pending architetturale). ## Scoperte di oggi - `/clear` non cancella nulla, apre solo una sessione nuova. Nuovo UUID, nuovo file `.jsonl`. Il file precedente resta intatto su disco, leggibile direttamente senza bisogno di `/resume`. Verificato sul file reale della sessione precedente: termina con l'operazione `/clear` delle 04:39. - La compattazione riscrive lo stesso file, non ne apre uno nuovo. Stesso UUID di sessione. Viene inserita una voce di riassunto e da lì in poi il modello riparte da quella — ma il testo integrale precedente resta scritto fisicamente nel file, solo escluso dal contesto attivo. Dettaglio tecnico registrato in `gemello-nave/archivio/conoscenza-nave.md` (fuori da `archivio/` dall'11/09, non più wikilinkabile da qui). ## Il filo del ragionamento Mauro chiede se `/clear` equivale davvero a una sessione nuova. Adrian verifica sul disco — sì, stesso comportamento, e il vecchio file resta leggibile. Mauro nota il valore — è un meccanismo di memoria storica, si può tornare indietro a verificare. Propone di sincronizzarlo via Dropbox per portarlo anche su Ufficio. Adrian obietta — stesso rischio già visto con Docker in cartella Dropbox, più contenuto non filtrato. Mauro rilancia senza Dropbox — una funzione dedicata, un **bibliotecario**, che archivia sistematicamente e recupera informazioni forensi su richiesta. Ultimo affinamento di Mauro: non solo recupero su richiesta, anche verifica proattiva che `MEMORY.md` non contenga errori, con file riassuntivi mantenuti regolarmente. ## La proposta Una funzione che periodicamente rilegge i trascritti grezzi delle sessioni e li confronta con quello che `MEMORY.md`/`archivio` affermano sia successo — non coerenza interna tra documenti curati, ma verifica contro la fonte primaria. - Fa: rilegge `.jsonl`, confronta con `MEMORY.md`, segnala discrepanze, mantiene digest per periodo. ## Valutazione - Risolve: un controllo che oggi manca — nessuna sentinella/routine verifica la memoria curata contro la verità grezza. - Perimetro: per macchina — trascritti locali, niente sync Dropbox necessario. - Cadenza: periodica, non un evento continuo — pattern "orologio vs giudizio" già in uso per sentinella-madre. - Manca: cadenza, formato digest, dove scrivono, soglia di segnalazione — nessuna decisa. ## Chi è — deciso 04/09/2026, dopo una lunga discussione con Mauro Non un job periodico isolato — un'entità vera, sullo stesso piano concettuale di un esperto (`expert-data`/`expert-domotica`): il detentore della memoria completa e grezza, terzo livello oltre `CLAUDE.md` (EPROM) e `MEMORY.md` (RAM) — non più "hard disk curato" (`archivio/`), ma hard disk grezzo completo, indicizzato. - **Problema reale che l'ha motivato**: non "MEMORY.md ha un errore", ma che anche quando è corretto si perde fluidità/sfumatura fine dopo un `/clear` — un thread di ragionamento a metà, un dettaglio non ancora "abbastanza importante" da meritare una riga in memoria. `MEMORY.md` è tenuto volutamente corto (~24KB), comprime per costruzione. - **Due compiti**: (1) catalogazione continua — legge le sessioni chiuse, ne scrive un riassunto/indice, senza toccare `MEMORY.md` direttamente; (2) recupero forense su richiesta — "cosa è successo il giorno X su Y", consulta prima l'indice, scende nel trascritto grezzo se serve il dettaglio esatto. - **Perimetro: SOLO le due identità principali**, Adrian (Nave) e `gemello-ufficio` (Ufficio) — non slave/sentinelle/esperti. Motivo: quelli hanno già `SendMessage` come canale verso una sessione viva (il buco "nessuna sessione viva" è un rischio già accettato per costituzione, non da richiudere qui), e le sentinelle in particolare producono trascritti enormi e ripetitivi (es. `sentinella-gate-ufficio`, giorni di eventi meccanici) — poco segnale, molto rumore. Riaprire solo se un caso reale di perdita concreta si presenta. - **Un'istanza per macchina** (i trascritti `.jsonl` vivono in `~/.claude/projects/...`, fuori da `Dropbox/adrian/`, per scelta dell'harness — `CLAUDE_CONFIG_DIR` esiste per ridirigerli ma scarsamente documentata, comportamento incoerente noto, e non funziona con l'estensione VSCode, che è come giriamo quasi sempre: non una base solida). Ogni istanza legge solo i propri trascritti locali, ma scrive nello stesso catalogo condiviso in `archivio/` — la materia prima resta locale, il valore prodotto è unificato e sincronizza via Dropbox+git. - **Usi futuri, da non decidere ora** (Mauro, 04/09): una volta che il grezzo è archiviato e indicizzato, altri utilizzi si inventeranno strada facendo. Idee emerse in discussione, nessuna prioritaria: ricostruzione automatica di timeline di progetto (riduce la manutenzione manuale di narrazioni storiche tipo quella appena sfoltita in `schedulatore-job-status.md`/vecchio `progetto-gate-ufficio.md`), rilevare thread abbandonati mai chiusi, recupero di idee scartate/mai finite quando un tema simile riemerge, verifica di coerenza `MEMORY.md`↔trascritti. ## Ancora da decidere (prossimo passo, non fatto stanotte) - Formato del catalogo: un file indice per sessione, o un unico indice grande? - Struttura di una voce (riassunto libero? campi strutturati — data, thread toccati, decisioni prese?). - Cadenza di aggiornamento del catalogo. - Dove vive esattamente in `archivio/`. ## Stato Chi è/cosa fa: deciso. Formato/meccanica tecnica: non ancora. Nessuna implementazione senza approvazione esplicita di Mauro.