PythagorasGoal/docs/diary/2026-08-25-manutenzione-deribit-e-resilienza-venue.md

# 2026-08-25 — La manutenzione del martedì, e i due difetti che ha scoperchiato

*Scritto da Claude (agente), su richiesta dell'operatore. Firmato come vuole P13: l'analisi in
prosa è opinione di un lettore fallibile, i numeri qui sotto vengono dai log e sono riproducibili.*

## Come è cominciata

Domanda dell'operatore: «stato trades». Report normale del libro di bordo — 24 fill, equity
$598,06 → $667,88 (+11,67%), 16 round-trip di cui 15 in utile, netto +39,78. Poi il `--reconcile`
ha stampato la riga che ha aperto la giornata:

```
venue: NON LETTO (HTTPError) — non e' 'zero trade', e' 'non misurato'
```

Non era il gateway. Era **Deribit in manutenzione**: `system_maintenance`, codice 11051, HTTP 503
sia sul pubblico che sul privato. Iniziata fra le **08:57:40Z** (ultimo 200 OK nei log di
`cerbero-mcp`) e le **09:01:46Z** (primo 503). Rientrata verso le 09:20 — ~20 minuti, coerenti con
i 15-30 annunciati da Deribit per le sue release.

## Cosa dicono i log, contati invece che ricordati

1.499 giri di `cron_book` fra il 2026-06-23 e il 2026-08-25:

| esito | n | % |
|---|---|---|
| manutenzione Deribit | 3 | 0,20% |
| traceback duro | 5 | 0,33% |
| giri senza esito utile | 26 | 1,7% |

E gli episodi di venue non sono sparsi:

```
2026-07-21T09:00  Tue  502 su get_positions (Deribit giù, vista dal gateway)
2026-08-11T09:07  Tue  system_maintenance 11051
2026-08-18T09:07  Tue  system_maintenance 11051   (giù anche alle 10:07)
2026-08-25T09:07  Tue  system_maintenance 11051
```

**Quattro martedì su dieci, tutti fra le 09:00 e le 09:07 UTC.** Il supporto Deribit conferma la
meccanica: le release escono il martedì alle 09:00 UTC. Il minuto `:07` del cron cadeva dentro
quella finestra — e ci cadeva per costruzione, non per sfortuna.

**Il punto singolo di guasto non è Deribit: siamo noi.** Dei 5 traceback, **4 sono il nostro
gateway** `cerbero-mcp.tielogic.xyz` (un 404 su `get_positions`, un 502, due `ReadTimeout`).

## I due difetti veri

### 1. Una riga sola per due guasti che vogliono azioni opposte

Fino a oggi qualunque guasto sul percorso Deribit stampava `conto non leggibile (offline)`, con la
nota di diagnosi **cablata**. Ma "Deribit in manutenzione" (aspetta, rientra da sola) e "il nostro
gateway è rotto" (ripara) non sono la stessa notizia. È **P4** violata, con l'aggravante di **P4
seconda metà**: *una nota di diagnosi cablata è peggio di nessuna nota*, perché si legge come una
misura.

Peggio ancora: il 18/08 **il codice 11051 era già dentro il processo**, nello stesso minuto,
raccolto da `livefeed`. Semplicemente non arrivava a chi decideva la gravità dell'allarme.

### 2. La finestra scoperta del disaster-SL — e l'asset che sparisce

`ensure_disaster_sl` ricostruisce un bracket incoerente **cancellando prima e ripiazzando dopo**.
Fra le due chiamate la posizione è senza alcuno stop on-book. Finché il ripiazzamento sollevava,
quell'eccezione risaliva fino a `main()`: il guasto peggiore (**posizione scoperta**) aveva la
stessa faccia di un errore qualunque.

E c'è il corollario che è successo davvero. Il **2026-07-21 alle 09:00 UTC** il 502 è arrivato
dentro `ensure_disaster_sl` su BTC. Nel log di quel giro **ETH non compare**: non è stato
ribilanciato e — quel che conta — **la sua protezione non è stata verificata**. Un guasto su un
asset toglieva la rete di sicurezza all'altro.

## Cosa è stato fatto

