Compare commits

2 Commits

Author SHA1 Message Date
Adriano Dal Pastro 11a2370027 journal: voci automatiche del 23-25/08
Giri notturni del cron. Il 23/08 e' stato rigenerato alle 00:36 del 24 col
giorno COMPLETO (24 giri invece di 20, equity $637.58, cumulato $+39.52):
la voce precedente era stata scritta alle 19:44 a giornata in corso.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-25 08:50:02 +00:00
Adriano Dal Pastro b237ad2e8b docs: compattazione di CLAUDE.md — 3458 -> 424 righe, memoria in docs/memory/
CLAUDE.md era arrivato a 310 KB (~80k token caricati a OGNI sessione) e la
sua funzione si era sdoppiata: era insieme il manuale operativo e l'archivio
di 69 filoni di ricerca. Le due cose hanno lettori diversi.

I 65 bullet-blocco sono stati spostati VERBATIM in docs/memory/ (nulla
riscritto). Verifica meccanica riga per riga prima del commit: 3272 righe
non vuote, 0 mancanti, 0 aggiunte, zero buchi e zero sovrapposizioni nella
copertura delle regioni estratte.

  10-sleeve-e-candidati.md    30 KB  TP01 XS01 VRP01 SKH01 GTAA01 XSR01
  20-ondate-e-scartati.md    126 KB  69 filoni, ogni scartato col suo perche'
  30-piano-capitale-fisco.md  59 KB  muri, versamenti, venue risk, fisco, prop
  40-produzione-e-deploy.md   66 KB  esecutore, tripwire, monitor, PRIIPs/UCITS
  50-dati-e-feed.md           14 KB  difetti del dato, catena opzioni
  60-metodo-e-gate.md          4 KB  i gate di altlib.py

In CLAUDE.md resta solo cio' che serve a non sbagliare una decisione: stato,
book live vs book di ricerca, i numeri da citare e quelli da NON citare,
7 decisioni vincolanti dell'operatore con "cosa le riapre", 6 gate
pre-registrati con la data, 9 debiti aperti non riparati, le regole di
prim'ordine (D/M/C/P/N, distillate dalle 113 righe che contenevano REGOLA),
IL DATO, metodologia, stack/struttura/comandi.

Tre fatti che erano sepolti in 3400 righe e ora stanno in testa: le TRE
baseline diverse che girano sotto il nome "libro 75/25" (spread piu' grande
di quasi tutti gli effetti misurati), il funding non modellato in nessun
backtest (-2,16%/anno), e che «N/N ancore» vale ~2 osservazioni.

Verificato prima del commit: 36/36 percorsi citati esistono su disco,
708 test collezionati, code fence bilanciati. Nessun file di codice toccato.

