feat(gui+infra): pagina Strategia, P/L parametrico, profili Conservativa/Aggressiva, dashboard via Traefik

Espone la GUI Streamlit su https://cerbero-bite.tielogic.xyz tramite il
Traefik già attivo sull'host (label allineate al pattern di cerbero-mcp,
TLS via Let's Encrypt, websocket pass-through). Aggiunge:

- nuova tab `📚 Strategia` con stato live dei gate §2 confrontati con
  l'ultimo tick di market_snapshots, pannello P/L parametrico
  affiancato Conservativa vs Aggressiva, tabella di sensibilità
  win-rate → APR e rendering del documento canonico esteso.
- doc `13-strategia-spiegata.md` che lega ogni regola §2-§9 al campo di
  market_snapshots che la alimenta, con sezioni §4-bis (P/L atteso
  realistico, win-rate empirico, drawdown, Sharpe) e §4-ter (confronto
  fra i due profili e quando passare dall'uno all'altro).
- `strategy.conservativa.yaml` (golden config v1.0.0 esplicita) e
  `strategy.aggressiva.yaml` (cap_per_trade 4×, max_concurrent 2×,
  max_contracts 4×, deroga §11 documentata) con config_hash validi.
- nel compose: servizio dedicato `cerbero-bite-gui` (Streamlit su
  0.0.0.0:8765, healthcheck su /_stcore/health, label Traefik), env
  condivisi via anchor YAML `x-bite-env`, `--environment mainnet`
  passato a `start` per allineare il boot check al token del .env (era
  testnet vs mainnet → kill switch armato all'avvio).
- Dockerfile installa anche l'extra `gui` (streamlit) e copia
  `docs/` + i due nuovi profili nell'immagine; `.dockerignore` non
  esclude più `docs/` (causa del primo build silenzioso).

Fix bonus: `_try_load` nella pagina ritornava `LoadedConfig` ma la GUI
leggeva `.sizing.*` direttamente — l'`except: pass` mascherava
l'AttributeError facendo cadere sui default conservativi sia nel
pannello P/L sia nello stato gate (stesso pattern presente nella
Calibrazione). Ora ritorna `.config`.

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

docs/13-strategia-spiegata.md

@@ -0,0 +1,592 @@
+# 13 — Strategia spiegata: dalle regole ai dati
+
+> Documento operativo che lega ogni decisione del rule engine al dato
+> osservabile da cui dipende. Pensato per chi guarda il cruscotto e
+> vuole capire **a cosa servono** le metriche raccolte ogni 15 minuti
+> nella tabella `market_snapshots`. La versione canonica e immutabile
+> delle regole resta in `01-strategy-rules.md`; questo documento è la
+> guida descrittiva da leggere prima di toccare le soglie in
+> `strategy.yaml`.
+
+---
+
+## TL;DR
+
+Cerbero Bite vende **credit spread settimanali su ETH/Deribit** quando
+la volatilità implicita è **abbastanza alta da pagare bene**, il
+mercato non è in **stress di liquidazione**, non ci sono **eventi macro
+forti** in finestra, e il bias direzionale è **chiaro** (bull o bear).
+Tutto il resto del tempo, l'engine **non opera**: la disciplina è la
+strategia.
+
+Ogni 15 minuti raccoglie 1 riga per asset (ETH e BTC) nella tabella
+`market_snapshots`. Quei dati alimentano tre obiettivi distinti:
+
+1. **Decisione live** — l'entry ciclo del lunedì 14:00 UTC legge i
+   campi più freschi per dire "go/no-go".
+2. **Monitoring continuo** — il decision loop di gestione attiva
+   confronta la situazione con quella all'apertura.
+3. **Calibrazione** — la pagina `📐 Calibrazione` usa la distribuzione
+   storica di ciascun campo per scegliere soglie basate sui percentili
+   reali del proprio ambiente, non a istinto.
+
+---
+
+## 1. Cosa c'è in `market_snapshots` (1 riga ogni 15 min, per asset)
+
+| Campo | Unità | Sorgente MCP | A che serve nella strategia |
+|---|---|---|---|
+| `timestamp` | UTC ISO | scheduler | indicizzazione della time-series |
+| `asset` | ETH / BTC | scheduler | partizionamento (ETH = sottostante operativo, BTC = controllo macro) |
+| `spot` | USD | mcp-deribit `spot_perp_price` | trend 30g (§3.1), distanza % strike (§3.2/3.3), context generale |
+| `dvol` | indice 0–200 | mcp-deribit `latest_dvol` | gate entry §2.3-§2.4 (35 ≤ DVOL ≤ 90), aggiustamento sizing §5.3, vol-stop §7.3 |
+| `realized_vol_30d` | % annualizzata | mcp-deribit `realized_vol` | confronto con DVOL → mean-reversion edge |
+| `iv_minus_rv` | punti vol | derivato | richness della IV: > 0 = premio "ricco" da vendere |
+| `funding_perp_annualized` | frazione | mcp-hyperliquid `funding_rate_annualized` | gate entry §2.6 (\|f\| ≤ 80% annualizzato), bias §3.1 |
+| `funding_cross_annualized` | frazione | mcp-sentiment `funding_cross_median_annualized` | bias direzionale §3.1 (mediana 4 maggiori exchange) |
+| `dealer_net_gamma` | USD | mcp-deribit `dealer_gamma_profile` | filtro quant §2.8 (long-gamma regime sopprime la vol → ideale per vendere spread) |
+| `gamma_flip_level` | USD | mcp-deribit `dealer_gamma_profile` | livello spot oltre il quale il regime di gamma flippa |
+| `oi_delta_pct_4h` | % | mcp-sentiment `liquidation_heatmap` | proxy di accumulo/sgonfiaggio leverage nelle ultime 4h |
+| `liquidation_long_risk` | low / med / high | mcp-sentiment `liquidation_heatmap` | rischio long squeeze imminente |
+| `liquidation_short_risk` | low / med / high | mcp-sentiment `liquidation_heatmap` | rischio short squeeze imminente |
+| `macro_days_to_event` | giorni | mcp-macro `next_high_severity_within` | gate §2.5 (no entry se evento macro entro DTE) |
+| `fetch_ok` | bool | scheduler | qualità riga (true = tutte le sotto-chiamate sono andate) |
+| `fetch_errors_json` | json o NULL | scheduler | mappa errori per debugging best-effort |
+
+> Un campo `NULL` non invalida la riga: la collezione è
+> **best-effort**, una MCP giù non blocca le altre. Le distribuzioni
+> si calcolano sui campi disponibili, l'engine entry-cycle invece
+> rifiuta l'entry se il dato che gli serve è `NULL` (sicurezza:
+> meglio saltare un trade che operare alla cieca).
+
+---
+
+## 2. Le sei famiglie di dati e il "perché"
+
+### 2.1 — Volatilità implicita (DVOL, realized vol, IV−RV)
+
+**Cosa misura.** DVOL è l'indice Deribit della IV ETM 30g. Realized
+30g è la deviazione standard annualizzata dei rendimenti spot. La
+differenza `IV − RV` quantifica quanto le opzioni stanno **pagando
+sopra** la volatilità che il mercato ha effettivamente realizzato:
+**questa è la materia prima del credit spread venditore.**
+
+**Come la usa l'engine.**
+
+- §2.3 / §2.4: `dvol_min = 35`, `dvol_max = 90` — sotto 35 il premio
+  è troppo magro rispetto a fees+slippage, sopra 90 si è in
+  stress-regime (rischio gap > edge).
+- §5.3: `dvol_adjustment` riduce la size all'aumentare del DVOL
+  (×1.0 sotto 45, ×0.85 fra 45–60, ×0.65 fra 60–80, no entry > 80).
+- §7.3: `vol_stop_dvol_increase = 10` — se durante la posizione
+  DVOL sale di 10 punti rispetto all'entry, si chiude.
+
+**Cosa si calibra dai dati raccolti.** Un mese di tick ti dà la
+distribuzione di DVOL nel TUO regime (testnet vs mainnet, bull vs
+bear). I percentili P25/P50/P75 nella pagina `📐 Calibrazione`
+dicono se 35 è davvero il "fondo" o se andrebbe alzato.
+
+### 2.2 — Funding rate (perpetual + cross-exchange median)
+
+**Cosa misura.** Il funding annualizzato del perpetual ETH-PERP
+(Hyperliquid principalmente) e la mediana dei funding sui 4 maggiori
+exchange. Il funding è la fee periodica che paga il lato sbilanciato
+del perp: **è il termometro più diretto del posizionamento leveraged
+del mercato.**
+
+**Come la usa l'engine.**
+
+- §2.6: `funding_perp_abs_max_annualized = 0.80` — funding > 80%
+  annualizzato (in valore assoluto) = liquidazioni a cascata
+  imminenti, no entry.
+- §3.1: il **bias direzionale** dipende dal funding cross:
+  - `funding_bull_threshold_annualized = 0.20` ⇒ bias bull se
+    cross-funding ≥ +20%.
+  - `funding_bear_threshold_annualized = -0.20` ⇒ bias bear se
+    ≤ -20%.
+  - In mezzo + trend neutro = candidato Iron Condor.
+  - Trend e funding discordi = no entry.
+
+**Perché due funding diversi.** Il perp di Hyperliquid è il segnale
+"è esecutibile la chiusura?" (l'ETH-PERP è la sede di hedge
+pratico). La mediana cross-exchange è il segnale macro
+"dove sta il mercato globale": più robusta a manipolazioni o picchi
+locali.
+
+### 2.3 — Dealer gamma (net gamma + flip level)
+
+**Cosa misura.** L'esposizione netta di gamma dei dealer di opzioni
+su Deribit, ricostruita da OI per strike e direzione. Quando
+`dealer_net_gamma > 0` (long gamma), i dealer **sopprimono** la
+volatilità realizzata col loro hedge (vendono salendo, comprano
+scendendo). Quando è negativo, **amplificano** ogni movimento.
+
+**Come la usa l'engine.**
+
+- §2.8: `dealer_gamma_min = 0`, `dealer_gamma_filter_enabled = true`
+  — entry solo in regime long-gamma. Vendere credit spread con
+  dealer corto-gamma è statisticamente perdente.
+- `gamma_flip_level` è il prezzo spot al quale il regime cambierebbe.
+  Se siamo a 1% dal flip, il margine di sicurezza è basso anche se
+  il segno è positivo.
+
+**Cosa si calibra dai dati raccolti.** La distribuzione di
+`dealer_net_gamma` nel proprio universo (qualche miliardo USD su
+mainnet, ordini di grandezza diversi su testnet) suggerisce se
+`min = 0` è troppo permissivo — su mainnet è frequente che il segno
+si trovi positivo per molto tempo, qui ha senso una soglia più alta.
+
+### 2.4 — Liquidation heatmap (OI delta + long/short squeeze risk)
+
+**Cosa misura.** Da `mcp-sentiment`:
+
+- `oi_delta_pct_4h`: variazione % dell'open interest aggregato nelle
+  ultime 4h. Spike positivo → leverage in entrata (rischio fragile);
+  spike negativo → squeeze appena avvenuta.
+- `liquidation_long_risk` / `liquidation_short_risk`: classificazione
+  qualitativa (`low` / `med` / `high`) della densità di livelli di
+  liquidazione vicini allo spot.
+
+**Come la usa l'engine.**
+
+- §2.8 (`liquidation_filter_enabled = true`): l'entry cycle scarta
+  setup con `_risk = high` sul lato che ci interesserebbe (es. un
+  bull put spread in regime di `long_risk = high` è esposto a un
+  long-squeeze giù).
+- Anche fuori dall'entry, queste due colonne servono come "filtro di
+  realtà" per il monitoring: se durante la posizione lo squeeze risk
+  cambia da low a high, è un primo segnale di vol-stop in arrivo.
+
+### 2.5 — Macro calendar (giorni al prossimo evento)
+
+**Cosa misura.** `mcp-macro` restituisce il numero di giorni al
+prossimo evento ad alta severità (FOMC, CPI USA, NFP, ECB, Powell
+speech) per US/EU. `NULL` = nessun evento entro la finestra DTE.
+
+**Come la usa l'engine.**
+
+- §2.5: se `macro_days_to_event ≤ dte_target = 18`, no entry. Le
+  uscite macro si trasformano in gap di volatilità che mangiano in
+  un'ora il credito di tre settimane.
+- Le entry sono comunque possibili poco dopo l'evento (vol elevata
+  appena dopo + RV destinata a comprimersi → IV−RV alto = setup di
+  scuola).
+
+### 2.6 — Spot ETH (e BTC come controllo)
+
+**Cosa misura.** Prezzo last/perp di ETH (e BTC come controllo).
+
+**Come la usa l'engine.**
+
+- §3.1: trend 30g calcolato come `(spot_now / spot_30g_ago - 1)`.
+  Soglie ±5% definiscono bias bull / bear / neutro.
+- §3.2: distanza % degli strike short dallo spot (15–25% OTM).
+- §7.6: `adverse_move_4h_pct = 0.05` — close su movimento contrario
+  ≥ 5% in 4h.
+
+**Perché anche BTC.** ETH è il sottostante operativo, BTC è il
+**termometro macro crypto**: in regimi di alta correlazione, un
+movimento BTC che ETH non sta seguendo è un segnale di divergenza che
+spesso precede un riallineamento brusco.
+
+---
+
+## 3. Il flusso decisionale, allineato al dato
+
+Quanto segue è la versione "leggibile" delle regole §2-§9 di
+`01-strategy-rules.md`. Ogni passo cita i campi di
+`market_snapshots` che lo alimentano.
+
+### Fase 1 — Trigger (lunedì 14:00 UTC, festività italiane escluse)
+
+```
+SE NESSUNA posizione aperta
+   E capitale ≥ 720 USD
+   E 35 ≤ dvol ≤ 90                                    # market_snapshots.dvol
+   E |funding_perp_annualized| ≤ 0.80                  # market_snapshots.funding_perp_annualized
+   E macro_days_to_event > dte_target  (oppure NULL)   # market_snapshots.macro_days_to_event
+   E ETH holdings cerbero-portfolio ≤ 30%
+   E (filtri quant: dealer_net_gamma > 0,
+       liquidation_*_risk ≠ high)                      # market_snapshots.dealer_net_gamma + liquidation_*
+ALLORA
+   procedi alla Fase 2
+ALTRIMENTI
+   no entry, log motivo, ritento la settimana successiva
+```
+
+### Fase 2 — Bias e struttura
+
+```
+trend_30g  = spot_now / spot_30g_ago - 1               # market_snapshots.spot
+funding_x  = funding_cross_annualized                  # market_snapshots.funding_cross_annualized
+
+SE trend_30g ≥ +5% E funding_x ≥ +20%:
+    struttura = Bull Put Spread
+SE trend_30g ≤ -5% E funding_x ≤ -20%:
+    struttura = Bear Call Spread
+SE |trend_30g| < 5% E |funding_x| < 20%
+   E dvol ≥ 55 E ADX(14) < 20:
+    struttura = Iron Condor
+ALTRIMENTI:
+    no entry (mercato indeciso o discordante)
+```
+
+### Fase 3 — Selezione strike (delta-target + distanza % spot)
+
+Lo strike short è quello a delta target ≈ 0.12 (tolleranza 0.10–0.15)
+**e** OTM 15–25%. Lo strike long è a 4% del spot (3–5% accettabile).
+Tutti i numeri sono parametrizzati in `strategy.yaml > structure`.
+Lo `spot` corrente per il calcolo viene da `market_snapshots.spot`.
+
+### Fase 4 — Sizing (Kelly frazionario + cap aggregato + DVOL clamp)
+
+```
+risk_target = capitale * 0.13                                # quarter Kelly
+risk_target = min(risk_target, 200 EUR)                      # cap per-trade
+n           = floor(risk_target / max_loss_per_contract)
+n           = min(n, 4, vincolo aggregato 1000 EUR)
+n           = round_down(n * dvol_multiplier)                # market_snapshots.dvol → §5.3
+```
+
+### Fase 5 — Esecuzione (combo limit GTC al mid)
+
+Limit al mid del combo, riprezzamento +1 tick / 30min fino a 3 step.
+Su trigger urgenti (CLOSE_STOP / CLOSE_VOL / CLOSE_DELTA) l'engine
+accetta fino a 5 step di slippage perché l'urgenza prevale sul
+prezzo.
+
+### Fase 6 — Monitoring (cron di gestione attiva, default ogni 12h)
+
+Per ogni posizione aperta, in **ordine** (primo trigger vince):
+
+| # | Trigger | Dato sorgente |
+|---|---|---|
+| 1 | Profit take: mark ≤ 50% credito | combo mark via deribit |
+| 2 | Stop loss: mark ≥ 250% credito | combo mark via deribit |
+| 3 | Vol stop: dvol_now ≥ dvol_entry + 10 | `market_snapshots.dvol` |
+| 4 | Time stop: dte ≤ 7 (skip se ≥ 70% profit) | scadenza struttura |
+| 5 | Delta breach: \|delta_short\| ≥ 0.30 | option chain via deribit |
+| 6 | Adverse move: \|return_4h_ETH\| ≥ 5% contro | `market_snapshots.spot` |
+| 7 | Altrimenti | HOLD |
+
+Il monitoring NON consulta `market_snapshots` per i prezzi opzioni
+(legge live), ma li consulta per `dvol` e `spot` con il vantaggio di
+una serie storica già normalizzata e auditabile.
+
+---
+
+## 4. Cosa fa OGGI il bot in modalità "data-only"
+
+Il bot oggi è in **modalità raccolta dati** (`ENABLE_DATA_ANALYSIS=true`,
+`ENABLE_STRATEGY=false`). Vuol dire:
+
+- Il job `market_snapshot` (cron `*/15`) gira: scrive nuove righe in
+  SQLite, alimenta calibrazione e monitoring storico.
+- Il job `health` (`*/5`) verifica disponibilità MCP e ambiente
+  Deribit; alza il kill switch se qualcosa non torna.
+- Il job `backup` (`0 *`) snapshotta lo stato ogni ora.
+- Il job `manual_actions` (`*/1`) consuma comandi dalla GUI.
+- I cicli `entry` e `monitor` **non sono nemmeno schedulati**: nessun
+  ordine può partire, nessuno strike viene letto.
+
+Quando si vuole passare alla fase operativa (paper trading o
+mainnet), basta:
+
+1. Riempire `strategy.yaml` con le **soglie calibrate** sui
+   percentili reali della pagina `📐 Calibrazione` (non lasciare i
+   valori default a istinto).
+2. Bumpare `config_version` + rigenerare `config_hash` con
+   `cerbero-bite config hash --file strategy.yaml`.
+3. Settare `ENABLE_STRATEGY=true` in `.env` e ricreare il container.
+4. Disarmare il kill switch da GUI o CLI con motivazione esplicita.
+5. **Una settimana di paper trading** (mainnet con ordini disabilitati
+   o testnet) prima di alzare il flag definitivo.
+
+---
+
+## 4-bis. P/L atteso (realistico)
+
+I numeri qui sotto sono **stime ex-ante**, non promesse. Servono ad
+allineare le aspettative con la geometria della strategia: capire
+**quanto poco si rischia per trade**, **quanto raramente si entra**, e
+**perché l'edge è strutturalmente sottile**.
+
+> **Domanda onesta che chiunque guardi i numeri dovrebbe farsi:** se a
+> win-rate 70–72% l'aspettativa per trade è circa zero, **che senso ha
+> la strategia?**
+>
+> **Risposta:** il selling vol nudo è effettivamente neutro a quel
+> win-rate. **L'edge della Cerbero Bite non è "vendere vol"; è
+> "vendere vol solo quando i filtri quant alzano il win-rate sopra il
+> 75%".** I gate §2 (DVOL band, dealer gamma > 0, no macro entro DTE,
+> liquidation risk ≠ high, bias trend × funding concorde) sono
+> **costruiti per saltare proprio le finestre statisticamente
+> perdenti** e operare solo in quelle favorevoli. La pagina
+> `📚 Strategia` ha una tabella di sensibilità che mostra come l'APR
+> passa da ≈0% (win 0.72) a +3-5% (win 0.78–0.80): è esattamente la
+> distanza che i filtri devono coprire. Per questo i primi giorni di
+> raccolta dati servono a **misurare** se i filtri stanno effettivamente
+> alzando il win-rate prima di committare capitale.
+
+### Per singolo trade (riferimento: ETH spot ≈ 3000 USD)
+
+| Voce | Formula / fonte | Valore tipico |
+|---|---|---|
+| Larghezza spread | 4% × spot | **120 USD / contratto** |
+| Credito incassato | ≥ 30% × larghezza | **36–48 USD / contratto** |
+| Max profit teorico | = credito (a scadenza OTM) | 36–48 USD / contratto |
+| **Profit-take §7.1 (50% credito)** | 0.5 × credito | **+18–24 USD / contratto** |
+| **Stop-loss §7.2 (mark = 2.5× credito)** | 1.5 × credito | **−54–72 USD / contratto** |
+| Margine bloccato | ≈ larghezza | 120 USD / contratto |
+| Fees Deribit | 0.03% notional × 2 leg | ~1–2 USD / contratto / trade |
+
+> Su spot più basso (2000 USD) la larghezza scende a 80 USD/contratto
+> e i numeri assoluti seguono proporzionalmente.
+
+### Sizing tipico vs capitale
+
+Il sizing è governato dal Quarter-Kelly **+ cap per-trade 200 EUR
+(~215 USD)**. Sopra una certa soglia, il cap domina: alzare il
+capitale **non aumenta** i contratti per trade.
+
+| Capitale | risk_target (Kelly) | risk effettivo (post-cap) | Contratti tipici (spot=3000) |
+|---|---|---|---|
+| 720 USD (minimo) | 94 USD | 94 USD | **0–1** (entry spesso saltata per sizing) |
+| 1 500 USD | 195 USD | 195 USD | **1** |
+| 3 000 USD | 390 USD | **215 USD** (cap) | **1** |
+| 10 000 USD | 1 300 USD | **215 USD** (cap) | **1** |
+| 50 000 USD+ | 6 500 USD | **215 USD** (cap) | **1** (cap aggregato 1 075 USD = max 4 trade aperti, ma `max_concurrent_positions: 1`) |
+
+> Con i cap correnti la strategia è **dimensionata per capitale
+> piccolo (1.5–10 k USD)**: oltre, il rendimento sul totale scala
+> sotto-lineare e tende a zero.
+
+### Frequenza realistica di entry
+
+La regola si valuta una volta a settimana, ma la maggioranza dei
+lunedì viene saltata per:
+
+| Motivo di skip | Frequenza tipica |
+|---|---|
+| DVOL fuori banda (35–90) | 25–40% |
+| Bias non chiaro (trend × funding discordi o entrambi neutri senza IC) | 25–35% |
+| Macro entro DTE | 10–20% |
+| Funding o liquidation risk fuori soglia | 5–15% |
+| Capitale o sizing insufficiente | 0–5% |
+
+**Risultato netto: 30–50% delle settimane finisce in entry effettiva
+⇒ 15–25 trade / anno** (52 lunedì × 30–50%). Le altre settimane il
+bot sta fermo. È il design.
+
+### Win-rate atteso (short delta 0.12 + profit-take 50%)
+
+Letteratura e backtest su credit spread short delta 0.10–0.15 con
+TP@50% e SL@1.5×:
+
+| Esito | Probabilità tipica | Risultato |
+|---|---|---|
+| Profit-take a 50% credito | **~70–75%** | +18–24 USD/contratto |
+| Stop-loss a 1.5× credito | ~15–20% | −54–72 USD/contratto |
+| Time-stop o exit DTE 7g | ~5–10% | piccolo positivo (~+5–10 USD) |
+| Vol/delta/macro stop | ~3–5% | variabile, mediamente neutro |
+
+Atteso medio per contratto:
+
+```
+E[trade] ≈ 0.72 × 21 + 0.18 × (-63) + 0.07 × 7 + 0.03 × 0
+        ≈ 15.1 − 11.3 + 0.5 + 0
+        ≈ +4.3 USD lordi / contratto
+```
+
+**Al netto di fees (~1.5 USD round-trip) e slippage (~5% del credito
+≈ 2 USD): E[trade] ≈ +1–3 USD per contratto.**
+
+### Proiezione annuale (1 contratto medio per trade)
+
+| Scenario | Trade/anno | E[trade] netto | P/L lordo annuo | Su capitale 1 500 USD | Su capitale 3 000 USD |
+|---|---|---|---|---|---|
+| **Pessimistico** (vol bassa, regime bear vol) | 12 | +1 USD | **+12 USD** | +0.8% | +0.4% |
+| **Realistico medio** | 18 | +2.5 USD | **+45 USD** | +3% | +1.5% |
+| **Buono** (regime favorevole, IV−RV alto) | 22 | +4 USD | **+88 USD** | +5.9% | +2.9% |
+| **Eccellente** (cherry-picking ex-post) | 25 | +6 USD | **+150 USD** | +10% | +5% |
+
+**Realisticamente: +1.5% / +5% APR sul capitale totale**, con i cap
+correnti. È in linea con la letteratura su short-vol systematic con
+disciplina di stop. **Non è una strategia "raddoppia il capitale".**
+È una strategia che vuole guadagnare il **premio di rischio della
+volatilità** in modo controllato.
+
+### Drawdown e rischio coda
+
+- **Streak realistico di perdite consecutive**: 3–5 stop-loss di fila
+  capitano. Drawdown su 1 contratto: −150 / −300 USD assoluti.
+- **Su capitale 1 500 USD** = drawdown del 10–20% del capitale
+  totale. Aspettarselo, è dentro il design.
+- **Tail risk:** un evento gap notturno (sentenza SEC, hack
+  exchange, default importante) può portare il mark a 100% della
+  larghezza prima che lo stop sia eseguibile. **Perdita massima
+  reale per trade = larghezza intera** (`width - credit_iniziale`),
+  cioè 72–96 USD/contratto, non i 54–72 USD del modello stop-loss.
+- I **filtri quant** (`dealer_gamma_min`, `liquidation_filter`) e
+  il **macro filter** sono stati introdotti **per ridurre la coda**,
+  non per migliorare l'aspettativa media.
+
+### Sharpe atteso
+
+Strategie short-vol sistematiche con disciplina hanno:
+
+- **Sharpe 0.8–1.5** in regimi favorevoli (mercato lento + IV alta).
+- **Sharpe 0.3–0.8** in regimi normali.
+- **Sharpe negativo** in regimi di vol-of-vol (es. Q1 2020, Maggio
+  2021, FTX week). I filtri li mitigano, non li annullano.
+
+### Cosa cambia con `ENABLE_STRATEGY=true`
+
+In modalità data-only (oggi) il P/L atteso è **0** — l'engine
+**non opera**. Il valore della raccolta di oggi è:
+
+1. **Calibrare** soglie su percentili reali → P/L atteso più
+   realistico al go-live.
+2. **Validare** i filtri quant osservando ex-post quanti tick
+   sarebbero stati filtrati (vedi pagina `📐 Calibrazione`, colonna
+   "% bloccato dalla soglia").
+3. **Misurare** la quota effettiva di lunedì che superano i filtri
+   nel proprio regime, prima di committare capitale.
+
+> Suggerimento: 4 settimane di dati = 4 lunedì × probabilità entry =
+> 1–2 candidate entry effettive. **Aspettare almeno 8 settimane**
+> prima di tarare le soglie dà uno storico con dispersione
+> sufficiente per decisioni non-rumorose.
+
+---
+
+## 4-ter. Due profili: Conservativa vs Aggressiva
+
+Il P/L del §4-bis assume i cap della golden config v1.0.0
+(`cap_per_trade_eur: 200`, `max_concurrent_positions: 1`,
+`max_contracts_per_trade: 4`). Su quel profilo il P/L assoluto è
+piccolo per design — la strategia è dimensionata come **macchina di
+conservazione del capitale** con premio modesto su T-bill.
+
+Per chi vuole rendimenti significativi, il repo include un secondo
+file di config — `strategy.aggressiva.yaml` — che **deroga
+esplicitamente** alla §11 di `01-strategy-rules.md` allargando le tre
+leve dominanti:
+
+| Leva | Conservativa | Aggressiva | Effetto sul P/L |
+|---|---|---|---|
+| `cap_per_trade_eur` | 200 | **800** | 4× la size per trade |
+| `cap_aggregate_open_eur` | 1 000 | **3 200** | 4× il rischio aggregato |
+| `max_concurrent_positions` | 1 | **2** | 2× le posizioni aperte simultanee |
+| `max_contracts_per_trade` | 4 | **16** | toglie il vincolo aggregato anche su capitali maggiori |
+| `kelly_fraction` | 0.13 | **0.13** | invariato (la disciplina Kelly resta) |
+| Filtri quant (gamma, liquidation, macro) | ON | **ON** | invariati (l'edge è qui, non si tocca) |
+
+**Risultato atteso (a parità di filtri e win-rate):** P/L ≈ 4–8× il
+profilo conservativo. Drawdown atteso scala con lo stesso fattore
+(20–40% del capitale impiegato in streak avverse, contro 10–20% del
+conservativo). La pagina `📚 Strategia` ha un pannello affiancato che
+calcola entrambi sugli stessi slider.
+
+**Il rovescio della medaglia.**
+
+- La deroga alla §11 va **autorizzata esplicitamente** nel commit che
+  switcha la config; tre settimane di paper trading dedicato sono
+  raccomandate.
+- Il drawdown maggiore richiede capitale "growth", non capitale di
+  parcheggio.
+- I filtri quant restano **identici** — non c'è "più aggressivo" sui
+  trigger di entry, perché lì non c'è alpha da spremere senza
+  peggiorare il win-rate.
+
+**Multi-asset (ETH + BTC) — caveat.**
+
+L'ulteriore moltiplicatore 2× citato nel §4-bis (multi-asset) **non è
+abilitato** dalla sola modifica della config: il rule engine attuale è
+single-asset (`asset.symbol`). Per estenderlo servono modifiche in:
+
+- `cerbero_bite/runtime/entry_cycle.py` (loop sui simboli)
+- `cerbero_bite/state/repository.py` (multi-position chiave per asset)
+- `cerbero_bite/runtime/orchestrator.py` (scheduler one-asset → N)
+
+Il job di raccolta dati è già multi-asset (`DEFAULT_ASSETS = ("ETH",
+"BTC")`), quindi tutto il dataset utile per validare l'estensione è
+già disponibile. È un lavoro di codice ben circoscritto, da fare in
+un branch dedicato dopo che il dataset di calibrazione è abbondante.
+
+**Quando passare dal profilo conservativo all'aggressivo.**
+
+Solo se **tutte** le seguenti sono vere:
+
+1. ≥ 8 settimane di dati raccolti su mainnet (≥ ~2k snapshot).
+2. Win-rate empirico misurato (paper trading o backtest sui tick
+   raccolti) **≥ 0.75**.
+3. APR atteso del profilo aggressivo (vedi pannello GUI) **≥ 8%**
+   netto a quel win-rate.
+4. Capitale impegnato è **growth capital**, non riserva tattica.
+5. Sopporti emotivamente un drawdown a doppia cifra senza disarmare
+   manualmente la strategia in mezzo a una streak.
+
+Se anche solo uno dei 5 manca → **resta sulla conservativa**, è
+quella che il sistema parte ad eseguire.
+
+---
+
+## 5. Come leggere il dato giorno per giorno
+
+Tre euristiche operative sui campi raccolti:
+
+1. **Premio "ricco":** `iv_minus_rv` consistentemente > 5 punti per
+   N giorni → il regime sta pagando bene la vendita di vol. Sono i
+   periodi in cui la strategia ha edge maggiore.
+2. **Premio "magro":** `dvol < 35` per più giorni → la finestra del
+   lunedì viene saltata. Non è un fallimento: è la disciplina che
+   funziona.
+3. **Stress imminente:** `liquidation_*_risk = high` o spike di
+   `oi_delta_pct_4h` (> 5% in valore assoluto) + funding ai limiti
+   → atteso vol stop / time stop attivi nei prossimi cicli, anche
+   se la posizione è in profit.
+
+Nei giorni di **eventi macro** (`macro_days_to_event` piccolo) la
+combinazione utile è: aspettare l'evento, lasciare che `dvol` scenda
+quando `realized_vol_30d` non si è realizzata, e cogliere il setup
+classico **post-evento**.
+
+---
+
+## 6. Glossario rapido
+
+- **Credit spread:** vendita di un'opzione e acquisto di un'opzione
+  più OTM stessa scadenza per cap del rischio. Si incassa un credito,
+  si vince se il sottostante non rompe lo strike short.
+- **Bull put / Bear call:** credit spread direzionali (rispettivamente
+  bullish / bearish).
+- **Iron condor:** Bull put + bear call sullo stesso sottostante e
+  scadenza. Si vince in regime laterale.
+- **DVOL:** indice Deribit della IV ETM 30g, scala 0–200.
+- **Realized vol 30g:** σ annualizzata dei rendimenti spot sui 30g
+  rolling.
+- **IV − RV:** differenza tra IV implicita (DVOL) e RV; > 0 = "premio"
+  positivo per il venditore di vol.
+- **Funding annualizzato:** funding rate del perp moltiplicato per le
+  finestre standard (di solito 8h × 3 al giorno × 365).
+- **Dealer net gamma:** somma di gamma per tutti gli strike, pesata
+  per direzione dei dealer (long = riduce vol, short = amplifica).
+- **OI delta % 4h:** variazione % dell'open interest aggregato nelle
+  ultime 4 ore.
+- **DTE:** Days To Expiry, giorni alla scadenza dell'opzione.
+- **Kill switch:** flag persistente che blocca apertura di nuove
+  posizioni; armato automaticamente su mismatch ambiente o failure
+  ripetuti, disarmato solo manualmente con motivazione.
+
+---
+
+## 7. Riferimenti incrociati
+
+- Regole canoniche e immutabili: `01-strategy-rules.md`
+- Schema dati persistente: `05-data-model.md`
+- Algoritmi (calcolo trend, IV−RV, ecc.): `03-algorithms.md`
+- Dettaglio integrazioni MCP: `04-mcp-integration.md`
+- Pagina GUI di calibrazione: `📐 Calibrazione`
+- Sorgente del collector: `src/cerbero_bite/runtime/market_snapshot_cycle.py`
+- Modello pydantic riga: `cerbero_bite.state.models.MarketSnapshotRecord`