**`src/live/venue_probe.py` (nuovo).** Interroga l'API **pubblica** Deribit in diretta — niente
gateway, niente credenziali — e classifica: `VENUE_MANUTENZIONE` / `VENUE_GIU` / `GATEWAY` /
`IGNOTO`. La sonda parte **solo dopo un guasto**: sul percorso sano costa zero. Rispetta **P1**:
non ridichiara la firma 11051, la importa da `venue_watch.is_maintenance`.

Su **P9** (*un allarme massimo speso per un evento atteso è un allarme che non verrà letto il
giorno che è vero*): la manutenzione dentro lo slot declassa il titolo a ℹ️. Ma con due paletti,
perché il rischio qui è costruire il silenzio proprio nell'ora in cui serve:

- declassa **solo su evidenza** della sonda, mai sull'orologio da solo → un gateway rotto di
  martedì mattina resta 🛑;
- declassa **solo dentro la durata annunciata** (30 min) → il 18/08 alle 10:07 la manutenzione
  aveva sforato, e torna una notizia. Stessa logica di `MAINT_GRACE_HOURS`, altra domanda.

**Isolamento per asset** in `book_execute`: un asset che esplode non ferma il ciclo, e il giro
esce con codice 2 per essere contabile.

**Stato `naked`** in `ensure_disaster_sl`: due tentativi di ripiazzamento, e se falliscono
entrambi lo stato è distinto da `place-failed` (**P5**: guasti diversi si distinguono anche quando
l'azione è la stessa). Non è "non sono riuscito a proteggere": è "**ho tolto la protezione e non
sono riuscito a rimetterla**" → 🚨 sempre, **mai** declassato da P9.

Non è stata invertita la sequenza in *piazza-poi-cancella*: due STOP `reduce_only` contemporanei
sono *probabilmente* innocui, ma "probabilmente" non basta per cambiare il ciclo di vita dei
bracket su un percorso con soldi veri senza misurarlo. **Riparato il silenzio, non toccata la
sequenza.**

**Cron `:07` → `:47`.** I due vincoli sono entrambi misurati e compatibili: 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) **e** fuori dallo slot di release. Il commento in
`cron_book.sh` è stato riscritto: lasciarlo dire `:07` sarebbe stato il difetto §5.7 in versione
nuova.

**Previsione dichiarata (M12).** Sulle 4 finestre osservate, 3 sono rientrate entro l'ora. Il `:47`
ne avrebbe scavalcate **3 su 4**. Se martedì prossimo il `:47` becca comunque la manutenzione, la
previsione è sbagliata e lo slot non è quello che credo.

## Cosa NON è stato fatto, e perché

**Il fallback diretto ai privati Deribit è bloccato, non rinviato.** Le credenziali Deribit
esistono **solo dentro il gateway**: in locale c'è `CERBERO_TOKEN` e basta. Leggere conto e
posizioni scavalcando `cerbero-mcp` richiede **chiavi API create dall'operatore** sul conto
Deribit. È una decisione con una superficie di rischio propria (una chiave in più che può
trapelare), non un refactor.

È stato fatto il pezzo che non le richiede — la sonda pubblica — e resta a debito in §5.11 il
resto. Nota onesta: la sonda pubblica **dice di chi è il guasto, non lo aggira**. Con il gateway
giù il libro continua ad astenersi; sa solo dire perché.

## Test

**19 nuovi** (12 in `test_venue_probe.py`, 7 in `test_book_resilienza_venue.py`), nessuno tocca la
rete. Suite: **730 passati, 1 fallito** — il fallito è quello già noto di §5.9 (SKH01 `canonical`
1,9223 contro banda cablata `<1,9`, deriva dei dati, non del codice).

Controllo positivo fatto, perché un test mai visto fallire non dimostra niente: contro il codice
vecchio **5 dei 7** test di resilienza falliscono. Con una riserva da dichiarare — il test di
isolamento, sul codice vecchio, fallisce perché il modulo di diagnosi non esiste, non perché
dimostri l'isolamento rotto. La prova di *quel* difetto è il log del 21/07, dove ETH non compare.

---

## Coda: la suite di test ha mandato un allarme falso sul telefono dell'operatore

Il primo giro al nuovo minuto `:47` è andato bene — entrambi gli asset elaborati, entrambi i
disaster-SL verificati `ok`, exit 0 — ma nel log c'era una riga che non poteva essere vera:

