Adriano/PythagorasGoal
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
PythagorasGoal/Old/docs/TODO.md
T
Adriano Dal Pastro 14522262e6 chore(reset): v2.0.0 — storico certificato Deribit mainnet, ripartenza pulita 
Reset del progetto su fondamenta verificate dopo la scoperta che l'intera
libreria "validata OOS" era artefatto di feed contaminato (print fantasma del
feed Cerbero TESTNET + storico Binance/USDT).

- Storico ricostruito da Deribit MAINNET (ccxt pubblico, tokenless) e
  CERTIFICATO (certify_feed.py): BTC/ETH puliti su TUTTA la storia
  (mediana 2-6 bps vs Coinbase USD), integrita' OHLC + coerenza resample
  (maxΔ 0.00) + cross-venue OK. Alt esclusi (illiquidi/divergenti: LTC/DOGE
  50-82% barre flat; XRP/BNB non certificabili).
- Verdetto sul feed pulito: FADE / PAIRS / XS01 / TSM01 morti (ogni
  portafoglio Sharpe -2.3..-3.0, DD ~40%); solo SH01 e frammenti HONEST
  con segnale residuo, da ri-validare in isolamento.
- Cleanup "restart pulito": strategie, stack live (src/live, src/portfolio,
  runner/executor, yml, docker), ~100 script ricerca/gate, waste/games/
  portfolios, dati non certificati + cache e 60+ diari -> archiviati in Old/
  (preservati, non cancellati). Diario consolidato in un unico documento.
- Skeleton ricerca tenuto: Strategy ABC + indicatori + src/fractal +
  src/backtest/engine + load_data; tool dati certificati (rebuild_history,
  certify_feed, audit_feed, multi_source_check).
- Universo dati ATTIVO: solo BTC/ETH (5m/15m/1h); guardrail fisico
  (load_data su alt -> FileNotFoundError). Esecuzione DISABILITATA, conto flat.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-19 15:20:59 +00:00

9.6 KiB
Raw Permalink Blame History

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): _panel condiviso scarta la barra in formazione via last_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). Diario 2026-06-11-stability-sweep.md.
  • engine duplicato nei 3 gate — FATTO (2026-06-11): fattorizzato in scripts/analysis/_port06_gate_common.py (build_trades_variant versione 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_fills guarda 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 campi real_*, ma un helper worker.real_book() usato da _save e dai reader chiuderebbe la classe di bug. Pulizia: _tp_hit helper 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 index_comp_disp W=168 — 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 in dispersion_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).

Reference in New Issue View Git Blame Copy Permalink