---
name: project-alleggerimento-elon
description: "Architettura 'AgentBricks' (decisa 27-28/07/2026) — Adrian pivot centrale, agenti web leggeri specializzati sotto sua supervisione, tutto su file"
metadata:
  type: project
---

**CHIUSO 03/08/2026** — smantellamento vault/vault-mcp/Elon completato, architettura AgentBricks decisa e in uso. Testo originale (storico) sotto. Sezione viva: "Roadmap / idee parcheggiate" in fondo.

**Decisione (27/07/2026, riflessione serale dopo test ChatGPT/voce)**: Mauro ha deciso di alleggerire l'architettura a due entità (Elon + Adrian) verso **Adrian come pivot unico**. Non un colpo secco — una dismissione graduale.

**Cosa resta**: la "memoria finita" — fatti che Mauro dimentica per via dell'ADHD auto-diagnosticato e che non cambiano interpretazione nel tempo (famiglia, portafoglio, regole permanenti tipo il Manifesto dell'Investitore, scadenze, stato progetti). Questa parte migra dentro la memoria di Adrian.

**Cosa si abbandona**: le "letture strategiche" del vault — dinamiche organizzative, inferenze su chi manovra cosa (Marcello-Simona, successione Modina, AllRights come aggiramento istituzionale, ecc.). Mauro le ha definite "un pozzo senza fondo": non decadono da sole, ogni conversazione ne genera di nuove, e la loro cura consumava energia sproporzionata al valore. Non vanno migrate — si lasciano semplicemente andare.

**Why:** Il test del 26-27/07 con ChatGPT (export vault + voce) e con la voce di Claude/Haiku ha chiarito cosa Mauro cerca davvero: un aiuto a ricordare cose finite, non un secondo cervello che accumula analisi politica d'ufficio senza fine. La comodità della voce è reale ma "succhia energie" se richiede continui escamotage tra più sistemi (ChatGPT, Elon, Adrian). Mauro ha validato esplicitamente: non è tempo perso, ha aiutato ad "aggiustare il tiro".

**How to apply:** Non trattare più il vault (`vault.db`/nodi persona-dinamica-episodio) come la fonte primaria da consultare per capire il contesto di Mauro — quella era la parte in dismissione. Il lavoro vero da fare (non ancora iniziato, sessione dedicata da programmare): decidere nodo per nodo cosa del vault è "memoria finita" (va salvato, probabilmente dentro `memory/` di Adrian) e cosa è "lettura strategica" (si lascia decadere). Poi decidere il destino tecnico di `vault-mcp.service`/progetto Elon su claude.ai.

**Non ancora deciso**: tempistica e modalità dello spegnimento di Elon/vault-mcp; se tenere il vault attuale come archivio consultabile ma non più mantenuto, o chiuderlo del tutto dopo l'estrazione della memoria finita.

**Prossimo contenitore pianificato (28/07, non ancora — solo dopo che calendario/todo/diario avranno dimostrato di reggere)**: email di lavoro. ~~Collegato all'idea RAG già registrata: esiste uno scheletro tecnico spento e riusabile, `vault-secondbrain/ingest.py`~~ — **`ingest.py` cancellato il 29/07** insieme allo spegnimento completo di vault-mcp/Elon (era costruito per ingerire dentro `vault.db`+LanceDB, architettura ormai smontata): se/quando si arriva alle email, si progetta da zero dentro l'architettura archivio-based, non riesumando questo file. Sequenza esplicita di Mauro resta valida: prima verificare che il framework tenga sui tre contenitori attuali, poi aggiungere le email — non in parallelo.

**Seconda passata di pulizia (29/07/2026)** — Mauro segnala di vedere ancora due file "fuori dalla cartella adrian": è `/mnt/ssd/data/vault-secondbrain/` (cartella **dati**, fuori dal repo git, distinta da `Dropbox/adrian/vault-secondbrain/` che è codice). Conteneva `vault.db` + `.session_token` (nascosto). Il secondo non è referenziato da nessun file nel codebase (grep su tutto `adrian/` e `adrian-ops/`, zero risultati) — cancellato. `vault.db` inizialmente tenuto (vuoto, compattato con `VACUUM` 4MB→1MB) ragionando che lo schema (tabelle, trigger `items_history`, gate R1/R2/R3) esiste solo dentro il file e `server.py` non lo ricrea da codice.

