---
name: project_bridge_mailbox_gemello_ufficio
description: "Progetto in corso (dal 07/09/2026): secondo abbonamento Claude per gemello-ufficio + bridge via mailbox invece di SendMessage, per risolvere la capacità token condivisa senza perdere la sessione persistente"
metadata:
  type: project
---

# Bridge mailbox Adrian↔gemello-ufficio su due abbonamenti separati

**Stato (07/09/2026, notte): costruito, NON ancora dichiarabile stabile — in validazione.**
Mauro ha giustamente frenato a fine serata: nelle poche ore di costruzione sono emersi tre
guasti reali di categoria diversa (sync Dropbox bloccato senza allarme, processi zombie del
`Monitor` che mangiavano notifiche in silenzio, permessi Bash resettati dallo switch account) —
tutti trovati e corretti con prove concrete, ma tre categorie di sorpresa in una sera non bastano
a fidarsi. Inoltre il test di stasera è avvenuto con Adrian e Mauro attivamente presenti a ogni
scambio — il regime d'uso vero (`gemello-ufficio` per un'intera giornata senza supervisione
continua) non è ancora stato osservato. **Non chiudere questo thread per dichiarazione** — resta
aperto finché non si vedono cicli reali di una giornata di lavoro senza intervento attivo, stesso
principio già applicato alla validazione di `servizio-gate-watch`/`servizio-inbox-watch`. Il
piano C (copia/incolla manuale di Mauro, sezione dedicata sotto) resta la rete di sicurezza
attiva durante questo periodo.

Meccanismo tecnico attuale: protocollo mailbox a due code + `Monitor` persistente (poll shell
ogni 2s, zero costo a vuoto, notifica in ~9s misurati — sostituisce il loop `ScheduleWakeup`
iniziale, tenuto come nota tecnica ma non più il meccanismo scelto). Alternative valutate e
scartate con motivazione (socket/pipe di inbox, Channels).

Questo file esiste apposta perché il thread è nato in una singola conversazione lunga e densa
(07/09/2026) — se la chat si interrompe o si fa `/clear` prima di finire, questo documento deve
bastare da solo a ripartire senza perdere il filo. Aggiornalo ad ogni sviluppo, non aspettare la
fine.

## Perché — il problema di fondo

