Adriano Dal Pastro
a1b4416ac0
"Come faccio a capire se l'edge e' morto?" scopre un buco: il progetto ha gate di kill pre-registrati per i CANDIDATI (DVOLSPREAD 24/10, XSR01 23/10, STATARB 27/09) e NESSUNO per il book che gira con soldi veri. La risposta implicita era "si vedra'", cioe' quello che il progetto non accetta dai candidati. LA RISPOSTA SCOMODA: non si puo' sapere in fretta. Sharpe rolling a 12 mesi: il 56% dei casi "edge morto" e' indistinguibile da uno vivo. Un anno brutto e' rumore, non informazione. CRITERIO A (ritorno, book intero): Sharpe rolling 36 mesi sotto -0.5. Tarato sul nullo (edge intatto) -> falso kill 1.8% in 10 anni; controllo positivo (edge morto) -> lo riconosce nel 91% dei casi, rilevamento mediano 3.8 anni. La lentezza non e' un difetto della regola ma statistica: a 12 mesi la stessa regola ucciderebbe un edge VIVO nell'80% dei casi. Non esiste una versione veloce e onesta. CRITERIO B (TP01, che e' DIFENSIVO): serve un criterio diverso perche' il LOO del 26/07 ha misurato il contributo hold-out di TP01 negativo nel 99.1% delle configurazioni d'ancora — firma dell'assicurazione, che paga premio negli anni senza incendio. "Non ha guadagnato" NON e' evidenza di morte. Criterio: in un anno con DD buy&hold > 10%, il DD di TP01 deve restare sotto il 75%. Storico 8 anni di sinistro, 8/8 superati (protezione 1.8x-34.4x). Negli anni SENZA sinistro il criterio non si valuta: non c'e' informazione. Questo criterio e' VELOCE dove l'altro e' lento. COSA SUCCEDE SE SCATTANO (dichiarato ora per non deciderlo nel momento sbagliato): (A) il book NON si spegne da solo -> revisione con weights_tilt_null + deflated-Sharpe sui dati nuovi; spegnere e' decisione dell'operatore. (B) fallito in DUE anni di sinistro consecutivi -> TP01 non assicura piu' e il peso 75% va rimesso in discussione. CABLATO: scripts/live/edge_watch.py in cron_daily.sh, allerta Telegram, non tocca l'esecuzione. Stato oggi: Sharpe 36m +1.51, protezione 8/8. IL LIMITE, DETTO: il criterio A rileva la morte ~4 anni dopo, e non e' riparabile con una regola migliore (e' il contenuto informativo dei dati). La difesa vera e' che il piano regge a un edge dimezzato (11.6 -> 15.8 anni, P(20a) ancora 77%) e che i rischi VELOCI (venue, esecuzione, feed) hanno sorveglianze che scattano in ore. 404 test verdi (+11). Book, pesi, config INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
33 lines
2.8 KiB
Bash
Executable File
33 lines
2.8 KiB
Bash
Executable File
#!/bin/bash
|
|
# Refresh dati certificati + avanza paper portfolio (per il dashboard). v2.0.0+.
|
|
export PATH="/home/adriano/.local/bin:$PATH"
|
|
cd /opt/docker/PythagorasGoal || exit 1
|
|
mkdir -p logs
|
|
{
|
|
echo "===== $(date -u '+%Y-%m-%dT%H:%M:%SZ') cron_daily ====="
|
|
uv run python scripts/analysis/rebuild_history.py --asset BTC ETH # BTC/ETH Deribit mainnet
|
|
uv run python scripts/analysis/fetch_hyperliquid.py # 52 alt Hyperliquid (certify)
|
|
uv run python scripts/research/fetch_dvol.py # DVOL (per ricerca opzioni)
|
|
uv run python scripts/live/paper_portfolio.py # avanza paper TP01+XS01
|
|
uv run python scripts/live/paper_prevday.py # forward-monitor lead prevday-breakout (PAPER, non deploy)
|
|
uv run python scripts/live/paper_statarb.py # forward-monitor lead STATARB-RESID ETH/BTC ortogonale (PAPER, non deploy)
|
|
uv run python scripts/live/paper_xsr.py # forward-monitor XSR01 cross-sectional residual 50 alt HL (PAPER, gate 2026-10-23)
|
|
uv run python scripts/live/paper_dvolspread.py # forward-monitor DVOLSPREAD implied-vol RV BTC/ETH (PAPER, kill 2026-10-24 / gate 2027-01-24)
|
|
uv run python scripts/live/cc01_regime_watch.py # trigger regime CC01 (read-only: WARN>=10%/ALERT>=15% funding 30g)
|
|
uv run python scripts/research/r0724_stable_snapshot.py # snapshot point-in-time supply stablecoin (sblocca WATCH STABLE a 12 mesi)
|
|
# NB: l'esecuzione Deribit e' passata al BOOK (TP01+SKH01 nettati) via scripts/cron_book.sh a
|
|
# cadenza ORARIA (SKH01 e' a 230m: il daily mancherebbe gli ingressi). live_execute.py
|
|
# (TP01-only) NON va piu' eseguito qui, sennò i due farebbero a pugni sullo stesso strumento.
|
|
# --- COMBO cross-venue (PAPER): refresh ETF IB (GTAA) + avanza paper TP01+GTAA ---
|
|
docker compose up -d ib-gateway >/dev/null 2>&1 # gateway IB paper (idempotente)
|
|
for i in $(seq 1 25); do (echo > /dev/tcp/127.0.0.1/4002) >/dev/null 2>&1 && break; sleep 6; done
|
|
uv run --with ib_async python scripts/research/fetch_ib_equities.py --only SPY,QQQ,IWM,TLT,GLD,HYG # ETF GTAA freschi
|
|
uv run python scripts/live/paper_combo.py # avanza paper combo (forward-only)
|
|
# --- REPORT GIORNALIERO Telegram (sola lettura): rompe il silenzio quando il libro e' flat ---
|
|
uv run python scripts/live/telegram_daily.py # stato conto + perche' non opera + gate
|
|
# Sorveglianza dell'EDGE del book live (criteri di kill pre-registrati,
|
|
# tarati in scripts/research/r0726_edge_death.py). Riporta e allerta, non spegne nulla.
|
|
uv run python scripts/live/edge_watch.py --quiet || true
|
|
echo "===== done $(date -u '+%H:%M:%SZ') ====="
|
|
} >> logs/cron_daily.log 2>&1
|