**Mauro rilancia ("ma il db non lo cancelliamo?" / "cosa ti serve tenere lo schema?" / "io butterei via tutto")** — a quel punto lo schema SQL è stato estratto in un file di testo (`schema.sql`, verificato: si ricrea identico da script) e il `.db` binario cancellato. Poi Mauro chiude il ragionamento: **una futura riattivazione avrebbe comunque caratteristiche completamente diverse** — non ha senso tenere né schema né codice "nel dubbio" per un'architettura che non si riattiverà mai identica. **Cancellati definitivamente**: `server.py`, `schema.sql`. Nello stesso giro **trovato un altro pezzo morto sfuggito alla prima pulizia**: `chrome_debug.sh` (profilo Chrome porta 9222) non era di `browser_agent.py` (che si apre il proprio Chrome via `subprocess`, porta 9223, profilo separato) ma di `elon_pull.py`, già cancellato — rimosso anche quello. `requirements.txt` riscritto da zero con le sole dipendenze reali di `browser_agent.py` (python-dotenv, httpx, playwright).

**Esito finale**: `/mnt/ssd/data/vault-secondbrain/` (dati) **non esiste più**. `Dropbox/adrian/vault-secondbrain/` (codice) **non esiste più**: rinominata/spostata in `tools/browser-agent/` (convenzione già in uso per `tools/diario-editor/`), contiene solo `browser_agent.py` + `requirements.txt` + `venv/` — tool indipendente, nome non più legato al vault.

**Terza passata — due file morti sfuggiti anche alla seconda pulizia**: `scripts/vault_guardian.py` ed `elon_checklist.py` (già in cron-pausa dal 12/07) referenziavano entrambi `/mnt/ssd/data/vault-secondbrain/vault.db` ed `elon_pull.py`, tutti e due ormai cancellati — non avrebbero mai più potuto girare. Cancellati, righe cron corrispondenti eliminate del tutto (non solo commentate). `maintenance_check.py` verificato indipendente (non referenzia vault/elon_pull) — resta paused per conto suo, non toccato.

**Chiusura definitiva**: nessun file, servizio, regola di rete o riga di cron legata a vault/vault-mcp/Elon sopravvive in nessuna posizione (Nave, VPS, adrian-ops). `CLAUDE.md` aggiornato in ogni sezione che ne parlava. Thread di smantellamento vault completamente chiuso.

**Pulizia file morti post-spegnimento (29/07/2026).** Su richiesta di Mauro ("elimina anche i file che non servono più"), cancellati dopo verifica delle referenze: `vault-secondbrain/ingest.py` (pipeline ingestione vault, dipendenze mai installate), `inbox_watch.py` (daemon systemd già disabilitato dal 12/07, importava da ingest.py), `elon_pull.py` (loop Playwright↔Elon, bridge già sospeso dal 15/07, e ora Elon stesso cancellato da Mauro su claude.ai), `.env` locale (solo credenziali OAuth vault-mcp, morte), `/mnt/ssd/data/adrian-ops/oauth_tokens.json` (token dello stesso servizio spento). Riga cron `elon_pull` rimossa del tutto dal crontab (non solo commentata). `requirements.txt` sfoltito alle sole dipendenze di `server.py` (rimossi loguru/playwright/httpx/pytz/python-docx, usati solo dagli script cancellati). `browser_agent.py`/`chrome_debug.sh` **non toccati**: tool indipendente (vision agent), la sua chiave OpenRouter vive nel `.env` di root, non in quello cancellato. `server.py` confermato l'unico superstite di `vault-secondbrain/`, tenuto per eventuale riattivazione futura.

## Architettura "AgentBricks" (28/07/2026 — evoluzione della decisione sopra)

