#!/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
  # LOCK SUL CONTO (#36): cuscino_watch (cron_cuscino.sh, :53) puo' mandare ordini spot USDE
  # sullo stesso conto — separati solo dal tempo, giri fino a 659s misurati. `flock -n` (mai
  # `-w`, un SIGTERM a meta' ordine perde la riga di log): se cuscino_watch tiene il lock questo
  # giro si SALTA (rc 75) invece di sovrapporsi. Niente kill/timeout sul comando.
  flock -n -E 75 logs/.conto.lock uv run python scripts/live/book_execute.py --execute; rc=$?
  [ $rc -eq 75 ] && echo "  book: SALTATO — conto occupato da un altro giro (logs/.conto.lock)"
  # 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. Fuori dal lock:
  # e' sola lettura, non tocca il conto.
  uv run python scripts/live/trades_db.py --sync --quiet || true
  echo "===== done $(date -u '+%H:%M:%SZ') ====="
} >> logs/cron_book.log 2>&1