```
💰 USCITA DI FONDI: $5,000.00 -> $667.68 (-86.6%) · cap/asset ora $333.84
```

Il conto non ha mai visto $5.000. Ha visto $598-668 da sempre.

**L'ho causato io**, lanciando `uv run pytest` per verificare le riparazioni di oggi.
`test_book_live.py::test_la_formula_del_report_ha_potenza_anche_a_libro_flat` prende solo
`monkeypatch` (niente `tmp_path`), sostituisce `shadow_report` con uno che dichiara
`real_equity=5000.0`, e chiama `book.book_report()` — che come **effetto collaterale** scrive
`data/live/equity_seen.json`. Riprodotto isolando il singolo test: watermark $667,68 → **$5.000**.

L'helper `_write_cfg` esisteva già proprio per questo — il difetto gemello è del **2026-07-26** —
ma quel test, aggiunto il **21/08**, non lo usa. È la terza volta che la stessa scommessa perde.

### Non era cosmetico

Il watermark alimenta il cap di fallback:

```
cap_fallback = min(cap_fisso_di_config, watermark × frac)
```

Con $5.000 dentro: `min($3.000, $2.500) = $2.500` per asset invece di `$334`. Su un conto da $668
sono fino a **$5.000 di nozionale lordo, ~7,5x di leva**. E il ramo che ci arriva è raggiungibile:
`eq_fallback` in `book_execute` **allerta e NON blocca**, per scelta dichiarata.

Cioè: **lanciare la suite di test poteva armare esattamente il pericolo che il watermark esiste
per impedire** (nota del 26/07 in `book.py` sul cap fisso e la leva 3,35x).

Danno reale oggi: **nessuno**. Alle 09:47 l'equity era leggibile, quindi il cap è stato calcolato
sull'equity vera e il watermark è stato riscritto col valore giusto. La finestra scoperta è stata
~09:25 → 09:47, e in quella finestra non c'è stato nessun giro con equity illeggibile. È andata
bene per la direzione del caso, non perché ci fosse una protezione.

### Riparazione, e perché è strutturale

`tests/conftest.py` con una fixture **autouse** che devia `EQUITY_WATERMARK` in `tmp_path` per
**ogni** test. Chiedere a ogni autore di ricordarsi il monkeypatch è la scommessa che ha già perso
due volte: la protezione deve valere anche per il test che qualcuno scriverà domani senza aver
letto niente. Un test che vuole davvero pilotare il watermark continua a funzionare — il suo
monkeypatch esplicito gira dopo e vince.

Più una guardia in `test_cap_watermark.py` che si accende se qualcuno rimuove la fixture:
controllo positivo, perché una protezione mai vista fallire non è una protezione.

**Resta aperto il principio più largo** (§5.12): un test non dovrebbe poter scrivere in
`data/live/` *affatto*. Oggi è deviato solo il watermark — `trades.db` e `book_executions.jsonl`
sono ancora esposti allo stesso errore.

### La lezione

Un **effetto collaterale su file** trasforma un test puro in un attore sul sistema vivo. Qui il
test non menzionava il watermark, non lo importava, non lo asseriva: lo scriveva passando per una
funzione di produzione tre livelli più in basso. **Il perimetro di un test non è quello che il test
dice di toccare: è quello che tocca il codice che chiama.**

---

## Seconda parte della giornata: il versamento, e le tre misure che ne sono uscite

Alle **11:03:35Z** sono atterrati **1.400 USDC**: equity **$667,88 → $2.066,88**. Il giro delle
11:47 ha ribilanciato correttamente (cap/asset $1.033, BTC +$238, ETH +$319, disaster-SL `placed`
su entrambi alla taglia nuova) — la prima volta che il ramo riparato al mattino gira sul serio.

Poi l'operatore ha chiesto tre cose in fila, e ognuna ha rotto qualcosa.

### (1) «€500/mese per 10 anni»

Rifatto sul conto vero invece che citare la tabella da $635. **Non centra**: capitale mediano
$114.934, rendita 18,35 €/g, **P(≥50 €/g) = 0,0%** su 3.000 traiettorie. Il bersaglio con €500/m
arriva al 17° anno; per averlo a 10 servono €1.718/mese.