Nome coniato da Mauro, in coerenza con PowerBricks: agenti web leggeri e specializzati, ciascuno su un perimetro stretto, tutti sotto supervisione di Adrian — non un blocco monolitico.

**Principio generale — QUESTO è il "framework standard replicabile" richiesto da Mauro il 28/07 (confermato esplicitamente: "queste regole diventeranno il nostro framework")**: cattura raw → (eventuale sintesi fatta dall'agente stesso) → passa da Adrian per verifica → ingestione nell'archivio centrale, più i cinque guardrail non negoziabili più sotto. Se la sintesi non convince, si recupera il raw e si aggiusta — mai fidarsi ciecamente della sintesi di un agente esterno senza poter tornare alla fonte. Stesso principio già validato nel vecchio vault ("editor-by-exception": ADD/UPDATE/DELETE/NOOP, modifiche a rischio in staging). Non è specifico di diario/calendario/todo: è scritto per reggere qualunque attività futura si aggiunga al perimetro.

**Documenti non-.md** (PDF, email, allegati, ecc.): archiviati **as-is**, mai convertiti — con un file `.md` sidecar all'occorrenza per note/considerazioni/estratti. Riprende il pattern "strato annotazioni documenti" già abbozzato nel vecchio vault (documento originale intatto, pensiero-sulla-fonte separato).

**Formato dati**: tutto file `.md` stile Obsidian (non più SQLite/vault.db) — deciso, non solo "probabile". Motivo esplicito di Mauro (28/07): vuole poter far rimodellare la struttura su sua indicazione quando serve, senza la rigidità di uno schema DB — **non intende editare i file a mano lui stesso**, l'editing manuale resta lavoro di Adrian/agenti su sua richiesta. È anche il formato che qualunque agente, locale o web, sa leggere/scrivere senza connettore dedicato.

**I tre contenitori di "memoria finita" (punto di partenza, non tetto — Mauro 28/07: "le informazioni che andremo a gestire man mano si allargheranno")**:
- **Calendario**: fonte resta iPhone nativo (Calendar) per facilità d'inserimento — non si migra la creazione. Consultazione anche da PC ufficio via il piccolo editor Python (vedi sotto), sola lettura.
- **Todo**: fonte resta iPhone nativo (Reminders) come default, MA inserimento reso bidirezionale anche da PC ufficio (vedi sotto) — deciso 28/07, poi messo in pausa ("ci pensiamo con calma per i todo, iniziamo keep simple") — il diario procede prima, i todo si riprendono dopo.
- **Diario**: log di lavoro quotidiano (occasionalmente anche casa, per rinforzo abitudini — stesso file, distinto solo da tag inline). Non a voce, non a schermo mobile — testuale, da un piccolo editor Python su PC ufficio. Segue la stessa logica raw+sintesi, ma senza AI in fase di data entry (deciso 28/07: rischio troppo alto che un agente aggiunga letture interpretive invece di fatti — il diario è il posto più facile in cui rientrerebbe di nascosto il "pozzo senza fondo" abbandonato).

**Progettazione diario ed editor Python (28/07/2026, sessione dedicata)**:
- **Niente ChatGPT/agenti esterni per il diario** — scartato esplicitamente. Un file per giorno (`2026-07-28.md`, convenzione "daily notes"), frontmatter minimo (`date`, `tipo: diario`). Corpo: testo libero, cronologico, nessuna sezione forzata mentre si scrive (niente split raw/sintesi imposto in scrittura — quello valeva nel disegno generale prima di escludere l'AI dalla data entry del diario specificamente).
- **Tag inline stile Obsidian** (`#lavoro`, `#casa`) invece di un campo frontmatter — riusa la ricerca/filtro nativi di Obsidian senza costruire un sistema di tag a parte. Stesso meccanismo per distinguere diario lavoro/casa: un solo file, tag diverso per blocco, non due strutture parallele per un caso che è il 10%.
- **Due flussi di scrittura, complementari non alternativi**: (A) Mauro scrive direttamente (nell'editor Python, o in Obsidian) — eccezione dichiarata alla regola generale "non edito a mano", giustificata dalla bassa frizione di un diario di lavoro (dopo una discussione su "sola lettura vs eccezione" chiusa da Mauro come "lana caprina": il file è un file, non conta chi lo scrive); (B) Mauro detta/scrive ad Adrian (anche da telefono via `/remote_control`), che scrive il file.
- **Sede**: direttamente nella cartella dell'archivio centrale gestito da Adrian (Dropbox) — niente Google Drive, niente staging intermedio, niente copia. Un solo posto.
- **Ogni aggiunta di Adrian al file va marcata visivamente distinta** (es. blocco firmato "*Nota Adrian, [data]: ...*") — mai confondibile con quanto scritto da Mauro.
- **Ruolo AI limitato all'ingestione**, mai alla data entry: promemoria di disciplina se non si scrive da giorni, estrazione di cose durature (scadenze, impegni) senza interpretarle, ricerca/richiamo su richiesta, riepilogo periodico fattuale (mai giudizi tipo "sembra che..." — quello è il registro abbandonato). Cadenza di ingestione non ancora decisa.
- **Consultazione**: Obsidian sulla stessa cartella dell'archivio centrale — deciso 28/07 che l'archivio crescerà oltre il diario, quindi conviene usare Obsidian come lente su tutto fin dal primo file.

**Editor Python — spec raccolta 28/07 (non ancora costruito)**:
- **Decisione esplicita: app Python (PyQt6), non webapp.** Discusso e chiuso 28/07: una webapp richiederebbe un server sempre acceso — esattamente il modello del vecchio cockpit, smantellato il 15/07 perché troppo pesante da mantenere rispetto al valore. L'app desktop è coerente con Frank/admin MyICR Suite (stesso stack, stesso pattern "copia cartella e funziona"), gira offline, nessuna manutenzione server. L'unico vantaggio di una webapp (accesso multi-dispositivo) non serve: il diario resta "principalmente da PC ufficio", e per il resto c'è comunque il Flusso B (dettare ad Adrian).
- Piccolo pannello PyQt6 su PC ufficio, sullo stile di quelli già esistenti (pannello Frank, admin MyICR Suite) — istantaneo da aprire, non l'app Obsidian intera.
- **All'apertura**: crea il file di oggi con frontmatter se non esiste ancora nella cartella concordata.
- **Salvataggio**: NON in tempo reale a ogni tasto (scartato) — salva a intervalli di sicurezza (es. ogni 30-60s) e comunque alla chiusura. Meccanismo append-only: il contenuto già presente nel file all'apertura è "congelato" e mai riscritto, solo il blocco in corso viene aggiornato — così un salvataggio periodico non rischia mai di sovrascrivere note aggiunte da Adrian o entry precedenti.
- **Formato blocco**: timestamp automatico davanti a ogni blocco (es. `**14:32** — testo`), tag `#lavoro`/`#casa` scritti inline dall'utente.
- **Todo (bidirezionale, in pausa — "ci pensiamo con calma")**: idea raccolta ma non decisa nei dettagli — l'app non parlerebbe mai direttamente con iOS (impossibile da Windows), passerebbe sempre da un file-ponte che Adrian legge/scrive periodicamente: Adrian pubblica uno snapshot dei todo correnti (lettura), l'app scrive intenzioni di nuovo todo che Adrian poi crea davvero su Reminders (scrittura). Aperta la domanda se i tag `#lavoro`/`#casa` sui todo restano solo testo o diventano vere liste Reminders separate.
- **Calendario nell'editor**: solo consultazione, stesso meccanismo a snapshot (Adrian scrive periodicamente, l'app legge) — mai scrittura verso il calendario da lì.

**PRINCIPIO DI FRAMEWORK — Adrian stesso segue la logica AgentBricks (28/07/2026, richiamo esplicito di Mauro: "altrimenti fra un po' non riesci più a stare dietro a tutto")**: Adrian non deve accumulare il dettaglio di ogni contenitore nella propria memoria — solo **sintesi con le informazioni chiave**, mentre il dettaglio resta nei file stessi (i "mattoncini"). Si scende nel dettaglio (si rilegge il file vero) solo quando qualcosa non torna o serve verificare. Stesso principio già applicato con successo ai sottoagenti `powerbricks-expert`/`myicr-flussi-expert` (conoscenza dedicata e separata, consultata a perimetro) — ora esteso esplicitamente anche al modo in cui Adrian tiene la propria memoria sui contenitori AgentBricks (diario, todo, ecc.), man mano che crescono. **Primo passo concreto fatto (29/07/2026)**: le due knowledge base (`powerbricks-expert`, `myicr-flussi-expert`), prima isolate in `memory/`, sono state spostate (non copiate) in `archivio/Adrian/` — ora fanno parte dello stesso spazio Obsidian consultabile, invece di essere silos separati. Creato un nodo hub minimo `archivio/Adrian/Adrian.md` (tre righe + due wikilink) per agganciarle nel grafo ed evitare che restino orfane. Aggiornati i riferimenti ai nuovi percorsi in entrambe le definizioni dei sottoagenti (`.claude/agents/`) e in tutta la memoria che le citava. Nessuna duplicazione: sono le uniche copie, usate realmente da Adrian tramite i sottoagenti, non un mirror passivo. Decisione esplicita di Mauro: *"se non è da te utilizzabile no... sposterei solo quello che tu potresti realmente utilizzare (non duplicato)"* — criterio guida per qualunque futuro spostamento di questo tipo.

**Correzione struttura, stesso giorno**: prima versione era `archivio/adrian.md` + `archivio/knowledge/` allo stesso livello — Mauro ha corretto: meglio raggruppare per appartenenza, `archivio/Adrian/Adrian.md` + `archivio/Adrian/` dentro un'unica cartella (nome file coerente con la maiuscola della cartella). Scala meglio se in futuro altre entità/sottoagenti avranno le proprie basi di conoscenza (ognuna nella propria cartella, invece di riempire la radice di `archivio/` con cartelle sciolte). Wikilink nel nodo hub resi a nome breve (`[[powerbricks]]` invece di `[[knowledge/powerbricks]]`) — più robusti a futuri spostamenti di cartella.

**Convenzione hub-per-cartella generalizzata (29/07/2026)**: ogni cartella con più file ha un hub omonimo alla cartella (non `_index.md` generico — Obsidian etichetta i nodi del grafo per nome file, più `_index.md` sarebbero indistinguibili tra loro). Due varianti secondo se la collezione è fissa o cresce: hub con link in uscita (Adrian, poche voci fisse) vs elenco che si auto-aggiorna nell'hub (diario, un file al giorno — l'editor Python aggiunge da solo la riga sotto "## Giorni").

**Backlink nei singoli file-giorno, deciso e poi tolto (29/07/2026)**: inizialmente ogni giorno conteneva anche `Vedi anche: [[_i_diario|diario]]`, pensato come guardrail per un'AI che consultasse il file isolato senza altro contesto. Discussione con Mauro: in Obsidian un link crea connessione bidirezionale indipendentemente da chi linka chi, quindi con l'elenco esplicito nell'hub il backlink era ridondante nel grafo. Riformulato sul piano giusto (Mauro: "non dobbiamo pensare nella logica del grafo, le AI useranno i file direttamente") — anche lì, applicarlo con coerenza in ogni file sarebbe costato più del beneficio, dato lo scenario reale (mirror futuri porterebbero comunque la cartella intera con l'hub, sottoagenti hanno le proprie istruzioni dedicate). **Rimosso**, sostituito da una regola generale scritta una volta sola: `archivio/_i_archivio.md`, che ogni AI (Adrian, sottoagenti, AI web) dovrebbe leggere prima di consultare o scrivere nell'archivio — spiega formato, convenzione hub-per-cartella, tag vs appartenenza.

