PythagorasGoal/docs/diary/2026-07-30-assorbimento-cerbero-bite.md

# 2026-07-30 (2º filone) — cerbero-bite viene eliminato: assorbita la raccolta, non il motore

**Decisione dell'operatore:** `/opt/docker/cerbero-bite` viene smantellato e il suo lavoro passa a
PythagorasGoal. **Esito:** book, pesi, config e strategia INVARIATI. Cambia solo *chi* raccoglie
la catena opzioni — e cambia in meglio su tre assi misurati.

## Cosa di bite valeva la pena, e cosa no

L'unica parte **irreversibile** è il dato: una catena opzioni non si ricostruisce a posteriori
(Deribit non serve book storici, non esiste un secondo venue). Tutto il resto è codice, e il codice
si riscrive.

| parte | assorbita? | perché |
|---|---|---|
| `option_chain_snapshots` (1.23M righe) | **sì** | ha appena falsificato il *f* di VRP01; irrecuperabile |
| `market_snapshots` (17.402 righe, 26/03+) | **sì** | dealer net gamma, gamma flip, rischio liquidazioni, funding cross: dati che il progetto non ha altrove |
| raccolta continua | **sì, riscritta** | senza, l'archivio si congela e "aspettare il crash" muore |
| `dvol_history` | no | `fetch_dvol.py` ha storia **più lunga** (2020+ vs 2026-05): copiarla sarebbe una seconda copia peggiore |
| motore credit-spread ETH | no | il progetto ha già la regola *niente short-vol da modello in deploy*; e il conto era a $52 contro un minimo di $720 |
| GUI, kill switch, dead-man, audit chain | no | PythagorasGoal ha già `venue_watch`, `edge_watch`, `monitor_health`, `fee_watch` |
| `decisions` / `positions` | no | 59 valutazioni d'ingresso, 0 posizioni |

Prima di toccare qualsiasi cosa: snapshot `VACUUM INTO` del DB (461 MB) + `audit.log` + config in
`/opt/docker/backups/manual/cerbero-bite-20260730/`, con SHA256.

## Il collettore nuovo — tre difetti di bite non replicati

`scripts/live/collect_chain.py`, cron **`25 * * * *`**.

**1. Una chiamata per strumento invece di due.** `public/get_order_book?depth=3` restituisce già
quote, greche, IV, open interest, volume, book **e** `underlying_price`. Bite chiamava ticker e
orderbook separatamente: doppio costo, e i due potevano riferirsi a istanti diversi.
Un `get_book_summary_by_currency` iniziale dà l'OI di tutta la catena in **una** chiamata e
prefiltra sotto soglia: 551 → **~290 chiamate per asset**.

**2. Pacing invece di raffica.** ⚠️ **Il carico non è mai stato il problema.** ~570 chiamate/ora
sono **0.16/s** se distribuite; bite le sparava in ~26 secondi (**~44/s**) e si auto-saturava il
rate limit per-IP — 12.186 risposte 429 in 26 ore, il 96% nel minuto `:00`. Token bucket a 4/s +
backoff: primo giro reale **574 chiamate, 0 risposte 429**.

