# 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.