PythagorasGoal/docs/diary/2026-07-26-wave-tp01-partial-gates.md

# 2026-07-26-bis — Ondata: TP01 su barra parziale + i due gate mai costruiti

**Richiesta:** *"fai un'altra ondata di ricerca"*.
**Esito: 0 sleeve nuovi, 1 audit sul libro live, 2 gate codificati, 1 falso positivo del mio
stesso gate su uno sleeve in produzione (catturato e corretto), 1 replica indipendente di un
finding di tre settimane fa.**
**Book, pesi, cron, config: INVARIATI.**

Script: `scripts/research/r0726_tp01_partial_day.py`, `scripts/research/r0726_gates_retro.py`.
Test: `tests/test_gates_implausible_anchor.py` (13). Gate in `scripts/research/alt/altlib.py`.

Da dove nasce: il 26/07 ho misurato che il path live di SKH01 divergeva dal modello su entrambi
i lati (uscite e ingressi) e che **il modello era pessimistico**. Due domande restavano aperte, ed
erano piu' interessanti di un'ennesima caccia al segnale: *lo stesso difetto esiste sullo sleeve
che pesa il 75% del book?* e *perche' i gate che il progetto si e' raccomandato tre volte non
esistono ancora?*

---

## T1 — TP01 nel live legge una barra giornaliera fatta di UN'ORA

**Il fatto, verificato non dedotto.** `resample_tf(..., label="left", closed="left")` non scarta il
giorno in corso; `TrendPortfolio.current_target` prende `target_series(df)[-1]`. Il feed certificato
si ricostruisce alle 00:30 UTC, quindi per tutta la giornata il book vede il giorno corrente come
**1 barra oraria su 24** (misurato: `barre1h=1/24`). Il docstring diceva "ultima barra CHIUSA":
**falso nel live**, ed e' la terza volta in due giorni che un docstring di produzione afferma una
causalita' che il codice non ha.

**Due canali con segno atteso opposto**, quindi vanno separati:
- *esecuzione ritardata* — il modello ribilancia al confine 00:00, il live al primo cron dopo il
  rebuild (~01:00);
- *barra parziale* — `c[t]` e' il prezzo delle 01:00 e `r[t]` e' un rendimento di **un'ora** contato
  come giornaliero nella finestra di vol a 30 barre → vol sottostimata → **sovra-leva sistematica**.

**Tre path, un grado di liberta' per volta**, su griglia oraria (i confini sono diversi: solo
l'orario li rende confrontabili):

| offset 0 (ancora canonica) | FULL | HOLD | maxDD |
|---|---:|---:|---:|
| MODEL — `tgt[t-1]` dal confine 00:00 | 1.30 | 0.24 | 16.7% |
| CLOSED@+1h — scarta la parziale, ora del live | 1.27 | 0.16 | 17.5% |
| LIVE — `tgt[t]` da barra parziale, +1h | 1.25 | −0.07 | 17.5% |

**Banda delle 24 ancore, mediana delle DIFFERENZE APPAIATE:**

| effetto | FULL | HOLD |
|---|---|---|
| barra parziale (LIVE − CLOSED) | **−0.031** [−0.135,+0.065], pos. 7/24 | **+0.118** [−0.230,+0.277], pos. 19/24 |
| ritardo 1h (CLOSED − MODEL) | −0.004 [−0.053,+0.034], pos. 11/24 | −0.007, pos. 9/24 |
| totale (LIVE − MODEL) | −0.046, pos. 7/24 | +0.128, pos. 18/24 |

Leva LIVE/MODEL: **1.004** (mediana, invariata su tutta la banda).

**Verdetto: trascurabile.** Il ritardo d'esecuzione e' letteralmente una moneta (11/24). La barra
parziale muove ±0.03 su FULL e la sua "vittoria" su HOLD (+0.118) e' su una finestra sola e con
segno opposto su FULL — cioe' esattamente il profilo che il progetto ha gia' codificato come
sospetto. La sovra-leva prevista esiste ma vale **0.4%**. Nessun cambio al live.

