feat: EDGE WATCH — criteri di kill pre-registrati per il book LIVE

"Come faccio a capire se l'edge e' morto?" scopre un buco: il progetto ha gate di kill
pre-registrati per i CANDIDATI (DVOLSPREAD 24/10, XSR01 23/10, STATARB 27/09) e NESSUNO
per il book che gira con soldi veri. La risposta implicita era "si vedra'", cioe' quello
che il progetto non accetta dai candidati.

LA RISPOSTA SCOMODA: non si puo' sapere in fretta. Sharpe rolling a 12 mesi: il 56% dei
casi "edge morto" e' indistinguibile da uno vivo. Un anno brutto e' rumore, non
informazione.

CRITERIO A (ritorno, book intero): Sharpe rolling 36 mesi sotto -0.5. Tarato sul nullo
(edge intatto) -> falso kill 1.8% in 10 anni; controllo positivo (edge morto) -> lo
riconosce nel 91% dei casi, rilevamento mediano 3.8 anni. La lentezza non e' un difetto
della regola ma statistica: a 12 mesi la stessa regola ucciderebbe un edge VIVO nell'80%
dei casi. Non esiste una versione veloce e onesta.

CRITERIO B (TP01, che e' DIFENSIVO): serve un criterio diverso perche' il LOO del 26/07 ha
misurato il contributo hold-out di TP01 negativo nel 99.1% delle configurazioni d'ancora —
firma dell'assicurazione, che paga premio negli anni senza incendio. "Non ha guadagnato"
NON e' evidenza di morte. Criterio: in un anno con DD buy&hold > 10%, il DD di TP01 deve
restare sotto il 75%. Storico 8 anni di sinistro, 8/8 superati (protezione 1.8x-34.4x).
Negli anni SENZA sinistro il criterio non si valuta: non c'e' informazione. Questo criterio
e' VELOCE dove l'altro e' lento.

COSA SUCCEDE SE SCATTANO (dichiarato ora per non deciderlo nel momento sbagliato):
(A) il book NON si spegne da solo -> revisione con weights_tilt_null + deflated-Sharpe sui
dati nuovi; spegnere e' decisione dell'operatore. (B) fallito in DUE anni di sinistro
consecutivi -> TP01 non assicura piu' e il peso 75% va rimesso in discussione.

CABLATO: scripts/live/edge_watch.py in cron_daily.sh, allerta Telegram, non tocca
l'esecuzione. Stato oggi: Sharpe 36m +1.51, protezione 8/8.

IL LIMITE, DETTO: il criterio A rileva la morte ~4 anni dopo, e non e' riparabile con una
regola migliore (e' il contenuto informativo dei dati). La difesa vera e' che il piano
regge a un edge dimezzato (11.6 -> 15.8 anni, P(20a) ancora 77%) e che i rischi VELOCI
(venue, esecuzione, feed) hanno sorveglianze che scattano in ore.

404 test verdi (+11). Book, pesi, config INVARIATI.

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

docs/diary/2026-07-26-edge-death.md

@@ -0,0 +1,112 @@
+# 2026-07-26 — "come faccio a capire se l'edge è morto?"
+
+Domanda dell'operatore dopo la misura del decadimento. Scopre un buco: il progetto ha gate di kill
+**pre-registrati per i candidati** (DVOLSPREAD 24/10, XSR01 23/10, STATARB 27/09) e **nessuno per
+il book che gira con soldi veri**. La risposta implicita era "si vedrà" — cioè esattamente ciò che
+il progetto non accetta dai candidati.
+
+**Script:** `r0726_edge_death.py` (taratura) + `scripts/live/edge_watch.py` (sorveglianza, cablata
+in `cron_daily.sh`). **Test:** `tests/test_edge_watch.py` (11). **Book/pesi/config INVARIATI.**
+
+---
+
+## 1. La risposta scomoda: non puoi saperlo in fretta
+
+Con Sharpe ~1.6 e vol ~8%, un anno di risultati non distingue nulla. Distribuzione dello Sharpe
+rolling su 4.000 percorsi bootstrap, con edge **vivo** e con edge **morto** (drift a zero, stessa vol):
+
+```
+finestra    VIVO (p5..p50..p95)      MORTO (p5..p50..p95)    sovrapposizione
+     6m   -1.06   1.60   4.15      -3.24  -0.10   2.71            67.8%
+    12m   -0.24   1.62   3.43      -2.20  -0.04   1.99            56.0%
+    24m    0.34   1.64   2.92      -1.51  -0.02   1.44            34.6%
+    36m    0.57   1.62   2.68      -1.22  -0.03   1.19            21.1%
+```
+
+**A 12 mesi il 56% dei casi "morto" è indistinguibile da uno vivo.** Un anno brutto non è
+informazione, è rumore.
+
+## 2. La taratura: falsi kill contro velocità
+
+*"Sharpe rolling a N mesi scende sotto S almeno una volta in 10 anni"*, con edge **intatto** —
+cioè quanto spesso la regola ucciderebbe una strategia che funziona:
+
+```
+finestra     S<-0.5    S<0.0    S<+0.5
+     6m      100.0%   100.0%    100.0%
+    12m       80.5%    95.9%     99.5%
+    24m       14.1%    43.7%     78.8%
+    36m        1.8%    12.3%     43.2%
+```
+
+Con il controllo positivo (edge davvero morto) accanto:
+
+| finestra | soglia | falso kill | lo prende | rilevamento mediano |
+|---|---|---|---|---|
+| 12m | −0.5 | 80.5% | 100% | 1.1 anni |
+| 24m | −0.5 | 14.1% | 98.5% | 2.5 anni |
+| **36m** | **−0.5** | **1.8%** | **90.8%** | **3.8 anni** |
+
+**→ CRITERIO A: Sharpe rolling 36 mesi sotto −0.5.** Falso kill 1.8% in 10 anni, riconosce l'edge
+morto nel 91% dei casi, in **3.8 anni** mediani.
+
+⚠️ **La lentezza non è un difetto della regola: è statistica.** Una versione a 12 mesi ucciderebbe
+un edge vivo nell'80% dei casi. **Non esiste una versione veloce e onesta.**
+
+## 3. TP01 non si giudica così — e questo è il punto
+
+Il leave-one-out del 26/07 ha misurato il contributo hold-out di TP01 **negativo nel 99.1% delle
+configurazioni d'ancora**. È la firma dell'assicurazione: paga premio negli anni senza incendio.
+**"Non ha guadagnato" non è evidenza di morte per uno sleeve difensivo** — la sua morte è *non
+proteggere quando serve*.
+
+```
+ anno   DD buy&hold   DD TP01   protezione
+ 2019       56.4%      10.3%       5.5x
+ 2020       59.2%       8.4%       7.0x
+ 2021       52.0%       6.8%       7.6x
+ 2022       68.4%       2.8%      24.2x
+ 2023       22.0%      12.3%       1.8x   <- il peggiore, e passa comunque
+ 2024       35.6%       7.1%       5.0x
+ 2025       45.1%       6.8%       6.6x
+ 2026       46.6%       1.4%      34.4x
+```
+
+**→ CRITERIO B: in un anno con DD buy&hold > 10%, il DD di TP01 deve restare sotto il 75% di
+quello.** Storico: **8 anni di sinistro, 8/8 superati**. Negli anni **senza** sinistro il criterio
+non si valuta: non c'è informazione.
+
+Questo criterio è **veloce** dove l'altro è lento — si pronuncia a ogni anno con un crash, che nel
+campione è ogni anno.
+
+## 4. Cosa succede se scattano
+
+Dichiarato ora per non doverlo decidere nel momento sbagliato:
+
+* **(A) scatta** → il book **non si spegne da solo**. Si apre una revisione: `weights_tilt_null` +
+  deflated-Sharpe ricalcolato sui dati nuovi. Spegnere è una decisione dell'operatore.
+* **(B) fallito in due anni di sinistro consecutivi** → TP01 non assicura più, e il suo peso (75%)
+  va rimesso in discussione: proteggere è **l'unico motivo** per cui sta lì.
+
+Cablato in `cron_daily.sh`, allerta Telegram, non tocca l'esecuzione. Stato al 2026-07-26:
+**Sharpe 36m +1.51**, protezione **8/8**.
+
+## 5. Il limite, di nuovo
+
+Il criterio A misura se l'edge è morto **dopo** che è morto, con ~4 anni di ritardo. Questo non è
+riparabile con una regola migliore — è il contenuto informativo dei dati. La difesa vera non è la
+rilevazione: è che **il piano regge a un edge dimezzato** (misurato: traguardo da 11.6 a 15.8 anni,
+P(entro 20a) ancora 77%) e che i rischi *veloci* — venue, esecuzione, feed — hanno sorveglianze
+proprie che scattano in ore.
+
+## 6. Regole trasferibili
+
+1. **Se si pretende un gate di kill dai candidati, se ne deve avere uno per ciò che gira.**
+   L'asimmetria era invisibile finché non è stata nominata.
+2. **Un criterio di kill si tara sul nullo e si valida su un controllo positivo** — identico al
+   tripwire di venue costruito lo stesso giorno. "Non è mai scattato" non è una buona notizia
+   finché non si è provato che sa scattare.
+3. **Uno sleeve difensivo richiede un criterio DIVERSO**, o lo si uccide per aver fatto il suo
+   mestiere. Il criterio giusto guarda il sinistro, e negli anni senza sinistro **non si valuta**.
+4. **Quando la rilevazione è strutturalmente lenta, dirlo e spostare la difesa altrove** invece di
+   accorciare la finestra fino a ottenere una risposta veloce e falsa.