chore(reset): v2.0.0 — storico certificato Deribit mainnet, ripartenza pulita

Reset del progetto su fondamenta verificate dopo la scoperta che l'intera
libreria "validata OOS" era artefatto di feed contaminato (print fantasma del
feed Cerbero TESTNET + storico Binance/USDT).

- Storico ricostruito da Deribit MAINNET (ccxt pubblico, tokenless) e
  CERTIFICATO (certify_feed.py): BTC/ETH puliti su TUTTA la storia
  (mediana 2-6 bps vs Coinbase USD), integrita' OHLC + coerenza resample
  (maxΔ 0.00) + cross-venue OK. Alt esclusi (illiquidi/divergenti: LTC/DOGE
  50-82% barre flat; XRP/BNB non certificabili).
- Verdetto sul feed pulito: FADE / PAIRS / XS01 / TSM01 morti (ogni
  portafoglio Sharpe -2.3..-3.0, DD ~40%); solo SH01 e frammenti HONEST
  con segnale residuo, da ri-validare in isolamento.
- Cleanup "restart pulito": strategie, stack live (src/live, src/portfolio,
  runner/executor, yml, docker), ~100 script ricerca/gate, waste/games/
  portfolios, dati non certificati + cache e 60+ diari -> archiviati in Old/
  (preservati, non cancellati). Diario consolidato in un unico documento.
- Skeleton ricerca tenuto: Strategy ABC + indicatori + src/fractal +
  src/backtest/engine + load_data; tool dati certificati (rebuild_history,
  certify_feed, audit_feed, multi_source_check).
- Universo dati ATTIVO: solo BTC/ETH (5m/15m/1h); guardrail fisico
  (load_data su alt -> FileNotFoundError). Esecuzione DISABILITATA, conto flat.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Old/docs/diary/2026-06-09-pairs15m-robustezza.md

@@ -0,0 +1,45 @@
+# 2026-06-09 — ETH/BTC 15m: analisi di robustezza (il limite è il COSTO)
+
+Domanda: lo sleeve `PR_ETHBTC_15M` (attivato in real, v1.1.16) è robusto? Risposta dai
+dati: **sì su parametri, tempo e qualità-dati; fragile sui COSTI** — e quel limite è
+strutturale (alta frequenza). Engine `pairs_research.pairs_sim_flat` (live-realizable).
+
+## ✅ Robusto su parametri, tempo, dati
+- **Plateau parametrico**: griglia n×z_in (40-80 × 1.5-2.5) → **16/16 celle Sharpe>1**
+  (range 9-12). Non un picco overfit. (`pairs15m_port06_gate.py`)
+- **Consistenza temporale**: 2018-2021 +1874% (3/4 anni+, solo 2018 negativo);
+  2022-2026 +12958% (**5/5 anni+**); **OOS ultimo 30% Sharpe 17.6, DD 13%, +**. L'edge
+  è distribuito, non un singolo regime.
+- **Non artefatto dei dati**: filtrando le candele flat ETH 15m (16% storico) resta
+  l'**83% dello Sharpe** (`pairs15m_flatcheck.py`).
+- **Decorrelato dal 1h** (corr rendimenti giornalieri **0.37**): segnale diverso, non un relabel.
+
+## ❌ Fragile sui COSTI — il vero tallone (frequenza 5× il 1h)
+Sharpe in funzione del costo all-in RT/coppia (fee + slippage):
+
+| costo RT/coppia | **15m Sharpe** | 1h Sharpe |
+|---|---|---|
+| 0.20% (reale, 1×) | **9.34** | 4.36 |
+| 0.40% (2×) | 6.15 | 3.52 |
+| 0.60% (3×) | 2.95 | 2.68 |
+| 0.80% (4×) | **−0.24** | 1.84 |
+| 1.20% (6×) | −6.63 | 0.16 |
+
+**Il 1h regge ~6× i costi; il 15m va negativo già a ~4×.** Tanti trade piccoli (8453 vs
+1756) → margine di costo sottile. Lo **Sharpe 9.34 è un numero a costo basso**: appena lo
+slippage reale a 2 gambe porta l'all-in verso 0.40-0.60%, scende a 3-6 (ancora positivo,
+ma l'edge enorme del backtest è in gran parte illusione da bassi costi).
+
+## Implicazioni (coerenti con la config deployata)
+1. **La mezza size era giusta**: non si dà al 15m il peso che il backtest a costo basso
+   suggerirebbe. È un blend-tilt, non una scommessa.
+2. **NO allo swap** (togliere il 1h, tenere solo 15m): sostituirebbe l'àncora cost-robust
+   (1h, regge 6×) con la sleeve cost-fragile. Confronto PORT06: swap OOS 9.95 vs blend 9.66
+   — +0.3 di Sharpe di backtest pagati in robustezza reale. Non vale.
+3. **Giudice finale = ledger reale shadow**: misurerà lo slippage vero a 15m. Soglia di
+   lettura: all-in <0.40% (Sharpe ≥6) → ottimo diversificatore, valutare size piena;
+   verso 0.60%+ → vale appena la mezza-size che ha (già protetto).
+
+**In una riga**: robusto come *segnale*, fragile come *esecuzione* → sta nel portafoglio a
+metà size accanto al 1h, non al suo posto. Riproducibile: fee-sweep + sub-periodo +
+OOS via `pairs_sim_flat`; plateau/flat-check negli script `pairs15m_*.py`.