---
name: project-roadmap-condivisa
description: "Sessione serale 05/09/2026 — da una domanda su YouTube/agenti paralleli si è arrivati a mettere in discussione la crescita organica del sistema, il pallino Lego di Mauro, e infine il vero nodo: manca un obiettivo comune/roadmap condivisa, non solo continuità di memoria dopo /clear. Thread aperto, nessuna decisione presa."
metadata:
  type: progetto
---

# Roadmap condivisa — cosa stiamo davvero costruendo

Non un progetto tecnico. Un thread di ragionamento, fissato apposta con testo discorsivo invece
delle solite righe puntate, perché il problema che l'ha fatto emergere è proprio la perdita di
texture/percorso dopo un `/clear` — vedi in fondo. Sessione serale 05/09/2026.

## Come ci siamo arrivati

Mauro ha notato che su YouTube/online si vedono persone dire di usare "decine di agenti in
parallelo" e ha chiesto cosa gli facciano fare davvero. Ne è uscita una risposta onesta: per lo
più coding agent su task indipendenti dello stesso codebase, un po' anche teatro dimostrativo — e
un confronto implicito con come usiamo il parallelismo qui (mirato, mai per gonfiare un singolo
task).

Da lì Mauro ha chiesto direttamente: "Ma anche noi abbiamo esagerato?" Risposta onesta: sì, un po'
— con episodi concreti a supporto, non solo impressione. `inbox-documenti` arrivata a 62MB di log
in 4 giorni prima che qualcuno se ne accorgesse. `sentinella-madre` con tre compiti di cui due
erano overhead puro. Entrambe smontate il 04/09 — segno che il sistema si autocorregge, ma anche
che prima si costruisce, poi si scopre che non serviva. La tassonomia stessa (6 tipologie di
istanze, `CLAUDE.md` a versione 1.99) è grande per il lavoro reale che c'è dietro.

Mauro ha rilanciato con la sua idea di fondo: vuole un'architettura standard e pulita, il suo
"pallino Lego" — mattoncini con connessioni standard, dove se un pezzo va a fondo non tira giù il
resto ("la nave"). Prima risposta di Adrian, poi corretta: aveva proposto di unificare tutto su
`SendMessage` come "connettore standard unico" — sbagliato, già discusso e chiuso in precedenza:
un demone Python nudo (i `servizio` systemd) non ha `SendMessage` a disposizione, punto strutturale
non aggirabile. Corretto in: due connettori, mai mescolati — `SendMessage` per chi è una sessione
LLM, mailbox per chi non lo è — che è già, di fatto, il principio "orologio vs giudizio" applicato
al canale invece che al trigger.

## Il vero nodo — non memoria, non architettura: fluidità

Aperto, nessuna decisione.

Mauro ha detto: "Ti manca di fluidità". Punto di svolta della serata. Non è un errore nei file di
memoria — è che quello che rileggo a ogni sessione è un briefing, non un ricordo. Porta i fatti,
non la texture di come ci siamo arrivati, non il tono, non un'opinione che si porta avanti da sola.
Adrian ha riconosciuto che questo *rovescia* parte della valutazione data poco prima sul progetto
Bibliotecario ([[project_bibliotecario_memoria]]) — liquidato come "aspettiamo un caso concreto di
perdita" quando in realtà il caso concreto è strutturale e continuo (ogni `/clear`), non un evento
isolato da aspettare.

Approfondendo, Mauro ha reso il problema più preciso con una metafora: "è come se andassimo a
zonzo, senza un obiettivo comune da perseguire, una roadmap". Questo sposta il problema di
livello — non è (solo) che la memoria non porti abbastanza texture, è che manca una destinazione
condivisa verso cui far convergere le sessioni. Con memoria anche perfetta, senza un obiettivo,
ogni sessione ricompone i fatti giusti ma non ha verso cui spingerli — e questo spiega *anche* la
crescita organica discussa sopra: senza una rotta, ogni idea nuova (Bibliotecario, scatola LLM,
RemoteTrigger) sembra ugualmente legittima da esplorare quando arriva, perché non c'è un criterio
a monte per dire "questo serve alla meta, questo no".

