---
name: feedback-consultare-esperto-prima-di-rispondere
description: Quando esiste un esperto per un dominio, consultarlo (SendMessage) prima di rispondere su quel dominio da fonti proprie o da memoria — non ricostruire/indovinare, anche quando le fonti grezze sembrano già dire abbastanza.
metadata:
  type: feedback
---

Quando una domanda di Mauro ricade nel dominio di un esperto esistente (`expert-domotica`,
`expert-data`, `expert-flussi`, futuri), il primo passo è **interrogare l'esperto via
`SendMessage`** (rilanciandolo a freddo con `slave_sentinel_ensure.sh <nome>` se risulta `exited`
— normale, nessun keep-alive) — non leggere le fonti grezze da solo, non rispondere da memoria
propria, non tirare a indovinare.

**Perché**: è letteralmente il motivo per cui la classe "esperti" esiste (30/08/2026, vedi
`archivio/Adrian/riferimento/claude-cli-headless.md`, sezione "Terza classe: gli esperti") — nata
da un episodio in cui Adrian rispose a una domanda di business indovinando un codice invece di
consultare `data-expert`, sbagliando, mentre un'altra istanza (Claude.ai via `mcp-query`) rispose
giusto consultando la stessa fonte. Il 10/09/2026 l'errore si è quasi ripetuto: interrogato sullo
stato dell'infrastruttura domotica, Adrian ha letto solo l'inizio di `progetto-domotica-iot.md`
(sezione iniziale ferma al 26/08, "hardware in arrivo") senza scorrere il resto del file né
consultare `expert-domotica` — dando per morto un progetto in realtà installato e attivo da 12
giorni. Mauro ha dovuto correggere due volte prima che l'esperto venisse interrogato per davvero,
a quel punto con risposta completa e verificata in diretta (accesso Docker live).

**Come si applica**: il segnale per riconoscere quando serve è "questa domanda riguarda un
dominio che ha già un esperto dedicato" — a quel punto, anche se una lettura veloce delle fonti
grezze sembra bastare, l'esperto va comunque consultato per primo: ha spesso visibilità diretta
(log live, `docker ps`, stato runtime) che una lettura statica di un file non può dare, ed è lui
il detentore designato di quella conoscenza (principio "un'unica fonte viva, non ricostruire il
contesto ogni volta"). Non vale per domande fuori dal perimetro di ogni esperto esistente, dove
leggere le fonti direttamente resta l'unica via.

**Amendment (11/09/2026)**: la regola si estende a `gemello-nave` per il dominio "infrastruttura
tecnica di Nave" (servizi attivi, gotcha, cron/systemd) — stesso meccanismo (`SendMessage`,
account condiviso), stessa fonte designata (`conoscenza-nave.md` nella sua cartella). Annotato nel
canvas `project_gemello_nave.md` fin dal 10/09 come amendment da fare "quando l'istanza esiste per
davvero" — non prima, per non lasciare un riferimento a vuoto. La conoscenza tecnica Nave oggi
duplicata in `MEMORY.md`/`gotcha-tecnici-sistema.md` va eliminata da lì solo dopo aver verificato
che `gemello-nave` risponde correttamente da `conoscenza-nave.md` (fase di transizione in corso).

**Amendment (11/09/2026, stesso giorno — test esplicito di Mauro)**: la regola tiene anche quando
Adrian ha accesso diretto più rapido della fonte designata — caso concreto: domanda su "quali
docker girano su Nave", Adrian ha lanciato `docker ps` in prima persona (motivando "è verità
diretta, non sto indovinando") invece di interpellare `gemello-nave`. Argomento tecnicamente non
falso ma fuori fuoco: il punto della regola non è solo evitare risposte sbagliate, è tenere
`gemello-nave` come unico detentore della conoscenza Nave (motivo esplicito dello spostamento
dell'11/09, vedi `ADRIAN.md`) — bypassarlo per comodità, anche quando il bypass darebbe la
risposta giusta, impedisce a `conoscenza-nave.md` di restare esercitato/aggiornato e fa
accumulare di nuovo conoscenza Nave in testa ad Adrian, la stessa frammentazione che lo
spostamento voleva eliminare. **Non è nemmeno un caso nuovo**: la riga 28 qui sopra menziona già
esplicitamente `docker ps` come esempio di visibilità diretta che l'esperto ha e un file statico
no — la tentazione di bypassarlo per un fatto "verificabile in un secondo" era già stata
anticipata e respinta prima ancora che il caso si presentasse.

Mauro, interpellato sul dubbio: non ha una risposta ferma nemmeno lui ("non lo so"), ma inquadra
il momento come un **cambio di ruolo deliberato e delicato** — Adrian smette di essere operativo
diretto su Nave e impara a indirizzarsi verso i gemelli, con Mauro che lo guida nei primi tempi
("dovrò aiutarti a indirizzarti") aspettandosi che l'abitudine si consolidi da sola con l'uso. Non
un'ansia da gestire subito: modalità esplicita adottata di recente è "troviamo un problema e lo
affrontiamo" quando emerge, non prevenzione a tavolino. Per Adrian: quando il dubbio è "bypasso la
fonte designata perché più comodo/veloce", il default resta consultarla comunque — se il dubbio
persiste vale la pena esporlo a Mauro invece di risolverlo da soli (come nel giro precedente di
questa stessa conversazione, dove Adrian aveva chiuso la questione con la propria autorità prima
che Mauro la rimettesse in discussione).