root
c0a0ee416f
Aggiunge la persistence della option chain Deribit con cron settimanale ``55 13 * * MON`` (5 minuti prima del trigger entry alle 14:00 UTC), sbloccando il backtest non-stilizzato e la calibrazione empirica dello skew premium. **Schema (migrazione 0004)** Nuova tabella ``option_chain_snapshots`` con primary key composta ``(timestamp, instrument_name)`` — tutti i quote prelevati nello stesso tick condividono il timestamp, così le query "lo snapshot del 2026-05-04 alle 13:55" diventano una singola WHERE timestamp = X. Indici su (asset, timestamp DESC) e (asset, expiry) per supportare sia listing recenti sia query per scadenza specifica. Campi: instrument_name, strike, expiry, option_type (C/P), bid, ask, mid, iv, delta, gamma, theta, vega, open_interest, volume_24h, book_depth_top3. Tutti i numerici sono nullable: il collector è best-effort, un ticker mancante produce comunque una riga (utile per sapere che lo strumento esisteva ma non era quotato). **Modello + repository** - ``OptionChainQuoteRecord`` (Pydantic, in ``state/models.py``). - ``Repository.record_option_chain_snapshot`` (bulk insert idempotente). - ``Repository.list_option_chain_snapshots`` (filtri su asset, timestamp window, expiry window, limit default 50000). - ``Repository.latest_option_chain_timestamp`` (freshness check per dashboard GUI). **Collector** Nuovo ``runtime/option_chain_snapshot_cycle.py`` che: 1. Calcola la finestra scadenze ``[now+dte_min, now+dte_max]`` da ``cfg.structure``: niente richieste su scadenze che il rule engine non userebbe mai. 2. Chiama ``deribit.options_chain()`` con ``min_open_interest=cfg.liquidity.open_interest_min``. 3. Batch ``deribit.get_tickers()`` (max 20 per call, limite Deribit) con error-isolation per batch — un batch fallito non blocca gli altri. 4. NON chiama l'order book per ogni strike (rate-limit guard); ``book_depth_top3`` resta NULL e il liquidity gate live lo chiede on-the-fly per gli strike candidati al picker. Best-effort end-to-end: chain assente, get_tickers giù, persist fallito → ritorna 0 senza alzare eccezioni, logga sempre. **Schedulazione** Wired in ``Orchestrator.install_scheduler`` come job parallelo a ``market_snapshot``, attivo solo quando ``ENABLE_DATA_ANALYSIS=true``. Cron parametrizzabile via il nuovo kwarg ``option_chain_cron`` (default ``55 13 * * MON``). **Test** - 4 unit test del collector (happy path, ticker mancante, chain vuota, fetch fail best-effort) con mock di RuntimeContext. - Aggiornato ``test_install_scheduler_registers_canonical_jobs`` per includere il nuovo job nel set canonico. **Cosa sblocca** - Backtest non-stilizzato: il PR ``feat/backtest-engine`` può dropparsi il modello BS+skew_premium e leggere prezzi reali ``mid`` dalla chain registrata. - Calibrazione empirica dello skew premium (hardcoded a 1.5 nel backtest stilizzato): plot del rapporto fra quote reali Deribit e BS per delta/expiry, regressione → valore data-driven. - Validazione ex-post: "il delta-0.12 era davvero a 25% OTM in quella settimana?" diventa una query SELECT. - Dimensione attesa: ~50 strike × 3 scadenze × 1 snapshot/settimana × 17 colonne ≈ 12 KB/settimana, ~600 KB/anno. Trascurabile. Suite: 409 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.