7 finder paralleli sul diff della giornata (8adf388..HEAD), fix dei confermati: CRITICI (money-path): - close_amount: GUARD stato-stantio sul fallback netting — il residuo non-reduce-only e' consentito solo fino al gap (conto reale - libri degli altri worker - orfani) nella direzione della chiusura (src/live/books.py = fonte unica, usata anche dal reconciler). Senza guard, un close su stato stantio (DSL scattato in outage, flatten manuale) APRIVA una posizione nuda a taglia piena bookata come 'chiusura verificata'. Fail-safe se il gap non e' calcolabile. Check polvere PRIMA di _quantize_step (che clampa al lotto minimo: un residuo 1e-17 diventava un ordine nudo da un lotto). - _real_close: market_amt = filled_amount anche a merged verified=False (i contratti chiusi dal reduce-only non si buttano se il leg netting fallisce); REAL_CLOSE_PARTIAL non piu' gateato su verified (era soppresso proprio nel caso parziale reale). - pairs: verita' per-FRAZIONE di gamba (gross proporzionale al fillato, orfano = solo il residuo — prima falsava reconciler e real_capital della parte gia' chiusa); REAL_OPEN_PAIR booka filled_amount; docstring applied corretta. - open_pair unwind: chiude il FILLATO, non il richiesto (senza il cap silenzioso del reduce-only avrebbe mangiato quota altrui). - place_tp_limit: quantize CONSERVATIVO (sell=floor/buy=ceil) — il rounding al tick piu' vicino poteva mettere il resting oltre il TP sim -> tocco genuino classificato phantom sistematicamente. ROBUSTEZZA/OSSERVABILITA': - runner: WORKER_ERROR_STREAK a 5 e poi ogni 50 poll + recovery RIPRESO + flag real_in_position nell'alert (prima: one-shot a n==5, poi silenzio). - _tp_phantom: TTL 120s sul verdetto (era ~50 HTTP/h per worker a barra fantasma); merge notes con entrambi gli order_id (audit-trail). - reset_flatten: _quantize_step Decimal (round float produceva amount che Deribit rifiuta); hourly_report: book XS01 con gambe SHORT visibili (abs). - validate_xsec_worker: POS/LEV importati (non hardcoded); xs01_tranche: regression-lock ESEGUITO vs xsec_sim; reconcile su src/live/books; drift_monitor: rolling vettoriale + exit code 1 su warn. Test: +4 guard/dust, fixture filled_amount -> 114 passed. Deferiti (TODO): resting esposti al netting, lifecycle orphan_legs, finestra trade-history TP_PHANTOM, validazione feed a monte, dedup minori. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
9.6 KiB
TODO — prossimi passi
Raccolta dei follow-up aperti. Aggiornato 2026-06-11 (XS01 dispersion-gate live v1.1.20; real-truth ledger attivo; reset portafoglio 2026-06-10).
Stato esecuzione per sleeve (REALE vs SIMULATO)
REALE (shadow su Deribit testnet, REAL-TRUTH: il ledger segue i fill reali) — 15 sleeve:
- 6 fade (MR01/MR02/MR07 × BTC/ETH) + DIP01_BTC → single-leg, v1.0.3+
- 6 pairs PR01 (ETH/BTC, LTC/ETH, ADA/ETH, BTC/LTC, ETH/SOL + ETH/BTC 15m) → 2 gambe, v1.1.12 (2026-06-08); il 15m dal v1.1.16 (2026-06-09)
- SH01 × BTC/ETH → single-leg, exit a orizzonte (no TP/SL), v1.1.13 (2026-06-08)
SIMULATO (paper, NON esegue reale) — 4 book multi-asset, fuori dal capitale-pool:
- TR01 / ROT02 / TSM01 / XS01 → bloccati dal CAPITALE (rumore arrotondamento)
Esecuzione reale — pezzi mancanti
Executor a 2 gambe per i PAIRS— FATTO + ATTIVO (v1.1.12, 2026-06-08).SH01 in reale— FATTO (v1.1.13, 2026-06-08): l'infrastruttura no-TP esisteva già (_place_real_tp no-op senza TP, _real_close chiude tutto market reduce-only a orizzonte). Bastava accettare kind 'ml' in _exec_for + SH01 in execution.sleeves. Disaster-bracket on-book = unica protezione di coda. Test SH01 open/close reale OK.- Multi-asset in reale (SIMULATO: TR01/ROT02/TSM01/XS01) — SBLOCCATO DA CAPITALE ≥ ~€20k.
Strumenti USDC tutti esistenti (BNB/DOGE/XRP inclusi), ma a €2k il rumore di arrotondamento
per-asset è 20-30% (DOGE/XRP/SOL step grandi in $, esposizione frammentata su 5-8 asset) →
l'esecuzione reale misurerebbe il rumore dei lotti, non la strategia. Serve un
BasketExecutionClient(ribilancio delta multi-strumento, long-only, netting con fade+pairs sui simboli condivisi). Beneficio limitato (~19% del portafoglio, diversificatori spesso flat) → bassa priorità anche a capitale alto. Analisi: chat 2026-06-08.
Capitale (decisione utente, non codice)
- Valutare aumento capitale a €5.000-10.000 per togliere il rumore di arrotondamento. A €2.000 il rumore BTC per trade è ~2.4% (morde); soglie: ~€4.800 (<1%), ~€9.500 (<0.5%, "punto dolce"), ~€19.000 (trascurabile). Le commissioni invece sono % e neutre al capitale. Col real-truth ledger il rumore di arrotondamento entra DIRETTAMENTE nell'equity → più capitale = ledger più fedele alla strategia. Riguarda i 15 sleeve che eseguono reale.
Follow-up dal code-review (bassa priorità, non urgenti)
forming-bar su ROT02/TSM01— GIÀ FIXATO (v1.1.10, 2026-06-08):_panelcondiviso scarta la barra in formazione vialast_bar_is_forming. Item rimasto stantio nel TODO.- ancora bfill di
_daily_equity— QUANTIFICATO 2026-06-11 (daily_equity_bfill_impact.py): NON materiale, lasciare documentato. PORT06 OOS invariato per costruzione (il bias vive in testa alla serie, pre-SPLIT; ΔSharpe +0.001, ΔDD 0.000); FULL DD leggermente OTTIMISTICO (3.46→3.67 col fix: il primo trade DIP01 2021, −3.75%, è nascosto dal bfill). Nessun verdetto di gate a rischio (bias identico nei due bracci A-vs-B, si cancella). Unica eccezione OOS: TSM01 (primo punto equity post-SPLIT, −0.014 Sh). Correggere SOLO in un eventuale refactor del builder daily, OVUNQUE in un colpo (~12 file di gate replicano la convenzione) e ri-baselinando i canonici nello stesso commit. CAVEAT per gate futuri: finestre IDX che partono a metà storia amplificano il bug → usare lì la convenzione carry-forward corretta. convenzione TR01 worker vs reference— ERA UN BUG, FIXATO (2026-06-11):mean(rets)sui soli asset in posizione sovrappesava N/k a paniere parziale (con 1 long: 0.45 del capitale invece di 0.09). Fix:sum(rets)/len(universe)(equal-weight 1/N canonico). Replay post-fix: +32% vs reference +42% (residuo = convenzione capitale-unico vs media-equity, dichiarata). Diario2026-06-11-stability-sweep.md.engine duplicato nei 3 gate— FATTO (2026-06-11): fattorizzato inscripts/analysis/_port06_gate_common.py(build_trades_variantversione trendmax = superset con hurst_mask/trend_max parametrici,equity_from_trades,port_metrics,dd); i 3 gate importano da lì. Nessuna drift di matematica trovata fra le copie (solo firme/docstring). Output dei 3 gate verificato BYTE-IDENTICO prima/dopo.dip_trades(DIP01) NON è una copia ma un sibling deliberato (long-only, orig_gap, j clampato) → resta nel suo script, documentato nel modulo comune.- epoche hardcoded in
hourly_report.lossguard_section(LOSSGUARD_SINCE, TRENDSWAP_SINCE): ogni nuova epoca-filtro richiede di editare la funzione. Derivarle da deploy history/config.
Code-review 2026-06-11 sera (8a2b065..) — finding DEFERITI (i confermati critici sono fixati in v1.1.26)
- RESTING reduce-only esposti al netting (TP limit + disaster-SL): se un worker opposto apre DOPO il piazzamento, il resting può fillare parziale o essere respinto — il fallback netting copre solo i close sincroni. È il pezzo "position manager / sotto-conti" già noto; lo scenario peggiore è il disaster-SL cappato proprio nel crash per cui esiste.
- Lifecycle
orphan_legs: append-only — un orfano risolto a mano (o da reset_flatten) resta nello status e MASCHERA per compensazione un drift vero futuro (falso negativo del reconciler). Serve un comando di risoluzione (--resolve-orphan) e/o reset_flatten che azzeri anche lo stato reale nei status.json. Idem: il PnL della chiusura manuale di un orfano non viene mai bookato in real_capital (diagnostica shadow divergente). - TP_PHANTOM residuo:
resting_fillsguarda solo le ultime 100 righe di trade-history per strumento — su conto molto attivo un fill TP reale può scivolare fuori finestra → falso phantom persistente (sim resta in posizione, reale flat). Mitigato dal quantize conservativo (v1.1.26); fix vero = endpoint order-state in cerbero-mcp. - Validazione feed a monte (altitudine): TP_PHANTOM copre solo i tocchi TP dei single-leg; le ENTRY spike-driven, lo SL close-confirm su close spike e lo z dei pairs restano esposti ai wick fantasma del feed testnet. Un validatore barre nel data layer coprirebbe tutti i consumer con un meccanismo solo (su mainnet il fenomeno non esiste: priorità bassa finché si resta su testnet, gli eventi TP_PHANTOM/NET_CLOSE ne misurano la frequenza).
- Contratto dello schema status.json: reconcile (
src/live/books.py), hourly_report e i worker condividono lo schema per convenzione implicita — books.py è ora la fonte unica per i campireal_*, ma un helperworker.real_book()usato da _save e dai reader chiuderebbe la classe di bug. Pulizia:_tp_hithelper per i 4 siti di tocco TP duplicati; port_metrics ri-biforcato in xs01_tranche_gate/pairs30m_gate (importare da _port06_gate_common); splits3/metriche duplicate nei games engine (estrarre in scripts/games/engine.py).
Ricerca dispersion/correlation (2026-06-08, 165 agenti) — follow-up opzionale
Gate PORT06 di— FATTO (2026-06-08): PROMOSSO MARGINALE. Decorrela bene (corr 0.06 col MASTER) ma OOS PIATTO (Sharpe −0.01). Documentato e rimandato (non deployato): gate inindex_comp_dispW=168dispersion_edges/gate_index_comp_disp.py, riprendere solo se si costruisce una famiglia DISP più ampia. Diario aggiornato.
Monitoraggio (osservare, non agire subito)
-
Churn da spike-print testnet su ETH (2026-06-11): il feed testnet stampa wick anomali sulla barra 1h ETH che (a) generano segnali short MR01/MR07 (lo spike È lo z-score estremo) e (b) "toccano" il TP intrabar della stessa barra → il sim booka +4% fantasma a bars_held=0, il reale apre+chiude pagando solo fee/spread (~−0.17€ a giro, 14 giri oggi ≈ −2.3€). Il real-truth ledger contabilizza GIUSTO (per questo esiste) e il report orario ora conta i win dal flag reale. MITIGATO in v1.1.23: gate
TP_PHANTOM(il tocco TP deve essere confermato dal fill del resting sul book reale, o dal prezzo oltre il livello) → niente più chiusure a mercato su wick fantasma. Resta l'ENTRY spike-driven (il segnale stesso nasce dal wick): NON filtrarlo nei segnali (= fit su artefatto testnet); osservare la frequenza dei log TP_PHANTOM — se cresce, valutare un gate di QUALITÀ FEED nel data layer. -
FADE in coda storica (2026-06-11): il rolling 120g equal-weight delle 6 fade è al 2° percentile della propria storia (−1.0% vs p5 +0.4%); il PORT06 complessivo resta in variazione normale (19-28° pct). NESSUN ritocco parametri (= fit sul regime corrente); osservare se rientra. Follow-up tecnico: alert di drift per-FAMIGLIA nel
hourly_report(precomputare la distribuzione storica dei rolling-return di famiglia dal backtest canonico → confrontare il rolling live; notifica sotto p5). -
PnL live post-swap trend (epoca TREND in
hourly_report): verdetto stop-rate fade a n>=30. -
SH01 post-bootstrap: il trade-rate live deve scendere da ~25% a ~10% delle barre (selettività della soglia ripristinata). Controllare nel report orario.
-
MR02_ETH: ultima posizione aperta SENZA disaster-SL (aperta pre-v1.1.4). Si chiuderà normalmente; le prossime aperture avranno il bracket.
-
parquet fresco per SH01 bootstrap: oggi al 2026-05-28, il feed copre 365g → margine ~11 mesi. Rilanciare
download_all()periodicamente (WARN automatico se il gap supera il lookback).