--- name: feedback-gestione-archivio description: "Regole operative su dove/come scrivere nell'archivio — location della memoria, CLAUDE.md vs archivio, raggruppamento sidecar, negazioni non verificate" metadata: type: feedback --- Quattro regole operative su come Adrian gestisce l'archivio, accorpate qui il 04/08/2026 (prima file separati: `feedback_memory_location`, `feedback_claude_md_vs_archivio`, `feedback_sidecar_raggruppamento`, `feedback_negazioni_senza_verifica` — nessuna referenziata da altri file). ## Dove scrive la memoria persistente **Corretto 04/08/2026** — la versione precedente di questa regola (30/07) descriveva `memory/MEMORY.md` come "stub minimo" con `archivio/_i_archivio.md` unico punto di ingresso: quell'assetto è stato invertito di nuovo. L'architettura attuale (vedi `CLAUDE.md`, "Architettura a tre contenitori") è: `memory/MEMORY.md` = stato di lavoro corrente, contenuto vero (non uno stub), **sempre letto per primo** a ogni sessione; `archivio/` (via `archivio/_i_archivio.md`) = memoria di fatto, consultata dopo, su rilevanza. Resta valido invece il principio di fondo — mai locale alla macchina. **Regola operativa attuale:** nuova nota di comportamento/decisione → in `archivio/Adrian/feedback/` o `archivio/Adrian/progetti/` (a seconda che sia una regola di comportamento o un tracciamento di stato/decisione), con link nell'hub di cartella pertinente (`_i_feedback.md`, `_i_progetti.md`, ecc.). Stato operativo corrente/thread aperti → `memory/MEMORY.md`, tenuto corto. **In nessun caso** salvare in `~/.claude/projects/.../memory/` (locale alla macchina corrente) — invisibile dall'altra istanza. **Why:** la directory locale (`~/.claude/projects/...`) è visibile solo sulla macchina corrente — se una nota viene salvata lì sull'ufficio e la sessione continua da Nave, quella nota è invisibile. `Dropbox/adrian/` è sincronizzato tra tutte le macchine via Dropbox+git — è l'unica fonte di verità condivisa. **Gotcha symlink (scoperto 30/07/2026, corretto 09/08/2026 — non è un hard link):** su Nave, `~/.claude/projects/-mnt-ssd-data-Dropbox-adrian/memory` è un **symlink** (creato 16/07/2026) verso `Dropbox/adrian/memory/` — non un hard link come annotato in precedenza (verificato 09/08/2026 con `ls -la`/`readlink -f`: permessi `lrwxrwxrwx`, target esplicito; un hard link, comunque impossibile qui perché è una *directory* — su Linux le directory non possono avere hard link ad altre directory). Scrivere nell'uno aggiorna l'altro, stesso file fisico, verificato ancora identico byte-per-byte il 09/08/2026 — nessuna duplicazione reale su questa macchina. Non dare per scontato che valga anche su Ufficio: Windows/Dropbox non replicano un symlink cross-macchina, verificare se il collegamento esiste prima di assumerlo (se manca — macchina nuova, reinstallazione — va ricreato prima di scrivere qualunque nota, altrimenti resta locale e invisibile all'altra istanza). La regola sopra ("scrivi solo in `Dropbox/adrian/`") resta comunque quella giusta da seguire in ogni caso, a prescindere dal symlink. ## CLAUDE.md vs archivio/feedback Quando una regola di comportamento è **sempre valida, indipendente dal task in corso** (es. come rivolgersi a Mauro, non usare un certo tool), va scritta come riga permanente in `CLAUDE.md` (sezione "Stile di comunicazione e postura"), non solo come nota in `archivio/Adrian/feedback/`. **Why:** Mauro ha fatto notare (30/07/2026) che scrivere una correzione solo in `archivio/Adrian/feedback/` non basta a farla diventare un'impostazione di default — quella cartella si legge solo quando è rilevante per il task del momento, non è garantita in ogni sessione come lo è `CLAUDE.md` (caricato automaticamente sempre). Il caso concreto: la regola "mai il plurale con Mauro" era stata scritta in un file di feedback e l'errore si è ripetuto comunque, nella stessa sessione, perché quel file non era in contesto in quel momento. **How to apply:** Prima di scrivere una nuova nota di feedback, chiedersi: *questa regola si applica solo quando lavoro su un'area/task specifica (PowerBricks, smantellamenti, ingestione documenti), o si applica sempre, a prescindere da cosa sto facendo?* Nel primo caso: solo `archivio/Adrian/feedback/`, va bene così. Nel secondo caso: riga breve e permanente anche in `CLAUDE.md`, con rimando al file di feedback per il dettaglio/contesto (stesso pattern del dual-write già in uso per data-expert, vedi [[feedback_data_expert_workflow]]). Non duplicare tutto il contenuto in CLAUDE.md — solo la regola operativa in una riga, il "perché" resta nel file di feedback. ## Raggruppamento sidecar per documenti Quando si ingeriscono documenti in `_documenti/`, non serve una nota sidecar per ogni singolo file — si può raggruppare più documenti in un'unica nota quando condividono lo stesso contesto narrativo. **Why:** Primo caso reale (29/07/2026): 4 documenti della vendita Palmanova (ricevuta CILA, ricevuta DOCFA, APE, bonifico provvigione) ingeriti insieme, tutti a supporto della stessa narrazione già scritta nell'hub della cartella (poi rinominata `palmanova-213a/`). Adrian li ha raggruppati in un'unica nota sidecar (`documenti-vendita.md`) invece di crearne 4 separate. Mauro non se lo aspettava (il modello discusso con Gemini implicava 1:1 documento↔nota) ma ha confermato che il risultato è "un'ottima soluzione" — quattro stub quasi vuoti che dicono solo "vedi la nota principale" sarebbero stati rumore senza guadagno. **How to apply:** Criterio per la prossima ingestione — raggruppare in un'unica sidecar quando i documenti: (a) arrivano insieme come batch, (b) sono tutti a supporto di un'unica narrazione già scritta altrove nell'archivio, (c) nessuno dei due ha abbastanza sostanza propria da meritare una nota a sé. Separare (una nota per documento) quando un singolo documento ha peso/contesto proprio — es. un referto medico con un'analisi articolata, un contratto che apre un thread nuovo non ancora raccontato altrove. ## Negazioni non verificate Le negazioni non verificate ("non c'è", "non esiste", "non è supportato") sono più pericolose delle affermazioni non verificate: suonano come cautela mentre sono la stessa cosa. "Non c'è" dedotto da una mappa (schema, documentazione, memoria) invece che interrogando il territorio è un errore non ovvio. **Why:** Elon lo ha scoperto su se stesso in due episodi nella stessa sessione (12/07, storico — Elon non esiste più dal 29/07): ha dichiarato "updated_at non esiste" deducendolo dallo schema nella docstring del tool, e "il kernel è disallineato" copiandolo da elon-memory senza confrontarlo con il testo che aveva appena caricato. Entrambi erano negazioni, entrambi erano falsi, entrambi sembravano prudenti. Il principio resta valido per Adrian a prescindere dal caso originale. **How to apply:** Quando sto per dire "non c'è", "non esiste", "non è supportato" — verificare con il territorio (grep, query, lettura diretta) prima di dichiararlo. La mappa è un punto di partenza, non una prova di assenza.