**⚠️ Da notare: all'ancora canonica il quadro sembra peggiore del vero.** A offset 0 la barra
parziale costa **−0.230** sull'hold-out, che e' il **minimo dell'intera banda** — mentre la mediana
e' +0.118. Guardando solo l'ancora canonica avrei concluso "il live degrada TP01 di 0.23 sull'hold-out"
e sarebbe stato l'artefatto di un'ancora. E' la stessa lezione del 26/07 in versione speculare
(li' l'ancora canonica *nascondeva* un vantaggio, qui *inventa* un danno).

**Il risultato trasferibile non e' il numero, e' il perche'.** La parzialita' dell'ultima barra conta
in proporzione a **quanto il segnale pesa la barra piu' recente**:

> SKH01 e' un Donchian breakout su barra 230m: **la barra corrente E' il segnale** → stesso difetto,
> **+0.38** di Sharpe mediano. TP01 e' un TSMOM 30/90/180 giorni: l'ora mancante e' 1/24 di **una**
> osservazione su 30-180 → **±0.03**.

Corollario operativo: la conclusione di uno sleeve su questo tema **non si trasferisce** all'altro,
e la domanda "il mio live legge barre parziali?" ha una risposta diversa per ogni sleeve a seconda
della lunghezza del lookback. Cablato nei docstring di `current_target` e `resample_tf`.

---

## T2 — I due gate raccomandati tre volte e mai scritti

Debito dichiarato: `implausible_sharpe` (raccomandato il 26/06 su CC01, ri-raccomandato "con piu'
forza" il 02/07 su Albimarini) e `anchor_luck_band` (dichiarato "candidato gate futuro" il 02/07,
dopo il timing-luck trovato su 4/4 sleeve ancorati). Tre occorrenze, tre diagnosi a mano, zero codice.

### `implausible_sharpe`
Uno Sharpe/track troppo bello significa che **il rischio e' fuori dal dataset**, non che la strategia
sia buona. Trigger: Sharpe > 3, frazione di barre attive in perdita < 2%, Calmar > 20 o maxDD ~0, e
la **regola del tre** (0 perdite su N trade lascia un tasso vero fino a ~3/N — su un payoff deep-OTM
basta a ribaltare l'expectancy: e' il motivo per cui "0/142" non si legge come "senza rischio").

### `anchor_luck_band` + `anchor_luck_delta`
La griglia di ancore **non e' una griglia di parametri**, quindi il deflated-Sharpe non la conta: e'
multiple-testing invisibile. Il gate riporta la stima onesta (**mediana della banda**) e la fortuna
(canonica − mediana). `anchor_luck_delta` codifica l'errore che ho commesso stamattina: fra offset
appaiati la statistica e' la **mediana delle differenze**, non la differenza delle mediane — le due
mediane cadono su offset diversi e il verdetto puo' ribaltarsi.

### ⚠️ Il gate ha segnalato VRP01. Il difetto era MIO.
Prima stesura: perdite contate su **tutte** le barre. VRP01 e' settimanale su griglia giornaliera →
**94.2% di zeri** → "0.96% di perdite, coda sinistra assente" su uno sleeve **in produzione al 12%**.
Sulle barre **ATTIVE** le perdite sono **16.5%**, che e' esattamente la forma attesa di un credit
spread a rischio definito.

Verifica: zeri per sleeve — VRP01 94.2%, SKH01 87.6%, XS01 39.6%, GTAA01 31.9%, TP01 30.7%. Un gate
che conta gli zeri come "non perdite" avrebbe finito per segnalare mezzo book.

Ed e' la parte che vale la pena ricordare: **avevo gia' imparato questa lezione ieri**, cablando la
contabilita' a 3 stati del monitor DVOLSPREAD ("finestra misurata in barre attive, non giorni di
calendario"), e l'ho ripetuta il giorno dopo in un contesto diverso. Ora e' un test.

### Esito dell'applicazione retroattiva — copertura 7/7

