# 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`** — QUANTIFICATO 2026-06-11 (`daily_equity_bfill_impact.py`):
      **NON materiale, lasciare documentato**. PORT06 OOS invariato per costruzione (il bias vive
      in testa alla serie, pre-SPLIT; ΔSharpe +0.001, ΔDD 0.000); FULL DD leggermente OTTIMISTICO
      (3.46→3.67 col fix: il primo trade DIP01 2021, −3.75%, è nascosto dal bfill). Nessun verdetto
      di gate a rischio (bias identico nei due bracci A-vs-B, si cancella). Unica eccezione OOS:
      TSM01 (primo punto equity post-SPLIT, −0.014 Sh). Correggere SOLO in un eventuale refactor
      del builder daily, OVUNQUE in un colpo (~12 file di gate replicano la convenzione) e
      ri-baselinando i canonici nello stesso commit. CAVEAT per gate futuri: finestre IDX che
      partono a metà storia amplificano il bug → usare lì la convenzione carry-forward corretta.
- [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`.
- [x] ~~engine duplicato nei 3 gate~~ — FATTO (2026-06-11): fattorizzato in
      `scripts/analysis/_port06_gate_common.py` (`build_trades_variant` versione trendmax =
      superset con hurst_mask/trend_max parametrici, `equity_from_trades`, `port_metrics`,
      `dd`); i 3 gate importano da lì. Nessuna drift di matematica trovata fra le copie
      (solo firme/docstring). Output dei 3 gate verificato BYTE-IDENTICO prima/dopo.
      `dip_trades` (DIP01) NON è una copia ma un sibling deliberato (long-only, orig_gap,
      j clampato) → resta nel suo script, documentato nel modulo comune.
- [ ] **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.

## Code-review 2026-06-11 sera (8a2b065..) — finding DEFERITI (i confermati critici sono fixati in v1.1.26)

- [ ] **RESTING reduce-only esposti al netting** (TP limit + disaster-SL): se un worker opposto
      apre DOPO il piazzamento, il resting può fillare parziale o essere respinto — il fallback
      netting copre solo i close sincroni. È il pezzo "position manager / sotto-conti" già noto;
      lo scenario peggiore è il disaster-SL cappato proprio nel crash per cui esiste.
- [ ] **Lifecycle `orphan_legs`**: append-only — un orfano risolto a mano (o da reset_flatten)
      resta nello status e MASCHERA per compensazione un drift vero futuro (falso negativo del
      reconciler). Serve un comando di risoluzione (`--resolve-orphan`) e/o reset_flatten che
      azzeri anche lo stato reale nei status.json. Idem: il PnL della chiusura manuale di un
      orfano non viene mai bookato in real_capital (diagnostica shadow divergente).
- [ ] **TP_PHANTOM residuo**: `resting_fills` guarda solo le ultime 100 righe di trade-history
      per strumento — su conto molto attivo un fill TP reale può scivolare fuori finestra →
      falso phantom persistente (sim resta in posizione, reale flat). Mitigato dal quantize
      conservativo (v1.1.26); fix vero = endpoint order-state in cerbero-mcp.
- [ ] **Validazione feed a monte** (altitudine): TP_PHANTOM copre solo i tocchi TP dei single-leg;
      le ENTRY spike-driven, lo SL close-confirm su close spike e lo z dei pairs restano esposti
      ai wick fantasma del feed testnet. Un validatore barre nel data layer coprirebbe tutti i
      consumer con un meccanismo solo (su mainnet il fenomeno non esiste: priorità bassa finché
      si resta su testnet, gli eventi TP_PHANTOM/NET_CLOSE ne misurano la frequenza).
- [ ] **Contratto dello schema status.json**: reconcile (`src/live/books.py`), hourly_report e i
      worker condividono lo schema per convenzione implicita — books.py è ora la fonte unica per
      i campi `real_*`, ma un helper `worker.real_book()` usato da _save e dai reader chiuderebbe
      la classe di bug. Pulizia: `_tp_hit` helper per i 4 siti di tocco TP duplicati; port_metrics
      ri-biforcato in xs01_tranche_gate/pairs30m_gate (importare da _port06_gate_common);
      splits3/metriche duplicate nei games engine (estrarre in scripts/games/engine.py).

## 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)

- [ ] **Churn da spike-print testnet su ETH (2026-06-11)**: il feed testnet stampa wick
      anomali sulla barra 1h ETH che (a) generano segnali short MR01/MR07 (lo spike È lo
      z-score estremo) e (b) "toccano" il TP intrabar della stessa barra → il sim booka
      +4% fantasma a bars_held=0, il reale apre+chiude pagando solo fee/spread (~−0.17€
      a giro, 14 giri oggi ≈ −2.3€). Il real-truth ledger contabilizza GIUSTO (per questo
      esiste) e il report orario ora conta i win dal flag reale. MITIGATO in v1.1.23:
      gate `TP_PHANTOM` (il tocco TP deve essere confermato dal fill del resting sul book
      reale, o dal prezzo oltre il livello) → niente più chiusure a mercato su wick
      fantasma. Resta l'ENTRY spike-driven (il segnale stesso nasce dal wick): NON
      filtrarlo nei segnali (= fit su artefatto testnet); osservare la frequenza dei log
      TP_PHANTOM — se cresce, valutare un gate di QUALITÀ FEED nel data layer.

- [ ] **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).