---
name: project-standard-esperti
description: "Canvas di lavoro (10/09/2026, non deciso) — a monte di expert-myicr, fissare lo standard generale che ogni esperto dovrebbe seguire: gestione della memoria, composizione/dipendenza tra esperti, effettivo alleggerimento di Adrian."
metadata:
  type: progetto
---

# Standard esperti — memoria, composizione, alleggerimento di Adrian

Nato il 10/09/2026 durante la discussione su un quarto esperto (`expert-myicr`, vedi
[[project_expert_myicr]]): prima di decidere quello specifico, Mauro ha chiesto di fissare a monte
alcuni concetti che valgono per la classe "esperti" in generale, non solo per il prossimo. Canvas
di lavoro — nessuna decisione presa, si ragiona insieme.

## Perché non basta partire da `expert-myicr` e basta

`expert-myicr` (se nasce) non sarebbe isolato: il suo dominio (comportamento applicativo di
MyICR_Suite/PowerBricks) tocca dati che `expert-data` conosce (semantica) e pipeline che
`expert-flussi` conosce (provenienza/trasformazioni). Una domanda reale a `expert-myicr` potrebbe
richiedere di sapere anche cose che oggi vivono solo negli altri due. Decidere lo standard solo
guardando il quarto esperto rischierebbe di fissare un pattern che poi non regge quando servirà un
quinto.

## Cosa osserviamo oggi nei tre esperti esistenti (descrittivo, non ancora "standard dichiarato")

Ricostruito osservando `expert-domotica`/`expert-data`/`expert-flussi` (10/09/2026), mai scritto
prima come regola esplicita:

- **`CLAUDE.md`** nella cartella slave-sentinel (`scripts/slave-sentinels/<nome>/`) — ruolo,
  protocollo, dove può guardare, obbligo di segnalazione. Cambia raramente, non porta conoscenza
  di dominio.
- **Base di conoscenza separata** in `archivio/Adrian/agenti/<nome>.md` (es. `flussi-expert.md`,
  `data-expert.md`) — qui vive il dominio vero: fatti, gotcha, domande aperte, ciascuno taggato
  `[CONFERMATO]`/`[IPOTESI]`. Letta dall'esperto a ogni avvio.
- **Un solo scrittore**: l'esperto è sola lettura anche verso la propria base di conoscenza — non
  se la aggiorna da solo. Quando trova qualcosa, lo segnala via `SendMessage` ad Adrian, che decide
  se/come integrarlo. Nessun `MEMORY.md` operativo per l'esperto — non gestisce priorità/thread
  propri, solo domande sincrone puntuali.
- `.session_id` per continuità di sessione (risparmio, non serve rileggere tutto se la sessione
  non è scaduta) — infrastrutturale, non memoria di dominio.

Questo è quanto emerge *osservando* i tre esperti attuali — non è detto sia la risposta giusta,
solo il punto di partenza per la discussione.

## Domande aperte da affrontare insieme

- **Composizione tra esperti**: se `expert-myicr` avesse bisogno di una risposta che sa già
  `expert-flussi` o `expert-data`, come si integra? Opzioni da esplorare, nessuna scelta ancora:
  - Adrian resta sempre l'hub — pone la domanda a ciascun esperto separatamente e sintetizza lui
    la risposta finale, nessuna comunicazione diretta tra esperti.
  - Gli esperti si parlano direttamente tra loro (`SendMessage` esperto→esperto) — da verificare
    se è compatibile con la regola costituzionale "nessun agente parla direttamente a un altro
    senza Mauro come bridge", che oggi sembra pensata per altri casi (gemello-ufficio, sentinelle
    verso Mauro) più che per una consultazione interna tra esperti di sola lettura.
  - Un esperto "eredita"/duplica parte della conoscenza di un altro nella propria KB — rischio di
    divergenza nel tempo se le due copie non restano sincronizzate.

  **(10/09) Indicazione di Mauro, da approfondire con calma**: niente `SendMessage`
  esperto→esperto diretto — "tu e gemello dovrete fare da pivot". Adrian e `gemello-ufficio` fanno
  da hub tra gli esperti, non gli esperti tra loro. Domande aperte lasciate esplicitamente da
  chiarire in seguito, non ancora risposte:
  - **Chi dei due pivot, e quando?** Due letture possibili, nessuna confermata: (a) Adrian resta
    il pivot di default come oggi, `gemello-ufficio` entra in gioco solo quando la domanda
    richiede la sua visibilità specifica (es. verifica live su Ufficio/PyQt6) — un pivot con
    competenza diversa, non equivalente; (b) più simmetrico, entrambi possono fare da hub
    indipendentemente a seconda di chi ha in mano il compito in quel momento.
  - Se `gemello-ufficio` diventa un pivot vero (non solo esecutore pilotato), che rapporto ha con
    gli esperti che vivono su Nave — li raggiunge lui stesso via `SendMessage`/`ListAgents` cross-
    macchina (già confermato funzionante), o passa comunque da Adrian per quello?
  - Come si concilia con l'idea di gerarchia proposta sopra (`expert-myicr` come nodo che orchestra
    sotto-esperti) — se niente esperto→esperto diretto, `expert-myicr` non potrebbe comunque
    "chiamare" `expert-flussi`/`expert-data` da solo: la gerarchia si realizzerebbe sempre passando
    dal pivot, non come vera comunicazione diretta tra nodi dell'albero.
