CLAUDE.md: il trasporto degli allarmi non e' mai stato validato — un tentativo, nessun registro, stato marcato prima dell'invio

CLAUDE.md

@@ -1241,6 +1241,40 @@ Prima ondata di ricerca onesta su BTC/ETH certificati (5 track, harness condivis
   powers*, conti dormienti) non lo sorveglia nessuno; `MAINT_GRACE_HOURS`=2 **presume** gli annunci
   invece di leggerli (due `locked=true` in 4 giorni: 18/08 ~4h, 21/08 ~1h); la terza referenza non
   e' validabile sulla storia.
+- 🚨 **IL TRASPORTO DEGLI ALLARMI E' UN PUNTO SINGOLO DI GUASTO — misurato 2026-08-23, NON
+  riparato (produzione, decisione dell'operatore).** Registro `docs/research/RESULTS-0822.md`
+  (sezione NOTIFIER). Il progetto ha tarato il **rilevatore** (`venue_watch`: 1 falso allarme in 8
+  anni, controllo positivo su 22 episodi Bitfinex, margine 3x su FTX) e **mai il trasporto**.
+  `src/live/notifier.send()` fa **UN tentativo** `urlopen(..., timeout=10)`, `except Exception:
+  return False`, **nessun retry**; `notify()` ritorna `bool` e **`scripts/live/venue_watch.py:80`
+  non lo guarda**; `logs/cron_book.log` ha **0 occorrenze** di un qualsiasi esito d'invio → *quando
+  serve sapere se l'allarme e' arrivato, l'informazione non e' stata scritta* (la regola del 29/07
+  — *"se un errore si ingoia per non bloccare, si registra nel punto in cui lo si ingoia"* — non e'
+  mai stata applicata al notifier).
+  🚨 **E lo stato e' marcato PRIMA dell'invio:** in `venue_watch` la riga `new.alerted = True`
+  sta dentro la logica pura e viene persistita comunque; alle ore successive
+  `already = st.alerted and st.sign == sign` fa tornare `"WATCH"` invece di `"ALERT"` → **`notify`
+  non viene piu' chiamata per quell'episodio**. **Un 🚨 perso e' perso per l'episodio intero**, e
+  gli episodi storici durano **200-2.324 ore a segno costante**: e' esattamente il caso in cui la
+  ri-notifica non arriva mai.
+  **Taglia misurata: 6,9% di invii falliti (2/29, IC95 Wilson [1,9%, 22,0%])** sul digest
+  giornaliero. ⚠️ **Fonte dichiarata:** e' il percorso del **digest** usato come **proxy** di quello
+  d'allarme, che **non ha dati propri — ed e' questo il punto**; stessa funzione, stesso endpoint,
+  stesso timeout. ⚠️ La nota stampata (`"config Telegram assente o rete KO"`) **conflazione due
+  cause e la prima e' falsa**: le chiavi sono presenti in `.env` (verificato) → manda a controllare
+  il posto sbagliato, **stessa forma del difetto codificato il 29/07**, su un percorso diverso.
+  **Perche' conta piu' del suo numero:** l'economia del 26/07 (falso allarme 0,248% di equity
+  contro il **100%** che un vero positivo evita, break-even `p > 0,031%`) assume che l'allarme
+  **arrivi**, e questa e' l'unica mitigazione rimasta dopo la decisione *100% Deribit fino a $20k*
+  contro un rischio prezzato a **P(perso tutto) 10/18/34/64%**.
+  **Riparazione in tre pezzi indipendenti, NON eseguita:** (a) retry con backoff in `send()`;
+  (b) **registrare l'esito** nel punto in cui l'eccezione viene ingoiata; (c) marcare
+  `alerted=True` **solo a invio riuscito**. ⚠️ **(c) cambia il comportamento** — rende l'allarme
+  ripetitivo finche' non passa: verso giusto per un 🚨, sbagliato per un ⚠️ → **decisione
+  dell'operatore**, non un fix ovvio.
+  **REGOLA: un rilevatore si valida sul segnale E sul TRASPORTO** — tarare la soglia e non misurare
+  mai se il messaggio arriva lascia un punto singolo di guasto a valle di tutto il lavoro di
+  taratura, e non produce numeri, quindi non si fa notare.
 - ⚖️ **RIVALUTAZIONE DELLA STRATEGIA (2026-07-26, fine giornata) — 0 cambi, e il peso 75/25
   confermato per la TERZA volta.** Script `r0726_reeval_live_weight.py`, test
   `tests/test_reeval_live_weight.py` (6), diario `2026-07-26-reeval-strategia.md`.