live(feed): l'allerta funzionava, la sua CAUSA era una riga cablata

Il 29/07 il feed 5m di SKH01 e' ricaduto sul certificato in 6 giri orari su 8
(eta' 265->685 min, +60 a ogni giro = firma esatta del fallback): latenza
d'uscita da ~1h a ~11h, book flat, nessuna posizione esposta. L'allerta del
26/07 ha segnalato 6/6, poi ha stampato un perche' che non aveva misurato —
la nota "fetch pubblico KO" era cablata, identica in ogni caso, compreso
quello in cui la coda fresca E' attaccata e il vecchio e' il certificato.

E la causa vera non era recuperabile per costruzione: _fetch_recent_5m ingoia
l'eccezione di pagina con un break e a prima pagina fallita ritorna un frame
vuoto, indistinguibile da "il venue non ha barre".

Cablato: livefeed.last_fetch_error() (registra E logga nel punto in cui
l'errore viene ingoiato) -> book_report.skh_feed_errors -> allerta con la
causa. Stesso buco chiuso sul ramo gemello "conto offline", che la ragione
l'aveva gia' in mark_src e non la stampava mai.

La causa del 29/07 resta IGNOTA e va citata cosi': una prima stesura la
attribuiva a un rate limit per-IP come se fosse un fatto -> rimossa, sarebbe
stato lo stesso difetto che stavo correggendo scritto meglio. Cron spostato
al minuto :07 come ripiego da UNA osservazione, dichiarato tale.

Test 11 -> 16 (incluso il caso a meta' paginazione: coda parziale attaccata,
mancano le barre PIU' recenti). Book/pesi/config/strategia INVARIATI.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -711,6 +711,40 @@ Prima ondata di ricerca onesta su BTC/ETH certificati (5 track, harness condivis
   **Scelta dichiarata: ALLERTA, NON blocca** — bloccare fermerebbe anche TP01 (nettato sullo stesso
   strumento) per un guasto di rete, e forzare SKH flat chiuderebbe posizioni buone su un glitch.
   Test `tests/test_skh_feed_freshness.py` (11 casi). Strategia/pesi/cadenza INVARIATI.
+  ⚠️ **SEGUITO 2026-07-29 — l'allerta ha funzionato, la sua CAUSA era una riga CABLATA.** Diario
+  `2026-07-29-feed-skh-causa.md`; test 11 → **16**. **Book/pesi/config/strategia INVARIATI.**
+  Il 29/07 (dopo il riavvio VPS delle 04:11) il feed e' ricaduto sul certificato in **6 giri orari
+  su 8** fra le 05:00 e le 12:00: eta' **265→685 min** (+60 a ogni giro = firma esatta del fallback)
+  → latenza d'uscita SKH01 da ~1h a **~11h**; book flat, nessuna posizione esposta. L'allerta ha
+  segnalato 6/6 — poi ha stampato un perche' che **non aveva misurato**: la nota *"fetch pubblico
+  KO"* era cablata, identica in ogni caso, **compreso quello in cui la coda fresca E' attaccata e il
+  vecchio e' il certificato stesso** (= feed-freeze 14/07 in altra veste). E la causa vera non era
+  recuperabile a posteriori **per costruzione**: `_fetch_recent_5m` ingoia l'eccezione di pagina con
+  un `break` e a prima pagina fallita ritorna un frame vuoto, indistinguibile da "il venue non ha
+  barre"; alle 12:14, a mano, `fresh_5m` rispondeva in 1.7s senza errori.
+  ✅ **Cablato:** `livefeed.last_fetch_error()` (+`_note_error`, registra E logga nel punto in cui
+  l'errore viene ingoiato) → `book_report.skh_feed_errors` (per asset) → allerta con la causa; e
+  stesso buco chiuso sul ramo gemello **"conto offline"**, che aveva gia' la ragione in `mark_src`
+  e non la stampava mai. Tre guasti ora distinti: eccezione / risposta vuota / **certificato
+  vecchio con coda attaccata**. Blindati anche il caso a **meta' paginazione** (coda parziale
+  attaccata: la paginazione va in avanti → mancano le barre PIU' RECENTI) e la non-sopravvivenza
+  della causa a una chiamata riuscita.
+  ⚠️ **La causa del 29/07 resta IGNOTA, e va citata cosi'.** Solo circostanziale: giri falliti
+  lunghi quanto i riusciti (**16-46s → errore immediato, non timeout**); finestra aperta col riavvio
+  ma non chiusa da esso (11:00 ok, 12:00 no); stesso giorno il percorso del **conto** (rete diversa
+  via `cerbero-mcp`, stesso venue a valle) dava `ReadTimeout/404/502`; i due percorsi falliscono **in
+  alternanza**, non insieme. Una prima stesura scriveva nei commenti "*rate limit Deribit per-IP
+  saturato da un altro progetto sulla stessa VPS*" **come fatto**: rimossa — sarebbe stato lo stesso
+  difetto che stavo correggendo, scritto meglio. **Cron spostato `0 * * * *` → `7 * * * *`**
+  (ipotesi contesa al minuto tondo): ripiego da **UNA** osservazione, costo zero, **dichiarato tale
+  in testa a `cron_book.sh`** perche' la riga di crontab vive fuori dal repo.
+  **REGOLE:** (a) **una nota di diagnosi cablata e' peggio di nessuna nota** — nessuna manda a
+  guardare i dati, una sbagliata manda sulla pista sbagliata e sembra una misura; (b) se un errore
+  si ingoia per non bloccare, **si registra nel punto in cui lo si ingoia** (non c'e' un secondo
+  momento buono: quando la diagnosi serve, il guasto e' rientrato); (c) un'allerta risponde a **due**
+  domande — *cosa* (decide) e *perche'* (ripara): misurare solo la prima costa un'intera occorrenza
+  del guasto; (d) distinguere guasti diversi **anche quando l'azione e' la stessa** (tre cause → tre
+  riparazioni); (e) una mitigazione da un'osservazione sola si applica pure, ma **si scrive che lo e'**.
   ✅ **FOLLOW-UP CHIUSO 2026-07-26 — la misura dedicata sugli INGRESSI e' fatta: NON e' un difetto,
   il verso e' LASCIARLO.** `scripts/research/r0726_skh_partial_entry.py`, test
   `tests/test_skh_partial_entry.py` (10), diario `2026-07-26-skh-partial-entry.md`.