research(gtaa): l'assenza di API DEGIRO vale -0.02 di Sharpe, non e' squalificante

Domanda dell'operatore: "degiro ha api?". Fatto: no, non ufficiale; Revolut nemmeno
(la sua e' per pagamenti); IB si'. I wrapper non ufficiali girano su credenziali +
seed 2FA e si rompono IN SILENZIO a ogni cambio di front-end — e il progetto ha gia'
pagato quel prezzo con fresh_5m il 26/07. Un esecutore che puo' rompersi senza dirlo
e' peggio dell'esecuzione manuale.

Misurato il costo di NON automatizzare invece di discuterlo:
  carico operativo: 15 settimane/anno con >=1 ordine (29% dei controlli, 1.4 per volta)
  ritardo 1g  -0.02 Sharpe (peggiora in 6/11 anni = moneta)
  ritardo 3g  -0.13
  ritardo 10g -0.27

Il costo non e' il ritardo tipico ma la coda: il rischio dell'operativita' manuale e'
la dimenticanza, e si copre con un allarme, non con una API (gtaa_rebalance_plan esiste
gia' in produzione ed e' nato per un esecutore).

Nota di metodo: sulla finestra UCITS di 3.2 anni la curva del ritardo NON e' monotona
(5g -0.26, 10g -0.13) -> il campione corto non risolve differenze di questa taglia,
quindi il numero si legge sulla finestra lunga a 10 anni, dove lo e'.

Book, pesi, cron, config INVARIATI.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XBbYmiXqbUNuGpK9sfbsGp

CLAUDE.md

@@ -1120,6 +1120,22 @@ Prima ondata di ricerca onesta su BTC/ETH certificati (5 track, harness condivis
   **LEZIONE: una raccomandazione poggiata su un fatto non verificato sul conto reale vale quanto
   quel fatto** — due volte in due giorni un'assunzione sul conto ha cambiato la conclusione (prima
   la negoziabilita' PRIIPs, poi quale conto e' davvero operativo).
+  (e) **"degiro ha api?" — NO, e costa −0.02 di Sharpe.** DEGIRO non espone una API di trading
+  ufficiale al retail; Revolut nemmeno (la sua e' per pagamenti); IB si'. I wrapper NON ufficiali
+  degli endpoint interni girano su credenziali + seed 2FA e **si rompono in silenzio** a ogni cambio
+  di front-end — e il progetto ha gia' pagato quel prezzo (`fresh_5m`, 26/07): **un esecutore
+  automatico che puo' rompersi senza dirlo e' peggio dell'esecuzione manuale.** Misurato invece il
+  costo di NON automatizzare: carico operativo **15 settimane/anno con ≥1 ordine** (29% dei
+  controlli, 1.4 ordini per volta); costo del ritardo su 10 anni **1g −0.02 (peggiora in 6/11 anni
+  = moneta), 3g −0.13, 10g −0.27**. ⚠️ Sulla finestra UCITS di 3.2 anni la curva NON e' monotona
+  (5g −0.26, 10g −0.13) → il campione corto non risolve differenze di questa taglia, si legge la
+  finestra lunga. **Il costo non e' il ritardo tipico ma la CODA: il rischio e' la dimenticanza, e
+  si copre con un ALLARME non con una API** (`gtaa_rebalance_plan` esiste gia' in produzione, nato
+  per un esecutore; l'allerta Telegram c'e' gia' sul book live). ⚠️ Lato opposto, vero: il resto del
+  book e' automatico, una gamba manuale aggiunge un modo di fallire che oggi non c'e' — argomento
+  reale a favore di IB, che pero' richiede un secondo venue e quindi cade sotto la decisione venue
+  ($20k). **REGOLA: una capacita' mancante si valuta sul costo di non averla, non sulla sua
+  assenza.**
 - ⚠️ **IL FEED EQUITY NON AVEVA UN CROSS-CHECK — buco trovato e chiuso (2026-07-26).**
   `src/data/eq_crosscheck.py`. Nel crypto la certificazione incrocia sempre piu' venue
   (`certify_feed.py` vs Coinbase USD); il feed equity aveva **solo controlli locali** (integrita',