research(vol): calendar-vol non backtestabile — data-first gate + forward logger

Angolo term-structure DVOL / calendar-vol. Scan di fattibilita' PRIMA del backtest:
la storia per-scadenza NON e' pubblica su Deribit (DVOL solo 30g; trade-history IV
solo per strumenti vivi; il front rotola/espira -> serie continua front-vs-back
irricostruibile). Per la metodologia (niente edge senza OOS su dati certi) -> STOP,
niente backtest su uno snapshot.

Unica via legittima: costruire il dato IN AVANTI. Aggiunto logger forward idempotente
che interpola l'ATM IV a tenor fissi {7,30,60,90,180}g e accumula data/raw/vol_term_*.
Seminati i primi snapshot (oggi: contango lieve su BTC/ETH). Non auto-cablato in cron.

- scripts/research/probe_vol_termstructure.py (scan fattibilita')
- scripts/research/log_vol_termstructure.py (forward dataset builder)
- tests/test_vol_termstructure.py (interpolazione offline)
- docs/diary/2026-06-26-vol-termstructure-feasibility.md

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

docs/diary/2026-06-26-vol-termstructure-feasibility.md

@@ -0,0 +1,47 @@
+# 2026-06-26 — Calendar-vol / term-structure DVOL: il DATO STORICO NON ESISTE (data-first gate)
+
+**Goal utente:** "continua" — angolo scelto: scaricare e certificare la term-structure DVOL per
+testare un calendar-vol (front IV vs back IV). **Esito: bloccato a monte dal gate "il dato prima
+della strategia" (lezione v2.0.0).** Branch `research/gamma-scalp-options`.
+Script: `scripts/research/probe_vol_termstructure.py` (scan) + `log_vol_termstructure.py` (forward).
+
+## Scan di fattibilità (prima di costruire qualunque backtest)
+
+Cosa l'API pubblica Deribit espone davvero per la vol per-scadenza:
+
+| dato | disponibile? |
+|---|---|
+| Snapshot CORRENTE della term-structure ATM (mark_iv per scadenza) | **SÌ** (book_summary_by_currency, tokenless) |
+| DVOL storico | solo **30g** fisso — nessun indice 7g/60g/90g pubblico |
+| Trade-history IV per strumento | solo per strumenti **VIVI** (gli scaduti spariscono) |
+| **Serie storica continua front-vs-back IV** | **NO** — il front-month rotola/espira → irricostruibile |
+
+**Snapshot oggi (2026-06-26), per riferimento:**
+- BTC spot $59.9k: 7g 45.6% · 30g 43.2% · 60g 42.7% · 90g 42.9% · 180g 44.5% — **contango** lieve.
+- ETH spot $1.58k: 7g 57.6% · 30g 56.4% · 90g 57.5% · 180g 59.2% — contango (+1.6pp slope).
+- (I valori sono interpolati a tenor fissi: il front a 1-giorno grezzo, 38%/54%, è rumore escluso.)
+
+## Verdetto
+
+**Un calendar-vol NON è backtestabile ora su dati certificati.** La storia per-scadenza non è
+pubblica su Deribit (la nostra fonte di verità), e — coerentemente con la metodologia — **nessun
+edge va creduto senza backtest OOS su dati certificati**. Costruire un calendar-vol su uno snapshot
+singolo o su una storia ricostruita-a-pezzi sarebbe esattamente il tipo di scorciatoia che ha
+prodotto la libreria fasulla v2.0.0. Quindi: **stop, niente backtest.**
+
+## L'unica via legittima: costruire il dato in avanti
+
+`scripts/research/log_vol_termstructure.py` — logger forward idempotente: ogni run prende lo snapshot
+ATM, lo interpola ai tenor fissi {7,30,60,90,180}g e appende una riga/asset a
+`data/raw/vol_term_<asset>.parquet`. Seminate le prime righe BTC/ETH oggi. Test offline
+`tests/test_vol_termstructure.py` (interpolazione pura).
+
+**Non auto-cablato in cron** (è ricerca forward, e non tocco il cron live senza ok). Per accumulare:
+aggiungere una riga giornaliera al crontab. Dopo **~6-12 mesi** → certificare (monotonia, spike,
+cross-venue) e SOLO ALLORA testare front-vs-back. Prima, nulla.
+
+## Lezione
+
+Il data-first gate ha funzionato: ha fermato un backtest su un dato che non esiste, invece di
+produrre un numero non falsificabile. La term-structure è in **contango** oggi (regime calmo) —
+osservazione da forward-monitor, non un edge. Nessun impatto sul book live (branch separato).