Adriano Dal Pastro
ec8478308f
Chiude il debito che CLAUDE.md dichiarava da settimane: la regola "ogni cambio di scala passa dal cap di config, non da target_vol" NON era implementabile perche' una chiave di scala non esisteva — qualunque cambio sarebbe finito su WEIGHT/W_TP01/W_SKH, cioe' codice su un percorso con soldi veri e per giunta nel posto sbagliato (W_TP01/W_SKH sono il RAPPORTO 75/25, non la taglia). Specifica gia' scritta in docs/research/SPEC-scale-key.md (618 righe, 9 condizioni di gate, prototipo). Non ho progettato: ho eseguito i punti 1-4. 🚨 config/live.json NON E' STATO TOCCATO. La chiave e' assente, vale 1,00, e T7 dimostra bit-exact che il libro e' quello di ieri (max|diff| = 0.0). Verificato anche a runtime: book_execute in dry-run da' gli stessi target del cron delle 15:47 (BTC $+355, ETH $+214). LE QUATTRO DECISIONI CHE NON SONO DI COMODO - La scala si applica DOPO il clamp. Prima, il cap se la mangerebbe proprio nei giorni di massima convinzione (a tp=1/sg=+1 il grezzo vale esattamente cap => k_eff tornerebbe a 1,00 a ogni k): sarebbe un cambio di FORMA travestito da cambio di taglia, e la curva g(k) con cui il gradino viene autorizzato non descriverebbe quel libro. Prezzo dichiarato: il cap diventa il tetto del libro UNITARIO, e la guardia sulla leva lorda va ricostruita. - Il tetto e' sul PRODOTTO e sta nel CODICE. Sulla sola chiave lascerebbe aperta la porta accanto (frac 0,625 x scala 1,25 = 1,562x); in config sarebbe un lucchetto con la chiave attaccata. LEVA_LORDA_MAX 1,25 in src/live/book.py => il gradino a 1,50 richiede codice, quindi review. - Fuori scaletta o fuori tetto = STOP, non clamp. book_execute si ferma, non invia, allerta (ScalaNonAutorizzata). E SCALA_LADDER (1,00 · 1,25) rende INESPRIMIBILE "solo un po'": 1,05 non e' prudente, e' fuori scaletta. - La scala vive solo sul percorso fidato (equity illeggibile => 1,00), cosi' "il fallback non e' piu' permissivo" e' vero per costruzione. Ma la VALIDAZIONE avviene sempre: una config rotta non si nasconde dietro un giro in cui l'equity non era leggibile. LA GUARDIA CHE MORDE PER PRIMA non e' il peggior giorno (k <= 3,49x) ma il COSTO di un disaster-SL (k <= 1,67x, 2,1x piu' stringente): l'invariante n_asset x frac x scala x disaster_sl_pct <= 0,50 scatta anche se qualcuno allarga lo stop invece di alzare la scala. TEST T1-T11 (tests/test_book_scale.py, 18 verdi). Il piu' importante e' T1b: a k=1 l'implementazione simmetrica e quella asimmetrica danno lo STESSO numero, quindi un test di simmetria scritto sul caso di default ha potenza ZERO. T1b verifica che le due coincidano a k=1 (il rischio e' reale) e che fuori da k=1 l'asserzione le SEPARI, con un'implementazione asimmetrica scritta nel test apposta perche' fallisca. SORVEGLIANTE scale_watch (cron_daily, 3 domande / 3 azioni / 3 stati, una allerta per streak, marcatore scritto solo dopo invio riuscito — debito #2). Riporta la frequenza del ramo di fallback, che sopra il 2% in 90 giorni invaliderebbe la regola: misurata 0/1.676, coi 19 giri "paper capital" (pre-finanziamento, dove il libro non invia) contati e dichiarati a parte. Non puo' impedire la modifica: la rende visibile entro 24h e attribuibile. CHIUDE il debito #5 di §5: T2/T3 sostituiscono il vecchio test_leva_massima_da_config (che misurava frac x n_asset mentre la grandezza vera e' frac x n_asset x scala), e T11 verifica che sia rimasto cancellato. NON FATTO, deliberato: la chiave in config (punto 2 lo vieta), GATE SCALA-01 (A2 richiede >=30 giorni a 1,00 col sorvegliante attivo — "l'unico modo di scoprire che il sorvegliante e' rotto mentre la leva e' ancora 1,00"), r0726_fee_sensitivity rifatto (A7: serve solo al gradino; a 1,25x una liquidazione costerebbe 1,25% non 1,00%, e ereditarlo sarebbe l'errore). Nessun ordine. Suite: 825 passati. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
69 lines
5.8 KiB
Bash
Executable File
69 lines
5.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
|
|
# Schema fee Deribit (nuovo dal 2026-08-01, annunciato senza numeri): legge il tier BASE
|
|
# dall'endpoint pubblico e applica la regola decisa in anticipo (<=5bps nulla, >10bps peso SKH01).
|
|
uv run python scripts/live/fee_watch.py --quiet || true
|
|
# Cosa il venue ANNUNCIA (debito #8: la sonda venue_probe legge se RISPONDE, non cosa dichiara).
|
|
# Feed RSS pubblico degli exchange-update. NON interpreta: classifica solo l'urgenza, su parole
|
|
# DERIVATE da deribit._CONTRACT e config/live.json. In una settimana quattro cambi di policy
|
|
# materiali erano arrivati a mano; le specifiche dei perp USDC cambiate il 18/08 erano annunciate
|
|
# il 14/08, e check_specs() se ne accorge solo DOPO.
|
|
uv run python scripts/live/venue_news.py --quiet || true
|
|
# f delle strutture VRP dalle quote REALI (canonico vs candidato bocciato dal gate 30/07).
|
|
# Criterio di sufficienza pre-registrato (>=40 coppie, IC95 <=0.12): avvisa da solo quando
|
|
# il campione basta, invece di lasciare la misura appesa a un promemoria.
|
|
uv run python scripts/live/vrp_f_watch.py --quiet || true
|
|
# La CHIAVE DI SCALA del libro: la config dichiara una scala che il giornale non ha autorizzato?
|
|
# Il criterio che la autorizzo' passa ancora? Il PRODOTTO frac x scala x n_asset ha superato il
|
|
# tetto? Tre domande, tre azioni diverse. Non impedisce la modifica: la rende visibile entro 24h
|
|
# e attribuibile — una chiave di scala e' il parametro che si alza "solo un po'" dopo un mese
|
|
# buono, e lo Sharpe (invariante alla scala) non lo vedrebbe mai. SPEC-scale-key §6.4.
|
|
uv run python scripts/live/scale_watch.py --quiet || true
|
|
# I forward-monitor stanno registrando? Tre gate pre-registrati (27/09, 23/10, 24/10) si
|
|
# decidono su queste serie: un monitor fermo produce silenzio, e il silenzio sembra uno zero.
|
|
# Va DOPO tutti i monitor, altrimenti misura lo stato di ieri.
|
|
uv run python scripts/live/monitor_health.py --quiet || true
|
|
# Giornale di bordo. Gira alle 00:30 UTC -> chiude IERI, che a quest'ora e' un giorno COMPLETO.
|
|
# Sola lettura: feed certificato, cron_book.log, trades.db. Il campo `nota` non lo tocca.
|
|
uv run python scripts/live/journal.py --giorno "$(date -u -d yesterday +%F)" --quiet || true
|
|
# NON si apre piu' la voce di OGGI (tolto 2026-08-25). A quest'ora coprirebbe ~30 minuti e
|
|
# nessuno la aggiorna fino alla notte dopo: una pagina con TUTTE le sezioni, che si legge come
|
|
# una giornata e ne contiene mezz'ora. Chi vuole lo stato corrente lancia `journal.py` a mano
|
|
# (la pagina si dichiara PARZIALE nel titolo) o legge trades.db, che cron_book sincronizza ogni
|
|
# ora. Se un giorno servisse la voce sempre fresca, la strada e' RIGENERARLA ogni ora in
|
|
# cron_book, non congelarla qui.
|
|
# Analista di bordo: un modello scrive la prosa del giorno CHIUSO nel campo `analisi`.
|
|
# Scrive SOLO li': non tocca `nota` (operatore) ne' le sezioni misurate, e se non risponde
|
|
# la pagina resta senza analisi invece di mostrare quella di ieri. Costo: 1 chiamata/giorno.
|
|
uv run python scripts/live/analista.py --giorno "$(date -u -d yesterday +%F)" --quiet || true
|
|
echo "===== done $(date -u '+%H:%M:%SZ') ====="
|
|
} >> logs/cron_daily.log 2>&1
|