**CHIUSO 03/08/2026**: nomenclatura hub/indice rivista — omonimo-alla-cartella creava ambiguità nel file explorer (indistinguibile da un contenuto qualunque). Rinominati tutti con prefisso `_i_` + nome originale (es. `Adrian.md` → `_i_Adrian.md`), non `_index.md` generico: il nome del file resta l'etichetta del nodo nel grafo Obsidian, `_index` ovunque avrebbe reso i nodi indistinguibili tra loro (stesso motivo per cui si era scartato `_index.md` la prima volta, 29/07). Il prefisso underscore fa risaltare il file nel file explorer e lo ordina in cima.

**PRINCIPIO GENERALE DI FRAMEWORK — Mirror vs Inbox (28/07/2026, confermato: "la regola tiene")**: qualunque mirror/specchio dell'archivio verso un'AI web (es. Google Drive per ChatGPT) si separa sempre in due parti distinte, anche se fisicamente nella stessa cartella:
- **Mirror** = proiezione in sola lettura dell'archivio già verificato — l'AI web legge e consulta, non scrive mai qui.
- **Inbox** = cartella separata dove l'AI web può scrivere proposte (nuovi todo, bozze, ecc.) — ma nulla qui è verità finché Adrian non lo verifica e lo ingerisce.
**Regola non negoziabile**: le AI web passano SEMPRE da Adrian per la scrittura, mai un accesso diretto all'archivio o al mirror — indipendentemente da quanto un contenuto sembri a basso rischio (anche un todo). Questo evita di dover ridecidere caso per caso ogni volta che si aggiunge un contenitore o un'AI web nuova: la regola è unica e vale a prescindere dal contenuto.

