live: diagnosi del guasto venue, disaster-SL scoperto, isolamento per asset, cron :47

Nato da "stato trades" durante una manutenzione Deribit (system_maintenance 11051,
08:57-09:20 UTC). Contati i log invece che ricordarli: 1.499 giri dal 23/06, 3 con
manutenzione, 5 traceback duri — e 4 dei 5 sono il NOSTRO gateway, non il venue.
Le release Deribit escono il martedi' alle 09:00 UTC: il cron al :07 ci cadeva dentro
per costruzione (21/07, 11/08, 18/08, 25/08).

DIAGNOSI (src/live/venue_probe.py, nuovo)
Sonda l'API PUBBLICA Deribit senza gateway e senza credenziali, e classifica il guasto:
VENUE_MANUTENZIONE / VENUE_GIU / GATEWAY / IGNOTO. Prima ogni causa stampava la stessa
riga ("conto non leggibile (offline)") con nota di diagnosi CABLATA — P4 violata, e il
18/08 il codice 11051 era gia' dentro il processo senza arrivare a chi decideva la
gravita'. Parte solo dopo un guasto: sul percorso sano costa zero. P1 rispettata: la
firma 11051 si importa da venue_watch.is_maintenance, non si ridichiara.

P9: la manutenzione dentro lo slot declassa il titolo a info, ma solo su EVIDENZA della
sonda (mai sull'orologio) e solo dentro la durata annunciata — oltre, RIALZA. Un gateway
rotto di martedi' mattina resta al massimo.

DISASTER-SL SCOPERTO (src/live/execution.py)
ensure_disaster_sl cancella i bracket incoerenti PRIMA di ripiazzarne uno: fra le due
chiamate la posizione e' senza stop. Se il ripiazzamento sollevava, l'eccezione risaliva
a main() e il guasto peggiore aveva la faccia di un errore qualunque. Ora: due tentativi,
poi stato `naked`, distinto da `place-failed` (P5). Non e' "non sono riuscito a
proteggere": e' "ho tolto la protezione e non sono riuscito a rimetterla" -> allarme
massimo, mai declassato. La SEQUENZA non e' stata invertita: piazza-poi-cancella sembra
piu' sicuro ma "sembra" non basta con soldi veri senza misurarlo.

ISOLAMENTO PER ASSET (scripts/live/book_execute.py)
Il 21/07 un 502 dentro ensure_disaster_sl su BTC ha ucciso il giro intero: nel log ETH
non compare — ne' ribilanciato ne' verificato nella protezione. Ora un asset che esplode
non ferma il ciclo, e il giro degradato esce con codice 2.

CRON :07 -> :47
Il vincolo vero non era ":07" ma "fuori dai ~26s del minuto tondo" (rate-limit per-IP
auto-saturato dal collettore catena, misura del 30/07). Il :47 lo soddisfa e in piu' sta
fuori dallo slot di release. PREVISIONE DICHIARATA (M12): 3 delle 4 finestre osservate
sono rientrate entro l'ora -> il :47 ne avrebbe scavalcate 3 su 4; se martedi' prossimo
becca comunque la manutenzione, la previsione e' sbagliata.

WATERMARK AVVELENATO DAI TEST (tests/conftest.py, nuovo)
Trovato addosso: lanciando la suite, data/live/equity_seen.json passava a $5.000 e il giro
successivo mandava un allarme Telegram FALSO ("USCITA DI FONDI -86,6%"). Non cosmetico:
cap_fallback = min(cap_config, watermark x frac) sarebbe passato da $334 a $2.500/asset,
~7,5x di leva su un conto da $668, sul ramo eq_fallback che allerta e NON blocca — cioe'
i test potevano armare il pericolo che il watermark esiste per impedire. Riparato con una
fixture AUTOUSE, non per-test: chiedere a ogni autore di ricordarsene ha gia' perso il
26/07 e il 21/08. Resta esposto lo stesso errore su trades.db e book_executions.jsonl.

BLOCCATO, NON RINVIATO
Il fallback diretto ai privati Deribit richiede chiavi API create dall'operatore: in
locale esiste solo CERBERO_TOKEN. Il gateway resta un punto singolo di guasto non
aggirabile (CLAUDE.md 5.11). La sonda dice di chi e' il guasto, non lo aggira.

Test: 20 nuovi, nessuno tocca la rete; controllo positivo fatto (5 su 7 falliscono contro
il codice vecchio). Suite 730 passati, 1 fallito — quello gia' noto di 5.9 (deriva dati).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1

docs/memory/40-produzione-e-deploy.md

@@ -800,3 +800,101 @@ e il cron lo ricostruisce ogni notte, quindi la finestra hold-out si allunga e i
 lezione del 2026-08-07 (*"un test che fallisce senza che il codice sia cambiato sta segnalando
 che i dati non sono versionati — si guarda sotto prima di toccarlo"*), e allargare una tolleranza
 per far passare un test e' esattamente la manovra che quella lezione vieta. **Resta aperto.**
+
+---
+
+## Addendum 2026-08-25 — La manutenzione del martedì: chi è rotto, e chi resta scoperto
+
+Racconto completo in `docs/diary/2026-08-25-manutenzione-deribit-e-resilienza-venue.md`.
+Qui restano i fatti citabili e i motivi, che valgono più degli esperimenti che li hanno prodotti.
+
+### I numeri, contati sui log (1.499 giri, 2026-06-23 → 2026-08-25)
+
+| esito | n | % |
+|---|---|---|
+| manutenzione Deribit | 3 | 0,20% |
+| traceback duro | 5 | 0,33% |
+| giri senza esito utile | 26 | 1,7% |
+
+**Lo slot di release Deribit è il MARTEDÌ alle 09:00 UTC**, 15-30 min annunciati. Quattro episodi,
+tutti fra le 09:00 e le 09:07: `2026-07-21` (502 visto dal gateway), `11/08`, `18/08` (giù anche
+alle 10:07 → **l'annuncio non è la durata**), `25/08` (~20 min). Il cron al `:07` ci cadeva
+**per costruzione**.
+
+🚨 **Il punto singolo di guasto non è il venue, è NOSTRO.** Dei 5 traceback, **4 sono
+`cerbero-mcp.tielogic.xyz`**: un 404 su `get_positions`, un 502, due `ReadTimeout`. Sostituire
+Deribit non toccherebbe il guasto che ci ha davvero morso. E il gateway **non è aggirabile**: le
+credenziali Deribit vivono solo lì dentro (§5.11).
+
+### I motivi — cioè la parte che chi riapre il tema deve battere
+
+- **Una nota di diagnosi cablata è peggio di nessuna nota (P4).** `conto non leggibile (offline)`
+  copriva due guasti con azioni opposte. E il 18/08 il codice **11051 era già dentro il processo**,
+  nello stesso minuto, raccolto da `livefeed`: non mancava il dato, mancava il **trasporto** del
+  dato a chi decideva la gravità.
+- **Declassare un allarme atteso (P9) è giusto, ma la finestra non è una prova.** `venue_probe`
+  declassa **solo su evidenza** della sonda (mai sull'orologio) e **solo dentro la durata
+  annunciata**: oltre, RIALZA. Senza questi due paletti si costruisce il silenzio esattamente
+  nell'ora in cui è più probabile che serva.
+- **`naked` ≠ `place-failed` (P5).** Il primo è "*ho tolto la protezione e non sono riuscito a
+  rimetterla*", il secondo "*non sono riuscito a metterla*". Solo uno lascia una posizione aperta
+  senza stop on-book, e non è mai un evento atteso: 🚨 sempre.
+- **Un guasto su un asset non deve togliere la rete all'altro.** Il 21/07 il ciclo è morto su BTC
+  e nel log **ETH non compare**: né ribilanciato, né verificato nella sua protezione. L'isolamento
+  per asset è la riparazione; il costo di non averlo era un'ora di posizione non controllata.
+- **Riparato il silenzio, NON toccata la sequenza.** `ensure_disaster_sl` continua a cancellare
+  prima e piazzare dopo. *Piazza-poi-cancella* sembra più sicuro (due STOP `reduce_only` dovrebbero
+  essere innocui) ma "dovrebbe" non basta per cambiare il ciclo di vita dei bracket con soldi veri
+  senza misurarlo. **Chi lo riapre deve portare la misura, non l'intuizione.**
+- **Il vincolo del minuto `:07` non era "il :07": era "fuori dai ~26s del minuto tondo"** (il
+  collettore catena si auto-satura il rate-limit per-IP — 12.186 risposte 429 in 26 ore, 96% nel
+  minuto `:00`, misura del 30/07). Letto così, il vincolo lascia libero qualunque minuto ≠ `:00`,
+  e il `:47` soddisfa anche il secondo (fuori dallo slot di release). **Una regola operativa va
+  riletta nella sua ragione, non nel suo valore** — altrimenti si difende un numero invece di un
+  motivo.
+
+### Previsione dichiarata, da misurare (M12)
+
+Sulle 4 finestre osservate 3 sono rientrate entro l'ora → il `:47` ne avrebbe scavalcate **3 su 4**.
+**Se al prossimo martedì il `:47` becca comunque la manutenzione, la previsione è sbagliata** e lo
+slot non è quello descritto in `venue_probe.RELEASE_*`: rileggerlo prima di spostare ancora.
+
+### Cosa resta scoperto
+
+1. **La sonda dice di chi è il guasto, non lo aggira.** Col gateway giù il libro continua ad
+   astenersi. Il fallback vero richiede **chiavi API Deribit create dall'operatore** — decisione,
+   non refactor, con una superficie di rischio propria (§5.11).
+2. **La sonda legge se il venue RISPONDE, non cosa il venue ANNUNCIA.** Il Rulebook (ADL, perdita
+   socializzata, *emergency powers*) resta non sorvegliato (§5.8).
+
+### Coda 2026-08-25 — Un test scriveva nel watermark VIVO (e ha mandato un allarme falso)
+
+Lanciando la suite completa, `data/live/equity_seen.json` è passato da **$667,68 a $5.000**; il
+giro del book alle 09:47 ha confrontato l'equity vera contro quel valore e ha spedito su Telegram
+un **`💰 USCITA DI FONDI: $5.000 → $667,68 (−86,6%)`** completamente falso.
+
+Colpevole: `test_book_live.py::test_la_formula_del_report_ha_potenza_anche_a_libro_flat` — prende
+solo `monkeypatch` (niente `tmp_path`), finge `real_equity=5000.0` e chiama `book.book_report()`,
+che **come effetto collaterale** scrive il watermark. Riprodotto isolando il singolo test.
+
+🚨 **Non era cosmetico.** `cap_fallback = min(cap_config, watermark × frac)`: con $5.000 dentro, il
+cap sarebbe passato da **$334 a $2.500/asset** — fino a **$5.000 di nozionale lordo su un conto da
+$668, ~7,5x di leva**. Il ramo che ci arriva (`eq_fallback`) **allerta e NON blocca**, per scelta
+dichiarata. **Lanciare i test poteva armare esattamente il pericolo che il watermark esiste per
+impedire.** Danno reale quel giorno: nessuno — alle 09:47 l'equity era leggibile, quindi il cap si
+è calcolato sul vero. *È andata bene per la direzione del caso, non per una protezione.*
+
+**I motivi da non ri-derivare:**
+
+- **Il perimetro di un test non è quello che il test dice di toccare: è quello che tocca il codice
+  che chiama.** Quel test non menziona il watermark, non lo importa, non lo asserisce — lo scrive
+  passando per una funzione di produzione tre livelli sotto.
+- **La riparazione per-test non regge, ed è dimostrato tre volte.** L'helper `_write_cfg` nasce per
+  questo il **26/07**; il test colpevole è del **21/08** e non lo usa; oggi la stessa scommessa ha
+  perso di nuovo. Quindi fixture **autouse** in `tests/conftest.py`: vale anche per il test che
+  qualcuno scriverà domani senza aver letto niente. Il monkeypatch esplicito di chi vuole davvero
+  pilotare il watermark gira dopo e continua a vincere.
+- **Una protezione mai vista fallire non è una protezione** → guardia in `test_cap_watermark.py`
+  che si accende se la fixture viene rimossa.
+- ⚠️ **Resta il principio più largo:** oggi è deviato **solo** il watermark. `data/live/trades.db` e
+  `data/live/book_executions.jsonl` sono esposti allo stesso errore (§5.12).