Adriano
067f74bc89
Conclude il doc drift residuo dei tre documenti che ancora descrivevano il modello di esercizio pre-Fase 4 (memory/brain-bridge, push_user_instruction, conferma manuale). Aggiornati per riflettere l'engine autonomo notify-only attuale, con tutti gli ultimi hardening integrati. docs/02-architecture.md: - Diagramma a blocchi: rimosso cerbero-memory ↔ Cerbero core, aggiunto annotation sull'audit chain con anchor SQLite. - Tabella stack: httpx pooling al posto dell'SDK mcp, hash chain con anchor in system_state. - Layout cartelle: aggiunte runtime/lockfile.py, runtime/orchestrator.py, runtime/recovery.py, scripts/dead_man.sh, state/migrations/0002_audit_anchor.sql. - Sequenze entry/monitor riscritte all'auto-execute via place_combo_order, niente attesa conferma utente. - Nuova sezione "Lifecycle del container" con boot order, scheduler, SIGTERM clean shutdown, lock release. - Failure modes aggiornati: environment mismatch, audit anchor mismatch, lock occupato. docs/05-data-model.md: - Filosofia estesa con la regola dell'audit chain e l'anchor. - Schema instructions: payload_json riferito ai response Deribit (combo_instrument, order_id, state) invece di push_user_instruction. - Aggiunta migration 0002_audit_anchor.sql con last_audit_hash. - Schema log JSONL: campi cycle e cycle_id propagati da structlog.contextvars. - Sezione "Audit log" descrive il formato concretamente in uso (separatori | con prev_hash/hash) ed elenco eventi reali (ENGINE_START, RECOVERY_DONE, ENTRY_PLACED, HOLD, EXIT_FILLED, KILL_SWITCH_*, ALERT, KELLY_RECALIBRATED). - Sezione backup riferita allo job APScheduler ora schedulato (0 * * * *). docs/07-risk-controls.md: - Nuova tabella trigger automatici allineata al codice (column "Implementato" punta ai moduli runtime/safety reali). - Sezione "Single-instance lock" introdotta (fcntl.flock, EngineLock, caveat multi-host). - Sezione "Anti-truncation" che descrive il flusso anchor: callback on_append → SQLite → check al boot. - "Cap di rischio" estesa con i due nuovi filter dealer-gamma e liquidation-heatmap (§2.8). - Sezione "Versionamento config" cita execution.environment, execution.eur_to_usd, dealer_gamma_min, dealer_gamma_filter_enabled, liquidation_filter_enabled. - Escalation tree concretizzata sull'AlertManager con i metodi reali (low/medium/high/critical). Test: 335 pass, 1 skip (sqlite3 CLI). 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.