Convenzione aggiunta (§14) perche' il file non torni a crescere: quando un
risultato CAMBIA UNA DECISIONE si aggiorna CLAUDE.md; quando aggiunge
racconto, va in docs/memory/.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-25 08:50:02 +00:00
10 changed files with 3894 additions and 3437 deletions
+384 -3418
View File
File diff suppressed because it is too large Load Diff
+22 -19
View File
@@ -1,57 +1,60 @@
# Giornale di bordo — 2026-08-23
*Scritto 2026-08-23T19:44:44+00:00. Numeri misurati; nessuna interpretazione automatica.*
*Scritto 2026-08-24T00:36:45+00:00. Numeri misurati; nessuna interpretazione automatica.*
## Mercato
| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
|---|---|---|---|---|---|---|---|
| **BTC** | $77,254.50 | +0.20% | +22.94% | +20.52% | 43.3% | ↑ ↑ (2/3 su) | 42.4 (52° pctl 1a) |
| **ETH** | $2,427.20 | +0.17% | +29.49% | +30.46% | 69.6% | ↑ ↑ ↑ (3/3 su) | 57.0 (44° pctl 1a) |
| **BTC** | $77,750.50 | +0.84% | +23.72% | +21.29% | 43.3% | ↑ ↑ (3/3 su) | 43.2 (56° pctl 1a) |
| **ETH** | $2,464.00 | +1.69% | +31.45% | +32.44% | 69.6% | ↑ ↑ ↑ (3/3 su) | 60.3 (54° pctl 1a) |
## Libro
Equity **$637.36** · nozionale lordo $259 · leva lorda 0.41x · barra dati 2026-08-23 · 20 giri
Equity **$637.58** · nozionale lordo $260 · leva lorda 0.41x · barra dati 2026-08-23 · 24 giri
| | TP01 | SKH01 | target | posizione | azione |
|---|---|---|---|---|---|
| **BTC** | +0.150 | LONG @ 75,280.0 | $+116 | $+116 | HOLD (a target) |
| **ETH** | +0.271 | LONG @ 2,436.4 | $+144 | $+143 | HOLD (a target) |
| **ETH** | +0.271 | LONG @ 2,436.4 | $+145 | $+144 | HOLD (a target) |
## P&L
- giorno: **$+2.36** di equity (20 letture)
- giorno: **$+2.58** di equity (24 letture)
- realizzato: +5.55 netto su 2 round-trip chiusi · 1 fill · fee 0.0243
- cumulato dall'arming: **$+39.30**
- cumulato dall'arming: **$+39.52**
## Salute
- giri di `book_execute`: 20/20 *(giorno in corso)*
- giri di `book_execute`: 24/24
- eta' feed SKH all'ultimo giro: 0 min
## Lettura
*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
- `[stato]` A mercato su BTC $+116 (TP01 +0.150, SKH01 long) e ETH $+143 (TP01 +0.271, SKH01 long).
- `[disaccordo]` BTC: gli orizzonti del trend **non concordano** (2/3 al rialzo) e l'esposizione TP01 e' parziale (+0.150) — e' il meccanismo, non una scelta di oggi.
- `[stato]` A mercato su BTC $+116 (TP01 +0.150, SKH01 long) e ETH $+144 (TP01 +0.271, SKH01 long).
- `[leva]` Leva lorda **0.41x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 0.59x.
- `[pnl]` Equity $+2.36 con 1 fill e 2 round-trip chiusi (realizzato $+5.55 netto).
- `[concentrazione]` 📌 **Il 102% di tutto il P&L cumulato ($+39.30) viene dagli ultimi 7 giorni.** Oltre il 100% perche' **il periodo precedente era in perdita**: senza questi 7 giorni il libro sarebbe sotto. Un risultato concentrato in una finestra non e' un tasso di rendimento: e' un evento.
- `[drawdown]` 📌 Equity **-1.18%** sotto il picco ($644.98). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
- `[vol]` BTC: implicita 42.4 contro realizzata 30g 43.3 (sotto); DVOL al 52° pctl di un anno; IV-rank espandente 0.18 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
- `[vol]` ETH: implicita 57.0 contro realizzata 30g 69.6 (sotto); DVOL al 44° pctl di un anno; IV-rank espandente 0.18 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
- `[pnl]` Equity $+2.58 con 1 fill e 2 round-trip chiusi (realizzato $+5.55 netto).
- `[concentrazione]` 📌 **Il 102% di tutto il P&L cumulato ($+39.52) viene dagli ultimi 7 giorni.** Oltre il 100% perche' **il periodo precedente era in perdita**: senza questi 7 giorni il libro sarebbe sotto. Un risultato concentrato in una finestra non e' un tasso di rendimento: e' un evento.
- `[drawdown]` 📌 Equity **-1.15%** sotto il picco ($644.98). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
- `[vol]` BTC: implicita 43.2 contro realizzata 30g 43.3 (sotto); DVOL al 56° pctl di un anno; IV-rank espandente 0.20 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
- `[vol]` ETH: implicita 60.3 contro realizzata 30g 69.6 (sotto); DVOL al 54° pctl di un anno; IV-rank espandente 0.23 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
- `[evidenza]` 📌 Campione a oggi: **61 giorni, 12 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
## Analisi (agente)
*Scritta da `claude-opus-5` il 2026-08-23T19:45:53+00:00. Prosa di un modello: puo' sbagliare, e non e' una misura. Controllo sui numeri: **ok**.*
*Scritta da `claude-opus-5` il 2026-08-24T00:37:10+00:00. Prosa di un modello: puo' sbagliare, e non e' una misura. Controllo sui numeri: **sospetta**.*
Il fatto nuovo non è il P&L di oggi ma il 19 agosto: dal 13 al 18 il libro è stato fermo a $597.12, zero fill, zero posizioni, e tutto quello che si vede adesso viene dai cinque giorni successivi. La concentrazione segnalata dalle regole ha quindi una lettura alternativa altrettanto compatibile: quei sette giorni sono anche gli unici in cui il libro è stato a mercato, e coincidono con un movimento del sottostante di +22.94% su BTC e +29.49% su ETH. Con TP01 e SKH01 entrambi long su entrambi gli asset, la finestra non separa l'edge dal beta a un rialzo forte, né il trend dal breakout. La perdita precedente citata dalle regole cade prima del 13 agosto e non è misurabile qui.
> ⚠️ numeri non presenti nella pagina: 327
Rispetto ai giorni scorsi l'attività si spegne: 1 fill contro i 3, 4, 5 e 2 dei quattro precedenti, entrambe le gambe a target, e il target BTC scende da $+185 a $+116 mentre il prezzo fa +0.20%. Sul BTC l'orizzonte intermedio resta giù (↑ ↓ ↑) nonostante +20.52% a 30 giorni: il rialzo ha riacceso gli estremi, non il centro.
Il libro esce dal letargo: sei giorni fermi a $597.12 senza fill fino al 18/08, e da allora quattro giorni di lavoro consecutivi. Oggi però è il primo della serie in cui la meccanica si ferma: 1 fill, 2 round-trip chiusi, entrambe le gambe a HOLD (a target), scarto di $1 su ETH. Il libro non sta più costruendo la posizione, la sta tenendo — e i $+2.58 di equity sono per la quasi totalità marcatura, non esecuzione, dato che il realizzato netto è $+5.55.
Da guardare senza allarme: l'equity di giornata ($+2.36) è sotto il realizzato ($+5.55) con entrambi i sottostanti in chiusura positiva.
Il nozionale, però, è sceso: $260 lordi contro i $327 impliciti nelle posizioni di ieri, e la leva a 0.41x resta lontana dal tetto di 1.00x pur con TSMOM a 3/3 su entrambi gli asset e la settimana a +23.72% e +31.45%. Il vol-target lavora contro il segnale: RV30 di ETH al 69.6% comprime la size proprio dove la direzione è più forte. Non è un malfunzionamento, è la definizione dello sleeve.
Il 9.00 di ieri e il 1.15% dal picco sono la prima flessione della finestra: leggerla come "il rally si sta esaurendo" o come normale respiro di quattro giorni in salita è ugualmente compatibile con questi dati — 61 giorni e 12 round-trip non separano le due letture, né lo fa la regola `[concentrazione]`.
L'implicita sta sotto la realizzata su entrambi (43.2 vs 43.3, 60.3 vs 69.6): VRP01 resta fermo per IV-rank, ma è lo stato in cui vendere vol sarebbe meno remunerativo, non più. Nulla da controllare a mano.
## Nota
+57
View File
@@ -0,0 +1,57 @@
# Giornale di bordo — 2026-08-24
*Scritto 2026-08-25T00:37:37+00:00. Numeri misurati; nessuna interpretazione automatica.*
## Mercato
| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
|---|---|---|---|---|---|---|---|
| **BTC** | $78,981.50 | +1.58% | +22.48% | +22.78% | 43.4% | ↑ ↑ ↑ (3/3 su) | 43.4 (59° pctl 1a) |
| **ETH** | $2,483.15 | +0.78% | +29.85% | +32.54% | 69.6% | ↑ ↑ ↑ (3/3 su) | 58.4 (49° pctl 1a) |
## Libro
Equity **$642.02** · nozionale lordo $334 · leva lorda 0.52x · barra dati 2026-08-24 · 24 giri
| | TP01 | SKH01 | target | posizione | azione |
|---|---|---|---|---|---|
| **BTC** | +0.449 | flat | $+108 | $+189 | SELL $-81 |
| **ETH** | +0.271 | LONG @ 2,436.4 | $+145 | $+145 | HOLD (a target) |
## P&L
- giorno: **$+4.44** di equity (24 letture)
- realizzato: +3.22 netto su 2 round-trip chiusi · 2 fill · fee 0.0520
- cumulato dall'arming: **$+43.96**
## Salute
- giri di `book_execute`: 24/24
- eta' feed SKH all'ultimo giro: 0 min
## Lettura
*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
- `[stato]` A mercato su BTC $+189 (TP01 +0.449, SKH01 flat) e ETH $+145 (TP01 +0.271, SKH01 long).
- `[leva]` Leva lorda **0.52x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 0.48x.
- `[pnl]` Equity $+4.44 con 2 fill e 2 round-trip chiusi (realizzato $+3.22 netto).
- `[concentrazione]` 📌 **Il 102% di tutto il P&L cumulato ($+43.96) viene dagli ultimi 7 giorni.** Oltre il 100% perche' **il periodo precedente era in perdita**: senza questi 7 giorni il libro sarebbe sotto. Un risultato concentrato in una finestra non e' un tasso di rendimento: e' un evento.
- `[drawdown]` 📌 Equity **-0.76%** sotto il picco ($646.95). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
- `[vol]` BTC: implicita 43.4 contro realizzata 30g 43.4 (sotto); DVOL al 59° pctl di un anno; IV-rank espandente 0.20 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
- `[vol]` ETH: implicita 58.4 contro realizzata 30g 69.6 (sotto); DVOL al 49° pctl di un anno; IV-rank espandente 0.21 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
- `[evidenza]` 📌 Campione a oggi: **62 giorni, 14 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
## Analisi (agente)
*Scritta da `claude-opus-5` il 2026-08-25T00:38:01+00:00. Prosa di un modello: puo' sbagliare, e non e' una misura. Controllo sui numeri: **ok**.*
Il libro esce dalla settimana ferma: dal 14 al 18 agosto l'equity era immobile a $597.12 con zero fill, e il P&L cumulato di $+43.96 nasce tutto dopo. Oggi è la prima giornata in cui entrambi gli asset mostrano TSMOM 3/3 su e il libro è a mercato su tutti e due, ma l'esposizione non cresce: il target BTC scende a $+108 contro una posizione di $+189 e la macchina vende $-81. È un dettaglio che merita di essere letto bene — il prezzo BTC sale (+1.58% oggi, +22.48% a 7 giorni) e il libro riduce: è il vol-targeting che risponde alla RV30 al 43.4%, non un cambio di segno del trend. La stessa cosa si può descrivere come "il libro incassa forza" oppure come "il libro perde esposizione proprio nella settimana che gli ha dato il risultato": entrambe le letture sono compatibili con questi numeri, e quale sia giusta non è determinabile su 62 giorni.
Insolito rispetto ai giorni scorsi: il 22 agosto era l'unico delta negativo (-$9.00) con 0 round-trip, mentre oggi $+4.44 arriva con 2 fill e 2 round-trip chiusi — la giornata più tranquilla dell'ultima settimana per movimento, non per esito. Salute nominale: 24/24 giri, feed SKH a 0 minuti.
Nulla qui richiede un intervento. L'unica cosa da tenere d'occhio nei prossimi giorni è se le vendite di ribilanciamento su BTC continuano mentre il prezzo sale: sarebbe il comportamento atteso, ma è anche il modo in cui questo libro restituirebbe un guadagno concentrato.
## Nota
*(vuota — campo dell'operatore)*
+47
View File
@@ -0,0 +1,47 @@
# Giornale di bordo — 2026-08-25
*Scritto 2026-08-25T00:37:36+00:00. Numeri misurati; nessuna interpretazione automatica.*
## Mercato
| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
|---|---|---|---|---|---|---|---|
| **BTC** | $78,810.00 | -0.22% | +21.82% | +20.58% | 43.4% | ↑ ↑ ↑ (3/3 su) | 43.5 (60° pctl 1a) |
| **ETH** | $2,477.35 | -0.23% | +29.22% | +26.81% | 68.7% | ↑ ↑ ↑ (3/3 su) | 58.5 (49° pctl 1a) |
## Libro
Equity **$642.56** · nozionale lordo $256 · leva lorda 0.40x · barra dati 2026-08-24 · 1 giri
| | TP01 | SKH01 | target | posizione | azione |
|---|---|---|---|---|---|
| **BTC** | +0.449 | flat | $+108 | $+111 | HOLD (a target) |
| **ETH** | +0.271 | LONG @ 2,436.4 | $+146 | $+145 | HOLD (a target) |
## P&L
- giorno: **$+0.54** di equity (1 letture)
- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
- cumulato dall'arming: **$+44.50**
## Salute
- giri di `book_execute`: 1/1 *(giorno in corso)*
- eta' feed SKH all'ultimo giro: 0 min
## Lettura
*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
- `[stato]` A mercato su BTC $+111 (TP01 +0.449, SKH01 flat) e ETH $+145 (TP01 +0.271, SKH01 long).
- `[leva]` Leva lorda **0.40x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 0.60x.
- `[pnl]` Equity $+0.54 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
- `[concentrazione]` 📌 **Il 102% di tutto il P&L cumulato ($+44.50) viene dagli ultimi 7 giorni.** Oltre il 100% perche' **il periodo precedente era in perdita**: senza questi 7 giorni il libro sarebbe sotto. Un risultato concentrato in una finestra non e' un tasso di rendimento: e' un evento.
- `[drawdown]` 📌 Equity **-0.68%** sotto il picco ($646.95). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
- `[vol]` BTC: implicita 43.5 contro realizzata 30g 43.4 (sopra); DVOL al 60° pctl di un anno; IV-rank espandente 0.20 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
- `[vol]` ETH: implicita 58.5 contro realizzata 30g 68.7 (sotto); DVOL al 49° pctl di un anno; IV-rank espandente 0.21 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
- `[evidenza]` 📌 Campione a oggi: **63 giorni, 14 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
## Nota
*(vuota — campo dell'operatore)*
+333
View File
@@ -0,0 +1,333 @@
# Sleeve, book e candidati
> Estratto **verbatim** da `CLAUDE.md` il 2026-08-25 durante la compattazione.
> Le cinque gambe del book, il portafoglio attivo e i candidati in forward-monitor.
Ogni numero va letto con la sua banda d'ancora e la sua lente.
> Il testo non e' stato riscritto: e' la memoria originale, spostata.
---
- **TP01 Trend Portfolio — strategia DIFENSIVA robusta (non alpha)** —
`src/strategies/trend_portfolio.py`. TSMOM multi-orizzonte (1-3-6 mesi) vol-targeted, long-flat,
50/50 BTC+ETH. Config canonica **PORT LF1d** (**>=12h, 1d raccomandato**, vol-target 20%, leva cap 2x):
**FULL Sharpe ~1.30, maxDD ~14%; HOLD-OUT 2025-26 Sharpe ~0.31 / +3.5%** mentre il buy&hold 50/50
faceva 39%/DD60%. Verificata indipendentemente col gauntlet onesto (hold-out + cross-asset +
plateau + deflated-Sharpe 0.999): **regge**. **Valore = taglio del drawdown ~6× vs buy&hold**, NON
generazione di ritorno (CAGR ~16% vs ~48% del buy&hold sul toro).
⚠️ **LOOK-AHEAD (2026-06-19):** un ffill MIXED-TIMEFRAME su barre open-labeled gonfiava il 4h
(~1.60 → reale ~1.1). Il calcolo per-singolo-TF è leak-free, ma **NON scendere sotto le 12h**:
costi+overfitting dominano senza vantaggio (FULL Sh piatto ~1.3 da 12h a 4h; hold-out migliore a 1d).
Deploy/paper a **1d**. Diari `2026-06-19-tp01-verification.md` / `-tp01-lookahead-fix-lf.md`.
Paper/forward: `scripts/live/paper_portfolio.py` (TP01+XS01, 1d). Test: `tests/test_trend_portfolio.py`.
(Il vecchio `paper_trend.py` standalone TP01 è RITIRATO in `Old/scripts/live/` 2026-07-17 — inerte
dal 2026-06-19, non in cron, sostituito da `paper_portfolio`.)
Ri-verifica: `scripts/analysis/{verify_tp01,stress_tp01,tp01_lowfreq}.py`.
⚠️ **ANCHOR TIMING-LUCK (2026-07-02, confermato da scettico):** l'hold-out ~0.31 è calcolato
sull'ancora daily 00:00 UTC, che è la **migliore delle 24 possibili** (mediana ancore 0.04, banda
[0.13,+0.30]; P~0.86 che una qualsiasi ancora mostri uno spike così per puro caso) → l'hold-out
2025-26 NON risolve l'edge di ritorno di TP01; ciò che regge a OGNI ancora è il **taglio del DD**
(7-10% vs ~60% B&H). FULL/plateau/deflated-Sharpe/gate INVARIATI (h=0 al 31° pctl su FULL).
Regola: i futuri numeri hold-out di strategie a ribilanciamento ancorato si citano con la banda
d'ancora. Diario `2026-07-02-timing-crt-wave.md`; script `scripts/research/r0702_tp01_offset.py`
+ `r0702_skeptic_offset.py`.
- **XS01 Cross-Sectional Momentum (Hyperliquid) — DIVERSIFICATORE che migliora il portafoglio** —
`src/portfolio/sleeves.py:_xsec_returns`. Market-neutral su **19 alt liquidi major** Hyperliquid (1d,
dal 2024): ogni 10g long i 5 più forti / short i 5 più deboli, vol-target 20%. **Scorrelato a TP01
(~0.12).** Affinato (2026-06-19): **(a) blend di lookback [30,90]** (z-score cross-sectional mediato,
come il multi-orizzonte di TP01); **(b) gate di dispersione p30** (entra solo se la dispersione
cross-section del momentum supera il percentile espandente causale, altrimenti flat — XS è rumore in
regime compatto). Standalone FULL Sh **1.50** / HOLD 1.71 / DD 11%, plateau robusto (lookback, gate
p15-35). **Caveat:** storia ~2.5 anni; STAT-MODE (book a 19 gambe non eseguibile a 2k, serve ~20k) →
monitor forward. NB il gate concentra XS nei regimi dispersi (2025-26 = hold-out alta-dispersione).
⚠️ **PHASE TIMING-LUCK (2026-07-02):** i numeri headline sono sulla fase 0 del ciclo H=10, che è
al **15° pctl di DD** (10.8% vs ~15.5% fase tipica, 29% peggiore) e 85° di FULL fra le 10 fasi
(HOLD solo 65°, non estremo); P(spike per caso)≈0.91-0.94. Lens onesta = **ensemble di fase:
FULL 1.25 / HOLD 1.31 / DD 10.9%**; a fase mediana FULL 1.08/HOLD 1.10/DD 21%. La decisione di
ammissione @15% regge (0 fasi negative, 8/10 FULL≥1.0), i numeri 1.50/1.71/11% no → citarli con
banda di fase. Ora-del-giorno NON testabile (solo 1d HL). Script `scripts/research/r0702_anchor_xs01.py`;
diario `2026-07-02-anchor-audit-xs01-skh01.md`.
Ricerca `scripts/portfolio/{xsec_research,xsec_blend,xsec_dispgate}.py`. Diari `2026-06-19-hyperliquid-xsec`
/ `-xsec-blend` / `-xsec-dispgate` / `-xsec-universe-expansion` / `-trend-multiasset`.
- **PORTAFOGLIO ATTIVO = TP01 (33%) + XS01 (15%) + VRP01 (12%) + SKH01 (20%) + GTAA01 (20%)**
(`src/portfolio/sleeves.active_sleeves`): TP01+XS01 combinato **FULL Sharpe 1.55, HOLD-OUT 1.55,
DD 4.4%**. Aggiunto **VRP01** (options short-vol, sotto): TP01+VRP01 da solo fa FULL Sh 1.30→1.44 /
HOLD 0.31→0.40 a peso 20%. **Aggiunto SKH01-V2-DD @25% effettivo (2026-06-23, sotto)**: 4-sleeve
**FULL Sharpe 1.68→2.13, HOLD-OUT 1.63→2.30, DD full 14.3%→7.8%** (Skyhook quasi-ortogonale,
corr ~0.09). **Aggiunto GTAA01 @20% effettivo (2026-07-01, i 4 preesistenti scalati ×0.80):**
trend difensivo equity 6-ETF su IB (`src/portfolio/gtaa.py`, ~30 anni storia, validato 2026-06-22
su OOS equity 2015+ INDIPENDENTE dall'hold-out crypto, corr al book ~+0.10) → 5-sleeve
**FULL Sharpe 2.12→2.24, HOLD-OUT 2.21→2.46, DD full 7.8%→6.2%** (costo dichiarato: CAGR full
23.3→18.8%; 2022 unico anno con dSh). Uplift positivo in-sample E su tutte le finestre disgiunte
(vs EW-STR refutato lo stesso giorno). Convenzioni: weekend/festivi equity = 0.0 (capitale IB
fermo, non riciclato); attivazione nel book all'era crypto 2019-03; **il book live Deribit
(`deribit_book_sleeves` TP01+SKH01 75/25) NON lo include** (GTAA in paper_combo dal 2026-06-23).
Test `tests/test_gtaa_sleeve.py`; diario `2026-07-01-strategy-wave-6threads.md` (addendum GTAA).
Report `scripts/portfolio/run_portfolio.py`. Sleeve a date d'inizio diverse → outer-join con pesi
rinormalizzati (TP01/SKH01/GTAA dal 2019*, VRP dal 2021, XS dal 2024; *GTAA troncato all'era book).
⚠️ **ANCHOR-LUCK del book — MISURATO 2026-07-26 (la stima del 02/07 era ottimista su 3/3).**
I numeri canonici sono calcolati con TUTTI e cinque gli sleeve alla loro ancora canonica. Il
02/07 la correzione fu **stimata a occhio** sommando le fortune marginali (HOLD ~1.9-2.1, FULL
~2.0-2.2, "DD ~6% invariato"); il 26/07 è stata **misurata sullo spazio congiunto** (24×10×7×23×5
= 193.200 configurazioni, 2000 estrazioni uniformi indipendenti, `r0726_loo_deluck.py`):
| | canonico | pctl | **stima onesta = mediana** | banda p10-p90 |
|---|---|---|---|---|
| Sharpe FULL | +2.222 | 97.0° | **+1.95** | [1.81, 2.12] |
| Sharpe HOLD-OUT | +2.364 | **99.6°** | **+1.54** | [1.11, 1.91] |
| maxDD FULL | 6.07% | 12.0° | **6.85%** | [5.99, 7.94] |
**Solo 9 estrazioni su 2000 battono l'hold-out canonico.** Il book resta positivo e diversificato
a ogni ancora, ma **i numeri da citare sono 1.95 / 1.54 / 6.85%**, non i canonici.
⚠️ **Lezione: la somma delle fortune marginali NON è la mediana congiunta** — sbagliava di +0.82
di Sharpe hold-out, più di quasi tutti gli uplift per cui in questo progetto si è discusso se
ammettere uno sleeve. Quando serve la banda di un AGGREGATO si campiona lo spazio congiunto; gli
audit uno-sleeve-alla-volta (02/07, 03/07) restano validi per giudicare *quello* sleeve.
Diari `2026-07-02-anchor-audit-xs01-skh01.md` (originale) e `2026-07-26-loo-deluck.md` (misura).
🚨 **«POSITIVO IN N/N ANCORE» NON E' N OSSERVAZIONI — misurato 2026-08-23, e tocca OGNI bullet
di questo file che cita una banda d'ancora.** Correlazione media fra le **24 ancore di TP01
0,631 → N_eff 1,55**; fra le **10 fasi di XS01 0,790 → N_eff 1,23**. **E non si salva sulla
differenza appaiata:** la componente comune **non si cancella** (corr 0,593 → N_eff 1,64-2,24) —
era l'attesa a priori del critico ed e' stata **REFUTATA**. Sulla stessa grandezza, la **banda
d'ancora e' 4,3x piu' stretta dell'IC95 bootstrap, che CONTIENE LO ZERO** (su XS01 il rapporto e'
3,8x: due misure indipendenti, stesso fattore ~4).
⚠️ **Cio' che NON significa: che i verdetti cadano.** Le decisioni prese con l'audit d'ancora
poggiano anche su iso-vol, maxDD, selection-on-holdout ed edge lordo. **Cade la PRECISIONE dei
numeri, non la DIREZIONE delle decisioni.**
**REGOLE:** (a) «N/N ancore» si cita come **robustezza alla SCELTA dell'ancora**, ~2 osservazioni
indipendenti — **non come N prove**; (b) **la banda d'ancora NON e' un intervallo di confidenza**
e non va usata al posto di uno; (c) **non attaccare un p-value a un conteggio di ancore o di
finestre sovrapposte** (caso preso in fallo: un «test dei segni 12/12, p=0,0005» su finestre 30g
sovrapposte *e* selezionate come le peggiori).
- **SKH01-V2-DD "Skyhook" — DIVERSIFICATORE quasi-ortogonale (research)** — `src/strategies/skyhook.SKH01_V2_DD`,
sleeve `src/portfolio/sleeves._skyhook_returns`. Sistema dual-TF (segnale 690m / exec 230m) regime
(BuzVola/BuzVolume tipo-Chande) AND pattern (Donchian breakout), NON trend-follower, L/S. Vincitrice
di 2 onde multi-agente (la 2ª = DD-reduction): exit a **percentuale fissa ASIMMETRICA** (long sl4%/tp10%,
short sl2%/tp8% più stretto) → standalone **maxDD BTC 21% / ETH 27% (<30%)**, minFull +0.99, minHold
+1.26, causale (0/400), fee-surviving 0.40%RT. Marginal vs TP01 **ADDS** (corr 0.09, has_insample_edge,
robust_oos multicut 7/7, is_hedge=False); blend 0.75·TP01+0.25·SKH **hold-out 0.31→1.17**. Verificato
leak-free + 2 scettici. **CAVEAT:** equity daily-step (Sharpe lens), ETH DD margine sottile, book 230m
(costi ribilanciamento da verificare a deploy) → research win, forward-monitor. Diario `2026-06-23-skyhook.md`.
⚠️ **GRID TIMING-LUCK (2026-07-02, più forte di TP01):** i numeri headline sono sull'offset 0 della
griglia 230m/690m, al **93-98° pctl dei 23 offset a priori** — minHold +1.26, blend 1.17 e book
HOLD 2.44 sono il MASSIMO dei 23 (mediane: minHold +0.39, blend 0.72, book 1.96); spike, non
plateau (±30m crolla); P(spike)≈0.70. **Il gate DD<30% (criterio di selezione di V2-DD) fallisce
in 15/23 offset** (mediana ETH 29.2%). Regge de-luckato: uplift blend positivo a TUTTE le 23 fasi
(min +0.18, med +0.42) + corr 0.05-0.11 → ADDS sopravvive ridimensionato. **LIVE (SKH=25% del book
Deribit):** path reale cron orario + exit software → book 50/50 FULL 1.46→1.19 / HOLD 1.64→1.15 /
DD 18→25%; nei crash gap-through-stop reale (sl2% modellato → 11/23% realizzato). Pesi/book
INVARIATI (ogni cambio passa weights_tilt_null). **Follow-up CHIUSO 2026-07-24**
(`scripts/research/r0724_skh_live_weight.py`): sul path live (lente hourly, 23 offset) il peso
ottimale de-luckato È 0.25 (argmax mediana-IS di banda, plateau 0.20-0.30; w=0.30 passa il gate
solo a off0 = ancora fortunata, fallisce a offset mediano) e la cadenza 230m vale ~+0.01/+0.02 Sh
mediano (rumore: il degrado live è il fill-al-livello, ~+0.35 Sh, che nessun cron recupera) →
**book 75/25 e cron orario CONFERMATI**; diario `2026-07-24-skh-live-weight.md`.
Script `scripts/research/r0702_anchor_skh01.py`; diario `2026-07-02-anchor-audit-xs01-skh01.md`.
- **VRP01 Options Short-Vol — DIVERSIFICATORE da FinanceOld/OptionsAgent** — `src/portfolio/sleeves._vrp_combo_returns`.
Put credit spread settimanale (vendi put -0.28, compra put -0.10) gated su IV-rank. Idee portate da
`../FinanceOld/OptionsAgent` (Bear Call Spread + gate d'ingresso). Migliora il lead VRP nudo
(options_vrp_lab): **(a) defined-risk** taglia la coda (worst-week -16.6%→-7.4%, DD 33%→14%);
**(b) gate IV-rank>0.30** = vendi vol solo ricca → ribalta HOLD-OUT da -0.25 a +0.28 (l'alpha è il
filtro di regime). Standalone **FULL Sh 1.10, HOLD 0.60, DD 12%**, positivo/piatto ogni anno (2022
crash incluso). Scorrelato a TP01 (~+0.01-0.07). **CAVEAT:** premio MODELLATO su DVOL ATM (skew non
esplicito), book a 1d, f di stress reale non catturato → LEAD robusto, non deploy pieno. Ricerca
`scripts/research/options_vrp_v2.py` (vs baseline `options_vrp_lab.py`). Test `tests/test_vrp_sleeve.py`.
⚠️ **ANCHOR-AUDIT CHIUSO + ondata "migliora e proteggi" (2026-07-03, 7 filoni + 2 lenti + scettico):
VRP01 NON è migliorabile e la protezione DD si compra SOLO con la size.** (a) **Anchor-luck (ciclo
settimanale, 7 fasi): PRIMO sleeve SENZA firma di luck** — la fase canonica è la PEGGIORE delle 7 su
FULL (1.09 = 7° pctl) e su DD (11.8% = 93° pctl), mediana su HOLD (0.59); spike bootstrap NEGATIVO →
i numeri di ammissione FULL 1.10/HOLD 0.60/DD 12% sono CONSERVATIVI, non gonfiati. Da ora si citano
con banda: ShFULL [1.09,1.83], ShHOLD [0.03,1.11], DD [5.7,11.8%]; edge OOS f-dipendente (f=0.8 →
HOLD~0). **Con questo l'audit anchor è completo su 4/4 sleeve ancorati.** (b) Griglia 288 strutture:
nessuna batte VRP01 (DSR 0.000; metà griglia = 3ª occorrenza "0-perdite/Sharpe implausibile" dopo
CC01/ALB-A → gate `implausible_sharpe` alzato di priorità). (c) 4 overlay DD (exit-spike/SL-MTM/
ala-coda/cooldown): 4/4 REFUTED dal null de-levering — la protezione crash vive già nel gate
d'ingresso IV-rank. (d) Gate nuovi: 4° fallimento su 4 (l'alpha è il binario IV-rank>0.30). (e)
Sizing: 12% deploy ≈ 0.27 Kelly onesto (anti-rovina); ⚠️ NON confondere col 12% di PESO del book
(~0.014 Kelly, fattore 19x). (f) Gate term-structure VIX/VXV su SPX (ΔSh +0.90, DSR 0.992) =
**confound di modello al 100%** (la var del gate coincide con l'errore BS-flat vs term-structure) →
nuova regola: riprezzare term-structure-consistent prima di credere a un gate vol su strutture
BS-flat. Book/pesi INVARIATI. Diario `2026-07-03-vrp-improve-dd.md`; script `scripts/research/r0703_vrpimp_*.py` (7 file).
Diario `2026-06-20-financeold-analysis-vrp-v2.md`.
⚠️ **f MISURATO SULLE QUOTE REALI = 0.73, NON 1.0 (2026-07-30) — i numeri di ammissione vanno
citati col f.** Primo confronto del prezzatore del sleeve con la catena Deribit mainnet vera
(`scripts/research/r0730_vrp_real_quotes.py`, dati cerbero-bite). Su 8/8 scadenze settimanali con
ENTRAMBE le gambe quotate (delta realizzati 0.270/0.099 contro target 0.280/0.100), agli
STESSI strike: **f del credito NETTO 0.73** (IC95% bootstrap [0.698, 0.780], **0/15 osservazioni
≥1.0**; 0.80 a mid). **Meccanismo, non rumore:** IV(corta)DVOL **+0.8pp** ma IV(lunga)DVOL
**+7.5pp** → il modello prezza a vol ATM anche l'ala che si COMPRA, che costa **~2.3× il modello**
→ il credito netto si comprime del 27%. **Il difetto non è nel premio incassato ma nella
protezione comprata**, cioè proprio il "(a) defined-risk" per cui v2 fu promosso.
**Conseguenza standalone (solo f cambiato):** f=1.00 → FULL 1.08 / HOLD **+0.58**; f=0.80 → 0.51 /
**0.02**; f=0.73 → 0.31 / **0.23**. **Book 5-sleeve** (VRP01 12%, ancore canoniche): FULL
2.215→2.146 (Δ−0.069), HOLD 2.347→2.244 (Δ−0.103), DD invariato → **dentro la banda d'ancora**,
ma il LOO del 26/07 dava a VRP01 +0.122 di FULL: **~metà era il prezzo che il modello si faceva da
solo** (l'audit d'ancora corregge la fortuna di calendario, non l'ottimismo di prezzo).
⚠️ **La calibrazione del 20/06 NON è contraddetta, è replicata:** misurava la **sola gamba corta**
(qui 1.02, implementazione indipendente). **REGOLA: il f di una struttura multi-gamba non è il f
di una sua gamba — misurare la sola gamba venduta dà la risposta sbagliata con segno
rassicurante.** Congelata in `tests/test_cb_chain_vrp.py`.
**PROFIT-TAKE al 50% del credito — REFUTED (2026-07-30, 3° filone).**
`scripts/research/r0730_vrp_profit_take.py`, test `tests/test_vrp_profit_take.py` (16), diario
`2026-07-30-vrp-profit-take.md`. **Book/pesi/cron/config INVARIATI.** VRP01 tiene FINO A
SCADENZA (`S1 = px[i+tn]`, nessuna gestione infra-settimana) e il profit-take era l'unico grado
di liberta' non misurato: gli overlay del 03/07 erano tutti sul lato del RISCHIO. Replica del
sleeve **bit-exact** (max|diff| = 0.0) prima di ogni delta. Esito con **fee reali per gamba**:
canonico ShFULL **1.32** → PT25 0.22 / **PT50 0.18** / PT75 0.45; **null del de-levering
REFUTED 6/6** (a PT25 basta k=0.818 per lo stesso DD con Sharpe 1.32 invece di 0.22).
**Meccanismo (confronto appaiato per ingresso):** scatta sull'**86-91% dei VINCENTI** e sul
**19-25% dei perdenti** → tronca i vincenti del **27%** e salva un perdente su cinque; la
**peggior settimana e' IDENTICA** (7.27%) in ogni variante = pura troncatura dell'upside.
**Ipotesi mia refutata in sessione:** "su 7g chi tocca +50% e' chi sarebbe scaduto senza
valore, quindi a scadenze lunghe paga" — testata su 7/10/14/18/21/28g, **ΔSh negativo a tutti e
sei** (a 18g, il tenore di cerbero-bite, il DD migliora 7.1→3.8% ma lo Sharpe crolla = firma del
de-levering). ⚠️ La colonna `Sh hold` di quello sweep **NON e' un risultato** (6 celle sul
campione pieno); il tenore >10g resta un buco reale della griglia 03/07, da chiudere con
`study_family_honest`, non con uno sweep. **Con questo gli overlay refutati su VRP01 sono 5/5.**
⚠️ **CORREZIONE a un numero pubblicato lo stesso giorno:** il sleeve modella le fee come 12.5%
del credito NETTO, il listino vero e' **0.03% del sottostante per gamba** (cap 12.5% del premio
della singola opzione, che quasi mai morde) → il modello **sovrastima le fee di ~2x**. Sleeve
ufficiale 1.08/0.58/DD 11.8% vs fee reali **1.32/0.82/DD 10.5%**. Quindi il numero onesto di
VRP01 con **f=0.73** e' **ShFULL 0.47 / DD 14.5%, non 0.31** (che era calcolato col forfait).
`fee_frac` **NON cambiato**: il forfait e' conservativo e questo progetto tiene i numeri di
ammissione conservativi. **Rientro immediato** dopo l'uscita: Sh 1.19 < 1.32 canonico; il suo
ShHOLD 2.42 non e' selezionabile in-sample → **non e' un lead**.
**BUCO DEL TENORE CHIUSO col gate onesto (2026-07-30, 4° filone) — nessun cambio.**
`scripts/research/r0730_vrp_tenor_gate.py`, test `tests/test_vrp_tenor_gate.py` (12), diario
`2026-07-30-vrp-tenor-gate.md`. La griglia 03/07 si fermava a **10g**; qui la famiglia e' stata
**dichiarata prima di guardare**: 8 tenori (5-35g) x 3 delta corti x 3 lunghi = **72 celle**
(riaprire il tenore riapre la struttura → i trial si contano al RIALZO). ⚠️ `study_family_honest`
e' cablato sui candidati DIREZIONALI (`factory -> target_fn` via `candidate_daily`), quindi sono
stati usati i suoi **tre componenti reali**: selezione in-sample-only → `altlib.deflated_sharpe`
`altlib.marginal_vs_tp01` (importati, non riscritti; c'e' un test d'identita').
**Esito: `earns_slot_honest = False`.** Cella scelta al buio **10g 0.28/0.05** (Sh IS 1.75 /
FULL 1.55 / HOLD 1.01 / DD 9.6%) contro il canonico 7g (1.50/1.32/0.82/10.5%; rango **17/72**
in-sample, 26/72 full) → batte il canonico, ma **DSR 0.948 < 0.95 FAIL** (il canonico stesso fa
0.885 dentro questa famiglia). `marginal_vs_tp01` = **ADDS** per entrambe → il verdetto non e'
"VRP01 e' rotto", e' che il vantaggio non sopravvive al conto dei trial.
📌 **Il buco si chiude meglio sul contenuto che sul gate: la regione MAI esplorata PERDE.**
Miglior cella >10g = 18g 0.28/0.05, **rango 8/72**, e solo **3/10** della top-10 stanno oltre i
10 giorni → lo studio **conferma** il 03/07 invece di ribaltarlo.
**"Il vincitore sta dove il modello sbaglia di piu'" — MIO ARGOMENTO, MISURATO E REFUTATO
LO STESSO GIORNO** (5° filone, sotto): l'ala a δ−0.05 e' molto piu' mispriced in RELATIVO
(f_long **5.85** contro 2.23) ma pesa il **3.2%** del premio corto invece del **18.4%**, quindi
sul credito NETTO l'effetto e' MINORE → f_net **0.852** contro **0.718**: il candidato ha un f
**migliore**, non peggiore. Meccanismo giusto, conclusione rovesciata. **La decisione (nessun
cambio) regge, ma su tre gambe invece di quattro:** gate DSR, regione nuova perdente,
ineseguibilita' sotto ~$2.6k.
⚠️ **Robustezza del verdetto, pubblicata:** DSR **0.983 PASS a N=8** / **0.948 FAIL a N=72** /
0.909 a N=360 → **il verdetto si ribalta col conteggio**. La griglia era dichiarata in anticipo e
il conto fatto al rialzo, ma **fallisce per 0.002**: si cita come tale, non come refutazione
netta. Congelato in `test_il_verdetto_dipende_dal_numero_di_trial_dichiarati`.
**Seguito giusto = una MISURA, non un altro backtest:** quanto vale f sul 10g/0.05 sulle quote
vere (la catena ora la raccogliamo noi ogni ora; oggi 15 osservazioni sul solo canonico).
**REGOLE:** (a) quando si riapre un parametro si riapre la sua **famiglia**, e il deflated-Sharpe
e' l'unico posto dove barare e' indolore e invisibile; (b) dichiarare la griglia **prima** e
pubblicare la **sensibilita' del verdetto al conteggio**; (c) un buco si chiude meglio mostrando
che dentro **non c'e' niente** che bocciando il candidato; (d) se la selezione converge dove un
difetto di modello e' gia' misurato, **il sospetto vale piu' del numero** — e si dice che e' un
sospetto.
**f MISURATO SULLE STRUTTURE, e sorvegliante cablato (2026-07-30, 5° filone).**
`scripts/live/vrp_f_watch.py` (in `cron_daily.sh`), test `tests/test_vrp_f_watch.py` (11),
diario `2026-07-30-vrp-f-strutture.md`. **Book/pesi/config INVARIATI.** Il campione c'era gia':
**8 scadenze utilizzabili per asset su 8**, entrambe le strutture, 16 osservazioni ciascuna.
| struttura | f_short | f_long | quota ala/corta | **f_net** |
|---|---|---|---|---|
| canonico 7g δ−0.10 | 1.013 | 2.233 | 18.4% | **0.718** |
| candidato 10g δ−0.05 | 0.972 | **5.846** | **3.2%** | **0.852** |
Aritmetica che rende ovvio l'errore: `f_net = (f_short k·f_long)/(1 k)` con
`k = premio_lungo/premio_corto` → **un f_long grande fa danno solo moltiplicato per un k
grande**. ⚠️ Artefatto di tick ESCLUSO prima di crederci: l'ask dell'ala sta a **22 tick**
mediani (min 15, **0%** a ≤2 tick).
**La DIFFERENZA non e' stabilita:** appaiata per (asset, scadenza) fa **+0.109 IC95
[0.047, +0.193]**, 11/16 positive → **contiene lo zero**. ✅ Replica indipendente del canonico
(**0.718** per un percorso con finestra DTE e pairing diversi da quello che dava 0.73).
Al proprio f: canonico **0.43**, candidato **1.18**.
**CRITERIO PRE-REGISTRATO (dichiarato prima del campione pieno, congelato in un test):
≥40 coppie E ampiezza IC95 ≤0.12** (oggi 16 e 0.241) → prima gamba verso **fine ottobre 2026**;
il sorvegliante rifa' la misura ogni giorno e **notifica una volta sola** quando basta (lezione
DVOLSPREAD: un lead senza sorvegliante e senza data e' un lead perso).
⚠️ **Calibrazione della soglia verificata prima di fidarsene:** con differenza vera nulla lo
zero e' escluso nel **5.0/4.0/3.0%** dei casi a n=16/40/60 = il 5% atteso. (Il test iniziale su
seed fisso falliva perche' quel seed era uno dei 5% legittimi → sostituito con un test sulla
PROPRIETA', 100 estrazioni.)
**NON promuove nulla:** il candidato resta bocciato sul deflated-Sharpe, che non dipende da f.
**REGOLE:** (a) **un fattore di errore si giudica moltiplicato per il suo peso** — 5.85 al 3%
fa meno danno di 2.23 al 18%, e guardare il fattore senza il peso da' la conclusione opposta a
quella vera; (b) prima di credere a un rapporto estremo su un prezzo piccolo, **contare i tick**;
(c) una soglia sull'ampiezza di un IC richiede di **verificare la copertura** di quell'IC;
(d) *"non abbastanza campione" non e' "nessuna differenza"* — si aspetta con una data.
💰 **A $3.000 la domanda non e' il rendimento** (`min_trade_amount` letti dal venue il 30/07):
~~**BTC min 0.1 = $6.210 di collaterale/lotto → FUORI**; ETH min 1 contratto = $1.832 → **1 lotto**.~~
🚨 **CORRETTO 2026-08-23 (§50): misurato sulla famiglia INVERSE, che un conto USDC non puo'
marginare.** Sulla **USDC-lineare** il lotto ETH e' **$242** e il BTC **$772** (7,5x piu' piccoli)
⇒ 1 lotto ETH copre il peso di book 12% gia' da **~$2.000**, e il BTC da ~$6.440.
**CADE IL LOTTO, NON LA REGOLA:** *niente short-vol da modello in deploy* non ha mai avuto
bisogno di un muro di taglia. **5ª occorrenza dello schema `fee_watch`** — un numero misurato su
una configurazione diversa da quella che gira.
Il sleeve 50/50 **diventa ETH-only**, e **al peso di book (12% = $360) sono 0 lotti** — servirebbe
il **61% del conto** su un solo sleeve. **REGOLE:** (a) un'uscita si giudica su un confronto
**appaiato per INGRESSO**, mai allineando le serie sulla data di USCITA — e' proprio quella che
la variante cambia, e l'inner-join tiene solo i casi in cui non e' successo niente (errore
commesso e corretto in sessione, 3ª occorrenza della trappola dopo venue-watch e GTAA; congelato
in un test); (b) **una regola d'uscita che scatta piu' spesso sui vincenti che sui perdenti non
e' protezione, e' troncatura** — si vede in una riga, la peggior settimana non cambia; (c) prima
di misurare il rendimento a un capitale dato, misurare il **lotto minimo del venue**.
**`VRP_CFG["f"]` NON cambiato** (15 osservazioni, 7 settimane, e per giunta **0/8 settimane
passano il gate IV-rank>0.30**: il f è misurato nel regime in cui il sleeve sta FLAT, DVOL max
raccolto al 24°/28° pctl della storia) → **caveat quantificato, non nuovo parametro**; il criterio
del 19/06 ("rivalutare quando cerbero-bite cattura un crash") è **intatto**.
⚠️ **Il DD 12% è un DD di CHIUSURE settimanali:** con le standing quotes (~164 riquotazioni/trade)
il peggior mark INFRA-settimana è mediana 6.9% / minimo **81.7%** del capitale su un trade finito
in utile, e il 50%-profit-take sarebbe scattato in **13/15** settimane. Stessa classe della lente
wick accoppiata (25/07): *un rischio valutato sul minimo non si misura sulle chiusure*.
Diario `2026-07-30-vrp-quote-reali.md`.
- **Universo Hyperliquid: ESPANDERLO NON aiuta XS01** (provato): 52-asset / top-liquidità dinamico /
trend-multi-asset → tutti peggiori (small-cap/memecoin diluiscono il momentum relativo; il trend
multi-asset è ridondante con TP01, corr 0.74). I margini su XS sono nella STRUTTURA DEL SEGNALE
(blend + gate), non nel numero di asset. I **51** parquet certificati restano per ricerca futura.
⚠️ Il test "52-asset = negativo" era in parte inquinato dal backfill sintetico (AXS 83%, ALGO/SAND
37% di barre vol=0) poi rimosso — vedi correzione estrazione 2026-06-20 sotto; resta comunque vero
che il long-tail diluisce XS01, ma il numero netto post-fix è 51.
-**XSR01 "Cross-Sectional Residual" — CANDIDATO NUOVO in forward-monitor (2026-07-25).**
`scripts/live/paper_xsr.py`; scoperta `r0725_statarb_basket_gate.py`, scettico
`r0725_statarb_demean_skeptic.py`, gate `r0725_xsr_deploy_gate.py`, test `tests/test_paper_xsr.py`.
**Cos'e':** il meccanismo congelato di STATARB-RESID (W=45, sgn=+1, residuo OLS causale su BTC,
z-score, tanh, vol-target 20%) applicato ai **50 alt HL**, con posizioni **DEMEANATE
cross-sezionalmente** ogni giorno. Il demeaning annulla ALGEBRICAMENTE la gamba BTC comune
(`sum(p_ip̄)(r_ir_btc) = sum(p_ip̄)r_i`) → non e' un paniere di coppie ma una **strategia
cross-sectional dollar-neutral**, e l'ampiezza effettiva passa da **4.5 a 37.4**.
**Numeri (2.6 anni):** Sharpe netta **1.82** (lorda 2.70), maxDD **2.6%**, vol 2.3%, ret 4.2%/a.
**Gate superati:** marginale **ADDS** (robust_oos + beats_noise_null + non-hedge +
has_insample_edge); **deflated-Sharpe 0.985 PASS**; **corr ~0 a TUTTI e 5 gli sleeve** (TP01 0.060,
XS01 0.019, VRP01 0.001, SKH01 0.001, GTAA01 0.071); book a w=15% HOLD 2.36→**2.51**, DD invariato.
**Scettico superato:** 3 null **a fee-neutrale** (permutazione cross-sezionale / casuale /
temporale a blocchi) centrati a ~0.01, candidato lordo 2.70 **sopra il massimo di 300 estrazioni**
(p<0.004); **lag 1.82/1.19/0.81/0.51** a +0/1/2/3g = decadimento dolce di segnale lento, NON
firma di look-ahead; non ridondante con XS-momentum semplice (corr 0.17-0.29).
**NON nel book, 3 motivi dichiarati:** (a) storia 2.6a monoregime e **crescente** (Sh 2024 1.03 /
2025 1.98 / 2026 3.11) → l'edge e' recente; (b) **`weights_tilt_null` FALLITO** (gate_pass=False a
10% e 15%, delta_insample 0.004/0.007: effetto della storia corta, ma un gate fallito resta
fallito); (c) **margine di costo sottile** — 1.82 a 0.05%/gamba, **0.93 a 0.10%, NEGATIVA a 0.20%**,
con turnover 38.5% del lordo/g su 50 alt anche illiquidi e **slippage NON modellato** (rischio #1).
**Eseguibilita':** ticket/gamba $1.73 a $600 (**sotto min-order $5 → STAT-MODE oggi**), $5.76 a
$2000, **$14.41 a $5000** → diventa reale a **~$5k**, non ai ~$20k di XS01.
🚨 **IL GATE QUI SOTTO LEGGE UN MONITOR MAL TARATO (misurato 2026-08-23, §67): il pavimento del
venue usato per l'haircut e' quello sbagliato — C\* vero $15.000-20.000, non i ~$3.000 riportati da
HL-EXEC con un criterio piu' permissivo.** Le soglie **NON sono state toccate**: cambiarle guardando
questa misura a due mesi dalla decisione sarebbe selection-on-holdout. Le due vie pulite: riscriverle
**adesso** dichiarando che le si riscrive prima di vedere l'esito, oppure lasciarle e **citare il
difetto al momento della decisione**. **Decisione dell'operatore.**
**Gate pre-registrato 2026-10-23** (forward-day 0): deploy solo se Sharpe≥1.0 **E** haircut di
eseguibilita' a $5000 ≤40% (se l'haircut sfonda → **RITIRO a prescindere dallo Sharpe**), poi
weights_tilt_null e capitale ≥$5k. Monitor in `cron_daily.sh`, 3 libri (MODELED $2000 / REAL $600 /
REAL $5000). ⚠ Lezione: XSR01 **non e' nato da un'idea nuova ma dalla DIAGNOSI di un fallimento**
(ampiezza effettiva 4.5 → c'e' un fattore comune da togliere); e i suoi null vanno confrontati
**a fee zero**, perche' permutare un segnale ne fa esplodere il turnover e il null perderebbe per
costo invece che per assenza di informazione (p-value trionfale e falso).
- **Soffitto strutturale BTC/ETH-direzionale ~1.3** superato SOLO espandendo a un meccanismo diverso:
cross-sectional su universo Hyperliquid certificato (XS01) → portafoglio Sharpe ~1.55.
File diff suppressed because it is too large Load Diff
+698
View File
@@ -0,0 +1,698 @@
# Piano, capitale, fisco e canale funded
> Estratto **verbatim** da `CLAUDE.md` il 2026-08-25 durante la compattazione.
> Muri, traiettorie, versamenti, rischio di venue, fisco e prop firm.
La tabella che comanda e' quella al netto di TUTTO (fisco + funding).
> Il testo non e' stato riscritto: e' la memoria originale, spostata.
---
- ⚠ **RENDITA / CURVA CAPITALE (2026-07-25, 2° filone del giorno) — il muro del 24/07 era ottimista
2-4x, e 1 DIFETTO DI ESEGUIBILITA' su GTAA01.** Script `r0725_capcurve.py` + `r0725_prop_config.py`,
test `tests/test_capcurve.py` (10 casi); diario `2026-07-25-rendita-capcurve-prop.md`. Book/pesi/cron
**INVARIATI**.
(1) **GTAA01 non e' eseguibile come codificato.** `gtaa.py` modella 2bps proporzionali e lo sleeve e'
documentato "switch mensile/basso turnover": FALSO — il vol-target e' **continuo giornaliero su 6
gambe**, e IB ha un **pavimento FISSO** `min(max($0.35, $0.0035/az), 1% valore)` per ordine =
~$530/anno indipendenti dal capitale. A $600: **CAGR 3.5% / Sh 0.55**; negativo fino a ~$3k;
a $50k 0.59. **La banda lo salva**: plateau robusto **weekly x banda $25-100** → Sh 0.45-0.64 a
ogni capitale (a $600: Sh 0.52 / CAGR 3.0%). ⚠ **Correzione a un errore MIO:** la prima stesura
citava il modello vecchio a "0.77/5.5%" — era un **artefatto di annualizzazione** (metricavo la
serie GTAA grezza a ~252 barre/anno con `metrics()` che annualizza a 365 → Sharpe ×1.20, CAGR
×1.45). Valore vero del modello vecchio: **0.64/3.8%**. **Quindi il difetto NON e' "sovrastimava
di 0.13": alla taglia grande il modello vecchio era GIUSTO (0.64 vs 0.59-0.66 reali). Il difetto
e' che era CIECO AL CAPITALE** — dava 0.64 sia a $50k sia a $600, dove la realta' e' 0.55.
**Lezione: una serie su giorni di borsa (~252/anno) non si passa a `metrics()` (che annualizza a
365) senza `to_daily()` — il Sharpe esce ×1.20 e il CAGR ×1.45.**
**FIX CABLATO** (stessa sessione, `src/portfolio/gtaa.py`): costo IB reale (`ib_commission`),
esecuzione a **banda+cadenza** (settimanale, $50/gamba), `gtaa_returns(capital=...)` capital-aware,
soglia `GTAA_MIN_CAPITAL=$3.000` + `gtaa_is_deployable`, e **`gtaa_rebalance_plan(held, capital)`**
per l'esecutore (salta le gambe sotto banda). `sleeves.py` dichiara il capitale assunto
(`GTAA_DEFAULT_CAPITAL=$10.000` ≈ book $50k al peso 20%). **Impatto book misurato: FULL 2.22→2.22,
HOLD 2.36→2.38, DD 6.2→6.0%** = trascurabile alla taglia assunta; il fix conta per il **DEPLOY**
(a $600-2k: da 3.5%/anno a +3.0%/anno). Pesi INVARIATI. Test `tests/test_gtaa_sleeve.py` (+4). **REGOLA NUOVA: il costo di un venue va modellato nella sua
FORMA (fisso vs proporzionale), non solo nel livello** — due venue a pari "costo medio" danno esiti
OPPOSTI al variare del capitale (il pavimento fisso e' una tassa regressiva). Controprova: su Deribit
(proporzionale, senza pavimento) lo Sharpe realistico di TP01 = modellato da ~$500 in su → conferma
indipendente di "a $600 il min-order $5 e' gia' la banda ottimale".
(2) **La rendita NON e' `capitale x CAGR`.** Il 24/07 calcolava capitale = target/CAGR (€122k a CAGR
15%), ignorando il rischio di sequenza. Bootstrap a blocchi sui ritorni REALI (SKH01 su **path live**):
rendita **perpetua** (= prelievo con P(cap a 20a >= cap iniziale) >= 90%) del book de-luckato ×0.6 =
**5.98% → $497k**; SWR-20a 7.31% → $406k; lente modellata 13.57% → $219k. ~~Il muro vero e' una
BANDA $232k-$497k, stima centrale ~$300-400k.~~
⚠️ **AGGIORNATO 2026-07-26 — il ×0.6 era MISURATO troppo severo del 31-34% → il muro scende
del ~45%.** Il fattore d'ancora onesto sul drift e' **×0.89** per il book live (misurato, non a
occhio) e ogni componente del path live e' non-negativa (bullet in fondo). Ricalcolo con la
STESSA macchineria (`r0726_capwall_refresh.py`): **perpetua 6.00% → 10.91%, muro $494.758 →
$272.061** a leva 1.0 (a leva 1.5: $366k → $200k). Il ×0.89 e' un **limite inferiore** del
fattore, quindi il muro vero sta fra la riga ×0.89 e la riga ×1.00 ($233k). **La conclusione
STRUTTURALE non cambia:** $272k restano **~453× il conto di oggi** → i €600 come CAPITALE
restano refutati, come BIGLIETTO (prop) no. Rendita a $600: €0.12/g → **€0.18/g** (centesimi:
il fattore conta per il MURO e le soglie prop, non per il conto attuale).
Cio' che NON dipende dalla lente: **la rendita perpetua vale ~45-55% del CAGR**, quindi ogni muro
calcolato come `target/CAGR` sbaglia di un fattore ~2.
**TRAIETTORIA da $600, ricalcolata col fattore corretto (26/07).** Il fattore agisce **due
volte**: alza il drift (si accumula prima) E abbassa il bersaglio (serve meno capitale), e i due
effetti pesano quasi uguale. Mediana degli anni per toccare il capitale-rendita:
| dep./mese | ×0.60 muro $495k (25/07) | ×0.89 muro $495k (solo drift) | ×0.89 muro $272k (26/07) |
|---|---|---|---|
| €0 | mai | mai | **mai** |
| €250 | 22.4a (8% entro 20a) | 19.6a (53%) | **16.2a (91%)** |
| €500 | 19.6a (48%) | 15.7a (94%) | **12.4a (100%)** |
| €1000 | 14.8a (95%) | 12.0a (100%) | **9.0a (100%)** |
| €2000 | 10.0a (100%) | 8.5a (100%) | **6.0a (100%)** |
⛔ **QUESTA TABELLA E' AL LORDO del fisco d'accumulo — la versione NETTA e' nel bullet "IL FISCO
DURANTE L'ACCUMULO" (r0807_piano_netto, 07/08) e cambia la riga di testa: €250/mese passa da
P(20a) 92% a 52%.** Le colonne qui restano perche' sono la replica di controllo del fattore
d'ancora, non perche' siano il piano.
✅ La colonna ×0.60 **riproduce esattamente** i numeri del 25/07 (19.6a / 14.8a) = validazione
indipendente della replica. ⚠️ **Cio' che NON cambia col fattore: senza depositi il
capitale-rendita non si raggiunge mai** (0% dei path a 20 anni a OGNI fattore) — l'accumulo
viene dai versamenti, non dal rendimento; e la mediana e' una MEDIANA (meta' dei path arriva
dopo, una quota non arriva affatto).
**QUANTO VERSARE PER UN ORIZZONTE DATO** (bersaglio $272k, ×0.89; "arrivarci in N anni" non e'
un numero: dipende dalla confidenza):
| orizzonte | P=50% | P=75% | P=90% | P=95% | totale versato @P=90% |
|---|---|---|---|---|---|
| **10 anni** | €806/m | €995/m | **€1.178/m** | €1.299/m | **$155.923** |
| 15 anni | €313/m | €408/m | €509/m | €583/m | $101.643 |
| 20 anni | €129/m | €180/m | €237/m | €280/m | $63.406 |
**AL LORDO: i numeri da usare sono quelli NETTI** (€1.323 / €672 / €371 a P=90%, bersaglio
$258k) nel bullet "IL FISCO DURANTE L'ACCUMULO" — il fisco costa **+12% al mese a 10 anni, +32%
a 15, +57% a 20**.
⚠️ **Comprimere l'orizzonte da 20 a 10 anni costa 2.5× al mese E 2.5× in totale**: a 10 anni
versi $155k per arrivare a $272k (il rendimento fa il 43%), a 20 anni ne versi $63k (il
rendimento fa il **77%**). **A orizzonti corti non fai lavorare la strategia, COMPRI il
capitale coi bonifici** — il confronto onesto e' sempre `totale versato` vs bersaglio.
Drill-down €250/m (5000 path): traguardo p10 13.4a / **mediana 16.2a** / p90 19.7a;
P(entro 15a) **31%** → P(entro 20a) **92%** (la curva non da' segnali per un decennio e poi si
muove tutta insieme: chi giudica al 5° anno giudica nel punto peggiore); al traguardo hai
versato ~$54k su $272k → **80% viene dal rendimento**. ⚠️ Bug catturato in sessione: il
contatore `paid` si congelava al traguardo mentre `cap` continuava a ricevere i depositi →
rapporto capitale/versato gonfiato (46× invece di 25× a 30 anni); test di regressione cablato.
(3) **Diversificare NON crea reddito a pari nozionale — libera BUDGET DI RISCHIO.** Per tier:
iso-nozionale 2 sleeve 5.98% → 4 sleeve 6.35% (nulla, il diversificatore a basso CAGR toglie vol e
ritorno insieme); a **ISO-RISCHIO** (vol 15%) 7.51%/$395k → **9.25%/$321k (19% di muro)**.
**REGOLA: un diversificatore a basso CAGR si giudica a ISO-RISCHIO, mai a iso-nozionale** (e' il
null de-levering al contrario). L'ipotesi "piu' capitale → piu' sleeve → CAGR super-lineare" e'
**REFUTATA nella forma forte**: la curva Sharpe del book eseguibile e' PIATTA da $600 a $200k.
(4) ✅ **ASIMMETRIA CAPITALE-PROPRIO vs FUNDED (risultato strategico).** Il 24/07 valuto' il fronte
prop **solo col book a 2 sleeve**; ma su un conto funded il capitale e' $100k → **gli sleeve STAT-MODE
per taglia (XS01, ~$20k) diventano eseguibili**, e le regole prop passano sul **DRAWDOWN, non sul
CAGR**. Finestra comune 2024+, de-luck, crypto-only: P(pass) HYRO 1.0x **44.4%→54.7%**, FTMO 1.5x
**51.9%→70.0%**; **funded HYRO 1.0x P(vivo 1a) 18.9%→57.6% (3x)**, FTMO 1.0x 58.8%→**92.0%**,
E[payout] $8.7k→$9.3k (~€15.7/g atteso). **Si RIBALTA la raccomandazione "funded a 0.75x"**: col book
diversificato 1.0x e' sostenibile. **In una riga: sul capitale proprio diversificare non aumenta il
reddito; su un conto funded si', perche' li' il vincolo binding e' la regola di DD, non il capitale
→ gli sleeve "inutili a $600" sono gli asset di maggior valore sull'unico canale che scala.**
⚠ CAVEAT: MC **close-only** (C-bis 24/07: i wick tagliano 6-37pp) → livelli assoluti = TETTO, il
DELTA e' la misura onesta ed e' conservativo (B ha vol minore); la finestra comune 2024+ e' quella in
cui XS01 e' stato scoperto/affinato → la TAGLIA del guadagno e' ottimista (finestra piena: 56.9%→58.5%),
il MECCANISMO (corr bassa → meno DD → piu' sopravvivenza sotto vincolo di DD) e' robusto.
(5) ✅ **LA VIA: i 600 euro come BIGLIETTO, e il problema della correlazione fra conti**
(`r0725_prop_ladder.py`). I €600 come capitale sono refutati; come **biglietto** no: si compra
un'eval, il funded moltiplica il NOZIONALE senza possedere capitale, i payout comprano altri
biglietti. Il 24/07 si fermava a UN conto (cap $200k/firm → ~€15-30/g); **50 EUR/g richiede piu'
conti**, e li' il problema mai studiato: **N conti sullo STESSO book bustano INSIEME** (corr 1.0)
→ la diversificazione fra conti e' illusoria salvo **sleeve diversi su conti diversi**. E' un
problema di portafoglio sotto **barriera di rovina PER-CONTO**. Sim 36 mesi, €600, max 6 conti,
2 firm, regole vere, payout mensile prelevato subito, fisco 33%, **morte-firm 10%/anno**,
bootstrap CONGIUNTO (corr reali). ~~**Vince il MISTO, non gli estremi**~~ 🚨 **SUPERATO 2026-08-23
(§60): rifatta la stessa griglia (288 celle) vince MISTO-A, `P(>=50/g)` 9,27% contro 6,60% — e la
mediana e' 0,00 EUR/g in TUTTE e sei le politiche. Cade il vincitore, non l'ordine fra gli
estremi.** Numeri del 25/07 (close-only, leva 1.0x):
MISTO mediana €10.70/g, P(≥50/g) 20.7%, P(zero) 33.4% > CONC-DIV 5.70/17.8%/33.4% > SPARSO
0.00/16.8%/**66.0%** > **CONC-2SL (= il book live attuale) 0.00/13.1%/55.6% = la PEGGIORE**.
Logica: ogni conto serve Sharpe per sopravvivere alla PROPRIA barriera (uccide SPARSO), ma i
conti servono decorrelati fra loro (penalizza CONC). **Con lente INTRADAY (wick)** tutto crolla:
P(≥50/g) 1.6-2.5%, P(zero) 78-90%. ⚠ Il mio wick e' un **PAVIMENTO**: gap estratto INDIPENDENTE
dal rendimento del giorno → breach spuri → **follow-up dichiarato, poi CHIUSO lo stesso giorno
(bullet successivo): la stima onesta e' P(≥50/g) ~6%, P(zero) 52-65%.** Il confronto fra POLITICHE
e' robusto (stessa lente per tutte) — **verificato a posteriori sulla lente accoppiata: l'ordine
MISTO ≥ CONC-DIV > CONC-2SL ≈ SPARSO regge a tutte e 3 le lenti** → **se si apre il fronte prop,
NON mandarci il book live attuale**.
(6) **ADDENDUM "e se metto 10K su IB?"** (`r0725_ib10k.py`): allocazione fra venue, non domanda su
GTAA01. Deribit = **motore** (CAGR ~11% de-luck), IB/GTAA01 = **diversificatore** (CAGR ~3.9%).
A $11.5k totali: 0% su IB → **€2.16/g**; 50% → €1.54/g (Sharpe migliore 1.13, DD 15.3→11.2%);
**94% (= i 10k su IB) → €0.93/g = REDDITO PIU' CHE DIMEZZATO**. La via d'uscita (levare per
convertire lo Sharpe in reddito) e' **chiusa dai costi**: su ETF a IB con €10k c'e' Reg-T **2x max**
(portfolio margin da ~$110k) e il margine costa **~5.5%/anno** → contando il finanziamento vince
**tutto-Deribit a 1.33x** (rendita €1.33/g vs €0.92/g a 50/50). **REGOLA: l'argomento iso-rischio
(punto 3) vale solo se la leva e' (a) disponibile e (b) a costo < uplift — su un retail da €10k su
ETF non lo e'.** Confronto che ridimensiona GTAA01: €10k nello sleeve = €0.93/g con maxDD 10.5%,
gli stessi €10k FERMI a ~2% = €0.54/g con maxDD ~0% → **premio ~€0.50/g pagato con un DD del 10%**.
Raccomandazione: i depositi vanno su **Deribit**; al massimo **25% su IB** (costa ~€0.08/g di
rendita, taglia il maxDD 15.3→12.0%, unico split che regge coi costi). ⚠ Il confronto FAVORISCE il
crypto per costruzione (7 anni con 2 bull vs 30 anni di GTAA); tassi e aliquote (26%/33%) sono
assunzioni dichiarate, da confermare col commercialista (non un parere fiscale).
(7) **HYROTRADER nello specifico** (`r0725_hyro.py`): la firm meglio classificata per questo book
(API reale da funded, nessun limite di tempo, **weekend consentito** — e il weekend porta il 38%
del gross di TP01). **Ipotesi REFUTATA: la regola di consistency 40% NON morde** (costo ≈0pp a
ogni leva/lente) perche' il book accumula il 10% in 130-300 giorni → nessun giorno si avvicina al
40% del cumulato; ⚠ prima di dichiararlo ho dovuto **provare che il controllo funziona** (un
"costo 0" puo' essere un bug): su un book con profitto concentrato in 1-2 giorni la regola porta
P(pass) da >90% a <5% (test cablato). **Il vincolo vero e' il maxDD 6% STATICO**: config A (book
live) ha maxDD 9.5% > 6% = strutturalmente incompatibile a leva piena — intraday a 1.0x
sopravvive l'**1.4%**; config B (+XS01) ha maxDD 6.2%, Sharpe 1.13. ~~**Funded consigliato: config B
a 0.50x**~~**CORRETTO a 0.75x dalla lente accoppiata (bullet successivo)**: il 0.50x era scelto
perche' il wick indipendente dava a 0.75x P(vivo) 55%; la lente onesta da' **76%**, e 0.75x
**massimizza il payout atteso su 3 anni** ($2.674 vs $1.230 a 0.50x e $1.992 a 1.00x). L'argomento
"la sopravvivenza COMPONE su piu' anni" resta valido: si sposta il punto in cui morde.
EV del biglietto $100k **positivo in entrambe le lenti** (+$6.789
close-only, +$1.166 intraday), ma ~69% di perdere la fee nella lente pessimista. Cap $200k/trader
⇒ ~€15-30/g max → per €50/g servono piu' firm (punto 5). ✅ Discrepanza col 24/07 (P(vivo) A@0.75x
58% vs 10% mio) **RISOLTA: non era la finestra, era la lente** — sulla stessa finestra piena la
lente accoppiata da' **63.2%** vs il 58% del 24/07 (accordo entro 5pp, implementazioni separate).
⚠ Bug catturato in sessione: base di prelievo funded aggiornata giornalmente come HWM mobile →
guadagno al checkpoint ≈ 0 → **payout $230/anno invece di ~$7.000**; regole vere = max-loss STATICO
dal saldo iniziale + base ripristinata dopo il prelievo. Test di regressione cablato.
-**LENTE WICK ACCOPPIATA (2026-07-25, follow-up del bullet precedente — CHIUSO).** Script
`r0725_prop_coupled.py`, test `tests/test_prop_coupled.py` (13 casi), diario
`2026-07-25-prop-wick-accoppiato.md`. Book/pesi/cron **INVARIATI**. Generalizza il recon MTM di
`r0724_goal50_intraday_mc.py`: (a) sleeve TP01/SKH01 **separati** a risoluzione oraria → il minimo
intraday si compone ESATTO per QUALSIASI vettore di pesi (prima erano cablati 75/25); (b) **XS01
accoppiato** dagli OHLC giornalieri HL (4 checkpoint, ordine condiviso avverso; recon = sleeve
ufficiale a `max|Δ|=0.0`).
⚠️ **IL FINDING: la CALIBRAZIONE del wick era giusta, l'errore era l'INDIPENDENZA.** Le marginali
coincidono quasi (p50 0.17pp **identico**, p90 1.03 vs 0.90, p99 2.70 vs 3.50) — sbagliava
**su quali giorni** cadono i tuffi. E la dipendenza va nel **verso inatteso**: il gap e' ~**3× piu'
profondo nei giorni che finiscono BENE** (1.58pp nel decile migliore vs 0.48pp nel peggiore),
perche' un giorno brutto scende tutto il giorno e **chiude sul minimo** (`m==R` nel **26%** dei
giorni). Il breach si valuta sul minimo → l'estrazione indipendente carica i giorni brutti con la
coda dei giorni buoni e **raddoppia i breach da daily-loss (2.0-2.9×, misurato sui giorni storici)**.
**`close-only` non e' conservativa, e' CIECA**: 0.00% di breach da daily-loss su OGNI configurazione
(la regola non scatta mai sulle chiusure) → usarla come controllo, mai come stima.
**Verifiche (un "nessuna differenza" va provato):** (1) **1h vs 5m** sulla gamba TP01 = identici
(p99 3.06 vs 3.14pp) → **il caveat di risoluzione portato avanti dal 24/07 e' quantificato e
trascurabile**, l'ora cattura gia' il minimo del giorno; (2) riconciliazione col 24/07 (sopra);
(3) **bound severo su XS01** (ogni gamba al proprio peggio insieme): config B resta sopra config A
(P(vivo) 57.6% vs 39.4%) → la conclusione non dipende dalla convenzione.
**Decisioni:** funded **0.75x** (non 0.50x, vedi sopra); scala di conti **P(≥50/g) ~5.6-6.5%** in
3 anni (non 1.6-2.5% ne' 20.7%) con **P(zero) 52% a 0.75x / 65% a 1.00x**, e **P(≥10/g) massima a
0.75x (29.7%)** = stesso ottimo di leva del conto singolo. **Ordine fra politiche INVARIATO a
tutte e 3 le lenti.** Verdetto ristretto: **€600→€50/g ≈ 6% in 3 anni, P(perdere i €600) ≈ 52-65%**
— resta coda destra, ma con probabilita' conoscibile invece di una banda di un ordine di grandezza.
**REGOLA NUOVA: un modello di rischio intraday NON si valida sulla marginale del wick ma sul suo
ACCOPPIAMENTO al rendimento del giorno** — qui un test "i percentili coincidono" sarebbe PASSATO
con la stima sbagliata di 2-3×. Ogni regola valutata sul minimo (daily-loss, trailing DD, stop di
conto) va misurata su **tuple accoppiate**, mai su un wick estratto a parte.
- ⚠️ **RISCHIO DI VENUE — mai prezzato in 2 mesi, e non e' diversificabile dagli sleeve
(2026-07-26).** Script `r0726_venue_risk.py`, test `tests/test_venue_risk.py` (13), diario
`2026-07-26-venue-risk.md`. **Book/pesi/cron INVARIATI.**
(0) **Il buco:** il progetto ha prezzato fee, slippage, min-order, pavimento IB, haircut
small-cap, fortuna d'ancora, degrado d'esecuzione, look-ahead, backfill, split — **mai la
probabilita' che l'exchange sparisca col saldo dentro**. E TP01+SKH01+VRP01 stanno **tutti sullo
stesso conto Deribit**: tre sleeve quasi-ortogonali sui ritorni, **perfettamente correlati sul
fallimento del venue** — cosa che la matrice di correlazione del book non vede per costruzione.
(0-bis) ⚠️ **Limite dei muri del 25-26/07:** `book_series` gira a **`alloc=$600` col book a 2
sleeve** → portarlo fino a $272k assume (a) che a $272k si giri ancora il book da $600 e (b)
**"tutto su Deribit" per 10-20 anni, senza dirlo**. ✅ **(a) MISURATO e REFUTATO il 26/07** —
vedi bullet "MURO COME PUNTO FISSO": il muro **non** scende, $273.900 vs $272.061 (**+1%**).
(1) **La misura** (accumulo da $600, €250/m, 20a, bersaglio $272k, ×0.89, jump di venue a
probabilita' annua `p`; CONC = 100% Deribit vs SPLIT = Deribit 65 / HL 15 / IB 20; **bersaglio
identico → conservativo CONTRO lo split**):
| p annua | P(arrivare) CONC | SPLIT | **P(perso TUTTO) CONC** | **SPLIT** |
|---|---|---|---|---|
| 0.5% | 87% | 90% | **10%** | **0%** |
| 1.0% | 81% | 83% | **18%** | **0%** |
| 2.0% | 69% | 71% | **34%** | **4%** |
| 5.0% | 42% | 45% | **64%** | **27%** |
Capitale mediano CONC a 20a: $544k (p=0) → **$0 (p=5%)**.
(2) **La colonna che conta non e' la prima.** Sulla probabilita' di ARRIVARE la concentrazione
costa 1-3pp; sulla **ROVINA** costa fino a 64pp. Motivo strutturale: **con un conto solo "almeno
un fallimento" COINCIDE con "perso tutto"**. ⚠️ Lo SPLIT viene colpito **2.5× piu' spesso** (26%
vs 10%) ed e' molto piu' sicuro → **"quante volte vieni colpito" NON e' una misura di rischio**.
(3) **Onesta' obbligatorie:** `p` **non e' stimato** (sensibilita', non previsione — la sceglie
l'operatore e va dichiarata); i fallimenti sono assunti **indipendenti**, ottimistico per
Deribit-HL (crisi sistemica) → **la parte solida dello split e' IB**, altra classe di rischio;
**a $600 lo split e' impossibile**, la concentrazione e' forzata.
(4) **RISPOSTA: no, ma la domanda ha una DATA.** Oggi concentrazione forzata; **~$3k = prima
riduzione vera** (GTAA01 su IB, 20-25% fuori dal rischio-exchange); ~$20k (XS01/HL) aggiunge
poco perche' e' ancora crypto. ✅ **Convergenza che rafforza il 25/07:** `r0725_ib10k` disse
"max 25% su IB, **costa** ~€0.08/g" su basi di solo RENDIMENTO; sull'asse della ROVINA quello
stesso 25% e' la mossa principale → **€0.08/g non e' il prezzo di un peggioramento, e' il premio
di un'assicurazione contro il modo piu' probabile di perdere tutto.**
⚖️ **(5) DECISIONE DELL'OPERATORE 2026-07-26: TUTTO SU DERIBIT FINO A $20k.** Presa DOPO aver
visto la tabella della rovina, e con la controparte esplicitata. **Cosa e' stato accettato:**
P(perso TUTTO) resta 10/18/34/64% a p=0.5/1/2/5% invece di 0/0/4/27%; in cambio si evita il
costo (~€0.08/g di rendita, commissione fissa IB, un secondo venue da gestire) di proteggere
**$750** alla soglia dei $3k. **L'argomento a favore, che regge:** sull'asse su cui l'operatore
ottimizza — P(ARRIVARE al capitale-rendita) — lo split vale solo **+1-3pp** (81%→83% a p=1%),
ed e' un fatto misurato, non una concessione. **L'argomento contro, che resta vero:** zero e'
**assorbente** (andare a zero all'anno 10 di un piano da 16 anni significa non arrivarci piu',
perche' si riparte da €0 + versamenti), quindi il valore del non-andare-a-zero NON e'
proporzionale alla frazione salvata. **Cosa NON si ri-discute:** la soglia $3k. **Cosa si
ri-apre a $20k:** lo split, che a quella taglia protegge ~$5k e ha senso anche solo per
eseguibilita' (XS01/HL, GTAA01/IB). ⚠️ **Nota per il futuro-me:** questa e' una decisione presa
con l'informazione completa, non una svista da correggere — se a $3k qualcuno propone lo split
"come da CLAUDE.md", la risposta e' che la data e' $20k. Se cambia il piano (orizzonte, importo
dei versamenti) o `p` diventa stimabile invece che assunto, si riapre PRIMA.
**REGOLE:** (a) un rischio non-diversificabile dagli sleeve va prezzato a parte; (b) P(successo)
puo' nascondere P(rovina) — per una rendita la metrica e' la seconda; (c) una raccomandazione
presa su un asse solo va ricontrollata sugli altri prima di considerarla stabile; (d) quando una
raccomandazione viene respinta con motivo, si registra **cosa e' stato accettato in cambio**
altrimenti la stessa analisi la ripropone fra tre mesi come se fosse nuova.
- 💰 **I VERSAMENTI — le 4 ipotesi che il piano non aveva mai fatto (2026-07-26, ultimo filone).**
Tutte le traiettorie del 25-26/07 assumevano versamento **piatto, ininterrotto, per sempre** =
l'ipotesi meno realistica del piano. Script `r0726_deposits.py`, test `tests/test_deposits.py`
(12), diario `2026-07-26-versamenti.md`. **Book/pesi/cron/config INVARIATI** (non tocca la
produzione). Block bootstrap sui ritorni reali del book live, fattore ×0.89 misurato.
(1) **SMETTERE — il costo non e' proporzionale ai soldi mancanti.** €250/m per K anni poi stop,
orizzonte 20a: 3a ($10.410) → $202.771 / P(muro) 32.7%; 5a ($16.950) → $287.081 / **53.3%**;
10a ($33.572) → $410.220 / 77.9%; 20a ($66.818) → $496.778 / 90.0%. **I primi 5 anni sono il 25%
dei soldi e il 58% del risultato.** → un'interruzione al 12° anno costa poco, una al 3° quasi
tutto: argomento per partire con un importo **sostenibile**, non ambizioso.
(2) **CRESCENTE E' PEGGIO DI PIATTO a pari soldi.** €150/m +5%/anno versa €67.998 → $401.889;
piatto €250 versa €66.818 → **$496.778** = **+24% con gli stessi soldi**, solo perche' entrano
prima. Metrica giusta per confrontare piani di taglia diversa = **`$ finale / $ versato`**
(piatti 7.4x, crescenti 5.1-5.9x). Contro-intuitivo: "i versamenti crescono col reddito" e'
prudente per il bilancio, **non** per il capitale.
(3) **STESSO TOTALE, CALENDARIO DIVERSO = fattore 6.** €60.000 distribuiti: ultimi 10 anni
$178.494 (P(muro) 11%) / piatto 20a $496.778 (90%) / primi 10a $806.285 (98.3%) / primi 5a
**$1.104.587 (99.4%)**. ⚠️ NON significa "versa tutto subito": un piano che non si sostiene non
e' un piano — serve a scegliere fra calendari **sostenibili**.
**Verificato col rischio di venue dentro** (il vantaggio front-load mette piu' capitale
sull'exchange prima = proprio il rischio del giorno): **regge**, 2.22x → 2.09x a p=2%, perche' il
rischio colpisce il **tempo**, non il calendario. ⚠️ **MA a p=5% il capitale mediano e' $0 per
OGNI calendario** (64% di rovina su 20a) → **formulazione piu' netta del rischio di venue trovata
finora: non erode il piano, lo CANCELLA.**
(4) **LA DOMANDA INVERSA — rendita netta €/g mediana** (riformula l'obiettivo: €50/g e' UN punto,
non l'unico risultato):
| €/mese | 5a | 10a | 15a | 20a | P(€50/g a 20a) |
|---|---|---|---|---|---|
| 100 | 2.08 | 6.54 | 16.40 | 38.07 | 31.0% |
| 150 | 3.00 | 9.55 | 23.96 | 55.80 | 58.7% |
| **250** | 4.83 | 15.53 | 39.11 | **91.30** | **90.0%** |
| 400 | 7.59 | 24.52 | 61.85 | 144.23 | 98.9% |
| 600 | 11.26 | 36.52 | 92.17 | 215.07 | 100.0% |
Non-linearita': **da 15 a 20 anni la rendita piu' che raddoppia a ogni livello** (gli ultimi anni
contano piu' in *rendita*, i primi piu' in *versamenti*).
(5) **FREQUENZA = la decisione meno importante.** Mensile fino a ~$2 di costo per trasferimento,
bimestrale sopra, trimestrale oltre $25 — ma le differenze sono **1-3%** del capitale finale.
Verificato che un deposito **non resta strozzato**: col cap dinamico attivo cap = equity/2 =
esattamente il nozionale massimo richiedibile per asset.
📌 **ORDINE DI IMPORTANZA (da citare quando si parla del piano):** versare o no (**da mai a 16
anni**) > quando (**6x**) > quanto presto si smette (5 anni = 58% del risultato) > piatto vs
crescente (24%) > frequenza (1-3%). E sopra tutte, fuori scala: **a p=5% di rischio venue il
risultato mediano e' zero comunque.**
**REGOLE:** (a) un piano di accumulo si giudica sulle sue **deviazioni**, non sul caso nominale —
piatto/ininterrotto/per sempre e' l'unico scenario che non succede; (b) piani di taglia diversa si
confrontano con una metrica **normalizzata** (`$ finale / $ versato`), altrimenti "versa di piu'"
vince sempre; (c) un vantaggio calcolato **ignorando un rischio noto** va ri-misurato con quel
rischio dentro anche quando ci si aspetta che regga (qui reggeva, ma la colonna p=5% ha prodotto
il risultato piu' importante del filone); (d) quando l'obiettivo dichiarato non e' raggiungibile,
la tabella utile e' quella **inversa** — non "quando arrivo a X" ma "cosa compro con quello che
ho".
- ❌ **MURO COME PUNTO FISSO — la mia previsione era SBAGLIATA e il numero pubblicato era giusto
per caso (2026-07-26).** Script `r0726_wall_fixedpoint.py`, test `tests/test_wall_fixedpoint.py`
(11), diario `2026-07-26-wall-fixedpoint.md`. **Book/pesi/cron INVARIATI.**
Il follow-up dichiarato diceva: *"i muri usano il book a 2 sleeve da $600 estrapolato a $272k;
il book diversificato ha Sharpe piu' alto → **il muro vero e' piu' basso**"*. **Misurato: FALSO.**
(1) **Struttura giusta: il muro e' un PUNTO FISSO** — serve capitale C per girare il book che
determina il muro C → si itera `C_{n+1} = muro(book(C_n))`. Converge in **1 iterazione** perche'
il muro cade **sopra** la soglia XS01 ($117k), quindi la composizione non cambia; la struttura
conta solo se il muro atterra vicino a una soglia — ma **va iterato per saperlo**.
(2) **Risultato:** book deployable (TP01 38/SKH01 23/GTAA01 23/XS01 17; **VRP01 escluso** per
regola short-vol, **XSR01 escluso** per gate 23/10; costi capital-aware; ancora ×0.860 misurata
su questo book) → Sharpe **1.94**, vol 8.9%, CAGR 18.3%. **Muro $273.900 vs $272.061 = +1%.**
(3) **Perche':** diversificare alza lo Sharpe (1.64 → 1.94) ma abbassa **drift e vol insieme**;
la rendita perpetua vive sul **drift** → 10.91% → 10.84% = invariata. **Il guadagno di Sharpe va
in meno rischio, non in piu' reddito** — cioe' il fatto gia' misurato il 25/07 §3, che avevo
dimenticato scrivendo il follow-up.
(4) ⚠️ **Stavo violando una regola gia' codificata:** *"un diversificatore a basso CAGR si giudica
a ISO-RISCHIO, mai a iso-nozionale"* (25/07 §3). A iso-rischio (leva **1.28x**): rendita 13.35%,
**muro $222.406 = 18%** — ✅ **replica indipendente** del 19% misurato il 25/07 con macchineria
e book diversi. Vale **solo** se la leva e' disponibile e a costo < uplift (IB: Reg-T 2x,
portfolio margin da ~$110k, margine ~5.5%/a): **$222k e' un TETTO, non una stima.**
(5) ⚠️ **BUG catturato prima di pubblicare:** la prima corsa dava Sharpe 0.95 e muro **$854k**
("diversificare triplica il muro" — spettacolare e falso). Causa: `CC.gtaa_banded` ritorna la
storia GTAA **dal 1996** mentre lo sleeve di produzione tronca a `GTAA_BOOK_ACTIVATION`; con la
rinormalizzazione per-riga di `combine_outer` il **75% del campione** era **GTAA01 da solo al
100%**. Preso **non da un test** ma perche' la somma pesata dei componenti (~18%) non tornava col
drift del combinato (6.8%). **Diagnostica decisiva: la COPERTURA PER COLONNA** (TP01 24.6% /
SKH01 24.6% / GTAA01 100.0% / XS01 8.6%) — un 100% accanto a valori bassi dice tutto.
**REGOLE:** (a) un follow-up dichiarato contiene una **previsione**, che va misurata non assunta;
(b) **rileggere le regole gia' codificate prima di impostare il confronto**; (c) quando un
aggregato non torna con la somma dei suoi pezzi, **fermarsi** — era l'unico segnale del bug
(nessun test, nessuna eccezione, output plausibile); (d) **la copertura per colonna e' la prima
diagnostica di un outer-join**.
- 💰 **IL CAPITALE GIA' FERMO — la leva mai misurata, e la decisione di venue che ne dipende
(2026-07-27).** `r0727_lumpsum_split.py`, test `tests/test_lumpsum_split.py` (14), diario
`2026-07-27-lumpsum-venue-gates.md`. **Book/pesi/config INVARIATI.** Tutte le traiettorie del
25-26/07 hanno `START = 600.0` **cablato**: il progetto ha misurato il *calendario* dei
versamenti (fattore 6) e mai un **versamento iniziale**, mentre su Revolut ci sono ~€10.000 (di
cui €6.043 in XEON a ~0% reale netto) contro i $600 che girano. Macchineria = generalizzazione
di `r0726_venue_risk.simulate`, **validata: con lump 0 riproduce IDENTICI i numeri del 26/07**.
(1) **Cosa compra** (p=0, 20a): **€10.000 fermi oggi e mai piu' nulla → traguardo 17.2a mediani,
P 62%, rendita €61.58/g** (il piano €250/m senza lump: 15.7a, P 95%, ma $66.818 versati contro
$10.900). Con entrambi: **13.3a, P 99.5%**. (2) ⚠️ **L'equivalenza si misura in versamento
mensile equivalente, NON in versamenti risparmiati**: la prima stesura diceva "€10k ≈ €7.414
risparmiati = 0.7x" — numero giusto, **domanda sbagliata** (il valore e' arrivare prima, non
versare meno), e invita alla conclusione opposta. Onesto: **€10.000 oggi = +€154/mese per 13
anni = €24.523, cioe' 2.45×.** (3) **Col rischio di venue dentro** (a €10k il conto e' $11.500 e
lo split diventa possibile — a quota IB **26%**, non il 25% preferito: sotto $3.000 la gamba
equity non esiste): lo split costa **1.9-2.6pp** di P(arrivare) e taglia **P(perso tutto) da
18.4% a 3.5%** a p=1% (da 33.7% a 11.2% a p=2%). Il haircut dichiarato sulla gamba IB (0.8pp
taglia piccola + 0.1pp UCITS) sposta **0.1-0.2pp**: il costo della gamba equity non decide.
⚠️ **P(perso tutto) sotto concentrazione NON dipende dal capitale** (con un conto solo "almeno
un fallimento" coincide con "perso tutto"): il lump non la peggiora, **moltiplica cio' che porta
via**. (4) ✅ **IL RISULTATO OPERATIVO — la protezione non e' bloccata dal PRIIPs.** GTAA01 oggi
non e' deployabile, quindi misurato anche lo **SPLIT-CASSA** (seconda gamba ferma): costa
**0.6-0.8pp** di P(arrivare) in piu' e **la protezione e' IDENTICA** (dipende da quanti conti
falliscono, non da cosa ci sta sopra). **Un rischio non-diversificabile si compra con un secondo
CONTO, non con un secondo sleeve.** (5) **Soglie:** split a quota raccomandata da **$12.000**,
forzando al 35% da **$8.571**. La riapertura della decisione venue e' a $20.000: **un lump da
€10k cade sotto quella soglia ma sopra la fattibilita' tecnica, ed e' un cambiamento del piano
= il caso in cui CLAUDE.md dice di riaprire PRIMA.** Materiale pronto; la decisione resta
dell'operatore. ⚠️ Cosa NON decide: quanto dei €6.043 sia vero fondo d'emergenza (un fondo
d'emergenza non e' capitale disponibile).
**ADDENDUM "€5k messi dove" (stessa sessione).** (a) ⚠️ La configurazione REALE non era quella
tabulata: `config/live.json` fu alzato il 26/07 *"in previsione del versamento (EUR 5.000 +
500/mese)"* → il piano e' **€500/mese**, non €250. **Nessuna azione di config al deposito**: il
cap e' gia' `min($3.000, equity_osservata × 0.5)` = leva lorda ≤1x a $6.050, protetto dal
watermark. (b) **A $6.050 non si sblocca NIENTE** (GTAA01 vorrebbe il 50% del conto e non e'
deployabile; XS01 $20k; XSR01 sotto gate) → il book resta TP01+SKH01 e l'unica domanda e' quanta
parte NON sta sull'exchange. (c) **Split in liquidita', p=1%, 20a:** fuori 0% → P(arrivare)
89.4% / 11.4a / P(perso tutto) 18.4%; **10% → 89.0% / 11.8a / 3.5% [0.0% con cassa in banca] /
salvati $6.818**; **25% → 88.5% / 12.4a / salvati $17.045**; 40% → 87.8% / 13.3a / $27.272.
⚠️ **P(perso tutto) SATURA a qualunque quota > 0** (3.5% al 10, 25 e 40%): la protezione binaria
si compra col FATTO di avere un secondo conto, non con quanto ci si mette → **quando una metrica
binaria satura, la decisione si sposta sulla metrica continua** (qui il salvataggio).
⚠️ **Errore mio corretto in sessione:** la colonna del salvataggio riportava prima il capitale a
20 anni condizionato al fallimento ($77k al 10% = 11× il vero), gonfiato dalla convenzione
ereditata dal 26/07 per cui **i versamenti si dirottano ai superstiti** (e si scartano se non ne
resta nessuno) → attribuiva allo split il valore di *continuare a versare*, che si ottiene
comunque aprendo un altro conto. Misura onesta = **salvataggio ISTANTANEO**, congelata in
`test_il_salvataggio_e_istantaneo_non_a_scadenza`. (d) ✅ **Lo split non si costruisce spostando
soldi su un secondo venue: si ottiene versandone di meno.** Con €6.043 in XEON, deporne €5.000
lascia fuori ~16% del capitale investito = gia' dentro la banda 10-25%, **a costo operativo
zero**. Prezzo del 25%: 0.9pp di P(arrivare) e ~1 anno di ritardo mediano.
- 💰 **IL FISCO DURANTE L'ACCUMULO — mai contato in nessuna traiettoria, vale 30% a 10 anni
(misurato 2026-07-27, registrato qui il 2026-08-07).** ⚠️ I quattro risultati del 27/07 sera
(`r0727_3k_vs_5k.py`, `r0727_orizzonte10.py`, `r0727_tasse.py`) erano **solo nei messaggi di
commit**, ne' in CLAUDE.md ne' in un diario — e uno cambia il numero di testa del piano.
`TAX_RATE` compariva in **un solo punto** del progetto: la lordizzazione del bersaglio in fase di
*prelievo*. L'accumulo componeva al **lordo** per dieci o vent'anni.
**Costo (lump €5.000 + €500/mese): 15.7% a 5 anni · 29.8% a 10 · 42.6% a 15**
(27/07 su lump €10k: 16.8 / 31 / 44% → replica coerente). **L'errore e' COMPOSTO.**
⚠️ **Conseguenza: TUTTE le tabelle a 15-20 anni pubblicate sopra sono al LORDO** del fisco
d'accumulo e vanno lette con questo sconto. Assunzioni dichiarate (33% plusvalenze, minusvalenze
in carry 4 anni, 0.2% annuo sul valore), **non un parere fiscale**; il modello tassa la variazione
ANNUA di valore = limite superiore, stretto perche' il book realizza quasi tutto entro l'anno.
**Vincolo dei 10 anni (operatore, 49 anni): il piano NON lo regge.** €5k+€500/m → P(entro 10a)
**19.7%** al lordo; €10k+€500/m → 33.9% lordo ma **3.8% col fisco**. Servono **€880/mese a P=50%**,
**€1.051 a P=75%** (lump €10k) → si versano oltre $119.000 per arrivare a $272.061: *a orizzonte
corto non fai lavorare la strategia, compri il capitale coi bonifici*.
📌 **Contro-intuitivo: versare di piu' RITARDA il sorpasso** (l'anno in cui il guadagno cumulato
supera tutto il versato): 7º anno a €500/m, **8º a €800/m** — alza l'asticella. I €300 in piu'
comprano il **traguardo**, non il sorpasso: mediana al bersaglio al 12º anno invece del 15º,
P(bersaglio) a 15a da 73.2% a **99.0%**. Lump €3k vs €5k = ~1.8 mesi ogni €1.000 → non e' una
decisione. Script `scripts/research/r0807_growth_yearly.py`.
**TABELLE RIFATTE AL NETTO (2026-08-07) — il muro si sposta poco, i VERSAMENTI molto.**
`scripts/research/r0807_piano_netto.py`, test `tests/test_piano_netto.py` (16), diario
`2026-08-07-piano-al-netto.md`. **Book/pesi/cron/config INVARIATI.**
**(0) Controllo di replica superato:** a fisco spento la nuova macchina riproduce **$272.061 al
dollaro** (implementazione separata) e la colonna LORDA delle traiettorie riproduce **4 righe su
4** della tabella pubblicata (16.3/12.4/9.0/6.0 contro 16.2/12.4/9.0/6.0). ⚠️ Trovato per
strada: `perp_and_wall` gira a **2000 path** e a quella taglia da' **$269.648** → **la terza
cifra del muro e' rumore Monte Carlo (0.9%)**: si cita **$272k**, non $272.061.
**(1) IL MURO era calcolato con una convenzione ASIMMETRICA** — prelievo lordizzato ma capitale
che compone senza mai pagare imposte. Coerente (imposte annue dentro il portafoglio, prelievo
gia' netto): perpetua **10.91% → 7.70%**, muro **$272.061 → $258.338 (5.0%)**; a 26% $236.310.
I due errori vanno in versi OPPOSTI e **si compensano quasi — per caso, non per costruzione**.
**(2) TRAIETTORIE da $600** (25a, 3000 path, seed 725; mediana CONDIZIONATA all'arrivo + P(20a)):
| €/mese | LORDO anni / P(20a) | **NETTO anni / P(20a)** |
|---|---|---|
| 0 | mai / 0% | **mai / 0%** |
| **250** | 16.3a / **92%** | **19.8a / 52%** |
| 500 | 12.4a / 100% | **14.7a / 99%** |
| 800 | 10.0a / 100% | **11.4a / 100%** |
| 1000 | 9.0a / 100% | **10.0a / 100%** |
| 2000 | 6.0a / 100% | **6.4a / 100%** |
📌 **€250/mese — il livello con cui il piano risultava «P 92%, funziona» — al netto e' una
moneta (52%).**
**(3) QUANTO VERSARE, al netto** (bersaglio $258.338; fra parentesi il vecchio numero lordo):
| orizzonte | P=50% | P=75% | **P=90%** | P=95% | tot. versato @P=90% |
|---|---|---|---|---|---|
| **10 anni** | €998/m | €1.162/m | **€1.323/m** *(€1.178)* | €1.424/m | **$175.058** *($155.923)* |
| 15 anni | €470/m | €570/m | **€672/m** *(€509)* | €725/m | $133.983 *($101.643)* |
| 20 anni | €245/m | €306/m | **€371/m** *(€237)* | €417/m | $98.762 *($63.406)* |
**Il fisco costa +12% al mese a 10 anni, +32% a 15, +57% a 20** (cresce con l'orizzonte perche'
l'errore era composto). La lettura del 26/07 si RAFFORZA: a 10 anni versi $175k per arrivare a
$258k (il rendimento fa il **32%**), a 20 anni ne versi $99k (il rendimento fa il **62%**).
**(4) RENDITA €/g mediana, netta** (perpetua 7.70%, imposte gia' dentro — non lordizzare due
volte): €250/m → 4.38 (5a) / 11.82 (10a) / 24.61 (15a) / **46.61 (20a)**, P(€50/g a 20a)
**42.0%** contro i **91.30 €/g e 90.0%** pubblicati; €500/m → 92.11 e 97.6%; €800/m → 146.78.
**COSA NON CAMBIA:** senza versamenti il capitale-rendita non si raggiunge **mai** a nessuna
lente fiscale; l'ordine delle leve (versare > quando > quanto presto si smette > piatto vs
crescente > frequenza) e' invariato; il rischio di venue resta fuori scala (a p=5% il mediano
e' zero comunque).
⚠️ **ERRORE MIO catturato prima di pubblicare:** la prima stesura calcolava la mediana degli
anni sull'INTERO vettore coi non-arrivi a `-1` → €250/mese risultava passare da 15.7 a **15.3**
anni col fisco (*piu' veloce*) mentre P crollava da 91% a 53%, perche' con meta' dei path a 1
la mediana cade sui PRIMI arrivi. **REGOLA: un non-arrivo va codificato +∞, mai 1** — con 1 il
numero migliora tanto piu' quanto peggio va la colonna. E **una mediana condizionata si stampa
sempre accanto alla sua probabilita'**.
**REGOLE:** (a) un modello che tassa una meta' del conto e non l'altra non e' conservativo, e'
**incoerente** — e i due errori possono compensarsi quasi esattamente, il che li rende
invisibili finche' non si rifa' il conto in modo simmetrico; (b) prima di pubblicare un numero
nuovo, **far riprodurre alla macchina quello vecchio**; (c) **un Monte Carlo ha una risoluzione
e va detta** ($272.061 e' esatto quanto $269.648: la differenza e' la taglia del campione).
- 🇮🇹 **QUADRO FISCALE VERIFICATO SULLE FONTI (2026-08-07) — il 33% e' confermato, la citazione
normativa del progetto era SBAGLIATA, e la domanda che vale $22k resta aperta.**
Fonti: Fisco Oggi (rivista dell'Agenzia), Eutekne, Fiscomania, Circolare AdE 30/E del
27/10/2023, guide professionali. **Non e' un parere fiscale.** Corretto in
`r0725_capcurve.py`, `r0725_ib10k.py`, `r0727_tasse.py`, `r0807_asset_compare.py` e nel diario
24/07. **Nessun numero del piano cambia**: l'aliquota assunta era ed e' 33%.
**CONFERMATO** — (a) **33%** sulle plusvalenze cripto realizzate **dal 1/1/2026**, su
`art. 67 c.1 lett. c-sexies` TUIR; (b) **franchigia €2.000 ABOLITA dal 2025**;
(c) **minusvalenze riportabili 4 periodi d'imposta** (`art. 68 c. 9-bis`) ma **solo contro
plusvalenze cripto** — comparto separato dagli strumenti finanziari tradizionali;
(d) **patrimoniale 2‰** sul valore al **31 dicembre** (dovuta sopra €12/anno), quadro RW/W;
(e) regime **dichiarativo** per gli exchange esteri (quadro RT per i redditi, RW per il
monitoraggio).
⚠️ **CORREZIONE DI FONTE:** il progetto citava ovunque «L.199/2025» come origine del 33%.
**Falso.** Il 33% dal 2026 e l'abolizione della franchigia vengono dalla **L. 207/2024
art. 1 c. 23-29** (Bilancio 2025). La **L. 199/2025 art. 1 c. 28** (Bilancio 2026) fa un'altra
cosa: ritaglia il **26% per i soli token di moneta elettronica denominati in EURO** (EMT ex
Reg. UE 2023/1114, riserve interamente in attivi in euro presso soggetti UE autorizzati) e
stabilisce che la conversione euro↔EMT non e' realizzo. **BTC/ETH e le stablecoin in DOLLARI
restano al 33%** → nessuna scappatoia per questo book.
**APERTA, e nessuna fonte la chiude: come si qualificano i DERIVATI Deribit.** La Circolare
30/E (118 pagine) definisce le cripto-attivita' e **non tratta i derivati**. Le fonti
professionali sono nette nel senso opposto al nostro assunto — *«i CFD su crypto NON sono
cripto-attivita': sono derivati su sottostante crypto e vivono nella Sezione II del Quadro RT,
aliquota 26%»* (`lett. c-quater`) — **ma parlano di CFD di broker UE regolati in euro**, non di
contratti *inverse* marginati e regolati **in cripto** su sede extra-UE, che e' esattamente il
caso in cui la qualificazione puo' ribaltarsi. **Domanda da porre al commercialista, in questi
termini:** i future/opzioni BTC-ETH di Deribit (inverse, margine e regolamento in cripto, sede
extra-UE) stanno in `c-sexies` (33%, RT Sez. V) o `c-quater` (26%, RT Sez. II)? E il
collaterale in BTC/ETH sconta comunque il 2‰ al 31/12?
💰 **Vale $258.338 → $236.310 di muro (8.5%) e ~€30/mese di versamento a 20 anni** — piu' di
quasi tutti gli uplift per cui in questo progetto si e' discusso se ammettere uno sleeve, e non
si risolve backtestando.
⚠️ **Conseguenza modellistica trovata qui:** se i derivati sono `c-quater` sono un **comparto
di compensazione SEPARATO** dalle cripto → il buffer di carry UNICO a 4 anni di
`r0807_piano_netto` / `r0727_tasse` e' ottimistico **sulla coda** (non sull'aliquota).
📌 L'**affrancamento al 18%** (rideterminazione del costo ai valori 1/1/2025, L. 207/2024) e'
**scaduto il 30/11/2025**: non e' una strada aperta, e a questo capitale non lo sarebbe stata.
**REGOLA: una fonte normativa citata in un commento di codice si verifica come un numero**
questa era sbagliata da settimane in 5 file, e nessun test poteva accorgersene.
- ⚖️ **BOOK vs ETF (S&P 500 / MSCI World) — le due lenti danno risposte OPPOSTE, e la scelta
robusta e' un MIX 50/50 (2026-08-07).** Script `r0807_asset_compare.py` + `r0807_best_strategy.py`;
diario `2026-08-07-crescita-fisco-etf-scelta.md`. **Book/pesi/cron/config INVARIATI.**
Tre cose rese comparabili: **griglia** (azioni su calendario con 0.0 a borsa chiusa = convenzione
GTAA01; senza, Sharpe ×1.20 — lezione 25/07), **fisco** (book realizza ogni anno al 33%; UCITS ad
accumulazione paga 26% **alla vendita** → le curve ETF sono valori di *liquidazione*: il
differimento e' un vantaggio strutturale dell'ETF ed e' nel modello), **bersaglio** ($272.061 vale
per la rendita perpetua *del book* e per il 33% → ricalcolato per ciascuno).
| a 15a, €5k+€500/m | book | S&P 500 | MSCI World (proxy) |
|---|---|---|---|
| rendita perpetua | 11.67% | 4.16% | 3.09% |
| capitale-rendita | $254.524 | $646.172 | $869.729 |
| lente A (storia piena) | $293.823 → **115%** | $204.663 → 32% | $188.417 → 22% |
| lente B (stessa finestra) | $295.540 → 118% | $343.805 → **110%** | $296.707 → 82% |
📌 **Il risultato non e' chi vince, e' che le due lenti si contraddicono:** sulla storia piena il
book stravince, **sulla stessa finestra l'S&P 500 accumula PIU' del book** — il divario della
lente A e' tutto nei crolli 2000/2008 che la strategia non ha mai vissuto.
📌 **E sulla stessa finestra il rendimento e' quasi identico — 17.4% contro 16.8%.** Tutta la
differenza e' nel RISCHIO (vol 11.0 vs 19.6%, maxDD 10.5 vs 33.7%): **il book non guadagna di
piu', perde di meno** — conferma indipendente di cio' che il progetto scrive di TP01 dal 19/06,
misurata contro un'alternativa vera. La rendita perpetua vive sul drawdown → **2.5× meno capitale**.
⚠️ **Un MIX esiste solo dove esistono ENTRAMBE le serie** (errore commesso e corretto: la lente
"storia piena" calcolava i bersagli del mix sull'intersezione → dichiarava 30 anni e ne usava 7).
Percio' la scelta si giudica su UNA finestra con gli scenari espressi come spostamento del
**drift**, simmetrico sui due lati. **A 12 anni, quota del proprio bersaglio:**
| w book | base | equity 30a | book/2 | entrambi cauti | peggiore | **rimpianto max** |
|---|---|---|---|---|---|---|
| 0% | 68% | 23% | 68% | 23% | 23% | 53% |
| 25% | 80% | 41% | 60% | 27% | 27% | 34% |
| **50%** | **86%** | 58% | 48% | 27% | 27% | **20%** |
| 75% | 84% | 69% | 32% | 23% | 23% | 35% |
| 100% | 75% | **75%** | 16% | 16% | 16% | 52% |
**Risposta: 50/50** — non perche' vinca (vince solo nel base) ma per il **rimpianto minimo**.
⚠️ Il criterio del solo caso peggiore **non** distingue 25% da 50% (27.09 vs 26.99% = pareggio
dentro il rumore): a separarli e' il rimpianto.
📌 **L'asimmetria fra i due stress E' il risultato:** quello sull'equity e' **MISURATO** (30 anni
esistono: 11.3% invece di 16.5%), quello sul book e' **GIUDIZIALE** (meta' del drift, a mano,
perche' 7.4 anni sono tutta la storia che ha e non c'e' nulla con cui stressarlo). Conseguenza
brutale: col drift dimezzato il capitale-rendita del book puro passa da $254k a **$771.646**
(rendita 11.67% → 3.85%).
**Perche' il mix non e' un compromesso:** corr book↔S&P **+0.082** (borsa aperta), **+0.046** nei
ribassi; nel 5% di giornate peggiori dell'indice (media 2.94%) il book fa **0.11%** → il
capitale-rendita del 50/50 e' **$235.769**, piu' basso sia del solo ETF ($311.567) sia del solo
book ($254.524): **due motori scorrelati abbassano l'asticella**.
⚠️ MSCI World e' un **PROXY** 70% SPY + 30% EFA (URTH/ACWI/VT non sono nell'abbonamento dati IB);
fra 50 e 80% di quota USA il drift si muove di 0.7pt e il Sharpe di 0.05. Il rischio di venue NON
e' nel conto (spingerebbe ancora verso il mix) e la decisione del 26/07 tiene tutto su Deribit
fino a $20k → **questa analisi e' materiale per quella soglia, non un'indicazione di agire ora**.
- 🖥️ **SIMULATORE NEL BROWSER — `scripts/web/` (2026-08-07).** Motore di accumulo in JavaScript
(`engine.js`) sui ritorni veri del book esportati da `export_series.py`; pagine assemblate da
`build.py` (dati **iniettati** da JSON, mai trascritti); `test_engine.js` prova che il motore
riproduce `r0807_growth_yearly.py` e `dep_necessario`; `smoke.js` ESEGUE le pagine con un DOM
finto. **REGOLE (quattro errori miei, tutti trovati da un controllo e non a occhio):**
(a) i dati di una pagina si **iniettano da un file**, mai si trascrivono — due anni di una serie
erano stati scritti *a memoria* perche' `tail` aveva troncato l'output;
(b) **un confronto punto-contro-distribuzione non prova una distorsione**: "8 semi JS tutti sopra
il Python, +0.75%" erano 8 estrazioni contro UN punto rumoroso → misurato bene (8 semi per parte)
**0.01%, t = 0.04**, ed entrambi i campionatori entro 1.7 SE dall'atteso ANALITICO;
(c) le chiavi di un dizionario Python si **leggono dal JSON**, non si ricostruiscono
(`"0.0"` vs `String(0)`=`"0"` → pagina pubblicata rotta, e i pesi intermedi funzionavano *per caso*);
(d) **`node --check` valida solo la SINTASSI**: una pagina puo' passarlo e morire alla prima riga.
Misura che ha guidato una scelta: la banda del versamento suggerito resta **±1% da 1.200 a 3.000
percorsi** → non domina il Monte Carlo ma la **granularita' della bisezione** (~€5) → percorsi
tenuti bassi e incertezza **dichiarata**.
- 🚨 **IL PIANO AL NETTO DI TUTTO — la tabella congiunta (2026-08-22, `r0822d_piano_vero.py`).**
**QUESTA SOSTITUISCE OGNI TABELLA DI TRAIETTORIA PUBBLICATA SOPRA.** Le due correzioni misurate al
piano — **fisco d'accumulo** (07/08) e **funding** (22/08) — erano state applicate **separatamente
allo stesso numero lordo**, e la tabella con **entrambe** non esisteva. Registro §36.
**Replica 6/6 prima di pubblicare, due esatte AL DOLLARO** sul vintage 07/08 ($272.061 lordo,
$258.338 netto fisco). ⚠️ Sulla serie di **oggi** la stessa riga da' **$278.033 (+2,2%)** — 15
giorni di dati in piu', `data/raw/` gitignored (**stessa lezione GTAA del 07/08**) → **ogni terza
cifra di un muro e' rumore**, e i confronti fra lenti vanno fatti sullo stesso vintage.
| lente (de-luck ×0,89) | drift | perpetua | muro | **€250/m da $635: P(20a)** |
|---|---|---|---|---|
| L0 LORDO (26/07) | 17,11% | 10,68% | $278k | **90%** *(pubbl. 92%)* |
| L1 +FISCO (07/08) | 17,11% | 7,52% | $264k | **49%** *(pubbl. 52%)* |
| L2 +FUNDING (22/08) | 15,19% | 9,06% | $328k | **63%** |
| 🚨 **L3 CONGIUNTA** | **15,19%** | **6,35%** | **$313k** | **14%** |
| L3b congiunta, funding "strumento vero" 1,39%/a | 15,87% | 6,72% | $296k | **26%** |
🚨 **IL MURO E' UNA MEDIANA, E LA SUA BANDA E' ESPLOSIVA (misurato dal critico, 23/08).**
La SE del drift L3 e' **5,151%/anno** (block bootstrap 20g; replicata su un'altra lente a 5,09):
**+1 SE → $204.517 · p90 → $186.623 · PUNTO $313.143 · p10 → $1.141.172 · 1 SE → $709.753 ·
2 SE → il traguardo NON ESISTE a nessun capitale.** «€500/mese → P(20a) 85%» diventa **~0% a
1 SE**; «€250/mese → 14%» diventa **96% a +1 SE**. 📌 **Meccanismo: il muro e'
`prelievo/perpetua` e la perpetua si annulla molto prima del drift → e' un 1/x su una quantita'
che va a zero, quindi l'errore e' asimmetrico verso l'alto.** 🚨 **E il progetto ha pubblicato la
risoluzione MONTE CARLO del muro (0,7%) accanto a un numero la cui incertezza di PARAMETRO e'
cento volte piu' grande: ha misurato la precisione del simulatore e mai quella del suo input.**
⚠️ La SE del block-bootstrap e' un **limite inferiore** (variabilita' dentro gli stessi 7,4 anni,
non il cambio di regime). **REGOLA: il piano si dimensiona sul VERSAMENTO, che e' certo, non sul
muro.**
🚨 **LE DUE CORREZIONI NON SI COMPENSANO: SI SOMMANO — e nel VERSAMENTO necessario il congiunto e'
+10% PEGGIORE della loro somma.** Il meccanismo "meno drift → meno plusvalenza → meno imposta"
**esiste** (+9,97% di capitale recuperato; il fisco toglie il 50,9% a funding OFF e il 46,0% a
funding ON) **ma la funzione versamento→probabilita' e' CONVESSA e ne ribalta il segno**.
Interazione misurata **in tre monete**: +9,97% sul capitale · **$815 sul muro (0,26%, SOTTO la
risoluzione MC)** · **+26 €/mese sul versamento (+10%, segno stabile su 3 semi)**.
**REGOLA: non contare su una compensazione fra correzioni misurate separatamente — la si misura, e
in piu' di una MONETA, perche' un'interazione piccola cambia segno con la moneta.**
**QUANTO VERSARE, al netto di tutto** (da $635, nessun lump):
| orizzonte | P=50% | P=75% | **P=90%** | totale versato @P=90% | **quota del bersaglio** |
|---|---|---|---|---|---|
| **10 anni** | €1.323 | €1.534 | **€1.733** | **$229.189** | **73%** |
| 15 anni | €656 | €784 | **€920** | $183.129 | 58% |
| 20 anni | €360 | €445 | **€541** | $143.804 | 46% |
Il **solo funding** aggiunge **1,27× / 1,33× / 1,40×** sopra la lente fisco-only.
**RENDITA €/g mediana a 20 anni:** €250/m → **31,85 €/g, P(≥50/g) 8,8%** · €500/m → **63,05, P
77,1%** · €800/m → 100,50, P 99,2%.
📌 **IL LUMP, mai entrato nelle tabelle nette: €10.000 oggi + €250/m porta P(20a) da 14% a 45%**
(€5.000 → 30%). E' la leva piu' grande misurata dopo il versamento mensile stesso.
📌 **LA RISPOSTA ALLA DOMANDA DEL PROGETTO:** *€250/mese da $635 → **23,4 anni** (mediana
incondizionata; 22,1 condizionata all'arrivo), **P(20a) 14%** [banda "strumento vero": 22,2 anni,
26%]. Per **€50/giorno in 10 anni** servono **€1.733/mese** a P=90%, totale versato **$229.189**.*
**A 10 anni si versano $229k per arrivare a ~$313k: il rendimento fa il 27%, i bonifici il 73%**
⚠️ **CORREZIONE 23/08: il 73% e' l'INTERO ORIZZONTE, non il versato fino all'arrivo.** Il
contatore `versato` di `accumula` e' uno **scalare che non si ferma al traguardo** (stessa
famiglia del bug `paid` catturato il 25/07, in un altro punto): il versato **fino all'arrivo** e'
**$190.265 = il 61%**, con P(traguardo) 91%. E **«€X/mese» versa ogni 30 GIORNI** →
**121/182/243** versamenti invece di 120/180/240 (+0,83/+1,11/+1,25%), in ogni tabella dal 25/07.
Entrambi i difetti vanno **a favore** del piano. —
forma piu' netta della lezione gia' scritta: *a orizzonte corto non fai lavorare la strategia,
COMPRI il capitale coi bonifici.*
⚠️ **Cosa NON e' incluso, di proposito:** il **rischio di venue**, che e' **rovina e non costo**
(a p=5% il mediano e' zero a ogni calendario) — resta sul suo asse separato.
**Smentitori dichiarati:** il funding pre-2022 e' **proxy inverse sul 40% del campione** (se il
lineare 2019-21 fosse costato quanto il 2022+, la colonna vera e' **L3b**); il modello fiscale tassa
la **variazione annua di valore** = limite superiore; il bootstrap gira su **7,4 anni con due tori**.
- ⚖️ **CANALE FUNDED — `GATE PROP-01` CHIUSO 3/3 in una notte, e il numero onesto e' 2,6%
(2026-08-22).** Registro §29-32, §37. **Libro, pesi, cron, config INVARIATI.**
Il gate nato ieri con **due gambe datate ad anni** e' stato chiuso **tutto oggi**, e ogni chiusura
ha peggiorato il numero:
| gamba | criterio | esito |
|---|---|---|
| **(a) LISTINO** | ≥10 delle 13 gambe shortabili | ✅ **PASS 13/13** — misurato sul **venue** (Bybit `instruments-info`, 833 strumenti), non sul sito |
| **(b) ANCORA SKH01** | delta appaiato > +0,05 sui 23 offset | ✅ **PASS 23/23**, +0,116, 230/230 celle congiunte — ⚠️ ma «23/23» vale **~2 osservazioni**, vedi sotto |
| **(c) CAPITALE** | *riformulata, vedi sotto* | ✅ **PASS 2/2** |
📌 **La (c) e' stata RIFORMULATA perche' era una constatazione, non un criterio** — e la sua forma e'
**imposta dal costo della misura**: l'EV costa una corsa di script (**zero dollari**), la
**rimborsabilita' del deposito costa $579 e si puo' misurare solo COMPRANDO** → un gate d'attesa su
quella sarebbe **superabile solo dopo averlo violato**. Quindi:
**(c1) ECONOMICA** — EV del biglietto **> 0 con la quota trattata come SPESA PERSA**, alla cella
d'ancora **mediana** (non canonica), col **funding dentro**, lente **accoppiata**. *Oggi **$+1.615***.
**(c2) DI SOPRAVVIVENZA** — prezzo del biglietto **≤ 2 versamenti mensili del piano in corso**
(il piano d'accumulo e' la leva dominante misurata, e **zero e' assorbente**). *Oggi **$579 contro
$1.090***. **(c1) e' scritta perche' la rimborsabilita' NON decida:** il rimborso e' **un regalo, non
un'ipotesi su cui si e' scommesso**.
🚨 **IL NUMERO, e la catena di un giorno solo: P(≥50 €/g) da €600 in 36 mesi = 42% → 7,8% → 4,4% →
2,6% [1,5%, 4,7%], con P(zero) 40,3%.** Nell'ordine: universo fuori campione (42% del J stava in 6
gambe che nel 2021-23 non esistevano) · banda d'ancora di SKH01 (canonica al 91° pctl) · **funding**
(dJ 0,049 su **69/69** celle appaiate).
📌 **EV del biglietto POSITIVO in tutte e tre le convenzioni sul deposito** (spesa persa +$1.615 ·
rimborso al pass +$1.919 · rimborso al primo payout +$1.835). ⚠️ **E il progetto conteneva GIA' due
modelli contraddittori della quota:** `r0725_hyro:200` la rimborsa **al pass**, `pc.simulate` **mai**
— e il numero operativo usciva dal secondo.
🚨 **XS01 PAGA il funding, non lo incassa — meccanismo DIMOSTRATO:** `max|ΣW| = 2,8e-17`
(dollar-neutral esatto) ⇒ **il livello del funding non entra, entra solo la DISPERSIONE
cross-sezionale**, e il momentum compra i perp col funding **piu' caro****+1,45%/anno**
[IC95 +1,18/+1,72; banda onesta +0,69/+1,45 se HL e' ~2,1× il venue]. *L'ipotesi opposta ("market-
neutral ⇒ si compensa") era esplicita nel briefing ed e' falsa.*
📌 **Piu' leva sul funded ALZA E[payout] e ABBASSA P(payout): sono due obiettivi diversi**, e chi
vuole il rimborso non vuole la leva massima.
**IL CONFRONTO CHE DECIDE** (36 mesi, $654, stesso bootstrap appaiato, funding e fisco in entrambe):
| versamento | strada | mediana | media | P(≥50/g) |
|---|---|---|---|---|
| €0 | BIGLIETTO | $132 | **$9.592** | 4,2% |
| €0 | LIBRO | **$787** | $803 | 0,0% |
| €500/m | **BIGLIETTO** | **$39.820** | **$46.298** | **13,7%** |
| €500/m | LIBRO | $22.444 | $22.694 | 0,0% |
**`IL BIGLIETTO CONTRO IL VERSARE: MEGLIO — ma solo perche' il piano di versamento c'e', e la ragione
non e' il rendimento, e' il NUMERO DI VOLTE CHE SI PUO' GIOCARE.`** Senza versamenti la stessa
scommessa **perde la mediana 6× e vince la media 12×**: una lotteria a EV positivo che un conto da
$654 puo' giocare **una volta sola**. *(Il libro da solo fa P(≥50/g) 0,0% a 36 mesi **per struttura**:
non e' un difetto del libro, e' l'orizzonte.)*
⚠️ **Cio' su cui poggia tutto, dichiarato:** il drift di XS01 misurato su **13 gambe su 19**; la
**morte-firm ~10%/anno** e' un'**assunzione** (se fosse ≫ l'EV si azzera **senza che nulla nel
modello lo segnali**); il cap **$200k/trader** limita il canale per struttura.
⚠️ **Un numero netto catturato PRIMA di pubblicarlo:** il "capitale d'incrocio €1.000-2.000" **non e'
un meccanismo** — la ricchezza terminale della strada-biglietto e' **bimodale**, `P(cassa < $249)` si
muove **liscia** (56,3 → 0,0%) mentre la **mediana salta di un ordine di grandezza** appena quella
massa passa il 50%. **Li' la mediana non e' robusta**, ed e' esattamente il tipo di numero netto che
si sarebbe finito per citare come soglia di progetto.
- **Onestà sul target €50/giorno:** NON raggiungibile su 2000 in 1-2 anni (servono ~130k di
capitale o un DD da rovina). La leva non è la scorciatoia; la via è target-vol + capitale +
tempo. La strategia che *guadagna* esiste, ma a ~+€1.5/giorno su 2000.
Script ricerca: `scripts/research/track{A,B,C,D,E}_*.py` + `trackD_timing.py`.
+741
View File
@@ -0,0 +1,741 @@
# Produzione, sorveglianze e deploy
> Estratto **verbatim** da `CLAUDE.md` il 2026-08-25 durante la compattazione.
> Cio' che gira con soldi veri: esecuzione, tripwire, monitor, libro di bordo,
e i vincoli di deploy (PRIIPs/UCITS/broker).
> Il testo non e' stato riscritto: e' la memoria originale, spostata.
---
- **Ondata 2026-07-26 (3 filoni: esecuzione SKH01 / DVOLSPREAD / XSR01 fuori dal crypto) — 0 sleeve
nuovi, 1 raccomandazione operativa aperta, 1 lead promosso, 1 falsificazione.** Script
`r0726_{skh_onbook,dvolspread_gate,xsr_equity}.py`, test `tests/test_wave_0726.py` (11 casi),
diario `2026-07-26-wave-esecuzione-dvolspread-xsr-equity.md`. **Book/pesi/cron INVARIATI.**
(1) ⚠️ **T1 — IL DEGRADO D'ESECUZIONE DI SKH01 ERA ANCH'ESSO FORTUNA D'ANCORA.** Testato l'unico
meccanismo che non e' un cron (ordini **resting on-book**: TP = limit al livello per costruzione +
fee maker; SL = stop-market). A **offset 0** l'on-book recupera il **94%** del degrado — ma
l'audit 02/07 aveva de-luckato i numeri headline di SKH01 e **NON il degrado**, misurato solo a
off0. Sulla banda appaiata dei 23 offset il degrado massimo recuperabile e' **+0.054 Sh di book**,
non 0.35 di sleeve. ⚠️ Errore di metodo mio, corretto in sessione: **mediana(A)mediana(B) fra
offset e' sbagliato** (confronta offset diversi) → serve la **mediana delle DIFFERENZE appaiate**;
con quella il verdetto si RIBALTA. Esito: **solo TP a limite = +0.054 FULL / +0.061 HOLD,
positivo in 19/23 (FULL) e 21/23 (HOLD) offset**; **lo SL on-book PEGGIORA** (contributo mediano
0.010, positivo in **11/23 = moneta**) perche' cristallizza la perdita al livello mentre l'exit
software ritardata incassa il rimbalzo — e sopra **0.50% di slippage** l'on-book e' peggio del
live. Meccanismo misurato: sulle uscite TP il fill orario **batte** il livello nel 42% dei casi
(vantaggio medio 0.035%) → il limit TP converte una lotteria in certezza piu' che aggiungere
ritorno; solo l'**1% degli SL gappa** davvero a 5m. **RACCOMANDAZIONE NON ESEGUITA (decisione
dell'operatore): TP come limit resting reduce-only, SL strategico NON on-book.** E' un cambio di
esecuzione (non passa `weights_tilt_null`) ma piccolo, da pesare contro ordini orfani/doppio fill.
Il disaster-SL 30% on-book resta com'e'.
**T1 NON IMPLEMENTATO — e il perche' e' una CORREZIONE DI MODELLO** (2026-07-26, diario
`2026-07-26-t1-esecuzione-skh-live.md`). Leggendo il codice di produzione: TP01 e SKH01 tradano
lo **stesso strumento** con **una sola posizione netta** Deribit → un ordine on-book al livello di
SKH chiuderebbe anche quota TP01. Misurati i 2 ostacoli: (A) segno compatibile nel **97%** dei
trade che escono in TP (long 100%, short 94%) = risolvibile; (B) divergenza modello/live che
sembrava bloccante (ritardo mediano 115 min, **70%** dei TP con ≥1 cron dentro la finestra).
⚠️ **MA (B) NON ESISTE: `resample_5m` NON scarta il bin 230m in corso** (verificato: 21 barre 5m
su 46 nell'ultimo bin) **e `_skyhook_positions` ci itera dentro** → il live rileva gia' SL/TP
**intra-barra**, entro ~1h dal tocco. I docstring che dicevano "usa solo barre chiuse" /
"latenza fino alla chiusura della barra 230m" erano **FALSI** e hanno guidato 3 analisi
(02/07, 24/07, T1) — **corretti sul posto**. Conseguenza: la lente `hourly` **sottostima il path
live di +0.081 Sharpe FULL di book (23/23 offset, banda appaiata)**, il live vero sta **sopra il
canonical** sul FULL, e **il fix richiesto sarebbe un DECLASSAMENTO** (+0.054 vs +0.081) in cambio
di ordini parziali sul netto in un percorso con soldi veri. → non fatto, per misura, non per
difficolta'.
**CABLATO INVECE il problema vero trovato per strada:** `fresh_5m` **fallisce in SILENZIO**
(fallback al feed certificato, rigenerato 1x/giorno) → la latenza d'uscita di SKH01 passa da ~1h
a **~1 giorno** senza che nulla lo segnali (conto online, posizione leggibile, e il gate di
staleness guarda il feed di TP01: **nessun controllo esistente scatta**). Stesso schema del
feed-freeze del 14/07, su un altro feed. Aggiunti: `livefeed.feed_age_minutes` (pura, eta' dalla
CHIUSURA della barra, `None`=non misurata, clamp sugli skew), `book_report.skh_feed_age_min`
(max fra gli asset), allerta Telegram in `book_execute` sopra `skh_feed_max_age_min`=**30 min**.
**Scelta dichiarata: ALLERTA, NON blocca** — bloccare fermerebbe anche TP01 (nettato sullo stesso
strumento) per un guasto di rete, e forzare SKH flat chiuderebbe posizioni buone su un glitch.
Test `tests/test_skh_feed_freshness.py` (11 casi). Strategia/pesi/cadenza INVARIATI.
⚠️ **SEGUITO 2026-07-29 — l'allerta ha funzionato, la sua CAUSA era una riga CABLATA.** Diario
`2026-07-29-feed-skh-causa.md`; test 11 → **16**. **Book/pesi/config/strategia INVARIATI.**
Il 29/07 (dopo il riavvio VPS delle 04:11) il feed e' ricaduto sul certificato in **6 giri orari
su 8** fra le 05:00 e le 12:00: eta' **265→685 min** (+60 a ogni giro = firma esatta del fallback)
→ latenza d'uscita SKH01 da ~1h a **~11h**; book flat, nessuna posizione esposta. L'allerta ha
segnalato 6/6 — poi ha stampato un perche' che **non aveva misurato**: la nota *"fetch pubblico
KO"* era cablata, identica in ogni caso, **compreso quello in cui la coda fresca E' attaccata e il
vecchio e' il certificato stesso** (= feed-freeze 14/07 in altra veste). E la causa vera non era
recuperabile a posteriori **per costruzione**: `_fetch_recent_5m` ingoia l'eccezione di pagina con
un `break` e a prima pagina fallita ritorna un frame vuoto, indistinguibile da "il venue non ha
barre"; alle 12:14, a mano, `fresh_5m` rispondeva in 1.7s senza errori.
**Cablato:** `livefeed.last_fetch_error()` (+`_note_error`, registra E logga nel punto in cui
l'errore viene ingoiato) → `book_report.skh_feed_errors` (per asset) → allerta con la causa; e
stesso buco chiuso sul ramo gemello **"conto offline"**, che aveva gia' la ragione in `mark_src`
e non la stampava mai. Tre guasti ora distinti: eccezione / risposta vuota / **certificato
vecchio con coda attaccata**. Blindati anche il caso a **meta' paginazione** (coda parziale
attaccata: la paginazione va in avanti → mancano le barre PIU' RECENTI) e la non-sopravvivenza
della causa a una chiamata riuscita.
⚠️ **La causa del 29/07 resta IGNOTA, e va citata cosi'.** Solo circostanziale: giri falliti
lunghi quanto i riusciti (**16-46s → errore immediato, non timeout**); finestra aperta col riavvio
ma non chiusa da esso (11:00 ok, 12:00 no); stesso giorno il percorso del **conto** (rete diversa
via `cerbero-mcp`, stesso venue a valle) dava `ReadTimeout/404/502`; i due percorsi falliscono **in
alternanza**, non insieme. Una prima stesura scriveva nei commenti "*rate limit Deribit per-IP
saturato da un altro progetto sulla stessa VPS*" **come fatto**: rimossa — sarebbe stato lo stesso
difetto che stavo correggendo, scritto meglio. **Cron spostato `0 * * * *` → `7 * * * *`**
(ipotesi contesa al minuto tondo): ripiego da **UNA** osservazione, costo zero, **dichiarato tale
in testa a `cron_book.sh`** perche' la riga di crontab vive fuori dal repo.
✅ **SEGUITO 2026-07-30 — il MECCANISMO ipotizzato e poi rimosso e' ora MISURATO; il "perche'
adesso" NO.** Analizzando `/opt/docker/cerbero-bite` (stessa VPS, stesso IP pubblico): il suo
collettore full-chain gira **al minuto :00** e produce **12.186 risposte 429** in 26 ore, di cui
**11.700 (96%) nel minuto :00** — ~770 chiamate ticker + ~770 orderbook in ~26s da un IP solo,
senza backoff → **si auto-satura** il rate limit Deribit per-IP (ticker: 5.738 respinte su
20.029). Co-timing **esatto** con l'incidente: le sue quote passano da ~0.4% a ~50% vuote alle
**05:00 del 29/07** e non sono ancora rientrate. ⚠️ **Ma la stessa disciplina vale due volte: il
carico di bite e' INVARIATO da settimane** (6.100-6.400 righe BTC/giorno prima e dopo, immagine
ferma al 09/06) e i log MCP non precedono il riavvio → le 429 spiegano **come** si perdono le
chiamate, **non perche' proprio quel giorno**. La causa del cambiamento resta ignota. Nessuna
azione: `cron_book` e' gia' a `:07`, fuori dalla finestra di ~26s. Diario `2026-07-30-vrp-quote-reali.md`.
**REGOLE:** (a) **una nota di diagnosi cablata e' peggio di nessuna nota** — nessuna manda a
guardare i dati, una sbagliata manda sulla pista sbagliata e sembra una misura; (b) se un errore
si ingoia per non bloccare, **si registra nel punto in cui lo si ingoia** (non c'e' un secondo
momento buono: quando la diagnosi serve, il guasto e' rientrato); (c) un'allerta risponde a **due**
domande — *cosa* (decide) e *perche'* (ripara): misurare solo la prima costa un'intera occorrenza
del guasto; (d) distinguere guasti diversi **anche quando l'azione e' la stessa** (tre cause → tre
riparazioni); (e) una mitigazione da un'osservazione sola si applica pure, ma **si scrive che lo e'**.
✅ **FOLLOW-UP CHIUSO 2026-07-26 — la misura dedicata sugli INGRESSI e' fatta: NON e' un difetto,
il verso e' LASCIARLO.** `scripts/research/r0726_skh_partial_entry.py`, test
`tests/test_skh_partial_entry.py` (10), diario `2026-07-26-skh-partial-entry.md`.
Confronto di due path identici in tutto (livelli, uscite intra-barra, cap, fee) tranne **quando si
valuta l'ingresso**: LIVE = a ogni confine orario dentro il bin 230m (cio' che il cron fa oggi),
BACKTEST = solo a chiusura di bin. **ΔSharpe su 3 offset x 2 asset: 0.01/+0.04/+0.44/+0.32/+0.59/
+0.98 → 6/6 non negativi, mediana +0.38.** All'offset 0 (l'ancora fortunata del backtest, 93-98°
pctl) l'effetto e' ~0 sul FULL ma l'hold-out BTC fa **1.12 live vs 0.71 backtest**. I falsi ingressi
(segnale che evapora) sono **~5/anno/asset**, e cannibalizzano il cap `max_per_day` solo 2-3 volte
in 7 anni (0.6-0.9% degli ingressi veri). **Meccanismo:** SKH01 e' un Donchian breakout — aspettare
fino a 230 min la chiusura del bin fa *pagare il movimento gia' avvenuto* (ingresso **0.25-0.26%
peggiore** in media); e siccome i livelli sono percentuali sull'ingresso (long sl4%/tp10%, short
sl2%/tp8%), lo stesso 0.26% vale il **6-13% della distanza dallo SL** contro il 2.6-3.3% di quella
dal TP → vantaggio **asimmetrico a favore della sopravvivenza del trade** (win rate +8pp ETH/+2pp BTC).
**Due attacchi superati:** (a) il divario NON e' concentrato — togliendo i 5 giorni migliori si
ALLARGA (ETH@460 35.6x vs 3.0x); e' il *backtest* il path concentrato (~39% del log-equity in 5
giorni contro 17-22% del live); (b) **nessun look-ahead intra-bin** — troncando i 5m alle sole barre
gia' chiuse la risposta e' identica in **289/289** osservazioni intra-bin e il prezzo d'ingresso e'
sempre l'ultimo close 5m disponibile (test permanente `test_nessun_lookahead_intra_bin`; serviva
perche' il self-check valida solo a **chiusura** di bin → un leak solo-intra-bin gli sarebbe
invisibile per costruzione).
⚠️ **La lettura che conta e' la seconda: live e backtest girano due strategie DIVERSE e la
differenza non e' neutra.** Ogni numero di SKH01 nel progetto (Sharpe standalone, peso 25%, audit
d'ancora 02/07, conferma peso/cadenza 24/07) e' calcolato sul path a chiusura di bin, che non e'
quello che gira. Sommato alla misura del 26/07 sulle uscite (+0.081 Sharpe FULL di book
sottostimato), **il path live di SKH01 e' stato modellato in modo sistematicamente pessimistico su
ENTRAMBI i lati.** Cio' che NON si conclude: che l'ingresso intra-bin sia un miglioramento
*validato* — e' stato misurato sugli stessi 7 anni su cui SKH01 e' stato selezionato, non e' passato
per `study_family_honest` ne' per un deflated-Sharpe, e la taglia varia molto fra ancore. Ma non
serve promuoverlo: **e' gia' cio' che il live fa**; l'azione e' smettere di trattare il numero del
backtest come l'aspettativa del live, NON "riparare" il live verso un backtest peggiore.
**Book, pesi, cron, config INVARIATI.**
⚠️ **Regole nuove (due errori catturati in sessione, entrambi del tipo che passa i test pigri):**
(i) **un self-check su eventi rari si campiona sugli EVENTI, non sulla popolazione** — la prima
stesura stampava "BTC 80/80 OK" mentre la ricostruzione era rotta da un off-by-one di confine
(`obs//MS_LTF` a chiusura cade nel bin successivo, vuoto → segnale 0): con gli ingressi al ~2% dei
bin confrontava **zeri con zeri**, potenza zero, e le 2 sole divergenze ETH erano gli unici 2 bin
con segnale vero. (ii) **un conteggio di eventi su segnale GREZZO non e' un conteggio di trade**
la prima scansione dava 1361 falsi ingressi e un costo inventato di 3%/anno di sleeve perche'
ignorava cap+non-overlap del live (**sovrastima ~20x**); la spia era 305 *giorni* con un falso
ingresso a fronte di 663 "eventi", impossibile con cap 1/giorno.
(2) ✅ **T2 — DVOLSPREAD ESCE DAL LIMBO** (era fermo dal 21/06, unico sopravvissuto del marginal
scorer indurito, mai ripreso: non nel book, non in monitor, non rifiutato). Passato ai due gate
che nel giugno NON esistevano. ⚠️ La griglia dichiarata dall'agente ("72 celle") ne contiene
**729** (6 assi x 3) → valutate tutte, scelta conservativa (piu' trial = DSR piu' basso).
Plateau REALE e larghissimo: **729/729 celle con hold-out positivo**, FULL [0.60,0.71].
Selection-on-holdout **confermata ma mite**: la cella pubblicata e' **83ª/729 sull'hold-out ma
471ª/729 in-sample**. Scegliendo onestamente in-sample: **FULL 0.68 / HOLD 0.69** (non il **0.93**
pubblicato — **citare 0.69**) e **DSR 0.953 PASS**, mentre la cella pubblicata **FALLISCE (0.947)**.
Marginale ADDS + robust_oos + multicut + non-hedge + insample_edge + beats_noise; corr +0.11,
alpha +7.4%/a, dSharpe book **+0.08 FULL / +0.17 HOLD** a w=15%. **PROMOSSO a forward-monitor con
i parametri ONESTI** (zwin=180 k=2.0 lw=0.6 zw=1.1 tgt=0.17 svw=60), **NON nel book**: campione
**ATTIVO 1949/2691 g** (prima del 2021-03 non c'e' DVOL, book flat) con **hold-out attivo 1.6
anni**, margine DSR sul filo, e `weights_tilt_null` mai affrontato.
**MONITOR CABLATO** (stessa sessione): `scripts/live/paper_dvolspread.py` in `cron_daily.sh`
dopo `fetch_dvol.py`, stato `data/paper_dvolspread/` (gitignored), test
`tests/test_paper_dvolspread.py` (10 casi). Inception **2026-07-25**, apertura +0.184 =
**$111/gamba** (cap $300), 2 libri MODELED $2000 / REAL $600.
⚠️ **Strumentazione specifica:** il book va **flat quando manca il DVOL** → un feed rotto
produrrebbe zeri che, contati come evidenza, direbbero "nessuna perdita" invece di "nessuna
misura". Contabilita' a **3 stati** (ATTIVE / flat-da-segnale / **flat-senza-dato**) e finestra
misurata in **barre attive**, non giorni di calendario; guardia sulla config che **esce 1** se
`FROZEN` diverge dallo stato salvato. **GATE PRE-REGISTRATO:** kill **2026-10-24** se Sharpe
forward < 0.50; decisione **2027-01-24** solo se TUTTE — (a) Sharpe>0 [debole di proposito:
con ~180 barre SE(Sharpe)≈1.4, una soglia alta sarebbe finta precisione] (b) marginale ancora
ADDS+robust_oos+insample_edge (c) **deflated-Sharpe ricalcolato ≥0.95** [e' qui il peso: se lo
0.953 gia' sul filo NON migliora con piu' dati, l'edge non c'e'] (d) `weights_tilt_null`;
**veto d'integrita'** se barre attive <80% → si ESTENDE, non si decide su dati mancanti.
(3) ❌ **T3 — XSR01 NON GENERALIZZA fuori dal crypto** (meccanismo CONGELATO W=45/sgn=+1 su
**9 settoriali SPDR 1998+ / 28 ETF 30 anni**, residuo vs SPY, demean giornaliero, split IWM/EFA
riparati, **annualizzazione √252**). Diverso dal test del 25/07: quello era a **coppie**, questo
e' la versione **DEMEANATA** (quella vera di XSR01). Lordo **+0.24 (SECT9, p=0.193)** e **0.14
(ALL28, p=0.747)** vs null di permutazione **a fee zero**; netto 1.6/1.8 ovunque; per decennio
stesso profilo nei 2 universi (neg. 1998-2005, debolmente pos. poi) = piu' cambio di regime che
edge. **Il risultato che conta non e' lo Sharpe ma l'AMPIEZZA:** il demeaning porta l'ampiezza
effettiva **4.5→37.4 (8x) sul crypto** ma solo **5.3→6.2 / 8.4→11.3 (1.2-1.35x) sulle azioni**.
Spiegazione strutturale (e migliore descrizione di XSR01 di quella della sua scoperta): il residuo
OLS rimuove gia' il beta al fattore comune; sul crypto alle gambe **RESTA** un enorme fattore
comune (ampiezza 4.5 su 50 gambe) ed e' quello che il demean toglie — sulle azioni il residuo-vs-SPY
e' **gia'** quasi indipendente, quindi non c'e' niente da togliere. **Per il gate del 23/10:**
conferma e CHIUDE la scappatoia lasciata aperta dal test a coppie; XSR01 e' **crypto-specifico**.
NON prova che sia falso. **Soglie del gate NON toccate**: resta appoggiato interamente su finestra
forward + haircut di eseguibilita' a $5.000, come pre-registrato.
**LEZIONI:** (a) **se si de-lucka una strategia va de-luckato anche il suo DEGRADO** — ogni Δ fra
due varianti misurato su griglia ancorata eredita la fortuna dell'ancora; (b) su offset appaiati
la statistica e' la **mediana delle differenze**, non la differenza delle mediane; (c) **un lead
"in forward-monitor" senza monitor e senza scadenza e' un lead perso** (DVOLSPREAD: 35 giorni di
limbo) → applicare ai lead la stessa disciplina dei candidati (config congelata + gate
pre-registrato + cron); (d) il claim di multiple-testing di un agente va **ricontato**, non
creduto (72 dichiarate, 729 reali); (e) quando un meccanismo non generalizza, **chiedersi PERCHE'
vale piu' del fatto che non generalizzi**.
-**VENUE WATCH — tripwire di fallimento exchange, CABLATO LIVE (2026-07-26).** Risposta alla
domanda *"trova un sistema di protezione da fallimento exchange"* **sotto il vincolo** della
decisione appena presa (100% Deribit fino a $20k): se non si puo' ridurre l'ESPOSIZIONE, l'unica
leva e' il **TEMPO**. Script `r0726_venue_tripwire.py` (segnale) + `r0726_venue_response.py`
(costo della risposta); produzione `src/live/venue_watch.py` + `scripts/live/venue_watch.py` in
`cron_book.sh`; test `tests/test_venue_watch.py` (**37**); diari `2026-07-26-venue-tripwire.md`,
`2026-08-19-venue-watch-disciplina-allarmi.md`, `2026-08-21-venue-taratura-tre-referenze.md`.
**Book, pesi, config INVARIATI.**
(1) **Il segnale:** un venue che gata i prelievi **rompe l'arbitraggio** → il suo prezzo si stacca
dal consenso e ci RESTA. Il segnale e' **|scarto|, non il segno** (Mt.Gox andava a *premio*, un
venue in fuga a *sconto*: dicono la stessa cosa). Consenso = **mediana** di venue **USD
indipendenti** (Coinbase, Bitstamp, **e Kraken dal 19/08** — vedi sotto); mai USDT (depeg 2022 →
falsi allarmi giganti). Deribit sta a **3 bps** dal consenso in mediana su 8 anni — fondo di
rumore bassissimo, ed e' cio' che rende possibile una soglia con margine. ⚠️ Le "65.043 ore BTC"
citate qui fino al 21/08 erano le ore del consenso **con bitfinex dentro**, che la produzione non
ha mai avuto: sull'insieme reale sono **69.633** (ETH 64.541 invariato).
(2) **Taratura CONGELATA = 100 bps persistenti 4h a segno costante.** Criterio **dichiarato
prima**, perche' i due ovvi sbagliano in versi opposti (provati entrambi): *minimi bps* → 25bps/24h
consuma 24 delle ~72h che diede FTX; *minime ore* → 500bps/2h **manca FTX** (margine 0.6x).
Regola adottata: (a) zero falsi allarmi su entrambi gli asset in 8 anni; (b) margine ≥3x sul caso
storico **piu' debole** (FTX ~300bps) → soglia ≤100bps; (c) a quei vincoli, minima latenza.
Margine finale **3x FTX / 5x QuadrigaCX / 10-20x Mt.Gox**.
⚠️ **CORREZIONE 2026-08-21 — la gamba (a) NON e' soddisfatta dalla configurazione che gira, e la
frase "zero falsi allarmi inclusi crash COVID 2020-03" era FALSA: il falso allarme E' il COVID.**
Vedi il blocco **(8)** in fondo. Il punto (100 bps, 4h) **resta**, per economia e per la gamba (b).
(3) ✅ **CONTROLLO POSITIVO superato** (obbligatorio: un rilevatore tarato per non segnalare e'
indistinguibile da uno rotto). Puntato su **Bitfinex 2018-19** (problemi bancari/Tether):
**22 episodi**, il piu' lungo **2.324 ore consecutive** a +447bps di picco, altri a 1.151h/+663bps
e 496h/+1136bps. **22 scatti dove il problema c'era, 1 solo su Deribit in 8 anni**
(era dichiarato 0 — vedi **(8)**). E la DURATA
risponde alla domanda vera: un venue gated resta dislocato per **settimane** → 4h di latenza
costano una frazione trascurabile del preavviso.
(4) **Economia della risposta:** costo ATTESO di un falso allarme (flat 3 giorni, misurato sul
book reale a ogni data d'inizio) = **0.248%** di equity (coda p5 2.065%); guadagno di un vero
positivo = **100%**. Break-even: `p_annua > (falsi allarmi/anno) × 0.00248` → a 1 ogni 8 anni
serve **p > 0.031%**, a 12/anno servirebbe p > 2.97%. **Il valore sta nella SPECIFICITA', non
nella sensibilita'.** ⚠️ Errore mio corretto: il break-even si calcola sulla **media**, non sul
p5 (con la coda esce 8.3x piu' severo e la conclusione si ribalta).
(5) **Tre stati, e il terzo NON e' il primo:** `OK` / `ALERT` / **`BLIND`** (referenze
irraggiungibili o in disaccordo fra loro → dopo 12h e' un allarme suo). *"Non vedo" non e' "va
tutto bene"* — stessa lezione della contabilita' a 3 stati di `paper_dvolspread`. **ALLERTA, NON
BLOCCA:** l'azione a un vero positivo e' *prelevare* (manuale — una chiave API con permesso di
prelievo sarebbe essa stessa un rischio), e bloccare non protegge il saldo, che e' a rischio
anche stando flat. **Runbook pre-deciso** nel docstring del modulo (escludere guasto referenze →
`public/status`**prelievo di prova**, unica evidenza diretta → flat + prelievo totale).
(6) ⚠️ **Cio' che NON copre, e non e' un argomento per riaprire il 26/07:** un fallimento **senza
finestra** (furto di chiavi, sequestro, exit-scam notturno) non lo prende nessun tripwire; quella
parte di `p` resta scoperta e la sola difesa e' lo split. E il preavviso di 200-2.300 ore viene da
**un** caso osservato: e' un'ancora, non una distribuzione.
**REGOLE:** (a) un rilevatore tarato per non segnalare va validato su un **controllo positivo**;
(b) una soglia si sceglie con un criterio **dichiarato prima** (i criteri ovvi sbagliano in versi
opposti); (c) la persistenza richiesta **e' latenza** e va confrontata con la durata del fenomeno
da rilevare; (d) un break-even si calcola sulla **media**, non sulla coda; (e) ⚠️ **una
diagnostica STAMPATA non e' un controllo** — la prima corsa tronco' il campione da 8 anni a
**29 giorni** per un inner-join con Kraken (che serve solo ~700 candele) e la copertura era gia'
a video: ora c'e' una guardia che ferma lo script (2ª occorrenza in un giorno dopo GTAA01 —
**l'outer-join con referenze di lunghezza diversa e' una trappola ricorrente**); (f) un controllo
positivo finito dentro il ramo `else` **non gira mai** (trovato in sessione: era esattamente il
difetto che doveva prevenire).
**(7) DISCIPLINA DEGLI ALLARMI + TERZA REFERENZA + SPECIFICHE CONTRATTO (2026-08-19)** —
*(bullet scritto il 21/08: la sessione era in un diario e in un commit e NON in memoria operativa,
2ª occorrenza dopo `edge_watch`)*. Nato da 4 🚨 identici il 18/08 per una **manutenzione Deribit
annunciata** (14/08 per il 18/08 09:00 UTC, downtime dichiarato 15-30 min) che ha **sforato fino
alle 14:07 UTC**. **Il book si era comportato bene** (astensione alle 09:07 e 10:07, *"conto non
leggibile → non eseguo a cieco"*): il difetto era negli allarmi. (a) Il blocco piattaforma era un
`if` secco **senza memoria**, accanto a un rilevatore che allerta una volta per streak → ora passa
da **`lock_step()`** pura: manutenzione entro `MAINT_GRACE_HOURS`=2 → ⚠️ **una volta**; che sfora
→ 🚨 una volta («ha SFORATO»); blocco **senza** manutenzione dichiarata → 🚨 subito; rientro
annunciato una volta; **`public/status` illeggibile → NIENTE** (dichiarare «e' rientrato» perche'
non si e' riusciti a guardare sarebbe la bugia peggiore). *Un allarme massimo speso per un evento
atteso e' un allarme che non verra' letto il giorno che e' vero.* (b) Il messaggio stampava
`locked=true` **cablato** mentre il parser accetta anche `partial` → dichiarava un valore che non
aveva letto, e il runbook manda a controllare **proprio quel campo**; ora stampa e **salva** il
grezzo. (c) ⚠️ **Il difetto che poteva costare:** il 18/08 Deribit ha cambiato **tick e size dei
perpetual lineari USDC** (BTC tick 0.5→**0.1**, ETH 0.05→**0.01**, ETH min/step 0.001→**0.0001**)
e la tabella `_CONTRACT` di `deribit.py`, **cablata a mano**, non se n'e' accorta. Nessun ordine
rifiutato **e non per merito nostro**: erano *riduzioni*, e un valore piu' grosso resta conforme
(costo effettivo: granularita', incremento minimo ETH $1.92 invece di $0.19). **Il giorno che
Deribit ALZA un minimo la stessa cecita' fa rifiutare gli ordini.** Cablato **`check_specs()`**
nel venue_watch orario, **fuori dal percorso ordini**: la tabella dichiarata resta l'AUTORITA'
per costruire un ordine, il venue e' il **controllore** (prendere i valori dall'API dentro
l'esecuzione renderebbe l'ordine dipendente da come ha risposto una GET = non ricostruibile).
Verdetti: `granularita'` (dichiarato piu' grosso → conforme, ⚠️) vs `rifiuto` (dichiarato piu'
fine → 🚨). Uno strumento **non letto** finisce in `non_letti`, non conta come «combacia».
(d) Aggiunta **Kraken** come terza referenza: **Coinbase ha comprato Deribit** e una referenza
che e' la casa madre non misura piu' se Deribit scolla dal mondo.
⚠️ **(8) LA TARATURA RI-MISURATA (2026-08-21) — «zero falsi allarmi in 8 anni» non ha mai
descritto la produzione, e il falso allarme e' il COVID.** Script `r0821_venue_refs.py`, diario
`2026-08-21-venue-taratura-tre-referenze.md`. **Soglie, book, config INVARIATI.**
**(i)** Il numero pubblicato veniva dal consenso **Coinbase+Bitstamp+Bitfinex** dello script di
ricerca; il sorvegliante live girava su **Coinbase+Bitstamp**. Due liste di referenze in due
posti diversi, e **nessun test poteva accorgersene**. Sull'insieme reale: **1 falso allarme in
8 anni**, il **2020-03-13 07:00-10:00 UTC**, 4 ore a **418 bps** di picco su BTC — cioe' proprio
l'evento che questo bullet elencava come esempio di cio' su cui NON scattava. La soglia minima a
zero falsi allarmi a 4h e' **150 bps** (BTC), non 100.
**(ii) Kraken non lo ripara:** su 8 anni porta **un mese** (tetto ~700 candele dell'endpoint
pubblico, **ri-verificato oggi**: 704 barre su 70.286 richieste = 1,00%) → LIVE-post ≡ LIVE-pre
sulla storia lunga, numeri **identici**.
**(iii) Perche' spariva a 3 referenze, ed e' il punto trasferibile:** con bitfinex dentro **1
delle 4 ore diventa BLIND** → lo streak si azzera e l'episodio non esiste, **ma la dislocazione
e' ancora li'** (mediana 343 bps). **Lo zero non veniva da un consenso piu' accurato, veniva da
un'ora buttata** (ore utilizzabili 93,4% contro 100,0%).
**(iv) La direzione dichiarata il 19/08 e' confermata, la sua TAGLIA dipende dal venue** (confronto
appaiato, stesse ore): con **bitfinex** le ore non-BLIND passano 99,95% → 86,04% = **13,91 pp**;
con **kraken** **+0,00 pp** (|scarto| mediano appaiato 0,04 bps). Non e' una proprieta' del
numero tre: e' **quanto la terza referenza e' d'accordo con le altre**.
**(v) Controllo positivo intatto:** Bitfinex 2018-19 → 22 episodi, il piu' lungo 2.324h, picco
**1.136 bps = 11,4x** la soglia.
**(vi) DECISIONE: (100 bps, 4h) NON si tocca, ma la giustificazione cambia.** 1 falso allarme in
8 anni = 0,125/anno × 0,248% = **0,031%/anno** di equity attesa contro il **100%** che un vero
positivo evita, e ogni `p` plausibile (0,5-5%) e' **16-160x sopra** il break-even; alzare a 150 bps
porterebbe il margine su FTX da **3,0x a 2,0x**, sotto la gamba (b) dichiarata prima di guardare i
dati. **Il numero da citare e' «1 in 8 anni»** — che e' esattamente l'esempio gia' usato al punto
(4): **la memoria si contraddiceva da sola e la meta' giusta era quella dell'economia.**
**REGOLE NUOVE:** (g) **un numero di taratura si etichetta con la CONFIGURAZIONE, non solo con la
finestra** — «zero falsi allarmi in 8 anni» era vero e inutile perche' descriveva un consenso che
la produzione non ha mai avuto; (h) **uno "zero" si legge accanto alla quota di campione
utilizzabile**: meno falsi allarmi perche' si vede meglio e meno perche' si vede di meno hanno lo
stesso valore stampato e valore opposto; (i) **quando due affermazioni della stessa memoria si
contraddicono, la contraddizione e' informazione** — una delle due e' stata scritta guardando i
dati; (j) **una nota che dichiara un debito puo' sottodimensionarlo**: il 19/08 diceva «il numero
non e' ri-misurato», e il numero era sbagliato **prima** della modifica che lo aveva fatto
dichiarare. **RESTA APERTO:** il Rulebook Deribit del 12/08 (ADL, perdita socializzata, *emergency
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.
-**GTAA01 NON E' DEPLOYABILE — blocco PRIIPs CONFERMATO sul conto reale (2026-07-26).**
Nato da una domanda dell'operatore ("GTAA01 puo' essere in revolut?"), verificato lo stesso
giorno tentando l'ordine. Il broker rifiuta: *"Trading limitato — Questo prodotto non dispone di
un KID in inglese o in una lingua approvata per il vostro Paese. I clienti retail possono
negoziare prodotti retail preconfezionati solo se e' disponibile un KID appropriato."*
SPY/QQQ/IWM/TLT/GLD/HYG sono ETF **domiciliati USA**: gli emittenti non pubblicano il KID e i
broker UE ne vietano l'**acquisto** al retail. ⚠️ **Le quotazioni restano visibili** — vedere i
prezzi non e' poter comprare, ed e' esattamente cio' che rendeva l'assunzione invisibile.
**COSA CADE:** lo sleeve **cosi' com'e' non e' deployabile**, e con esso il piano di attivarlo a
~$13k. Restano **valide come ricerca e nulle come deploy**: la validazione a 30 anni (22/06), il
fix dei costi IB (25/07), `GTAA_MIN_CAPITAL`, e il risultato del LOO (26/07) che lo indicava come
**l'unico sleeve positivo nel 100% delle estrazioni su tutte e tre le metriche**.
**COSA NON CADE:** tutte le traiettorie, i muri e le tabelle di rendita pubblicate usano
`book_series(with_gtaa=0)` = **solo TP01+SKH01 su Deribit** → nessun numero del piano va rifatto.
E il book live non lo include.
**REGOLA: la negoziabilita' sul conto REALE va verificata quando lo sleeve entra in RICERCA, non
quando entra nel book.** Qui 5 settimane di misure poggiavano su un'assunzione mai controllata, e
il controllo e' costato **un ordine di prova**. E' l'analogo azionario di cio' che il progetto fa
gia' rigorosamente sul crypto (min-order, haircut small-cap, eseguibilita' a $600): la stessa
disciplina non era stata applicata all'equity.
- ✅ **LA VIA D'USCITA UCITS E' APERTA E COSTA ~ZERO — misurata 2026-07-26 (domanda dell'operatore:
"usiamo revolut o degiro"). E la premessa su cui era stata scartata era MIA e FALSA.**
Script `fetch_ib_ucits.py` + `r0726_gtaa_ucits.py`; modulo nuovo `src/data/eq_crosscheck.py`;
test `tests/test_eq_crosscheck.py` (14) + `tests/test_gtaa_ucits.py` (10); diario
`2026-07-26-gtaa-ucits.md`. **Book/pesi/cron/config INVARIATI.**
(0) ⚠️ **CORREZIONE:** la nota diceva "storia UCITS piu' corta → si perde la validazione a 30
anni". FALSO per un motivo strutturale: **il PRIIPs vieta di COMPRARE, non di GUARDARE**. I
prezzi dei 6 ETF USA restano leggibili (l'operatore li aveva sul terminale *mentre* l'ordine
veniva rifiutato) → il **segnale** gira sui 30 anni per sempre, cambia solo il **veicolo** su cui
si incassa. La storia corta serve solo a misurare la deviazione del veicolo, un drift lento.
**Regola: prima di dichiarare che un vincolo esterno distrugge un risultato, chiedersi cosa
vincola esattamente** — "non posso comprare" ≠ "non posso vedere".
(1) **Il cambio di veicolo NON costa.** Tre lenti a un grado di liberta' per volta su 6.3 anni
comuni: L0 (segnale USA + rend. USA, pubblicato) **Sh 0.81 / CAGR 3.96%**; L2 (segnale UCITS +
rend. UCITS, deploy) **Sh 0.84 / CAGR 4.08%**. Drag del veicolo **+0.10%/anno** EW, coerente coi
TER (controllo piu' netto: GLD 0.40% vs IGLN 0.12% → atteso +0.28%, misurato +0.36%); e la
**ritenuta USA 15% sui dividendi (~35bps) e' A FAVORE dell'UCITS** e non e' nel drag misurato
(`ADJUSTED_LAST` USA e' al lordo). *(Ipotesi fiscale dichiarata, fonte secondaria.)*
⚠️ **Lo stimatore ovvio da' la risposta sbagliata:** la media delle differenze giornaliere dava
**0.47%/anno** su CSPX contro **0.06%** vero. Le due serie seguono lo stesso indice ma sono
campionate a orari diversi (Londra chiude 4h30 prima) → la differenza giornaliera e' dominata da
uno sfasamento che si inverte il giorno dopo: **SE ~7%/anno, 15× la quantita' stimata**, piu' il
drag di varianza. **REGOLA: la deviazione fra due veicoli sullo stesso indice si misura sul
RAPPORTO CUMULATO** (e' una domanda sul drift), mai sulla media delle differenze.
(2) ✅ **IL VINCOLO NON E' IL BROKER, E' IL PREZZO DI UNA AZIONE — e quello e' una SCELTA.**
CSPX costa $802 e VUAA $144 sullo **stesso** S&P 500. Due insiemi: **STORIA** (CSPX/EQQQ/XRSU/
IDTL/IGLN/IHYU, finestra lunga, per misurare) e **DEPLOY** (VUAA/XNAS/R2US/IDTL/IGLN/IHYU, prezzo
unitario basso, per eseguire). A **$3.000** con esecuzione a azioni INTERE: STORIA tiene **4/6
gambe** ed e' a mercato il **33%** del tempo; DEPLOY tiene **6/6** al **65%**, ΔSharpe 0.04.
**Il frazionamento del broker NON serve.** Scartati benche' con piu' storia: RTWO (Russell 2000
*quality*), CSUSS (*ESG*), IDP6 (S&P 600) — equivalenza dell'INDICE prima della storia.
⚠️ Letto sulla colonna **gambe vive + vol**, non su Sharpe: il vincolo intero *alza* lo Sharpe a
capitale piccolo perche' arrotonda in giu' e paga meno commissioni = **null de-levering, 4ª
occorrenza** (VRP-DD, TP01×DVOL, MAT01).
(3) **Il costo per ordine.** Col canonico lo sleeve fa **77 ordini/anno a $3k, 102 a $10k, 149 a
$50k**; soglia oltre cui non vale la pena (Sharpe<0.45) = **$0.90/ordine a $3k, $2.23 a $10k,
$7.62 a $50k**. Listino **proporzionale** ≈ indifferente al capitale, listino **fisso** = tassa
regressiva (regola 25/07 riconfermata su altro venue). ⚠️ **Revolut/Degiro NON sbloccano gli ETF
USA**: il PRIIPs vale per ogni intermediario UE, IB e' anzi fra i piu' permissivi.
- ✅ **ADDENDUM 2026-07-27 — il numero di ordini e' un PARAMETRO, e con la banda giusta il costo
smette di essere binding su qualunque broker UE.** Nato dalla correzione dell'operatore *"io ho
gia' Revolut e Degiro e li uso da anni, IB sono solo iscritto"*: la raccomandazione del 26/07
("restare su IB") poggiava su **"il conto esiste gia'"**, che era falso. Il gateway IB serve solo
per i **dati** del segnale (basta il paper), quindi il broker di esecuzione e' libero.
Script `r0727_gtaa_broker.py`, test `tests/test_gtaa_broker.py` (9). **Book/pesi/cron/config
INVARIATI.**
(a) I 77-149 ordini/anno sono la conseguenza di `REBAL_EVERY=5`/`REBAL_BAND_USD=50`, scelti il
25/07 **per il listino IB su azioni USA e a una taglia sola**. A cadenza settimanale allargare la
banda **non costa**: Sharpe a **costo zero** 1.27 ($50) → **1.27** ($400) mentre gli ordini vanno
84 → 23. Rallentare la CADENZA invece costa (1.27 → 1.12 mensile). Meccanismo: `_exposure` e' la
media di 4 indicatori binari, si muove a scatti di 0.25 ≈ $417 su una gamba da $1.667 → **la
banda filtra la deriva del vol-target, non il segnale di trend**. ✅ Controllo fuori finestra: sui
**veicoli USA su 10 anni** lo Sharpe a costo zero passa 0.98 → **0.96** mentre gli ordini calano
del **74%** (133 → 35) — non e' un artefatto della finestra corta UCITS (3.2a).
(b) ⚠️ **MA la banda in dollari ASSOLUTI e' la parametrizzazione sbagliata.** A $3.000 una banda
da $400 e' l'**80% della gamba**: **3 ordini/anno**, a mercato il **45%** del tempo invece del
66%. Lo Sharpe resta 0.71 — accettabile — **su una strategia che ha smesso di seguire il proprio
target**. E' il **null de-levering in veste nuova**: non travestito da "meno drawdown" ma da
"meno costi". **REGOLA: quando un parametro di esecuzione e' espresso in valuta assoluta il suo
effetto dipende dal capitale, e il controllo non e' lo Sharpe ma la QUOTA DI TEMPO A MERCATO.**
(c) **Configurazione proposta: banda = 25% della gamba****21 ordini/anno a OGNI capitale**
(invariante), esposizione 66% ovunque; soglia per ordine **$5.65 a $3k / $18.90 a $10k / $47 a
$25k** contro i **$2.08 a $3k** del canonico. E' la differenza fra "serve un broker economico" e
"va bene qualunque broker europeo". ⚠️ **Proposta, non cambio di produzione**: tarata su questa
finestra, non passata per `study_family_honest` ne' per un deflated-Sharpe — e GTAA01 non e'
deployabile prima dei $20k, quindi c'e' tempo per validarla.
(d) **Cosa cercare sul proprio conto — per ISIN, non per ticker** (da contract details IB; tutti
domiciliati IE, quotati a **Londra in USD**): **VUAA** `IE00BFMXXD54` ($143.80) · **XNAS**
`IE00BMFKG444` ($65.74) · **R2US** `IE00BJ38QD84` ($86.35) · **IDTL** `IE00BSKRJZ44` ($3.09) ·
**IGLN** `IE00B4ND3602` ($79.06) · **IHYU** `IE00B4PY7Y77` ($94.12).
Nessuna azione oggi (decisione venue: 100% Deribit fino a $20k).
⚠️ **CORREZIONE 27/07 A QUESTO PUNTO.** Avevo scritto "una linea in EUR aggiunge la conversione
per ordine → prendere quella in USD". E' vero **solo per un conto in USD**. Per un conto in EURO
(retail italiano su Revolut/Degiro) vale l'**OPPOSTO**: la linea USD costringe a convertire a ogni
ordine, quella EUR no. L'esposizione economica e' identica (il fondo detiene attivi USD e
**nessuna delle due linee e' coperta**): la valuta di quotazione non copre nulla, decide solo se
serve una conversione. **REGOLA GIUSTA: prendere la linea nella valuta del proprio saldo.**
Misurato (turnover lordo **$13.655/anno** su $10k, 21 ordini): 15bps 0.04 Sh/$20 a., 25bps
**0.07 Sh/$34 a.**, 50bps 0.14/$68 → a 25bps equivale a **~$1.6 in piu' per ordine**, piccolo
rispetto alla soglia di $18.90. **REGOLA: un costo di conversione non e' una proprieta' dello
strumento ma della coppia strumento-CONTO.**
(f) **Equivalenze e ripieghi, verificati su contract details IB (27/07).**
**ZPRR (Xetra EUR) == R2US (Londra USD): stessa ISIN `IE00BJ38QD84`, stesso fondo, stesso NAV**
se un broker non quota la linea di Londra, quella di Xetra e' identica (e su conto in euro,
migliore). **REGOLA: si cerca per ISIN, non per ticker** — lo stesso fondo ha ticker diversi su
borse diverse. ⚠️ **SPY4 `IE00B4YBJ215` NON e' small cap ne' S&P 500**: e' SPDR **S&P 400 MID
cap** (l'S&P 500 e' SPY5 `IE00B6YX5C33`). Misurato come ripiego della gamba small: su 6.5 anni
Sharpe **0.86 vs 0.86**, CAGR 4.26% vs 4.20%, **corr fra i due sleeve 0.991**, peggiore in 3/7
anni = moneta (sulla finestra corta di 3.2a sembrava 0.15: rumore) → **ripiego accettabile**, per
ragione meccanica (small e mid USA correlano ~0.95 giornaliero, un TSMOM si accende negli stessi
giorni). Non e' "validato": 6.5 anni non distinguono due gambe cosi' simili, ed e' esattamente
perche' la scelta non conta. Se c'e' una linea Russell 2000, si usa quella.
(g) ✅ **DEGIRO HA TUTTE E SEI LE GAMBE — verificato sul conto reale (2026-07-27, screenshot
watchlist "Pythagoras").** Era **Revolut** a non avere R2US. Su Degiro: VUAA e XNAS su **Tradegate
in EUR**, R2US/IDTL/IGLN/IHYU su **LSE in USD**. ✅ Verifica indipendente che le linee EUR siano
gli stessi fondi (dai dati, non dallo screenshot): il rapporto prezzo-IB/prezzo-Degiro dev'essere
**un solo cambio** → VUAA 1.1341, XNAS 1.1315, **scarto 0.23%**; le altre 4 stanno a 0.993-0.998
(gia' USD). Due fondi diversi non darebbero lo stesso cambio.
⚠️ **ERRORE MIO, dello stesso tipo che avevo appena codificato:** per cercare le linee in euro
delle altre 4 gambe ho interrogato IB **per TICKER** sulle borse tedesche → "nessuna linea EUR"
su 4/4, **falso**. Cercando **per ISIN** ognuna ce l'ha: **ZPRR** (=R2US), **IS04** (=IDTL),
**EGLN** (=IGLN, Londra EUR), **IS0R** (=IHYU). **Un "assente" da una ricerca per ticker su una
borsa dove quel ticker non esiste NON significa "non esiste".**
**Turnover per gamba a $10k (21 ordini/anno):** **IDTL 9 ordini / $6.257 = 46%**, VUAA $2.289
(17%), IGLN $1.695 (12%), XNAS $1.614 (12%), IHYU $958 (7%), R2US $843 (6%) → **il turnover e'
concentrato**, il 71% e' su gambe in USD (**$9.752/anno**, conversione **$24/a a 25bps**, $49 a
50bps = 6-12% del CAGR). **Spostare la sola IDTL su IS04 copre il 64% del turnover convertibile.**
⚠️ Non e' un risparmio netto (spread Xetra piu' larghi delle linee primarie di Londra + tariffa di
connettivita' per borsa) e su $10k parliamo di decine di dollari l'anno in entrambe le direzioni:
**non e' una decisione importante, ed e' piu' utile dirlo che costruire una precisione finta.**
⚠️ Il prompt **W-8BEN** di Degiro ("aliquota ridotta della ritenuta USA") **non riguarda queste
sei**: sono fondi IRLANDESI, non titoli USA — la ritenuta 15% la subisce il fondo al proprio
interno e nessun modulo dell'investitore la cambia.
**Stato: PREPARAZIONE, non azione** (saldo Degiro €328,92; GTAA01 richiede ≥$3k e la decisione
venue tiene tutto su Deribit fino a $20k).
**LEZIONE: una raccomandazione poggiata su un fatto non verificato sul conto reale vale quanto
quel fatto** — due volte in due giorni un'assunzione sul conto ha cambiato la conclusione (prima
la negoziabilita' PRIIPs, poi quale conto e' davvero operativo).
(e) **"degiro ha api?" — NO, e costa 0.02 di Sharpe.** DEGIRO non espone una API di trading
ufficiale al retail; Revolut nemmeno (la sua e' per pagamenti); IB si'. I wrapper NON ufficiali
degli endpoint interni girano su credenziali + seed 2FA e **si rompono in silenzio** a ogni cambio
di front-end — e il progetto ha gia' pagato quel prezzo (`fresh_5m`, 26/07): **un esecutore
automatico che puo' rompersi senza dirlo e' peggio dell'esecuzione manuale.** Misurato invece il
costo di NON automatizzare: carico operativo **15 settimane/anno con ≥1 ordine** (29% dei
controlli, 1.4 ordini per volta); costo del ritardo su 10 anni **1g 0.02 (peggiora in 6/11 anni
= moneta), 3g 0.13, 10g 0.27**. ⚠️ Sulla finestra UCITS di 3.2 anni la curva NON e' monotona
(5g 0.26, 10g 0.13) → il campione corto non risolve differenze di questa taglia, si legge la
finestra lunga. **Il costo non e' il ritardo tipico ma la CODA: il rischio e' la dimenticanza, e
si copre con un ALLARME non con una API** (`gtaa_rebalance_plan` esiste gia' in produzione, nato
per un esecutore; l'allerta Telegram c'e' gia' sul book live). ⚠️ Lato opposto, vero: il resto del
book e' automatico, una gamba manuale aggiunge un modo di fallire che oggi non c'e' — argomento
reale a favore di IB, che pero' richiede un secondo venue e quindi cade sotto la decisione venue
($20k). **REGOLA: una capacita' mancante si valuta sul costo di non averla, non sulla sua
assenza.**
- 📅 **NUOVO SCHEMA FEE DERIBIT dal 2026-08-01 — misurata la CURVA, nessuna azione oggi
(2026-07-26).** Script `r0726_fee_sensitivity.py`, test `tests/test_fee_sensitivity.py` (6),
diario `2026-07-26-fee-deribit.md`. **Book/pesi/cron/config INVARIATI.**
L'annuncio (taker piu' bassi, **maker rebate piu' bassi**, soglie VIP abbassate, nuovo VIP7,
**liquidation fee 1%** su tutti i prodotti, spot a zero fino al collegamento con Coinbase) **non
contiene numeri** e ⚠️ **la tabella nell'articolo Insights e' un'IMMAGINE, non letta da fonte
primaria** → i valori indicativi (base ~5bps taker / 2bps maker, VIP7 2/0) vengono da un
riassunto **secondario** e vanno etichettati come tali. Percio' e' misurata la **curva**:
| bps/lato | %RT | TP01 Sh | SKH01 Sh | BOOK Sh | BOOK CAGR |
|---|---|---|---|---|---|
| 0 | 0.00% | 1.322 | 1.567 | 1.849 | 21.69% |
| 3 | 0.06% | 1.303 | 1.495 | 1.799 | 20.99% |
| **5** | **0.10%** | **1.290** | **1.446** | **1.766** | **20.53%** ← oggi |
| 10 | 0.20% | 1.258 | 1.324 | 1.682 | 19.39% |
| 15 | 0.30% | 1.226 | 1.200 | 1.597 | 18.26% |
**Sensibilita' marginale del book: 0.017 Sharpe/bps, 0.23% CAGR/bps** → anche un RADDOPPIO del
taker costa 0.08 di Sharpe, **meno della banda d'ancora dello stesso book** (2.222 → 1.946).
⚠️ **SKH01 e' ~4× piu' sensibile di TP01** (0.69% vs 0.09% CAGR/bps: round-trip discreti vs
posizione continua vol-targeted) → **se il taker salisse, il primo parametro da rivedere e' il
peso 75/25**, non altro. **REGOLA DECISA IN ANTICIPO (per non decidere col numero davanti):
taker ≤5bps/lato → non si tocca nulla; >10bps/lato → rivedere il peso di SKH01.**
**Punti irrilevanti e perche':** *maker* — il book manda ordini **market**; tocca solo la
raccomandazione **T1 non implementata** (TP resting per incassare il maker), che resta chiusa
per il netting su strumento unico e il cui beneficio era quasi tutto "convertire una lotteria in
certezza", non la fee. *Liquidation fee 1%*`live.json` da' nozionale lordo max **1.00x
l'equity** (`frac 0.5` × 2 asset) con disaster-SL 30%: servirebbe un movimento avverso ~100%;
⚠️ la conclusione poggia sul CAP, quindi e' cablata una **guardia di decisione**
(`test_leva_massima_da_config_resta_sotto_o_uguale_a_1x`): **alzare il cap rompe il test**.
*VIP/VIP7* — a $600 il volume 30g e' trascurabile, tier base a qualunque soglia.
**Cio' che il cambio non puo' rompere:** tutti i backtest sono a 0.10% RT → se la fee scende
diventano **conservativi**. **AZIONE 1 agosto:** leggere il tier reale in Account Settings e
applicare la regola sopra. **REGOLE:** (a) a un annuncio senza numeri si risponde misurando la
**curva**, non aspettando il numero; (b) dichiarare la **qualita' della fonte** (immagine non
letta = dato secondario); (c) una conclusione che poggia su un parametro di config va legata a
un **test su quel parametro**, o sopravvive al cambio che la rende falsa.
-**EDGE WATCH — criteri di kill del book LIVE, cablati (2026-07-26).** *(Bullet aggiunto il
27/07: era in cron dal 26/07 e NON stava in CLAUDE.md — il criterio di morte di cio' che gira
con soldi veri non era nella memoria operativa.)* `scripts/live/edge_watch.py` (in
`cron_daily.sh`), taratura `r0726_edge_death.py`, test `tests/test_edge_watch.py` (11).
Chiudeva l'asimmetria: gate di kill pre-registrati per i CANDIDATI, nessuno per il book.
**(A) RITORNO: Sharpe rolling 36m < 0.5** — falso kill 1.8% in 10 anni, riconosce l'edge morto
nel 91% dei casi in ~3.8 anni. ⚠️ **La lentezza non e' un difetto della regola, e' statistica:**
a 12 mesi la stessa regola ucciderebbe un edge VIVO nell'80% dei casi; a 12m il 56% dei casi
"morto" e' indistinguibile da uno vivo. **(B) PROTEZIONE: in un anno con DD buy&hold > 10%, il
DD di TP01 deve restare sotto il 75% di quello** — storico 8/8 anni di sinistro superati
(protezione 1.8x-34.4x). Serve un criterio SEPARATO perche' il LOO misura il contributo hold-out
di TP01 negativo nel 99.1% delle ancore: **"non ha guadagnato" non e' evidenza di morte per uno
sleeve difensivo** — la sua morte e' non proteggere nel sinistro, e negli anni senza sinistro il
criterio NON si valuta. Se (A) scatta il book **non si spegne da solo**: si riapre
`weights_tilt_null` + deflated-Sharpe sui dati nuovi. Se (B) fallisce **2 anni di sinistro
consecutivi**, il peso di TP01 va rimesso in discussione. Stato 27/07: **Sharpe 36m +1.51,
protezione 8/8.** Diario `2026-07-26-edge-death.md`.
-**FEE WATCH + MONITOR HEALTH — due sorveglianze cablate (2026-07-27).** Nessuna tocca
l'esecuzione; entrambe in `cron_daily.sh`. (1) **`scripts/live/fee_watch.py`** (test 13): il
nuovo schema fee Deribit entra il **1° agosto** e l'annuncio non ha numeri → invece di un
promemoria, un sorvegliante. Legge il tier **BASE** da `public/get_instrument` (nessuna chiave;
a $600 ogni soglia VIP e' fuori portata), oggi **taker 5.00 / maker 0.00 / liquidazione 75-90
bps**, applica la regola congelata (≤5bps nulla · >10bps rivedere il peso SKH01) e allerta su
**qualsiasi** cambiamento dei tre. `test_baseline_e_quella_dei_backtest` lega la soglia al
default `fee_rt=0.001` di `backtest_signals`: se divergono, il test lo dice.
⚠️ **CORREZIONE 2026-08-21 — sorvegliava lo STRUMENTO SBAGLIATO (test 13 → 17).** `INSTRUMENTS`
era la tupla cablata `("BTC-PERPETUAL","ETH-PERPETUAL")` = i perpetual **INVERSE** (regolati in
BTC/ETH), mentre il book esegue sui **LINEARI USDC** (`BTC_USDC-PERPETUAL`). Due conseguenze:
(a) il tier sorvegliato era di un prodotto **mai tradato** — oggi identico per caso (3.50/1.50 su
entrambe le linee) ma **la prova che si muovono in modo indipendente e' nel progetto**: il cambio
del 18/08 tocco' i SOLI lineari (inverse ancora tick 0.5/min 10.0, lineari 0.1/0.0001) → un
aumento sulla sola linea lineare sarebbe stato invisibile e la regola ≤5/>10 bps applicata al
numero sbagliato; (b) **il cross-check sui trade reali non poteva misurare nulla per
costruzione** — chiedeva `trade_history` di uno strumento con **0 fill** e stampava «NON
MISURATO» anche nei giorni con 4 esecuzioni (verificato: inverse 0 trade, `_USDC` 3+1). Ora
`INSTRUMENTS` si **DERIVA da `src.live.book.INSTRUMENT`**: la divergenza non e' un rischio da
ricordare, e' impossibile. ⚠️ **E non era un rename:** le due famiglie hanno unita' DIVERSE —
inverse `amount`=nozionale USD e `fee` in valuta base; lineare `amount`=quantita' BASE e `fee`
gia' in USDC. Ripuntare senza correggerle avrebbe dato, su un fill vero (0.001 BTC @ 74.305,80,
fee 0,02600703), **~2,6e8 bps invece di 3,50** — e **senza sollevare nulla**. Cablate
`convenzione()` (lineare/inverse/**ignota**: una famiglia non nota non si indovina) e
`fee_bps_di_un_fill()` pure; il cross-check ora gira e da' **3,50 bps effettivi = il tier
esatto**, e il report stampa lo scarto effettivotier con ⚠️ sopra 1 bps.
**REGOLA: un sorvegliante deve DERIVARE il proprio bersaglio dal codice sorvegliato, mai
ridichiararlo** — due liste in due file divergono in silenzio, e il giorno che divergono il
sorvegliante continua a dire OK. **3ª occorrenza in un giorno della stessa forma** (test di
`book_live` senza potenza a libro flat, taratura di `venue_watch` misurata con bitfinex mentre
il live girava senza): *un controllo puntato su una configurazione diversa da quella che gira
passa sempre, e non sta controllando niente.*
(2) **`src/live/monitor_health.py` + `scripts/live/monitor_health.py`** (test 16): **tre gate
pre-registrati** (STATARB 27/09, XSR01 23/10, DVOLSPREAD 24/10) si decidono su serie forward di
cui **una sola** aveva una guardia d'integrita'. Un monitor fermo produce silenzio, e **il
silenzio in una serie di ritorni si legge come zero** (stesso schema di `fresh_5m` e del
feed-freeze 14/07). Misura **due guasti**, perche' uno solo non basta: **coda** (ultima barra
vecchia) e **buchi interni** (copertura fra prima e ultima barra) — ⚠️ *una serie bucata E
fresca passa qualunque controllo di freschezza, ed e' il guasto che falsifica un gate senza
farsi notare*. Cadenze dichiarate per monitor (prevday e' **orario**, combo segue il calendario
di **borsa**: sbagliarle = un falso allarme a settimana); soglia di copertura **0.80** riusata
dal veto DVOLSPREAD perche' i gate restino confrontabili. Stati **OK/FERMO/BUCATO/ASSENTE/NUOVO**
— "troppo giovane per un giudizio" non e' "sano". Controlli positivi obbligatori nei test.
Stato 27/07: 6/6 giudicati, tutti OK (combo 96% per una festivita' che `np.busday_count` non
conosce = limite dichiarato, conservativo).
-**BANDA GTAA01 AL 25% — VALIDATA, produzione NON toccata (2026-07-27).**
`r0727_gtaa_band_gate.py`, test `tests/test_gtaa_band_gate.py` (13). Chiude il debito dichiarato
il 27/07 ("tarata su questa finestra, non passata per `study_family_honest` ne' per un
deflated-Sharpe"). Griglia **30 celle** (5 cadenze × 6 bande) su **29.9 anni** del path di
produzione, annualizzazione **√252**. **(A) Selezione in-sample** (cella scelta sui soli dati
pre-2015, letta sul 2015+): proposta **4/30 in-sample, 5/30 hold-out** → il rango NON migliora
sull'hold-out, quindi **non e' selection-on-holdout**. La cella scelta al buio (cadenza
**giornaliera**, banda 25%) vale +0.04 di Sharpe ma costa **250 controlli manuali/anno** su un
conto senza API → non e' una configurazione, e' un'ipotesi. **(B) Deflated Sharpe 0.999 PASS**
(nullo 0.14). **(C)** ⚠️ **il modo di fallire NON e' il de-levering**: allargando la banda la
**vol non scende** (0.99-1.10 del riferimento), si rompe il **TRACKING** (corr 0.951 a 25% →
0.907 a 40% → 0.859 a 60%) e lo Sharpe smette di migliorare insieme alla correlazione → nessuna
zona premia il congelamento. **Ma il 25% e' AL BORDO** (0.951 contro soglia 0.95), non al centro
di un plateau: citarlo cosi'. **Invarianza**: **25 ordini/anno a $3k/$10k/$50k** (banda 25%,
Sharpe 0.66/0.70/0.71) contro **65/92/134** (banda $50 fissa, 0.52/0.62/0.66) — ⚠️ 25 e non i
**21** citati il 27/07: stimatore diverso (griglia dei controlli su 30 anni USA vs cambi di
posizione sulla finestra UCITS di 3.2a); l'*invarianza*, che e' la proprieta' sotto esame,
regge in entrambi. **Impatto sul book: Sharpe FULL 2.221 → 2.221, maxDD 6.08% → 5.94% = zero**
(il book modella GTAA01 a $10k, dove la banda fissa gia' funziona) → **il valore e' tutto al
capitale piccolo** (0.52 → 0.66 a $3k), cioe' al deploy. **`REBAL_BAND_USD` NON cambiato**: non
sposta un numero pubblicato e lo sleeve non e' deployabile prima dei $20k → si applica **al
deploy**, con questo gate come giustificazione. **REGOLA: un parametro d'ESECUZIONE scelto
guardando il risultato e' selezione come ogni altra** e passa per gli stessi gate, anche quando
"non tocca l'allocazione".
⚠️ **CORREZIONE 2026-08-07 — il criterio (A) qui sopra e' RITIRATO: non misurava cio' che
dichiarava, e il "4/30 in-sample, 5/30 hold-out" non e' un'evidenza.** Il test lo aveva
segnalato smettendo di passare (9ª/30 in-sample, 8ª/30 hold-out) **senza che il codice fosse
cambiato** — `data/raw/` e' gitignored e il cron riscrive i parquet equity ogni notte con
`ADJUSTED_LAST` di IB, che e' retroattivo. Misurato in `r0807_gtaa_gate_resolution.py`:
**(a)** i due ranghi distavano **0.00116 di Sharpe** su uno spread di griglia di **0.3124**
(0.4%); **(b)** e soprattutto **il criterio `rank_in <= rank_oos` lo passano 14/30 celle
(47%) PER COSTRUZIONE** — la somma dei ranghi e' la stessa nelle due finestre → *e' una moneta,
e il 27/07 la moneta era uscita bene*. Contorno: spostamento tipico fra le due finestre **8
ranghi** (max 25), **Spearman IS/OOS +0.05**.
**CRITERIO SOSTITUITO, e la proposta ne esce piu' forte di prima.** La proposta e' una
**BANDA** (la cadenza settimanale e' gia' `REBAL_EVERY=5` in produzione), quindi la domanda
decidibile e' *quale banda si sceglie a cadenza di produzione guardando solo il pre-2015*:
esce **25% = la proposta**, con margine **+0.0151** di Sharpe sulla seconda (**13×** il margine
del vecchio criterio); chi avesse scelto **sull'hold-out** avrebbe preso **40%** (controllo
positivo: se coincidessero il gate non avrebbe potenza). Su **tutta** la griglia la cella al
buio e' cadenza 1 / banda **25%** — stessa banda. **La proposta e' il CONTRARIO di una
selezione-sull'hold-out.** Regge identico sull'universo a **5 gambe** (blind 25%, hold-out 40%,
margine +0.0164). ⚠️ Il criterio dice da dove VIENE la scelta, **non** che sia la migliore
sull'hold-out (con Spearman ~0 nessuna cella lo sarebbe): provenienza ≠ previsione.
⚠️ **TROVATO PER STRADA, ed e' il difetto vero: TLT ha 13.5 ANNI DI STORIA IN MENO.** Parte dal
**2016-02-03** invece che dalla quotazione (2002-07-22) → **GTAA01 gira su CINQUE gambe prima
del 2016**, e quella assente e' la gamba obbligazionaria, cioe' quella che diversifica. Non e'
di oggi (cosi' fin dal primo giro nel `cron_daily.log`, 24/06 = **prima** della validazione del
27/07) e **non e' un fetch da rifare**: una richiesta retro esplicita a IB su questo conto
ritorna **0 barre**. Conseguenza metodologica: **l'in-sample e l'hold-out di GTAA01 non sono la
stessa strategia**, e ogni confronto fra le due finestre su questo sleeve va letto cosi'.
**Guardia cablata** (`fetch_ib_equities.certify`, test `tests/test_eq_history_guard.py`, 11):
**`TRONCATO`** = storia persa rispetto al disco → **il file NON viene sovrascritto** (e neppure
fuso: `ADJUSTED_LAST` e' ri-aggiustato all'indietro, incollare due vintage crea un salto sul
giunto); **`STORIA-CORTA`** = parte >1 anno dopo la quotazione e non al tetto della richiesta
(`PRIMA_QUOTAZIONE`, 6 simboli, **fonte secondaria dichiarata**). Controlli positivi
obbligatori: giro normale, serie al tetto 30Y, ETF giovane, simbolo fuori tabella.
**REGOLE:** (a) **un criterio si misura sulla sua RISOLUZIONE prima che sul suo esito** — se
decide su una frazione di percento dello spread e' rumore anche quando passa; (b) **un gate si
valida contando quante volte lo passa un candidato a caso** (qui 47%: il conto si poteva fare
il 27/07 senza dati nuovi); (c) **una certificazione che guarda solo DENTRO la serie non vede
cio' che la serie ha PERSO** — una serie troncata e' integra, senza gap, senza spike, senza
duplicati, e passa tutto (3ª occorrenza dopo split 2:1 e contaminazione EUR/USD); (d)
distinguere «giovane» / «al tetto della richiesta» / «troncato», o la guardia segnala sempre e
viene ignorata; (e) **un test che fallisce senza che il codice sia cambiato sta segnalando che
i dati non sono versionati** — si guarda sotto prima di toccarlo.
Diari `2026-08-07-crescita-fisco-etf-scelta.md` §7 (scoperta) e
`2026-08-07-gate-gtaa-e-storia-troncata.md` (risoluzione).
- 📓 **LIBRO DI BORDO — i trade allineati col tempo, il giornale e l'analista (2026-08-23).**
`src/live/{tradesdb,journal,analista}.py`, CLI in `scripts/live/`, voci in `docs/journal/`,
test `tests/test_{tradesdb,journal,analista}.py` (77). **Strategia, pesi, config INVARIATI.**
🚨 **IL DIFETTO CHE L'HA FATTO NASCERE: i trade erano salvati e NON allineati col tempo.**
`book_execute.py` scriveva `ts_utc = pd.Timestamp(r['last_data'])`, cioe' la data della
**barra di segnale**: 19 righe su 19 a `00:00:00`, e **un trade registrato SEI GIORNI prima di
essere eseguito** (ETH 0.04 @ 1.869,74: fill vero 2026-07-14T14:00, scritto 08/07). L'ora vera
esisteva **solo** in `logs/cron_book.log`**gitignored, fuori dal backup, ruotabile**: la
cronologia reale del libro live viveva in un file che una rotazione avrebbe cancellato senza
che nessuno se ne accorgesse. Riparato alla sorgente (`ts_utc` = ora vera, `bar_ts` = barra)
**con un test di regressione sul sorgente**: se qualcuno rimette `last_data`, il test lo dice.
📌 **IL DB** (`data/live/trades.db`, dentro il perimetro del backup): `fills` col contesto del
segnale a quel giro (tp_frac, skh_sign, entry, target, posizione, equity), `roundtrips`
**derivati e ricalcolati da zero**, `equity` oraria, `journal`. Sync **orario** in `cron_book`.
**Le tre fonti si INCROCIANO e non si sovrascrivono:** log (ora vera) x jsonl (i fill) x venue
(autorevole ma **TRONCA** — 1 trade su BTC, 0 su ETH). `reconcile()` riporta le divergenze e
**non ripara niente da solo**: fra due fonti che non concordano, una riparazione silenziosa e'
un'invenzione. E' cosi' che il difetto dell'ora e' stato *isolato* invece che dedotto.
📌 **QUATTRO LIVELLI IN PAGINA, SEPARATI PER PROVENIENZA** — e la separazione E' il prodotto:
**numeri** (feed + DB) · **Lettura** (12 regole dichiarate, ognuna con l'id stampato accanto
alla riga che ha prodotto, ognuna con **due** test: uno che la accende e uno che la tiene
spenta) · **Analisi** (prosa di un modello, firmata e datata) · **Nota** (l'operatore, mai
riscritta da un ricalcolo). *Un giornale che mescola misura e racconto, a sei mesi, non
permette piu' di sapere quale delle due si stava leggendo.*
🚨 **L'ANALISTA SBAGLIA, E IL TRIPWIRE NON PUO' PRENDERLO.** `numeri_non_supportati()` verifica
che ogni cifra dell'analisi compaia in cio' che il modello ha ricevuto (oltre 3 numeri liberi:
**rifiutata**), ma **due errori su due giri con sonnet-5 non contenevano cifre nuove** — una
frase su un merge mai raccontato, e un round-trip corretto dichiarato inesistente con una
spiegazione inventata per il proprio dubbio. **Il modello e' stato portato a `claude-opus-5`;
il campione e' di due osservazioni, quindi e' un tentativo di abbassare un tasso, non una
garanzia.** **REGOLA: una guardia sui NUMERI non copre il RAGIONAMENTO — l'analisi si legge
come opinione di un lettore fallibile, mai come parte del registro.**
⚠️ **CICLO DI RETROAZIONE, trovato al primo giro reale:** il modello leggeva la **propria**
analisi del giorno prima e la commentava (aveva prodotto un paragrafo sull'avviso del tripwire
che si era preso). `senza_analisi()` toglie la sua sezione dalla pagina prima di dargliela; la
`Nota` resta, perche' il contesto dell'operatore serve. **Nessun controllo automatico puo'
distinguere il meta-commento da prosa valida: si vede solo LEGGENDO l'uscita.**
**TELEGRAM, e due delle tre riparazioni al notifier finalmente fatte.** L'analisi parte ogni
giorno con una testata di numeri; se manca, **il messaggio parte lo stesso dicendo perche'**
(il silenzio si legge come «non e' successo niente»). Il trasporto era il punto singolo di
guasto gia' misurato (**6,9% di invii persi, 2/29**) = ~25 messaggi l'anno su una cadenza
giornaliera: (a) `send(text, tentativi=1)` — retry **opzionale**, default invariato perche'
alzarlo per tutti cambierebbe la latenza degli allarmi di `venue_watch` e `book_execute` su un
percorso con soldi veri; (b) `ultimo_errore()` registra il motivo **nel punto in cui veniva
ingoiato** e non sopravvive a un invio riuscito. **(c) `alerted=True` solo a invio riuscito
resta la decisione dell'operatore**: cambia il comportamento degli allarmi. Esito nel DB in tre
stati: `inviata` / `non configurato` / `FALLITA — motivo`.
⚠️ **CINQUE difetti trovati dai test o leggendo l'uscita, nessuno a occhio:** (1) il tetto di
leva era **RIDICHIARATO** (`0.5` cablato) invece che letto da `config/live.json` — **quinta
occorrenza** dello schema che il progetto paga da luglio; (2) l'IV-rank era il percentile **a un
anno** etichettato col nome del gate di VRP01, che usa quello **espandente**: davano il verdetto
**opposto** (0,52 «sopra» contro 0,18 «sotto», e il valore giusto combacia con «0/8 settimane
passano il gate» misurato il 30/07); (3) il renderer cadeva in `KeyError` se mancava il blocco
mercato; (4) «24 giri attesi» su un giorno **in corso** = allarme a ogni esecuzione; (5) libro e
P&L leggevano **due istanti diversi** e la stessa pagina mostrava due equity.
📌 **REGOLE:** (a) **un dato operativo non ricostruibile non puo' vivere in un file gitignored**
— si materializza dove il backup arriva; (b) **una guardia piu' stretta del contratto produce
allarmi che si impara a ignorare** (il tripwire validava sulla sola pagina mentre il prompt
include anche lo storico, e bocciava un'equity vera); (c) **una regola che si accende su $2 di
cumulato insegna a saltare la sezione**: serve una soglia di rilevanza; (d) chi scrive in un
registro va **firmato**, o il registro perde il suo valore probatorio.
+159
View File
@@ -0,0 +1,159 @@
# Dati, feed e difetti trovati
> Estratto **verbatim** da `CLAUDE.md` il 2026-08-25 durante la compattazione.
> Difetti del dato scoperti e riparati, e la catena opzioni raccolta in proprio.
> Il testo non e' stato riscritto: e' la memoria originale, spostata.
---
-**SPLIT NON AGGIUSTATI nel feed equity — difetto sul LIBRO LIVE, riparato (2026-07-25).**
`data/raw/eq_iwm_1d.parquet` ed `eq_efa_1d.parquet` avevano uno split non aggiustato il
**2005-06-09** (IWM 2:1 = 49.5%; EFA 3:1 = 66.5%); IB `ADJUSTED_LAST` non li aveva aggiustati.
**La certificazione non li vedeva per un punto cieco strutturale:** l'unica guardia era
`maxret > 50% → SPIKE?` e uno split 2:1 fa **esattamente 50%** → IWM passava a 49.5% con status
OK. **IWM e' una delle 6 gambe di GTAA01 in produzione.** Impatto: GTAA6 FULL Sh 0.61→**0.64**,
IS 0.49→**0.54**, OOS 2015+ e maxDD **INVARIATI** (artefatto nel 2005, fuori hold-out) → il
difetto SOTTOSTIMAVA lo sleeve, **nessuna decisione presa va rivista**. Discriminante
split-vs-crollo (riusabile): **non il rapporto** (SLV 2026-01-30 ha rapporto 1.3994, a 4bps da
1.4, ma e' un crollo vero: GLD 10.3% lo stesso giorno) ma il **RANGE INTRADAY** — lo split apre
gia' al nuovo livello con range normale (IWM: open 47.00, range 1.7%), il crollo si muove DENTRO
la barra (SLV: range 33%). Modulo `src/data/eq_splits.py` (`detect_unadjusted_splits` a 3
condizioni congiunte + `repair_splits` componibile), riparazione **in lettura** in
`src/portfolio/gtaa.py::_close` e `scripts/research/eqlib.py::load_eq`, status
**`SPLIT-NON-AGG`** in `fetch_ib_equities.certify()`, test `tests/test_eq_splits.py` (8 casi).
**Regola nuova: ogni soglia di certificazione tarata su un valore tondo va controllata contro il
difetto che genera esattamente quel valore** (una soglia a 50% non puo' sorvegliare gli split 2:1).
- ⚠️ **IL FEED EQUITY NON AVEVA UN CROSS-CHECK — buco trovato e chiuso (2026-07-26).**
`src/data/eq_crosscheck.py`. Nel crypto la certificazione incrocia sempre piu' venue
(`certify_feed.py` vs Coinbase USD); il feed equity aveva **solo controlli locali** (integrita',
gap, spike, split). Il primo veicolo estero ha trovato il buco alla prima estrazione: **CSPX
2012-01-13** con `open/high 112.740` in **USD** e `low/close 88.010` in **EUR** (fattore dai close
adiacenti **1.2797** = EURUSD di quel giorno) → 21.9% e poi +27.8% mentre SPY faceva 0.39%.
**La certificazione esistente non lo vedeva:** unica guardia `maxret > 50% → SPIKE?`, e una
contaminazione EUR/USD vale ~22-28% — **stesso schema dello split 2:1 del 25/07** (che valeva
*esattamente* 50%). **2ª conferma: una soglia tarata su una classe di difetto non sorveglia le
altre.**
**Perche' il GEMELLO e non una regola locale:** il discriminante del 25/07 (range intraday) qui
non funziona — anche un crollo vero ha range enorme (SLV 33%). Cio' che separa i casi e' che **un
evento di mercato lo fa anche il gemello**: nel *rapporto* i movimenti veri si cancellano.
Controprova su dati reali: la scansione sui **prezzi** segnalava IDTL 2020-03 (liquidazione
treasury) e IGLN 2013-04 (crollo oro); sul **rapporto** spariscono.
⚠️ **La soglia non era tarabile sulla deviazione** — rumore legittimo fino al **9.90%**
(2025-04-09: Londra chiude alle 11:30 di New York) contro un difetto del 21.4% → margine 2.2×,
sotto il 3× richiesto. **La risposta non e' accettare il margine ma CAMBIARE STATISTICA:**
`|dev| / movimento del gemello` (un disallineamento d'orario **non puo' superare il movimento del
mercato**) → rumore **8.1**, difetto **42.7**, **margine 5.3×**. Soglia 18.0, equidistante in
scala log. Tre condizioni congiunte: deviazione + non-spiegato + **rientro** entro 5 barre.
**Riparazione = SCARTARE la barra, non ricostruirla** (del prezzo vero non si sa nulla).
⚠️ **Limite dichiarato e chiuso sul DANNO, non sulla rilevabilita':** GBPUSD 1.27 → 21% sempre
rilevato; EURUSD 1.09 → 8.3% **dentro il rumore** e non tappabile senza falsi positivi. Misurato
invece il danno di una contaminazione non vista: **dSharpe mediano 0.003, peggiore 0.056,
|Δ|>0.05 nel 2%**. **REGOLA: quando un buco non si puo' chiudere senza generare falsi positivi,
si misura il DANNO del caso non rilevato** — un buco quantificato e innocuo e' un risultato, uno
taciuto e' un debito. Il limite e' congelato in un test (`test_limite_dichiarato_*`): se qualcuno
abbassa la soglia, il test dice cosa e' cambiato.
- **CATENA OPZIONI REALE — RACCOLTA PROPRIA dal 2026-07-30 (cerbero-bite ASSORBITO e dismesso).**
`/opt/docker/cerbero-bite` (progetto separato) accumulava dal 2026-06-09 la catena Deribit
**mainnet** BTC+ETH; **è stato ELIMINATO il 2026-07-30** (container, volume, immagine e cartella
rimossi, 12 GB liberati; codice conservato su Gitea `Adriano/Cerbero-Bite`, ultimo commit di
dismissione) **e la raccolta è passata dentro PythagorasGoal**:
- **raccolta:** `scripts/live/collect_chain.py`, cron **`25 * * * *`** (`scripts/cron_chain.sh`) →
`data/raw/cb_chain/YYYY-MM-DD.parquet`. Entrambe le ali, scadenze ≤95g, OI≥100, ~570 strumenti
a giro, ~3 min. **Minuto :25 scelto, non arbitrario:** :00 era la raffica di bite, :07 è
`cron_book` (feed 5m di SKH01, la cosa che non deve trovare l'IP occupato).
- **archivio ereditato:** `scripts/analysis/import_cb_archive.py` (una-tantum) →
`cb_chain/bite_archive.parquet` (1.23M righe, 2026-05-01+) e `cb_market_snapshots.parquet`
(17.402 righe, 2026-03-26+: DVOL, RV30, funding perp e cross, **dealer net gamma**, gamma flip,
**rischio liquidazioni**, giorni all'evento macro — dati che il progetto non ha altrove).
Snapshot sqlite integrale in `/opt/docker/backups/manual/cerbero-bite-20260730/` (SHA256).
- **certificazione:** `scripts/analysis/certify_cb_chain.py`; **harness** `scripts/research/cblib.py`
(`load_chain()` unisce archivio + raccolta, dedup su `(ts, strumento)`).
- **battuta di cuore:** ogni giro scrive `data/chain_collect/runs.jsonl`, sorvegliato da
`monitor_health` (cadenza 1h, `max_age_h=3`) — **un collettore fermo non produce niente, e il
niente si legge come "nessun dato quel giorno"**.
- **BACKUP (aggiunto 2026-07-30):** `data/raw/` è gitignored → la catena **non è in git**, e il
backup rotativo della VPS non copriva PythagorasGoal. Aggiunta `do_pythagoras` a
`/opt/docker/scripts/backup.sh` (daily 04:00, retention 7/28/185 g): salva **solo il dato non
ricostruibile** — catena + contesto, `data/paper_*` e `data/chain_collect` (serie forward-only
che alimentano i gate pre-registrati: **non sono ricalcolabili**), `data/options_daily`,
`data/live`, `venue_watch`, `fee_watch`, `config/live.json`. ~28 MB. **Esclusi di proposito**
i ~110 MB ricostruibili (`rebuild_history.py`, `fetch_dvol.py`, `fetch_hyperliquid.py`,
`fetch_ib_equities.py`, cache). La funzione **fallisce rumorosamente** se la catena è assente o
vuota, e verifica il tar prodotto (controllo positivo provato in entrambi i versi).
⚠️ `/opt/docker/scripts` **non è un repo git**: quella modifica vive solo su disco.
- **Dopo un riavvio della VPS la raccolta riprende da sola** (cron di sistema `enabled`+`active`,
nessuna dipendenza da docker o da cerbero-mcp: API pubblica Deribit diretta). Verificato con
`env -i` che il giro funzioni nell'ambiente nudo di cron. Finestra scoperta: fino al `:25`
successivo, **senza recupero** — un'ora persa resta persa (il collettore non fa catch-up).
**TRE DIFETTI DI BITE NON REPLICATI** (misurati il 30/07): (a) **una chiamata per strumento**
`get_order_book?depth=3` dà già quote+greche+IV+OI+book+underlying, bite ne faceva due con
rischio di disallineamento; (b) **pacing** (token bucket 4/s + backoff) invece della raffica —
il carico non è mai stato il problema (~570 chiamate/ora = 0.16/s **distribuite**), bite le
sparava in ~26s (~44/s) auto-saturandosi il rate limit per-IP; misurato sul nostro giro:
**574 chiamate, 0 risposte 429**; (c) **`quote_status` esplicito** in {`ok`, `no_quote`, `error`}
— "book vuoto" (fatto di mercato) e "chiamata fallita" (fatto di infrastruttura) sono cose
diverse, e `book_depth_top3` è **NULL su errore, mai 0**. ⚠️ Le righe ereditate da bite hanno
`quote_status='unknown'`: bite non registrava il perché, e si dichiara l'ignoranza invece di
inventare uno stato.
🚨 **BUCO DI COLONNA nell'archivio ereditato, trovato il 2026-08-22 e mai registrato prima:**
`bite_archive` ha `index_price` e `underlying_price` **100% None (1.232.212/1.232.212)**. Il
sottostante esiste **solo dal 2026-07-30** (raccolta propria, 18,2% delle righe) e
`book_depth_top3` solo nel **67,2%**. **Chiunque calcoli moneyness o riprezzi sull'archivio
pre-30/07 sta usando una colonna che non c'è** — e il file si legge senza errori, quindi il
difetto è silenzioso.
**Ed è CHIUDIBILE senza dato nuovo:** il forward si ricostruisce con la **parità put-call**
dalla catena stessa — verificato contro l'osservato su **6.578 coppie: |errore| mediano 0,023%,
p95 0,147%, corr 1,000000** → rende la superficie utilizzabile su tutti i **75 giorni** invece
che 23. (Lo **smile**, che non richiede il forward, esiste invece su **113 giorni dal 2026-05-01**;
la **superficie completa** solo da **2026-06-09**, perché prima bite raccoglieva una sola scadenza
per giro — misurato da **tre** agenti indipendenti.)
⚠️ La famiglia raccolta è quella **inverse** (`get_instruments?currency=BTC|ETH`): la superficie
**USDC-lineare non è nell'archivio**, e ogni conclusione su di essa nel progetto è oggi un
**controfattuale costruito sui mid inverse**, non una misura. Puntare il collettore anche su
`currency=USDC` costa ~~**+587 chiamate/giro (+90%)**~~ 🚨 **CORRETTO 2026-08-23 (§51): sono
+117 chiamate = +18%.** Il 587 era il conteggio **grezzo** (1.140 strumenti USDC ≤ 95g = +81%)
**senza il filtro OI≥100 che il collettore applica davvero**, e quel filtro taglia il 90% della
famiglia USDC: con gli stessi filtri del collettore vivo sono **113 strumenti** contro **649**
inverse (✅ verificato al venue da due percorsi indipendenti; replica esatta di §8 — su Deribit
USDC l'OI e la negoziabilità sono anti-correlati). Il giro passerebbe da 652 chiamate/163 s a
**769/192 s**, dentro la finestra del :25 e senza toccare `cron_book` al :07. Resta una decisione
sul rate-limit per-IP, che ha già causato un guasto il 29/07 — ma **di un ordine di grandezza
più piccola di come era stata scritta**, ed è un numero **di oggi** (cresce con la liquidità
USDC, va ri-misurato prima di accendere).
🚨 **LA RAGIONE PER RACCOGLIERLA E' CADUTA (2026-08-23, §64): le due superfici sono LA STESSA
SUPERFICIE** a strike appaiati — prezzo equo identico per costruzione, mezzo-spread Δ 0,21/0,38 pp,
`f_venue` Δ +0,005/0,011 ⇒ il `f` di VRP01 misurato sull'inverse **non e' «il numero della famiglia
sbagliata», e' lo stesso numero**. Resta vero che la lineare **non e' nell'archivio**; cade
l'argomento che la sua assenza falsi una misura gia' fatta.
**NON assorbito, e perché:** il motore credit-spread ETH (il progetto ha già la regola "niente
short-vol da modello in deploy"), la GUI, kill switch/dead-man/audit (PythagorasGoal ha
`venue_watch`/`edge_watch`/`monitor_health`/`fee_watch`), `dvol_history` (`fetch_dvol.py` ha
storia **più lunga**: 2020+ contro 2026-05), `decisions`/`positions` (59 righe a capitale $52,
0 posizioni). Test `tests/test_collect_chain.py` (11) + `tests/test_cb_chain_vrp.py` (13).
⚠️ **Prima di cancellare la sorgente** (verifiche nel diario `2026-07-30-assorbimento-cerbero-bite.md`):
snapshot **completo** e non solo integro (4 tabelle su 4 con conteggi identici al volume vivo e ai
parquet); i 10,6 GB di backup interni **non** contenevano dati unici (stessa riga più vecchia in
tutti gli snapshot + conteggi monotoni ⇒ nessuna potatura); zero dipendenze a runtime.
⚠️ **`cerbero-mcp` è un progetto DIVERSO e serve a PythagorasGoal** (Hyperliquid, percorso del
conto) — resta acceso; la rete `traefik` che condividevano è `external:` nel compose di bite,
quindi `down -v` non la tocca. **REGOLA: prima di cancellare una sorgente si verifica che la copia
sia COMPLETA, non che esista** — un hash prova che il file non è corrotto, non che contenga tutto.
**Perché si MEMORIZZA invece di interrogarla:** una catena opzioni non è ricostruibile a
posteriori — Deribit non serve book storici, un'ora non raccolta è persa per sempre, e non c'è un
secondo venue da cui recuperarla.
**Certifica 4 difetti:** quote vuote, book incrociato, premio non monotono nello strike,
`depth==0` (ambiguo **by design**: chiamata fallita e book vuoto danno lo stesso valore → si
riporta, non si ripara).
⚠️ **GUASTO IN CORSO dal 2026-07-29 05:00 UTC — status `QUOTE-VUOTE`.** Il collettore persiste la
riga anche quando il ticker fallisce (rate-limit Deribit **per-IP**: ~650 risposte 429 in ~26s a
ogni giro, **96% al minuto :00**, generate dalla spazzata full-chain che si auto-satura) →
`bid`/`ask`/`iv`/`delta` NULL e **conteggio righe INVARIATO** (13k/giorno prima e dopo). Tasso di
quote vuote per settimana: 0.4·0.7·2.2·1.5·0.5·0.4·0.3 → **22%**; giorno peggiore **51.7% BTC /
30.6% ETH**. ✅ **Risolto dal cambio di collettore** (30/07): la raccolta propria è paced e ha
fatto 574 chiamate con **0 risposte 429**. **REGOLA: una riga presente non è un dato presente**
contare ciò che è QUOTATO, non ciò che è SCRITTO (3ª occorrenza dopo `paper_dvolspread` e
`fresh_5m`). **REGOLA: un guasto IN CORSO si misura al GIORNO PEGGIORE, non in media** — la prima
stesura confrontava "tutto" con "ultimi 7g" e diluiva un guasto di 2 giorni al 13.5%, commettendo
a 7 giorni lo stesso errore che dichiarava di evitare a 3 mesi. Diario `2026-07-30-vrp-quote-reali.md`.
+52
View File
@@ -0,0 +1,52 @@
# Metodo: gate e harness
> Estratto **verbatim** da `CLAUDE.md` il 2026-08-25 durante la compattazione.
> I gate codificati in `altlib.py` che ogni candidato deve attraversare.
> Il testo non e' stato riscritto: e' la memoria originale, spostata.
---
- **MARGINAL SCORER (implementato 2026-06-20)** — la lezione "Sharpe marginale, non assoluto" è
ora codice in `scripts/research/alt/altlib.py`: `study_marginal(name, target_fn)` valuta un
candidato direzionale BTC/ETH **sia** in assoluto **sia** rispetto al baseline `tp01_baseline_daily()`
(corr, uplift del blend OOS, beta+alpha residua) e ritorna `earns_slot = (abs!=FAIL) AND
(marginal==ADDS)`. **Regola: una nuova strategia direzionale si giudica su `earns_slot`, non sullo
Sharpe assoluto** (gli overlay-su-TSMOM ereditano lo Sharpe di trend e prendono PASS fasulli —
es. CMB04 PASS assoluto → NEUTRAL marginale). Demo `marginal_demo.py`, test `tests/test_marginal_scorer.py`.
⚠️ **INDURITO 2026-06-21 (onda ortho):** la versione fisso-HOLDOUT + jackknife-mese era
ingannabile — 17/18 book relative-value "ADDS" su una sola finestra 2025 (ETH-bleed dove TP01 è
debole). Tre gate nuovi in `marginal_vs_tp01`: **(1) persistenza multi-cut** (uplift positivo a più
date di taglio, non solo 2025); **(2) edge in-sample** (`has_insample_edge`: lo Sharpe standalone
PRE-holdout dev'essere ≥0.5 — un low-corr a Sharpe ~0.3 "aggiunge" solo matematica di
diversificazione, riportata via `null_pctl_*` vs un asset-rumore a corr-zero); **(3) hedge vs
alpha** (`is_hedge`: un low-corr che paga SOLO quando TP01 è debole — `corr(Sharpe-TP01, uplift
annuo)` molto negativa — è un hedge, non alpha). Verdetti nuovi: HEDGE, NOISE. Sull'onda ortho lo
scorer indurito collassa 17/18 → **1** (`dvol_spread`, unico con edge in-sample reale; comunque
forward-monitor per multiple-testing/storia DVOL corta). Lezione: un nuovo sleeve si giudica su
edge-in-sample + persistenza multi-cut + non-hedge, non sull'uplift di una finestra fortunata.
- **HARNESS REALISM (codificato 2026-06-21, onda intraday)** — due gate nuovi in `altlib.py`,
test `tests/test_harness_realism.py`:
- **`day_boundary_robust(target_fn, tf)`** — un effetto ora/sessione/giorno il cui uplift
marginale **si inverte** spostando il confine del giorno UTC di poche ore è un **artefatto di
etichettatura calendario** (ha ucciso `open_drive`: +0.23 a 00:00 → 0.33 a +8h → ARTIFACT-RISK).
Un segnale di prezzo è INVARIANT (spread 0); un effetto calendario vero è ROBUST (resta positivo;
es. `prevday_range_breakout`). **Regola: ogni segnale calendar/session/hour passa questo test
prima di crederci.**
- **`eval_weights_smallcap(df, target, capital=600, min_order=5)`** — a ~$600 un ribilanciamento
di nozionale < min_order **non si esegue**; la fee proporzionale che `eval_weights` applica a
migliaia di micro-trade sub-dollaro (tipici di un overlay vol-target) è **finzione**. Salta i
sub-min_order e riporta lo **Sharpe haircut** reale vs modellato. **Vale per OGNI sleeve a questo
capitale, TP01 incluso** — lo Sharpe netto onesto a $600 è quello small-cap, non quello modellato.
- **SELECTION-ON-HOLDOUT gate (codificato 2026-06-29, filone B intraday ERM)** — terzo gate in
`altlib.py`, test `tests/test_harness_realism.py`. Il lead ERM faceva `earns_slot=True` MA lo script
di scoperta sceglieva la cella per **`min_hold` massimo** su 60+ celle = **selezione-sull'hold-out**:
scegliendola in-sample-only ne esce un'altra (trend-beta corr→TP01 0.53, NEUTRAL) e il deflated-Sharpe
crolla (DSR 0.0-0.24 su 122 trial). `study_marginal` da solo non lo vede (giudica UNO stream, non *come*
è scelto). Tre funzioni: **`deflated_sharpe()`** (Bailey & Lopez de Prado, PASS ≥0.95), **`select_cell_insample()`**
(cella scelta col solo Sharpe pre-HOLDOUT), e il gate combinato **`study_family_honest(name, factory, grid, tfs)`**
`earns_slot_honest = earns_slot[cella in-sample] AND deflated-Sharpe≥0.95`. **Regola: una strategia
direzionale grid-searched si giudica con `study_family_honest`, non chiamando `study_marginal` sulla
cella a max hold-out.** Chiude il punto cieco gemello di CC01 ("Sharpe implausibile"). Diario
`2026-06-29-intraday-regime.md` (analisi `scripts/research/intraday_regime_analysis.py`).