- **Alleggerimento reale di Adrian**: cosa smetterebbe davvero Adrian di dover portare a mente, e
  cosa resta comunque suo compito (sintesi finale, giudizio, decisione)? Il rischio da evitare è
  costruire un quarto esperto che sposta solo il posto dove l'informazione vive, senza ridurre
  il carico cognitivo reale di orchestrarli.
- **Perimetro/confini**, già in parte discussi nel canvas specifico di `expert-myicr` ma rilevanti
  anche qui in generale: quanto un esperto deve restare stretto al proprio dominio prima di dover
  chiedere a un altro, invece di espandersi per coprire da solo i casi limite.

## Proposta di Mauro (10/09) — gerarchia di esperti, non solo hub piatto

Mauro rilancia sulla domanda "composizione tra esperti" sopra: `expert-myicr`, se nasce, sarà
enorme — si occuperà di tutto il codice degli applicativi del mondo lavoro, non solo
MyICR_Suite/PowerBricks. Per questo propone due cose insieme:

1. `expert-flussi` ed `expert-data` diventano subordinati di `expert-myicr` (Mauro dice
   "slave", nel senso di gerarchicamente sotto — non la tipologia tecnica `slave` della
   tassonomia, che è un'altra cosa: un'istanza temporanea che muore dopo un compito. Da
   chiarire con un nome diverso quando si formalizza, per non sovrapporre i due significati).
2. Gli applicativi grandi al suo interno (es. MediaTrack) avrebbero a loro volta un proprio
   esperto specializzato sotto `expert-myicr` — altrimenti `expert-myicr` non riuscirebbe a
   tenere il filo di tutto da solo.

Risponde di fatto alla domanda di composizione sopra scegliendo l'opzione "gli esperti si parlano
direttamente tra loro", ma non a coppie isolate — come vera gerarchia ad albero:
`expert-myicr` come nodo intermedio che orchestra i propri sotto-esperti, non solo Adrian che
smista tra pari.

### Punti da chiarire prima di considerarla decisa (Adrian, valutazione critica)

- **Terminologia**: "slave" qui è usato nel senso comune ("sotto di"), non nel senso tecnico
  della tassonomia (istanza temporanea one-shot). Va trovato un nome che non collida — es.
  "sotto-esperto" o semplicemente "esperto subordinato" — prima di scrivere qualunque `CLAUDE.md`.
- **`expert-flussi`/`expert-data` restano raggiungibili direttamente da Adrian, o solo tramite
  `expert-myicr` d'ora in poi?** Se il loro dominio (semantica dati, provenienza pipeline) serve
  anche per domande che non riguardano il comportamento applicativo, avrebbe senso restassero
  raggiungibili su entrambe le vie, non "assorbiti" in una sola gerarchia.
- **Meccanismo di comunicazione tra esperti**: questa proposta richiede `SendMessage`
  esperto→esperto per davvero (non solo Adrian→esperto) — la domanda costituzionale già aperta
  sopra ("nessun agente parla direttamente a un altro senza Mauro come bridge") va risolta prima
  di costruire, non scoperta strada facendo.
