PythagorasGoal/docs/diary/2026-06-12-fade15m-gate.md

2026-06-12 — GATE PORT06: fade 15m PROMOSSI (tutte e tre le varianti)

Seguito del probe ACCEL50: i 6 sleeve fade (MR01/02/07 × BTC/ETH) a 15m, parametri live 1h NON ri-tunati, engine canonico build_trades/fade_daily_equity parametrizzato sul timeframe. Script: scripts/analysis/fade15m_port06_gate.py.

Risultati

[1] Parità. Builder locale a 1h == sleeve canonico, diff 0.00 esatto su tutti e 6.

[2] Standalone (daily, pos 0.15 lev 3, fee 0.10% RT). Il 15m batte il twin 1h quasi ovunque; OOS Sharpe: MR01_ETH 4.94 (vs 1.10), MR02_ETH 6.40 (vs 4.72), MR07_ETH 4.44 (vs 1.97), MR07_BTC 2.37 (vs 1.59). Fee 2x: regge ovunque tranne MR02_BTC (OOS 0.60 — il piu' fee-sensitive, ma a fee reali e' il migliore BTC).

[3] Correlazione 15m↔1h: media 0.26 (range 0.16-0.41) — più decorrelato del pairs 15m promosso a 0.37. NON è la stessa scommessa più veloce: è un edge a orizzonte diverso.

[4] Gate PORT06 (cap PAIRS 0.33 / SHAPE 0.0588):

variante	FULL CAGR	FULL DD	FULL Sh	OOS CAGR	OOS DD	OOS Sh
BASELINE (1h)	74%	3.46%	7.34	111%	1.48%	10.07
ADD (+6 sleeve 15m)	85%	2.73%	8.02	125%	1.38%	10.48
SWAP (15m al posto 1h)	101%	2.47%	8.13	163%	2.09%	10.86
BLEND 50/50	87%	2.31%	8.06	136%	1.77%	10.82

Tutte e tre PROMOSSE dal criterio standard (OOS Sharpe non peggiora E DD scende).

[5] Anti-illusione flat (il check che ha ucciso pairs-alt e XEX/DOGE). ETH 15m ha 14-30%/anno di candele flat. Con flat-entry-skip l'edge SOPRAVVIVE: MR01_ETH Sh 3.11→2.85 (OOS 4.94→4.60), MR02_ETH 4.72→4.63, MR07_ETH 3.76→3.55; BTC invariato (≤0.01). Coerente col finding registrato 2026-05-28. La quota di ritorno persa (~30-40% del FULL ETH) è il caveat slippage onesto: il ledger reale shadow sarà il giudice, come per il pairs 15m.

Raccomandazione

ADD è la promozione più pulita: migliora TUTTE le metriche senza buttare il track record live dei 6 sleeve 1h (SWAP rinuncia alla config validata dal vivo; il suo OOS DD peggiora 1.48→2.09). In subordine BLEND (miglior FULL DD 2.31%).

Per il deploy (non fatto qui)

1. _defs.py: 6 SleeveSpec nuovi MR0x_{asset}_15M con tf: 15m nei params.
2. Runner: estendere il fetch sub-orario (già esistente per PR_ETHBTC_15M) ai fade 15m; verificare lookback (EMA200 a 15m = 50h → bastano ~2200 barre).
3. Validazione worker a 15m (replay == backtest, come validate_worker_pairs).
4. Sizing: a peso pieno i 6 sleeve 15m raddoppiano la famiglia FADE; valutare position_size ridotto come il blend pairs (il gate ADD qui è già a peso pieno e migliora comunque, ma il caveat slippage 15m suggerisce prudenza).
5. MR02_BTC 15m è il più fee-sensitive (fee2x OOS 0.60): monitorare le fee reali.

Addendum — DEPLOY: SWAP SECCO (stessa giornata, scelta utente)

L'utente ha scelto SWAP (la variante a CAGR più alto), consapevole dei due costi discussi: OOS DD 1.48→2.09% e perdita della maturità operativa 1h (la meccanica live — EXIT-16 confirm, TP_PHANTOM, TP resting — gira 4x più veloce su un feed testnet con wick anomali; il gate misura l'edge, non la robustezza operativa). Proposta alternativa staged (ADD temporaneo 1-2 settimane, poi spegnere il 1h) declinata: "swap secco".

Implementazione (deliberatamente minima, sid INVARIATI → pesi/alloc/epoche intatti):

• _defs.py: FADE specs → tf="15m" (DIP01 resta 1h: non era nel gate).
• combine_portfolio.py: FADE_TF="15m" nel builder canonico → le due facce (backtest/live) restano sulla STESSA definizione; il lock di parità (test_backtest_parity) confronta le facce fra loro e resta verde.
• Runner: NESSUNA modifica (il fetch sub-orario BTC/ETH 15m esisteva già per il blend pairs; _spec_assets_tf/_series_for sono generici).
• Worker: nuove dir *__15m (stato 1h preservato in *__1h, worker flat al momento dello switch). Esecuzione reale invariata (match per nome MR01/02/07).
• max_bars=24 barre ora = 6h; EXIT-16 confirm sulla barra 15m completata.

Monitor post-deploy: stop-rate e divergenza sim/reale dei fade 15m nell'hourly report; fee reali su MR02_BTC; STALE_FEED (le barre flat 15m sono più frequenti che a 1h).