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

tests/test_cap_watermark.py

@@ -163,3 +163,30 @@ def test_la_soglia_di_salto_e_congelata():
 def test_book_execute_avvisa_sul_salto():
     src = (ROOT / "scripts" / "live" / "book_execute.py").read_text()
     assert "equity_jump" in src and "VERSAMENTO" in src
+
+
+# ---------------------------------------------------------------------------
+# GUARDIA: la suite non deve poter scrivere il watermark VIVO (2026-08-25).
+# ---------------------------------------------------------------------------
+def test_la_suite_non_scrive_il_watermark_vivo():
+    """Controllo POSITIVO della protezione in `tests/conftest.py`.
+
+    Il 2026-08-25 la suite ha scritto $5.000 in `data/live/equity_seen.json` e il giro successivo
+    del book ha mandato un allarme Telegram falso ("USCITA DI FONDI -86,6%"). Peggio: con quel
+    valore il cap di fallback sarebbe passato da $334 a $2.500 per asset — ~7,5x di leva su un
+    conto da $668, per un ramo (`eq_fallback`) che per scelta dichiarata NON blocca.
+
+    Questo test NON verifica il file vivo (dipenderebbe dal conto e da chi ha girato prima):
+    verifica che dentro un test il bersaglio sia gia' stato deviato fuori da `data/live/`.
+    Se qualcuno rimuove la fixture autouse, questo si accende.
+    """
+    import src.live.book as book
+    vivo = book.PROJECT_ROOT / "data" / "live" / "equity_seen.json"
+    assert book.EQUITY_WATERMARK != vivo, \
+        "la fixture autouse di conftest.py non sta deviando EQUITY_WATERMARK"
+    assert "data/live" not in str(book.EQUITY_WATERMARK).replace("\\", "/")
+
+    # e la scrittura deve finire davvero nel bersaglio deviato, non nel vivo
+    book.write_equity_watermark(5000.0)
+    assert book.EQUITY_WATERMARK.exists()
+    assert "5000" in book.EQUITY_WATERMARK.read_text()