Files

T

root 6ff021fbf4 feat(strategy): abbandono gating settimanale — entry daily 24/7

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>

2026-05-03 16:21:16 +00:00

8.9 KiB

Raw Blame History

09 — Development Roadmap

Sviluppo per fasi, ognuna con obiettivo chiaro, criteri di completamento e dipendenze. La sequenza è stretta: ogni fase aggiunge valore e si costruisce sulla precedente.

Fase 0 — Setup (3-5 giorni)

Obiettivo: scheletro di progetto eseguibile, niente logica di business.

Tasks:

git init + branch main + .gitignore (esclude data/, .lockfile, *.local.yaml).
pyproject.toml con uv, deps base: pydantic, sqlalchemy, apscheduler, mcp, rich (CLI), pytest, mypy, ruff.
Layout cartelle come da 02-architecture.md.
Logger strutturato con structlog, output JSONL su file.
__main__.py con CLI Click: comandi start, stop, status, dry-run, kill-switch, replay.
Pre-commit hooks installati.
tests/conftest.py con fixtures di base.
Hello-world test che valida l'avvio dell'engine senza nessun tool MCP reale (tutti fake).

Definition of Done:

uv run cerbero-bite status stampa "engine idle, kill_switch=0"
uv run pytest passa con almeno 5 test triviali
mypy --strict src/ passa
Repository committato

Fase 1 — Core algorithms (7-10 giorni)

Obiettivo: i 7 algoritmi puri implementati, con test al 100%.

Tasks (ordine TDD):

entry_validator.validate_entry + compute_bias
liquidity_gate.check
sizing_engine.compute_contracts
combo_builder.select_strikes + build
greeks_aggregator.aggregate
exit_decision.evaluate (questo è il più complesso, due giornate dedicate)
kelly_recalibration.recalibrate

Per ogni modulo:

scrivere test che falliscono
implementare la versione minima che li passa
aggiungere property test con hypothesis
code review (skill superpowers:requesting-code-review)

Definition of Done:

100% statement+branch coverage su core/
Property test per ogni invariante documentata
0 errori mypy --strict
Tutti i test obbligatori in 08-testing-validation.md presenti

Fase 2 — Persistenza e safety (5-7 giorni)

Obiettivo: state machine + risk control implementati.

Tasks:

Schema SQLite + migration 0001
state/repository.py con CRUD typed
Audit log con hash chain
safety/kill_switch.py con tutti i trigger automatici
safety/dead_man.sh script shell separato
Backup utility + retention policy
CLI audit verify, kill-switch arm/disarm, state inspect

Definition of Done:

Coverage state/ ≥ 90%, safety/ 100%
Test di corruzione SQLite e hash chain passano
Recovery test: kill engine mid-write, restart, stato consistente

Fase 3 — MCP clients (4-6 giorni)

Obiettivo: wrapper tipizzati per tutti i server MCP usati.

Tasks (parallelizzabili tra collaboratori se ci fossero):

clients/_base.py: McpClient abstract + retry/timeout
clients/deribit.py con tutti i metodi documentati
clients/hyperliquid.py
clients/macro.py
clients/sentiment.py
clients/portfolio.py
clients/memory.py
clients/telegram.py (anche listener webhook per conferme)
clients/brain_bridge.py

Per ogni client: fake corrispondente in tests/fixtures/fakes/.

Definition of Done:

Coverage clients/ ≥ 80%
Fake test scenari happy/timeout/anomaly per ognuno
cerbero-bite ping lista lo stato di ogni MCP

Fase 4 — Orchestrator e flussi (5-7 giorni)

Obiettivo: i flussi di 06-operational-flow.md cablati.

Tasks:

runtime/orchestrator.py — composizione core + clients + state
runtime/scheduler.py — APScheduler con i cron documentati
runtime/monitoring.py — loop ogni 12h
runtime/alert_manager.py — escalation policy

Test integration su scenari completi (vedi 08-testing-validation.md):

daily open happy path
monitor profit take
monitor vol stop
recovery dopo crash
kill switch blocca entry

Definition of Done:

Tutti gli integration test passano
Engine può girare in --dry-run per 24h senza errori
I log sono leggibili e completi

Fase 4.5 — GUI Streamlit (4 giorni) ✅ implementata

Obiettivo: dashboard locale per osservazione e azioni manuali. Spec dettagliata in 11-gui-streamlit.md.

Implementata in quattro round (A–D):

✅ gui/main.py + sidebar nav (auto-refresh attivo non cablato; il re-render Streamlit è sufficiente per la frequenza tipica)
✅ Pagina Status (engine state, kill switch panel con typed confirmation, audit anchor, open positions)
✅ Pagina Equity (cumulative P&L, drawdown, P&L distribution per close reason, per-month stats)
✅ Pagina Position (legs from entry snapshot, payoff plotly per bull_put/bear_call con annotazioni, decision history) — greche live e force-close differiti
✅ Pagina History (filtri window/reason/winners-losers, KPI strip, CSV export)
✅ Pagina Audit (live log stream, chain verify, event filter)
✅ Consumer runtime/manual_actions_consumer.py con job APScheduler */1 per arm/disarm (force_close = not_supported per ora)
⏳ Test integration con streamlit.testing.v1.AppTest

