# PROTOCOLLO.md — servizio-gate-watch (`watch.py`)

**Versione:** 5 (11/09/2026 — spostato in `gemello-nave/gate-watch/`, i suoi fallimenti job entrano
nel perimetro `gate-watch:` di `gemello-nave`. Eliminata la slave one-shot dedicata: prima un
fallimento lanciava una slave separata che leggeva il log e riportava via `SendMessage` diretto ad
Adrian, ora `watch.py` scrive l'evento grezzo in mailbox e `gemello-nave` — già invocata a freddo
sullo stesso evento dal demone di trigger — legge il log e spiega la causa lei stessa. Un
passaggio in meno, non uno in più. Dettaglio/decisione: `archivio/Adrian/progetti/
project_gemello_nave.md`.)
**Ultimo aggiornamento:** 2026-09-11

Eredita la Costituzione principale (`Dropbox/adrian/CLAUDE.md`). Componente meccanico esterno a
`gemello-nave` (nessun LLM in questo processo) — stessa logica di `trigger/`, `logbook/` e
`gmail-check/`: cartella propria dentro `gemello-nave/`, mai toccata da `gemello-nave` stessa.

## Cosa fa

`watch.py` fa girare `PYTHON/gate-ufficio/nave/monitor_executions.py` invariato (riusato, non
reimplementato) e reagisce alle righe classificate che stampa:

- `[avviato]`/`[warning]`: nessuna azione, solo tenute a mente per job (servono solo se il job
  fallisce, per portarle nell'evento di fallimento).
- `[concluso]` successo (`status=completed`, `exit_code=0`): scritto direttamente in mailbox
  (sender `gate-ufficio`, testo `<job>: completato regolarmente (durata Ns)`) — evento meccanico,
  nessun LLM coinvolto. Filtrato come routine dalla checklist di avvio sessione di Adrian e dal
  suo `Monitor` (stessa regola "completato regolarmente" già in uso per `check_dropbox_health`).
- `[concluso]` fallimento (qualunque altro `status`/`exit_code`, incluso `exit_code=3`): scritto in
  mailbox (sender `gate-watch`, prima riga `<job>: fallito (exit_code=N, duration=Ns), log=<path>`,
  righe successive = le ultime warning già viste durante l'esecuzione, se presenti). Il demone di
  trigger di `gemello-nave` (`gemello-nave/trigger/watch.py`) la invoca su questo evento;
  `gemello-nave` legge il log al path indicato, spiega la causa e decide se segnalare — vedi il suo
  `CLAUDE.md`, sezione Perimetro.

## Girato come servizio systemd

`servizio-gate-watch.service` (`Type=simple`, `Restart=on-failure`), installato in
`/etc/systemd/system/`. Riavviato l'11/09/2026 dopo lo spostamento fisico (path aggiornati in
`ExecStart`/`WorkingDirectory`, `daemon-reload` + `restart` — non un `enable` nuovo, il servizio
era già abilitato da prima, quindi non ha toccato il blocco assoluto di Auto Mode su
`systemctl enable`).

## Limite noto, non risolto (fuori scope per ora)

`monitor_executions.py` osserva solo eventi che accadono davvero (righe scritte nei log) — non sa
se un job schedulato in `PYTHON/gate-ufficio/nave/schedule.json` **non è nemmeno partito**
all'orario atteso (es. `gate-ufficio` non in esecuzione sul PC ufficio). Quel caso è coperto dal
perimetro `check_job_health:` (confronto attivo con lo schedule), non da questo — i due perimetri
sono complementari, non ridondanti.