Il giro delle 21:25 (primo con bite gia' cancellato): 576 chiamate, 0 risposte
429, 0 errori. E' il controllo che conta, perche' il guasto del 29/07 era la
raffica di bite che saturava il rate limit per-IP.
Aggiunta la tabella dei 5 giri della giornata, che mostra invarianza prima/dopo.
⚠️ E una precisazione sul nostro stesso strumento: 'ok' significa ALMENO UN LATO
del book, non quota completa. Con ok=572 le righe a due lati sono 432 (75.5%).
Che sia strutturale (opzioni molto OTM) e non un degrado si vede dall'invarianza
fra i giri, non dal fatto che il numero sembri alto.
E' 'una riga presente non e' un dato presente' un livello piu' in giu', applicata
allo strumento costruito per quella lezione: la battuta di cuore vedrebbe il
guasto del 29/07 (quote vuote) ma non una deriva verso book a un lato solo.
Nessuna soglia cablata: con 5 giri di storia sarebbe inventata, e una soglia
inventata e' peggio di nessuna soglia. La colonna da guardare e' 'due lati %'.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Container, volume, immagine e cartella rimossi il 2026-07-30 (12 GB liberati).
Book, pesi, cron, config INVARIATI: la raccolta era gia' passata al successore
e la sovrapposizione fra le due ha coperto la consegna senza buchi.
Le quattro verifiche, nessuna delle quali era 'il backup esiste':
1. Snapshot COMPLETO, non solo integro: SHA256 OK su entrambi i file, ma
soprattutto conteggi confrontati tabella per tabella fra volume vivo e
snapshot (1.232.212 / 17.406 / 59 / 0), identici anche ai parquet importati.
Un hash prova che il file non e' corrotto, non che contenga tutto.
2. I 10,6 GB di backup interni al volume non contenevano dati unici. La domanda
giusta non era la loro dimensione ma se bite potasse lo storico: tutti e tre
i campioni controllati hanno la STESSA riga piu' vecchia (2026-05-01T20:53:49)
e conteggi monotoni crescenti -> nessuna potatura, sottoinsiemi stretti.
3. Zero dipendenze a runtime: ne' cron, ne' systemd, ne' route traefik, ne'
altri progetti. I riferimenti rimasti sono documentazione, che resta.
4. cerbero-mcp e' un progetto DIVERSO e serve a PythagorasGoal (Hyperliquid,
percorso del conto). Progetto compose separato; la rete traefik condivisa e'
external: nel compose di bite, quindi down -v non la tocca. Verificato dopo:
Up 41 hours (healthy). Due servizi con lo stesso prefisso sono un incidente
che aspetta.
Il codice non e' stato perso: era su Gitea (Adriano/Cerbero-Bite) e l'unica
modifica pendente e' stata committata la' come commit di dismissione.
REGOLA: prima di cancellare una sorgente si verifica che la copia sia COMPLETA,
non che esista.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
data/raw/ e' gitignored e /opt/docker/scripts/backup.sh non copriva questo
progetto: dopo lo spegnimento di cerbero-bite la catena opzioni esisteva in
due copie SULLO STESSO DISCO.
Aggiunta do_pythagoras con criterio dichiarato — si salva cio' che non si
puo' riscaricare:
dentro (28 MB): catena + contesto, data/paper_* e data/chain_collect
(serie forward-only che alimentano i gate pre-registrati: non sono
ricalcolabili, sono un registro di cosa si sapeva e quando),
options_daily, live, venue_watch, fee_watch, config/live.json
fuori (~110 MB): quanto si riscarica dai venue (rebuild_history, fetch_dvol,
fetch_hyperliquid, fetch_ib_equities) + cache
Due guardie provate nei DUE versi: fallisce se la catena e' assente o vuota
invece di produrre un archivio che sembra a posto, e verifica che il tar
contenga davvero la catena (caso negativo: 0 file prodotti). La radice e'
sovrascrivibile via PYG_ROOT solo per poter far scattare la guardia.
Verificato che dopo un riavvio la raccolta riprenda da sola: cron enabled +
active, nessuna dipendenza da docker o cerbero-mcp; giro provato con env -i
(574 chiamate, 0 errori). Finestra scoperta fino al :25 successivo, senza
catch-up.
/opt/docker/scripts NON e' un repo git: la modifica vive solo su disco, il
diario e' l'unico posto in cui e' scritta.
Book, pesi, config, strategia INVARIATI.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cerbero-bite viene eliminato. L'unica sua parte irreversibile e' il DATO:
una catena opzioni non si ricostruisce a posteriori (Deribit non serve book
storici, non c'e' un secondo venue). Il codice si riscrive; le ore non
raccolte no.
ASSORBITO
- scripts/live/collect_chain.py + scripts/cron_chain.sh (cron 25 * * * *):
raccolta propria, ~570 strumenti/giro, ~3 min.
- scripts/analysis/import_cb_archive.py: archivio 1.23M righe (2026-05-01+)
+ market_snapshots 17.402 righe (2026-03-26+: dealer gamma, gamma flip,
rischio liquidazioni, funding cross — dati che non abbiamo altrove).
- snapshot sqlite integrale in /opt/docker/backups/manual/ (SHA256).
NON ASSORBITO, con motivo: motore credit-spread ETH (regola "niente
short-vol da modello in deploy", conto a $52 contro minimo $720), GUI, kill
switch/dead-man/audit (abbiamo venue_watch/edge_watch/monitor_health/
fee_watch), dvol_history (fetch_dvol.py ha storia PIU' LUNGA: 2020+ contro
2026-05), decisions/positions (0 posizioni).
TRE DIFETTI DI BITE NON REPLICATI, tutti misurati il 30/07:
1. una chiamata per strumento invece di due (get_order_book?depth=3 da' gia'
quote+greche+IV+OI+book+underlying) + prefiltro OI in una chiamata sola:
551 -> ~290 chiamate per asset;
2. pacing invece di raffica. Il carico non e' mai stato il problema: 570
chiamate/ora = 0.16/s DISTRIBUITE; bite le sparava in 26s (~44/s) e si
auto-saturava il rate limit per-IP (12.186 risposte 429 in 26h, 96% al
minuto :00). Primo giro reale: 574 chiamate, 0 risposte 429. Il minuto :25
e' scelto: :00 era la raffica, :07 e' cron_book (feed 5m di SKH01).
3. quote_status esplicito {ok, no_quote, error} e book_depth NULL su errore
mai 0. "Book vuoto" e "chiamata fallita" sono cose diverse: e' per questo
che il guasto del 29/07 (50% di quote perse, 38 ore) non produsse alcun
segnale. Le righe ereditate restano 'unknown': bite non lo registrava e a
posteriori non e' ricostruibile.
Battuta di cuore in data/chain_collect/runs.jsonl anche a giro fallito,
sorvegliata da monitor_health (1h, max_age 3h): un collettore fermo non
produce niente, e il niente si legge come "nessun dato quel giorno".
Difetto trovato per strada: due formati ISO nella stessa colonna (92 righe
di backfill senza microsecondi). pd.to_datetime senza `format` ne inferisce
uno solo e manda gli altri a NaT -> il dropna a valle li toglieva in
silenzio, e la serie di contesto perdeva 5 settimane slittando dal 26/03 al
01/05. Corretto con format="ISO8601" e scarto RUMOROSO.
Book, pesi, config, strategia INVARIATI. 537 test verdi.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adriano Dal Pastro