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>
This commit is contained in:
Adriano Dal Pastro
2026-08-25 08:50:02 +00:00
parent 214599e0a8
commit b237ad2e8b
7 changed files with 3768 additions and 3418 deletions
+381 -3415
View File
File diff suppressed because it is too large Load Diff
+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`).