Definition of Done — stato:

✅ cerbero-bite gui lancia la dashboard su 127.0.0.1:8765
✅ Tutte le 5 pagine raggiungibili e popolate
✅ Disarm da GUI loggato in audit chain (source="manual_gui") ed effettivo entro ~1 minuto
⏳ Force-close da GUI: l'enqueue funziona ma l'orchestrator deve ancora esporre handle_force_close
⏳ Test integration AppTest: non scritti

Fase 5 — Reporting e UX (3-5 giorni)

Obiettivo: report Telegram puliti, daily digest, replay command.

Tasks:

reporting/pre_trade.py — testo Markdown con sezioni
reporting/exit_proposal.py
reporting/daily_digest.py
reporting/monthly_report.py
CLI cerbero-bite replay per backtest
CLI cerbero-bite recalibrate-kelly --dry-run

Definition of Done:

Tre messaggi Telegram esempio committati come fixtures
Replay command funziona su 30 giorni di dati storici simulati

Fase 6 — Golden tests e backtest (3-4 giorni)

Obiettivo: suite di scenari golden + replay storico.

Tasks:

Almeno 10 scenari golden coprenti tutti i path principali
Storia ETH spot + DVOL caricata da CSV in tests/data/historical/
Confronto P&L replay vs simulazione Monte Carlo del documento

Definition of Done:

Replay 2024-01 → 2026-04 senza errori
Equity curve riprodotta con stesso seed numerico
Differenza con MC entro intervalli attesi

Fase 7 — Paper trading (90 giorni)

Obiettivo: validazione su segnali reali ma niente capitale.

Setup:

Engine live in --dry-run
Telegram alert reali
Adriano replica trade su testnet Deribit o paper book per misurare slippage reale

Metriche da raccogliere:

Numero proposte giornaliere emesse
Quante passano i filtri
Win rate, avg P&L paper
Discrepanze tra mid stimato e fill reale (slippage)
Errori di sistema, kill switch armati

Definition of Done:

≥ 30 trade paper concluso
0 errori critici
Win rate ≥ 70% (paper ETH credit spread baseline atteso)
Sign-off Adriano via audit chain

Fase 8 — Soft launch (30 giorni live, cap dimezzato)

Obiettivo: primi trade reali con capitale ridotto.

Setup:

Cap 100 EUR per trade, 500 EUR engagement totale
Solo Bull Put Spread (no IC) per ridurre superficie di rischio
Daily digest manuale ogni mattina con Adriano

Metriche di passaggio a full:

≥ 10 trade reali conclusi
P&L coerente con Monte Carlo (entro 1 sigma)
0 incidenti operativi
Spread fill mediano ≤ 5% slippage rispetto al mid stimato

Fase 9 — Full launch

Obiettivo: operatività regime.

Cap pieno: 200 EUR per trade, 1.000 EUR engagement
Iron Condor abilitato (regime laterale)
Mensile review Kelly + report Brain-Bridge
Ogni 6 mesi review completa con Milito

Roadmap futura (post-launch, idee)

Sottostante BTC: stessa strategia, parametri ricalibrati. Richiede fase di paper-trading dedicata.
Multi-exchange execution: alternativa a Deribit (Bybit options, Binance options) per ridurre counterparty risk.
Dashboard locale: pagina HTML statica generata dai log per visualizzare equity curve e trade list senza tool esterni.
Auto Kelly update: dopo 100 trade reali, valutare l'auto-update con sand-box di review Milito.
Promozione MCP options-engine: estrarre core/ come server MCP dedicato, riusabile da Cerbero core stesso e da Milito.

Stima cumulativa

Fase	Giorni di lavoro	Calendar (con review)
0 — Setup	3-5	1 settimana
1 — Core	7-10	2 settimane
2 — State & Safety	5-7	1.5 settimane
3 — Clients	4-6	1 settimana
4 — Orchestrator	5-7	1.5 settimane
4.5 — GUI Streamlit	4	1 settimana
5 — Reporting	3-5	1 settimana
6 — Golden + Backtest	3-4	1 settimana
Totale fino a paper-ready	34-48	~10 settimane
7 — Paper trading	—	12-13 settimane
8 — Soft launch	—	4-5 settimane
9 — Full launch	—	ongoing

Tempo a regime: ~6 mesi dal kickoff.

8.9 KiB Raw Blame History Unescape Escape

09 — Development Roadmap

Fase 0 — Setup (3-5 giorni)

Fase 1 — Core algorithms (7-10 giorni)

Fase 2 — Persistenza e safety (5-7 giorni)

Fase 3 — MCP clients (4-6 giorni)

Fase 4 — Orchestrator e flussi (5-7 giorni)

Fase 4.5 — GUI Streamlit (4 giorni) ✅ implementata

Fase 5 — Reporting e UX (3-5 giorni)

Fase 6 — Golden tests e backtest (3-4 giorni)

Fase 7 — Paper trading (90 giorni)

Fase 8 — Soft launch (30 giorni live, cap dimezzato)

Fase 9 — Full launch

Roadmap futura (post-launch, idee)

Stima cumulativa

8.9 KiB

Raw Blame History