Il minuto `:25` è una scelta, non un default: `:00` era la raffica di bite, `:07` è `cron_book`
(da lì passa il feed 5m di SKH01, la cosa che non deve trovare l'IP occupato).

**3. Stato esplicito della quota.** `quote_status` ∈ {`ok`, `no_quote`, `error`}:
- `no_quote` = il venue ha risposto, il book è vuoto → **fatto di mercato**
- `error` = la chiamata è fallita → **fatto di infrastruttura**

Bite li faceva collassare entrambi su "riga con bid/ask NULL", ed è per questo che il guasto del
29/07 (50% di quote perse per 38 ore) non ha prodotto **nessun** segnale: il conteggio righe non
cambiava. Per lo stesso motivo `book_depth_top3` ora è **NULL su errore, mai 0** — bite scriveva 0,
e "chiamata fallita" diventava indistinguibile da "book vuoto".

⚠️ Le righe ereditate portano `quote_status='unknown'`. Bite non registrava il perché e **a
posteriori non è ricostruibile**: si dichiara l'ignoranza invece di inventare uno stato.

## Il silenzio, di nuovo

Un collettore fermo non produce niente, e il niente si legge come "nessun dato quel giorno" invece
che come "raccolta rotta" — su una serie irrecuperabile è il modo più caro di sbagliare. Ogni giro
scrive una riga in `data/chain_collect/runs.jsonl`, **anche quando fallisce**, e
`monitor_health` la sorveglia con cadenza 1h e `max_age_h=3` (due giri persi). È la stessa lezione
di `paper_dvolspread` e di `fresh_5m`, applicata prima che serva invece che dopo.

## Un difetto trovato per strada: due formati ISO nella stessa colonna

L'import del contesto restituiva **17.310 righe dal 2026-05-01** contro le 17.402 dal **2026-03-26**
del database. 92 righe di backfill sono scritte senza microsecondi
(`2026-03-26T12:00:00+00:00`), le altre con (`2026-05-01T15:45:00.062918+00:00`).
`pd.to_datetime` senza `format` **inferisce un formato solo** dal primo elemento e manda gli altri
a `NaT`, che il `dropna` a valle rimuoveva **in silenzio**: la serie perdeva i suoi 5 settimane più
vecchi e la data d'inizio slittava di un mese senza un messaggio.

Corretto con `format="ISO8601"` **e** con uno scarto rumoroso (`_drop_unparsed` stampa quante righe
cadono e perché). **REGOLA: `dropna` dopo un parsing è un rilevatore di difetti travestito da
pulizia — se toglie righe deve dirlo.** Un import silenzioso non è un import pulito, è un import
che non sai se ha funzionato.

## Eliminazione (stessa sera, 21:20 UTC)

Container rimossi, volume `cerbero-bite_bite-data` rimosso, immagine `cerbero-bite:dev` rimossa,
`/opt/docker/cerbero-bite` cancellata. **12 GB liberati** (73G → 61G di disco usato).

Prima di cancellare, quattro verifiche — nessuna delle quali era "il backup esiste":

1. **Lo snapshot è *completo*, non solo integro.** SHA256 `OK` su entrambi i file, ma soprattutto
   conteggi confrontati tabella per tabella fra il volume vivo e lo snapshot: `option_chain_snapshots`
   1.232.212, `market_snapshots` 17.406, `decisions` 59, `positions` 0 — **4 su 4 identici**, e
   identici anche ai parquet importati. *Un hash prova che il file non è corrotto, non che contenga
   tutto.*
2. **I 10,6 GB di backup interni al volume non contenevano dati unici.** 32 snapshot sqlite storici:
   la domanda giusta non era la loro dimensione ma *se bite potasse lo storico*. Tutti e tre i
   campioni controllati (09/06, 01/07, finale) hanno **la stessa riga più vecchia**
   (`2026-05-01T20:53:49.294928`) e conteggi monotoni crescenti (218.500 → 665.949 → 946.990 →
   1.232.212) → nessuna potatura, sottoinsiemi stretti del DB finale.
3. **Nessuna dipendenza a runtime.** Né cron, né systemd, né route traefik, né altri progetti: i
   soli riferimenti rimasti sono documentazione (questo diario, CLAUDE.md, un commento in
   `backup.sh` e uno in `health-watch.py`) — cioè memoria storica, che è corretto lasciare.
4. ⚠️ **`cerbero-mcp` è un progetto DIVERSO e serve a PythagorasGoal** (universo Hyperliquid, e il
   percorso del conto): progetto compose separato, e la rete `traefik` che condividono è dichiarata
   `external:` nel compose di bite → `down -v` non la tocca. Verificato dopo: `Up 41 hours
   (healthy)`. *Due servizi con lo stesso prefisso nel nome sono un incidente che aspetta.*

Il codice non è stato cancellato: era già su Gitea (`Adriano/Cerbero-Bite`), e l'unica modifica
locale pendente — il ripiego del collector da `:00` a `:20`, superato dal successore — è stata
committata e pushata come commit di dismissione. **Il dato era l'unica parte irreversibile.**

**REGOLA: prima di cancellare una sorgente si verifica che la copia sia completa, non che
esista** — e "quanto è grande" non è la domanda da fare a un backup, "cosa contiene che l'originale
non ha più" sì.

### Il primo giro dopo l'eliminazione, e un modo di leggere male il nostro stesso indicatore

Verificato invece che dedotto (21:25 UTC, il primo giro con bite già cancellato):
**576 chiamate, 0 risposte 429, 0 errori.** È il controllo che conta, perché il guasto del 29/07
era esattamente la raffica di bite che saturava il rate limit per-IP.

| giro | righe | ok | no_quote | error | **due lati** |
|---|---|---|---|---|---|
| 20:00 | 570 | 552 | 17 | 1 | 71.6% |
| 20:06 | 570 | 570 | 0 | 0 | 75.8% |
| 20:22 | 570 | 570 | 0 | 0 | 75.6% |
| 20:25 | 570 | 570 | 0 | 0 | 75.6% |
| **21:25** | **572** | **572** | **0** | **0** | **75.5%** |

(Il `1 error / 17 no_quote` delle 20:00 è il primo giro in assoluto, con bite ancora acceso a
sparare al minuto `:00`: la firma del problema, catturata nel suo ultimo momento di vita.)

⚠️ **`ok = 572` non significa "572 quote complete".** Nel collettore `ok` vuol dire *almeno un lato
del book* (`bid is not None or ask is not None`); le righe con **entrambi** i lati sono **432 su
572 (75.5%)**. Il resto sono book a un lato solo, normali sulle opzioni molto OTM. Che sia
strutturale e non un degrado si vede dal fatto che la percentuale è **identica a tutti i giri**,
prima e dopo l'eliminazione — non dal fatto che sembri alta.

È la lezione «*una riga presente non è un dato presente*» un livello più in giù, applicata allo
strumento costruito **per** quella lezione: la battuta di cuore distingue `ok`/`no_quote`/`error`,
quindi vedrebbe il guasto del 29/07 (quote vuote), ma **non** vedrebbe una deriva più sottile —
book che diventano progressivamente a un lato solo. Non è cablata una soglia: con cinque giri di
storia sarebbe inventata, e una soglia inventata è peggio di nessuna soglia. **La colonna da
guardare quando ci saranno settimane di serie è "due lati %".**

## File

- `scripts/live/collect_chain.py` + `scripts/cron_chain.sh` — la raccolta (cron `25 * * * *`)
- `scripts/analysis/import_cb_archive.py` — import una-tantum dell'archivio
- `scripts/analysis/certify_cb_chain.py` — certificazione dello store (era `fetch_cb_chain.py`)
- `scripts/research/cblib.py` — `load_chain()` ora unisce archivio + raccolta
- `src/live/monitor_health.py` — nuovo spec `collect_chain`
- `tests/test_collect_chain.py` (11 casi)

## Addendum (stessa sera) — spegnimento, backup, ripresa dopo un riavvio

**Spegnimento.** Prima di fermare i container ho preso uno snapshot **finale** (bite aveva raccolto
fino alle 20:15, oltre il backup delle 19:55) e ho reimportato: archivio a **1.232.212 righe**.
Consegna verificata: ultima riga di bite 20:15:00, prima nostra 20:00:18 → **sovrapposizione, nessun
buco**. `docker compose stop` (non `down -v`: i volumi restano). Effetto misurato: **0 risposte 429**
su cerbero-mcp nei minuti successivi, contro ~650 per ogni giro orario.

**Backup.** `data/raw/` è gitignored e il backup rotativo della VPS non copriva PythagorasGoal: dopo
lo spegnimento di bite l'archivio esisteva in due copie **sullo stesso disco**. Aggiunta
`do_pythagoras` a `/opt/docker/scripts/backup.sh` con un criterio dichiarato: **si salva ciò che non
si può riscaricare**. Dentro: catena + contesto, `data/paper_*` e `data/chain_collect` (serie
forward-only che alimentano i gate pre-registrati — non ricalcolabili per costruzione),
`options_daily`, `live`, `venue_watch`, `fee_watch`, `config/live.json` → **28 MB**. Fuori: i ~110 MB
che si riscaricano dai venue.

Due guardie, entrambe provate **nei due versi**: la funzione fallisce se la catena è assente o
vuota (invece di produrre un archivio che sembra a posto), e verifica che il tar prodotto contenga
davvero la catena. Il caso negativo produce **0 file**. Per poterlo provare la radice è
sovrascrivibile via `PYG_ROOT` — *una guardia che non si riesce a far scattare non è distinguibile
da una rotta.*

⚠️ `/opt/docker/scripts` **non è un repo git**: quella modifica vive solo su disco, e questo diario
è l'unico posto in cui è scritta.

**Riavvio.** La raccolta riprende da sola: `cron` è `enabled` e `active`, e il collettore non
dipende da docker né da cerbero-mcp (API pubblica Deribit diretta) — il contrario di bite, che era un
container. Verificato girando `cron_chain.sh` con `env -i PATH=/usr/bin:/bin`: 574 chiamate, 0
errori, dato e battuta di cuore scritti. ⚠️ **Finestra scoperta: fino al `:25` successivo, senza
recupero.** Il collettore non fa catch-up e non potrebbe: le quote passate non sono richiedibili.