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
This commit is contained in:
Adriano Dal Pastro
2026-08-25 10:27:36 +00:00
parent 2751a7efd0
commit 426735448e
12 changed files with 1136 additions and 47 deletions
+27 -4
View File
@@ -47,8 +47,10 @@ il 2026-07-26, e sei ondate lo hanno **confermato** invece che ribaltarlo.* I vi
**LIVE (soldi veri).** Deribit mainnet, **TP01 + SKH01 a 75/25**, nettati in software su **una sola
posizione per asset** (`src/live/book.py`: `W_TP01=0.75`, `W_SKH=0.25`, `WEIGHT=0.5` → 50/50 BTC/ETH).
Esecutore `scripts/live/book_execute.py`, cron **orario** `scripts/cron_book.sh` (minuto **:07**,
scelto per stare fuori dalla finestra di rate-limit per-IP). **GTAA01, XS01, VRP01, XSR01 NON sono
Esecutore `scripts/live/book_execute.py`, cron **orario** `scripts/cron_book.sh` (minuto **:47**
dal 2026-08-25; era `:07`). Due vincoli, entrambi misurati: fuori dai ~26s del minuto tondo
(rate-limit per-IP) **e** fuori dallo slot di release Deribit (**martedi' 09:00 UTC**, 15-30 min
annunciati), che il `:07` beccava — 4 volte in 63 giorni. **GTAA01, XS01, VRP01, XSR01 NON sono
nel book live.**
**RICERCA (paper).** Portafoglio a 5 sleeve `src/portfolio/sleeves.active_sleeves`:
@@ -182,14 +184,35 @@ d'ancora in modo diverso (nella differenza si cancella in parte, nel livello per
sposterebbe il libro sulla riga 4h, dove BTC **raddoppia** gli scatti del disaster-SL.
8. ⚠️ **Il Rulebook Deribit** (ADL, perdita socializzata, *emergency powers*, conti dormienti) **non
lo sorveglia nessuno**; `MAINT_GRACE_HOURS`=2 **presume** gli annunci invece di leggerli.
*Ridotto in parte il 2026-08-25:* `src/live/venue_probe.py` interroga l'API **pubblica**
Deribit e distingue **manutenzione / venue giu' / NOSTRO gateway / non vedo**, e lo slot di
release (**martedi' 09:00 UTC**) e' ora una costante dichiarata e testata. Resta scoperto il
Rulebook vero e proprio: la sonda legge se il venue *risponde*, non cosa il venue *annuncia*.
9. ⚠️ **`tests/test_wave_0726.py::test_t1_canonical_riproduce_il_backtest_ufficiale` FALLISCE**
(dal ~24-25/08): Sharpe hold-out SKH01 `canonical` **1,9223** contro la banda cablata
`1.3 < h < 1.9`. **Il codice non e' cambiato, sono cambiati i DATI**`data/raw/` e' gitignored
e il cron lo ricostruisce ogni notte, quindi la finestra si allunga e il numero deriva (verso
l'**alto**). **La banda non e' stata allargata**: si guarda sotto prima di toccarla (lezione
07/08). Suite: **710 passati, 1 fallito**.
07/08). Suite: **730 passati, 1 fallito** (25/08).
10. ⚠️ **Nessuna tabella pubblicata prima del 22/08 contiene fisco E funding insieme.** L'unica
congiunta e' quella in `30-piano-capitale-fisco.md` — le altre vanno lette con lo sconto.
11. 🚨 **Le credenziali Deribit esistono SOLO dentro il gateway** (`cerbero-mcp`): in locale c'e'
solo `CERBERO_TOKEN`. Quindi il gateway e' un **punto singolo di guasto non aggirabile**
**4 dei 5 traceback in 63 giorni** sono suoi (404 su `get_positions`, 502, due `ReadTimeout`),
ed e' l'unico pezzo della catena che possediamo. Un fallback diretto ai **privati** Deribit
(conto/posizioni/ordini) richiede **chiavi API create dall'operatore** sul conto Deribit:
e' una decisione, non un refactor. Fatto intanto il pezzo che non le richiede: la sonda
**pubblica**, che almeno dice *di chi e' il guasto*.
12. ⚠️ **Un test scriveva nel watermark VIVO** (`data/live/equity_seen.json`): lanciare la suite
ci metteva **$5.000** e il giro successivo del book mandava un allarme falso *"USCITA DI FONDI
86,6%"*. Non era cosmetico: `cap_fallback = min(cap_config, watermark × frac)` sarebbe passato
da **$334 a $2.500/asset — ~7,5x di leva** su un conto da $668, per giunta sul ramo `eq_fallback`
che **allerta e NON blocca**. ✅ Riparato il 2026-08-25 con una fixture **autouse** in
`tests/conftest.py` (strutturale: non si chiede a ogni autore di ricordarsene — quella scommessa
ha gia' perso il 26/07 e il 21/08) + guardia in `test_cap_watermark.py`. **Resta il principio:
un test non deve poter scrivere in `data/live/`; oggi e' deviato solo il watermark, non
`trades.db` ne' `book_executions.jsonl`.**
---
@@ -405,7 +428,7 @@ uv run python scripts/live/trades_db.py --report # stato libro d
uv run python scripts/live/trades_db.py --reconcile # incrocio delle 3 fonti sui fill
uv run python scripts/live/journal.py # voce del giorno (numeri + lettura)
uv run python scripts/live/analista.py --secco # analisi del giorno, senza salvare
uv run pytest # test (708)
uv run pytest # test (731: 730 ok, 1 noto §5.9)
```
```python