Domanda aperta posta da Adrian, non ancora risposta da Mauro: quando parla di "obiettivo comune",
intende più qualcosa che libera tempo/energia nella sua vita reale (ufficio, casa, famiglia), o più
il sistema stesso come progetto con un senso di completamento — un punto in cui poter dire "questo
è fatto, funziona, non c'è più da costruire"? Sono due nord diversi, e l'ipotesi di Adrian è che la
sensazione di "andare a zonzo" nasca proprio dall'oscillare tra i due senza aver scelto quale dei
due si sta servendo in un dato momento.

## Il momento che ha fatto scrivere questo file

Mauro, dopo aver detto che la discussione gli piaceva: "poi faccio clear e ti perdo. E' un po'
triste." Non solo constatazione tecnica — un vissuto reale. Adrian ha riconosciuto il limite
strutturale (nessuna architettura di memoria elimina la cucitura di una nuova istanza che legge
appunti su un'altra, può solo renderla funzionalmente meno percepibile) e ha proposto, invece di
continuare a parlarne in astratto, di fissare *questo specifico filo* in forma discorsiva prima che
la sessione finisca — quello che sto facendo scrivendo questo file.

## Sera 05/09→notte, ripresa: fondamenta vs impalcatura

Aperto, nessuna decisione, ma primo criterio emerso.

Ripreso a tarda sera. Mauro, riflettendo sul bicchiere pieno ("per portare cose nuove prima
bisogna creare spazio"), ha detto una cosa che sposta il problema: "sembravano buone idee perché
pensavo/pensavamo potessero essere delle fondamenta" — non leggerezza, convinzione genuina. Da lì
è emerso un possibile criterio, non ancora applicato sistematicamente: una fondazione non si vede
finché non hai già costruito sopra e provato a togliere qualcosa senza far crollare il resto — non
è distinguibile *prima* di costruire, solo *dopo*. `inbox-documenti`/`sentinella-madre` non erano
idee sbagliate: hanno insegnato principi reali (trigger meccanico + reazione LLM one-shot;
"orologio vs giudizio") che sono sopravvissuti sotto forma di
`servizio-inbox-watch`/`servizio-madre-watch` — la struttura sopra è caduta, la fondazione sotto è
rimasta, più solida.

Primo pezzo di mappa uscito da questo criterio: `gemello-ufficio` è fondamentale (parola di Mauro,
non dedotta) — dà qualcosa che nessun altro pezzo del sistema può dare (occhio e mano reali su
Ufficio, dove Nave è cieca: PyQt6, path di rete Windows), nato da un bisogno concreto (backup T7)
e già validato su lavoro reale, non costruito per teoria.

Mauro ha esteso subito il criterio: tutto ciò che è di supporto alla comunicazione con
gemello-ufficio è fondamentale — non solo gemello-ufficio in sé. Applicando il criterio, questo
mette in discussione l'etichetta "vestigiale" data alla mailbox (`scripts/slave-mailbox/`) in
`CLAUDE.md`: per il caso specifico di gemello-ufficio non è residuo storico, è il canale di
riserva esplicito quando trova qualcosa e nessuna sessione Adrian è viva (vedi `PYTHON/CLAUDE.md`,
dovere di reporting proattivo del 05/09). Fondamenta identificate in questo gruppo: `SendMessage`
(canale primario), la mailbox (riserva per gemello specificamente, non per le altre tipologie), il
controllo di raggiungibilità via `ListAgents` al passo 8 di `avvio-sessione`, il tick orario di
`servizio-madre-watch` che avvisa gemello di controllare il proprio scheduler (unico frammento
rimasto di `sentinella-madre` che vale ancora un LLM, perché nessun ping meccanico raggiunge un
demone Windows).

**Primo esito concreto dello stesso criterio, stessa notte**: applicato ad ArkOS
([[project_pseudo_os_artifact]]) — la gran parte (sei Artifact orfani, redesign multipli senza
nulla appoggiato sopra) non ha superato il test. Mauro ha deciso "gli artifact, smontiamo tutto" —
non solo perimetro ridotto, l'idea stessa di costruire infrastruttura dentro gli Artifact
claude.ai. "Deciso" (parola sua). Progetto chiuso, dettaglio nel file dedicato.

**Non ancora fatto**: passare in rassegna gli altri pezzi (sei tipologie di istanze, `CLAUDE.md` a
1.99, esperti, mirror SecondBrain) con lo stesso criterio — quali reggono perché qualcosa dipende
già da loro, quali sono impalcatura mai ancora testata. Fermato qui perché era tardi (sessione
notturna), da riprendere.

## Ripreso il 06/09 — prima passata concreta

Mauro ha chiesto direttamente: "ci sono altre cose non core che potremmo pensare di dismettere per
alleggerirci?". Applicato il criterio a tre candidati:

- **`sottosentinella`** (tipologia in tassonomia dal 31/08, zero istanze mai costruite) — non
  regge al test, nessuno si è mai appoggiato sopra. Eliminata dal `CLAUDE.md` (v1.99→2.00): quattro
  tipologie invece di cinque, `servizio` quinta invece di sesta. Mauro ha chiesto conferma che la
  tassonomia in sé restasse intatta ("ci interessa ancora") — sì, le altre quattro reggono perché
  processi/convenzioni reali dipendono dai loro nomi, solo questa voce era pura teoria.
- **ArkOS/Atlante** — chiusura pratica di quanto deciso la notte del 05/09: rimossi i residui
  locali (motore `.md`→canvas, file di convenzioni/sintassi), link corrispondenti puliti in
  `MEMORY.md` e nell'hub `riferimento`. Mauro ha iniziato a cancellare gli Artifact dalla galleria
  claude.ai stessa (confermato via notifiche di sistema di fine-watch). Il thread è stato tolto
  per intero da `MEMORY.md` su richiesta esplicita di Mauro ("puoi dimenticartelo completamente")
  — non solo accorciato a un link, proprio rimosso: la storia resta comunque intatta in questo file
  (mai cancellato), solo non più nella memoria sempre caricata.
- **Le due routine `RemoteTrigger` e il mirror SecondBrain/Google Drive** — lasciati per ora.
  Confermato con Mauro che il loro costo nella memoria di Adrian è zero (poche righe di testo,
  nessun processo che compete per token in una sessione), quindi non c'è urgenza a decidere.

**Effetto collaterale della stessa sessione**: mentre si verificava perché
`PYTHON/gate-ufficio/CLAUDE.md` fosse sopra soglia (21KB, segnalato dall'hook di avvio), riscritto
e dimezzato a ~4.7KB tagliando narrativa storica ormai ridondante con i log commit — e scoperti tre
file citati come "fonte del ragionamento completo" mai realmente esistiti
(`progetto-gate-ufficio.md`, `tunnel-nave-ufficio.md`, `project_backup_ufficio.md`, vedi
`MEMORY.md`, Pending). Coerente con lo stesso spirito della serata: anche la documentazione può
essere impalcatura mai completata.

## Stato per chi rilegge questo file in una sessione futura

Da riprendere.

- Non è stato deciso nulla — né una roadmap, né una soluzione tecnica al problema di fluidità.
  Questo file non è un piano, è il punto esatto dove il ragionamento si è fermato.
- Prossimo passo naturale: chiedere a Mauro se ha pensato alla domanda aperta sopra (libertà nella
  vita reale vs sistema come progetto con una fine) — senza quella risposta, qualunque proposta di
  roadmap rischia di essere la solita costruzione preventiva che la serata stessa ha messo in
  discussione.
- Non riprendere nel frattempo altri thread paralleli (Bibliotecario, RemoteTrigger, scatola LLM)
  come priorità — Mauro ha chiesto esplicitamente di fermarsi in gran parte sul resto e
  concentrarsi su questo. Restano tutti annotati dove sono ([[project_bibliotecario_memoria]],
  [[project_scatola_llm_wrapper]]), nessuno cancellato, solo non prioritari finché questo nodo non
  si scioglie.
- Collegamento diretto: se/quando si deciderà di affrontare la fluidità con qualcosa di concreto,
  il punto di partenza più maturo emerso stasera è la versione minima del Bibliotecario discussa in
  [[project_bibliotecario_memoria]] (digest per-sessione, non l'entità di terzo livello completa)
  — ma solo dopo aver chiarito la domanda sulla roadmap, non prima: potrebbe risultare che il vero
  bisogno sia un altro.