root
4ab7590745
Aggiunge il filtro a maggior impatto sul win-rate atteso: l'entry
salta se la IV implicita non sta pagando un margine misurabile sopra
la realized vol. La letteratura short-vol systematic indica che
l'edge sostenibile della strategia esiste solo quando IV30g − RV30g
supera una soglia di alcuni punti vol; senza questo gate il selling
vol nudo è strutturalmente neutro a win-rate 70-72%.
Implementazione end-to-end:
- `EntryConfig`: due nuovi campi `iv_minus_rv_min` e
`iv_minus_rv_filter_enabled`, con default `0` / `false` per non
rompere setup pre-calibrazione.
- `validate_entry`: §2.9 hard gate che blocca l'entry se
`iv_minus_rv < iv_minus_rv_min` (skip silenzioso quando il dato è
`None`, coerente con il pattern §2.8 dei filtri quant).
- `entry_cycle._gather_snapshot`: nuovo `_safe_iv_minus_rv` che
legge `deribit.realized_vol("ETH")["iv_minus_rv_30d"]` in
best-effort e lo propaga via `_MarketSnapshot.iv_minus_rv` →
`EntryContext.iv_minus_rv` → audit `inputs.snapshot.iv_minus_rv`.
- `tests/unit/test_entry_validator.py`: 5 nuovi casi (default
permissivo, gate sotto/sopra/uguale soglia, dato mancante).
- `tests/integration/test_entry_cycle.py`: stub `get_realized_vol`
nel mock helper così tutti gli scenari di happy/edge path
continuano a passare.
Configurazione di profili coerente con la disciplina:
- `strategy.yaml` (golden 1.1.0) e `strategy.conservativa.yaml`:
gate `enabled=false, min=0`. Manteniamo i lunedì pre-calibrazione
per accumulare dati sulla distribuzione di `iv_minus_rv`.
- `strategy.aggressiva.yaml` (1.1.0-aggressiva): gate
`enabled=true, min=3`. Coerente con la filosofia del profilo —
size più grande pretende win-rate più alto. La soglia 3 è
conservativa; la documentazione raccomanda 5 dopo 4-8 settimane di
calibrazione.
Doc + GUI:
- `docs/13-strategia-spiegata.md` §4-quater: spiega gate, parametri,
default per profilo, effetto atteso sul P/L (trade/anno scendono
ma E[trade] sale → APR cresce comunque), roadmap di hardening
(soglia adattiva, vol-of-vol guard, multi-asset).
- pagina `📚 Strategia`: la riga "IV − RV" passa da informativa a
pass/fail reale; mostra "filtro DISABILITATO (info-only)" quando
spento, ✅/❌ contro la soglia di config quando acceso.
Bump versioni e hash di tutti e tre i file YAML
(`config_version: 1.1.0`, hash ricalcolato). Test pinning aggiornato
(`test_load_repo_strategy_yaml`).
Suite: 410 passed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Cerbero Bite
Sistema deterministico rule-based per l'esecuzione sistematica della strategia Cerberus Bite: credit spread su opzioni Ethereum (Deribit) con gestione attiva, sizing Quarter Kelly e disciplina di uscita rigida.
Sintesi della strategia
- Sottostante: ETH/USD su Deribit (opzioni europee).
- Struttura: Bull Put Spread (modalità principale) o Bear Call Spread, vendita di credito a delta corto 0.10–0.15 (≈ 18% OTM).
- DTE: 14–21 giorni, sweet spot a 18 DTE.
- Sizing: Quarter Kelly = 13% del capitale corrente, con cap hard 200 EUR per trade e 1.000 EUR di engagement aperto totale.
- Gestione attiva: profit take 50% credito, stop loss 1.5× credito, vol stop +10 punti DVOL, time stop 7 DTE, exit su short strike testato (|delta| ≥ 0.30). Su ETH non si difende rollando: si esce.
- Frequenza: apertura ogni 7 giorni, una posizione alla volta.
Il sistema è deterministico: nessun LLM partecipa al decision loop. Le regole sono codificate, le soglie sono parametri di configurazione, i tool MCP sono usati esclusivamente come fonti di dati e canali di esecuzione (proposta verso Cerbero core, notifiche verso Adriano).
Catena di responsabilità
Cerbero Bite (rule engine) → Adriano (decisione finale) → Cerbero core (esecuzione)
- Cerbero Bite propone trade e segnala uscite. Non esegue mai direttamente sul broker.
- Adriano riceve un report strutturato e dà conferma esplicita.
- Cerbero core riceve l'istruzione tramite
cerbero-memory.push_user_instructionconsource="cerbero-bite"e ne pianifica l'apertura/chiusura sul proprio motore di esecuzione.
Documentazione
I documenti di progetto si trovano sotto docs/. Sono numerati e da
leggere in ordine per chi implementa.
| File | Contenuto |
|---|---|
docs/00-overview.md |
Visione del sistema, perimetro, non-obiettivi |
docs/01-strategy-rules.md |
Regole della strategia (entry/manage/exit) |
docs/02-architecture.md |
Architettura software, componenti, interfacce |
docs/03-algorithms.md |
Specifiche dettagliate dei sette algoritmi core |
docs/04-mcp-integration.md |
Mappa dei tool MCP usati e contratti |
docs/05-data-model.md |
Schema persistenza posizioni, log, KB |
docs/06-operational-flow.md |
Flussi operativi: avvio, settimanale, monitoring |
docs/07-risk-controls.md |
Kill switch, cap, dead-man, audit |
docs/08-testing-validation.md |
TDD, paper trading, golden tests |
docs/09-development-roadmap.md |
Fasi di sviluppo e milestone |
docs/10-config-spec.md |
Schema di strategy.yaml con soglie |
docs/11-gui-streamlit.md |
Dashboard Streamlit locale per osservazione e azioni manuali |
Stato attuale
Il progetto è in fase specifica. Nessun codice è stato ancora
prodotto; tutta la documentazione di design è quella presente nella
cartella docs/. La prima fase di implementazione è dettagliata in
docs/09-development-roadmap.md.
Avvertenza
Questo sistema gestisce capitale reale ed è soggetto alle Hard
Prohibitions di Cerbero (vedi Cerbero_Office/CLAUDE.md). Le opzioni
su criptovaluta sono strumenti complessi con rischio di perdita totale.
La validazione statistica via Monte Carlo (Cerbero_Office/NewStrategy/ analisi_dai_storici/) è uno stimatore, non una garanzia. Le regole di
stop loss e i cap di sizing sono non negoziabili.