- **Costo/moltiplicazione di istanze persistenti**: ogni esperto in più è una sessione `--bg`
  sempre esistente (anche se `idle` tra una domanda e l'altra). Un albero con `expert-myicr` +
  `expert-flussi`/`expert-data` sotto + un esperto per ogni applicativo grande (MediaTrack e
  potenzialmente altri) moltiplica il numero di istanze da tenere in vita/monitorare — proprio il
  tipo di crescita che ha già causato il problema del 04/09 (sessioni che non ruotano mai, vedi
  `archivio/Adrian/progetti/project_servizi_meccanici.md`). Non un motivo per scartare l'idea, ma
  da dimensionare con attenzione, non dare per scontato che "un esperto in più" sia sempre a costo
  marginale zero.
- **Non costruire l'albero tutto insieme a tavolino**: coerente col criterio "fondamenta vs
  impalcatura" già maturato nel thread roadmap ([[project_roadmap_condivisa]]) — una fondazione si
  vede solo *dopo* aver costruito sopra e provato a togliere qualcosa senza far crollare il resto.
  Suggerimento: partire da `expert-myicr` solo, osservare empiricamente dove non riesce a tenere
  il filo, e solo lì staccare un sotto-esperto dedicato (es. MediaTrack) — non presupporre a monte
  quali applicativi lo meriteranno.

## Generalizzazione di Mauro (10/09) — i gemelli come genitori naturali degli esperti

Idea che si sta formando in Mauro, emersa dalla stessa discussione: non solo `expert-myicr` come
nodo che orchestra sotto-esperti — più in generale, **i gemelli** (`gemello-ufficio`,
l'eventuale `gemello-nave`, vedi [[project_gemello_nave]]) potrebbero avere sotto di loro gli
esperti di dominio, ciascuno raggruppato sotto il gemello più vicino operativamente al suo
dominio, invece che tutti appesi direttamente ad Adrian.

Risolverebbe in modo più naturale la domanda "chi è il pivot" lasciata aperta sopra: non "Adrian
o `gemello-ufficio` a seconda del momento", ma "qualunque esperto è raggiunto tramite il gemello
che ne possiede il dominio". Esempio plausibile (non deciso): `expert-myicr` (codice
applicativo Ufficio) sotto `gemello-ufficio`, che ha visibilità diretta sulla GUI reale;
`expert-domotica`/`expert-data`/`expert-flussi` (infrastruttura e dati visti da Nave) sotto
`gemello-nave`.

**Complicazione tecnica reale, non solo di principio**: gli esperti oggi possono vivere *solo* su
Nave (il CLI standalone non è installato su Ufficio, per scelta — vedi Costituzione, sezione
Autonomia). Se `expert-myicr` finisse "sotto" `gemello-ufficio` concettualmente ma dovesse comunque
girare fisicamente su Nave, `gemello-ufficio` dovrebbe raggiungerlo con un canale cross-macchina —
e siccome `gemello-ufficio` ha lo stesso vincolo di secondo account che gli impedisce
`SendMessage`/`ListAgents` anche verso Adrian, raggiungere un esperto su Nave richiederebbe
probabilmente un altro ponte mailbox, non un collegamento diretto. "Genitore concettuale" e "dove
gira fisicamente" potrebbero non coincidere, e questo va chiarito prima di assegnare esperti ai
gemelli, non dopo.

Non scoped, solo registrato — generalizzazione naturale della proposta sopra, da riprendere
insieme a tutte le altre domande aperte di composizione.

## Un livello ancora più giù — servizi meccanici sotto gli esperti (10/09, stesso filo)

Mauro estende ulteriormente: anche i `servizio-*` meccanici potrebbero stare sotto un esperto,
non solo genericamente sotto un gemello/Adrian. Es. un futuro `servizio-domotica-watch` sotto
`expert-domotica`, `servizio-gate-watch` sotto `expert-flussi`, un eventuale
`servizio-inbox-watch` riallineato sotto `expert-myicr` (coerente con l'idea già registrata in
[[project_servizi_meccanici]] su un expert dedicato alla classificazione documenti). L'albero
completo diventerebbe: Adrian → gemelli → esperti → servizi meccanici, ciascun livello filtra
prima di passare su.

**Bivio architetturale da sciogliere, non scontato**: questo tocca la natura stessa degli esperti
di oggi, che sono deliberatamente **passivi** — nessun `Monitor` armato per design, nessun evento
da sorvegliare, motivo per cui possono scadere/andare `exited` senza che sia un problema (vedi
`claude-cli-headless.md`, sezione Terza classe). Due letture possibili, molto diverse in costo e
comportamento:

- **Modello "pull" (consultivo, coerente con oggi)**: l'esperto non sorveglia nulla di proprio
  iniziativa — quando viene interrogato (dal suo gemello o da Adrian), consulta anche lo storico
  recente dei `servizio-*` nel proprio dominio come fonte in più, insieme alla propria KB. Nessun
  Monitor, nessun costo aggiuntivo da fermo, stesso design di oggi solo con un'altra fonte da
  leggere su richiesta.
- **Modello "push" (l'esperto sorveglia attivamente)**: l'esperto arma un proprio `Monitor` sui
  `servizio-*` del suo dominio e reagisce agli eventi in autonomia, senza aspettare una domanda.
  Più reattivo, ma di fatto trasforma l'esperto in un ibrido esperto-sentinella — reintroduce
  proprio il tipo di costo (sessione che deve restare viva, monitorare, non scadere mai) che la
  conversione sentinelle→servizi del 04/09 aveva eliminato (vedi [[project_servizi_meccanici]]).

Non scoped — il modello "pull" sembra il più coerente con tutto quanto deciso finora (nessun
esperto ha mai avuto un ruolo attivo), ma non è stato scelto esplicitamente, solo osservato come
l'opzione a minor rischio. Da confermare con Mauro prima di dare per scontato quale dei due si
intende.

## Collegamento con `expert-myicr`

[[project_expert_myicr]] resta il canvas specifico per il quarto esperto (nome, perimetro
applicativo, dove vive) — utile leggerlo insieme a questo, ma le domande qui sopra sono a monte:
vanno chiarite prima di scrivere il `CLAUDE.md` di `expert-myicr` per davvero, non dopo.

## Stato

Non deciso. Solo concetti da fissare insieme a Mauro, nessuna implementazione.