| | Sharpe | maxDD | perdite/attive | esito |
|---|---:|---:|---:|---|
| TP01 | 1.29 | 14.3% | 48.7% (1865) | ok |
| XS01 | 1.36 | 10.9% | 46.6% (566) | ok |
| VRP01 | 1.08 | 11.9% | 16.5% (109) | ok |
| SKH01 | 1.45 | 18.1% | 55.6% (333) | ok |
| GTAA01 | 1.01 | 8.9% | 45.2% (1831) | ok |
| XSR01 (monitor) | 1.79 | 2.5% | 47.8% (892) | ok |
| DVOLSPREAD (monitor) | 0.68 | 25.5% | 50.8% (1949) | ok |

Controlli positivi (obbligatori: un gate che non segnala nulla puo' essere semplicemente rotto):
firma CC01 e firma deep-OTM **segnalate** con le motivazioni giuste; rumore a Sharpe 0.62 **non**
segnalato.

**Nota che vale per XSR01**, il cui gate di deploy scade il 23/10: il suo maxDD del 2.5% *non* e'
una coda mancante — il **47.8%** delle barre attive e' in perdita. Il DD basso viene da vol bassa
(2.3%) e dollar-neutrality. Il rischio #1 di XSR01 resta lo slippage non modellato, non un modo di
perdita nascosto.

### Replica indipendente del finding d'ancora del 02/07
Il gate, applicato alla cieca a TP01 sulle 24 ancore orarie, ritrova da solo cio' che il 02/07 era
stato diagnosticato a mano:

> canonica (00:00) **+0.237** = **92° percentile** delle 24 | mediana onesta **+0.056** |
> banda [−0.087, +0.247] | fortuna **+0.182**

Il 02/07 riportava mediana 0.04 e banda [−0.13, +0.30] con un'implementazione **separata**. Accordo
buono. **Il numero onesto dell'hold-out di TP01 e' ~+0.05, non 0.31.** (Il valore del sleeve resta
quello gia' stabilito e non ancorato: il taglio del drawdown ~6× vs buy&hold.)

---

## Cosa NON e' stato fatto, e perche'

**Il book ricalcolato sul path LIVE.** Sarebbe la sintesi naturale (SKH01 live > modello su entrambi
i lati; TP01 live ≈ modello) e cambierebbe la stima de-luckata del book, che oggi applica un ×0.6
assunto. Non l'ho fatto perche' le due misure vivono su **lenti diverse**: il simulatore di SKH01
compone per-trade a nozionale unitario, lo sleeve di `sleeves.py` e' vol-targeted. Combinarle
produrrebbe un numero che sembra preciso e non lo e'. **Follow-up dichiarato con l'ostacolo nominato:**
serve una versione vol-targeted del path live di SKH01 prima di toccare il fattore di de-luck.

Resta pero' una conseguenza qualitativa gia' solida: il ×0.6 fu scelto assumendo che il live
**degradi**. Su SKH01 e' misurato il contrario, su TP01 e' ~zero. **Il ×0.6 e' probabilmente
conservativo**, e la nota gia' presente in CLAUDE.md ("il ×0.6 sopra il path live rischia di contare
due volte la degradazione SKH01") va letta come confermata, non come cautela ipotetica.

---

## Regole nuove

1. **La parzialita' dell'ultima barra conta in proporzione a quanto il segnale pesa la barra piu'
   recente.** Breakout/livelli: massima. Momentum a lookback lungo: ~nulla. Non trasferire la
   conclusione fra sleeve.
2. **Ogni statistica di "frazione in perdita" si calcola sulle barre ATTIVE.** Uno sleeve flat la
   maggior parte del tempo non ha una coda assente, ha meno osservazioni. (E: una lezione imparata
   in un contesto non si applica da sola in un altro — questa era gia' cablata nel monitor
   DVOLSPREAD il giorno prima.)
3. **Un gate nuovo si valida su un controllo positivo prima di credere ai suoi "ok".** Un gate rotto
   e un gate soddisfatto producono lo stesso output.
4. **Anche un DANNO misurato a un'ancora sola e' fortuna d'ancora.** A offset 0 la barra parziale
   sembrava costare −0.23 di hold-out: era il minimo della banda, mediana +0.12.