9d15506b05
Audit anti-overfit su tutte le 19 sleeve (diario 2026-06-11-stability-sweep.md): - FIX BasketTrendWorker: mean(rets) sui soli asset in posizione sovrappesava N/k a paniere parziale (1 long = 0.45 del capitale invece di 0.09) -> replay -44% vs ref +42%. Ora sum(rets)/N (convenzione canonica 1/N): replay +32% vs +42% (residuo = convenzione dichiarata). Solo statistica PAPER. - XS01 PHASE-TRANCHING (gate xs01_tranche_gate: plateau K=2 E K=3 promossi, PORT06 OOS Sh 10.07->10.15 DD 1.48->1.38, FULL pari): la fase del roll e' timing-luck (Sharpe daily 1.52-2.33, DD 13.8-33% sulle 12 fasi). Worker con param tranches (default 1), 3 sub-book sfasati hold/3 su capitale comune, migrazione status legacy, last_bar_ts solo-avanti; runner forward del param; _defs tranches=3; hourly_report aggrega i sub-book; validatore esteso e PASSATO (K=1 == xsec_sim esatto, K=3 == unione fasi esatto). - Disaster-cap z sui pairs: pre-registrato e BOCCIATO su tutti i criteri (coda OOS peggiora 4/6 coppie, Sharpe -10..-49%, plateau solo del danno; 5a conferma stop-su-MR). Record pairs_zstop_research.py; pairs restano senza stop. - Audit drift: regression-lock trendmax OK (parita' 1.00000, plateau 2.5/3.0/3.5 confermato), correlazioni cross-famiglia ~0 invariate; PORT06 rolling al 19-28mo pct (normale) ma FADE 120g al 2o percentile storico -> monitor in TODO (nessun ritocco parametri). - TODO: forming-bar ROT02/TSM01 era gia' fixato (v1.1.10), item chiuso. Test: pytest 99 passed; validate_honest_workers OK; validate_xsec_worker OK. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
82 lines
5.6 KiB
Markdown
82 lines
5.6 KiB
Markdown
# TODO — prossimi passi
|
||
|
||
> Raccolta dei follow-up aperti. Aggiornato 2026-06-11 (XS01 dispersion-gate live v1.1.20;
|
||
> real-truth ledger attivo; reset portafoglio 2026-06-10).
|
||
|
||
## Stato esecuzione per sleeve (REALE vs SIMULATO)
|
||
|
||
**REALE (shadow su Deribit testnet, REAL-TRUTH: il ledger segue i fill reali) — 15 sleeve:**
|
||
- 6 fade (MR01/MR02/MR07 × BTC/ETH) + DIP01_BTC → single-leg, v1.0.3+
|
||
- 6 pairs PR01 (ETH/BTC, LTC/ETH, ADA/ETH, BTC/LTC, ETH/SOL + ETH/BTC 15m) → 2 gambe,
|
||
v1.1.12 (2026-06-08); il 15m dal v1.1.16 (2026-06-09)
|
||
- SH01 × BTC/ETH → single-leg, exit a orizzonte (no TP/SL), v1.1.13 (2026-06-08)
|
||
|
||
**SIMULATO (paper, NON esegue reale) — 4 book multi-asset, fuori dal capitale-pool:**
|
||
- TR01 / ROT02 / TSM01 / XS01 → bloccati dal CAPITALE (rumore arrotondamento)
|
||
|
||
## Esecuzione reale — pezzi mancanti
|
||
|
||
- [x] ~~Executor a 2 gambe per i PAIRS~~ — FATTO + ATTIVO (v1.1.12, 2026-06-08).
|
||
- [x] ~~SH01 in reale~~ — FATTO (v1.1.13, 2026-06-08): l'infrastruttura no-TP esisteva già
|
||
(_place_real_tp no-op senza TP, _real_close chiude tutto market reduce-only a orizzonte).
|
||
Bastava accettare kind 'ml' in _exec_for + SH01 in execution.sleeves. Disaster-bracket
|
||
on-book = unica protezione di coda. Test SH01 open/close reale OK.
|
||
- [ ] **Multi-asset in reale** (SIMULATO: TR01/ROT02/TSM01/XS01) — **SBLOCCATO DA CAPITALE ≥ ~€20k**.
|
||
Strumenti USDC tutti esistenti (BNB/DOGE/XRP inclusi), ma a €2k il rumore di arrotondamento
|
||
per-asset è 20-30% (DOGE/XRP/SOL step grandi in $, esposizione frammentata su 5-8 asset) →
|
||
l'esecuzione reale misurerebbe il rumore dei lotti, non la strategia. Serve un
|
||
`BasketExecutionClient` (ribilancio delta multi-strumento, long-only, netting con fade+pairs
|
||
sui simboli condivisi). Beneficio limitato (~19% del portafoglio, diversificatori spesso
|
||
flat) → bassa priorità anche a capitale alto. Analisi: chat 2026-06-08.
|
||
|
||
## Capitale (decisione utente, non codice)
|
||
|
||
- [ ] **Valutare aumento capitale a €5.000-10.000** per togliere il rumore di arrotondamento.
|
||
A €2.000 il rumore BTC per trade è ~2.4% (morde); soglie: ~€4.800 (<1%), ~€9.500 (<0.5%,
|
||
"punto dolce"), ~€19.000 (trascurabile). Le commissioni invece sono % e neutre al capitale.
|
||
Col real-truth ledger il rumore di arrotondamento entra DIRETTAMENTE nell'equity → più
|
||
capitale = ledger più fedele alla strategia. Riguarda i 15 sleeve che eseguono reale.
|
||
|
||
## Follow-up dal code-review (bassa priorità, non urgenti)
|
||
|
||
- [x] ~~forming-bar su ROT02/TSM01~~ — GIÀ FIXATO (v1.1.10, 2026-06-08): `_panel` condiviso
|
||
scarta la barra in formazione via `last_bar_is_forming`. Item rimasto stantio nel TODO.
|
||
- [ ] **ancora bfill di `_daily_equity`**: la serie a punti-trade reindexata su IDX àncora il primo
|
||
valore della finestra al PRIMO trade in-finestra, non al capitale portato avanti. Tocca le
|
||
metriche canoniche di TUTTI gli sleeve a punti-trade (honest/pairs/tsm). Valutare se
|
||
correggere OVUNQUE in un colpo (cambierebbe i numeri canonici di riferimento). Scoperto nel
|
||
gate DIP01 (parità inizialmente fallita per questo).
|
||
- [x] ~~convenzione TR01 worker vs reference~~ — ERA UN BUG, FIXATO (2026-06-11): `mean(rets)`
|
||
sui soli asset in posizione sovrappesava N/k a paniere parziale (con 1 long: 0.45 del
|
||
capitale invece di 0.09). Fix: `sum(rets)/len(universe)` (equal-weight 1/N canonico).
|
||
Replay post-fix: +32% vs reference +42% (residuo = convenzione capitale-unico vs
|
||
media-equity, dichiarata). Diario `2026-06-11-stability-sweep.md`.
|
||
- [ ] **engine duplicato nei 3 gate** `*_port06_impact.py` (exit16/trendmax/dip01): `build_trades_variant`
|
||
/ `port_metrics` copiati quasi verbatim. Sono regression-lock per decisioni live → la
|
||
copy-drift corrompe i verdetti. Fattorizzare in un modulo condiviso.
|
||
- [ ] **epoche hardcoded in `hourly_report.lossguard_section`** (LOSSGUARD_SINCE, TRENDSWAP_SINCE):
|
||
ogni nuova epoca-filtro richiede di editare la funzione. Derivarle da deploy history/config.
|
||
|
||
## Ricerca dispersion/correlation (2026-06-08, 165 agenti) — follow-up opzionale
|
||
|
||
- [x] ~~Gate PORT06 di `index_comp_disp` W=168~~ — FATTO (2026-06-08): PROMOSSO MARGINALE.
|
||
Decorrela bene (corr 0.06 col MASTER) ma OOS PIATTO (Sharpe −0.01). **Documentato e
|
||
rimandato** (non deployato): gate in `dispersion_edges/gate_index_comp_disp.py`,
|
||
riprendere solo se si costruisce una famiglia DISP più ampia. Diario aggiornato.
|
||
|
||
## Monitoraggio (osservare, non agire subito)
|
||
|
||
- [ ] **FADE in coda storica (2026-06-11)**: il rolling 120g equal-weight delle 6 fade è al
|
||
**2° percentile** della propria storia (−1.0% vs p5 +0.4%); il PORT06 complessivo resta
|
||
in variazione normale (19-28° pct). NESSUN ritocco parametri (= fit sul regime corrente);
|
||
osservare se rientra. Follow-up tecnico: alert di drift per-FAMIGLIA nel `hourly_report`
|
||
(precomputare la distribuzione storica dei rolling-return di famiglia dal backtest
|
||
canonico → confrontare il rolling live; notifica sotto p5).
|
||
- [ ] **PnL live post-swap trend** (epoca TREND in `hourly_report`): verdetto stop-rate fade a n>=30.
|
||
- [ ] **SH01 post-bootstrap**: il trade-rate live deve scendere da ~25% a ~10% delle barre
|
||
(selettività della soglia ripristinata). Controllare nel report orario.
|
||
- [ ] **MR02_ETH**: ultima posizione aperta SENZA disaster-SL (aperta pre-v1.1.4). Si chiuderà
|
||
normalmente; le prossime aperture avranno il bracket.
|
||
- [ ] **parquet fresco per SH01 bootstrap**: oggi al 2026-05-28, il feed copre 365g → margine ~11
|
||
mesi. Rilanciare `download_all()` periodicamente (WARN automatico se il gap supera il lookback).
|