root
6ff021fbf4
Crypto opera 24/7: la cadenza settimanale lunedì-only era un retaggio TradFi senza giustificazione. La nuova cadenza è giornaliera (cron 0 14 * * *), con i gate quantitativi a decidere se entrare o saltare. Cambiamenti principali: * runtime/orchestrator.py — _CRON_ENTRY 0 14 * * * (era MON) * runtime/auto_pause.py — pause_until(days=) (era weeks=); minimo clamp 1 giorno (era 1 settimana) * core/backtest.py — MondayPick→DailyPick, monday_picks→daily_picks (1 pick per calendar-day all'ora target); Sharpe annualization su ~120 trade/anno (era 52) * config/schema.py — default cron daily; max_concurrent_positions 1→5; AutoPauseConfig.pause_weeks→pause_days, default 14 * runtime/option_chain_snapshot_cycle.py + orchestrator — cron */15 per accumulo continuo dataset di backtest empirico Strategy yamls (config_version 1.3.0 → 1.4.0, hash rigenerati): * strategy.yaml — max_concurrent 1→5, cap_aggregate coerente * strategy.aggressiva.yaml — max_concurrent 2→8, cap_aggregate 3200→6400, max_contracts_per_trade invariato a 16 * strategy.conservativa.yaml — max_concurrent 1→3 * tutti — pause_weeks→pause_days: 14 GUI (pages/7_📚_Strategia.py): * slider Trade/anno: range 20-200 (era 8-30), default 110, help riallineato sulla math 365 candidature × pass-rate 30-40% * card profili: versione letta dinamicamente da config_version invece che hard-coded "v1.2.0" * warning "entrambi perdono soldi" ora valuta i P/L effettivi (cons['annual_pl'], aggr['annual_pl']) invece del win_rate grezzo; aggiunto stato intermedio quando solo conservativo è in perdita Tests (450/450 passati): * test_auto_pause: pause_days, clamp ≥1 giorno * test_backtest: rinomina + ridisegno daily picks (assert su calendar-day dedupe e hour filter) * test_sizing_engine: other_open_positions=5 per cap default * test_config_loader: version 1.4.0 Docs (README + 9 file in docs/) — tutti i riferimenti weekly/lunedì allineati a daily/24-7, volume option_chain ricalcolato per cron */15 (~1.1 MB/giorno, ~400 MB/anno). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
76 lines
3.5 KiB
Markdown
76 lines
3.5 KiB
Markdown
# 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:** candidatura giornaliera (cron `0 14 * * *`, crypto è 24/7),
|
||
fino a **5 posizioni concorrenti** sul profilo principale (3 sul
|
||
conservativo, 8 sull'aggressivo). I gate quantitativi decidono se entrare;
|
||
nei giorni in cui falliscono, niente trade.
|
||
|
||
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_instruction`
|
||
con `source="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, entry daily, 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**.
|