research_collector.enabled false -> true: il collettore full-chain
gira ora orario (cron 0 * * * *), catturando tutte le scadenze <=95g
ed entrambe le ali con book_depth_top3 popolato. config_version
1.7.0 -> 1.7.1, config_hash rigenerato.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- option_chain_research_cycle: parametro force=True bypassa il gate
enabled, per testare la raccolta prima di accendere il cron.
- CLI `option-chain research-trigger`: esegue UNA volta il collector
full-chain (source='research', book_depth popolato), come il gemello
`trigger` per il collettore live.
Verificato: 324 quote ETH su 7 scadenze (DTE 1..80), book_depth su tutte.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Allinea la documentazione alle modifiche di v1.7.0.
- 01-strategy-rules: §3.2 delta short 0.18 (banda 0.12-0.22, OTM>=10%)
con la motivazione dell'analisi (credit/width ~6% irraggiungibile a
delta basso); delta_by_dvol aggressiva ritarata; §3.3 width fino a 6%
(griglia strike 100pt); §3.4 credit/width min 30% -> 8%.
- 05-data-model: option_chain_snapshots alimentata da due collettori
(live/research) via colonna source; CREATE TABLE + indice aggiornati;
book_depth_top3 popolato sulle righe research; migrazioni 6 e 7 in
tabella; backup orario -> giornaliero con nota storica.
- 10-config-spec: valori structure profilo B + nuovo blocco
research_collector.
- 06-operational-flow: cron summary con i due collettori opzioni.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Il backup faceva uno snapshot full del DB ogni ora: ~16GB accumulati per
~98MB di dato unico (218k righe option_chain ricopiate ~337 volte), con
retention 30g. Porta il cron a giornaliero (0 0 * * *): -24x lo spazio a
parita' di retention. Rilevante prima di accendere il collettore research
(che 2-4x la crescita del DB e quindi dei backup).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Due modifiche di config, raggruppate perche' condividono i file YAML e il
config_hash (rigenerato sullo stato finale di ciascun profilo).
1) Profilo B credit-spread. L'analisi su 3.689 snapshot (1mag-8giu) mostra che
con delta short 0.10-0.15 il miglior credit/width fisicamente ottenibile e'
~6%, quindi credit_to_width_ratio_min=0.30 era irraggiungibile: 0 spread
fattibili. La sola leva efficace e' vendere piu' vicino.
- short_strike: delta 0.12-0.22 (target 0.18), distance_otm_pct_min 0.10
- spread_width.max_pct_of_spot 0.05 -> 0.06 (la griglia strike ETH a 100pt
sotto i $1500 e' ~6% a spot <$2k: con cap 5% nessuna gamba long in banda)
- credit_to_width_ratio_min 0.30 -> 0.08 (allineato al realizzabile)
- aggressiva: ritarata anche la delta_by_dvol step-function
Atteso: ~1,5 trade/mese (tetto dato da posizione-singola + tenuta 18g).
Nota rischio: delta ~0.18-0.22 alza la prob. di assegnazione da ~12% a ~18-22%.
2) Blocco research_collector in entrambi i profili (enabled=false, opt-in):
wiring del collettore full-chain introdotto nel commit precedente.
config_version 1.6.0 -> 1.7.0 (conservativo), 1.4.0 -> 1.5.0-aggressiva;
config_hash rigenerato e verificato stabile su entrambi.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Aggiunge un secondo collettore opzioni indipendente dal live, pensato per
trasformare il dataset da "skew/premi medi" a backtest opzioni vero
(per-trade e standing put).
- option_chain_research_cycle.py: cattura tutte le scadenze <= expiry_max_days
(1g..3mesi) ed entrambe le ali (OI>=100, filtro moneyness opzionale),
popolando book_depth_top3 via orderbook_depth_top3 (concorrenza limitata)
cosi' lo slippage reale e' modellabile. Best-effort come il collettore live.
- migrazione 0007: colonna `source` su option_chain_snapshots ('live' default
per le righe storiche, 'research' per il nuovo collettore) + indice
(asset, source, timestamp). user_version 6 -> 7.
- ResearchCollectorConfig (schema): blocco `research_collector`, enabled=false
di default (costo API non trascurabile); cron orario, expiry_max_days=95.
- orchestrator: job `option_chain_research` schedulato solo se data-analysis
attiva E research_collector.enabled.
- repository: insert+mapper estesi con `source`; list_option_chain_snapshots
accetta un filtro `source` per le query di backtest.
Verificato in isolamento (immagine + interprete reali): import, migrazione,
round-trip repo. Suite: 527 passed, zero regressioni vs baseline pristina.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Niente aggiornamenti automatici dell'immagine per un bot di trading:
i deploy devono essere deliberati (build + up manuali), non innescati
da un push del registry.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Aggiornamenti post-incidente 31/05 (kill switch armato 6 giorni da un
singolo McpTimeoutError transitorio) e post-ripristino 05/06:
- 07: tabella trigger — documentato orchestrator._safe (qualsiasi
eccezione di tick → arm CRITICAL al primo errore) e la tolleranza
al lag benigno dell'anchor (647e3e5)
- 07: sezione Disarm — percorso raccomandato via coda manual_actions
a engine acceso; CLI solo a engine fermo (race CLI<->engine = gap
permanente nella hash chain)
- 07: nuova sezione "Limiti noti" — vincolo single-writer e i 7 gap
storici benigni del log di produzione (01/05 e 29/05); audit verify
full-chain fallisce alla riga 11 by design
- 06: nota in Flusso 5 — la tolleranza "3 fallimenti" vale solo per i
probe health, _safe arma al primo errore su ogni altro tick
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
L'anchor dell'audit (system_state.last_audit_hash) e' persistito best-effort:
sotto contesa di lock SQLite il mirror puo' restare indietro rispetto al log,
che invece cresce in avanti integro. Il check di boot armava il kill-switch
su qualsiasi disuguaglianza anchor!=coda, scambiando questo lag per
manomissione.
- audit_log: nuova tail_continues_from() — True solo se l'anchor e' un
antenato valido della coda (presente in catena + chain forward integra a EOF)
- orchestrator._verify_audit_anchor: se lag benigno -> re-sync anchor + warning;
solo anchor assente o chain rotta (troncamento/tamper) -> critical -> arma
Verificato live: anchor in ritardo -> re-sync senza armare; anchor bogus -> arma.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Il gate macro riusava structure.dte_target (18g) per decidere entro quanti
giorni un evento high-severity blocca l'entrata, accoppiando la protezione
di rischio-evento alla scelta delle scadenze opzioni. Disaccoppiato con un
parametro dedicato.
- schema: nuovo entry.exclude_macro_within_days (default 18 = comportamento storico)
- entry_validator: il gate macro usa il nuovo campo; rimosso structure_cfg inutilizzato
- entry_cycle: la fetch del calendario macro guarda avanti exclude_macro_within_days giorni
- strategy.yaml: exclude_macro_within_days=1, config_version 1.5.0->1.6.0, hash rigenerato
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cerbero MCP V2 ha spostato get_instruments/get_historical/get_indicators
sul router unificato /mcp (rimossi dagli endpoint per-exchange) e ha
rinominato get_technical_indicators in get_indicators. Il client chiamava
ancora questi tool su /mcp-deribit -> 404 -> kill-switch armato, raccolta
option-chain ferma e bias direzionale rotto.
- mcp_endpoints: nuovo endpoint `unified` (CERBERO_BITE_MCP_UNIFIED_URL,
default http://cerbero-mcp:9000/mcp)
- deribit: i 3 tool dati passano dal client unificato con exchange="deribit",
interval minuscolo (1D->1d) e parsing del nuovo shape (symbol + native.*);
adx_14 usa get_indicators (indicators.adx.adx)
- dependencies/gui: iniettano il client unificato in DeribitClient
- docker-compose: default in-cluster per l'endpoint /mcp
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nuovo campo ChainAuditReport.ask_zero_count. La logica del loop
parsifica prima l'ask: se ask<=0 è "missing ask side" (su Deribit
significa nessun ordine in vendita), conta in ask_zero_count e non
applica il check bid>ask. Solo con ask>0 si confronta con bid.
Sul DB prod gli "bid>ask" del primo audit (27 ETH + 10 BTC negli
ultimi 7d) erano tutti falsi positivi con ask=0 — concentrati sulla
weekly 2026-05-29, OI alti ma volume basso. Dopo il fix: bid>ask=0,
ask<=0=83 ETH + 13 BTC.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Allinea la spec all'implementazione: dataclass ChainAuditReport senza
depth_zero_pct, tabella checks senza la riga book_depth_top3=0, output
example senza la riga depth_top3. Aggiunta nota che spiega perché il
check è stato rimosso (colonna popolata solo dal path entry_cycle).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Riflette la struttura effettiva del CLI: il group 'audit' contiene già
'verify' per la hash chain; il data-quality audit è entrato come
sibling 'data'. Documentata la deviazione in linea.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Usa il group 'audit' esistente (sibling di 'audit verify' per la hash
chain). Opzioni: --db, --since DAYS, --asset ETH|BTC, --json.
Output stdout Rich di default, dump JSON con --json. Esce con codice 2
su sqlite3.OperationalError (DB malformato/schema mancante).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Implementa la funzione dichiarata in __all__ ma mancante. Helper _pct
usa statistics.quantiles(method="inclusive") con fallback per len<=1.
Niente check su book_depth_top3: per design è NULL sugli snapshot
(popolato solo da entry_cycle per gli strike candidati al picker).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
book_depth_top3 è popolato solo dal path entry_cycle (per gli strike
candidati al picker), mai dal collector option_chain_snapshot — il
controllo depth_zero su questi snapshot sarebbe strutturalmente 100%.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Il piano originale aveva `floor(span/15) + 1` che over-conta a span allineati
(span=60min → 5 invece di 4). Il primo fix dell'implementer (`floor(span/15)`)
under-conta a span non-allineati (span=16min → 1 invece di 2). Solo
`ceil(span/15)` è corretto in entrambi i casi. Aggiunti 2 test che
coprono gli scenari non-allineato e boundary-esatto per impedire
regressioni. Plan doc allineato.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Piano dettagliato task-by-task per `cerbero-bite audit`:
analysis/data_audit.py (helper puri + dataclass), CLI subcommand,
test unit + smoke test, end-to-end su DB produzione. Ogni task ha
i suoi step TDD con codice completo, comandi e commit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Migration 0006 promuove dvol_history da PK=(timestamp) mono-ETH a
PK=(timestamp, asset), rinomina eth_spot -> spot, e backfilla con
asset='ETH' le righe storiche. market_snapshot_cycle ora scrive sia
per ETH che per BTC; monitor_cycle resta ETH-only via WHERE asset='ETH'
nella lookup di return_4h.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Directory creata localmente dall'infrastruttura OMC per stato sessione
(project-memory.json, research/, sessions/, state/). Non è artefatto
del progetto cerbero-bite.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pannello "P/L atteso — Conservativa vs Aggressiva":
* Sostituiti slider Capitale/Spot con slider parametrici Cap/trade
(EUR) + posizioni concorrenti. Il capitale richiesto viene calcolato
in automatico via Kelly-binding aggregato:
capital = cap_pertrade_usd × concorrenza / max(kelly, 1e-3).
* Profili Conservativa/Aggressiva ora ereditano dai yaml SOLO le leve
qualitative (width_pct, credit_ratio, kelly_fraction, feature
attive); le leve di sizing (cap, concorrenza) sono comandate dagli
slider per confronti omogenei.
* Tre metriche header: capitale richiesto, cap aggregato notional,
cap per trade USD.
Fix in `_compute_pl`:
* Max loss per contratto era `width` (errato per credit spread).
Corretto a `width − credit` allineato a core/sizing_engine.py.
Effetto: n_kelly aumenta proporzionalmente al credit incassato →
P/L stimato più realistico per spread con credit_to_width_ratio
alto (es. 0.30+ in profilo Aggressiva).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sostituisce `option_chain_asset: str = "ETH"` con
`option_chain_assets: tuple[str, ...] = ("ETH", "BTC")` e itera nel
job schedulato. Coerente con `market_snapshot_assets` già multi-asset
e con i 64 strikes BTC + 51 strikes ETH già visibili in
option_chain_snapshots.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sblocca il warmup hard del gate IV-RV adattivo (~21 giorni residui)
permettendo di mischiare cadenze diverse (tick live 15min + backfill
giornaliero) senza assumere il fattore costante 96 tick/giorno.
API change (no backwards-compat shims):
* compute_adaptive_threshold(history, *, n_days, percentile,
absolute_floor): rimossi `min_days`/`target_days`. La selezione
finestra (target_days/min_days/intera storia) si sposta al caller.
Warmup hard quando `n_days == 0`.
* repository: rimosso `iv_rv_history`; aggiunti
`count_iv_rv_distinct_days` (COUNT DISTINCT substr(ts,1,10)) e
`iv_rv_values_for_window`.
* EntryContext aggiunge `iv_rv_n_days: int = 0`. entry_cycle calcola
n_days, sceglie window_days e popola il context. Audit
`iv_rv_n_days` reale (non più len/96).
* GUI Calibrazione: counter giorni distinti tramite set di date.
* Spec aggiornata con errata 2026-05-10 e nuova warmup table.
Backfill (scripts/backfill_iv_rv.py, stdlib-only):
* Fetch DVOL daily + ETH/BTC-PERPETUAL closes da Deribit public REST.
* Calcolo RV30d annualizzato (stdev log-return × √365 × 100).
* INSERT OR REPLACE in market_snapshots con timestamp 12:00 UTC e
fetch_errors_json='{"backfill":true}' per distinzione audit.
* Compute layer testato (9 test): RV su prezzi costanti/monotoni/
alternati, build_records con cutoff e missing data.
Verifica live post-deploy (10 mag 2026 08:50 UTC):
* ETH: n_days=46, P25=2.21 vol pt, IV-RV=10.05 → gate PASS
* BTC: n_days=46, P25=5.69 vol pt, IV-RV=8.60 → gate PASS
509 test passati (500 esistenti + 9 backfill), ruff pulito.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Risponde al final review (spec §6.4): il decisions log ora
contiene iv_rv_threshold_used (la soglia P_q effettivamente
applicata) e iv_rv_window_used_days (giorni di history nella
finestra). Permette ricostruire ex-post perché un trade è stato
saltato e con quali numeri.
Helper privi di I/O — la soglia viene ricomputata in base alla
history già caricata, costo trascurabile.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
L'hash dichiarato non rispecchiava più il contenuto del file dopo
l'attivazione del gate adattivo (commit 080acf8). Senza questo fix
il loader sollevava ConfigHashError e l'orchestrator rifiutava il
profilo Aggressiva al boot.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Sequence importato da collections.abc invece di typing (PYI001).
- compute_adaptive_threshold spostato a top-level (PLC0415):
niente circular dep risk perché adaptive_threshold non importa
da entry_validator.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mostra status (warmup/attivo), soglia P25 rolling corrente, IV-RV
ultimo tick, floor assoluto, decisione hypothetical e sezione
Vol-of-Vol guard. Read-only: i percentili statici esistenti
restano per analisi.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
P25 rolling 60g, warmup a finestra disponibile, VoV guard 5pt.
Conservativa e golden invariati (default disabled).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Verifica integrazione tra Repository.iv_rv_history,
compute_adaptive_threshold e dvol_lookback su un DB reale
seedato con 30 giorni di market_snapshots bimodale.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Quando i flag adaptive_enabled / vol_of_vol_guard_enabled sono
attivi, entry_cycle carica history e lookback dal repository
prima di costruire EntryContext. Il decisions log riceve i meta
n_history e dvol_24h_ago per audit ex-post.
Quando i flag sono off, niente query DB extra (zero overhead).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Risponde alla code review di 395191e:
- iv_rv_history accetta as_of (default now UTC) invece di
affidarsi al clock SQLite, rendendo i test time-stable.
- Valida max_days > 0 e raise se as_of/reference sono naive.
- Aggiunge 3 test sulle nuove guard.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Due nuovi metodi che leggono market_snapshots filtrando NULL e
fetch_ok=0. iv_rv_history limita a max_days; dvol_lookback trova
il tick più vicino a un istante con tolerance configurabile.
Tests: ordered ASC, asset filter, NULL skip, fetch_ok=0 skip,
lookback closest, gap returns None.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Blocca entry se |DVOL_now - DVOL_24h_ago| >= threshold (default
5 pt). Fail-open quando dvol_24h_ago è None (gap dati). Independente
dal gate IV-RV: i due gate sono additivi.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Quando iv_minus_rv_adaptive_enabled=True, la soglia diventa
max(P_q rolling, iv_minus_rv_min). Path legacy (statico) e
None-bypass restano invariati.
Aggiunge anche due model_validator a StrategyConfig per
fail-fast su config invalida (window_min_days < target_days,
percentile in (0,1)) — risponde alla code review T1.
Tests: pass/skip su rolling, warmup hard, floor binding,
backwards compat statico, None bypass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Campi opzionali con default vuoto/None per non rompere i caller
esistenti. Saranno popolati da entry_cycle quando i flag
adaptive_enabled / vol_of_vol_guard_enabled sono True.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Risponde alla code review di 7dc2fda:
- Valida percentile in [0,1] e 0 < min_days < target_days, raise
ValueError quando out-of-range. Fail-fast invece di IndexError o
silent wrong result.
- Aggiunge test boundary esattamente a min_days*96 e target_days*96
(spec §9.1 item 9 era mancante).
- Aggiunge 4 test sulle nuove guards.
- Fix typo docstring (Determinismic → Deterministic).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Implementa il calcolo del percentile rolling con warmup,
transizione min_days → target_days e floor assoluto. Pure
function senza I/O: il caller passa la sequenza pre-filtrata
(NULL e fetch_ok=0 esclusi).
Tests: warmup, transizione finestra, floor, percentili.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Aggiunge i flag e i parametri per il gate IV-RV adattivo (P25
rolling) e per il Vol-of-Vol guard. Default disabilitati per
non cambiare comportamento dei profili attuali.
Vedi docs/superpowers/specs/2026-05-08-iv-rv-adaptive-gate-design.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Piano TDD bite-sized in 11 task con steps dettagliati, codice
completo, comandi e expected output. Coverage completa dello
spec 2026-05-08-iv-rv-adaptive-gate-design.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Spec del gate IV-RV adattivo (P25 rolling 60g + Vol-of-Vol guard 5pt
24h) — riprende roadmap §4-quater di 13-strategia-spiegata.md punti
1 e 2 e li promuove a design pronto per implementazione.
Decisioni emerse dal brainstorming:
- Hybrid (percentile rolling + VoV guard), non regime detection
- Window target 60g, min 30g, sotto usa storia disponibile (warmup)
- Floor assoluto via vecchio iv_minus_rv_min (backwards compat)
- Inline nel validator, stateless, no DB cache
- GUI Calibrazione: pannello informativo, slider esistenti invariati
- Fail-open su tutti i casi di dato mancante
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Il commento dichiarava cron settimanale (55 13 * * MON) ma lo
scheduler reale (orchestrator._CRON_OPTION_CHAIN_SNAPSHOT) è */15
24/7, allineato a market_snapshot. Aggiornato per evitare confusione
nei lettori futuri. Anche fixato l'header file (0004 → 0005).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Alle 00:00 UTC Deribit non ha ancora costruito il candle 1D di oggi:
con start_date=oggi la response è vuota e il client tirava
McpDataAnomalyError ('neither latest nor candles'). Includendo ieri
nello start_date, candles[-1] resta valido come fallback.
Verificato sui dati raccolti: 3 fail consecutivi 2026-05-02/03/04 a
00:00 UTC su ETH, zero fail dal 2026-05-05 in poi (container
rebuildato in mezzo al periodo).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adriano Dal Pastro