**Divisione dei ruoli**:
- **Adrian**: pivot/supervisore centrale. Riceve raw+sintesi da tutti gli agenti web, verifica, decide l'ingestione nell'archivio centrale. Fa anche da ponte per i gap tecnici (es. ChatGPT non legge i Reminders iPhone — Adrian può scrivere uno snapshot periodico su Drive che ChatGPT legge invece dell'accesso diretto).
- **ChatGPT** (abbonamento che Mauro mantiene, riducendo Claude a un solo piano): candidato per calendario/todo (non più per il diario, escluso il 28/07 — vedi sotto). Vantaggio: voce molto fluida, funzione di pianificazione di attività periodiche in autonomia (da approfondire, possibile equivalente delle mie cron). **Limite noto**: non può salvare/usare connettori in modalità vocale (vedi [[project_test_secondbrain_voce]]).
- **Elon/vault.db**: in dismissione gentile, non colpo secco (vedi sopra). Le "letture strategiche" (dinamiche, inferenze politiche) si abbandonano; solo la memoria finita eventualmente sopravvive, migrata nei nuovi contenitori.

**Guardrail per agenti web (criterio di selezione, non solo buona pratica — Mauro 28/07: "poche ma molto chiare")**: bozza di cinque punti proposta da Adrian — scrivi sempre su file mai solo in chat; salva raw+sintesi non solo sintesi; perimetro fisso senza inferenze fuori scope; nessuna modifica distruttiva silenziosa; non è fonte di verità, propone soltanto (Adrian verifica e ingerisce). **Un agente che non si attiene in modo affidabile a queste regole si scarta senza cercare compromessi — non è idoneo al ruolo.** Testo definitivo delle istruzioni da scrivere in fase di implementazione, non ora.

**PRINCIPIO — fonte di verità unica, no duplicazioni (29/07/2026, Mauro)**: una volta che un'informazione è migrata dentro `archivio/`, quello diventa la fonte di verità — non si lasciano copie nella posizione precedente (già applicato: ogni spostamento fatto oggi è stato `git mv`, mai copia). Se la sintesi fatta in fase di migrazione rischia di perdere sfumature rispetto al raw originale, si usa la tecnica già concordata per gli agenti web: un **bidone raw** dove recuperare il dettaglio se davvero serve — può stare dentro `archivio/` o fuori, da valutare caso per caso quando si arriva alla migrazione vault→Mauro/. Vale soprattutto per la migrazione futura di finanze/casa/lavoro dal vecchio vault.db: se un domani si scopre che la sintesi ha perso qualcosa, si va a ripescare dal raw, non si tiene una copia parallela "per sicurezza" nel frattempo.

**Struttura archivio consolidata (29/07/2026)** — vedi `archivio/_i_archivio.md` per il quadro completo: due proprietari paralleli (`Adrian/`, `Mauro/`) più `diario/`, ciascuno con hub-per-cartella. Verificata la navigabilità con un agente a mente fresca (Explore, senza contesto pregresso): struttura regge, nessun link rotto, unico neo aggiustato — `adrian_state.md` presupponeva conoscenza dell'ecosistema tecnico esterno, ora `archivio.md` rimanda esplicitamente a `CLAUDE.md` per quello.

**Non ancora deciso**:
- Meccanica esatta con cui gli agenti web "consegnano" a Adrian (oggi: salvano dove è più comodo/sicuro per loro — es. Drive — poi si costruiranno connettori per riportare l'informazione al sistema centrale)
- Timeline di dismissione vault.db/vault-mcp
- Todo: come colmare il gap ChatGPT↔Reminders in modo più solido dello snapshot manuale, se necessario

Vedi anche [[project_test_secondbrain_voce]] per il test che ha portato a questa decisione.

**Revisione scope "letture strategiche" (29/07/2026, Mauro)**: la decisione del 27/07 di abbandonare le letture strategiche è stata rivista. Mauro ritiene ora che il problema fosse la disciplina di distillazione di Elon, non il contenuto in sé — "per fare pulizia c'è sempre tempo". Decisione: **migrare AS-IS anche le letture strategiche** (persone/dinamiche/episodi), non filtrare fatto-vs-lettura in fase di migrazione. Adrian aveva inizialmente proposto di trattare questo materiale (profilazione di colleghi reali) con cautela di livello `_secrets`; Mauro ha corretto ("cautela esagerata") e Adrian ha concordato: il rischio è paragonabile alle voci `#lavoro` già presenti nel diario normale, non a una credenziale — va in `Mauro/lavoro.md` con la protezione standard dell'archivio.

**Migrazione vault→Mauro/, prima tranche completata (29/07/2026)**: creati [[finanze]] e [[_i_palmanova-213a|palmanova-213a]] (rinominato da `casa` il 29/07 per disambiguare dalle altre proprietà — Milano Due, via Palmanova 131), arricchito [[_i_famiglia|famiglia]] con i nodi vault.db `nadia`/`samuele`/`francesco`/`mario`/`concetta`. Nodi vault.db corrispondenti **cancellati** (DELETE reale, confermato da Mauro): `patrimonio`, `portafoglio-fineco`, `allocazione-post-palmanova`, `vendita-palmanova`, `incontro-tempocasa-15-07`, `nadia`, `samuele`, `francesco`, `mario`, `concetta`. Vault.db passato da 75 a 65 nodi. Nota tecnica disclosata prima di procedere: `items_history` cattura solo UPDATE su body/meta/file/type, non DELETE — la rete di sicurezza reale è restic/pCloud, non l'audit trail interno.

**Migrazione dominio lavoro, completata (29/07/2026)**: creato [[_i_lavoro|lavoro]] — 40 nodi persona/organizzazione/dinamica/episodio/progetto migrati **AS-IS** (persone, riorg MFE luglio 2026 con tutte le letture "degradati"/scenari (a)(b)(c), Asse Marcello-Simona, Canale Poletti, Frattura Marcello-Sonia, Pacchetto emergenza ICR, Report Gemma, ecc.), organizzati in sezioni (ruolo/postura, persone, struttura organizzativa, dinamiche, episodi, progetti/strumenti) invece che come nodi-grafo separati — le liste `## Sinapsi`/`## Fili` del vault sono state ricondotte a prosa dentro le sezioni pertinenti. Nodi vault.db cancellati (DELETE reale, confermato): tutti e 40, verificato 40/40 senza anomalie. Vault.db passato da 65 a 24 nodi.

**Migrazione "memoria finita" (famiglia/finanze/casa/lavoro) COMPLETATA (29/07/2026).** Vault.db passato da 75 nodi iniziali a 24, poi a **0**: i 24 nodi meta/architettura-di-sistema residui (fusione-agenti, consolidamento-notturno, stato-sistema, policy-decadimento, spegnimento-supabase, decisione-motore-vault, distillazione-automatica, graphviewer-dsl, hermes-agent, loop-adrian-elon, push-loop-elon-adrian, mappe-scratch-dinamiche, nl-query-prototype, strato-annotazioni, vault-cli-bill, architettura-storage, la-nave, resilienza-la-nave, adrian, elon, bill, cockpit, archivio, fusione-bill-adrian) sono stati **letti in sintesi da Adrian, mostrati a Mauro, e cancellati senza migrazione** — decisione di Mauro (29/07): non fatti su di lui, descrivono un'architettura già smontata (Bill assorbito, cockpit rimosso, Supabase congelato, LanceDB sospeso), già ben coperti dalla narrazione di questo stesso file. Unico spunto valutato e scartato: la decisione UPS/resilienza-la-nave — Mauro conferma di non volerlo prendere in considerazione, nodo cancellato senza riporto altrove.

**Vault.db azzerato del tutto (29/07/2026): 0 righe nella tabella `items`.** Ultimi due nodi (`kernel-elon` — mandato/costituzione operativa di Elon, e `elon-memory` — suo diario di lavoro/log di sessione) letti, riassunti a Mauro e cancellati senza migrazione: non erano memoria-di-fatto su Mauro ma configurazione e diario interno dell'agente stesso, già superati (architettura descritta tutta smontata) o già confluiti altrove (i thread riorg-MFE/Palmanova sono dentro `lavoro.md`/`casa.md`). Recuperabile da restic/pCloud in caso di ripensamento. Thread "migrazione memoria finita" **chiuso**.

**Spegnimento vault-mcp COMPLETATO (29/07/2026).** Su richiesta di Mauro ("spegniamo tutto adesso"): `vault-mcp.service` fermato e disabilitato su systemd (Nave); regola firewall `8765/tcp` rimossa (ufw); blocco `vault.privcloud.dev` rimosso dal Caddyfile sul VPS Avamposto (backup del file salvato prima della modifica, Caddy ricaricato e validato senza errori). **Codice (`vault-secondbrain/server.py`, 479 righe, gate di validazione R1/R2/R3 + trigger `items_history` + tool `patch_item`) lasciato intatto su disco** — non buttato: costa niente tenerlo, e ricostruirlo identico da zero non sarebbe banale se mai servisse riattivarlo. Nessuna superficie esposta residua per il vault.

**Elon cancellato (29/07/2026).** Mauro ha eliminato il progetto Elon da claude.ai — non esiste più, nessun destino da decidere. Thread completamente chiuso: vault smantellato, agente cancellato, nessun residuo da nessuna parte.

## Roadmap / idee parcheggiate

Appunti leggeri da conversazioni strategiche — non decisioni, non progetti avviati, solo mappa mentale per non perdere il filo tra una sessione e l'altra (vedi [[feedback_comunicazione_mauro]], sezione "Modalità sounding board strategico"). Una riga ciascuna, si espande solo se/quando si passa a scoping vero.

- **(30/07/2026) Framework a due strati, generale per qualsiasi progetto**: strato dati (`.md`/archivio, già fatto) + strato interfaccia (webapp, solo quando serve interazione vera — non di default, per non ricreare la complessità appena smontata con cockpit/vault-mcp).
- **(30/07/2026) PowerBricks LLM come biglietto da visita esterno**: query naturali dal telefono ("quanti film ha trasmesso C5 in prime time nel 2026?") come dimostrazione concreta di cosa Mauro ha costruito con l'AI, se mai gli venisse chiesto fuori Mediaset. Uso interno stealth in emergenza resta "io la uso" (coerente con la postura da regista silenzioso), non distribuzione a terzi.
- **(30/07/2026) Lavoro sui due subagenti (`data-expert`, `flussi-expert` — rinominati il 04/08/2026 da `powerbricks-expert`/`myicr-flussi-expert`) nelle prossime settimane** — non ancora scopato: verificato oggi lo stato (KB + istruzioni), il punto più concreto già identificato è il fix "canale secondario DVB-T" in `flussi.md` (sezione "Domande aperte").