Adriano Dal Pastro
426735448e
Nato da "stato trades" durante una manutenzione Deribit (system_maintenance 11051,
08:57-09:20 UTC). Contati i log invece che ricordarli: 1.499 giri dal 23/06, 3 con
manutenzione, 5 traceback duri — e 4 dei 5 sono il NOSTRO gateway, non il venue.
Le release Deribit escono il martedi' alle 09:00 UTC: il cron al :07 ci cadeva dentro
per costruzione (21/07, 11/08, 18/08, 25/08).
DIAGNOSI (src/live/venue_probe.py, nuovo)
Sonda l'API PUBBLICA Deribit senza gateway e senza credenziali, e classifica il guasto:
VENUE_MANUTENZIONE / VENUE_GIU / GATEWAY / IGNOTO. Prima ogni causa stampava la stessa
riga ("conto non leggibile (offline)") con nota di diagnosi CABLATA — P4 violata, e il
18/08 il codice 11051 era gia' dentro il processo senza arrivare a chi decideva la
gravita'. Parte solo dopo un guasto: sul percorso sano costa zero. P1 rispettata: la
firma 11051 si importa da venue_watch.is_maintenance, non si ridichiara.
P9: la manutenzione dentro lo slot declassa il titolo a info, ma solo su EVIDENZA della
sonda (mai sull'orologio) e solo dentro la durata annunciata — oltre, RIALZA. Un gateway
rotto di martedi' mattina resta al massimo.
DISASTER-SL SCOPERTO (src/live/execution.py)
ensure_disaster_sl cancella i bracket incoerenti PRIMA di ripiazzarne uno: fra le due
chiamate la posizione e' senza stop. Se il ripiazzamento sollevava, l'eccezione risaliva
a main() e il guasto peggiore aveva la faccia di un errore qualunque. Ora: due tentativi,
poi stato `naked`, distinto da `place-failed` (P5). Non e' "non sono riuscito a
proteggere": e' "ho tolto la protezione e non sono riuscito a rimetterla" -> allarme
massimo, mai declassato. La SEQUENZA non e' stata invertita: piazza-poi-cancella sembra
piu' sicuro ma "sembra" non basta con soldi veri senza misurarlo.
ISOLAMENTO PER ASSET (scripts/live/book_execute.py)
Il 21/07 un 502 dentro ensure_disaster_sl su BTC ha ucciso il giro intero: nel log ETH
non compare — ne' ribilanciato ne' verificato nella protezione. Ora un asset che esplode
non ferma il ciclo, e il giro degradato esce con codice 2.
CRON :07 -> :47
Il vincolo vero non era ":07" ma "fuori dai ~26s del minuto tondo" (rate-limit per-IP
auto-saturato dal collettore catena, misura del 30/07). Il :47 lo soddisfa e in piu' sta
fuori dallo slot di release. PREVISIONE DICHIARATA (M12): 3 delle 4 finestre osservate
sono rientrate entro l'ora -> il :47 ne avrebbe scavalcate 3 su 4; se martedi' prossimo
becca comunque la manutenzione, la previsione e' sbagliata.
WATERMARK AVVELENATO DAI TEST (tests/conftest.py, nuovo)
Trovato addosso: lanciando la suite, data/live/equity_seen.json passava a $5.000 e il giro
successivo mandava un allarme Telegram FALSO ("USCITA DI FONDI -86,6%"). Non cosmetico:
cap_fallback = min(cap_config, watermark x frac) sarebbe passato da $334 a $2.500/asset,
~7,5x di leva su un conto da $668, sul ramo eq_fallback che allerta e NON blocca — cioe'
i test potevano armare il pericolo che il watermark esiste per impedire. Riparato con una
fixture AUTOUSE, non per-test: chiedere a ogni autore di ricordarsene ha gia' perso il
26/07 e il 21/08. Resta esposto lo stesso errore su trades.db e book_executions.jsonl.
BLOCCATO, NON RINVIATO
Il fallback diretto ai privati Deribit richiede chiavi API create dall'operatore: in
locale esiste solo CERBERO_TOKEN. Il gateway resta un punto singolo di guasto non
aggirabile (CLAUDE.md 5.11). La sonda dice di chi e' il guasto, non lo aggira.
Test: 20 nuovi, nessuno tocca la rete; controllo positivo fatto (5 su 7 falliscono contro
il codice vecchio). Suite 730 passati, 1 fallito — quello gia' noto di 5.9 (deriva dati).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1
45 lines
3.0 KiB
Bash
Executable File
45 lines
3.0 KiB
Bash
Executable File
#!/bin/bash
|
|
# BOOK DERIBIT-ONLY (TP01+SKH01 nettati) — esecuzione LIVE a cadenza ORARIA. v2.0.0+.
|
|
# SKH01 decide su griglia 230m -> serve girare piu' spesso del daily; orario IDEMPOTENTE:
|
|
# riconcilia al target NETTO corrente (se non cambia nulla -> HOLD). Il feed 5m fresco per il
|
|
# segnale SKH e' preso IN MEMORIA dentro book_execute (livefeed.fresh_5m): NON tocca i dati
|
|
# certificati su disco. Esecuzione reale gated da config/live.json (execution_enabled) + --execute.
|
|
#
|
|
# INSTALLATO AL MINUTO :47 (`47 * * * *`). Due vincoli, entrambi misurati — e questa riga deve
|
|
# restare d'accordo con la crontab: un commento che dichiara un minuto diverso da quello che gira
|
|
# e' lo stesso difetto del docstring "ogni ~230 minuti" (§5.7), e si paga quando qualcuno lo
|
|
# "corregge" nel verso sbagliato.
|
|
#
|
|
# 1. FUORI DAL MINUTO TONDO. Il collettore full-chain al :00 produce 12.186 risposte 429 in 26
|
|
# ore, di cui 11.700 (96%) dentro il minuto :00 — ~770 ticker + ~770 orderbook in ~26s da un
|
|
# IP solo, che si auto-saturano il rate-limit Deribit per-IP (misura del 2026-07-30). Il
|
|
# vincolo vero e' *stare fuori da quei ~26 secondi*: qualunque minuto != :00 lo soddisfa.
|
|
# Storia: :00 -> :07 il 2026-07-29 (ipotesi di contesa, dichiarata non verificata), :07 ->
|
|
# :47 il 2026-08-25.
|
|
# 2. FUORI DALLO SLOT DI RELEASE DERIBIT. Le release Deribit escono il MARTEDI' alle 09:00 UTC,
|
|
# annunciate 15-30 minuti. Il :07 cadeva dentro quella finestra, e ci e' caduto 4 volte in 63
|
|
# giorni: 2026-07-21 (che uccise anche il giro di ETH), 11/08, 18/08, 25/08. Il :47 lascia
|
|
# 47 minuti di margine dall'inizio dello slot, e 22 dal collettore catena del :25.
|
|
#
|
|
# ⚠️ PREVISIONE DA MISURARE (M12: un follow-up dichiarato contiene una previsione). Sulle 4
|
|
# finestre osservate, 3 sono rientrate entro l'ora (21/07, 11/08, 25/08 ~20 min) e una no (18/08,
|
|
# giu' anche alle 10:07). Il :47 avrebbe quindi scavalcato 3 episodi su 4. Se al prossimo martedi'
|
|
# il :47 becca comunque la manutenzione, la previsione e' sbagliata e lo slot non e' quello che
|
|
# credo: rileggere `venue_probe.RELEASE_*` prima di spostare ancora.
|
|
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_book ====="
|
|
# Tripwire di venue PRIMA dell'esecuzione: se Deribit e' in stress l'allarme deve
|
|
# partire anche quando book_execute fallisce per la stessa ragione. Non blocca (exit 2
|
|
# = allarme inviato); l'azione a un allarme e' manuale, vedi src/live/venue_watch.py.
|
|
uv run python scripts/live/venue_watch.py --quiet || true
|
|
uv run python scripts/live/book_execute.py --execute
|
|
# Libro di bordo: materializza in data/live/trades.db (che il backup COPRE) l'ora vera dei
|
|
# fill, che altrimenti vive solo in questo log — gitignored, fuori dal backup e ruotabile.
|
|
# Va DOPO book_execute: dentro lo stesso blocco vede le righe appena scritte.
|
|
uv run python scripts/live/trades_db.py --sync --quiet || true
|
|
echo "===== done $(date -u '+%H:%M:%SZ') ====="
|
|
} >> logs/cron_book.log 2>&1
|