Il numero che ordina tutto: **€100/mese in più valgono +4,07%/anno di drift**, cioè +27% su tutto
il drift del libro. Dettaglio in `30-piano-capitale-fisco.md`.

### (2) «A cosa serve XSR01, allora?» → e poi: «l'abbiamo fatto per la leva»

Due osservazioni dell'operatore, entrambe centrate, che hanno spostato la conversazione dal
candidato al **disegno**.

XSR01 ha già fallito `weights_tilt_null` (peso ottimo ~0). Ma la risposta vera è che **anche un
uplift di strategia riuscito vale meno di un bonifico modesto**, e questo si applica a qualunque
sleeve, non solo a XSR01.

Poi la misura che ha ribaltato la discussione sulla leva: **il libro non è poco levato, è FERMO**.
Esposizione lorda realizzata in 64 giorni live: mediana **0,00x**, media 0,05x, **max 0,52x** su un
tetto strutturale di 1,0x, esposto in **14 giorni su 64**. Il cap non ha mai morso: il vincolo è il
segnale. *Il basso drawdown di TP01 non viene dall'essere piccolo nel mercato — viene dallo stare
fuori dal mercato.*

⚠️ Correzione che mi sono fatto da solo: quel 78% è il **regime attuale**, non la media. Sull'intera
storia i giorni flat sono il **28,0%** — 2,7% nel 2021, 77,0% nel 2022, 75,6% nel 2026.

### (3) «Allora usiamo l'ETF quando il libro è flat» → SCARTATO

Test in `r0825_capitale_fermo.py`. **Perde** a iso-rischio (Sharpe 1,01 contro 1,40 del 50/50 e
1,35 del libro), e il null a maschera casuale lo mette al **30° percentile**: fa peggio di
commutare a caso.

E qui la parte che vale più del risultato. Stavo per scrivere un meccanismo pulito — *«il libro va
flat quando anche l'azionario soffre»* — sostenuto da un aggregato netto (SPY 4,91% nei giorni
flat contro 21,48% negli altri, −16,57%). **La scomposizione per anno lo ha demolito**: il segno
alterna, 3 anni su e 4 giù, e il **2022** — l'anno che doveva reggerlo — ha il segno **opposto**.
Artefatto di composizione: i giorni flat stanno negli **anni** brutti per l'azionario, non nei
**giorni** brutti. M9 ha fatto esattamente il suo lavoro, su di me.

### I due difetti di misurazione trovati addosso

1. **Maschera vuota vestita da risultato.** La prima versione prendeva i giorni flat dalla serie
   **de-luckata**; ma `deluck` sottrae una costante, quindi lo zero esatto sparisce. Maschera
   vuota → dinamico identico al book → e lo script ha stampato tabelle piene e un p-value. Lo ha
   rivelato solo la riga che stampava `0 = 0.0%`.
   **Regola: stampare la CARDINALITÀ di una maschera prima di usarla.**
2. **`r0822_slip_audit.py` aveva l'equity CABLATA a `636.0`** con un commento che diceva di leggerla
   dal watermark — P1 in piena regola. Il giorno del versamento avrebbe continuato a stampare $636,
   sbagliando di 3,3x proprio la sezione che esiste per dire *quando la misura scade*. Riparato
   leggendo il watermark — e poi riparato **di nuovo**, perché la prima riparazione divideva tutti i
   fill per l'equity di oggi mentre i fill del campione sono stati eseguiti a conti diversi
   ($597–$2.067). Ora la normalizzazione è **per fill**, e a $600 riproduce il 22,0% originale.

### La misura di slippage, rifatta alla taglia vera

26 fill (erano 18), taglia $6–$319. I due più grandi mai eseguiti sono di oggi e hanno preso
**1,01%** e **0,54%** della loro barra 5m, con il print **a metà del range** (q=0,50). Il caso
peggiore resta un fill da **$74 del 18/07 al 21,9%** — un sabato, nastro inesistente.

📌 **L'attrito non è funzione della taglia: è funzione di `taglia / volume della barra`.** Un fill
4,3× più grande in un'ora liquida ha fatto 20× meno partecipazione di uno piccolo in un'ora morta.
⚠️ Ma non è «assente», è **«non ancora testato»**: nel campione non c'è ancora un fill grande in una
barra sottile, e il weekend è dove TP01 fa il 38% del proprio gross.