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-14-timing-sweep-pairs-honest.md

@@ -0,0 +1,149 @@
+# 2026-06-14 — Timing sweep: PAIRS & HONEST su 5/10/15/30m (vs live)
+
+## Domanda (goal utente)
+
+Dopo lo swap fade 1h→15m (v1.1.30), i **pairs** e le **honest** beneficiano dello stesso
+trattamento — girare su timeframe più veloci (5/10/15/30 min)?
+
+Script: `scripts/analysis/timing_sweep_pairs_honest.py` (riusa i motori canonici
+`pairs_sim_flat`, replica DIP intrabar verificata == `dip_market_gated(market_n=0)`, gate
+PORT06 == `pairs30m_gate`/`dip01`). Niente re-tuning dei parametri al cambio TF (anti-overfit,
+come lo swap fade). Tutto netto, leva 3x, OOS held-out (da 2024-10).
+
+## Vincolo dati (hard — definisce lo scope)
+
+Solo **BTC/ETH** hanno 5m/15m/30m in locale (10m = resample causale da 5m). **TUTTI gli alt**
+(ADA/BNB/DOGE/LTC/SOL/XRP) sono **SOLO 1h**. Quindi:
+- **PAIRS:** solo **ETH/BTC** è sweepabile sub-orario. Gli altri 4 pair (gambe alt: LTC/ETH,
+  ADA/ETH, BTC/LTC, ETH/SOL) restano 1h per sempre senza dati alt sub-orari.
+- **HONEST:** solo **DIP01** (BTC, mean-reversion) ha senso + dati. **TR01** (trend EMA20/100 su
+  4h, basket alt) e **ROT02** (rotazione dual-momentum 1d, momentum 60g, universo alt) sono lente
+  (orizzonte multi-giorno/mese) E multi-asset-su-alt → sub-orario **infattibile** (dati) e
+  **insensato** (momentum a 60 giorni su barre da 5 min). Nessuno sweep.
+
+## Flat-share (print stale O=H=L=C, = rischio fill) — sale al scendere del TF
+
+| asset | 5m | 10m | 15m | 30m | 1h |
+|-------|----|-----|-----|-----|-----|
+| BTC | 10.0% | 4.8% | 3.5% | 1.5% | 0.9% |
+| ETH | **29.0%** | 17.3% | 16.4% | 9.0% | 6.7% |
+
+ETH 5m al 29% è un allarme operativo serio. Nota: **30m ETH (9%) < 15m (16.4%)** → il 30m ha
+*meno* rischio stale-print del 15m già live.
+
+## PAIRS ETH/BTC — il vero free-lunch
+
+Config UNIVERSALE 1h (n=50, z_in=2.0, z_exit=0.75, max_bars=72), flat_skip live-realizable:
+
+| tf | Sharpe FULL | OOS Sh | OOS Sh fee2x | CAGR | win% |
+|----|-------------|--------|--------------|------|------|
+| 5m | 9.54 | 17.19 | 11.98 | 2071% | 56.0 |
+| 10m | 9.26 | 16.54 | **13.03** | 1214% | 64.1 |
+| 15m (live) | 8.10 | 14.40 | 11.74 | 673% | 66.7 |
+| 30m | 6.20 | 11.17 | 9.59 | 312% | 71.7 |
+| 1h (live) | 3.74 | 7.11 | 6.19 | 119% | 72.4 |
+
+(I CAGR a quattro cifre sono compounding leva su singolo sleeve, irrealistici — il portafoglio
+normalizza/cappa; il segnale robusto è lo **Sharpe** e il **gate PORT06**.)
+
+- Sharpe **monotono** al scendere del TF, e **regge le fee 2x** (a differenza delle fade, dove
+  MR02 muore a 5m). Pairs market-neutral: lo spread rientra più spesso ad alta frequenza, e
+  ETH/BTC è la coppia più liquida.
+- Corr daily fra TF: 5m↔1h 0.28, 10m↔1h 0.32, 30m↔1h 0.51; 10m↔15m 0.67 → i TF veloci sono
+  **fasi diverse dello stesso edge**, diversificanti, non duplicati.
+
+**Gate PORT06 (add half-size al BLEND 1h+15m, OOS da 2024-10):**
+
+| config | FULL Sh | FULL DD% | OOS Sh | OOS DD% | verdetto |
+|--------|---------|----------|--------|---------|----------|
+| ATTUALE (1h+15m) | 8.13 | 2.47 | 10.86 | 2.09 | — |
+| +30m | 8.24 | 2.28 | 10.87 | 1.97 | **MIGLIORA** (già `pairs30m_gate`, mai deployato) |
+| +10m | 8.44 | 2.28 | 11.04 | **1.92** | **MIGLIORA** (domina tutto) |
+| +5m | 8.52 | 2.30 | 11.00 | 1.95 | **MIGLIORA** (FULL Sh max) |
+
+Tutte e tre dominano su FULL Sh, FULL DD, OOS Sh, OOS DD. **10m** è il candidato più pulito
+(miglior OOS DD, flat-share moderato 17%); **30m** è il più sicuro (flat-share 9% < 15m live).
+
+## DIP01 (BTC) — più veloce, ma lo swap NON domina
+
+Engine canonico (n=50, z_in=2.5, sl_atr=2.5, max_bars=24), parità 1h verificata:
+
+| tf | OOS Sh BTC | OOS Sh fee2x BTC | corr↔1h | OOS Sh ETH |
+|----|------------|------------------|---------|------------|
+| 5m | 4.91 | 2.41 | 0.13 | 8.43 |
+| 10m | 3.47 | 1.99 | 0.17 | 6.51 |
+| 15m | 2.40 | 1.40 | 0.22 | 4.49 |
+| 30m | 1.34 | **0.77** | 0.41 | 3.54 |
+| 1h (live) | 1.69 | 1.36 | — | 2.68 |
+
+Standalone Sharpe sale al scendere del TF e i TF veloci sono **fortemente diversificanti**
+(corr 0.13–0.22 con l'1h). MA: **BTC fee-fragile** (30m f2x 0.77), e il **gate-swap non domina**:
+
+| config | FULL Sh | FULL DD% | OOS Sh | OOS DD% |
+|--------|---------|----------|--------|---------|
+| DIP01 1h (live) | 8.13 | 2.47 | 10.86 | 2.09 |
+| DIP01 30m | 8.16 | 2.27 | 10.78 | 2.03 |
+| DIP01 15m | 8.16 | 2.30 | 10.82 | 2.14 |
+| DIP01 10m | 8.31 | 2.49 | 10.85 | 2.15 |
+| DIP01 5m | 8.46 | 2.27 | 11.02 | 2.16 |
+
+Tutti migliorano i FULL ma **alzano l'OOS DD** (e 30m abbassa l'OOS Sharpe) → nessuno domina
+sui 4 criteri. DIP01 5m dà il miglior OOS Sharpe (11.02) ma OOS DD 2.16 vs 2.09. La bassa corr
+suggerirebbe un **ADD** (DIP01 5m come secondo sleeve diversificante) più che uno swap, ma
+aumenta la concentrazione BTC-rev e non è il free-lunch netto che sono i pairs.
+
+## Caveat (perché backtest ≠ via libera a scalare)
+
+1. **Slippage su feed flat-alto** = il vero banco di prova, già flaggato per il 15m blend
+   ("il vero banco di prova è il ledger reale shadow"). A 5m/10m è peggio (ETH 5m 29% flat).
+   Il backtest usa flat_skip (timing live-realizable) ma NON modella lo slippage attorno ai
+   print stali. → gateare via shadow ledger PRIMA di sizing, specie il 5m.
+2. **OOS = un solo regime** (2024-10→, calmo). Lo Sharpe monotono-col-TF può essere in parte
+   un artefatto di regime calmo (la MR veloce prospera nel range a bassa vol; lo sweep fade
+   trovò "i tf veloci pagano nella volatilità, non nella calma"). I pairs sono market-neutral
+   → meno esposti dei fade ai crash direzionali, ma il caveat resta.
+
+## Verdetto del backtest (gate full + OOS 2024→)
+
+- **PAIRS ETH/BTC: il gate diceva SÌ.** Estendere il BLEND con TF più veloci migliorava PORT06
+  su tutte le metriche (10m domina, 30m il più sicuro, 5m FULL Sh max), fee-2x robusto.
+- **DIP01: marginale.** Più veloce è diversificante ma lo swap non domina e BTC è fee-fragile.
+- **TR01/ROT02: NO.** Dati alt 1h-only + orizzonte lento → fuori scope per costruzione.
+
+## Tentativo di deploy → due muri, NESSUN deploy (2026-06-14)
+
+L'utente ha scelto di deployare un blend pairs ETH/BTC più veloce. Il wiring è stato fatto e
+validato (sleeve def, backtest face, worker replay == backtest esatto, regression-lock
+aggiornato) PRIMA di scoprire due blocchi che hanno ribaltato la decisione:
+
+1. **MURO FEED (30m e 10m).** Il feed live **Cerbero v2 (`/mcp/tools/get_historical`) serve
+   solo 5m/15m/1h** — il 30m e il 10m danno 400 in OGNI formato (30m/30/30min/1800), e
+   l'endpoint legacy è 404 (rimosso). La voce `"30m"` in `runner._SUBHOURLY` era **speculativa,
+   mai testata live**. → un blend 30m/10m NON è drop-in: richiede di derivarlo resamplando il
+   feed 15m/5m nel runner (modifica al data-path live condiviso). **Lezione: il _SUBHOURLY del
+   runner ≠ ciò che il feed serve davvero — smoke-testare il fetch prima di promettere un TF.**
+
+2. **MURO REGIME (5m).** Il 5m è l'unico TF veloce nativo (drop-in), ma il gate full-history
+   (Sharpe 9.54) è un **relitto dei regimi volatili vecchi**. Nel regime ATTUALE è il PEGGIORE
+   (ETH/BTC pairs half-size, ret%/Sharpe/DD):
+
+   | tf | ultimi 30g | ultimi 90g | ultimi 180g |
+   |----|-----------|-----------|------------|
+   | 5m | −10.5% / −11.5 / 11.6% | −2.0% / −0.2 / 14.1% | +78% / 2.93 / **19.5%** |
+   | 15m | −4.4% / −6.2 / 5.8% | −3.1% / −0.9 / 5.8% | +56% / 3.80 / 7.9% |
+   | 1h | −1.0% / −1.1 / 3.0% | +3.0% / +1.3 / 3.0% | +25% / **3.95** / 3.0% |
+
+   Il 5m perde su ogni finestra recente e ha **DD 3-6× il 1h**; persino sui 180g il suo Sharpe
+   (2.93) è SOTTO 15m/1h. Sommato al **flat-share ETH 5m 29%** (slippage reale, non modellato
+   dal backtest) e al fatto che girerebbe **reale**, il guadagno modesto di backtest (FULL
+   Sharpe +0.39) non vale il rischio. **5m: non conviene.**
+
+**ESITO: nessun deploy. Config live invariata (19 sleeve, pairs 1h+15m).** I file tracciati
+ripristinati a HEAD; restano solo questo diario + `timing_sweep_pairs_honest.py` come record.
+
+**Lezione di metodo:** il gate PORT06 full+OOS è necessario ma non sufficiente — va incrociato
+con (a) la fattibilità del FEED live e (b) il regime RECENTE. Un edge full-history può essere
+un relitto di volatilità passata; "più veloce = più Sharpe storico" si rovescia in "più veloce
+= più DD nel regime calmo attuale". Se in futuro si vorrà un blend più veloce: il **30m** resta
+il migliore on-paper (flat 9%), ma serve prima derivarlo dal 15m nel runner + ri-verificarlo
+nel regime del momento.