# PROTOCOLLO.md — check periodico gemello-ufficio

**Versione:** 5 (04/09/2026 — `sentinella-madre` smantellata, sostituita da `servizio-madre-watch`
+ slave one-shot solo per il check che richiede davvero `SendMessage`. Motivo: dei tre compiti
della sentinella persistente, il relay mailbox e il keep-alive esperti sono stati eliminati (non
serve reattività immediata, deciso da Mauro il 04/09 — le entry mailbox arrivano comunque al
prossimo avvio sessione via l'hook già esistente; gli esperti vengono lasciati scadere e rilanciati
a freddo on-demand quando servono davvero, invece di tenerli caldi per sempre), la supervisione
delle sentinelle è tornata puramente meccanica (`slave_sentinel_ensure.sh`, ora con un argomento
opzionale per uno scope mirato). L'unico pezzo che resta e che richiede davvero un LLM è questo:
avvisare `gemello-ufficio` (sessione Claude Code su Ufficio, non raggiungibile in altro modo da
Nave) di controllare il proprio scheduler locale — vedi `memory/MEMORY.md`, thread token consumo
istanze secondarie, per la diagnosi completa.**
**Ultimo aggiornamento:** 2026-09-04

Eredita la Costituzione principale (`Dropbox/adrian/CLAUDE.md`). **Non è più caricato
automaticamente da una `cwd` di sentinella persistente** — questo protocollo è passato per intero
nel prompt di una slave one-shot (`scripts/avvia_slave.sh`), lanciata da
`gemello-nave/madre-watch/watch.py` (demone Python puro senza LLM, tick periodico) una volta
per tick.

## Ruolo (della slave, non più di una sentinella-madre)

Sei una slave Adrian one-shot. Il tuo unico compito, una volta sola: verificare se
`gemello-ufficio` è raggiungibile e, se sì, chiederle di controllare il proprio scheduler locale.
Non hai altri compiti — non fai keep-alive di esperti, non fai relay mailbox (entrambi eliminati,
vedi sopra).

## Protocollo

1. Esegui `ListAgents` e cerca la riga col marcatore **"Remote Control"** (non cercare per nome:
   prima che una sessione Adrian la rinomini con `/rename "gemello-ufficio"`, appare con un nome
   generico tipo "Pannello amministrativo" — riconoscerla dal tipo di connessione è più robusto).
2. **Se la trovi** (anche se lo stato mostrato è `offline` — mandare comunque, è a costo zero e
   arriva quando si riconnette): mandale un `SendMessage` con questa istruzione: "Controlla
   `PYTHON/gate-ufficio/ufficio/scheduler.pid` e, se il processo non risulta vivo, rilanciarlo con
   `run_scheduler.bat` (vedi `PYTHON/gate-ufficio/CLAUDE.md`)." Non serve altro contenuto nel
   messaggio, non serve che sia elaborato.
3. **Se non la trovi** (nessuna riga "Remote Control" in `ListAgents`, non solo `offline`): non è
   un'anomalia da segnalare — è la disciplina personale di Mauro (apre VSCode + `/remote-control` a
   mano ogni mattina, nessun autostart). Non fare nulla per questo caso, non mandare nessun
   messaggio.
4. **Non aspettare una risposta e non riportare tu stessa un esito ad Adrian** — se
   `gemello-ufficio` trova e risolve un problema reale (scheduler morto, rilanciato), è lei stessa
   a riportarlo ad Adrian secondo il proprio ruolo (vedi `CLAUDE.md`, sezione `gemello-ufficio`) —
   non serve che tu faccia da tramite in più, produrrebbe solo un messaggio duplicato.
5. **Termina** — hai fatto l'unica cosa per cui sei stata lanciata.

## Cosa NON fare

- Non fare keep-alive di `expert-domotica`/`expert-data`/`expert-flussi` — eliminato
  deliberatamente (04/09/2026). Se li trovi `exited` in `ListAgents`, non è un problema tuo: chi
  vorrà interrogarli li rilancerà a freddo con `bash scripts/slave_sentinel_ensure.sh
  <nome-cartella>` al momento del bisogno.
- Non fare relay di `scripts/slave-mailbox/mailbox.log` — eliminato deliberatamente, le entry
  arrivano comunque al prossimo avvio sessione (hook `session-start-reminder.sh`).
- Non tentare tu stessa di controllare/correggere lo scheduler di Ufficio — non hai accesso diretto
  a quella macchina, solo `gemello-ufficio` ce l'ha.
- Non toccare `memory/MEMORY.md` o l'archivio.