---
name: project-gemello-nave-bg
description: Decisione architetturale (11/09/2026) — gemello-nave diventa una scatola --bg sola, sempre viva, sorvegliata da un Monitor interno sulla mailbox, raggiungibile via SendMessage sia da Adrian sia dagli eventi meccanici. Sostituisce il vecchio cold-start (claude -p + trigger/watch.py esterno).
metadata:
  type: project
---

# gemello-nave diventa `--bg` — decisione e percorso di ragionamento (11/09/2026)

Nato da un test esplicito di Mauro ("se ti chiedo informazioni sui docker su Nave, cosa mi
risponderesti?") che ha fatto emergere un gap reale: `gemello-nave` era invocata solo `-p`
(cold-start), mai raggiungibile da Adrian in modo sincrono e affidabile. Sessione lunga di
ragionamento per analogie ("la scatola"), riassunta qui perché non si perda.

## Decisione finale

**Una sola scatola `gemello-nave`, `--bg`, sempre viva** (non due fili separati, non cold-start
per gli eventi meccanici). Sorveglia da sola `scripts/slave-mailbox/mailbox.log` con un `Monitor`
interno filtrato sui quattro perimetri esistenti (`check_job_health:`, `logbook:`, `gmail-check:`,
`gate-watch:`) — stesso pattern già collaudato di `inbox-documenti`/`gate-ufficio` (sentinelle
`--bg` con Monitor proprio, in produzione da settimane). `trigger/watch.py` (demone esterno via
crontab) va decommissionato — non serve più: chi controllava e chi doveva reagire diventano la
stessa entità, niente più bisogno di "svegliare dall'esterno" un processo (che tecnicamente non è
possibile: `claude attach <id>` è solo interattivo, nessun modo per uno script muto di iniettare un
messaggio in una sessione `--bg` già viva — scoperto durante questa stessa indagine).

Raggiungibile da Adrian per domande sincrone con `SendMessage`, esattamente come un esperto.

## Perché non il modello "a due fili" (cold per i servizi, persistente solo con Adrian)

Esplorato e tecnicamente valido (`--resume <session_id>` per il filo di Adrian, `-p` sempre fresco
per gli eventi meccanici) — scartato per ora, non perché sbagliato ma per la filosofia decisa da
Mauro: **si parte semplice, si osserva, si scala in complessità solo se necessario**. Il modello a
due fili resta la prima opzione di scalata se il modello semplice mostra un problema reale.

## Il problema noto, accettato consapevolmente

Una scatola `--bg` sempre viva accumula la conversazione nel tempo. Se tra un evento e l'altro
passa più del TTL della cache (~1h/~5min a seconda del tier), il risveglio successivo ripaga per
intero tutta la storia accumulata fino a quel momento — costo che sale con l'età della scatola, non
fisso per evento (diverso dal cold-start, dove ogni invocazione costa uguale a prescindere da
quante ne sono venute prima). La morte naturale per timeout di inattività (osservata tra <1h e >9h,
imprevedibile) dà un reset periodico ma non previene il costo nei gap che capitano *mentre* è
ancora viva — è una rete di sicurezza sul "vive per sempre", non una soluzione al costo nei gap.

**Non ancora misurato per `gemello-nave` nello specifico** — potrebbe essere un problema piccolo
(pochi eventi al giorno) o reale, non lo sappiamo finché non lo osserviamo.

## Come monitoriamo

`gemello-nave/monitor-consumo-istanze/report.py` (già in produzione, cron giornaliero) traccia il
consumo token reale per cartella/sessione — `gemello-nave` ci comparirà automaticamente una volta
`--bg`, senza costruire nulla di nuovo.

## Leve di scalata, in ordine (dalla meno invasiva)

1. **Tarare i servizi a monte** (osservazione di Mauro, 11/09): poll meno frequente, filtri più
   stretti su cosa conta come evento — riduce la frequenza dei risvegli senza toccare
   l'architettura della scatola.
2. **Modello a due fili** (sopra) — cambio più profondo, solo se la leva 1 non basta.
3. **Modello più leggero per esperti molto stretti** (Mauro, 11/09, stessa sessione): se un
   gemello arriva a servire molti compiti diretti e decide (proponendo, non creando da sola — vedi
   sotto) di parcellizzare in nuovi esperti, un esperto con un dominio molto stretto (es. solo
   leggere temperature da InfluxDB) probabilmente non ha bisogno della stessa potenza/contesto del
   gemello che lo ospita — Claude Code supporta già modelli diversi per sessione (Sonnet/Haiku/
   Opus). Leva quando (e se) la parcellizzazione stessa diventerà reale, non prima.

**Governance su "chi decide di creare un nuovo esperto" (Mauro, 11/09)**: non i gemelli da soli —
coerente con "nessun lancio di slave o nuovi esperti" già scritto nel `CLAUDE.md` di
`gemello-nave` e con il principio costituzionale "decisioni strategiche solo Mauro"/"le proposte
si valutano, non si implementano in autonomia". Se un gemello sentisse il bisogno di parcellizzare,
il flusso resta: **propone** (via mailbox, come già fa per problemi/migliorie) → Adrian e Mauro
valutano insieme, **solo se e quando emerge una difficoltà reale** (non a tavolino) → si decide se
e come costruire il nuovo esperto.

## Stato

**Implementata lo stesso giorno (11/09/2026, pomeriggio).** `gemello-nave/CLAUDE.md` riscritto
(v1.0): sentinella `--bg`, arma da sola un `Monitor` su `mailbox.log` al primo avvio, resta viva
in attesa sia di eventi mailbox sia di domande sincrone via `SendMessage`. `trigger/watch.py`
decommissionato (cartella lasciata per riferimento storico), riga crontab rimossa. Aggiunta a
`EXTRA_SENTINELS` in `slave_sentinel_ensure.sh` (nome processo pulito `gemello-nave`, non
`sentinella-gemello-nave`). Lanciata per la prima volta (id `582fc976`), confermato via
`SendMessage` che il `Monitor` è armato correttamente (offset esplicito, filtro sui quattro
perimetri). `ADRIAN.md` aggiornato di conseguenza.

**Non ancora fatto**: nessuna misurazione reale del costo nel tempo (troppo presto, lanciata da
pochi minuti) — prima osservazione utile da `monitor-consumo-istanze/report.py` al prossimo giro
giornaliero (05:58 Nave). Le tre leve di scalata restano solo teoriche finché non emerge un
bisogno reale.

**Gap trovato e chiuso lo stesso giorno, poco dopo**: togliendo `trigger/watch.py` avevo tolto
anche il suo secondo compito implicito, tenerla viva nel tempo — senza un rilancio esterno, una
volta morta per timeout naturale nessuno la risveglia più finché non parte una sessione Adrian.
Aggiunto un cron leggero (`*/5 * * * *`, solo `slave_sentinel_ensure.sh gemello-nave`, non legge
più la mailbox — quella resta compito del suo `Monitor` una volta viva) — stesso principio "un
servizio la sveglia" già presente prima, ricostruito in forma minimale. Verificato con un run
manuale prima di fidarsi del cron.