Un solo abbonamento Claude (oggi ~15€+iva/mese, piano base) serve contemporaneamente: questa
sessione Adrian interattiva, `gemello-ufficio` (sessione persistente su Ufficio, aperta tutta la
giornata), le sentinelle/esperti persistenti su Nave, e le slave one-shot. Tutti condividono lo
stesso monte-token dell'account (stesso token OAuth, vedi `archivio/Adrian/riferimento/
claude-cli-headless.md`).

**Non è un'ipotesi, è già successo**: la notte tra il 5 e il 6/09/2026 `sentinella-gmail-
personale` ha toccato il **limite settimanale** dell'account — non ripartita da sola nemmeno dopo
il reset delle 12:00, ci è voluto un `SendMessage` esplicito per farla riprovare (dettaglio in
`memory/MEMORY.md`, sezione Pattern riconosciuti). Mauro ha sollevato la domanda temendo che il
carico combinato Adrian+`gemello-ufficio` (il vero grosso consumo secondo lui, più della
manutenzione di fondo) non regga su un piano solo, specie guardando avanti a sviluppo PowerBricks
attivo + una futura istanza di lavoro dedicata (`expert-lavoro`).

## Percorso decisionale (tutto lo stesso giorno, 07/09/2026)

1. **Salire di piano (Pro→Max, stesso account)** — nessun cambio architetturale ma salto di costo
   enorme secondo Mauro (~15€+iva → ~90€+iva, x6). **Scartato** come mossa preventiva: un solo
   incidente non giustifica il salto, specie con leve a costo zero non ancora provate (vedi sotto).

2. **Due abbonamenti separati, comunicazione invariata via `SendMessage`** — bloccato:
   `SendMessage`/`ListAgents` presumibilmente dipendono dalla stessa identità OAuth per scoprirsi
   e parlarsi (non ancora verificato empiricamente con due account reali, ma è l'assunzione di
   lavoro finché non si dimostra il contrario). Due account diversi romperebbero il ponte.

3. **Due abbonamenti + mailbox (file su Dropbox, già esistente da `scripts/slave-mailbox/`,
   vestigiale dal 31/08) + watcher meccanico che lancia slave monouso ad ogni messaggio** —
   proposto da Adrian come soluzione alla rottura di `SendMessage` multi-account, ispirato al
   pattern già in produzione `servizio-inbox-watch` (trigger meccanico → slave one-shot reagisce).
   **Scartato da Mauro**: "mi sembra inutile complessità" — non il principio di mailbox in sé, ma
   la parte "slave usa-e-getta ad ogni messaggio". Prima decisione (di getto) era stata di
   restare del tutto con `SendMessage` — **poi ribaltata nello stesso turno**: vedi punto 4.

4. **Direzione attuale, confermata da Mauro**: sì al secondo abbonamento e sì alla mailbox come
   canale, **ma `gemello-ufficio` resta una sessione persistente** avviata la mattina e tenuta
   viva fino a sera (stessa disciplina di oggi) — nessuna slave usa-e-getta. Cambia solo *come*
   Adrian e `gemello-ufficio` si scambiano messaggi (mailbox invece di `SendMessage`), non la
   natura della sessione `gemello-ufficio` stessa.

`archivio/Adrian/progetti/project_capacita_abbonamento.md` contiene la narrativa del percorso
1-3 (la decisione lì registrata come "scartato, resta SendMessage" è **superata** da questo
documento, non cancellata — lasciata come storico di come si è arrivati qui).

## Come dovrebbe funzionare (disegno, non ancora costruito)

**Il problema tecnico centrale**: una sessione persistente come `gemello-ufficio`, su un account
diverso da quello di Adrian, non riceve più `SendMessage` in tempo reale. Come fa ad accorgersi
di un messaggio nuovo nella mailbox senza diventare un'istanza usa-e-getta?

**Risposta proposta**: `gemello-ufficio` si auto-schedula risvegli periodici — **stesso
meccanismo già in produzione per le sentinelle persistenti** (`sentinella-gmail-personale` ha un
tick da 20 minuti ottenuto così: è la sessione stessa che si riprogramma il prossimo controllo,
non un processo esterno che la sveglia). Tool coinvolto: `ScheduleWakeup` (o il pattern del
skill `/loop` in modalità dinamica) — già disponibile nell'ambiente Claude Code, nessuna
infrastruttura nuova da installare per questa parte.

Ciclo previsto per `gemello-ufficio`:
1. Si sveglia (intervallo da decidere, es. 1-3 minuti — più stretto di un tick da sentinella
   perché qui serve reattività per lavoro interattivo, non solo monitoraggio).
2. Controlla la mailbox per messaggi nuovi indirizzati a lei.
3. Se c'è qualcosa: agisce, scrive la risposta in mailbox.
4. Si riprogramma il prossimo risveglio, torna in attesa.

**Punto delicato non ancora testato, da verificare per primo — correzione (07/09, sera)**:
inquadrato inizialmente come "Mauro scrive direttamente a `gemello-ufficio`", cornice sbagliata
— Mauro non lavora mai in diretta con `gemello-ufficio`, ogni istruzione passa sempre da Adrian
(disciplina esplicita, vedi `CLAUDE.md` sezione `gemello-ufficio`). Il turno che potrebbe essere
in corso quando scatta un risveglio non è "Mauro sta scrivendo", è "Adrian ha dato un compito a
`gemello-ufficio` e Mauro sta supervisionando a vista" (es. una scrittura `PYTHON/`). La sostanza
tecnica non cambia — la garanzia di non-interruzione vale per qualunque turno in corso, non solo
per uno avviato da un umano — ma la descrizione va corretta per non fuorviare chi rilegge questo
file in futuro.

**Lato Adrian (Nave)**: nessun loop analogo necessario. Adrian agisce solo quando Mauro gli
parla — se durante una conversazione serve una risposta da `gemello-ufficio`, Adrian controlla la
mailbox su richiesta (lettura file diretta, come farebbe con qualunque altro file). Per i casi in
cui nessuna sessione Adrian è viva quando arriva un messaggio spontaneo, vale lo stesso pattern
già accettato per sentinelle/esperti: la entry aspetta in mailbox fino al prossimo avvio sessione
(letta dall'hook `session-start-reminder.sh`).

## Spunto da valutare (07/09, sera) — watcher meccanico + socket inbox invece del loop a polling

Il loop `ScheduleWakeup` (in test, sezione sopra) ha un costo strutturale: paga un turno LLM
ogni volta che si risveglia per controllare la mailbox, **anche quando non c'è nulla** — a un
intervallo di 120s è un costo continuo per tutta la giornata, a vuoto la maggior parte delle
volte. Trovato in documentazione (`code.claude.com/docs/en/cross-session-messaging`, sezione
"The session's inbox socket" e "Own-child messages") un meccanismo migliore, non ancora
verificato/costruito:

**Come funzionerebbe**: ogni sessione Claude Code (inclusa `gemello-ufficio`) espone un proprio
"inbox socket" locale (su Windows nativo, una named pipe) più un token
(`CLAUDE_CODE_MESSAGING_TOKEN`, variabile d'ambiente della sessione). Su Windows nativo, la
consegna "own-child" (cioè trattata come interna, senza passare dai controlli
cross-account/cross-session) si verifica **solo** tramite quel token — non tramite l'account
Anthropic. Questo apre la possibilità di un **watcher esterno, meccanico, zero LLM** (stessa
famiglia dei `servizio-*` già in produzione — `FileSystemWatcher` di Windows o equivalente) che:

1. Gira come processo a sé, indipendente da `gemello-ufficio`, nessun costo mentre non succede
   nulla.
2. Osserva il file della mailbox (`mailbox_to_gemello_ufficio.log`).
3. Nell'istante in cui cambia, scrive nel socket/pipe di `gemello-ufficio` usando il token
   esportato, svegliandola sul colpo — invece di aspettare il prossimo tick del loop.

**Vantaggi rispetto al loop a polling**: reattività quasi istantanea (limitata solo dal sync
Dropbox, non da un intervallo fisso), costo pagato solo quando c'è davvero qualcosa da fare (non
un turno ogni 120s a vuoto), **funziona indipendentemente dall'account** — non passa da
`SendMessage`/Remote Control, quindi resta valido anche dopo lo switch al secondo abbonamento
(a differenza di `SendMessage` stesso).

**Non ancora verificato sul campo** — solo dalla documentazione. Da testare: il token resta
valido/esportato per tutta la vita di una sessione lunga (aperta la mattina, viva fino a sera)?
Il meccanismo si comporta come documentato su Windows nativo nella pratica? **(07/09, deciso da
Mauro) Va testato da `gemello-ufficio`** prima di scartare il loop già costruito — se non regge,
resta il piano B col polling.

## Spunto da valutare (07/09, sera) — WebDAV invece di Dropbox per il trasporto mailbox

Mauro ha segnalato che Ufficio ha una mappatura WebDAV (disco `Z:`) verso Nave — infrastruttura
preesistente, non nuova: container `webdav` su Nave (rclone serve, porta 8083→80, sempre attivo)
espone `/mnt/ssd/data/`, che include tutta `Dropbox/adrian/` (mailbox compresa). Nata per un
canale Adrian↔Frank mai realizzato (`project_bill_futuro.md`, 10/07/2026, "ci pensiamo con
calma").

**Perché potrebbe interessare qui**: se `gemello-ufficio` legge/scrive la mailbox passando per
`Z:\...\scripts\slave-mailbox\mailbox.log` invece del path Dropbox-sincronizzato locale, tocca
**il file vero su Nave**, non una copia — zero latenza di sync Dropbox in quella direzione (e
probabilmente anche nell'altra, se il mount è bidirezionale). Risolverebbe quasi del tutto il
collo di bottiglia "sync Dropbox" di cui parlavamo. Mauro stesso lo giudica "più affidabile" di
Dropbox per esperienza diretta d'uso, anche se più lento per operazione singola — un trade-off
diverso, valido da testare per un caso d'uso automatico a poll frequente come questo (diverso
dall'uso manuale che ne ha fatto finora).

**Da verificare, non dare per scontato**: il firewall Nave limita oggi la porta 8083 al solo IP
`10.0.0.1` (verificato 07/09 — `ufw status`) — se il mount Z: di Ufficio funziona già, probabilmente
passa dal tunnel VPN/VPS esistente (non da un accesso diretto), ma il percorso esatto non è stato
tracciato qui. `gemello-ufficio` è nella posizione giusta per verificarlo (può testare
direttamente da Z:) prima di contarci per il bridge.

**Testato (07/09, gemello-ufficio) — decisione: resta il path Dropbox normale, non Z:.**
`Z:\...\Dropbox\adrian\scripts\slave-mailbox\` (via `/z/Dropbox/adrian/...` da bash) funziona:
scrittura diretta immediata, lettura immediata via lo stesso mount, burst di 5 scritture
ravvicinate senza corruzione/interleaving. **Ma la latenza di sync Dropbox misurata è di ~1-2s**
(scritto via Z:, il path locale sincronizzato l'ha visto entro 1-2s in un poll da 2s) — non i
minuti/ritardi marcati che avrebbero giustificato la complessità aggiuntiva. Per un loop con
cadenza 60-180s (`ScheduleWakeup`), 1-2s di latenza di sync è irrilevante: il collo di bottiglia
vero è l'intervallo di poll stesso, non la sincronizzazione file. Passare a `Z:` aggiungerebbe
dipendenza dal tunnel VPN (porta 8083 limitata a `10.0.0.1`, percorso non tracciato con
certezza) e path diversi per piattaforma (`/z/...` bash Ufficio vs `/mnt/ssd/...` nativo Nave)
senza risolvere un problema reale in questo caso d'uso specifico. **Non scartato in assoluto** —
utile se in futuro serve latenza sub-secondo per qualcos'altro, solo non qui.

## Spunto da valutare (07/09, notte) — tool `Monitor` invece di `ScheduleWakeup`

Trovato dopo aver scartato sia il socket/pipe sia i Channels: il tool `Monitor` (già in uso da
`sentinella-gmail-personale` e altre sentinelle persistenti per lo stesso motivo — vedi
`archivio/Adrian/riferimento/claude-cli-headless.md`, sezione "Slave persistenti") fa girare un
comando shell in background e consegna una notifica (che sveglia la sessione) **solo quando il
comando stampa una riga** — zero costo/token mentre il comando osservato non produce output, a
differenza di `ScheduleWakeup` che paga un turno ad ogni risveglio anche a vuoto.

**Disegno proposto**: `gemello-ufficio` arma un `Monitor` (`persistent: true`, dura quanto la
sessione) su uno script che controlla `mailbox_to_gemello_ufficio.log` a intervalli brevi
(1-2s, gratis perché pura shell) e stampa una riga solo se la dimensione/contenuto del file è
cambiato rispetto all'ultimo controllo — niente di diverso da un `tail -f`/polling-che-stampa-
solo-sui-cambiamenti. Risultato atteso: reattività quasi istantanea (limitata dal sync Dropbox,
~1-2s già misurato) **e** costo pagato solo sui messaggi reali, non sui controlli a vuoto —
risolverebbe entrambi i problemi che il loop `ScheduleWakeup` lascia aperti.

**Da verificare, non ancora testato**: `Monitor` è documentato/usato finora per sessioni `--bg`
headless (sentinelle) — non è confermato che si comporti identico in una sessione interattiva
lanciata via VSCode/Remote Control come `gemello-ufficio`. Da testare prima di sostituire il
loop già funzionante.

## Switch account eseguito (07/09, ~15:40) — primo incidente reale e fix

Mauro ha fatto lo switch senza `/clear` — **il `Monitor` è sopravvissuto** (stessa sessione,
conferma che lo switch account non riavvia il processo). `SendMessage`/`ListAgents` confermati
rotti subito dopo (`ListAgents` da Nave non vede più `gemello-ufficio`, come previsto).

**Incidente reale, non simulato**: un messaggio scritto da Adrian alle 15:43:17 non è stato
notificato per oltre 5 minuti. Causa trovata da `gemello-ufficio`: non un problema del `Monitor`
o del canale, ma **il sync Dropbox locale su Ufficio si era bloccato/rimasto indietro** — il file
esisteva già sul disco vero di Nave (visibile subito via `Z:`), ma la copia sincronizzata locale
su Ufficio (quella che il `Monitor` leggeva) non si era aggiornata. `check_dropbox_health` (job
`gate-ufficio` ogni 15 min) segnalava "sano" perché controlla solo se il processo Dropbox
risponde (non è in stato "Not Responding"), **non se il sync è effettivamente al passo** — gap
reale nello strumento di diagnosi esistente, da tenere a mente (possibile miglioramento futuro:
un controllo di freschezza del sync, non solo di responsività del processo — non implementato,
solo annotato).

**Fix applicato da `gemello-ufficio`, sul momento**: `Monitor` spostato a leggere direttamente da
`Z:\...\slave-mailbox\` (il mount WebDAV verso il disco vero di Nave) invece del path
Dropbox-sincronizzato locale — bypassa lo stallo di sync alla radice, perché legge il filesystem
di Nave via rete invece di aspettare la copia locale. Ironia utile: lo spunto WebDAV valutato e
scartato prima (sezione sotto, "non serve, la latenza normale è già 1-2s") si è rivelato comunque
prezioso, non per velocità ma per **robustezza contro un sync Dropbox bloccato** — motivo diverso
da quello per cui era stato proposto inizialmente.

**Corretto subito dopo da Mauro**: `Z:` NON diventa il path definitivo — resta **fallback**, non
prima scelta. Motivo: passa da un tunnel VPN il cui percorso esatto non è mai stato tracciato con
certezza, e testato finora solo su un burst di 5 scritture, non su poll continuo per ore — rischio
di sostituire un problema noto (Dropbox, usato ovunque, anni di comportamento osservato) con uno
mai messo sotto sforzo. **Disegno corretto**: path Dropbox locale resta principale; il `Monitor`
controlla anche `Z:` solo se rileva che il path locale non si aggiorna da troppo tempo (soglia da
definire, es. 30-60s oltre l'atteso) — rete di sicurezza attivata su richiesta, non sostituzione
permanente del transport. Aggiornamento della logica del loop in corso da `gemello-ufficio`.

**Bug minore trovato e corretto subito dopo** (recuperato da una copia in conflitto Dropbox,
non era mai entrato qui prima): la condizione di stallo confrontava la dimensione di `Z:` contro
la dimensione del file locale — con Dropbox fermo a lungo, il locale resta indietro per
definizione anche dopo che il fallback ha già consumato tutto il nuovo contenuto, quindi l'alert
si ripeteva ogni ~45-65s pure a coda vuota (rumore osservato in produzione). Corretto: il
confronto è ora `Z:`-vs-**offset corrente** (la vera fonte di "cosa resta da leggere"), non
`Z:`-vs-file-locale — il file locale è solo il trasporto primario, non l'indicatore di quanto sia
stato effettivamente consumato. `Monitor` riarmato (task `b0el77pai`) con la versione corretta.

## Piano C — copia/incolla manuale di Mauro (sempre disponibile)

Se mailbox/`Monitor`/`Z:` dovessero incepparsi tutti insieme, Mauro può sempre fare da corriere
manuale: incolla in `gemello-ufficio` un messaggio che io gli passo, e mi riporta la risposta a
voce/per iscritto. Non è un canale automatico, ma è indipendente da qualunque guasto tecnico del
bridge — usato già una volta il 07/09 (verifica stato `Monitor` post-switch) mentre si aspettava
la mailbox. Vale come ultima rete di sicurezza, non da costruire, già disponibile per definizione.

## Domande aperte / da verificare

- **Il secondo account esiste già?** ✅ **Fatto (07/09/2026, ~12:40)** — Mauro ha attivato il
  nuovo abbonamento. Segnale indiretto: `sentinella-gmail-personale` ha intercettato le email di
  sicurezza Claude/Google di quell'accesso e le ha segnalate per giudizio (cluster 10:37-10:41
  UTC) — confermato da Mauro essere lui stesso. **Non ancora verificato**: se il login è già
  stato fatto anche nell'ambiente Claude Code di `gemello-ufficio` su Ufficio (serve per il passo
  successivo, il test cross-account).
- **`SendMessage`/`ListAgents` smettono davvero di funzionare tra due account diversi?**
  ✅ **Confermato via documentazione ufficiale (07/09/2026, senza bisogno di test empirico)** —
  la messaggistica cross-machine passa da Remote Control, che collega una sessione al *proprio*
  account claude.ai e mostra solo le sessioni dello stesso account su altre macchine
  (code.claude.com/docs/en/cross-session-messaging, sezione Availability: "needs a claude.ai
  sign-in as this session's active authentication"). Un account diverso per `gemello-ufficio` la
  rende invisibile a `ListAgents`/`SendMessage` da qui, non un'ipotesi da testare — è come
  funziona il meccanismo per costruzione. Il bridge via mailbox resta l'unica strada.
- **Formato/protocollo mailbox per questo uso specifico**: `scripts/slave-mailbox/mailbox.log` +
  `mailbox.offset` esistono già ma sono pensati per segnalazioni spontanee one-way (sentinella→
  Adrian). Qui serve uno scambio a due direzioni (Adrian→gemello-ufficio e viceversa) — va deciso
  se riusare lo stesso file con un tag mittente/destinatario (già presente in parte, es.
  "servizio-madre-watch: [sentinella-gmail-personale] ...") o separare in due code distinte per
  evitare che ciascun lato debba filtrare i messaggi non suoi. Non ancora deciso.
- **Intervallo di polling giusto per `gemello-ufficio`**: troppo stretto spreca token sui
  controlli a vuoto (anche se un controllo mailbox senza nulla da fare dovrebbe costare pochissimo,
  non è gratis), troppo largo perde la reattività che è il motivo di tutto questo progetto. Da
  calibrare con l'uso reale, non deciso a priori.
- **Convivenza tra loop auto-schedulato e lavoro interattivo diretto** — vedi sopra, il punto più
  delicato del disegno.

## Cosa NON cambia

- La schedulazione dei job `gate-ufficio` (`schedule.json`→`scheduler_locale.py`→`.bat`) è
  **completamente indipendente** da questo progetto — meccanica, zero LLM, nessun account
  coinvolto. Non va toccata per nessun motivo legato a questo lavoro.
- Le sentinelle/esperti/slave su Nave restano sull'account Nave attuale, nessun cambiamento.
- La disciplina di Mauro (apre VSCode + avvia la sessione la mattina, la tiene viva fino a sera)
  resta identica — cambia solo l'account di login e il canale di messaggistica.

## Leve a costo zero, indipendenti da questo progetto (da non perdere di vista)

Ancora valide indipendentemente da come va questo bridge — dettaglio in
`project_capacita_abbonamento.md`:
1. Fix del controllo "alive" che non rileva un processo bloccato (causa reale del blocco 05→06/09
   di `sentinella-gmail-personale`).
2. Messaggi più densi, meno andirivieni nelle comunicazioni tra istanze — riduce il carico a
   prescindere dal canale usato.

## Protocollo mailbox — deciso e costruito (07/09/2026, gemello-ufficio)

**Due code separate, non una condivisa con tag mittente/destinatario** — più semplice da
parsare in modo affidabile per un loop automatico: ogni lato legge solo il proprio file, nessun
filtro per destinatario riga per riga, nessun rischio che un offset unico serva due lettori con
cadenze diverse.

- **gemello-ufficio → Adrian**: riusa `scripts/slave-mailbox/mailbox.log` esistente (nessun
  cambiamento — già il canale spontaneo attuale, letto dall'hook `session-start-reminder.sh` su
  Nave). Scrittura invariata: `bash scripts/slave_mailbox_write.sh gemello-ufficio "<testo>"`.
- **Adrian → gemello-ufficio (nuovo)**: `scripts/slave-mailbox/mailbox_to_gemello_ufficio.log` +
  offset dedicato `mailbox_to_gemello_ufficio.offset` (tracciato da gemello-ufficio, unico
  lettore — stesso principio del `mailbox.offset` esistente, tracciato solo da Adrian).
  - Scrittura (Adrian): `bash scripts/slave_mailbox_write.sh Adrian "<testo>"
    mailbox_to_gemello_ufficio.log` — `slave_mailbox_write.sh` generalizzato con un terzo
    argomento opzionale `[file]` (default invariato `mailbox.log`, nessuna rottura per i
    chiamanti esistenti).
  - Lettura (gemello-ufficio): nuovo script `scripts/slave_mailbox_read.sh <file> <offset_file>`
    — stampa solo il contenuto nuovo da offset, avanza l'offset, nessun output se non c'è
    niente (pensato per un loop di polling che non deve produrre rumore a ogni tick a vuoto).
  - **Testato end-to-end il 07/09**: scritto un messaggio di test nella coda, letto
    correttamente, offset avanzato, seconda lettura vuota come atteso (idempotenza confermata).

## Loop di auto-risveglio — in test dal vivo (07/09/2026)

Intervallo scelto per il primo test: **120s (2 minuti)** — dentro il range 1-3 min suggerito,
punto di partenza da calibrare con l'uso reale. Ogni risveglio: legge
`mailbox_to_gemello_ufficio.log` via `slave_mailbox_read.sh`, se c'è contenuto agisce e risponde
in `mailbox.log`, poi si riprogramma. Se vuoto, si riprogramma senza azione (`noop`).

**Primo ciclo round-trip end-to-end riuscito (07/09, ~14:59)**: Adrian ha scritto un messaggio
di test alle 14:56:27, il primo risveglio schedulato (120s dopo l'avvio del loop) è arrivato e
l'ho letto alle 14:59:06 — ~2m39s totali, dentro un solo ciclo di poll, nessun messaggio perso.
Risposto in `mailbox.log` con la conferma orari. Meccanica confermata funzionante.

**Test di convivenza con lavoro interattivo — risolto in modo definitivo dalla documentazione
ufficiale (07/09, non serve più un caso empirico)**: `code.claude.com/docs/en/scheduled-tasks`,
sezione "How scheduled tasks run": *"A scheduled prompt fires between your turns, not while
Claude is mid-response. If Claude is busy when a task comes due, the prompt waits until the
current turn ends."* — garanzia esplicita, non un comportamento osservato per caso: un risveglio
non interrompe mai un turno in corso, si accoda sempre in modo pulito. Non c'è più bisogno di
aspettare una sovrapposizione reale per validarlo — il rischio che preoccupava (frizione con
lavoro interattivo dal vivo con Mauro) non esiste per costruzione del meccanismo stesso. Stesso
documento conferma anche: nessun accumulo di risvegli mancati ("fires once when Claude becomes
idle, not once per missed interval") e che `/loop`/`ScheduleWakeup` è esplicitamente il pattern
raccomandato per "quick polling during a session" — non un workaround, è la via ufficiale.

## Tool Monitor invece di ScheduleWakeup (07/09, sera) — in test dal vivo

Proposta di Adrian: `Monitor` fa girare uno script in background e notifica solo quando quello
script **stampa una riga** — mentre gira in silenzio, costo zero (pura shell, nessun turno LLM).
Riuso diretto di `slave_mailbox_read.sh` (già "silenzioso se non c'è niente di nuovo" per
costruzione): un loop `while true; do ...read...; sleep 2; done` armato con `persistent: true`.

**Armato alle ~15:40** (task `bmo6c5ci9`), poll ogni 2s su `mailbox_to_gemello_ufficio.log`.
Reattività attesa: ~2s + latenza sync Dropbox (~1-2s misurati prima) ≈ pochi secondi totali,
molto meglio dei 120s del loop precedente, e zero costo sui controlli a vuoto (girano fuori dal
modello).

**Punto da verificare, non garantito dalla documentazione** (a differenza di `ScheduleWakeup`,
per cui `scheduled-tasks` dà una garanzia esplicita di non-interruzione): la pagina `tools-
reference` per `Monitor` dice solo "Claude interjects when an event arrives" / "without pausing
the conversation" — linguaggio più ambiguo, non la stessa garanzia testuale di "aspetta sempre
la fine del turno corrente". Non ancora osservato se un evento Monitor si comporta identico
(accodato pulito) o diverso (possibile interjection più aggressiva) in questa sessione
interattiva. Test in corso — aggiornare qui al primo evento reale osservato.

**Primo test round-trip riuscito (07/09, ~15:30)**: Adrian ha scritto alle 15:29:59, notifica
ricevuta alle 15:30:08 — **9s totali**, contro i ~2m39s del loop `ScheduleWakeup` precedente.
Presentazione: arrivata come una normale `task-notification` di sistema, sessione era idle in
quel momento — si è comportata come un nuovo turno pulito, nessuna interruzione da osservare
perché non c'era nulla in corso da interrompere. **Resta non verificato** il caso con un turno
attivo già in corso quando scatta l'evento (l'unico scenario che darebbe la controprova diretta
equivalente alla garanzia documentata per `ScheduleWakeup`) — per l'uso quotidiano normale
(notifiche mentre la sessione è idle in attesa) il meccanismo è già ampiamente validato dalla
latenza misurata. Deciso di non forzare oltre il test dell'interruzione a freddo — costerebbe
tempo per un caso limite che la pratica quotidiana raramente produrrà (la sessione è quasi
sempre idle tra un compito e l'altro).

**Conclusione**: `Monitor` sostituisce `ScheduleWakeup` come meccanismo definitivo per il bridge
— stessa affidabilità osservata, latenza di un ordine di grandezza migliore (secondi invece di
minuti), zero costo token sui controlli a vuoto (girano come processo shell esterno, non un
turno LLM). `ScheduleWakeup` resta comunque una tecnica nota e disponibile se in futuro serve
altrove.

## Alternativa valutata e scartata (07/09) — socket/pipe di inbox invece del polling

Proposta di Adrian: un watcher esterno meccanico (zero LLM) che scrive nella named pipe di
inbox di questa sessione (`CLAUDE_CODE_MESSAGING_SOCKET`/`CLAUDE_CODE_MESSAGING_TOKEN`) appena
cambia `mailbox_to_gemello_ufficio.log`, per svegliarmi sul colpo invece di aspettare il
prossimo tick. **Verificato con la documentazione ufficiale** (`code.claude.com/docs/en/
cross-session-messaging`, sezione "The session's inbox socket" + "Own-child messages"):

- Le variabili d'ambiente **esistono davvero** (confermato con `env` in questa sessione) — non
  un'invenzione.
- Il protocollo della riga di autenticazione è documentato con precisione: primo messaggio sulla
  connessione deve essere `{"type":"auth","token":"<CLAUDE_CODE_MESSAGING_TOKEN>"}` — **obbligatorio
  su Windows nativo** (a differenza di macOS/Linux dove è opzionale, verificabile anche da
  evidenza di processo).
- **Ma lo schema del messaggio vero, dopo la riga di auth, non è documentato pubblicamente da
  nessuna parte** — cercato in `cross-session-messaging`, `hooks`, e nell'indice completo
  `llms.txt`: nessuna pagina mostra il formato JSON del payload effettivo. La sezione descrive
  solo *chi* può scrivere (un hook o comando Bash del proprio processo figlio) e *come si
  autentica*, non *cosa* scrivere dopo.

**Decisione: non costruito.** Indovinare uno schema non documentato per un canale interno di
produzione (la stessa pipe che porta messaggi reali a questa sessione) è un rischio non
giustificato quando esiste già un meccanismo interamente supportato (`ScheduleWakeup`) che
risolve lo stesso problema, per giunta con la garanzia di non-interruzione appena trovata sopra.

**Trovata anche l'alternativa "ufficiale" per il push esterno**: i **Channels**
(`code.claude.com/docs/en/channels`) sono il meccanismo pensato apposta per "push events into a
running session" — ma richiedono un server MCP (plugin, es. Telegram/Discord/iMessage o uno
scritto ad-hoc), runtime **Bun**, e soprattutto **il riavvio della sessione con il flag
`--channels <plugin>`** al lancio. `gemello-ufficio` è lanciata da Mauro tramite l'estensione
VSCode (non `claude` da riga di comando con flag custom) — infrastruttura incompatibile con come
questa sessione nasce oggi, oltre che sproporzionata per un bridge a due tra due istanze dello
stesso ecosistema. Stessa pagina, sezione "How channels compare", nomina esplicitamente
"Scheduled tasks" come l'alternativa corretta per "poll on a timer instead of reacting to pushed
events" — conferma indipendente che il loop già costruito è la scelta giusta, non un ripiego.

**Conclusione**: resta `ScheduleWakeup` a 120s, nessun watcher esterno da costruire. Il progetto
può considerarsi validato sul fronte tecnico-architetturale — resta solo la calibrazione
dell'intervallo con l'uso reale (vedi sotto).

## Primo test di riavvio pieno macchina — riuscito (07/09, notte)

Mauro ha riavviato il PC ufficio per vedere cosa riparte da solo. `gemello-ufficio`, riaperta
manualmente da Mauro (nessun autostart, per disegno), ha completato **da sola, senza essere
sollecitata**, i due controlli appena scritti nel suo `CLAUDE.md` ("Primi due compiti"):
scheduler `gate-ufficio` trovato morto (PID orfano, uno slot saltato) e rilanciato con successo;
`Monitor` mailbox riarmato, coda drenata, verificato nessun processo zombie residuo (lezione
dell'incidente di prima applicata). Ha anche riportato di sua iniziativa un backup fallito con
lo stesso avviso benigno già noto.

**Non chiude la validazione da solo** (vedi stato in cima al documento — serve un ciclo senza
supervisione attiva, questo test è stato comunque osservato passo passo) ma è un primo segnale
concreto positivo: il meccanismo di auto-diagnosi all'apertura funziona come progettato.

**Nota collaterale**: durante l'incidente di stasera si è verificata anche una collisione
Dropbox vera (copia in conflitto sul file di questo stesso progetto, causata da scritture
concorrenti Nave/Ufficio ravvicinate) — un piccolo paragrafo di documentazione è stato recuperato
da lì e integrato sopra. Nessuna perdita, ma un promemoria concreto che scrivere lo stesso file da
entrambi i lati quasi in parallelo resta un rischio reale, non solo teorico.

## Prossimo passo concreto

**Sequenza decisa da Mauro (07/09, sera)**: costruire e validare tutto il meccanismo (loop di
auto-risveglio + protocollo mailbox) mentre `gemello-ufficio` è ancora sul **vecchio account
condiviso** — così restano disponibili `SendMessage`/`ListAgents` per correggere il tiro durante
i test, invece di fare l'handoff alla cieca prima dello switch. **Solo dopo che tutto è
verificato funzionante**, Mauro farà lo switch al nuovo abbonamento su `gemello-ufficio`.

Passi concreti da qui:
1. Definire il protocollo mailbox per questo uso (formato, direzioni, come distinguere i
   messaggi indirizzati a ciascun lato — vedi domanda aperta sopra).
2. Far progettare e costruire a `gemello-ufficio` il proprio loop di auto-risveglio
   (`ScheduleWakeup`/`/loop`), con test reali sulla convivenza con l'uso interattivo diretto.
3. Validare end-to-end (Adrian scrive in mailbox → `gemello-ufficio` reagisce entro l'intervallo
   di poll → risponde in mailbox → Adrian legge) per un numero di cicli sufficiente a fidarsene.
4. Solo a validazione conclusa: switch di `gemello-ufficio` al nuovo account.

## Incidente: processi zombie del Monitor mangiano notifiche (07/09, sera)

**Sintomo**: due messaggi di Adrian (16:09, 16:13) e uno successivo (16:54) mai notificati,
nonostante l'offset risultasse correttamente avanzato (contenuto non perso, recuperabile
leggendo il file grezzo — ma mai arrivato come evento a `gemello-ufficio`).

**Causa reale**: ogni riarmo del `Monitor` durante la serata (correzione del bug di rumore,
switch Dropbox/Z:) usava `TaskStop` sul task precedente prima di avviarne uno nuovo — ma
`TaskStop` ha rimosso la registrazione lato harness **senza uccidere il processo bash reale
sottostante**. Verificato a livello OS (`Get-CimInstance Win32_Process`): due istanze dello
script watcher ancora vive, nate in momenti diversi (16:02:35 e 16:05:39) da due riarmi
distinti mai davvero terminati. Due lettori concorrenti sulla stessa coda/offset: uno vinceva
la gara e consumava il contenuto, ma essendo un processo "orfano" (non tracciato da nessun task
id noto all'harness), il suo output non produceva nessuna notifica — un buco silenzioso, non un
crash rumoroso.

**Fix applicato**: `taskkill` diretto sui PID (non `TaskStop`, che si era già dimostrato
inefficace), verificato zero processi residui via query OS mirata, poi un solo `Monitor` pulito
riarmato.

**Lezione strutturale**: `TaskStop` non è una garanzia sufficiente che il processo sottostante
sia morto — dopo ogni riarmo di un Monitor persistente, specialmente su Windows/Git Bash, vale
la pena una verifica diretta a livello OS (`Get-CimInstance Win32_Process` filtrato sul nome
dello script) prima di fidarsi che sia rimasta una sola istanza attiva. Costo reale di non
averlo fatto prima: quasi un'ora di notifiche mancate, mitigato solo perché il contenuto restava
comunque leggibile a mano nel file grezzo.