r0910: risk-off ±2h intorno a FOMC/CPI su TP01 REFUTED 0/3 (ΔSh −0,097, −1,24%/anno; le ore dei dati sono fra le migliori)

Calendario letto dal web (Fed 61 riunioni + BLS 88 release CPI, 2019-2026), TP01 orario dalla stessa
held di sleeves, null location-matched 1000 estrazioni (Δ vero al 4,2° pctl), per anno 2/8.
Registro §78, memoria 20-ondate (D-bis), diario 2026-09-10b.

Fixes #9

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016kqvff47UBGeYfj1QeN4zE

.gitignore

@@ -31,6 +31,7 @@ data/funds_watch.json
 
 # dati regime (DVOL/funding/feature cache, rigenerabili)
 data/regime/
+data/venue_watch/
 _disp_scratch/
 data/regime/dispersion_features.parquet
 
@@ -48,6 +49,10 @@ Old/**/__pycache__/
 # run logs (rigenerabili dagli script)
 logs/
 
+# cache di ricerca rigenerabile (serie d'ancora, tabelle di segnale intra-bin SKH01):
+# 22MB, ~2.4h a ricostruirla, ma e' DERIVATA dai parquet certificati -> non si versiona.
+data/_cache/
+
 # cache della ricerca trackE (rigenerabile)
 .cache_trackE_*.npy
 
@@ -68,6 +73,12 @@ data/paper_prevday/
 data/paper_combo/
 data/paper_statarb/
 data/paper_xsr/
+data/paper_dvolspread/
+# stato della sorveglianza fee (ultima lettura del tier Deribit, per rilevarne i cambiamenti)
+data/fee_watch/
+# battuta di cuore del collettore catena (stato runtime, come gli altri monitor)
+data/chain_collect/
+data/vrp_f_watch/
 
 # log esecuzioni del book live (stato runtime, contiene fill/fee del conto reale)
 data/live/
@@ -75,3 +86,7 @@ data/live/
 # dati esterni di ricerca (on-chain CoinMetrics community, F&G) — non certificati, non in git
 data/external/
 data/options_daily/
+
+# libro di bordo: il DB e' dato operativo (coperto dal backup), non codice
+data/live/trades.db
+data/cache_regime_capitale.json

README.md

@@ -1,423 +1,153 @@
 # PythagorasGoal
 
-Sistema di riconoscimento pattern frattali e predizione per il trading di criptovalute (BTC, ETH), ispirato al framework teorico di Serleto & Malanga (*Pythagoras Trading Prediction*).
+Ricerca e esecuzione di strategie algoritmiche su BTC/ETH, con **un libro che gira con soldi veri**
+su Deribit mainnet dal 20 giugno 2026.
 
-## Obiettivo
+> 🚨 **v2.0.0 — RESET del 2026-06-19. Tutto ciò che questo README diceva prima è archiviato in
+> `Old/` e non è fidato.** L'intera libreria di strategie "validata out-of-sample" (le famiglie
+> FADE/HONEST/PAIRS/TSMOM/SHAPE, i portafogli PORT01-06, gli Sharpe fra 6 e 10) era un **artefatto
+> di uno storico contaminato**: print fantasma di un feed *testnet* più storico Binance/USDT.
+> Ri-testate sul feed reale ricostruito da Deribit mainnet, **perdono ogni anno**. Documento di
+> fondazione: `docs/diary/2026-06-19-deribit-history.md`.
+>
+> Questo README descrive il progetto **dopo** il reset. È stato riscritto il 2026-09-02, dopo
+> essere rimasto fermo al 4 giugno — quindici giorni prima del reset — mentre pubblicava i numeri
+> che il progetto aveva già dichiarato falsi.
 
-Partendo da un capitale iniziale di €1.000, raggiungere un profitto medio di €50 al giorno entro 6–8 mesi, tramite un portafoglio di strategie algoritmiche poco correlate fra loro — mean-reversion, trend/rotazione e spread market-neutral — validate out-of-sample e fee-aware.
+**L'autorità sui numeri e sulle decisioni è `CLAUDE.md`**, e il racconto completo sta in
+`docs/memory/`. Questo file è l'ingresso, non la fonte.
 
-## Risultati
+---
 
-> ⚠️ **Revisione 2026-05-28.** La famiglia squeeze-breakout (SQ/MT/ML/AD/CM/PD, con
-> accuracy storiche dichiarate 76-82%) è stata **scartata**: quei numeri erano un
-> **artefatto di look-ahead**. I backtest decidevano la direzione dalla candela di
-> breakout `close[i]` ma entravano a `close[i-1]` — impossibile dal vivo. Sotto
-> ingresso onesto (`close[i]`) e fee reali, l'edge sparisce e tutte perdono, anche
-> a fee zero. Dettagli e prove: `scripts/analysis/oos_validation.py`.
+## Cos'è vivo, adesso
 
-Dopo una validazione **out-of-sample, fee-aware** di molte famiglie di strategie,
-emergono cinque famiglie con edge netto reale, tutte radicate nella stessa lezione
-(in cripto la **mean-reversion** funziona, la continuazione no) o nella diversificazione:
+| | |
+|---|---|
+| libro live | **TP01 + SKH01 a 75/25**, nettati in software su una sola posizione per asset (50/50 BTC/ETH) |
+| venue | Deribit mainnet, perpetual lineari USDC. Esecuzione **armata** dal 2026-06-20 |
+| capitale | ~$2.050 (USDC + USDE), non i €2.000 nominali di nessun paper trader |
+| cadenza | **oraria**, minuto `:47` (`scripts/cron_book.sh`) |
+| leva | lorda ~0,28x su un tetto di 1,00x. Il cap non ha mai morso: **il vincolo è il segnale** |
+| protezione on-book | un solo disaster-SL rotolante al −30% sulla posizione netta |
 
-| Famiglia | Meccanismo | Strategie | Profilo (netto OOS) |
-|----------|-----------|-----------|---------------------|
-| **FADE** | mean-reversion intraday 1h (long/short, BTC/ETH) | MR01 Bollinger, MR02 Donchian, MR07 Return-reversal | Acc 52-55%, DD 18-34% |
-| **HONEST** | long-only multi-regime multi-crypto | DIP01 dip-buy, TR01 EMA-trend, ROT02 dual-momentum | CAGR 31-56%, DD 15-27% |
-| **PAIRS** | spread reversion *market-neutral* (2 gambe) | PR01 ETH/BTC, LTC/ETH, ADA/ETH, BTC/LTC, ETH/SOL | Sharpe 2.0-4.4, corr col mercato ~0.05 |
-| **TSMOM** | time-series momentum multi-orizzonte | TSM01 (3/6/12m + risk-off) | diversificatore, DD 15-22% |
-| **SHAPE** | ML walk-forward su feature di *forma* del prezzo | SH01 (LogisticRegression, orizzonte 12 barre) | diversificatore, corr +0.08 col resto |
+**Non** sono nel libro live: XS01, VRP01, GTAA01, XSR01. Vivono nel portafoglio di **ricerca**
+(paper, 5 sleeve), che è una serie diversa da quella che gira — quasi tutti i numeri di portafoglio
+del progetto sono su quella, non su questa.
 
-Tutti i numeri sono **netti** dopo fee realistiche (Deribit 0.10% RT single-leg, 0.20%
-RT/coppia sui pairs), leva 3x, su finestra held-out. Le strategie sono robuste su griglia
-parametri, sweep fee 0.00-0.20% RT e — per i pairs — validate con **walk-forward** e
-config universale (niente cherry-picking).
+## I numeri, con la loro lente
 
-### Portafoglio combinato (la vera leva anti-drawdown)
+Ogni numero va scritto con la lente e la banda che gli appartengono. La tabella completa
+("non citare" ↔ "citare") è in `CLAUDE.md` §2; qui i tre che contano.
 
-Le famiglie sono **quasi scorrelate fra loro** (~0.05). Combinandole in un unico
-portafoglio equipesato il drawdown crolla sotto quello di ogni singola sleeve:
+| grandezza | valore onesto |
+|---|---|
+| rendimento del libro live | **TWR +10,6%** dall'armamento, spezzato sul versamento del 25/08: +11,61% prima, −0,9% dopo |
+| crescita di trading | **+$50** in 71 giorni, su 30 round-trip chiusi e $0,87 di fee totali |
+| Sharpe del portafoglio di ricerca | **1,95** [1,81 – 2,12] full, **1,54** [1,11 – 1,91] hold-out |
 
-| Portafoglio | CAGR | Max DD | Sharpe |
-|-------------|------|--------|--------|
-| FADE (6 sleeve) | ~46% | 8% | 3.9 |
-| HONEST (3 sleeve) | ~46% | 13% | 2.2 |
-| **MASTER** (FADE + HONEST, 9) | ~47% | **5%** | 4.2 |
-| **MASTER + PAIRS + TSM01** (15) | ~67% | ~5% | ~6 |
-| **PORT06 live** (17 sleeve, cap pairs 33%, leva 2×, config EXIT-16) | ~79% | **2.6%** | 7.8 (FULL) / 10.1 (OOS) |
+⚠️ Il rendimento dell'equity **non** è la performance: il 96% della crescita del conto è un
+bonifico. Chi legge una percentuale su questo progetto deve sapere se è un TWR o un rapporto fra
+due saldi — è stato un difetto reale, riparato il 2026-09-02.
 
-> 🔎 **Numeri sobri (anti-overfit).** L'OOS singolo cade nel regime favorevole 2024-25:
-> i valori di Sharpe/DD sopra sono ottimistici di circa il 50%. Da pianificare per le
-> decisioni: **Sharpe atteso ~5**, **worst-drawdown su 90 giorni ~6%**, profilo che regge
-> a leva 2x con slippage raddoppiato. Configurazione raccomandata: equal-weight, leva 2x,
-> con un cap sull'allocazione ai pairs (~30-35%, poiché concentrano ~57% del rischio).
-> Tutto resta da confermare nel paper trading live.
+## La riga che ordina tutto il resto
 
-## Come funziona
+> La ricerca ha smesso di essere il vincolo il 2026-07-26, e **sei ondate successive lo hanno
+> confermato invece che ribaltarlo**. I vincoli sono **il capitale che entra** e **il conto che non
+> sparisce**.
 
-### MR01 — Bollinger Fade (mean-reversion)
+Misurato: il miglior candidato nuovo vale **+0,046 €/giorno**; versare €500/mese invece di €250
+porta la probabilità di arrivare al traguardo in 20 anni **dal 14% all'85%**. E €100/mese in più
+equivalgono a **+4,07%/anno di drift**, cioè più di tutta la leva autorizzabile.
 
-La strategia attiva sfrutta il fatto, emerso dai dati, che su BTC/ETH a 1h gli estremi
-di prezzo **rientrano verso la media** più di quanto proseguano:
+## Metodo — cosa deve superare una strategia nuova
 
-1. **Bollinger Bands** (window `n`, `k` deviazioni standard) sul close.
-2. **Entry** — quando il close esce *sotto* la banda inferiore → **long** (o *sopra* la superiore → **short**). Ingresso a `close[i]`, eseguibile dal vivo.
-3. **Take-profit** alla media mobile (il rientro atteso).
-4. **Stop-loss** a `sl_atr × ATR` oltre l'estremo; **time-limit** a `max_bars`.
+Sei requisiti, nessuno negoziabile (`CLAUDE.md` §8, gate in `scripts/research/alt/altlib.py`):
 
-Nessun look-ahead: direzione e livelli sono calcolati con dati fino a `close[i]`.
+1. **ingresso eseguibile** — direzione e prezzo da dati fino a `close[i]`, mai l'estremo di una candela;
+2. **backtest netto** dopo fee Deribit realistiche, più la leva;
+3. **out-of-sample** held-out, robustezza su griglia, sweep fee;
+4. **liquidità e plausibilità** — un edge su un book fermo o su wick fantasma non è un edge;
+5. i **gate**: `marginal_vs_tp01` (Sharpe marginale, non assoluto), `study_family_honest` con
+   deflated-Sharpe ≥ 0,95, `day_boundary_robust`, `anchor_luck_band`, `weights_tilt_null`;
+6. codice, test e diario.
 
-### Le altre famiglie
+Il progetto ha **73 regole di prim'ordine** (`CLAUDE.md` §6) — sul dato, sul metodo, sui costi,
+sulla produzione e sul piano — ognuna pagata almeno una volta. La più
+ricorrente, cinque occorrenze: *un sorvegliante deve derivare il proprio bersaglio dal codice
+sorvegliato, mai ridichiararlo — un controllo puntato su una configurazione diversa da quella che
+gira passa sempre, e non sta controllando niente.*
 
-- **FADE** (oltre MR01): MR02 fada la rottura del canale Donchian verso il centro;
-  MR07 fada il movimento di barra estremo misurato in deviazioni standard dei
-  rendimenti. Stessa logica di reversione, indicatori indipendenti.
-- **HONEST** (long-only, multi-crypto): DIP01 compra i dip estremi e rivende al
-  recupero; TR01 segue il trend con incrocio di EMA su un paniere; ROT02 ruota ogni
-  giorno sui tre asset col momentum più forte, andando in cash quando BTC è sotto la
-  sua media (risk-off). Coprono i regimi di trend e rotazione, complementari alle fade.
-- **PAIRS** (market-neutral): scommette sul rientro verso la media del log-ratio fra
-  due cripto (z-score). Long su una, short sull'altra: l'esposizione netta al mercato è
-  quasi nulla (correlazione ~0.02), il che la rende un diversificatore eccellente.
-- **TSMOM**: tiene gli asset con momentum positivo persistente su più orizzonti
-  (3/6/12 mesi), con overlay risk-off. Rende meno ma è poco correlato, utile in ensemble.
+## Il dato
 
-### Perché lo squeeze breakout è stato abbandonato
+- **La verità è Deribit mainnet**, perché è dove si esegue. Binance è un audit indipendente, mai
+  un'ancora per "ripulire": è USDT, ~10 bps fuori, fino al 3% sotto depeg.
+- Universo certificato: **solo BTC/ETH**, ogni timeframe. Gli alt sono esclusi.
+- Lo storico si aggiorna **solo** con `rebuild_history.py` e si certifica **sempre** con
+  `certify_feed.py`. Il vecchio downloader è la causa del reset.
+- La catena opzioni si **raccoglie** ogni ora (`collect_chain.py`, minuto `:25`): un'ora non
+  raccolta è persa per sempre.
 
-L'ipotesi originale era opposta — *continuazione* dopo la compressione di volatilità
-(Bollinger dentro Keltner → breakout direzionale). Su dati storici sembrava dare
-76-82% di accuracy, ma era un **artefatto di look-ahead**: il backtest entrava a
-`close[i-1]` con direzione decisa da `close[i]`. Replicando l'esecuzione reale
-(ingresso a `close[i]`) l'edge collassa al ~47% (lancio di moneta) e i costi fanno
-il resto. Il test sui breakout intra-barra a 5m conferma che il movimento *rientra*
-subito (mean-reversion), giustificando MR01. Tutta la famiglia squeeze è in `scripts/waste/`.
-
-### Lezione metodologica
-
-Ogni nuova strategia deve passare: (1) **ingresso eseguibile** senza look-ahead,
-(2) backtest **netto** dopo fee realistiche (0.10% RT Deribit), (3) validazione
-**out-of-sample** + robustezza su griglia parametri + sweep fee. Strumenti in
-`scripts/analysis/` (`strategy_research.py`, `oos_validation.py`, `intrabar_test.py`).
-
-## Struttura progetto
+## Struttura
 
 ```
-PythagorasGoal/
-├── src/
-│   ├── data/              # Download e gestione dati (Cerbero MCP + Binance)
-│   ├── fractal/           # Indicatori frattali: Hurst, Higuchi FD, self-similarity
-│   ├── backtest/          # Motore di backtesting con fee e metriche
-│   ├── strategies/        # Classe base Strategy ABC + indicatori condivisi
-│   │   ├── base.py        # Strategy, Signal, BacktestResult, YearlyStats
-│   │   └── indicators.py  # keltner_ratio, detect_squeezes, ema, atr, rv, corr
-│   ├── live/              # Paper trading live su Deribit testnet
-│   │   ├── multi_runner.py     # Orchestratore multi-strategia (strategie + pairs)
-│   │   ├── strategy_worker.py  # Worker single-leg con stato persistente
-│   │   ├── pairs_worker.py     # Worker a 2 gambe per i pairs (market-neutral)
-│   │   ├── strategy_loader.py  # Import dinamico classi Strategy
-│   │   ├── cerbero_client.py   # Client HTTP per Cerbero MCP
-│   │   ├── signal_engine.py    # Squeeze + ML real-time (legacy) + validazione OOS
-│   │   └── telegram_notifier.py
-│   └── portfolio/         # Portafogli di prima classe (capitale condiviso, backtest + live)
-│       ├── base.py        # SleeveSpec, Portfolio (.backtest), load_active_portfolio
-│       ├── weighting.py   # Schemi di ponderazione: equal, cap, inverse_vol, cluster_rp, manual
-│       ├── sleeves.py     # Builder unificato equity-per-sleeve (fonte unica, parità report)
-│       ├── ledger.py      # PortfolioLedger: PnL/DD aggregati, persistenza e resume
-│       └── runner.py      # PortfolioRunner live (Cerbero v2, sizing, ribilancio giornaliero)
-├── scripts/
-│   ├── strategies/        # Strategie con edge validato OOS (FADE, HONEST, PAIRS, TSMOM + portafogli)
-│   ├── portfolios/        # Definizioni PORT01-06 e report run() dei portafogli di prima classe
-│   ├── waste/             # Strategie scartate (squeeze SQ/MT/ML/AD/CM/PD, MR03, ROT01, W01-W28)
-│   └── analysis/          # Ricerca/validazione OOS fee-aware, gestione rischio, report
-├── strategies.yml         # Config multi-strategy paper trader
-├── data/
-│   ├── raw/               # Parquet OHLCV (gitignored, ~70 MB)
-│   └── regime/            # DVOL + funding (Deribit mainnet) + cache feature regime (gitignored)
-├── VERSION                # versione semver (cotta nell'immagine, mostrata nei msg Telegram)
-├── docs/
-│   ├── diary/             # Diario di ricerca giornaliero
-│   └── specs/             # Specifiche di design
-├── Dockerfile
-├── docker-compose.yml
-└── pyproject.toml
+src/
+  data/downloader.py        load_data(asset, tf) sui parquet certificati
+  strategies/               trend_portfolio.py (TP01) · skyhook.py (SKH01) · base · indicators
+  portfolio/                portfolio.py (N sleeve + weights_tilt_null) · sleeves.py · gtaa.py
+  backtest/harness.py       backtest onesto, senza look-ahead
+  live/                     book.py (esecutore netto) · deribit · livefeed · usde
+                            venue_watch · venue_probe · venue_news · monitor_health · scale_watch
+                            tradesdb · journal · analista · notifier · cli
+scripts/
+  live/                     book_execute · trades_db · journal · analista · balance_watch
+                            paper_* (forward-monitor) · usde_watch · usde_convert · fee_watch
+  research/                 r<data>_*.py — un file per esperimento, harness in alt/altlib.py
+  analysis/                 rebuild_history · certify_feed · audit_feed · multi_source_check
+  cron_{book,daily,chain,balance,usde,opt_snapshot,vol_term}.sh
+docs/
+  memory/                   LA MEMORIA — 6 file, indicizzati in testa a CLAUDE.md
+  research/                 RESULTS-0822 (§1-77, un registro per filone) · BRIEF-0822 · SPEC-scale-key
+  diary/                    una voce per esperimento (144)
+  journal/                  libro di bordo, una voce al giorno, 4 livelli per provenienza
+tests/                      1008, tutti verdi
+Old/                        archivio pre-reset — consultabile, non fidato
 ```
 
-## Strategie attive
-
-Le strategie single-asset estendono `src.strategies.base.Strategy`
-(`generate_signals() → backtest()`); i pairs hanno un worker dedicato a 2 gambe.
-
-| Codice | Script | Famiglia | Descrizione |
-|--------|--------|----------|-------------|
-| **MR01** | `MR01_bollinger_fade.py` | FADE | Fada la banda di Bollinger, TP alla media, SL ad ATR |
-| **MR02** | `MR02_donchian_fade.py` | FADE | Fada la rottura del canale Donchian, TP al centro |
-| **MR07** | `MR07_return_reversal.py` | FADE | Fada il movimento di barra estremo (z dei rendimenti) |
-| **DIP01** | `DIP01_dip_reversion.py` | HONEST | Dip-buy long-only su z-score estremo |
-| **TR01** | `TR01_ema_trend.py` | HONEST | EMA 20/100 trend-following su paniere cripto (4h) |
-| **ROT02** | `ROT02_dual_momentum.py` | HONEST | Rotazione cross-sectional top-3 + risk-off (1d) |
-| **PR01** | `PR01_pairs_reversion.py` | PAIRS | Spread reversion market-neutral su 5 coppie |
-| **TSM01** | `tsmom_research.py` | TSMOM | Time-series momentum multi-orizzonte + risk-off |
-| **SH01** | `SH01_shape_ml.py` | SHAPE | LogisticRegression walk-forward su 17 feature di forma, orizzonte 12 barre (diversificatore) |
-
-Le fade applicano tre protezioni live: un **filtro trend** (`trend_max`/`ema_long`,
-salta i segnali col prezzo troppo esteso rispetto alla EMA200), un **loss-guard Hurst**
-(`hurst_max=0.55`, salta i segnali in regime persistente/trending dove si concentrano gli stop-loss
-— dimezza il drawdown del portafoglio, calcolato dalle sole close) e l'**EXIT-16 close-confirm SL**
-(`sl_confirm_atr=0.5`, 2026-06-04: lo stop scatta solo se la barra *chiude* oltre `sl ∓ 0.5·ATR14` —
-gli stop intrabar da wick erano falsi negativi, l'overshoot che buca lo stop è proprio il movimento
-che la fade fada; a livello PORT06 porta l'OOS Sharpe da 8.82 a 10.06). Più un filtro `min_tp_frac`
-che scarta i micro-scalp col take-profit entro il costo delle fee. Le tre protezioni sono
-complementari: Hurst toglie il regime tossico, il trend-filter gli ingressi sovra-estesi, il
-close-confirm i falsi stop. Portafogli pronti: `PORT01`
-(honest), `PORT02` (fade), `PORT03` (master fade+honest), **`PORT06`** (master esteso, default live).
-
-**Scartate** (in `scripts/waste/`): la famiglia squeeze (SQ01-04, ML01, MT01, PD01,
-CM01, AD01 — artefatto di look-ahead), MR03 Keltner (debole/ridondante con MR01) e
-ROT01 (dominata da ROT02).
-
-### Comandi utili
+## Comandi
 
 ```bash
-# Backtest di una strategia
-uv run python scripts/strategies/MR01_bollinger_fade.py
-uv run python scripts/strategies/PR01_pairs_reversion.py
-
-# Ricerca e validazione fee-aware out-of-sample
-uv run python scripts/analysis/strategy_research.py      # screening famiglie + deep-dive fade
-uv run python scripts/analysis/strategy_research_v2.py   # MR02 / MR03 / MR07
-uv run python scripts/analysis/oos_validation.py         # perche' la famiglia squeeze e' scartata
-uv run python scripts/analysis/pairs_research.py         # ricerca + verifica no-look-ahead dei pairs
-
-# Gestione rischio, combinazione, report
-uv run python scripts/analysis/risk_management.py        # filtro trend + portafoglio fade
-uv run python scripts/analysis/combine_portfolio.py      # combinare fade + honest
-uv run python scripts/analysis/combine_v2.py             # master esteso con pairs + TSM01
-uv run python scripts/analysis/report_families.py        # report per anno di tutte le famiglie
-
-# Validazione dei worker live (replay == backtest)
-uv run python scripts/analysis/validate_worker_mr01.py   # worker single-leg su MR01
-uv run python scripts/analysis/validate_worker_pairs.py  # worker a 2 gambe sui pairs
-uv run python scripts/analysis/live_smoke_pairs.py       # smoke test feed live reale dei pairs
+uv sync                                                            # dipendenze
+uv run python scripts/analysis/rebuild_history.py --asset BTC ETH  # storico da Deribit mainnet
+uv run python scripts/analysis/certify_feed.py                     # certifica i feed
+uv run python scripts/live/trades_db.py --report                   # stato del libro + TWR
+uv run python scripts/live/journal.py                              # voce del giorno
+uv run python scripts/live/analista.py --secco                     # analisi del giorno, senza salvare
+uv run python scripts/portfolio/run_portfolio.py                   # portafoglio di ricerca
+uv run pytest                                                      # 1008 test
 ```
 
-## Paper Trading Live
+Ogni script di `scripts/live/` accetta `--help` e **rifiuta un flag che non conosce** (esce 2): fino
+al 2026-09-02 un flag sbagliato eseguiva l'azione di default, e su tre script quell'azione scriveva.
 
-Il multi-strategy runner esegue N strategie in parallelo su dati live da Cerbero MCP,
-ognuna con €1000 USDC virtuali indipendenti. Gestisce due tipi di worker:
+## Gate aperti
 
-- **Single-leg** (`strategy_worker.py`): per le strategie direzionali. Se un `Signal`
-  porta `tp`/`sl`/`max_bars` in `metadata` (come le fade), chiude su take-profit /
-  stop-loss / time-limit; altrimenti usa il fallback `hold_bars`/stop -2%.
-- **Due gambe** (`pairs_worker.py`): per i pairs market-neutral. Apre long su una gamba
-  e short sull'altra, esce sul rientro dello z-score o per time-limit, conta le fee su
-  entrambe le gambe. Validato: il replay storico coincide *esattamente* col backtest.
+Un gate si decide **alla data**, coi criteri scritti **prima**. Elenco completo in `CLAUDE.md` §4.
 
-### Avvio
+| gate | data | dove punta oggi |
+|---|---|---|
+| STATARB | 2026-09-27 | ritiro (Sharpe −1,61 sulla serie vera) |
+| SCALA-01 — leva 1,00 → 1,25 | non prima del 2026-10-01 | chiave costruita e **inerte**; 9 condizioni, 2 fatte |
+| XSR01 | 2026-10-23 | sotto la lente rendita il meccanismo vale ~0 |
+| DVOLSPREAD | kill 2026-10-24 | serie −4,41 |
+| GTAA01 tenere/bloccare | al book a $15k | contributo reale +0,10/+0,12 di Sharpe, non incassabile sotto la soglia |
 
-```bash
-# Locale
-uv run python -m src.live.multi_runner
+## Obiettivo, e cosa lo rende difficile
 
-# Docker
-docker compose up -d
-```
+Il target dichiarato è **€50/giorno partendo da €1.000**. Non è raggiungibile a questo capitale:
+servono ~$313k (banda [$187k – $1,14M]) o **€1.733/mese per dieci anni** per averlo al 90% di
+probabilità. La leva non è la scorciatoia — quella difendibile vale quanto €100-150/mese di
+versamento. La via è target-vol, capitale e tempo.
 
-### Configurazione
-
-Le strategie attive sono definite in `strategies.yml`:
-
-```yaml
-defaults:
-  capital: 1000
-  position_size: 0.15
-  leverage: 3
-
-strategies:                       # strategie single-leg
-  - name: MR01_bollinger_fade
-    asset: BTC
-    tf: 1h
-    enabled: true
-    params: { bb_window: 50, k: 2.5, sl_atr: 2.0, max_bars: 24, trend_max: 3.0, ema_long: 200 }
-
-pairs:                            # strategie a 2 gambe (market-neutral)
-  - name: PR01_pairs_reversion
-    a: ETH
-    b: BTC
-    tf: 1h
-    enabled: true
-    params: { n: 50, z_in: 2.0, z_exit: 0.75, max_bars: 72, jump_max: 0.08 }
-```
-
-Per aggiungere una strategia: nuova riga in `strategies.yml` (sezione `strategies` o
-`pairs`), poi `docker compose restart`. Lo storico delle strategie esistenti rimane intatto.
-
-### Persistenza
-
-Ogni strategia ha la sua directory in `data/paper_trades/`:
-
-```
-data/paper_trades/
-  MR01_bollinger_fade__BTC__1h/
-    trades.jsonl    # Storico trade append-only
-    status.json     # Stato corrente (resume al restart, include tp/sl/max_bars)
-```
-
-Notifiche Telegram per ogni trade (richiede `TELEGRAM_BOT_TOKEN` e `TELEGRAM_CHAT_ID` in `.env`).
-
-## Paper Trading a Portafoglio
-
-Accanto al multi-strategy runner originale — in cui ogni strategia gestisce autonomamente il proprio conto virtuale da €1.000 — il progetto dispone ora di un **paper trader a portafoglio** (`src/portfolio/`) che tratta l'insieme delle strategie come un unico organismo con un capitale condiviso.
-
-### Come funziona
-
-La definizione di un portafoglio (`SleeveSpec` + schema di peso) ha due facce sulla stessa sorgente dati:
-
-- **Backtest** (`.backtest()`): ricostruisce le equity-curve di ogni sleeve tramite il builder unificato in `sleeves.py`, le pondera secondo lo schema scelto e calcola le metriche aggregate (CAGR, Sharpe, max DD). La parità con i report prodotti da `report_families.py` è garantita dalla fonte unica.
-- **Live** (`PortfolioRunner`): ogni ora il runner scarica le candele aggiornate via Cerbero v2, calcola i pesi correnti, avvia i worker appropriati per ogni sleeve attiva e registra il PnL aggregato nel ledger (`data/portfolios/{code}/`). Il ledger persiste tra i riavvii.
-
-### Schemi di ponderazione
-
-Il modulo `weighting.py` mette a disposizione cinque schemi: `equal` (default), `cap` (tetto per famiglia — p.es. `pairs: 0.33` per limitare la concentrazione), `inverse_vol` (pesi inversamente proporzionali alla volatilità storica), `cluster_rp` (equal tra cluster naturali poi inverse-vol all'interno del cluster) e `manual` (pesi liberi). Lo schema si specifica in `portfolios.yml` insieme al codice portafoglio e alla leva.
-
-### Portafoglio di default: PORT06
-
-La configurazione raccomandata è **PORT06** (`scripts/portfolios/PORT06_master_shape.py`): portafoglio master esteso che include tutte e sei le famiglie (FADE, HONEST, PAIRS, TSMOM, SHAPE), con schema `cap` che limita i pairs al 33% del capitale per moderare la loro concentrazione di rischio. Backtest canonico (dati al 2026-05-28): Sharpe 6.47 (FULL) / 8.82 (OOS), drawdown massimo 4.10% (FULL) / 1.30% (OOS), leva 2×; **con la config live attuale (EXIT-16 close-confirm): Sharpe 7.84 / 10.06, DD 2.60% / 1.15%**.
-
-### Scope live
-
-Il runner esegue **tutti e 17 gli sleeve** di PORT06: **fade** (MR01, MR02, MR07 × BTC/ETH),
-**honest** (DIP01, TR01-basket 4h, ROT02-rotation 1d), **pairs** (PR01, cinque coppie),
-**TSMOM** (TSM01 1d) e **shape** (SH01 × BTC/ETH). Worker dedicati: `StrategyWorker` (single-leg, fade/
-dip/**shape**), `PairsWorker` (2 gambe), `BasketTrendWorker`, `RotationWorker`, `TsmomWorker`. Il runner
-fetcha 1h da Cerbero v2 e resampla a 4h/1d; il pool di capitale, il ribilancio giornaliero e il ledger
-sono validati == backtest.
-
-> **SH01 (2026-06-01):** gira come `StrategyWorker` normale (il walk-forward è interno a
-> `generate_signals`). Il vecchio `MLWorkerWrapper` usava il `SignalEngine` **squeeze scartato** —
-> rimosso. **Loss-guard Hurst (2026-06-02):** le fade saltano i segnali in regime persistente
-> (rolling-Hurst ≥ 0.55), dove si concentrano gli stop-loss — dimezza il drawdown del portafoglio
-> (FULL 4.1%→2.4%; stop-loss fade −67% in numero, perdite totali −68%). Calcolato dalle sole close,
-> attivo live (`hurst_max` nei params). Il report orario su Telegram **monitora lo stop-rate fade
-> prima/dopo l'attivazione** e dà il verdetto automatico quando il campione è sufficiente.
-
-### Esecuzione reale (shadow, Deribit testnet)
-
-Sette sleeve single-leg — le **6 fade** (MR01/MR02/MR07 × BTC/ETH) e **DIP01** (dal 2026-06-04) —
-eseguono ordini **reali su Deribit testnet** accanto al fill simulato (*shadow*: il sim resta la
-verità che guida le decisioni; il reale misura la fattibilità). Punti chiave:
-
-- **Strumenti lineari USDC** (`BTC_USDC`/`ETH_USDC-PERPETUAL`): payoff lineare = matematica del
-  backtest; fee e PnL in USDC. Quantizzazione `Decimal` di amount (step) e prezzi (tick).
-- **Take-profit reale = limit reduce-only AL livello** (v1.0.7): piazzato all'apertura, copre la
-  sola quota del worker (gli strumenti sono condivisi fra worker e nettati per conto); alla
-  chiusura il worker cancella il resting, riconcilia i fill dal trade history per `order_id` e
-  chiude a market solo il residuo. Fix della divergenza misurata: il market-on-poll usciva
-  +235 bps oltre il livello TP. Fill da resting = fee maker (~0%).
-- **Stop-loss close-confirm** (v1.1.0): uscita al close che sfonda il livello → market
-  reduce-only al poll (nessun ordine stop sul book, per scelta: i trigger Deribit generano un
-  nuovo order_id allo scatto, non verificabile, e i wick non devono stoppare).
-- **Verifica sul trade** (order_id in `get_trade_history`), fee reali dai `trades[]`, ledger
-  reale parallelo persistito (`real_capital`), eventi `REAL_OPEN`/`REAL_TP_RESTING`/`REAL_CLOSE`
-  nel log + alert Telegram (`REAL_EXEC_LIVE`, `REAL_OPEN_FAIL`).
-- Config in `portfolios.yml` → `overrides.execution {enabled, sleeves, instruments}`.
-  **Pairs/rotation/TSMOM/shape restano simulati**: i pairs richiedono un executor a 2 gambe
-  (leg-risk), i multi-asset un rebalance-to-target; roadmap nel diario.
-
-### Versione & deploy
-
-Ogni deploy ha una **versione** (file `VERSION`, semver) che compare nei messaggi Telegram (notifiche
-trade + report orario), così correli ogni messaggio al codice che l'ha generato. Il sorgente è **cotto
-nell'immagine** → per aggiornare il live serve un **rebuild**, non un semplice restart:
-
-```bash
-./scripts/deploy.sh           # bump patch (1.0.0 → 1.0.1) + commit + rebuild + ricrea container
-./scripts/deploy.sh minor     # 1.0.x → 1.1.0
-```
-
-Il volume `data/` persiste tra i deploy → i worker fanno RESUME dello stato (capitale, posizioni aperte).
-
-### Avvio del paper trader a portafoglio
-
-```bash
-# Backtest del portafoglio di default (PORT06)
-uv run python scripts/portfolios/PORT06_master_shape.py
-
-# Paper trading live a portafoglio
-uv run python -m src.portfolio.runner
-
-# Report orario su Telegram (stato + stop-rate fade prima/dopo loss-guard) — via cron
-uv run python scripts/portfolios/hourly_report.py
-
-# Smoke test del data layer Cerbero v2
-uv run python scripts/analysis/smoke_portfolio.py
-```
-
-## Setup
-
-```bash
-# Clona e installa
-git clone <repo-url> && cd PythagorasGoal
-uv sync
-
-# Scarica dati storici (~70 MB)
-uv run python -m src.data.downloader
-
-# Backtest strategia attiva
-uv run python scripts/strategies/MR01_bollinger_fade.py
-
-# Paper trading live
-uv run python -m src.live.multi_runner
-```
-
-### Requisiti
-
-- Python ≥ 3.11
-- [uv](https://docs.astral.sh/uv/) come package manager
-- Accesso a Cerbero MCP (`cerbero-mcp.tielogic.xyz`) per dati Deribit live
-- Docker (opzionale, per deploy su VPS)
-
-## Dati
-
-| Asset | Timeframe | Copertura |
-|-------|-----------|-----------|
-| BTC, ETH | 5m / 15m / 1h | 2018-01 → oggi |
-| SOL, LTC, ADA, XRP, BNB, DOGE | 15m / 1h | 2019-2022 → oggi (variabile per asset) |
-
-Fonte primaria: perpetual Deribit via Cerbero MCP. Fallback: Binance spot via ccxt.
-Formato: Apache Parquet (in `data/raw/`, gitignored).
-
-> **Nota sul naming Deribit (per il feed live).** I major sono perpetui *inverse*
-> (`BTC-PERPETUAL`, `ETH-PERPETUAL`); gli altcoin sono perpetui *lineari USDC*
-> (`SOL_USDC-PERPETUAL`, `LTC_USDC-PERPETUAL`, …) con storia dal 2022. Attenzione:
-> `LTC-PERPETUAL`/`ADA-PERPETUAL` non esistono e `SOL-PERPETUAL` restituisce dati
-> errati — per gli altcoin usare sempre la forma `_USDC-PERPETUAL`.
-
-### Discovery & validazione strumenti
-
-`src/data/instruments.py` scopre e **valida** gli strumenti disponibili sugli
-exchange implementati — **Deribit** e **Hyperliquid** (esclusi Alpaca/stocks e
-**Bybit**, feed testnet inaffidabile). Ogni perpetuo viene testato sui dati
-storici realmente raccoglibili: esistenza, congruenza OHLC, contratto non-morto,
-liquidità e **congruenza prezzo cross-exchange** (mediana per base-coin, tolleranza
-5%) — così feed farlocchi e contratti sbagliati (es. `SOL-PERPETUAL`=9.6) vengono
-scartati. Il risultato è `data/instruments_registry.json` (strumenti validi +
-timeframe + data d'inizio).
-
-**Solo gli strumenti validati possono essere scaricati**: il downloader ha un gate
-(`_download_cerbero_range`) che rifiuta quelli non nel registry. Rigenera con:
-
-```bash
-uv run python -m src.data.instruments
-```
-
-Simboli Deribit: BTC/ETH = `<COIN>-PERPETUAL` (inverse); altcoin =
-`<COIN>_USDC-PERPETUAL` (lineari USDC). Registry attuale (testnet): Deribit 18/106
-validi (major liquidi, BTC dal 2018), Hyperliquid 66/74.
-
-## Riferimenti
-
-- Serleto, L. & Malanga, C. — *Pythagoras Trading Prediction* (2024)
-- Serleto, L. & Malanga, C. — *Libro dei Frattali* (2024)
-
-## Licenza
-
-Uso privato. Non destinato alla distribuzione.
+**Onestà prima di tutto**: nessun numero va creduto finché non è netto fee, out-of-sample, robusto
+su griglia, e su dati certificati, liquidi ed eseguibili. Il resto di questo repo esiste per rendere
+quella frase verificabile invece che dichiarata.

config/live.json

@@ -1,11 +1,27 @@
 {
   "_nota": "Config esecuzione LIVE del BOOK DERIBIT (TP01+SKH01 nettati in software). execution_enabled=true + --execute -> ordini REALI. ARMATO 2026-06-23: esecutore scripts/live/book_execute.py via cron ORARIO scripts/cron_book.sh (SKH01 e' a 230m). disaster-SL on-book -30% sulla posizione netta. Tutto flat all'arming -> nessun ordine finche' un segnale non arma.",
-  "_nota_cap": "Cap notional per-asset DINAMICO (frontiera 2026-07-03): con max_notional_per_asset_frac=0.5 il cap = equity/2, cosi' cresce col capitale e un deposito non resta strozzato. A ~$600 equity/2=~$300 -> INERTE (identico al vecchio cap fisso). Il cap dinamico si usa solo con equity reale fidata; su fallback/offline si ripiega su max_notional_per_asset_usd (protezione downside). Per tornare al cap fisso: rimuovere max_notional_per_asset_frac.",
+  "_nota_cap": "Cap notional per-asset DINAMICO (frontiera 2026-07-03): con max_notional_per_asset_frac=0.5 il cap = equity/2, cosi' cresce col capitale e un deposito non resta strozzato. AGGIORNATO 2026-07-26: max_notional_per_asset_usd alzato 300 -> 3000 in previsione del versamento (EUR 5.000 + 500/mese -> equity ~$6.050, equity/2 ~$3.025). ⚠️ Alzarlo NON e' pericoloso perche' dal 2026-07-26 il cap di FALLBACK (equity reale non leggibile) e' min(questo valore, ultima_equity_reale_osservata * frac) — vedi src/live/book._cap e il watermark data/live/equity_seen.json. Senza quel legame, un cap da $3.000 su un conto da $597 avrebbe permesso $2.000 di nozionale lordo = 3.35x di leva nel momento peggiore. Questo rende inutile l'azione manuale 'al deposito alzare il cap' (pre-registrata 2026-07-02).",
   "execution_enabled": true,
-  "max_notional_per_asset_usd": 300,
+  "max_notional_per_asset_usd": 3000,
   "max_notional_per_asset_frac": 0.5,
   "min_order_usd": 5,
   "disaster_sl_pct": 0.3,
   "_nota_stale": "Staleness-gate (2026-07-25): se l'ultima barra del feed certificato e' piu' vecchia di max_data_age_days, book_execute NON invia ordini e allerta su Telegram. Il 2026-07-14 il book compro' ETH con il feed fermo da 6 giorni (conto online e posizione leggibile -> gli altri due gate non scattavano). Follow-up raccomandato nel diario 2026-07-15-feed-freeze, ora cablato.",
-  "max_data_age_days": 2
+  "max_data_age_days": 2,
+  "_nota_skh_feed": "Freschezza del feed 5m usato per il segnale SKH01 (2026-07-26). fresh_5m ricade sul feed certificato IN SILENZIO se il fetch pubblico Deribit fallisce, e il certificato si rigenera 1x/giorno: senza controllo la latenza d'uscita di SKH01 passa da ~1h a ~1 giorno senza segnalazione. Sopra soglia book_execute ALLERTA e NON blocca (bloccare fermerebbe anche TP01, nettato sullo stesso strumento, per un guasto di rete). Diario 2026-07-26-t1-esecuzione-skh-live.md.",
+  "skh_feed_max_age_min": 30,
+  "_nota_usde": "Collaterale USDE a rendimento (test di eligibilita' 2026-08-26: 500 USDE, verdetto entro il 29/08 — diario 2026-08-26-usde-analisi). L'autorita' che LEGGE questa sezione e' src/live/usde.py; la usano shadow._collaterale_usde (equity oraria del book) e scripts/live/usde_watch.py (sorveglianza giornaliera 12:35 UTC). Criteri delle soglie, dichiarati (P6): depeg_warn 0.99 = fuori dalla banda operativa dello spot (~3 bps) e oltre il clamp +-0.5% per fonte dell'indice usde_usdc — a quel prezzo non e' rumore di book; depeg_crit 0.95 = meta' del buffer di haircut (10%) consumata. quota_target 0.70 (CHIAVE TOLTA il 2026-09-10, issue #7: il bersaglio operativo e' DERIVATO dalle bande del cuscino, vedi usde._nota_cuscino — quanto segue e' la storia della decisione) = la quota DECISA dall'operatore il 2026-08-30 (la decisione di quota che il gate USDE-01 apriva; anticipata di un giorno sul rinvio al 31/08, su richiesta esplicita dell'operatore \"porta in usde tutto il capitale che non viene usato\"). Il 70% NON e' un argmax (M8): e' il massimo compatibile col CUSCINO DI REGOLAMENTO, cioe' il vincolo che r0830_usde_quota non aveva guardato — il P&L e il funding dei perp USDC-lineari si regolano in USDC, non nel collaterale, quindi a quota alta il saldo USDC va negativo alla prima perdita del libro e Deribit lo finanzia a interesse. Il cuscino richiesto e' il disaster-SL sulla massima esposizione lorda: n_asset x frac x disaster_sl_pct = 2 x 0.5 x 0.30 = 30% dell'equity, che lascia esattamente il 70%. quota_max_frac 0.50 = tetto di ALLERTA sulla quota USDE/equity totale (N4: la quota e' l'unica leva contro il rischio emittente, -100% = 25 anni di resa, non recuperabile). Alzato a 0.85 il 2026-08-30 in previsione della quota al 70% e RIMESSO A 0.50 lo stesso giorno perche' il 70% pareva irraggiungibile; RIMESSO A 0.85 il 2026-09-06, quando la quota e' arrivata al 68,7% su autorizzazione dell'operatore e la sonda non ha trovato tetto. 🚨 venue_cap_frac: il 06/09 il tetto NON C'ERA (null, vedi venue_cap_misurato) — quanto segue e' la storia del 30-31/08, tenuta perche' il tetto puo' tornare: venue_cap_frac 0.318 = TETTO DEL VENUE sull'USDE, misurato e NON documentato da Deribit (ne' 'Cross collateral specifications' ne' 'Yield-generating collateral' prevedono un limite sulle quantita' detenibili; il Cap ETHENA che esiste diluisce il TASSO a livello di exchange, non limita gli acquisti). Ogni acquisto oltre il tetto e' rifiutato con `not_enough_funds_in_currency` pur avendo $1.400 disponibili: messaggio FUORVIANTE. E' una FRAZIONE dell'equity, non un livello: provato il 31/08 lasciando scendere l'equity di $8, il tetto e' sceso con lei. ⚠️ DIPENDE DAL MODELLO DI MARGINE, ma pochissimo — misurato a saldo neutro sotto entrambi: SEGREGATO S:SM [643,18-644,18) con equity $2.055,56 = 31,29-31,34%; CROSS X:SM [654,18-655,18) con equity $2.054,90 = 31,84-31,88%. Il passaggio a cross ha comprato +0,55pp = **+11 USDE (~$11)**: il modello entra nel tetto, ma non lo spiega. ⇒ la quota resta ~31-32% sotto qualunque configurazione e il 70% di quota_target NON e' raggiungibile (manca un fattore ~2,2x). Il valore 0.318 e' il bordo BASSO del bracket CROSS, che e' il modello attivo: fa fallire il piano PRIMA dell'ordine. Se si torna a S:SM va rimesso a 0.312. haircut 0.05 — ✅ DIVERGENZA CHIUSA il 2026-08-31 (era 0.10, SBAGLIATO). La pagina margini del conto non espone l'haircut come numero: si RICAVA per differenza fra le due righe, perche' il modello CROSS conta l'USDE scontato e il SEGREGATO non lo conta affatto. Contributo dell'USDE al cross $610,81 su $643,05 di valore -> 5,0137%: l'ipotesi 5% torna a $0,09, la 10% sbaglia di $32,06. Riproducibile: `scripts/research/r0831_margini_conto.py` (N11). Il 26/08 il 10% fu registrato come 'verificato sul venue' senza lasciare traccia di come, e non lo era. 🚨 SCOPERTO NELLA STESSA LETTURA, e vale piu' dell'haircut: il modello di margine ATTIVO e' **Segregated: Standard Margin (S:SM)**, NON cross-collateral. Nella tabella del modello attivo l'USDE **non compare**: non fa margine per i perp USDC-settled del book. Percio' l'haircut oggi non si applica affatto — ed e' esattamente il motivo per cui la misura del 31/08 trovava $0,0000 accantonati. Passare a X:SM aggiungerebbe $610,87 di margine utilizzabile: e' una decisione dell'operatore, non un refactor, e porta con se' la meccanica cross (collateral fee 0,05%/giorno sul saldo negativo, ribilanciamento automatico).",
+  "usde": {
+    "index_name": "usde_usdc",
+    "haircut": 0.05,
+    "_nota_cuscino": "Dal 2026-09-10 (issue #7) la quota USDE NON e' un numero scelto: e' DERIVATA dal cuscino USDC di regolamento (n_asset x frac x disaster_sl_pct = 30% dell'equity) e da queste tre frazioni del cuscino, lette da src/live/usde.py per scripts/live/cuscino_watch.py (cron :53). cuscino_margine_frac 0.20 = bersaglio unico di ogni conversione: quota = 1 - 0.30 x 1.20 = 0.64 (il vecchio quota_target 0.70 lasciava slack ZERO: ogni ora in perdita avrebbe venduto). cuscino_preavviso_frac 0.10 = sotto, allerta. cuscino_riacquisto_frac 0.40 = sopra, si RICOMPRA USDE fino al bersaglio (un bonifico alza lo slack di 0,7 x importo e fa scattare il riacquisto da solo). Isteresi [0 ; 0.40] x cuscino con bersaglio a 0.20: oscillare richiede +-6% di equity di slack, cioe' +-8,6% di equity USDC (slack = 0,7 USDC - 0,3 USDE). Soglie DICHIARATE, non ottimizzate (M8): un giro costa ~6 bps sull'importo mosso. Ordine obbligato: 0 < preavviso < margine < riacquisto (usde.bande_cuscino lo verifica).",
+    "cuscino_preavviso_frac": 0.1,
+    "cuscino_margine_frac": 0.2,
+    "cuscino_riacquisto_frac": 0.4,
+    "venue_cap_frac": null,
+    "venue_cap_misurato": "2026-09-06: NESSUN tetto fino al 68,7% (fermata dal cuscino di regolamento al 70%, non dal venue): +2.434 USDE in 39 ordini a saldo crescente, zero rifiuti (r0906_usde_tetto_sonda.py). Il 30-31/08 il tetto c'era: [643-644) e [654-655) USDE su ~$2.055 = 31,3-31,9%. Non spiegato: e' SPARITO, non e' scalato. null = nessun tetto noto; usde_convert si affida al chunk+backoff sui rifiuti",
+    "quota_max_frac": 0.85,
+    "depeg_warn": 0.99,
+    "depeg_crit": 0.95
+  }
 }

docker-compose.yml

@@ -7,7 +7,12 @@ services:
     restart: unless-stopped
     command: ["uv", "run", "python", "-m", "src.live.dashboard", "--port", "8787"]
     ports:
-      - "8787:8787"
+      # Bind SOLO su 127.0.0.1: la dashboard non ha autenticazione e mostra conto e
+      # posizioni reali (Shadow live). Fino al 2026-08-04 era "8787:8787", cioe' pubblicata
+      # su tutte le interfacce e raggiungibile da internet: ufw NON protegge le porte
+      # pubblicate da Docker (il DNAT scavalca la catena INPUT). La consuma AI-OS da
+      # localhost per le risposte via Telegram.
+      - "127.0.0.1:8787:8787"
     volumes:
       - ./data:/app/data:ro
       # token mainnet (sola lettura) per lo "Shadow live": conto/posizioni reali sulla dashboard.

docs/diary/2026-07-24-goal-50eur-roadmap.md

@@ -111,8 +111,9 @@ capitale altrui = art. 166 TUF) approfondito nella ricerca dedicata sotto.
   MiFID-II da monitorare; **Hyperliquid ancora accessibile** senza KYC ma è il
   test-case del perimetro EU → rischio geoblock futuro reale. In pratica: i nostri
   due venue sono esattamente ciò che resta.
-- ⚠️ **FISCO ITALIA 2026**: capital gain crypto **33% dal 1/1/2026** (L.199/2025),
-  esenzione €2.000 ABOLITA, IVAFE 0.2%, DAC8 auto-reporting, crypto nell'ISEE.
+- ⚠️ **FISCO ITALIA 2026**: capital gain crypto **33% dal 1/1/2026** (~~L.199/2025~~ →
+  **L. 207/2024 art. 1 c.23-29**, corretto il 2026-08-07: la L.199/2025 fa altro, vedi CLAUDE.md),
+  esenzione €2.000 ABOLITA (dal 2025), IVAFE 0.2%, DAC8 auto-reporting, crypto nell'ISEE.
   → ogni numero di questo diario è LORDO: **50 EUR/g netti ≈ 75 EUR/g lordi**, il
   muro di capitale sale di ~1.5x (~EUR 180k a CAGR 15%). Da verificare col
   commercialista il trattamento di yield/staking.

docs/diary/2026-07-25-prop-wick-accoppiato.md

@@ -0,0 +1,234 @@
+# 2026-07-25 — La lente wick ACCOPPIATA: chiusura del follow-up dichiarato
+
+**Script:** `scripts/research/r0725_prop_coupled.py` · **Test:** `tests/test_prop_coupled.py` (13 casi)
+**Segue:** `2026-07-25-rendita-capcurve-prop.md` §5 (scala prop) e §7 (HyroTrader)
+**Book / pesi / cron: INVARIATI.** Nessuna decisione di portafoglio dipende da questo lavoro.
+
+---
+
+## 1. Cosa era rimasto aperto, e perché contava
+
+La scala di conti funded (§5 del diario di stamattina) era stata giudicata con **due lenti** che
+differiscono di un **ordine di grandezza** su P(≥50 €/g in 3 anni):
+
+| lente | P(≥50/g) | com'era descritta |
+|---|---|---|
+| close-only | **20.7%** | tetto ottimista — le regole prop scattano sull'equity intraday, non sulla chiusura |
+| wick indipendente | **1.6-2.5%** | pavimento pessimista — gap lognormale estratto **indipendente** dal rendimento del giorno |
+
+Una banda 1.6%-20.7% non decide niente: è la differenza fra "scommessa a coda destra che vale i
+600 euro" e "non vale la pena". E il difetto del pavimento era **già dichiarato** nel docstring:
+
+> *«nella realtà i wick profondi stanno sulle giornate brutte (sono ACCOPPIATI): estrarli
+> indipendenti aggiunge finti tuffi anche nelle giornate buone → breach spuri → stima troppo
+> severa. Il modo giusto è il bootstrap delle TUPLE (ritorno, gap) come in
+> r0724_goal50_intraday_mc.py, che però ha il recon solo per TP01+SKH01 → FOLLOW-UP dichiarato.»*
+
+Questo lavoro chiude quel follow-up.
+
+## 2. Metodo
+
+Tre pezzi, tutti verificati contro qualcosa di indipendente:
+
+1. **Recon per-sleeve a risoluzione oraria.** `r0724` calcola il minimo intraday del book Deribit
+   con i pesi 75/25 **cablati dentro**. Qui i pesi si dividono via per ottenere gli sleeve nudi
+   (ret, wick) di TP01 e SKH01 — così il minimo si compone **esattamente** sul path orario per
+   **qualsiasi** vettore di pesi. Logica invariata: exit-al-livello, SL prioritario, fee.
+2. **Lente accoppiata per XS01**, che su Hyperliquid è 1d nativo. L'escursione intraday si
+   ricostruisce dagli **OHLC giornalieri** dei 19 alt: il book si valuta ai 4 checkpoint
+   O / primo estremo / secondo estremo / C, con **ordinamento condiviso** fra le gambe (le alt
+   co-muovono) preso nell'ordine **avverso**. Non è path-exact, ma è **accoppiato al giorno vero**,
+   che è tutto il punto.
+   *Sanity:* il recon riproduce lo sleeve ufficiale con `max|Δ| = 0.0` esatto.
+3. **Le tre lenti sulla stessa macchina di simulazione** (close / indipendente / accoppiata), così
+   il confronto non mescola differenze di modello con differenze di lente.
+
+---
+
+## 3. Il risultato principale: la calibrazione era giusta, l'**indipendenza** era l'errore
+
+Confronto delle distribuzioni **marginali** del gap (book live TP01/SKH01, 2691 giorni):
+
+| | p50 | p90 | p99 | peggiore |
+|---|---|---|---|---|
+| **accoppiato (recon)** | −0.17pp | −1.03pp | −2.70pp | −5.96pp |
+| indipendente (calibrazione 25/07) | −0.17pp | −0.90pp | −3.50pp | — |
+
+**Sono quasi identiche.** La calibrazione lognormale di stamattina era buona. Quello che era
+sbagliato non è *quanto* sono profondi i tuffi, ma **su quali giorni cadono**.
+
+### 3.1 E la dipendenza va nel verso inatteso
+
+Mi aspettavo — e lo avevo scritto — che i gap profondi stessero sui giorni brutti. **È il
+contrario:**
+
+| book | giorni | m==R | gap medio | gap \| decile PEGGIORE | gap \| decile MIGLIORE |
+|---|---|---|---|---|---|
+| A TP01/SKH01 (live) | 2691 | 26% | −0.38pp | **−0.48pp** | **−1.58pp** |
+| B +XS01 (diversif.) | 937 | 20% | −0.36pp | −0.39pp | −1.30pp |
+| TP01 solo | 2691 | 33% | −0.39pp | −0.59pp | −1.57pp |
+| SKH01 solo | 2691 | 76% | −0.39pp | −0.40pp | −2.97pp |
+| XS01 solo | 937 | 53% | −0.44pp | −0.22pp | −2.32pp |
+
+L'escursione intraday è **~3× più profonda nei giorni che finiscono BENE** che in quelli che
+finiscono male. Il meccanismo, una volta visto, è ovvio: un giorno brutto **scende tutto il
+giorno e chiude sul minimo** (`m == R` nel 26% dei giorni: la chiusura *è* il peggio), mentre
+un recupero a V ha un minimo profondo e una chiusura alta.
+
+Il breach però si valuta **sul minimo**. Quindi ciò che conta è quanto gap si aggiunge **nei
+giorni brutti** — e lì il gap vero è ~1/3 di quello dei giorni buoni. Un'estrazione indipendente
+usa la stessa distribuzione ovunque, e così **carica i giorni brutti con la coda che nella realtà
+appartiene ai giorni buoni**.
+
+### 3.2 Quanto costa, misurato sui giorni storici (nessun bootstrap)
+
+Frazione di giorni che sfondano la regola di daily-loss:
+
+| book | leva | regola | close-only | **ACCOPPIATO** | indipendente | gonfiaggio |
+|---|---|---|---|---|---|---|
+| A (live) | 0.75 | daily 4% (HYRO) | 0.00% | 0.21% | 0.40% | **1.9×** |
+| A (live) | 1.00 | daily 4% (HYRO) | 0.00% | 0.32% | 0.78% | **2.4×** |
+| B (+XS01) | 0.75 | daily 4% (HYRO) | 0.00% | 0.11% | 0.25% | **2.4×** |
+| B (+XS01) | 1.00 | daily 5% (FTMO) | 0.00% | 0.11% | 0.31% | **2.9×** |
+
+Due letture:
+- la lente indipendente **raddoppia** i breach da daily-loss (2.0-2.9×);
+- **close-only non è "leggermente ottimista": è strutturalmente cieca.** Fa `0.00%` su ogni riga —
+  la regola di daily-loss **non scatta mai** sulle chiusure. Non è una lente approssimata, è una
+  lente che non vede affatto quel vincolo.
+
+---
+
+## 4. Tre verifiche — perché un "nessuna differenza" va provato, non assunto
+
+### (1) Risoluzione: l'1h basta? — **sì, misurato**
+
+TP01 tiene peso costante nel giorno, quindi il suo minimo intraday si può calcolare **anche a 5m**
+ed è un confronto pulito:
+
+| | p50 | p90 | p99 | peggiore |
+|---|---|---|---|---|
+| gamba TP01 @1h | −0.337pp | −1.358pp | −3.056pp | −5.34pp |
+| gamba TP01 @5m | −0.336pp | −1.366pp | −3.136pp | −5.33pp |
+
+Identici. **Il caveat "i wick a 1h sono un tetto, i 5m sarebbero più profondi" — portato avanti dal
+24/07 — è quantificato e trascurabile.** L'ora cattura già il minimo del giorno: i 5m aggiungono
+solo rumore dentro un'ora di minimo già individuata.
+
+*Nota di metodo:* entrambe le righe riportavano `n=1865` e la cosa sembrava un errore (stessa
+serie confrontata due volte). Non lo era: il filtro scarta i giorni in cui TP01 è **flat** (~30%),
+che sono gli stessi a qualsiasi risoluzione. Verificato prima di accettare il risultato.
+
+### (2) Riconciliazione col 24/07 — **la discrepanza dichiarata è risolta**
+
+CLAUDE.md portava un ⚠ aperto: *«Discrepanza col 24/07 (P(vivo) A@0.75x 58% vs 10% mio)»*, con
+l'ipotesi che fosse un effetto-finestra. **Non era la finestra, era la lente:**
+
+| finestra | lente | P(pass) | P(vivo 1a) | E[payout/a] |
+|---|---|---|---|---|
+| 2019-03+ FULL | close | 53.8% | 79.7% | $2.085 |
+| **2019-03+ FULL** | **accoppiato** | 48.1% | **63.2%** | $1.618 |
+| 2024+ comune | close | 47.0% | 74.8% | $1.632 |
+| 2024+ comune | accoppiato | 35.6% | 39.4% | $770 |
+
+Sulla **stessa finestra piena** del 24/07 (recon MTM indipendente, che dava **58%**) la mia lente
+accoppiata dà **63.2%** — accordo entro 5pp, con due implementazioni scritte separatamente. Il
+**10%** del 25/07 era l'artefatto della lente indipendente. La finestra spiega il resto
+(63.2% full → 39.4% sul 2024+, dove config A è debole).
+
+### (3) Bound severo su XS01 — **non ribalta niente**
+
+È XS01 a reggere il vantaggio della config diversificata, e il suo gap dipende da una convenzione
+(ordinamento condiviso). Girato anche il bound opposto — ogni gamba al **proprio** peggio nello
+stesso istante, fisicamente impossibile su 10 gambe co-moventi ma utile a delimitare l'errore:
+
+| convenzione | gap p90 | peggiore | P(pass) | P(vivo 1a) | E[payout/a] |
+|---|---|---|---|---|---|
+| ordine condiviso (base) | −0.86pp | −4.81pp | 42.9% | **76.0%** | $1.144 |
+| per-gamba (bound severo) | −1.83pp | −15.56pp | 32.3% | **57.6%** | $814 |
+| *config A, per confronto* | — | — | 35.6% | **39.4%** | $770 |
+
+Anche al bound severo **config B resta sopra config A** (57.6% vs 39.4%, $814 vs $770). La
+conclusione non dipende dalla convenzione.
+
+---
+
+## 5. Cosa cambia nelle decisioni
+
+### 5.1 La raccomandazione HyroTrader si sposta da 0.50x a **0.75x**
+
+Config B (book diversificato, +XS01), lente accoppiata, finestra 2024+:
+
+| leva | P(pass eval) | P(vivo 1a) | E[payout/a] | **E[payout] su 3 anni** |
+|---|---|---|---|---|
+| 0.50x | 28.6% | 99.5% | $412 | ~$1.230 |
+| **0.75x** | 42.9% | 76.0% | $1.144 | **~$2.674** |
+| 1.00x | 46.6% | 42.1% | $1.246 | ~$1.992 |
+
+Stamattina la scelta era **0.50x**, perché la lente indipendente dava a 0.75x una sopravvivenza
+del 55%. Con la lente onesta la sopravvivenza a 0.75x è **76%**, e 0.75x **massimizza il payout
+atteso su 3 anni** — batte 0.50x di 2,2× e 1.00x di 1,3× (a 1.00x la sopravvivenza crolla e
+l'effetto composto la punisce). L'argomento del 25/07 — *"la sopravvivenza compone su più anni"* —
+resta valido; è il punto in cui morde che si sposta.
+
+### 5.2 La scala di conti: il ranking regge, i livelli no
+
+| lente | leva | MISTO EUR/g med | P(≥10/g) | P(≥50/g) | P(zero) |
+|---|---|---|---|---|---|
+| close-only | 1.00x | 11.11 | 50.8% | **22.0%** | 33.9% |
+| **accoppiata** | **0.75x** | 0.00 | **29.7%** | 5.6% | **52.2%** |
+| **accoppiata** | **1.00x** | 0.00 | 20.8% | **6.5%** | 65.5% |
+| indipendente | 1.00x | 0.00 | 5.2% | 1.0% | 81.5% |
+
+- **L'ordinamento fra politiche SOPRAVVIVE a tutte e tre le lenti**: MISTO ≥ CONC-DIV >
+  CONC-2SL ≈ SPARSO. L'affermazione di stamattina — *«il confronto fra POLITICHE è robusto:
+  è la stessa lente applicata a tutte»* — è confermata su una lente che allora non esisteva.
+  **CONC-2SL (= il book live attuale su ogni conto) resta la peggiore o penultima ovunque.**
+- **I livelli si spostano parecchio.** La stima onesta di P(≥50/g) in 3 anni è **~5,6-6,5%**, non
+  1,6-2,5% e non 20,7%. La scala è **~3-4× più probabile** di quanto diceva il pavimento e
+  **~3,4× meno** di quanto diceva il tetto.
+- **P(≥10/g) è massima a 0.75x (29,7%)**, non alla leva piena: l'ottimo di leva della scala
+  coincide con quello del conto singolo.
+- Il prezzo resta alto: **P(bruciare i €600) = 52% a 0.75x, 65% a 1.00x.**
+
+### 5.3 Il verdetto sul goal, ristretto
+
+Il 25/07 concludeva: *«una via da €600 a €50/g ESISTE con P ~2-21% in 3 anni e P(bruciare i €600)
+~33-78% → scommessa a coda destra, NON una rendita»*. Con la lente onesta la banda si stringe:
+
+> **P(≥50 €/g entro 3 anni) ≈ 6%, con P(perdere i €600) ≈ 52-65%.**
+> Resta una scommessa a coda destra. Ma è una scommessa con una probabilità **conoscibile**,
+> non un intervallo di un ordine di grandezza.
+
+---
+
+## 6. Cosa NON cambia
+
+- **Book, pesi, cron: invariati.** Niente qui tocca il portafoglio.
+- Il fronte prop **non è aperto**: questo lavoro dice *cosa costerebbe e con quale probabilità*,
+  non che vada fatto.
+- Resta il caveat di finestra del 25/07: il **2024+** è la finestra in cui XS01 è stato scoperto e
+  affinato → la **taglia** del vantaggio di config B è ottimista; il **meccanismo** (correlazione
+  bassa → meno DD → più sopravvivenza sotto vincolo di DD) è robusto. La verifica (2) qui sopra
+  quantifica per la prima volta quanto pesa la finestra da sola (63.2% → 39.4% su config A).
+- XS01 resta **STAT-MODE sul capitale proprio** (serve ~$20k). Su un conto funded da $100k è
+  eseguibile: è esattamente l'asimmetria capitale-proprio vs funded del §4 di stamattina.
+
+---
+
+## 7. Lezione da portare avanti
+
+> **Un modello di rischio intraday non si valida sulla distribuzione marginale del wick, ma sul suo
+> ACCOPPIAMENTO al rendimento del giorno.** Qui la marginale era calibrata quasi perfettamente
+> (p50 −0.17pp identico) e ciò nonostante il modello sbagliava di 2-3× sui breach, perché metteva
+> i tuffi sui giorni sbagliati. Un test "i percentili del mio wick sintetico coincidono con quelli
+> del recon" sarebbe **passato**, e la stima sarebbe rimasta sbagliata.
+
+Corollario controintuitivo, da ricordare perché è il contrario dell'intuizione: **l'escursione
+intraday è più profonda nei giorni che chiudono bene**. I giorni che chiudono male chiudono *sul*
+minimo. Ogni regola valutata sul minimo (daily-loss, trailing DD, stop di conto) va misurata su
+tuple accoppiate, mai su un wick estratto a parte.
+
+Terzo: **close-only non è una lente conservativa, è una lente cieca** per le regole intraday —
+0.00% di breach da daily-loss su ogni configurazione testata. Va usata come controllo, mai come
+stima.

docs/diary/2026-07-25-rendita-capcurve-prop.md

@@ -25,11 +25,25 @@ Entrambe le cose sono false come codificate:
 
 | capitale allocato a GTAA | CAGR reale | Sharpe reale | drag commissioni |
 |---|---|---|---|
-| $600 | **−3.5%** | **−0.55** | 9.0%/anno |
-| $2.000 | −0.7% | −0.09 | 6.2%/anno |
-| $5.000 | +1.5% | 0.28 | 4.0%/anno |
-| $50.000 | +3.4% | 0.59 | 2.1%/anno |
-| *modellato (2bps)* | *+5.5%* | *0.77* | — |
+| $600 | **−3.5%** | **−0.55** | 7.2%/anno |
+| $2.000 | −0.7% | −0.09 | 4.4%/anno |
+| $5.000 | +1.5% | 0.28 | 2.2%/anno |
+| $50.000 | +3.4% | 0.59 | 0.2%/anno |
+| *modello vecchio (2bps propor.)* | *+3.8%* | *0.64* | — |
+
+⚠️ **Correzione a un errore MIO, trovata implementando il fix.** La prima stesura di questa
+sezione citava il modello vecchio a *Sharpe 0.77 / CAGR 5.5%*: era un **artefatto di
+annualizzazione** del mio script di analisi — metricavo la serie GTAA grezza (solo giorni di
+borsa, ~252/anno) con `metrics()`, che annualizza a 365 e calcola `years = n/365.25` → Sharpe
+gonfiato di √(365/252) = 1.20× e CAGR di ~1.45×. Le righe per-capitale erano già su calendario
+365 (reindex + weekend a zero), quindi **il confronto era falsato solo sulla riga di riferimento**.
+Valore corretto del modello vecchio: **0.64 / 3.8%**.
+
+**La formulazione giusta del difetto cambia di conseguenza.** Non è "il modello sovrastimava lo
+Sharpe di 0.13": alla taglia grande il modello vecchio era sostanzialmente **giusto** (0.64 contro
+0.59-0.66 reali). Il difetto è che era **CIECO AL CAPITALE** — dava 0.64 sia a $50.000 sia a $600,
+mentre a $600 la realtà è **−0.55**. Un modello di costo proporzionale non può descrivere un
+pavimento fisso, e l'errore è tutto concentrato dove lo sleeve verrebbe realmente deployato.
 
 **La banda lo salva.** Con costo fisso la banda ottimale non è il minimo eseguibile (come su
 Deribit) ma un valore molto più alto. Plateau robusto = **cadenza settimanale × banda $25-100**
@@ -38,11 +52,24 @@ dà **Sh 0.52 / CAGR 3.0%** invece di −0.55/−3.5%. (La cella argmax a $600 e
 a 0.57, ma è isolata — crolla a 0.28 a banda 100 → scartata: il parametro è di costo, si sceglie
 sul plateau, non sull'argmax in-sample.)
 
-**Due conseguenze.**
-1. Se GTAA01 va live su IB **deve** avere banda+cadenza cablate. Come sta ora, a $600-2k è un
-   distruttore di capitale.
-2. Lo Sharpe **onesto** di GTAA01 è **~0.55-0.64, non 0.77** → i numeri headline del book a 5
-   sleeve vanno citati con questo haircut (in aggiunta all'anchor-luck già documentato).
+**Conseguenza operativa: CABLATO** (stessa sessione, `src/portfolio/gtaa.py`). Il modulo ora
+modella il costo IB reale (`ib_commission`), esegue a **banda + cadenza** (settimanale, $50/gamba),
+prende il **capitale allocato** come parametro (`gtaa_returns(capital=...)`), dichiara la soglia
+di deployabilità (`GTAA_MIN_CAPITAL = $3.000`, `gtaa_is_deployable`) ed espone
+**`gtaa_rebalance_plan(held, capital)`** — il piano che l'esecutore deve usare per non ribilanciare
+ogni giorno per pochi dollari. `sleeves.py` dichiara esplicitamente il capitale assunto
+(`GTAA_DEFAULT_CAPITAL = $10.000` allocati ≈ book $50k al peso 20%) invece di nasconderlo.
+
+**Impatto sul book, misurato prima/dopo** (non citato: ricalcolato sostituendo la sola gamba GTAA):
+
+| | GTAA01 standalone | book 5 sleeve FULL | HOLD | maxDD |
+|---|---|---|---|---|
+| prima (2bps, continuo) | Sh 0.64 / CAGR 3.76% | 2.22 | 2.36 | 6.2% |
+| dopo (IB reale + banda) | Sh 0.61 / CAGR 3.65% | 2.22 | **2.38** | **6.0%** |
+
+Alla taglia assunta l'impatto sul book è **trascurabile** — il fix non è cosmetico per i numeri
+storici, lo è per il **deploy**: è a $600-2.000 che cambia tutto (da −3.5%/anno a +3.0%/anno).
+Pesi **invariati** (nessun cambio pesi → nessun `weights_tilt_null` richiesto).
 
 **Regola nuova (generale): il costo di un venue va modellato nella sua FORMA — fisso vs
 proporzionale — non solo nel suo livello.** Due venue con lo stesso "costo medio" danno

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.

docs/diary/2026-07-26-fee-deribit.md

@@ -0,0 +1,123 @@
+# 2026-07-26 — Nuovo schema fee Deribit (dal 1 agosto 2026): la curva, non il numero
+
+**Input:** annuncio Deribit di un nuovo schema fee **effettivo 2026-08-01** — taker piu' bassi e
+maker rebate piu' bassi su futures/perpetual, soglie VIP abbassate, nuovo tier VIP7,
+**liquidation fee 1% su tutti i prodotti** (opzioni: cap premio 25%), fee spot temporaneamente
+azzerate fino al collegamento coi mercati spot Coinbase.
+
+**Script:** `r0726_fee_sensitivity.py`. **Test:** `tests/test_fee_sensitivity.py` (6).
+**Book, pesi, cron, config: INVARIATI.**
+
+---
+
+## 0. Perche' non ho aspettato la tabella
+
+La fee e' un **vincolo di prim'ordine** dichiarato di questo progetto ("0.10% RT baseline; molte
+operazioni = morte per fee"). Ma l'annuncio non contiene un solo numero, e **la tabella numerica
+nell'articolo Insights e' un'IMMAGINE**: non l'ho letta da fonte primaria.
+
+⚠️ I valori che cito del nuovo schema vengono da un **riassunto testuale secondario**, non dalla
+tabella di Deribit: tier base ~**5 bps taker / 2 bps maker**, VIP7 **2/0 bps**. Vanno trattati come
+indicativi finche' non si legge il tier reale in Account Settings.
+
+Quindi invece di assumere un numero ho misurato la **curva**: quando la tabella e' leggibile si
+prende il valore giusto da qui, senza rifare l'analisi.
+
+Il progetto modella ovunque **5 bps/lato = 0.10% RT (taker)**: `trend_portfolio.CANONICAL
+.fee_side = 0.0005`, `sleeves._skyhook_returns fee_rt=0.001`, paper monitor `FEE_SIDE = 0.0005`.
+Le repliche parametrizzate riproducono **bit-exact** gli sleeve di produzione alla fee canonica
+(`max|dif| = 0.0`, test permanenti) — altrimenti la curva descriverebbe un'altra strategia.
+
+---
+
+## 1. La curva
+
+```
+ bps/lato   %RT |  TP01 Sh   CAGR |  SKH01 Sh   CAGR |  BOOK Sh   CAGR   maxDD
+      0.0  0.00% |   1.322  16.60% |    1.567  35.66% |   1.849  21.69%   8.92%
+      1.0  0.02% |   1.316  16.51% |    1.543  34.95% |   1.833  21.46%   9.02%
+      2.0  0.04% |   1.309  16.42% |    1.519  34.24% |   1.816  21.22%   9.12%
+      3.0  0.06% |   1.303  16.33% |    1.495  33.53% |   1.799  20.99%   9.22%
+      5.0  0.10% |   1.290  16.15% |    1.446  32.14% |   1.766  20.53%   9.42%  <- oggi
+      7.5  0.15% |   1.274  15.92% |    1.385  30.41% |   1.724  19.96%   9.67%
+     10.0  0.20% |   1.258  15.69% |    1.324  28.70% |   1.682  19.39%   9.92%
+     15.0  0.30% |   1.226  15.24% |    1.200  25.36% |   1.597  18.26%  10.59%
+
+drag della fee attuale vs fee zero:  TP01 -0.032 Sh / -0.46% CAGR
+                                     SKH01 -0.121 Sh / -3.52% CAGR
+                                     BOOK  -0.084 Sh / -1.15% CAGR
+sensibilita' marginale:              BOOK  -0.017 Sharpe/bps   -0.23% CAGR/bps
+```
+
+**Il book e' poco sensibile.** Anche un raddoppio del taker a 10 bps costerebbe 0.08 di Sharpe —
+**meno della banda d'ancora misurata oggi stesso** (book FULL canonico 2.222 vs mediana 1.946).
+Mettere la fee nella giusta scala di grandezza: e' un effetto piu' piccolo dell'ancora.
+
+### I due sleeve NON sono uguali
+
+**SKH01 e' ~4x piu' sensibile di TP01** (−0.69% vs −0.09% di CAGR per bps/lato). Il motivo e'
+strutturale: SKH01 fa round-trip **discreti** (~500 trade sui 7 anni per asset), TP01 e' una
+posizione **continua vol-targeted** che ribilancia poco. Conseguenza operativa: **se il taker
+salisse in modo serio, il primo parametro da rivedere e' il peso 75/25, non il resto**; se scende,
+SKH01 e' quello che guadagna di piu'.
+
+---
+
+## 2. I quattro punti dell'annuncio, uno per uno
+
+| punto | ci tocca? |
+|---|---|
+| **Taker piu' basso** | bene o neutro: a 3 bps il book va 1.766 → 1.799 di Sharpe. Nessuna decisione cambia. |
+| **Maker rebate piu' basso** | **non oggi**: il book manda ordini **market** (taker). |
+| **Liquidation fee 1%** | **irrilevante** — vedi sotto. |
+| **Soglie VIP piu' basse + VIP7** | **irrilevante a $600**: volume 30g trascurabile, restiamo al tier base a qualunque soglia. |
+
+### Il maker tocca una raccomandazione non implementata
+
+L'idea **T1 del 26/07** — TP di SKH01 come **limit resting** per incassare il maker — perderebbe
+parte della sua convenienza se il maker passa da rebate a **+2 bps**. Ma: (a) **non e'
+implementata** (lo blocca il fatto che TP01 e SKH01 tradano lo stesso strumento con una sola
+posizione netta), e (b) il beneficio misurato era quasi tutto *"convertire una lotteria in
+certezza"*, non la fee. Quindi il cambio maker **non riapre** quella decisione, la rende solo
+meno appetibile se un giorno si riaprisse.
+
+### Liquidation fee 1%: perche' e' irrilevante
+
+`live.json` impone `max_notional_per_asset_frac = 0.5` su **2 asset** → nozionale lordo massimo
+**1.00x l'equity**, con `disaster_sl_pct = 0.30`. A leva ≤1x la liquidazione richiederebbe un
+movimento avverso ~100%, e il disaster-SL interviene a −30%.
+
+⚠️ Questa conclusione **poggia sul cap**, non sulla strategia. Se il cap sale, decade. Per non
+lasciarla valida per inerzia c'e' una **guardia di decisione** cablata
+(`test_leva_massima_da_config_resta_sotto_o_uguale_a_1x`): alzare il cap **rompe il test** e
+rimanda qui.
+
+---
+
+## 3. Azione
+
+**Nessuna adesso.** Il 1 agosto: leggere il tier reale in Account Settings e confrontarlo con la
+curva. Regola decisa in anticipo, per non decidere col numero davanti:
+
+* taker **≤5 bps/lato** → non si tocca nulla (il modello e' gia' giusto o conservativo);
+* taker **>10 bps/lato** → rivedere per primo il peso di SKH01 (e' li' che morde 4x).
+
+**Cio' che il cambio NON puo' rompere:** tutti i backtest del progetto sono a 0.10% RT, quindi se
+la fee scende diventano **conservativi** — la direzione dell'errore e' quella giusta.
+
+---
+
+## 4. Regole trasferibili
+
+1. **Quando arriva un annuncio senza numeri, misurare la CURVA invece di aspettare il numero.**
+   Il risultato vale per qualunque valore esca, e sposta la decisione da "aspettiamo" a "sappiamo
+   gia' cosa fare in ogni caso".
+2. **Dichiarare la qualita' della fonte.** Qui la tabella e' un'immagine non letta: i numeri del
+   nuovo schema sono **secondari** e vanno etichettati come tali, non usati come se fossero il
+   listino.
+3. **Una conclusione che poggia su un parametro di config va legata a un test su quel parametro.**
+   "Liquidation fee irrilevante" e' vera *perche'* la leva e' ≤1x; senza guardia sopravviverebbe
+   al cambio di cap che la rende falsa.
+4. **Mettere ogni effetto nella sua scala di grandezza.** Un raddoppio della fee vale meno della
+   fortuna d'ancora dello stesso book: senza il confronto si rischia di dedicare a una fee un
+   allarme che merita altro.

docs/diary/2026-07-26-gtaa-ucits.md

@@ -0,0 +1,613 @@
+# 2026-07-26 — GTAA01 sugli UCITS: la via d'uscita dal blocco PRIIPs è aperta, e il broker non è la variabile
+
+**Domanda dell'operatore:** *"usiamo revolut o degiro"* — dopo che il conto reale ha rifiutato
+l'ordine sui 6 ETF USA di GTAA01 con `Trading limitato — Questo prodotto non dispone di un KID`.
+
+**Risposta breve:** cambiare broker non sblocca niente (il PRIIPs è una norma, non una politica di
+IB). Ciò che sblocca è cambiare **veicolo**. Misurato: il cambio di veicolo costa **~0**, e con la
+scelta giusta delle linee lo sleeve è eseguibile **senza frazionamento** già a $3.000.
+
+**Book, pesi, cron, config: INVARIATI.** GTAA01 non entra nel book live (resta la decisione venue
+del 26/07: 100% Deribit fino a $20k).
+
+Script: `scripts/research/fetch_ib_ucits.py`, `scripts/research/r0726_gtaa_ucits.py`.
+Modulo nuovo: `src/data/eq_crosscheck.py`. Test: `tests/test_eq_crosscheck.py` (14),
+`tests/test_gtaa_ucits.py` (10).
+
+---
+
+## 0. La premessa che era falsa, ed è la ragione per cui il problema è piccolo
+
+La nota che avevo scritto in `src/portfolio/gtaa.py` diceva:
+
+> storia più CORTA (diversi nati dopo il 2010) → si perde la validazione a 30 anni che è ciò che
+> rendeva credibile questo sleeve
+
+**È falsa, per un motivo strutturale: il PRIIPs vieta di COMPRARE, non di GUARDARE.** I prezzi di
+SPY/QQQ/IWM/TLT/GLD/HYG restano leggibili — l'operatore li aveva sotto gli occhi sul terminale
+*mentre* l'ordine veniva rifiutato. Quindi il **segnale** di GTAA01 può continuare a girare sui 30
+anni di serie USA per sempre; cambia solo il **veicolo** su cui si incassa il rendimento.
+
+La storia corta degli UCITS non serve a validare la strategia. Serve a misurare una cosa sola: la
+**deviazione del veicolo**, che è un drift lento e si stima bene anche su pochi anni.
+
+> **Regola:** prima di dichiarare che un vincolo esterno distrugge un risultato, chiedersi
+> *esattamente cosa* vincola. Qui la differenza fra "non posso comprare" e "non posso vedere"
+> separa uno sleeve morto da uno sleeve con un problema di esecuzione.
+
+---
+
+## 1. Il dato, prima della strategia — e il feed equity non aveva un cross-check
+
+Estratti 12 veicoli UCITS da IB (`LSEETF`, **tutti in USD**: quotare in USD elimina un livello di
+costo, la conversione per ordine). Alla prima certificazione, **7 su 10 con gap lunghi** e CSPX con
+un **+27.8% giornaliero** su un tracker S&P 500.
+
+I gap sono tutti **al lancio** della linea USD (ultimo gap lungo: CSPX 2014-04, XRSU 2016-10,
+IGLN/IHYU 2011); negli ultimi 3 anni tutti i veicoli fanno 253 barre/anno. Non è un problema
+corrente.
+
+Il +27.8% invece è un difetto vero. La barra CSPX 2012-01-13:
+
+```
+open 112.740   high 112.740   low 88.010   close 88.010
+```
+
+**`open`/`high` in USD, `low`/`close` in EUR** — fattore dai close adiacenti **1.2797**, cioè
+l'EURUSD di quel giorno (reale 1.266-1.282). Andata e ritorno: 112.63 → 88.01 → 112.47 mentre SPY
+faceva −0.39% e +0.23%.
+
+**La certificazione esistente non lo vedeva.** L'unica guardia sui movimenti era
+`maxret > 50% → SPIKE?`, e una contaminazione EUR/USD vale ~22-28%. È lo **stesso schema** dello
+split 2:1 non aggiustato del 25/07 (che valeva *esattamente* −50%): una soglia tarata su una classe
+di difetto non sorveglia le altre.
+
+### Perché serviva il gemello e non una regola locale
+
+Il discriminante del 25/07 (**range intraday**) qui non funziona: una barra contaminata ha un range
+enorme, ma anche un crollo vero (SLV 2026-01-30 aveva 33% di range). Ciò che separa i due casi è che
+**un evento di mercato lo fa anche il gemello**: nel *rapporto* veicolo/gemello i movimenti veri si
+cancellano.
+
+Controprova su dati reali: la stessa scansione fatta sui **prezzi** segnalava IDTL 2020-03
+(liquidazione dei treasury) e IGLN 2013-04 (crollo dell'oro) — andate-e-ritorni identiche nella
+forma. Sul **rapporto** spariscono, e resta la sola CSPX 2012-01-13.
+
+Questo è il buco che il feed equity aveva: nel crypto la certificazione incrocia sempre più venue
+(`certify_feed.py` vs Coinbase USD); il feed equity aveva **solo controlli locali**.
+
+### La soglia non è tarabile sulla deviazione, ed è il punto interessante
+
+| statistica | rumore massimo misurato | difetto CSPX | margine |
+|---|---|---|---|
+| deviazione dal gemello | **9.90%** (2025-04-09) | 21.4% | 2.2× ❌ |
+| **|dev| / movimento del gemello** | **8.1** | **42.7** | **5.3×** ✅ |
+
+Il 9.90% è **legittimo**: Londra chiude alle 11:30 di New York, quindi in un giorno violento le due
+chiusure sono davvero lontane. Ma **un disallineamento d'orario non può superare il movimento del
+mercato**: se il gemello si è mosso dello 0.4% e il veicolo se ne va del 21%, non c'è orario che lo
+spieghi. La statistica adimensionale porta il margine da 2.2× a 5.3× — sopra il 3× che questo
+progetto richiede a un rilevatore.
+
+Tre condizioni congiunte (come il rilevatore di split, e per la stessa ragione): deviazione oltre
+`MIN_DEV`, non-spiegato oltre `MIN_UNEXPLAINED=18.0`, e **rientro** entro 5 barre (una divergenza di
+NAV vera persiste, una stampa sbagliata no).
+
+**Riparazione = scartare la barra, non ricostruirla.** Del prezzo vero non sappiamo niente;
+sappiamo che quello scritto è sbagliato. Scartarla rende corretto il rendimento 12/01→17/01
+(−0.14%); "ripararla" con un fattore stimato inventerebbe un dato.
+
+### ⚠️ Limite dichiarato, e come è stato chiuso
+
+GBPUSD ~1.27 → 21% di deviazione = **sempre rilevata**. EURUSD ~1.09 → 8.3% = **dentro il rumore**
+dei giorni violenti. Non è tappabile abbassando la soglia (sotto 12 si segnalano i giorni veri).
+
+Invece di inseguire la rilevabilità ho misurato il **danno** di una contaminazione non vista:
+iniettando 60 contaminazioni casuali, **dSharpe mediano −0.003, peggiore −0.056, |Δ|>0.05 nel 2%
+dei casi**. Il limite resta, ma è quantificato e irrilevante.
+
+> **Regola:** quando un rilevatore ha un buco che non si può chiudere senza generare falsi positivi,
+> si misura il **danno** del caso non rilevato, non la sua probabilità. Un buco quantificato e
+> innocuo è un risultato; un buco taciuto è un debito.
+
+---
+
+## 2. Quanto costa il veicolo: ~zero — ma lo stimatore ovvio dà la risposta sbagliata
+
+Prima stesura: media delle differenze giornaliere → **CSPX −0.47%/anno**. Sbagliato.
+
+Le due serie seguono lo **stesso indice** ma sono campionate a orari diversi. La differenza
+giornaliera è dominata da uno sfasamento che si **inverte il giorno dopo**: volatilità 17-22%
+annualizzata, **errore standard ~7%/anno** sulla stima del drag — cioè **15 volte più grande del
+drag stesso**. In più la media delle differenze *semplici* è contaminata dal drag di varianza.
+
+Il rapporto veicolo/gemello invece è **stazionario**: il suo drift *è* il drag.
+
+| gamba | UCITS | drag misurato | atteso da TER | + ritenuta USA | banda annua |
+|---|---|---|---|---|---|
+| SPY | CSPX | **−0.06%** | +0.02% | +0.20% | [−0.52,+0.63] |
+| QQQ | EQQQ | **−0.00%** | −0.10% | −0.03% | [−0.13,+1.29] |
+| IWM | XRSU | **−0.15%** | −0.11% | +0.07% | [−0.91,+0.37] |
+| TLT | IDTL | **+0.18%** | +0.08% | +0.68% | [−0.45,+1.60] |
+| GLD | IGLN | **+0.36%** | +0.28% | +0.28% | [−0.56,+0.99] |
+| HYG | IHYU | **+0.28%** | −0.01% | +0.89% | [−0.83,+1.88] |
+| **media EW** | | **+0.10%/anno** | +0.03% | **+0.35%** | |
+
+Controllo di plausibilità: **segno concorde in 4/6, scarto < 30bps in 6/6**. Il caso più netto è
+l'oro (GLD 0.40% vs IGLN 0.12% → atteso +0.28%, misurato +0.36%): è un controllo indipendente che la
+misura sta cogliendo il TER e non rumore. Le due gambe discordi restano entro 30bps, e su una banda
+annua larga [−0.9%,+1.9%] il segno di uno scarto così piccolo non è informativo. **Ciò che il
+controllo stabilisce è la scala: decine di bps, non punti.**
+
+⚠️ La colonna "ritenuta" è **a favore dell'UCITS e non è nel drag misurato**: `ADJUSTED_LAST` sulle
+serie USA è al **lordo** della ritenuta USA del 15% che un residente italiano paga davvero sui
+dividendi. Comprando SPY quella ritenuta la paghi e nella serie non c'è; un UCITS irlandese la
+subisce una volta a livello di fondo e non una seconda all'incasso. *(Ipotesi fiscale dichiarata,
+fonte secondaria, da confermare col commercialista — non è un parere fiscale.)*
+
+### Le tre lenti
+
+| lente | Sharpe | CAGR | maxDD | vol |
+|---|---|---|---|---|
+| L0 segnale USA + rend. USA (pubblicato) | 0.81 | 3.96% | −7.9% | 5.0% |
+| L1 segnale USA + rend. UCITS (veicolo) | 0.89 | 4.22% | −7.0% | 4.8% |
+| L2 segnale UCITS + rend. UCITS (+orologio) | **0.84** | **4.08%** | −7.5% | 4.9% |
+
+**Totale L2−L0: dSharpe +0.03, dCAGR +0.12%/anno.** Il cambio di veicolo *non costa*.
+
+⚠️ `corr(L0,L2) = 0.65`, bassa per due serie sullo stesso indice — ed è l'**orologio**, non un
+difetto: le due chiusure condividono la notte e la mattina americana ma non il pomeriggio.
+Verificato che non sia uno sfasamento di date: la correlazione veicolo/gemello è **massima a lag 0
+su 6/6 coppie** (0.46-0.78). Conseguenza: le statistiche *giornaliere* delle due lenti non sono
+confrontabili una a una, mentre il **drift** sì — che è esattamente perché la sezione 2 usa il
+rapporto cumulato.
+
+---
+
+## 3. Il vincolo vero non è il broker: è il prezzo di UNA azione
+
+Senza frazionamento un ordine è almeno una azione. **Il prezzo unitario è una scelta
+dell'emittente, non una proprietà dell'indice**: CSPX costa $802 e VUAA $144 sullo *stesso* S&P 500.
+
+| gamba | STORIA | prezzo | DEPLOY | prezzo | a $3.000 | a $10.000 |
+|---|---|---|---|---|---|---|
+| SPY | CSPX | $801.86 | **VUAA** | $143.80 | 29% | 9% |
+| QQQ | EQQQ | $692.67 | **XNAS** | $65.74 | 13% | 4% |
+| IWM | XRSU | $437.80 | **R2US** | $86.35 | 17% | 5% |
+| TLT | IDTL | $3.09 | IDTL | $3.09 | 1% | 0% |
+| GLD | IGLN | $79.06 | IGLN | $79.06 | 16% | 5% |
+| HYG | IHYU | $94.12 | IHYU | $94.12 | 19% | 6% |
+
+*(% = quanto pesa una azione sull'allocazione di quella gamba)*
+
+Danno misurato dell'esecuzione a numero **intero** di azioni, stessa finestra per entrambi:
+
+| insieme | capitale | Sh fraz. | Sh intero | Δ | vol fraz. | vol intero | **gambe vive** | esposta |
+|---|---|---|---|---|---|---|---|---|
+| STORIA | $3.000 | 0.84 | 0.80 | −0.04 | 5.1% | **2.2%** | **4/6** | **33%** |
+| STORIA | $10.000 | 1.08 | 1.02 | −0.06 | 5.1% | 4.2% | 6/6 | 63% |
+| **DEPLOY** | **$3.000** | 0.88 | 0.84 | −0.04 | 5.1% | **4.5%** | **6/6** | **65%** |
+| DEPLOY | $10.000 | 1.10 | 1.09 | −0.02 | 5.1% | 4.9% | 6/6 | 66% |
+
+**Con i veicoli giusti il frazionamento non serve.** Con quelli sbagliati, a $3.000 lo sleeve perde
+due gambe su sei ed è a mercato un terzo del tempo: non è GTAA01 con un vincolo, è un'altra cosa.
+
+⚠️ **Si legge `gambe vive` e `vol`, non `Sharpe`.** Un vincolo che alza lo Sharpe non è un
+miglioramento: arrotondando in giù riduce l'esposizione e paga meno commissioni. È il **null
+de-levering** (4ª occorrenza dopo VRP-DD, TP01×DVOL, MAT01). Qui il controllo è stato eseguito e
+il verdetto è che con l'insieme DEPLOY il de-levering **non c'è**.
+
+⚠️ Scartati di proposito, benché con più storia: **RTWO** (Russell 2000 *quality* = fattore),
+**CSUSS** (MSCI USA Small Cap *ESG*), **IDP6** (S&P 600, indice diverso). Equivalenza dell'indice
+prima della storia.
+
+---
+
+## 4. Il costo del venue, per FORMA — la sola cosa su cui i broker differiscono davvero
+
+**Ordini/anno** (dipendono da banda e cadenza, non dal listino): **77 a $3.000, 102 a $10.000, 149 a
+$50.000**. Con questo numero ogni listino è calcolabile a mano.
+
+| costo fisso/ordine | $3.000 Sh | CAGR | $10.000 Sh | CAGR | $50.000 Sh | CAGR |
+|---|---|---|---|---|---|---|
+| $0.00 | 0.92 | 4.45% | 0.92 | 4.48% | 0.92 | 4.48% |
+| $0.35 (IB US) | 0.73 | 3.52% | 0.84 | 4.11% | 0.90 | 4.37% |
+| $1.00 | 0.39 | 1.80% | 0.71 | 3.42% | 0.86 | 4.17% |
+| $2.00 | −0.13 | −0.79% | 0.50 | 2.37% | 0.79 | 3.86% |
+| $5.00 | −1.51 | −8.17% | −0.12 | −0.71% | 0.61 | 2.93% |
+
+| costo proporzionale | $3.000 | $10.000 | $50.000 |
+|---|---|---|---|
+| 5 bps/ordine | 0.89 | 0.89 | 0.88 |
+| 25 bps/ordine | 0.77 | 0.76 | 0.75 |
+| 50 bps/ordine | 0.62 | 0.60 | 0.59 |
+
+**Le soglie da verificare presso il broker:**
+
+| capitale allocato | CAGR = 0 | Sharpe = 0.45 |
+|---|---|---|
+| $3.000 | $1.68/ordine | **$0.90/ordine** |
+| $10.000 | $4.34/ordine | **$2.23/ordine** |
+| $50.000 | $14.65/ordine | **$7.62/ordine** |
+
+Un listino **proporzionale** è quasi indifferente al capitale (0.75-0.89 di Sharpe a ogni taglia);
+uno **fisso** è una tassa regressiva. È la regola del 25/07 riconfermata su un venue diverso.
+
+---
+
+## 5. Risposta operativa alla domanda
+
+**Revolut o Degiro non sbloccano gli ETF USA**: il PRIIPs vale per ogni intermediario che serve
+retail UE. IB è anzi fra i più permissivi. Aprire un terzo conto per lo stesso rifiuto aggiunge
+rischio di venue senza guadagno.
+
+Ciò che si compra su *qualunque* dei tre sono gli **UCITS**, e a quel punto la scelta si gioca su
+**una sola dimensione misurabile**: il costo per ordine, contro le soglie della tabella sopra, con
+77-149 ordini l'anno.
+
+**Raccomandazione: restare su IB**, perché (a) il conto esiste già, (b) i dati per il segnale
+arrivano dallo stesso gateway, (c) è l'unico dei tre di cui la forma di costo è già modellata in
+`gtaa.py`. La verifica che resta da fare è **una sola**: la tariffa IB per ordine su LSEETF in USD,
+contro $2.23 (a $10.000) o $0.90 (a $3.000).
+
+**Nessuna azione oggi**: la decisione venue del 26/07 tiene tutto su Deribit fino a $20k, cioè
+~2028 col piano di versamenti corrente.
+
+---
+
+## Lezioni
+
+1. **Prima di dichiarare che un vincolo esterno distrugge un risultato, chiedersi cosa vincola
+   esattamente.** "Non posso comprare" ≠ "non posso vedere": tutta la validazione a 30 anni era
+   salva, e la nota che diceva il contrario era mia.
+2. **Un feed senza secondo parere non è certificato**, e la regola valeva già nel crypto. Il feed
+   equity ha vissuto 5 settimane con soli controlli locali, e il primo veicolo estero ha trovato
+   il buco alla prima estrazione.
+3. **Una soglia tarata su una classe di difetto non sorveglia le altre** — 2ª conferma dopo lo
+   split 2:1 del 25/07. E quando la taratura non regge il margine richiesto, la risposta non è
+   accettarla ma **cambiare statistica**: qui il passaggio da assoluta ad adimensionale
+   (deviazione / movimento del gemello) porta il margine da 2.2× a 5.3×.
+4. **La media delle differenze giornaliere non è la deviazione fra due veicoli sullo stesso
+   indice.** Errore standard 15× più grande della quantità stimata, più il drag di varianza. La
+   domanda "quanto mi costa il veicolo" è una domanda sul **drift**, quindi si misura sul rapporto
+   cumulato.
+5. **Il prezzo unitario di un ETF è un parametro di progetto, non un dato.** Sceglierlo cambia la
+   soglia di capitale di uno sleeve più di qualunque negoziazione con un broker.
+6. **Il grado d'accordo si conta, non si dichiara.** La prima stesura stampava "stesso segno su 6/6
+   gambe"; i dati dicevano 4/6. Scriverlo a mano nel `print` è il modo più facile di pubblicare una
+   conclusione che i propri dati smentiscono — 3ª occorrenza in questa sessione.
+
+---
+
+# Addendum 2026-07-27 — "io ho già Revolut e Degiro, IB sono solo iscritto"
+
+L'informazione ribalta la raccomandazione di ieri. L'argomento principale per IB era **"il conto
+esiste già"**, e non è vero: i conti reali sono Revolut e Degiro, IB è una registrazione.
+
+Cosa **non** cambia: il gateway IB serve per i **dati** del segnale (ADJUSTED_LAST sui 6 ETF USA),
+e per quello basta il paper — non serve eseguire lì. La scelta del broker di **esecuzione** è
+quindi libera, e si gioca su una sola dimensione misurabile: il **costo per ordine**.
+
+Script: `scripts/research/r0727_gtaa_broker.py`. Test: `tests/test_gtaa_broker.py` (9).
+**Book, pesi, cron, config: INVARIATI.**
+
+## Il numero di ordini è un parametro, non un dato
+
+I 77-149 ordini/anno del 26/07 sono la conseguenza di `REBAL_EVERY=5` e `REBAL_BAND_USD=50`,
+scelti il 25/07 sul plateau **per il listino IB su azioni USA e a una taglia sola**.
+
+| cadenza | banda | ord/anno | Sh @ $0 | Sh @ $1 | Sh @ $2 |
+|---|---|---|---|---|---|
+| settimanale | $25 | 102 | 1.28 | 1.08 | 0.87 |
+| settimanale | **$50** (canonico) | 84 | 1.27 | 1.10 | 0.94 |
+| settimanale | $400 | **23** | **1.27** | 1.22 | 1.18 |
+| mensile | $50 | 33 | **1.12** | 1.06 | 1.00 |
+| bimestrale | $400 | 10 | 1.10 | 1.08 | 1.06 |
+
+**Si legge `Sh @ $0` per prima**: è il prezzo della banda *in assenza di commissioni*. Allargare la
+banda a cadenza settimanale **non lo tocca** (1.27 → 1.27), rallentare la cadenza sì (1.27 → 1.12).
+
+Il meccanismo è interpretabile: `_exposure` è la media di 4 indicatori binari, quindi si muove a
+scatti di 0.25 ≈ $417 su una gamba da $1.667. **La banda filtra la deriva del vol-target, non il
+segnale di trend.**
+
+### Controllo su finestra lunga e veicoli diversi
+
+Sui **veicoli USA**, finestra comune ai 6 (10 anni, limitata dalla cache TLT dal 2016):
+
+| banda | ord/anno | Sh @ $0 | Sh @ $1 |
+|---|---|---|---|
+| $25 | 133 | 0.98 | 0.72 |
+| $400 | **35** | **0.96** | **0.89** |
+
+✅ Lo Sharpe a costo zero perde **0.02** mentre gli ordini calano del **74%**. Non è un artefatto
+della finestra corta.
+
+## ⚠️ Ma la banda in dollari assoluti è la parametrizzazione sbagliata
+
+| capitale | banda | % della gamba | ord/anno | **esposta** | Sharpe | |
+|---|---|---|---|---|---|---|
+| $3.000 | $400 | **80%** | **3** | **45%** | 0.71 | ❌ congelato |
+| $10.000 | $400 | 24% | 23 | 66% | 1.22 | OK |
+| $50.000 | $400 | 5% | 75 | 66% | 1.25 | OK |
+
+A $3.000 la banda da $400 è l'80% della gamba: **3 ordini l'anno**, a mercato il **45%** del tempo
+invece del 66%. Lo Sharpe resta 0.71 — accettabile — **su una strategia che ha smesso di seguire il
+proprio target**. È il null de-levering in una veste nuova: qui non travestito da "meno drawdown"
+ma da "meno costi".
+
+> **Regola: quando un parametro di esecuzione è espresso in valuta assoluta, il suo effetto dipende
+> dal capitale — e il controllo non è lo Sharpe ma la QUOTA DI TEMPO A MERCATO.**
+
+## La configurazione: banda = 25% della gamba
+
+| capitale | banda | ord/anno | esposta | soglia $/ordine | budget/anno |
+|---|---|---|---|---|---|
+| $3.000 | $125 | **21** | 66% | **$5.65** | $120 |
+| $6.000 | $250 | **21** | 66% | $11.34 | $240 |
+| $10.000 | $417 | **21** | 66% | $18.90 | $400 |
+| $25.000 | $1.042 | **21** | 66% | $47.26 | $1.000 |
+| $50.000 | $2.083 | **21** | 66% | >$60 | — |
+
+**21 ordini l'anno a ogni capitale**, esposizione 66% ovunque. Contro il canonico: a $3.000 la
+soglia passa da **$2.08 a $5.65 per ordine** — cioè dalla differenza fra *"serve un broker
+economico"* e *"va bene qualunque broker europeo"*.
+
+⚠️ **Non è un cambio di produzione.** È una configurazione **proposta**, tarata su questa finestra,
+non passata per `study_family_honest` né per un deflated-Sharpe. Regge il controllo su 10 anni e
+veicoli diversi, ma GTAA01 non è deployabile prima dei $20k (decisione venue 26/07): c'è tempo per
+validarla come si deve.
+
+## Cosa cercare sul proprio conto — per ISIN, non per ticker
+
+| gamba | ticker | ISIN | prezzo | descrizione |
+|---|---|---|---|---|
+| SPY | VUAA | `IE00BFMXXD54` | $143.80 | Vanguard S&P 500 UCITS (Acc, USD) |
+| QQQ | XNAS | `IE00BMFKG444` | $65.74 | Xtrackers Nasdaq 100 UCITS 1C |
+| IWM | R2US | `IE00BJ38QD84` | $86.35 | SPDR Russell 2000 US Small Cap UCITS |
+| TLT | IDTL | `IE00BSKRJZ44` | $3.09 | iShares $ Treasury Bond 20+yr UCITS |
+| GLD | IGLN | `IE00B4ND3602` | $79.06 | iShares Physical Gold ETC |
+| HYG | IHYU | `IE00B4PY7Y77` | $94.12 | iShares $ High Yield Corp Bond UCITS |
+
+*(ISIN da contract details IB: i ticker cambiano da borsa a borsa, le ISIN no. Tutti domiciliati in
+Irlanda — è il motivo per cui sono acquistabili nell'UE.)*
+
+Tutti quotati a **Londra in USD**. ⚠️ Le stesse ISIN esistono su altre borse e in altre valute: una
+linea in **EUR** aggiunge la conversione per ordine, che a 25bps costa **~0.15 di Sharpe** — più del
+costo per ordine di qualunque broker a questa cadenza. **La valuta della linea conta più del
+broker.**
+
+## Verdetto
+
+Con 21 ordini l'anno e una tolleranza di $5.65/ordine già a $3.000, **il vincolo di costo smette di
+essere binding su qualunque broker retail europeo**. La domanda "Revolut o Degiro" perde quindi la
+sua parte quantitativa e resta solo la parte di disponibilità: quale dei due quota le sei ISIN sopra
+sulla linea in USD.
+
+Restano due criteri non misurabili da qui, entrambi a favore di Degiro su Revolut per questo uso
+(universo ETF europeo tipicamente più ampio, e accesso diretto a LSE), **ma vanno verificati
+guardando i due conti** — non sono cose che posso misurare da questo lato.
+
+## Lezione
+
+**Una raccomandazione poggiata su un fatto non verificato sul conto reale vale quanto quel fatto.**
+Ieri ho consigliato IB in parte perché "il conto esiste già": era un'assunzione, e per la seconda
+volta in due giorni un'assunzione sul conto reale ha cambiato la conclusione. La prima volta era la
+negoziabilità (PRIIPs), questa volta quale conto è davvero operativo.
+
+---
+
+# Addendum 2026-07-27 (2) — "degiro ha api?"
+
+**Fatto:** DEGIRO **non** espone una API di trading ufficiale per il retail. Revolut nemmeno (la sua
+API è per pagamenti, non per il portafoglio titoli). IB sì, documentata e supportata — è quella che
+il progetto già usa per i dati.
+
+Esistono wrapper **non ufficiali** degli endpoint interni del web trader DEGIRO. Girano su
+credenziali + seed 2FA depositati sulla macchina, sono fuori dai termini di servizio, e si rompono
+**in silenzio** a ogni cambio di front-end. Questo progetto ha già pagato una volta il prezzo di un
+guasto silenzioso (`fresh_5m`, 26/07: fallimento muto → latenza d'uscita di SKH01 da ~1h a ~1 giorno
+senza che nulla lo segnalasse). **Un esecutore automatico che può rompersi senza dirlo è peggio
+dell'esecuzione manuale.**
+
+Quindi la domanda utile non è "si può automatizzare" ma **"quanto costa non farlo"**.
+
+## Carico operativo (banda 25%, controllo settimanale, $10.000)
+
+| | |
+|---|---|
+| controlli/anno | 50 |
+| **settimane con ≥1 ordine** | **15** (29% dei controlli) |
+| ordini per settimana attiva | 1.4 (max 5) |
+
+Nel 71% dei controlli non c'è nulla da fare.
+
+## Costo del ritardo di esecuzione
+
+Veicoli USA, 10 anni. ⚠️ Sulla finestra UCITS di 3.2 anni la curva **non risulta monotona** (5
+giorni −0.26, 10 giorni −0.13): il campione corto non risolve differenze di questa taglia, quindi
+il numero si legge sulla finestra lunga.
+
+| ritardo | Sharpe | ΔSharpe | stabilità |
+|---|---|---|---|
+| 0 giorni | 0.90 | — | — |
+| **1 giorno** | 0.89 | **−0.02** | peggiora in 6/11 anni = **moneta** |
+| 2 giorni | 0.83 | −0.07 | 7/11 |
+| 3 giorni | 0.78 | −0.13 | 7/11 |
+| 5 giorni | 0.73 | −0.18 | 7/11 |
+| **10 giorni** | 0.63 | **−0.27** | 6/11 |
+
+**Il costo non è il ritardo tipico, è la coda.** Eseguire il giorno stesso o il giorno dopo costa
+nulla; dieci giorni valgono quasi un terzo dello sleeve.
+
+## Conseguenza
+
+Il rischio dell'operatività manuale non è la lentezza, è la **dimenticanza** — e quella si compra
+con un **allarme**, non con una API. `gtaa_rebalance_plan(held, capital)` esiste già in produzione
+ed è nato esattamente per un esecutore; il progetto ha già l'allerta Telegram sul book live. Un cron
+settimanale che calcola il piano e notifica quando c'è da agire copre il caso 15 volte l'anno.
+
+⚠️ **L'altro lato, che resta vero:** il resto del book è automatico (TP01 e SKH01 mandano ordini
+veri su cron). Aggiungere una gamba manuale introduce un modo di fallire che il sistema oggi non ha.
+È un argomento reale a favore di IB — che l'API ce l'ha — ma richiede finanziare un secondo venue, e
+la decisione venue del 26/07 tiene tutto su Deribit fino a $20k. **La scelta è quindi rimandata al
+punto in cui la si riaprirebbe comunque.**
+
+## Lezione
+
+**Una capacità mancante si valuta sul costo di non averla, non sulla sua assenza.** Qui l'assenza di
+API sembra squalificante e vale −0.02 di Sharpe se si esegue entro un giorno; ciò che vale davvero
+(−0.27) è un rischio operativo che si copre con una notifica.
+
+---
+
+# Addendum 2026-07-27 (3) — "r2us in revolut non c'è, ma ho zprr e spy4"
+
+## ZPRR **è** R2US
+
+| ticker | borsa | valuta | ISIN |
+|---|---|---|---|
+| R2US | Londra | USD | `IE00BJ38QD84` |
+| **ZPRR** | **Xetra** | **EUR** | **`IE00BJ38QD84`** |
+
+Stessa ISIN = stessa classe di quote = **stesso fondo, stesso NAV**. Cambia solo dove e in che
+valuta si negozia. La gamba small cap è risolta: **compra ZPRR**, non si perde niente.
+
+> **Regola: si cerca per ISIN, non per ticker.** Lo stesso fondo ha ticker diversi su borse diverse,
+> e un ticker copiato da una lista può essere un altro prodotto.
+
+## ⚠️ SPY4 non è quello che sembra
+
+`IE00B4YBJ215` = SPDR **S&P 400 US Mid Cap**. Non è small cap, e non è l'S&P 500 (quello è SPY5,
+`IE00B6YX5C33`). Non serve, dato che ZPRR c'è — ma misurato come ripiego, su 6.5 anni:
+
+| gamba small cap | Sharpe | CAGR | maxDD |
+|---|---|---|---|
+| R2US (small) | 0.86 | 4.20% | −8.2% |
+| SPY4 (mid) | 0.86 | 4.26% | −8.3% |
+
+Correlazione dei due sleeve **0.991**, SPY4 peggiore in **3/7 anni** = moneta. *(Sulla finestra
+corta di 3.2 anni sembrava −0.15 di Sharpe: era rumore.)*
+
+**Ripiego accettabile**, e il motivo è meccanico: small e mid cap USA hanno correlazione giornaliera
+~0.95, e un TSMOM su due serie così vicine si accende quasi negli stessi giorni. ⚠️ Non è
+"validato" — 6.5 anni non bastano a distinguere due gambe così simili, ed è **esattamente per
+questo** che la scelta fra le due non conta.
+
+## ⚠️ Correzione a un'indicazione data ieri: sulla valuta avevo ragionato al contrario
+
+Ieri ho scritto che *"una linea in EUR aggiunge la conversione per ordine"*. È vero **solo per un
+conto in USD**. Per un conto in **euro** — cioè un retail italiano su Revolut o Degiro — vale
+l'opposto: comprare la linea in USD costringe a convertire a ogni ordine, la linea in EUR no.
+
+L'esposizione economica è identica nei due casi: il fondo detiene attivi in USD e **nessuna delle
+due linee è coperta**. La valuta di quotazione non copre niente — decide solo se serve una
+conversione.
+
+> **Regola giusta: prendere la linea nella valuta del proprio saldo.**
+
+Quanto vale, misurato (turnover lordo **$13.655/anno** su $10.000, 21 ordini):
+
+| bps FX per ordine | ΔSharpe | costo/anno |
+|---|---|---|
+| 15 bps | −0.04 | $20 |
+| 25 bps | −0.07 | $34 |
+| 50 bps | −0.14 | $68 |
+
+A 25bps la conversione equivale a ~**$1.6 in più su ciascuno dei 21 ordini**: reale, ma piccolo
+rispetto alla soglia di $18.90/ordine a $10.000. Quindi **ZPRR in EUR su un conto in euro è la
+scelta migliore**, non un compromesso.
+
+## Lezione
+
+**Un costo di conversione non è una proprietà dello strumento ma della coppia strumento-conto.**
+Avevo dedotto "linea in EUR = costo in più" da un caso (conto in USD) e l'avevo scritta come regola
+generale; per il conto che l'operatore usa davvero il segno è invertito. È la terza volta in due
+giorni che un'assunzione non verificata sul conto reale cambia la conclusione — dopo la
+negoziabilità PRIIPs e quale conto è operativo.
+
+---
+
+# Addendum 2026-07-27 (4) — DEGIRO ha tutte e sei
+
+Screenshot della watchlist "Pythagoras" su flatexDEGIRO: **le sei gambe ci sono tutte**, con i
+ticker esatti raccomandati. (Era Revolut a non avere R2US.)
+
+| gamba | ticker | borsa | valuta | prezzo Degiro |
+|---|---|---|---|---|
+| SPY | VUAA | TDG | **EUR** | € 126,795 |
+| QQQ | XNAS | TDG | **EUR** | € 58,10 |
+| IWM | R2US | LSE | USD | $ 86,66 |
+| TLT | IDTL | LSE | USD | $ 3,09987 |
+| GLD | IGLN | LSE | USD | $ 79,585 |
+| HYG | IHYU | LSE | USD | $ 94,32 |
+
+## Verifica indipendente che le linee in EUR siano gli stessi fondi
+
+Non dallo screenshot ma dai dati: il rapporto fra il prezzo IB (Londra USD) e il prezzo Degiro deve
+essere **un solo cambio** per entrambe le linee EUR.
+
+| ticker | Degiro | IB (LSE USD) | rapporto |
+|---|---|---|---|
+| VUAA | 126,795 | 143,80 | **1.1341** |
+| XNAS | 58,10 | 65,74 | **1.1315** |
+| R2US / IDTL / IGLN / IHYU | — | — | 0.993-0.998 (già USD) |
+
+EURUSD implicito **1.1341 vs 1.1315, scarto 0.23%**. Due fondi diversi non darebbero lo stesso
+cambio: sono le stesse quote, quotate in euro.
+
+## ⚠️ Un errore mio, dello stesso tipo che avevo appena codificato come regola
+
+Per cercare le linee in euro delle altre quattro gambe ho interrogato IB **per ticker** sulle borse
+tedesche: risultato "nessuna linea EUR" su 4/4. **Falso.** Il ticker cambia da borsa a borsa — R2US
+su Xetra si chiama ZPRR. Cercando **per ISIN**:
+
+| gamba | linea USD | **linea EUR** | ISIN |
+|---|---|---|---|
+| SPY | VUAA (LSE) | VUAA (Xetra/BIt) | `IE00BFMXXD54` |
+| QQQ | XNAS (LSE) | XNAS (Xetra) | `IE00BMFKG444` |
+| IWM | R2US (LSE) | **ZPRR** (Xetra) | `IE00BJ38QD84` |
+| TLT | IDTL (LSE) | **IS04** (Xetra) | `IE00BSKRJZ44` |
+| GLD | IGLN (LSE) | **EGLN** (Londra) | `IE00B4ND3602` |
+| HYG | IHYU (LSE) | **IS0R** (Xetra) | `IE00B4PY7Y77` |
+
+**Ogni gamba ha una linea in euro.** Avevo scritto la regola "si cerca per ISIN, non per ticker" un
+messaggio prima e poi ho costruito la sonda per ticker. *Un "assente" da una ricerca per ticker su
+una borsa dove quel ticker non esiste non significa "non esiste".*
+
+## Quanto vale la conversione, e su quale gamba
+
+Turnover per gamba a $10.000 (banda 25%, 21 ordini/anno):
+
+| gamba | ticker | ordini/anno | turnover/anno | quota |
+|---|---|---|---|---|
+| **TLT** | **IDTL** | **9** | **$6.257** | **46%** |
+| SPY | VUAA | 3 | $2.289 | 17% |
+| GLD | IGLN | 3 | $1.695 | 12% |
+| QQQ | XNAS | 3 | $1.614 | 12% |
+| HYG | IHYU | 1 | $958 | 7% |
+| IWM | R2US | 2 | $843 | 6% |
+
+- turnover su gambe in **USD** (da convertire): **$9.752/anno = 71%**
+- costo conversione: **$24/anno a 25bps**, $49 a 50bps (0.24-0.49% del capitale, ~6-12% del CAGR)
+
+**IDTL da sola vale il 46% del turnover e 9 dei 21 ordini.** Se si vuole ridurre la conversione
+senza cambiare sei strumenti, si sposta **quella** sulla linea in euro (IS04, `IE00BSKRJZ44`): da
+sola copre il **64%** del turnover convertibile.
+
+⚠️ Il risparmio non è netto: le linee di Xetra possono avere spread più larghi delle linee di Londra
+(che sono le primarie), e Degiro storicamente addebita una tariffa di connettività per borsa. Su
+$10.000 parliamo di decine di dollari l'anno in entrambe le direzioni — **non è una decisione
+importante**, e dirlo è più utile che costruire una precisione finta.
+
+## Cosa NON serve
+
+Il messaggio in cima allo screenshot — *"Richiedi un'aliquota ridotta della ritenuta alla fonte sugli
+investimenti statunitensi"* (il W-8BEN) — **non riguarda queste sei posizioni**: sono fondi
+irlandesi, non titoli USA. La ritenuta del 15% la subisce il fondo al proprio interno e nessun
+modulo dell'investitore la cambia. Va compilato se un giorno si detengono azioni USA dirette.
+
+## Stato
+
+Saldo Degiro €328,92: questa è **preparazione, non azione**. GTAA01 richiede ≥$3.000 per reggere i
+costi, e la decisione venue del 26/07 tiene tutto su Deribit fino a $20k.

docs/diary/2026-07-26-loo-deluck.md

@@ -0,0 +1,225 @@
+# 2026-07-26 — "Quale strategia terrei?" — leave-one-out del book DE-LUCKATO sulle ancore
+
+**Richiesta:** *"dimmi qual strategia pensi di tenere"*.
+
+**Script:** `scripts/research/r0726_loo_deluck.py` — **test:** `tests/test_loo_deluck.py` (9).
+**Book, pesi, cron, config: INVARIATI.** Nessuna decisione di allocazione cambia.
+Cambia invece un **numero documentato in CLAUDE.md** (§4) e cambiano **due giudizi che avevo
+dato un'ora prima nella stessa sessione** (§3).
+
+---
+
+## 0. Perche' la risposta ovvia non vale
+
+La domanda "quanto vale ogni sleeve al suo posto nel book" ha una misura ovvia: togli lo sleeve,
+guarda quanto cala il book. L'ho fatta, e alla prima lettura diceva questo:
+
+```
+BOOK COMPLETO        FULL +2.222   HOLD +2.364   maxDD 6.07%
+tolto                 dFULL    dHOLD      dDD
+TP01    (33%)        +0.280   -0.219   +0.24pp
+XS01    (15%)        +0.142   +0.640   +0.25pp
+VRP01   (12%)        +0.087   +0.064   +1.08pp
+SKH01   (20%)        +0.432   +0.652   +1.64pp
+GTAA01  (20%)        +0.120   +0.244   +1.70pp
+```
+
+Letta cosi', SKH01 e' il motore del book e TP01 e' un peso morto sull'hold-out.
+**Entrambe le letture sono sbagliate**, e il motivo era gia' scritto nel progetto il giorno prima:
+
+> *se si de-lucka una strategia va de-luckato anche il suo DEGRADO* — ogni Δ fra due varianti
+> misurato a un'ancora sola eredita la fortuna di quell'ancora.
+> (lezione 26/07, codificata in `altlib.anchor_luck_delta`)
+
+Un leave-one-out **e' esattamente un Δ fra due varianti**. E qui il problema e' al quadrato: 4
+sleeve su 5 sono ancorati, e per 3 di loro l'ancora canonica era gia' stata misurata come
+fortunata (TP01 92° pctl su 24 ancore, SKH01 93-98° su 23 offset, XS01 fase 0 al 15° pctl di DD).
+VRP01 e' l'unico senza firma — la sua fase canonica e' la **peggiore** delle 7.
+
+---
+
+## 1. Il metodo: estrazioni CONGIUNTE, non una griglia per sleeve
+
+Gli audit del 02/07 e del 03/07 hanno de-luckato **uno sleeve alla volta**, tenendo gli altri alla
+loro ancora canonica. Va bene per giudicare quello sleeve; non basta per giudicare il **book**,
+perche' i numeri del book sono calcolati con tutti e cinque alla canonica insieme.
+
+Spazio di luck congiunto: **24 (TP01, ancore orarie) x 10 (XS01, fasi H=10) x 7 (VRP01, fasi
+settimanali) x 23 (SKH01, offset di griglia 230m/690m) x 5 (GTAA01, fasi della cadenza
+settimanale) = 193.200 configurazioni.** Non enumerabile: si campiona.
+
+**2000 estrazioni uniformi e indipendenti** (seed 20260726). Uniformi-indipendenti e' il null
+onesto: non avevamo nessuna ragione a priori di preferire un'ancora a un'altra — se ce l'avessimo
+avuta, sarebbe stata parte della strategia.
+
+Per ogni estrazione: book completo + i 5 leave-one-out, **tutti alla stessa configurazione
+d'ancora**. La statistica e' la **mediana delle differenze appaiate**, mai la differenza delle
+mediane (l'errore che il 26/07 aveva ribaltato il verdetto sul recupero on-book di SKH01: le due
+mediane cadono su ancore diverse).
+
+**Repliche riusate, non riscritte.** I quattro generatori ancorati vengono dagli audit che li
+hanno gia' verificati bit-exact (`r0702_tp01_offset.daily_off`, `r0702_anchor_xs01.xs_phase`,
+`r0703_vrpimp_anchor.combo_weekly`, `r0702_anchor_skh01.skh_port`). Riscriverli avrebbe voluto
+dire rifare gli stessi errori di convenzione. L'unico pezzo nuovo e' la fase di GTAA01
+(`i % REBAL_EVERY == ph` invece di `== 0`), ed e' l'unico coperto da test dedicato.
+
+**Sanity obbligatorio prima di tutto** — ogni replica ancorata deve riprodurre lo sleeve di
+**produzione** alla sua ancora canonica, altrimenti sto misurando un'altra strategia:
+
+```
+TP01    ancora   0  max|dif| = 0.0e+00  (n=2692)  OK
+XS01    ancora   0  max|dif| = 0.0e+00  (n=938)   OK
+VRP01   ancora   0  max|dif| = 0.0e+00  (n=1884)  OK
+SKH01   ancora   0  max|dif| = 0.0e+00  (n=2690)  OK
+GTAA01  ancora   0  max|dif| = 0.0e+00  (n=2690)  OK
+```
+
+Costo totale: 69 serie, ~8s di precalcolo, 34s per le 2000 estrazioni.
+
+---
+
+## 2. Il livello del book: i numeri pubblicati stanno in cima alla banda
+
+```
+                 canonico    pctl    MEDIANA        p10      p90    fortuna
+Sharpe FULL       +2.222    97.0%    +1.946     +1.807   +2.116     +0.276
+Sharpe HOLD-OUT   +2.364    99.6%    +1.542     +1.109   +1.910     +0.822
+maxDD FULL         6.07%    12.0%     6.85%      5.99%    7.94%     -0.78%
+```
+
+**L'hold-out canonico sta al 99.6° percentile dello spazio d'ancora: solo 9 estrazioni su 2000
+fanno meglio.** La stima onesta e' **1.54**, con banda [1.11, 1.91].
+
+⚠️ **Un "100%" che ho dovuto correggere.** La prima stampa dava `pctl 100%` — arrotondamento di
+99.55% con un `%.0f`. In un artefatto di ricerca un 100% stampato significa "e' il massimo, punto"
+e avrebbe fatto concludere a una sessione futura qualcosa di piu' forte del vero. Verificato a
+mano (max fra le 2000 = +2.577, a `TP01=0 / XS01=7 / VRP01=1 / SKH01=0 / GTAA01=3`), formato
+portato a 1 decimale. *Regola pratica: un percentile stampato senza decimali mente esattamente
+agli estremi, che sono l'unico posto dove lo si legge.*
+
+---
+
+## 3. Il leave-one-out de-luckato — e due giudizi miei ribaltati
+
+```
+dSharpe FULL          canonico   pctl      MEDIANA    >0 in
+  TP01    33%          +0.280    5.8%      +0.390    100.0%
+  SKH01   20%          +0.432   99.0%      +0.142     90.8%
+  XS01    15%          +0.142   76.8%      +0.125     99.9%
+  VRP01   12%          +0.087    1.8%      +0.122    100.0%
+  GTAA01  20%          +0.120   63.5%      +0.115    100.0%
+
+dSharpe HOLD-OUT      canonico   pctl      MEDIANA    >0 in
+  XS01    15%          +0.640   63.4%      +0.497     96.2%
+  GTAA01  20%          +0.244   17.3%      +0.267    100.0%
+  SKH01   20%          +0.652   96.0%      +0.190     85.5%
+  VRP01   12%          +0.064   47.4%      +0.065     84.2%
+  TP01    33%          -0.219   39.5%      -0.200      0.9%
+
+dMaxDD (pp, >0 = protegge)       pctl      MEDIANA    >0 in
+  GTAA01  20%        +1.695pp   23.8%    +1.999pp    100.0%
+  VRP01   12%        +1.075pp   55.6%    +1.056pp     88.3%
+  SKH01   20%        +1.636pp   89.3%    +0.322pp     64.0%
+  TP01    33%        +0.236pp   48.4%    +0.274pp     62.1%
+  XS01    15%        +0.251pp   65.0%    +0.000pp     43.0%
+```
+
+**SKH01 non e' il motore del book.** Del suo contributo apparente, l'ancora canonica regala **2/3
+sul FULL** (+0.43 → +0.14), **70% sull'hold-out** (+0.65 → +0.19), **80% sulla protezione DD**
+(+1.64pp → +0.32pp). De-luckato e' indistinguibile dagli altri sul FULL ed e' **il meno affidabile
+dei cinque**: l'unico sotto il 91% di estrazioni positive su tutte e tre le metriche (91/86/64%).
+
+**GTAA01 non e' il primo da tagliare** (lo avevo detto un'ora prima, sulla lente canonica). E'
+**l'unico sleeve positivo nel 100% delle estrazioni su tutte e tre le metriche** e il miglior
+protettore di DD del book, al doppio del secondo. Non ha fortuna da restituire: il suo canonico
+sta *sotto* la mediana su FULL e DD. ⚠️ L'altra gamba di quel giudizio resta pero' intatta e
+indipendente: a $10k comprare ~€0.50/giorno sopra il risk-free con un maxDD del 10% e' caro, e
+sotto `GTAA_MIN_CAPITAL` = $3k lo sleeve non e' deployabile. **Attribuzione ≠ eseguibilita'.**
+
+**TP01 e' il maggior contributore, e il canonico lo SOTTOSTIMAVA** (+0.280 al 5.8° pctl → +0.390
+de-luckato, positivo in 2000/2000, quasi 3x il secondo). Il suo hold-out negativo **non e'
+artefatto d'ancora**: e' negativo nel **99.1%** delle configurazioni. Le due cose insieme sono la
+storia dell'assicurazione, finalmente misurata invece che asserita — sul campione pieno (che
+contiene il 2022) e' il contributore piu' grande; nella finestra 2025-26 e' stato fermo mentre gli
+altri guadagnavano, e questo costa −0.20. **Giudicarlo sulla finestra in cui non e' servito
+significa venderlo esattamente prima che serva.**
+
+**VRP01** conferma per la seconda volta di essere l'unico senza firma di fortuna: canonico al
+**1.8° pctl** sul FULL, cioe' i numeri di ammissione erano *conservativi*. Secondo protettore di DD.
+
+**XS01** tiene il primo posto sull'hold-out anche de-luckato (+0.497), ma la sua protezione di DD
+e' **esattamente zero** (mediana 0.000, positiva nel 43% = moneta). E' un diversificatore di
+**rendimento, non di rischio** — e conta, perche' sul canale funded il vincolo binding e' il DD,
+non il CAGR (25/07 §4).
+
+**Correlazioni:** stabili sotto de-luck, tutte quasi-nulle. La sola sopra 0.1 e' TP01-GTAA01
+(mediana +0.189, canonica +0.242).
+
+### Il contrappeso che SKH01 ha diritto ad avere
+
+Questo de-luck penalizza SKH01 sul path **backtest** (chiusura di bin). Ma le due misure del 26/07
+dicono che il **path live e' migliore del backtest su entrambi i lati**: ingressi +0.38 di Sharpe
+mediano, uscite +0.081 di Sharpe FULL di book. Applicare il de-luck senza quel contrappeso lo
+penalizzerebbe due volte. Verdetto onesto: **SKH01 vale meno dei suoi numeri di ammissione e piu'
+di questa tabella.** Quanto esattamente resta il follow-up gia' dichiarato e bloccato (serve la
+versione vol-targeted del path live di SKH01).
+
+---
+
+## 4. Correzione a CLAUDE.md
+
+La stima del 02/07 era **a occhio** — sommava le fortune misurate sleeve-per-sleeve. Oggi e'
+**misurata congiuntamente**, ed era ottimista su tutte e tre le metriche:
+
+| | stimato 02/07 | misurato 26/07 |
+|---|---|---|
+| HOLD-OUT | ~1.9-2.1 | **1.54** [1.11, 1.91] |
+| FULL | ~2.0-2.2 | **1.95** [1.81, 2.12] |
+| maxDD | "~6% invariato" | **6.85%** [5.99, 7.94] |
+
+L'errore non e' stato usare una stima: e' stato che una stima per somma di effetti marginali
+**non e' la mediana congiunta**, e la differenza (+0.82 di hold-out) e' piu' grande di quasi
+tutti gli uplift per cui in questo progetto si e' discusso se ammettere uno sleeve.
+
+---
+
+## 5. Cosa NON e' questa misura
+
+- **Non e' evidenza out-of-sample.** Il book e' valutato sugli stessi anni in cui XS01 e SKH01
+  sono stati scelti e affinati. E' attribuzione, de-luckata.
+- **Non e' un gate sui pesi.** Ogni proposta di cambio pesi passa da `weights_tilt_null`. Qui non
+  si propone nulla: i pesi restano 33/15/12/20/20.
+- **Non e' una lente di eseguibilita'.** Dice quanto uno sleeve contribuisce al book modellato,
+  non se lo si puo' comprare a $600 (GTAA01 sotto $3k e XS01 sotto ~$20k non si possono).
+
+---
+
+## 6. Risposta alla domanda
+
+**TP01**, se ne va tenuta una. Maggior contributore de-luckato (+0.390, 2000/2000), l'unico
+eseguibile davvero oggi a $600 senza haircut, e l'unico il cui valore dichiarato — il taglio del
+DD ~6x contro il buy&hold — **non e' ancorato** e regge a tutte le ancore testate. Tutto il resto
+dei suoi numeri e' gia' stato declassato (hold-out 0.31 → ~0.05); quello no.
+
+Le altre: **SKH01** si tiene al 25% e non un euro di piu'; **GTAA01** si tiene nel book modello
+(miglior protettore di DD) ma non nel live finche' non ci sono $3k su IB; **VRP01** si tiene come
+*metro* — e' l'unico i cui numeri sono onesti per costruzione; **XS01** non e' da tenere oggi, e'
+da accendere quando arriva il capitale (~$20k, o un conto funded, dove vale piu' di tutte).
+
+Il book live che gira — **TP01 75 / SKH01 25** — e' gia' questa risposta.
+
+---
+
+## 7. Regole trasferibili
+
+1. **Un leave-one-out e' un Δ, quindi va de-luckato come ogni Δ.** L'attribuzione all'ancora
+   canonica ha invertito la classifica su 2 metriche su 3.
+2. **De-luckare uno sleeve alla volta non de-lucka il book.** La fortuna del book e' un fenomeno
+   *congiunto*: la somma delle fortune marginali ha sbagliato di +0.82 di Sharpe hold-out. Quando
+   serve la banda di un aggregato, si campiona lo spazio congiunto.
+3. **Un percentile stampato a 0 decimali mente agli estremi**, che sono l'unico posto dove serve.
+4. **La frazione di estrazioni positive dice piu' della mediana.** Fra +0.142 (SKH01, positivo nel
+   91%) e +0.115 (GTAA01, positivo nel 100%) la mediana preferisce il primo e l'affidabilita' il
+   secondo — ed e' la seconda a decidere se ci si mette del capitale.
+5. **Uno sleeve difensivo si giudica sul sinistro, non sul premio.** L'hold-out negativo di TP01 e'
+   robusto (99.1% delle ancore) e *non* e' un argomento per ridurlo.

docs/diary/2026-07-26-reeval-strategia.md

@@ -0,0 +1,113 @@
+# 2026-07-26 — Rivalutazione della strategia dopo le correzioni del giorno
+
+**Richiesta:** *"in base a quanto definito rivalutiamo la strategia"*.
+
+**Script:** `r0726_reeval_live_weight.py`. **Test:** `tests/test_reeval_live_weight.py` (6).
+**Book, pesi, cron, config: INVARIATI.**
+
+---
+
+## 0. Cosa c'era da rivalutare davvero
+
+La giornata ha prodotto sei misure che toccano la strategia. Solo **una** apriva una decisione:
+
+| misura di oggi | cambia una decisione? |
+|---|---|
+| fattore de-luck ×0.6 → ×0.89 | no: cambia i *numeri* (muro −45%), non cosa si fa |
+| muro come punto fisso ($273.900) | no: la mia previsione era sbagliata, il piano resta |
+| LOO de-luckato (SKH01 il meno affidabile) | **forse**: e' un argomento per *ridurre* SKH01 |
+| path live SKH01 migliore su entrambi i lati | **forse**: argomento opposto, per *aumentarlo* |
+| curva fee (SKH01 4x piu' sensibile) | no oggi: regola gia' decisa per il 1 agosto |
+| rischio venue + tripwire | no: decisione dell'operatore gia' registrata |
+
+Le due righe "forse" puntano in **versi opposti** e nessuna delle due si puo' dedurre a tavolino.
+Il peso 75/25 fu confermato il **24/07** con la lente *hourly* — la stessa che il 26/07 e' risultata
+pessimistica su entrambi i lati di SKH01 (uscite **+0.081** Sharpe FULL di book, ingressi **+0.048**).
+Quindi la domanda e' legittima: **se SKH01 vale piu' di come e' stato pesato, 0.25 e' ancora giusto?**
+
+## 1. La misura
+
+Path live vero (`intra_entry=True`), 8 offset del sottocampione a priori, statistica = mediana
+delle differenze **appaiate** per offset.
+
+```
+ peso SKH  Sh FULL med    banda p10-p90   Sh HOLD med   d vs 0.25 (appaiata)
+     0.00        1.289   [1.289, 1.289]        0.296        -0.322 ( 12%)
+     0.15        1.523   [1.425, 1.714]        0.705        -0.091 ( 12%)
+     0.20        1.575   [1.450, 1.825]        0.825        -0.038 ( 12%)
+     0.25        1.611   [1.463, 1.915]        0.928        +0.000 (  0%)  <- LIVE
+     0.30        1.632   [1.465, 1.982]        1.012        +0.022 ( 88%)
+     0.35        1.639   [1.455, 2.028]        1.078        +0.030 ( 88%)
+     0.40        1.634   [1.435, 2.055]        1.127        +0.025 ( 88%)
+     0.50        1.595   [1.374, 2.064]        1.188        -0.013 ( 38%)
+```
+
+**Argmax a w=0.35**, e in **88% degli offset** 0.30-0.40 batte 0.25: il segnale c'e' ed e' nel verso
+previsto dalla correzione di lente. Ma:
+
+* **plateau entro 0.05 di Sharpe = [0.25, 0.30, 0.35, 0.40, 0.50]** — il peso live e' dentro, quindi
+  la differenza col massimo non e' distinguibile;
+* **`weights_tilt_null` FALLISCE** (`delta_insample −0.0026`, `gate_pass False`);
+* e soprattutto la lettura che la mediana da sola nasconde ⬇.
+
+## 2. Il motivo vero per non toccarlo: il guadagno e' tutto nella coda ALTA
+
+```
+peso      p10      mediana      p90
+0.25    1.463       1.611      1.915
+0.30    1.465       1.632      1.982
+0.35    1.455       1.639      2.028
+0.40    1.435       1.634      2.055
+0.50    1.374       1.595      2.064
+```
+
+Il **p10 e' piatto fino a 0.30 e poi SCENDE**, mentre il p90 sale monotono. Alzare il peso di SKH01
+non compra Sharpe: compra **dipendenza da quale ancora ti e' capitata**. La banda si allarga da
+0.45 (a w=0.25) a 0.69 (a w=0.50).
+
+E' coerente con il leave-one-out de-luckato dello stesso giorno — SKH01 e' lo sleeve con la
+frazione d'ancora piu' grande da restituire — e con la curva fee, dove SKH01 e' **4x** piu'
+sensibile di TP01. Tre misure indipendenti dicono la stessa cosa: **SKH01 e' la gamba fragile del
+book, e 0.25 sta all'estremo prudente della regione robusta.**
+
+**→ Nessun cambio. Il 75/25 e' confermato per la terza volta** (24/07 lente hourly, 26/07 path live
+intra-bin, e ora il gate sui pesi).
+
+## 3. La rivalutazione che conta non e' sulla strategia
+
+Messi in fila, gli ordini di grandezza di oggi:
+
+| leva | effetto misurato |
+|---|---|
+| ottimizzare il peso SKH01 (0.25 → 0.35) | **+0.030 Sharpe**, gate fallito |
+| versare €250/mese invece di €0 | da **mai** a **16.2 anni** (mediana), P(entro 20a) 92% |
+| perdere il conto Deribit (p=1%, 20 anni) | **−18%** di probabilita' di arrivare, e si riparte da zero |
+
+**L'esito del piano non e' piu' governato dalla strategia.** Il book e' dentro il suo plateau su
+ogni asse misurato; il margine residuo di ricerca vale centesimi di Sharpe, mentre i versamenti
+valgono la differenza fra "mai" e "16 anni" e il rischio di venue vale il 18% del risultato.
+
+Questo **non** dice che la ricerca sia finita — dice che la ricerca ha smesso di essere il vincolo
+binding. Il vincolo binding oggi e' **capitale che entra** e **conto che non sparisce**.
+
+## 4. Cio' che la rivalutazione NON cambia
+
+* **La strategia resta quella**: TP01 0.75 / SKH01 0.25 su Deribit, cron orario, cap 1.0x.
+* **I gate pre-registrati restano alle loro date** (1 ago fee, 27 set STATARB, 23 ott XSR01,
+  24 ott kill DVOLSPREAD, 24 gen 2027 decisione DVOLSPREAD). Rivalutare non vuol dire anticiparli:
+  anticipare un gate e' selezione sull'hold-out.
+* **La decisione venue resta $20k**, con il tripwire a coprire la parte di rischio che ha una
+  finestra.
+
+## 5. Regole trasferibili
+
+1. **Una rivalutazione onesta parte dall'elenco di cosa CAMBIA una decisione**, non dal riassunto
+   di cosa si e' scoperto. Sei misure, una sola apriva qualcosa.
+2. **Quando due correzioni puntano in versi opposti, si misura**: qui l'una (lente pessimistica)
+   spingeva ad alzare SKH01, l'altra (LOO de-luckato) ad abbassarlo, e a occhio si sarebbe potuto
+   argomentare qualunque cosa.
+3. **Un argmax dentro un plateau non e' una decisione.** E la mediana da sola nascondeva il fatto
+   decisivo: il guadagno stava tutto nel p90, il p10 peggiorava.
+4. **Quando le leve hanno ordini di grandezza diversi, dirlo.** +0.030 di Sharpe e "da mai a 16
+   anni" non sono la stessa categoria di scelta, e trattarle come tali e' il modo piu' comune di
+   lavorare molto senza cambiare niente.

docs/diary/2026-07-26-skh-live-book-deluck.md

@@ -0,0 +1,215 @@
+# 2026-07-26 — Follow-up SKH01 "vol-targeted": il blocco non esisteva. E il ×0.6 era troppo severo del 31-34%.
+
+**Richiesta:** *"fai il follow-up SKH01 vol-targeted"*.
+
+**Script:** `r0726_skh_sigcache.py` (cache), `r0726_skh_live_book.py` (misura),
+`r0726_deluck_factor.py` (decomposizione), `r0726_capwall_refresh.py` (muri ricalcolati).
+**Test:** `tests/test_skh_live_book.py` (8). **Book, pesi, cron, config: INVARIATI.**
+
+---
+
+## 0. Il follow-up era mal diagnosticato
+
+Portato avanti come bloccante per tre sessioni, con questa motivazione registrata in CLAUDE.md:
+
+> il book ricalcolato sul path live e' bloccato da una **incompatibilita' di lenti** — il
+> simulatore SKH01 compone per-trade a nozionale unitario, **lo sleeve e' vol-targeted**;
+> combinarle darebbe un numero preciso e falso.
+
+**Lo sleeve SKH01 non e' vol-targeted.** Tre verifiche indipendenti:
+
+1. `_skyhook_returns` chiama `backtest_signals(..., leverage=1.0, position_size=1.0)` — che nel
+   suo docstring dice *"ogni trade muove capital di position_size \* leverage \* ret_netto"*:
+   compounding per-trade a nozionale pieno, **la stessa lente del simulatore**;
+2. nel sorgente dello sleeve non compare `target_vol` / `vol_target` / `realized_vol`;
+3. `r0702_anchor_skh01.sim_equity(mode='canonical')` riproduce `backtest_signals` con
+   **max|diff| = 0.0**.
+
+Vol annualizzata realizzata per sleeve: SKH01 **20.7%**, TP01 12.2%, XS01 20.9%, GTAA01 5.4%.
+Il 20.7% e' probabilmente cio' che aveva suggerito "vol-target 20%" — ma e' un **prodotto** della
+strategia (uscite % asimmetriche + poco tempo a mercato), non un parametro. **SKH01 e' l'unica
+delle cinque a NON essere vol-targeted**, ed e' il contrario di quanto si credeva.
+
+**Lezione:** un blocco dichiarato va ri-verificato prima di costruirci sopra, non ereditato. Qui
+il costo e' stato tre sessioni di follow-up rimandato per un ostacolo inesistente, e la verifica
+che lo ha smontato e' durata due minuti.
+
+---
+
+## 1. La misura: ingressi live vs backtest, de-luckata
+
+Due path identici in tutto (livelli, uscite intra-barra, cap `max_per_day`, fee, non-overlap)
+tranne **quando si valuta l'ingresso**: LIVE = a ogni confine orario dentro il bin 230m (cio' che
+il cron fa), BACKTEST = solo a chiusura di bin.
+
+Riusa la macchina a stati fedele del 26/07 (`r0726_skh_partial_entry.simulate`). ⚠️ Trovato per
+strada: **`simulate` non e' mai chiamata da `main()` di quello script** — i numeri headline del suo
+diario vennero da una corsa ad hoc mai committata. Qui il driver e' committato.
+
+**Costo:** la ricostruzione del segnale a ogni osservazione oraria costa ~9 min per (asset,
+offset). Su 2 core con il cron live da non affamare, la griglia piena (23 offset) era fuori
+portata → **sottocampione uniforme dichiarato a priori: 8 offset**, uno ogni 90m su [0,690).
+E' un sottocampione per costo, non una selezione; la banda che ne esce ha 8 punti invece di 23.
+
+**Sanity superato prima di tutto** (campionato sugli EVENTI, non sulla popolazione — lezione del
+26/07): **120/120** bin con ingresso ricostruiti su entrambi gli asset.
+
+```
+  off    CANON     ShBT   ShLIVE   dSharpe   trade LIVE  trade BT  falsi
+    0   +1.446   +1.174   +1.204    +0.029          534       447     68
+   90   +1.043   +1.182   +1.194    +0.011          538       472     67
+  180   +1.467   +1.505   +1.698    +0.193          544       469     60
+  270   +1.231   +1.199   +1.205    +0.006          605       477    179
+  360   +0.761   +1.069   +1.397    +0.328          570       478    109
+  450   +0.921   +0.917   +2.025    +1.108          530       484     36
+  540   +0.751   +0.374   +0.445    +0.071          531       411    138
+  630   +0.871   +0.991   +1.144    +0.154          460       412     47
+
+SLEEVE (50/50)  mediana appaiata +0.112   positive 8/8    banda [+0.006, +1.108]
+PER-ASSET       mediana appaiata +0.097   positive 13/16  banda [-0.170, +1.086]
+```
+
+**Il numero del 26/07 era ~4x troppo grande.** Confrontando like-with-like — quel diario citava la
+mediana **per-asset** — si passa da **+0.38 su 3 offset** a **+0.097 su 8**, e da "6/6 non
+negativi" a **13/16**. Il segno regge, la taglia no: ennesimo Δ misurato su poche ancore che ne
+eredita la fortuna. L'outlier a offset 450 (+1.108) mostra perche' la statistica e' la mediana.
+
+⚠️ Le due righe della tabella **non sono la stessa grandezza** e vanno tenute separate: nel BOOK
+entra lo sleeve 50/50, dove la diversificazione BTC/ETH cambia il denominatore.
+
+### A livello di book
+
+```
+dSharpe FULL       mediana  +0.048   p10 -0.015   p90 +0.677   >0 in  79.3%
+dSharpe HOLD-OUT   mediana  +0.051   p10 -0.589   p90 +0.721   >0 in  51.2%
+d drift annuo      mediana  +0.731pp  p10 +0.044pp p90 +6.800pp >0 in 100.0%
+```
+
+Lo Sharpe e' quasi una monetina, **il drift e' positivo nel 100% delle estrazioni**. Meccanismo:
+l'ingresso intra-bin prende un prezzo migliore (piu' drift) ma i falsi ingressi aggiungono churn
+(530-605 trade live contro 411-484) → vol e ritorno salgono insieme e lo Sharpe non si muove.
+Per la domanda del ×0.6, che e' **sul drift**, il numero rilevante e' +0.73pp.
+
+---
+
+## 2. Un'ipotesi mia, nata e morta nella stessa sessione
+
+Guardando i primi **due** offset avevo notato che il canonico oscillava di 0.40 mentre i path del
+simulatore stavano fermi, e ne avevo tratto un'ipotesi: la *grid timing-luck* di SKH01 (audit
+02/07: 93-98° pctl, "spike non plateau", gate DD<30% che fallisce in 15/23 offset) sarebbe stata
+in buona parte un **artefatto della lente a chiusura-di-bin**, non una fragilita' della strategia
+live — che valuta ogni ora e non e' ancorata al confine del bin.
+
+**Refutata.** Dispersione dello Sharpe fra gli 8 offset:
+
+```
+path                              min   mediana      max    range      std
+CANONICO (chiusura bin)        +0.751    +0.982   +1.467    0.716    0.289
+BT-sim (chiusura bin)          +0.374    +1.122   +1.505    1.131    0.325
+LIVE-sim (intra-bin)           +0.445    +1.204   +2.025    1.580    0.459
+
+rapporto di dispersione LIVE/CANONICO: 1.59x
+```
+
+Il path live e' **piu'** disperso fra le fasi della griglia, non meno. **L'audit del 02/07 resta
+valido com'e':** la timing-luck di SKH01 e' della strategia, non della lente. L'ipotesi e' nata su
+2 offset, si e' incrinata a 4 (1.24x) e si e' chiusa a 8 (1.59x) — e la direzione dell'errore era
+sempre la stessa, il che e' il motivo per cui 2 punti non bastano mai.
+
+---
+
+## 3. Il ×0.6 decomposto, misurato, corretto
+
+Il fattore taglia il **drift** (`b - 0.4*mean(b)`) ed era applicato **sopra** la lente `hourly`,
+cioe' sopra un modello del live gia' pessimistico. Mescolava due cose separabili.
+
+**(a) Fortuna d'ancora sul drift** — misurata sullo spazio congiunto:
+
+| | canonico | pctl | MEDIANA | p10-p90 |
+|---|---|---|---|---|
+| book 5-sleeve, drift | 17.33% | 96.0° | **15.15%** | [13.88, 16.49] |
+| book 5-sleeve, CAGR | 18.56% | 96.0° | **16.00%** | [14.55, 17.56] |
+| book LIVE 75/25, drift | 19.27% | 93.8° | **17.16%** | [15.75, 18.67] |
+
+→ fattore d'ancora **×0.874** (5-sleeve) / **×0.890** (book live). La **vol e' invariata** fra le
+ancore (7.80% → 7.76%): la fortuna sta tutta nel drift, non nel rischio.
+
+**(b) Degradazione del path live** — non-negativa su tutto cio' che e' stato misurato:
+uscite SKH01 **+0.081** Sharpe di book (23/23 offset); ingressi SKH01 **+0.73pp** di drift
+(100% delle estrazioni); TP01 barra parziale trascurabile (24 ancore).
+
+**Il ×0.6 implicava un residuo ×0.687 attribuito al live oltre l'ancora.** Nessuna misura del
+progetto lo sostiene. Il sospetto gia' registrato in CLAUDE.md — *"il ×0.6 sopra il path live
+rischia di contare DUE VOLTE la degradazione SKH01"* — e' **confermato quantitativamente**.
+
+> **FATTORE ONESTO: ×0.87 – ×0.91** (5-sleeve) / **≥×0.89** (book live), contro il ×0.60 in uso.
+> **Troppo severo del 31-34%.**
+
+La componente uscite spingerebbe oltre, ma e' misurata in Sharpe e non in drift: non convertita,
+per non inventare precisione. Quindi il limite superiore e' esso stesso conservativo.
+
+---
+
+## 4. Cosa cambia nei muri di capitale (`r0726_capwall_refresh.py`)
+
+Stessa macchineria del 25/07 (`book_series`, `survival`, `_boot_paths` importati, non riscritti).
+
+```
+fattore                           leva   SWR-20a  PERPETUA        capitale
+×0.60  (25/07, a occhio)          1.00    7.36%     6.00%        $494,758
+×0.60  (25/07, a occhio)          1.50    8.16%     8.11%        $366,300
+×0.89  (26/07, ancora MISURATA)   1.00   10.94%    10.91%        $272,061
+×0.89  (26/07, ancora MISURATA)   1.50   13.72%    14.87%        $199,625
+×1.00  (nessun haircut)           1.00   12.48%    12.72%        $233,330
+```
+
+**Il muro per 50 EUR/g scende del ~45%: da ~$495k a ~$272k** (leva 1.0), e il valore vero sta fra
+la riga ×0.89 e la riga ×1.00 perche' ×0.89 e' un limite inferiore.
+
+**Cio' che NON cambia:** $272k restano **~453x** il conto di oggi. La conclusione strutturale del
+25/07 — *i 600 euro come CAPITALE sono refutati, come BIGLIETTO (prop) no* — regge intatta.
+Cambia la taglia dell'errore, e cambia che il numero e' misurato invece che scelto.
+
+Rendita sul conto attuale: EUR 0.12/g (×0.6) → **EUR 0.18/g** (×0.89). A questa taglia sono
+centesimi: **il fattore conta per il MURO e per le soglie prop, non per il conto di oggi.**
+
+### La traiettoria — il fattore agisce DUE volte
+
+Correggere il fattore alza il drift (si accumula prima) **e** abbassa il bersaglio (serve meno
+capitale). I due effetti pesano quasi uguale, quindi vanno separati invece che sommati alla cieca:
+
+```
+dep./mese   ×0.60 muro $495k    ×0.89 muro $495k    ×0.89 muro $272k
+            (25/07)             (solo drift)        (26/07)
+   €0       mai                 mai                 mai
+   €250     22.4a  (8% <20a)    19.6a  (53%)        16.2a  (91%)
+   €500     19.6a  (48%)        15.7a  (94%)        12.4a  (100%)
+   €1000    14.8a  (95%)        12.0a  (100%)        9.0a  (100%)
+   €2000    10.0a  (100%)        8.5a  (100%)        6.0a  (100%)
+```
+
+✅ **Validazione indipendente:** la colonna ×0.60 riproduce **esattamente** i numeri pubblicati il
+25/07 (€500/m → 19.6a, €1000/m → 14.8a). La replica e' fedele, quindi le altre due colonne sono
+confrontabili con quelle.
+
+A €500/mese: dei ~7 anni guadagnati, ~4 vengono dal drift e ~3 dal bersaglio piu' basso.
+
+⚠️ **Cio' che il fattore NON cambia:** senza depositi il capitale-rendita **non si raggiunge mai**
+(0% dei path a 20 anni, a ogni fattore). L'accumulo viene dai versamenti, non dal rendimento —
+correggere il ×0.6 accorcia i tempi, non crea una via che non c'era. E la mediana e' una mediana:
+meta' dei path arriva dopo, e una quota non arriva affatto.
+
+---
+
+## 5. Regole trasferibili
+
+1. **Un blocco dichiarato e' un'ipotesi, non un fatto.** Ri-verificarlo prima di costruirci sopra
+   o di rimandare: qui tre sessioni di attesa contro due minuti di verifica.
+2. **Un Δ su poche ancore eredita la loro fortuna, sempre** — terza occorrenza in due giorni
+   (recupero on-book, degrado d'esecuzione, e ora gli ingressi: +0.38 → +0.097).
+3. **Quando un fattore correttivo e' scelto a occhio, decomporlo prima di rifiutarlo o accettarlo.**
+   Il ×0.6 non era "sbagliato": era due fattori moltiplicati insieme, uno dei quali contato due volte.
+4. **Sharpe e drift rispondono a cose diverse.** L'effetto ingressi e' una monetina sullo Sharpe e
+   certo sul drift: chiedersi *quale* delle due grandezze entra nella decisione prima di misurare.
+5. **Due punti non fanno una tendenza** — nemmeno quando la meccanica sembra spiegarla. L'ipotesi
+   sulla dispersione era plausibile e sbagliata, e il costo di verificarla era basso.

docs/diary/2026-07-26-skh-partial-entry.md

@@ -0,0 +1,202 @@
+# 2026-07-26 — SKH01: gli INGRESSI su barra 230m PARZIALE. Misura dedicata.
+
+**Richiesta:** *"fai la misura sugli ingressi con barra parziale"*.
+**Follow-up dichiarato che chiude** (registrato in CLAUDE.md stamattina, misura T1):
+
+> la stessa barra parziale tocca anche gli INGRESSI — `ent[n-1]` puo' venire da un breakout non
+> confermato a fine barra → se evapora, il book apre e richiude. Su 112 bin campionati:
+> disaccordo parziale-vs-completa in 1 (~1%), ma con sole 3 entry nel campione la taglia non e'
+> stimabile … serve una misura dedicata prima di decidere il verso.
+
+**Script:** `scripts/research/r0726_skh_partial_entry.py` — **test:** `tests/test_skh_partial_entry.py` (8).
+**Book, pesi, cron: INVARIATI.** Nessuna decisione di allocazione cambia.
+
+---
+
+## 0. Il fatto meccanico da cui parte tutto
+
+`resample_5m(..., origin="epoch")` **non scarta il bin in corso**. Il cron gira a ore piene; una
+barra SKH01 dura 230 minuti. Quindi a ogni giro il live valuta il segnale su una barra 230m che, in
+media, e' **completa a meta'**. Il backtest invece valuta solo alle chiusure dei bin.
+
+Stamattina ho misurato il lato **uscite** di questo fatto (e ho scoperto che il live esce
+gia' intra-barra, quindi le uscite erano modellate troppo pessimisticamente). Restava il lato
+**ingressi**, che e' l'opposto: il live puo' entrare su un breakout che a fine barra **non c'e' piu'**.
+
+La domanda non e' "succede?" (succede per costruzione). E' **di che segno e' il saldo**.
+
+---
+
+## 1. Come si misura senza misurare la propria aritmetica
+
+Il rischio di questa misura non e' sbagliare un numero: e' costruire una ricostruzione rotta e non
+accorgersene. `signal_at(obs_ms, ...)` ricostruisce il segnale che il live *avrebbe visto* a un
+istante arbitrario: storia completa fino a li' + barra parziale, passata per i **veri**
+`htf_features` / `merge_htf_to_ltf` / `atr` su una finestra di 200 barre HTF.
+
+**Due errori catturati in sessione, entrambi del tipo che passa i test se i test sono pigri:**
+
+**(a) Self-check vacuo + bug di confine.** La prima versione stampava "BTC 80/80 OK". Era falso su
+due livelli insieme. `obs_ms // MS_LTF` a un'osservazione *alla chiusura* del bin cadeva nel bin
+**successivo**, ancora vuoto → aggregato vuoto → `signal_at` ritornava `None` → segnale 0. E il
+check campionava bin **a caso**: gli ingressi sono ~2% dei bin, quindi confrontava **zeri con zeri**
+e passava comunque. Le uniche 2 divergenze su ETH erano gli unici 2 bin con un segnale vero — cioe'
+il campione stava gia' dicendo che era rotto al 100%, non al 2.5%.
+
+Fix: `((obs_ms - 1) // MS_LTF) * MS_LTF`, e `selfcheck` riscritta per testare **esplicitamente i bin
+CON ingresso**. Esito corretto: **120/120 su BTC, 120/120 su ETH**. I "falsi allarmi" sui bin flat
+(17 BTC / 22 ETH su 400) sono bin dove il segnale c'e' ma il backtest lo sopprime col cap
+`max_per_day=1` — atteso, non un difetto.
+
+> **Regola:** un self-check su eventi rari va campionato **sugli eventi**, non sulla popolazione.
+> Un check che confronta zeri con zeri ha potenza zero e sembra un successo.
+
+**(b) Sovrastima ~20× dei falsi ingressi.** La prima scansione contava **1361** falsi ingressi
+(204% in piu' dei trade veri, costo stimato −3.03%/anno di sleeve). Numero **sbagliato**: `signal_at`
+riporta il compositore **grezzo**, mentre il live applica anche il cap `max_per_day=1` e il
+non-overlap. La spia era nella sezione D della stessa stampa — **305 giorni** con un falso ingresso a
+fronte di 663 "eventi": con cap 1/giorno non possono essere eventi indipendenti. Riscritta come
+**macchina a stati sequenziale** fedele al live: i falsi ingressi veri sono **~5/anno/asset**.
+
+> **Regola:** un conteggio di eventi su un segnale grezzo non e' un conteggio di **trade**. Prima di
+> monetizzare un evento, farlo passare per gli stessi filtri che ha il live.
+
+---
+
+## 2. Il risultato
+
+Due path identici in tutto (stessi livelli SKH01_V2_DD pct-asimmetrici, stesse uscite intra-barra,
+stesso cap, stesse fee 0.10% RT) tranne **quando si valuta l'ingresso**:
+
+- **LIVE** — segnale valutato a ogni confine orario interno al bin (= cio' che fa il cron oggi);
+- **BACKTEST** — segnale valutato solo alle chiusure dei bin (= cio' che il backtest assume).
+
+| asset | offset | path | equity× | trade | falsi | Sharpe |
+|---|---:|---|---:|---:|---:|---:|
+| BTC | 0 | LIVE | 6.58 | 249 | 29 | **1.07** |
+| BTC | 0 | BACKTEST | 6.28 | 211 | 0 | 1.08 |
+| ETH | 0 | LIVE | 6.09 | 285 | 39 | **0.95** |
+| ETH | 0 | BACKTEST | 5.44 | 236 | 0 | 0.91 |
+| BTC | 230 | LIVE | 27.10 | 254 | 20 | **1.63** |
+| BTC | 230 | BACKTEST | 8.32 | 226 | 0 | 1.19 |
+| ETH | 230 | LIVE | 11.47 | 283 | 34 | **1.20** |
+| ETH | 230 | BACKTEST | 5.08 | 241 | 0 | 0.88 |
+| BTC | 460 | LIVE | 17.53 | 258 | 18 | **1.44** |
+| BTC | 460 | BACKTEST | 4.29 | 236 | 0 | 0.85 |
+| ETH | 460 | LIVE | 72.87 | 281 | 17 | **1.93** |
+| ETH | 460 | BACKTEST | 6.12 | 253 | 0 | 0.95 |
+
+**ΔSharpe (live − backtest): −0.01, +0.04, +0.44, +0.32, +0.59, +0.98 → 6/6 non negativi,
+mediana +0.38.**
+
+⚠️ **I multipli d'equity NON sono ritorni dello sleeve.** Questo simulatore compone per-trade senza
+vol-target, senza pesi di book, a nozionale unitario. Servono solo a confrontare due path che
+differiscono per una cosa sola. La lente onesta qui e' lo **Sharpe** (che non compone), e i multipli
+sono la sua integrazione su 7 anni.
+
+**Split in-sample / hold-out (offset 0, dove ho le serie):**
+
+| asset | path | FULL | IS | HOLD |
+|---|---|---:|---:|---:|
+| BTC | LIVE | 1.07 | 1.07 | **1.12** |
+| BTC | BACKTEST | 1.08 | 1.15 | 0.71 |
+| ETH | LIVE | 0.95 | 0.93 | 1.03 |
+| ETH | BACKTEST | 0.91 | 0.88 | 1.03 |
+
+All'offset 0 il FULL e' un pareggio ma l'hold-out favorisce il live su BTC (**+0.41**) e pareggia su
+ETH. Coerente col fatto noto che **offset 0 e' l'ancora fortunata del backtest** (93-98° pctl sui 23
+offset a priori): e' esattamente l'ancora dove il path canonico ha meno da guadagnare.
+
+---
+
+## 2-bis. I due controlli che il risultato doveva superare
+
+Un +0.98 di Sharpe e un 72.87× di equity sono il tipo di numero che va attaccato prima di crederci.
+
+**(a) E' concentrato in pochi giorni?** No — e il controllo va nella direzione **opposta** al sospetto:
+
+| offset 460 | ret/trade | win rate | top-5 gg = % del log-equity | equity senza i top-5 |
+|---|---:|---:|---:|---:|
+| ETH LIVE | +1.878% | 48.6% | **16.7%** | 35.64× |
+| ETH BACKTEST | +0.946% | 40.6% | **39.5%** | 2.99× |
+| BTC LIVE | +1.307% | 46.1% | **22.5%** | 9.20× |
+| BTC BACKTEST | +0.801% | 44.0% | **38.3%** | 2.46× |
+
+Togliendo i 5 giorni migliori il divario si **allarga** (ETH 35.6× vs 3.0×). E' il **backtest** il
+path concentrato (~39% del log-equity in 5 giorni). La differenza vive nella **distribuzione**:
+ret/trade circa doppio e win rate +8pp (ETH) / +2pp (BTC).
+
+**(b) C'e' look-ahead intra-bin?** E' il rischio serio, perche' il self-check valida la ricostruzione
+solo **a chiusura di bin** — un leak che esistesse solo intra-bin gli sarebbe **invisibile per
+costruzione**. Test decisivo: ricalcolare ogni osservazione intra-bin con la serie 5m **troncata**
+alle sole barre gia' chiuse a `obs_ms`. Se il futuro contasse, la risposta cambierebbe.
+
+> **BTC 145/145 e ETH 144/144 osservazioni intra-bin: risposta identica dopo il troncamento**, e il
+> prezzo d'ingresso coincide sempre con l'ultimo close 5m gia' chiuso (241/241).
+
+Cablato come test permanente (`test_nessun_lookahead_intra_bin`).
+
+---
+
+## 3. Il meccanismo (perche' vince, e perche' non e' una sorpresa)
+
+Sezione B della scansione: quando il segnale c'e' **anche** a fine bin, il live entra in anticipo di
+**180 minuti mediani** a un prezzo **0.25-0.26% migliore** in media (0.11-0.12% mediano).
+
+SKH01 e' un **Donchian breakout**. Aspettare fino a 230 minuti la chiusura del bin significa, sui
+casi che confermano, **pagare il pezzo di movimento gia' avvenuto**. Il costo di quell'attesa e'
+sistematico; il beneficio (evitare i breakout che evaporano) e' reale ma raro — **~5 eventi/anno/asset**
+dopo i filtri del live, perche' il cap `max_per_day=1` e il non-overlap assorbono quasi tutto.
+
+E l'effetto si amplifica sui **livelli**, che sono percentuali sull'ingresso (long sl4%/tp10%, short
+sl2%/tp8%). Entrare 0.26% piu' avanti nella direzione del breakout sposta TP **e** SL dello stesso
+0.26% — ma il TP e' a 4-10% e lo SL a 2-4%: la stessa quantita' assoluta vale il **6-13% della
+distanza dallo SL** contro il 2.6-3.3% della distanza dal TP. Il vantaggio d'ingresso e' quindi
+**asimmetrico a favore della sopravvivenza del trade**: e' il canale che spiega il win rate piu' alto,
+non un giorno fortunato.
+
+**La cannibalizzazione del cap non morde:** ingressi veri bloccati da un falso ingresso = **2 su BTC
+(0.6%) e 3 su ETH (0.9%)**.
+
+---
+
+## 4. Verdetto
+
+**L'ingresso su barra parziale NON e' un difetto da correggere. Il verso del follow-up e': lasciarlo.**
+
+Ma la lettura che conta e' la seconda:
+
+> **Il live e il backtest stanno girando due strategie diverse, e la differenza non e' neutra.**
+
+Tutti i numeri di SKH01 nel progetto — Sharpe standalone, il peso 25% del book Deribit, l'audit
+d'ancora del 02/07, la conferma di peso/cadenza del 24/07 — sono calcolati sul path **a chiusura di
+bin**, che non e' quello che gira. La misura dice che il path reale e' **≥** in 6/6 coppie
+asset×offset. Insieme alla misura di stamattina sulle uscite (il live esce gia' intra-barra, +0.081
+Sharpe FULL di book sottostimato), **il path live di SKH01 e' stato modellato in modo
+sistematicamente pessimistico su entrambi i lati**.
+
+**Cosa NON concludo.** Che "l'ingresso intra-bin e' un miglioramento validato". Non ha passato
+nessuno dei gate del progetto: e' stato *misurato* sugli stessi 7 anni su cui SKH01 e' stato
+selezionato e affinato, non e' passato per `study_family_honest` ne' per un deflated-Sharpe, e la
+taglia varia molto fra ancore (da −0.01 a +0.98). Promuoverlo a meccanismo canonico sarebbe
+esattamente la selezione-sull'hold-out che il progetto ha gia' codificato come gate.
+
+E non serve promuoverlo: **e' gia' cio' che il live fa**. L'azione richiesta e' l'opposta — smettere
+di trattare il numero del backtest come l'aspettativa del live, e non "riparare" il live per farlo
+somigliare a un backtest peggiore.
+
+**Nessun cambio a book, pesi, cron, config.**
+
+---
+
+## 5. Regole nuove
+
+1. **Un self-check su eventi rari si campiona sugli EVENTI.** Confrontare zeri con zeri ha potenza
+   zero e passa. (Costo: un "80/80 OK" completamente falso.)
+2. **Un conteggio di eventi su segnale grezzo non e' un conteggio di trade.** I filtri del live
+   (cap giornaliero, non-overlap) vanno applicati prima di monetizzare qualsiasi evento. (Costo:
+   sovrastima 20× e un costo inventato di −3%/anno di sleeve.)
+3. **Quando live e backtest differiscono, misurare il DELTA con machinery identica** — un solo grado
+   di liberta' cambiato — e quotarlo sulla **banda d'ancora**, non su un'ancora sola. All'ancora
+   canonica questo effetto vale ~0; sulla banda vale +0.38 mediano. Su un'ancora sola avrei
+   concluso "irrilevante".

docs/diary/2026-07-26-t1-esecuzione-skh-live.md

@@ -0,0 +1,155 @@
+# 2026-07-26 — T1 nel live: il fix richiesto NON va fatto, e il perché è una correzione di modello
+
+**Richiesta:** implementare nel live il fix T1 (TP di SKH01 come limit resting on-book).
+**Esito: NON implementato**, con i numeri sotto. **Implementato invece** ciò che le misure
+sostengono: la sorveglianza della freschezza del feed 5m di SKH01, e la correzione dei docstring
+che hanno causato tre settimane di misure sbagliate.
+
+**File toccati (produzione):** `src/live/livefeed.py`, `src/live/book.py`, `src/portfolio/sleeves.py`
+(solo docstring), `scripts/live/book_execute.py`, `config/live.json`.
+**Test:** `tests/test_skh_feed_freshness.py` (11 casi) · suite **266 verdi**.
+**Strategia, pesi, cadenza del cron: INVARIATI.** Nessun ordine inviato.
+
+---
+
+## 1. Cosa ho trovato leggendo il codice di produzione
+
+Il fix T1 nasceva da una simulazione in cui SKH01 esce per conto suo. Il live non funziona così, e
+il vincolo era scritto nel codice:
+
+> `book.py`: *«gli exit sono SOFTWARE (no bracket on-book per SKH, sennò chiuderebbero anche la
+> quota TP01)»*
+
+TP01 e SKH01 tradano **lo stesso strumento** e Deribit tiene **una sola posizione netta**. Un
+ordine on-book al livello di TP di SKH chiuderebbe una fetta della posizione netta, che è per il
+75% di TP01. Ho quindi misurato i due ostacoli invece di assumerli:
+
+**(A) Compatibilità di segno — risolvibile.** Un ordine reduce-only può muovere la posizione solo
+verso lo zero. Se SKH è short mentre il netto è long (perché TP01 pesa di più), chiudere lo short
+significa *aumentare* il netto: non esprimibile. Frequenza sui trade che escono in TP — gli unici
+che il fix tocca: **97% compatibili** (SKH long 100%, SKH short 94%). Il 3% si sarebbe potuto
+saltare con fallback all'uscita software.
+
+**(B) Divergenza modello/live — sembrava bloccante.** Se il limit riempie a metà barra ma il
+modello non "vede" l'uscita, il cron successivo ricalcola il target includendo ancora la quota SKH
+e **ricompra ciò che il TP ha appena chiuso**. Misurato assumendo la rilevazione a fine barra 230m:
+ritardo mediano **115 min**, p90 **210**, e nel **70% dei TP almeno un cron gira nella finestra**
+(mediana 1.9 cron, p90 3.5).
+
+## 2. …e poi ho scoperto che il problema (B) non esiste
+
+Il problema (B) presuppone che il modello veda le uscite solo a barra 230m chiusa. È ciò che dicono
+i docstring:
+
+> `sleeves._skyhook_positions`: *«fino all'ultima barra 230m chiusa. Causale: usa solo barre chiuse»*
+> `book.py`: *«latenza fino alla chiusura della barra 230m corrente»*
+
+**Sono falsi.** `resample_5m` **non scarta il bin in corso** — aggrega le barre 5m che ci sono
+finora — e il ciclo di `_skyhook_positions` itera fino a `n-1`, quindi valuta gli hit di SL/TP
+anche sul bin **parziale**, col suo high/low corrente. Verificato sul feed reale: l'ultimo bin 230m
+conteneva **21 barre 5m su 46** (105 minuti su 230).
+
+Quindi il live rileva il tocco **entro il primo cron dopo il tocco (~1h)**, non a fine barra. E non
+è look-ahead: il livello è fissato all'ingresso da barre chiuse, e osservare che il prezzo l'ha già
+toccato è esattamente ciò che fa qualunque stop reale.
+
+### La conseguenza: il path live era modellato male da tre settimane
+
+La lente `hourly` — usata dall'audit del 02/07, dal follow-up del 24/07 e dal mio stesso T1 di
+stamattina — assume la rilevazione a fine barra. Il modello fedele è un altro (`fastdetect`:
+rilevazione intra-barra a 5m, uscita a mercato al primo cron successivo). Sulla banda appaiata dei
+23 offset, **relativo al path live come veniva modellato**:
+
+| modalità | ΔFULL mediana [min,max] | ΔHOLD mediana | offset migliorati (FULL) |
+|---|---|---|---|
+| **`fastdetect` = il live VERO** | **+0.081** [+0.00,+0.14] | +0.039 | **23/23** |
+| `canonical` (tetto teorico del backtest) | +0.054 [−0.05,+0.12] | +0.099 | — |
+| `onbook_tp` (**il fix richiesto**) | +0.054 [−0.03,+0.07] | +0.061 | 19/23 |
+| `onbook` (TP+SL on-book) | +0.024 [−0.07,+0.11] | +0.031 | 17/23 |
+
+Due letture, entrambe importanti:
+
+1. **Il "−0.35 di degrado del path live" è in gran parte un artefatto di modello**, sopra
+   l'artefatto di ancora già trovato stamattina. Sul FULL il live vero sta **sopra** il canonical.
+2. **Il fix richiesto sarebbe un declassamento**: +0.054 contro i +0.081 che il live già fa — e in
+   cambio si porterebbero in un percorso con soldi veri ordini parziali sul netto, un 3% di casi
+   non esprimibili, e la riconciliazione fra fill del broker e stato del modello.
+
+**Per questo non l'ho implementato.** Non è una difficoltà tecnica: è che la misura, fatta sulla
+lente giusta, dice che peggiorerebbe.
+
+---
+
+## 3. Il problema vero, trovato per strada
+
+`fresh_5m` è il pezzo che tiene bassa la latenza d'uscita. E **fallisce in silenzio**:
+
+```python
+try:
+    tail = _fetch_recent_5m(sym, lookback_days)
+except Exception:
+    return base          # ← nessun log, nessun errore, nessuna traccia
+```
+
+`_fetch_recent_5m` inghiotte a sua volta le eccezioni (`except Exception: break`). Se il fetch
+pubblico Deribit non risponde, il segnale SKH gira sul **feed certificato**, che il cron ricostruisce
+**una volta al giorno**. La latenza d'uscita passa da **~1 ora a ~1 giorno**, e niente lo segnala:
+il conto è online, la posizione è leggibile, il gate di staleness guarda il feed *di TP01* — nessuno
+dei controlli esistenti scatta. È lo stesso schema del feed-freeze del 2026-07-14, su un altro feed.
+
+E conta esattamente quanto il resto di questo lavoro: la latenza d'uscita **è** dove vive la qualità
+del path live.
+
+### Cosa ho cablato
+
+- **`livefeed.feed_age_minutes(df5)`** — pura, testabile senza rete: età in minuti dell'ultima barra
+  5m, misurata dalla sua **chiusura**, con `None` per input non interpretabili (`None` = "non
+  misurata", da trattare come sospetta: se tornasse `0.0` sembrerebbe fresca) e clamp a zero sugli
+  skew d'orologio.
+- **`book.book_report(live_feed=True)`** avvolge il loader per misurare la freschezza del feed
+  **effettivamente usato**, e la espone come `skh_feed_age_min` (massimo fra gli asset: se anche uno
+  solo è stantio, il netto è sospetto).
+- **`book_execute`** stampa lo stato e **allerta su Telegram** sopra `skh_feed_max_age_min` (30 min,
+  in `config/live.json`).
+
+**Scelta dichiarata: allerta, NON blocca.** Bloccare fermerebbe anche il ribilancio di TP01 — sono
+nettati sullo stesso strumento — per un guasto di rete; e forzare SKH a flat chiuderebbe posizioni
+buone su un glitch. Non ho evidenza su quale politica di blocco sia giusta, quindi la decisione
+resta all'operatore, informato.
+
+### Docstring corretti
+
+I due docstring falsi sono stati corretti *sul posto*, con la misura e il perché. Erano loro a
+sostenere la catena di ragionamenti sbagliata, ed erano la cosa più economica da riparare.
+
+---
+
+## 4. Follow-up dichiarato, non risolto
+
+La stessa barra parziale che migliora le **uscite** tocca anche gli **ingressi**: `ent[n-1]` può
+venire da un bin parziale, cioè da un breakout non ancora confermato a fine barra. Se il segnale
+evapora, il book apre e richiude — churn puro.
+
+Misurato su **112 bin campionati**: entry sulla barra completa in 3, sulla parziale in 2,
+**disaccordo in 1 (~1% dei bin)**. Ma con sole 3 entry nel campione la **taglia dell'effetto non è
+stimabile**: so che esiste, non so quanto pesa. Non l'ho toccato — a differenza delle uscite, qui
+il comportamento del live **diverge dal backtest in modo sostanziale** (entra su un segnale che il
+backtest non avrebbe visto), e sistemarlo è un cambio di strategia, non di strumentazione.
+Serve una misura dedicata prima di decidere in che verso.
+
+---
+
+## 5. Lezioni
+
+1. **Prima di implementare una raccomandazione, leggere il codice che dovrà ospitarla.** T1 era
+   corretto sul suo modello e inapplicabile sull'architettura reale — e leggendo quel codice è
+   saltato fuori che il modello stesso era sbagliato. La ricerca del mattino non lo poteva sapere:
+   simulava lo sleeve, non il book nettato.
+2. **Un docstring falso costa più di un bug**, perché nessun test lo cattura e tutti ci ragionano
+   sopra. Questi due hanno guidato tre analisi (02/07, 24/07, T1) verso una latenza che il codice
+   non aveva.
+3. **Un fallback silenzioso è un guasto silenzioso.** `fresh_5m` fa la cosa giusta (mai operare a
+   cieco) ma non dice di averla fatta: la scelta giusta è tenere il fallback **e** misurarlo.
+4. Terzo caso in due giorni in cui **il numero di partenza era peggio di com'era stato scritto**:
+   la fortuna d'ancora sul degrado (stamattina), la lente `hourly` (qui), il wick indipendente
+   (ieri). Ogni volta il difetto stava nella **lente**, non nella strategia.

docs/diary/2026-07-26-venue-risk.md

@@ -0,0 +1,187 @@
+# 2026-07-26 — "Tutto su Deribit?" — il rischio di venue, mai prezzato in 2 mesi di progetto
+
+**Richiesta:** *"tutto su deribit?"* (dopo il ricalcolo dei muri di capitale e della traiettoria).
+
+**Script:** `r0726_venue_risk.py` + aggiunte a `r0726_capwall_refresh.py` (drill-down €250/mese,
+`solve_deposit`). **Test:** `tests/test_venue_risk.py` (13). **Book, pesi, cron: INVARIATI.**
+
+---
+
+## 0. La domanda ha scoperto un buco, non un dettaglio
+
+Il progetto ha prezzato con ossessione: fee a 0.10% RT, slippage, min-order $5, pavimento fisso
+IB, haircut small-cap, fortuna d'ancora su 4 sleeve, degrado d'esecuzione su entrambi i lati di
+SKH01, look-ahead, backfill sintetico, split non aggiustati.
+
+**Non ha mai prezzato la probabilita' che l'exchange sparisca col saldo dentro.** Per un piano di
+rendita a 10-20 anni su un exchange offshore e' un rischio di prim'ordine, e — punto che rende il
+buco piu' grave — **non e' diversificabile con gli sleeve**: TP01, SKH01 e VRP01 stanno tutti
+sullo stesso conto Deribit. Tre sleeve quasi-ortogonali sui ritorni, **perfettamente correlati sul
+fallimento del venue**.
+
+## 0-bis. E un limite nei muri che avevo appena pubblicato
+
+`r0725_capcurve.book_series` gira a **`alloc=$600`** col book a **2 sleeve** (TP01+SKH01 75/25).
+Portare quella serie fino a $272.061 assume due cose mai dichiarate:
+  (a) che a $272k si giri ancora il book da $600 — falso: a ~$3k si accende GTAA01, a ~$5k XSR01,
+      a ~$20k XS01, e il book a 5 sleeve ha Sharpe piu' alto → **il muro vero e' piu' basso**;
+  (b) che tutto il capitale stia su **un solo exchange** per 10-20 anni — cioe' i muri
+      **assumevano gia' "tutto su Deribit"**, senza dirlo.
+
+---
+
+## 1. La misura
+
+Monte Carlo dell'accumulo (da $600, €250/mese, 20 anni, bersaglio $272.061, de-luck ×0.89) con
+**jump di venue**: ogni venue fallisce indipendentemente con probabilita' annua `p`, e in quel caso
+la sua quota di capitale va a **zero**; i depositi futuri si ripartiscono fra i superstiti.
+
+* **CONC** = tutto su Deribit (TP01+SKH01) — l'ipotesi implicita dei muri
+* **SPLIT** = Deribit 65% / Hyperliquid 15% (XS01) / IB 20% (GTAA01) — il book attivo mappato sui
+  venue dove gira davvero
+
+Bersaglio **identico** nei due casi, per confrontabilita': lo SPLIT ha in realta' Sharpe piu' alto
+e quindi muro piu' basso → **il confronto e' conservativo CONTRO lo split**.
+
+```
+p annua       P(arrivare a $272k in 20a)         P(perso TUTTO)
+              CONC        SPLIT      diff        CONC      SPLIT
+0.0%           95%         96%        +1%          0%         0%
+0.5%           87%         90%        +2%         10%         0%
+1.0%           81%         83%        +3%         18%         0%
+2.0%           69%         71%        +3%         34%         4%
+5.0%           42%         45%        +3%         64%        27%
+```
+
+Capitale mediano a 20 anni, CONC: $544k (p=0) → $475k (p=1%) → **$0 (p=5%)**.
+
+### La colonna che conta non e' la prima
+
+Sulla probabilita' di **arrivare** al bersaglio la concentrazione costa quasi nulla (1-3pp): se il
+venue regge, ci arrivi. Il danno e' tutto sulla **rovina**: a p=1%/anno la concentrazione porta
+**18% di probabilita' di perdere tutto** contro **0%**; a p=5% il capitale mediano e' azzerato.
+
+Il motivo e' strutturale: **con un solo conto "almeno un fallimento" coincide con "perso tutto"**.
+Nello split un fallimento costa una frazione.
+
+⚠️ Controintuitivo ma corretto: **lo SPLIT viene colpito PIU' spesso** (26% vs 10% a p=0.5%: ha
+tre venue che possono fallire) ed e' irrilevante. Conta quanto perdi, non quante volte sei toccato.
+Una metrica "P(almeno un incidente)" avrebbe classificato lo split come il piu' rischioso.
+
+---
+
+## 2. Tre onesta' obbligatorie
+
+1. **`p` NON e' stimato.** Il record degli exchange crypto dice che non e' trascurabile, ma
+   metterci una cifra precisa qui sarebbe inventarla. La tabella e' una **sensibilita'**: la scelta
+   di `p` resta dell'operatore e va dichiarata insieme al risultato.
+2. **I fallimenti sono assunti INDIPENDENTI**, e per la coppia Deribit-Hyperliquid e' ottimistico:
+   in una crisi sistemica crypto possono andare insieme. **La parte solida dello split e' IB**, che
+   e' un'altra classe di rischio (broker regolamentato), non un terzo exchange crypto.
+3. **Oggi lo split non e' una scelta.** GTAA01 richiede $3k (`GTAA_MIN_CAPITAL`), XS01 ~$20k. A
+   $600 la concentrazione e' **forzata**, non scelta.
+
+---
+
+## 3. Conclusione: la domanda ha una data, non una risposta secca
+
+**No, non tutto su Deribit — ma non da oggi.**
+
+| soglia | cosa si sblocca | effetto sul rischio di venue |
+|---|---|---|
+| oggi ($600) | niente | concentrazione **forzata** |
+| **~$3k** | GTAA01 su IB | **prima riduzione vera**: 20-25% fuori dal rischio-exchange, su un broker regolamentato |
+| ~$20k | XS01 su Hyperliquid | poco: e' ancora crypto, fallimenti plausibilmente correlati |
+
+### La convergenza che rafforza una decisione gia' presa
+
+Il 25/07 (`r0725_ib10k.py`) concludeva: **"al massimo 25% su IB, costa ~€0.08/g di rendita"** — su
+basi puramente di **rendimento**, e con tono di concessione ("costa"). Questa misura dice che quel
+25% compra una riduzione grande della probabilita' di **rovina**, che l'analisi di allora non
+prezzava affatto.
+
+**Stesso numero, ragione diversa, e molto piu' forte: €0.08/giorno non e' il prezzo di un
+peggioramento, e' il premio di un'assicurazione contro il modo piu' probabile di perdere tutto.**
+
+---
+
+## 4. Regole trasferibili
+
+1. **Un rischio non-diversificabile dagli sleeve va prezzato a parte.** Tre sleeve ortogonali sui
+   ritorni possono essere perfettamente correlati sul fallimento del venue: la matrice di
+   correlazione del book non lo vede, per costruzione.
+2. **P(successo) puo' nascondere P(rovina).** Qui la concentrazione costa 1-3pp sulla prima e fino
+   a 64pp sulla seconda. Per un piano di rendita la metrica e' la seconda.
+3. **"Quante volte vieni colpito" non e' una misura di rischio** — lo split viene colpito 2.5x piu'
+   spesso ed e' molto piu' sicuro.
+4. **Quando una raccomandazione e' presa su un asse solo, ricontrollarla sugli altri prima di
+   considerarla stabile.** Il "25% su IB" era una concessione sul rendimento; sull'asse della
+   rovina e' la mossa principale.
+
+---
+
+## 5. Addendum — la decisione dell'operatore (stessa sessione)
+
+**Domanda dell'operatore, in sequenza:** *"tutto su deribit?"* → *"quanto tengo su deribit
+allora?"* → *"la protezione e' solo di 25%, conviene usarli in Deribit"* → **"resto tutto su
+deribit fino a 20k"**.
+
+**DECISIONE: concentrazione 100% Deribit fino a $20k.** Presa dopo aver visto la tabella della
+rovina, non prima. Registrata qui perche' non venga ri-litigata alla soglia dei $3k.
+
+### Cosa e' stato verificato per rispondere (e che ha corretto un mio suggerimento)
+
+Avevo suggerito, genericamente, *"non lasciare su Deribit piu' di quanto serve a girare il book"*.
+Letto il codice di produzione, e' **inerte** su questa architettura:
+
+```python
+# src/live/book.py:81
+raw = weight * equity * (W_TP01 * max(tp_frac, 0.0) + W_SKH * skh_sign)   # weight = 0.5
+```
+
+`equity` e' il **saldo reale letto dal conto**. Il sizing e' proporzionale: prelevare $100 non
+mette al sicuro $100, **riduce il nozionale del book di $100**, 1:1. Non esiste capitale in
+eccesso da spazzare via. L'unico modo di tenere meno saldo a pari nozionale sarebbe scollegare la
+base di sizing dal conto e usare il margine — cioe' **scambiare rischio-venue con rischio di
+liquidazione**, che oggi il cap a 1.0x esclude strutturalmente (e che ha una guardia cablata,
+`test_leva_massima_da_config_resta_sotto_o_uguale_a_1x`). Cattivo affare: 10-18% ventennale contro
+qualche punto **annuo**, per proteggere $500.
+
+Correlato, da mettere agli atti: **"exchange FDIC" non esiste.** L'FDIC assicura depositi bancari
+in USD, non crypto e non derivati; la "FDIC pass-through" pubblicizzata da alcuni exchange copre
+solo il saldo USD in contanti. Le protezioni reali sono **SIPC** (IB, copre ETF/azioni — cioe'
+GTAA01 — non le crypto, che passano da Paxos) e la **segregazione CFTC** (CME, ma la taglia dei
+contratti la rende inaccessibile sotto le decine di migliaia).
+
+### L'argomento dell'operatore regge sull'asse su cui ottimizza
+
+Non e' una concessione: e' un fatto gia' nella tabella del §2. Sulla probabilita' di **arrivare**
+al capitale-rendita lo split vale **+1-3pp** (81% → 83% a p=1%) e costa ~€0.08/g. Se il criterio
+e' quello, la concentrazione e' quasi gratis.
+
+### L'argomento contro, che resta vero e va lasciato scritto
+
+**Zero e' assorbente.** In un piano di accumulo da 16 anni (€250/mese verso $272k), andare a zero
+all'anno 10 significa **non arrivarci piu'**: si riparte da €0 + versamenti. Restare col 25%
+significa aver perso ~4 anni. Il valore del non-andare-a-zero **non e' proporzionale alla frazione
+salvata** — ed e' l'unico argomento vero a favore dello split.
+
+### Termini registrati
+
+| | |
+|---|---|
+| **Accettato** | P(perso TUTTO) resta 10/18/34/64% a p=0.5/1/2/5% invece di 0/0/4/27% |
+| **In cambio di** | ~€0.08/g di rendita, commissione fissa IB, un secondo venue da gestire — per proteggere **$750** a $3k |
+| **Non si ri-discute** | la soglia $3k |
+| **Si riapre a** | **$20k** (dove lo split protegge ~$5k ed e' comunque richiesto dall'eseguibilita': XS01/HL, GTAA01/IB) |
+| **Si riapre PRIMA se** | cambia il piano (orizzonte, importo dei versamenti) oppure `p` diventa **stimabile** invece che assunto |
+
+⚠️ **Nota per il futuro-me:** decisione presa con l'informazione completa, non una svista da
+correggere. Se a $3k qualcuno ripropone lo split "come da CLAUDE.md", la risposta e' che la data
+e' $20k.
+
+### Regola trasferibile (5ª)
+
+5. **Quando una raccomandazione viene respinta con motivo, registrare COSA E' STATO ACCETTATO IN
+   CAMBIO.** Senza, la stessa analisi si ripresenta fra tre mesi come se fosse nuova — e l'operatore
+   deve ri-decidere una cosa gia' decisa, con meno contesto di adesso.

docs/diary/2026-07-26-venue-tripwire.md

@@ -0,0 +1,182 @@
+# 2026-07-26 — Un sistema di protezione dal fallimento exchange, a capitale concentrato
+
+**Richiesta:** *"trova un sistema di protezione da fallimento exchange"* — subito dopo la decisione
+di restare **100% su Deribit fino a $20k**.
+
+Il vincolo e' quello che rende il problema interessante: **la riduzione dell'esposizione e' fuori
+discussione**. Lo split di venue e' stato valutato e rifiutato con motivo (§5 del diario
+`2026-07-26-venue-risk.md`). Quindi non si puo' ridurre *quanto* si perde: si puo' solo ridurre
+**la probabilita' di essere ancora dentro quando succede**.
+
+**Script:** `r0726_venue_tripwire.py` (il segnale), `r0726_venue_response.py` (il costo di
+rispondere). **Produzione:** `src/live/venue_watch.py` + `scripts/live/venue_watch.py`, cablato in
+`cron_book.sh`. **Test:** `tests/test_venue_watch.py` (23). **Book, pesi, config: INVARIATI.**
+
+---
+
+## 0. L'idea in una riga
+
+Il modello di rischio del mattino assumeva il **salto a zero istantaneo**. I fallimenti reali non
+lo sono: Mt.Gox gato' i prelievi per mesi, FTX ebbe ~72 ore, e — misurato qui — **Bitfinex nel
+2018-19 resto' dislocato dal consenso per 2.324 ore consecutive**. Se dentro quella finestra il
+saldo esce, la perdita non e' totale. Il sistema e' quindi un **rilevatore di finestra**, non una
+riduzione di esposizione.
+
+## 1. Il segnale, e perche' e' falsificabile
+
+Quando un exchange gata i prelievi **l'arbitraggio si rompe**: non si puo' piu' comprare li' e
+vendere altrove per chiudere lo scarto, quindi il suo prezzo si stacca dal consenso e ci resta.
+Il segnale e' **|scarto|, non il segno** — su Mt.Gox il BTC andava a *premio* (si comprava BTC per
+far uscire valore), su un venue in fuga si vede lo *sconto*. Dicono la stessa cosa.
+
+Misurato su 8 anni di feed certificato, consenso = mediana di venue **USD indipendenti** (Coinbase,
+Bitstamp; mai USDT — il depeg 2022 sposta BTC/USDT fino al 3% e genererebbe falsi allarmi giganti):
+
+```
+asset       ore   mediana      p95      p99    p99.9       max   >50bps   >100bps
+BTC      65,043       3.1     11.4     18.0     34.4     712.9    0.06%    0.018%
+ETH      64,541       3.3     13.3     22.2     44.3     453.1    0.07%    0.017%
+```
+
+Deribit sta a **3 bps** dal consenso in mediana. E' un fondo di rumore bassissimo, ed e' cio' che
+rende possibile una soglia con margine.
+
+## 2. L'ipotesi meccanica era in parte SBAGLIATA
+
+Avevo scritto, prima di misurare, che il discriminante sarebbe stato la **costanza del segno**:
+un venue gated resta da un lato, un crash rimbalza fra i due. **Falso.** Gli episodi peggiori su
+Deribit sono tutti a segno costante anche loro:
+
+```
+BTC  2020-03-13 10:00   12h  picco  158 bps  segno -1      (crash COVID)
+ETH  2022-09-14 20:00   10h  picco   97 bps  segno -1      (Merge)
+ETH  2020-03-12 23:00    3h  picco  453 bps  segno -1
+BTC  2021-07-01 13:00    2h  picco  150 bps  segno +1
+```
+
+In un cascata di liquidazioni il perp sta **sotto** lo spot per ore di fila: e' un run a segno
+costante come quello di un venue gated. Il segno costante resta nel rilevatore (toglie il rumore
+simmetrico), ma **non e' lui a separare i due casi**: separano **ampiezza e durata**. Ipotesi
+corretta nella conclusione, sbagliata nel meccanismo.
+
+## 3. La taratura va DICHIARATA, perche' due criteri ovvi sbagliano in versi opposti
+
+Provati entrambi in sessione:
+
+| criterio ingenuo | esito | perche' e' sbagliato |
+|---|---|---|
+| **minimi bps** | 25 bps / 24h | consuma 24 delle ~72 ore che diede FTX |
+| **minime ore** | 500 bps / 2h | **manca FTX** (300 bps): margine 0.6x |
+
+Criterio adottato, in quest'ordine: **(1)** zero falsi allarmi su entrambi gli asset in 8 anni;
+**(2)** margine ≥3x sul caso storico **piu' debole** (FTX ~300 bps) → soglia ≤100 bps; **(3)** a
+quei vincoli, **minima latenza**.
+
+```
+   2h  ->   500 bps  (scartata: 0.6x < 3x su FTX)
+   3h  ->   150 bps  (scartata: 2.0x < 3x su FTX)
+   4h  ->   100 bps  <- SCELTA
+   6h  ->    75 bps
+  24h  ->    25 bps
+```
+
+**→ 100 bps persistenti 4 ore a segno costante.** Margine 3x su FTX, 5x su QuadrigaCX, 10-20x su
+Mt.Gox. Zero falsi allarmi in 8 anni, **crash COVID / maggio 2021 / LUNA / novembre 2022 inclusi**.
+
+## 4. Il controllo positivo — senza, "non scatta mai" non e' una buona notizia
+
+Un rilevatore tarato per non segnalare e' indistinguibile da uno rotto. Puntato su **Bitfinex
+2018-19** (problemi bancari/Tether, premio persistente), consenso Coinbase+Bitstamp con Bitfinex
+escluso dal proprio consenso:
+
+```
+BTC: 33.000 ore, scarto mediano 11 bps, max 1136 bps -> 22 EPISODI a 100bps/4h
+    2018-12-26   2324h  picco  447 bps  segno +1
+    2018-11-08   1151h  picco  663 bps  segno +1
+    2018-10-10    496h  picco 1136 bps  segno +1
+    2019-04-25    363h  picco  734 bps  segno +1
+```
+
+**22 scatti su un venue realmente in stress, zero su Deribit in 8 anni.** E la *durata* di quegli
+episodi risponde alla domanda che conta davvero: un venue gated resta dislocato per **settimane**,
+quindi 4 ore di latenza di rilevamento costano una frazione trascurabile del preavviso.
+
+## 5. Il lato risposta: quanto costa sbagliarsi
+
+Un allarme senza il costo della risposta non e' un sistema. Misurato sul book Deribit reale
+(TP01+SKH01 75/25) forzando flat una finestra a **ogni** data d'inizio possibile:
+
+```
+ giorni   costo medio   mediana   p5 (peggio)  p95 (meglio)  % dannosi
+      1       -0.149%   -0.100%       -1.093%        0.590%      76.4%
+      3       -0.248%   -0.100%       -2.065%        1.006%      67.9%
+      7       -0.442%   -0.100%       -4.072%        1.505%      62.4%
+     30       -1.537%   -0.455%       -9.236%        2.993%      57.3%
+```
+
+⚠️ **Errore mio, corretto:** avevo impostato il break-even sul **p5** (la coda). Per un valore
+atteso ripetuto nel tempo si usa la **media** — con la coda il numero esce 8.3x piu' severo e la
+conclusione si ribalta. Il p5 serve a sapere quanto puo' bruciare *una* volta, non a decidere.
+
+```
+Il tripwire conviene se p_annua > (falsi allarmi/anno) x 0.00248:
+     1 ogni 8 anni  ->  p >  0.031%     conviene per ogni p del ventaglio
+            1/anno  ->  p >  0.248%     conviene per ogni p del ventaglio
+            4/anno  ->  p >  0.991%     conviene da p=1%
+           12/anno  ->  p >  2.974%     conviene solo a p=5%
+           52/anno  ->  p > 12.889%     NON conviene mai
+```
+
+**Il valore del sistema sta tutto nella SPECIFICITA', non nella sensibilita'.** Un tripwire che
+strilla 12 volte l'anno sarebbe dannoso; questo, a zero falsi allarmi misurati su 8 anni, ha un
+break-even di **p > 0.031%** — un ordine di grandezza sotto l'ipotesi piu' ottimistica del
+venue-risk (0.5%).
+
+## 6. Cosa e' stato cablato
+
+`src/live/venue_watch.py` (nucleo puro, testabile) + `scripts/live/venue_watch.py` (runner), in
+`cron_book.sh` **prima** di `book_execute` — se Deribit e' in stress l'allarme deve partire anche
+quando l'esecuzione fallisce per la stessa ragione.
+
+**Tre stati, e il terzo non e' il primo:** `OK` (misurato, sotto soglia) / `ALERT` (misurato,
+sopra soglia e persistente → Telegram) / **`BLIND`** (non misurabile: referenze irraggiungibili o
+in disaccordo fra loro). *"Non vedo" non e' "va tutto bene"*: dopo 12 ore di cecita' scatta un
+allarme suo. Stessa lezione della contabilita' a 3 stati di `paper_dvolspread`.
+
+**Allerta, non blocca.** L'azione giusta a un vero positivo e' *prelevare*, che richiede comunque
+un intervento manuale — una chiave API con permesso di prelievo sarebbe essa stessa un rischio.
+E bloccare l'esecuzione non protegge il saldo: il saldo e' a rischio anche stando flat.
+
+**Runbook pre-deciso** (nel docstring del modulo, per non doverlo decidere nel momento sbagliato):
+1. escludere il guasto delle referenze (`n_refs`, `ref_spread_bps`);
+2. `public/status` (`platform_locked`) e canali ufficiali;
+3. **prelievo di prova piccolo** — l'unica evidenza DIRETTA; se non passa in tempi normali
+   l'allarme e' vero qualunque altra spiegazione esista;
+4. se non passa: flat + prelievo totale. Sbagliarsi costa **0.248%**, aver ragione salva il 100%.
+
+## 7. Cio' che questo sistema NON copre — e va detto
+
+Il tripwire prezza la finestra, non la sua esistenza. **Un fallimento senza finestra non lo prende
+nessuno**: furto di chiavi, sequestro, exit-scam notturno. Quella parte di `p` resta scoperta, e la
+sola difesa e' quella che l'operatore ha rifiutato fino a $20k — lo split. Il sistema **riduce** il
+rischio di venue, non lo elimina, e non e' un argomento per cambiare la decisione del 26/07.
+
+Secondo limite dichiarato: il preavviso storico di 200-2300 ore viene da **un** caso osservato
+(Bitfinex). E' un'ancora, non una distribuzione.
+
+## 8. Regole trasferibili
+
+1. **Un rilevatore tarato per non segnalare va validato su un controllo positivo**, o "non e' mai
+   scattato" e' indistinguibile da "e' rotto". Qui: 22 scatti su Bitfinex, zero su Deribit.
+2. **Una soglia si sceglie con un criterio dichiarato PRIMA**, perche' i criteri ovvi sbagliano in
+   versi opposti: "minimi bps" perde preavviso, "minime ore" perde il caso da prendere.
+3. **La persistenza richiesta e' latenza, e la latenza va sottratta al preavviso.** Va confrontata
+   con la durata del fenomeno da rilevare, non scelta in astratto.
+4. **Un break-even si calcola sulla media, non sulla coda.** La coda dice quanto fa male una volta;
+   la media dice se conviene ripeterlo.
+5. **Un outer-join con una referenza corta e' una trappola** (2ª volta oggi, dopo GTAA01): la
+   prima corsa tronco' il campione da 8 anni a 29 giorni *in silenzio*, e la diagnostica di
+   copertura era gia' stampata. **Una diagnostica stampata non e' un controllo** — ora c'e' una
+   guardia che ferma lo script.
+6. **Un controllo positivo dentro il ramo `else` non gira mai.** Trovato in sessione: era finito
+   nel ramo di fallimento, cioe' esattamente il difetto che doveva prevenire.

docs/diary/2026-07-26-versamenti.md

@@ -0,0 +1,421 @@
+# 2026-07-26 — I versamenti: le quattro ipotesi che il piano non aveva mai fatto
+
+**Richiesta:** *"allora concentriamoci sui versamenti"* — dopo la rivalutazione che ha misurato il
+book dentro il suo plateau (ottimizzare il peso = +0.030 Sharpe, gate fallito) mentre i versamenti
+valgono la differenza fra **mai** e **16 anni**.
+
+**Script:** `r0726_deposits.py`. **Test:** `tests/test_deposits.py` (12).
+**Book, pesi, cron, config: INVARIATI.** (Questo filone non tocca il codice di produzione.)
+
+---
+
+## 0. Cosa mancava
+
+Tutte le traiettorie calcolate finora (25/07 e 26/07) assumono la stessa cosa: **versamento
+piatto, ininterrotto, per sempre**. E' l'ipotesi meno realistica dell'intero piano. Qui si misurano
+le deviazioni che succedono davvero, con la stessa macchineria (block bootstrap sui ritorni reali
+del book live, fattore d'ancora ×0.89 **misurato**).
+
+## 1. Smettere di versare — il costo non e' proporzionale ai soldi mancanti
+
+€250/mese per K anni, poi stop, orizzonte 20 anni:
+
+```
+ versi per  totale versato   cap. mediano a 20a  P(muro entro 20a)  rendita mediana
+       3a          $10,410             $202,771             32.7%       37.27 €/g
+       5a          $16,950             $287,081             53.3%       52.76 €/g
+      10a          $33,572             $410,220             77.9%       75.39 €/g
+      20a          $66,818             $496,778             90.0%       91.30 €/g
+```
+
+**I primi 5 anni sono il 25% dei soldi e il 58% del risultato.** Chi versa 5 anni e poi smette
+arriva comunque alla rendita bersaglio nel 53% dei casi; chi versa gli ultimi 10 anni (piu' soldi)
+arriva nell'11% (§3). **La variabile non e' quanto versi: e' quanto presto.**
+
+Corollario pratico: un'interruzione al 12° anno costa poco; una al 3° costa quasi tutto. Se il
+piano deve rompersi, e' meglio che si rompa tardi — il che e' un argomento per **partire con un
+importo sostenibile** invece che con uno ambizioso.
+
+## 2. Un piano crescente e' peggiore di uno piatto, a pari soldi
+
+```
+piano             totale versato   cap. mediano   P(muro)   $ finale / $ versato
+piatto €250              $66,818       $496,778     90.0%                  7.43x
+€150 +5%/anno            $67,998       $401,889     80.8%                  5.91x
+```
+
+**Stessi soldi (€67-68k), 24% di risultato in meno.** Il piano crescente versa gli stessi euro
+piu' **tardi**, e quegli euro compongono meno. L'ultima colonna e' la metrica giusta per
+confrontare piani di taglia diversa: quanto capitale finale compra ogni dollaro versato — e i
+piani crescenti stanno tutti a 5.1-5.9x contro 7.4x dei piatti.
+
+E' contro-intuitivo perche' "i versamenti crescono col reddito" suona prudente. Lo e' dal punto di
+vista del bilancio familiare; **non** lo e' dal punto di vista del capitale.
+
+## 3. Stesso totale, calendario diverso — il tempo vale 2.2x
+
+€60.000 in totale (= €250/mese per 20 anni), distribuiti diversamente:
+
+```
+calendario                   cap. mediano   P(muro)   vs piatto
+piatto su 20 anni                $496,778     90.0%       1.00x
+tutto nei primi 10 anni          $806,285     98.3%       1.62x
+tutto nei primi 5 anni         $1,104,587     99.4%       2.22x
+solo negli ultimi 10 anni        $178,494     11.0%       0.36x
+```
+
+**Gli stessi €60.000 valgono da $178k a $1.104k — un fattore 6 — a seconda di QUANDO entrano.**
+
+⚠️ Questo **non** dice "versa tutto subito": dice quanto vale il tempo. Un piano che non si
+sostiene non e' un piano, e il confronto serve a scegliere fra calendari **sostenibili**.
+
+### E regge al rischio di venue?
+
+Il vantaggio del front-loading e' calcolato mettendo **piu' capitale sull'exchange prima** — cioe'
+proprio il rischio misurato stamattina. Andava verificato, non assunto:
+
+```
+calendario                     p=0.5%          p=2.0%          p=5.0%
+piatto su 20 anni            $463,413        $359,251              $0
+tutto nei primi 10 anni      $765,178        $555,904              $0
+tutto nei primi 5 anni     $1,015,491        $752,367              $0
+solo negli ultimi 10 anni    $172,228        $147,203              $0
+```
+
+Il vantaggio **regge** (2.22x → 2.09x a p=2%): il rischio di venue colpisce il **tempo**, non il
+calendario dei versamenti. Anticipare non aumenta la probabilita' di essere colpiti, aumenta solo
+quanto c'e' dentro quando succede — e nel frattempo ha composto di piu'.
+
+⚠️ **Ma guardare la colonna p=5%: il capitale mediano e' $0 per OGNI calendario.** A quel tasso di
+rischio la meta' dei percorsi finisce a zero (64% di rovina su 20 anni, come misurato stamattina) e
+**come versi diventa irrilevante**. E' la formulazione piu' netta del rischio di venue trovata
+finora: non erode il piano, lo **cancella**.
+
+## 4. La domanda inversa — che rendita compra quello che posso permettermi
+
+Rendita **netta** mediana in €/giorno:
+
+```
+  €/mese         5a        10a        15a        20a   P(€50/g a 20a)
+     100      2.08€     6.54€    16.40€    38.07€            31.0%
+     150      3.00€     9.55€    23.96€    55.80€            58.7%
+     250      4.83€    15.53€    39.11€    91.30€            90.0%
+     400      7.59€    24.52€    61.85€   144.23€            98.9%
+     600     11.26€    36.52€    92.17€   215.07€           100.0%
+```
+
+E' la tabella che **riformula l'obiettivo**. €50/g e' un punto su questa griglia, non l'unico
+risultato che conta: €150/mese porta a ~€24/g in 15 anni, che non e' un fallimento del piano da
+€50 — e' un risultato diverso, e ora si sa quanto costa il salto.
+
+Da notare la **non-linearita' temporale**: da 15 a 20 anni la rendita piu' che raddoppia a ogni
+livello. Gli ultimi anni del piano contano piu' dei primi *in rendita*, esattamente come i primi
+contano piu' degli ultimi *in versamenti*.
+
+## 5. Ogni quanto versare — la decisione meno importante
+
+```
+ costo/tras.       mensile     bimestrale    trimestrale     semestrale
+       $0.00     *$490,149       $486,725       $482,587       $473,908
+       $2.00     *$486,597       $484,964       $481,446       $473,342
+       $5.00      $481,270      *$482,323       $479,727       $472,495
+      $25.00      $445,984       $464,692      *$468,226       $466,817
+```
+
+**Mensile fino a ~$2 di costo per trasferimento, bimestrale sopra.** Ma le differenze sono
+**1-3%** del capitale finale: e' la meno importante delle cinque decisioni di questo diario, e non
+merita ottimizzazione oltre la regola in una riga.
+
+Verificato che un deposito **non resta strozzato**: col cap dinamico attivo (`_cap`), cap =
+equity/2 = esattamente il nozionale massimo che il book puo' chiedere per asset.
+
+## 6. Le cinque decisioni, in ordine di quanto pesano
+
+| decisione | effetto misurato |
+|---|---|
+| **versare o no** | da **mai** a 16 anni |
+| **quando** (front vs back, stesso totale) | **6x** sul capitale finale |
+| **quanto presto smettere** | 5 anni = 25% dei soldi, 58% del risultato |
+| piatto vs crescente | 24% a pari soldi |
+| frequenza | 1-3% |
+
+E sopra tutte, fuori scala: **a p=5% di rischio venue il risultato mediano e' zero comunque.**
+
+## 7. Regole trasferibili
+
+1. **Un piano di accumulo si giudica sulle sue deviazioni, non sul caso nominale.** Piatto,
+   ininterrotto e per sempre e' l'unico scenario che non succede.
+2. **Confrontare piani di taglia diversa richiede una metrica normalizzata** (`$ finale / $
+   versato`), altrimenti "versa di piu'" vince sempre e non si impara niente.
+3. **Un vantaggio calcolato ignorando un rischio noto va ri-misurato con quel rischio dentro**,
+   anche quando ci si aspetta che regga — qui reggeva, ma la colonna p=5% ha prodotto il risultato
+   piu' importante del filone.
+4. **Quando l'obiettivo dichiarato non e' raggiungibile, la tabella utile e' quella inversa**:
+   non "quando arrivo a X" ma "cosa compro con quello che ho".
+
+---
+
+# Addendum — il piano dichiarato: €5.000 subito + €500/mese
+
+L'operatore ha dato i numeri veri. Cambiano la scala: €5.000 portano il conto da **$597 a $6.047
+(10.1x)** e €500/mese e' il doppio del livello tabulato sopra. Ricalcolato in dedicata
+(`r0726_piano_5k500.py`), non estrapolato.
+
+## Quando
+
+```
+traguardo ($272.061):   p10 9.4a    MEDIANA 11.6a    p90 14.4a
+P(entro 10a) 18%   P(entro 12a) 57%   P(entro 15a) 94%   P(entro 20a) 100%
+```
+
+```
+ anno    capitale p10       MEDIANO           p90    rendita mediana
+    1$        12,408$        14,057$       16,405           2.58 €/g
+    3$        28,401$        34,674$       44,000           6.37 €/g
+    5$        48,306$        62,952$       86,121          11.57 €/g
+   10$       130,089$       191,398$      299,555          35.18 €/g
+   15$       288,993$       476,825$      847,266          87.63 €/g
+```
+
+✅ **Validazione incrociata:** la variante "solo €500/mese da $600" da' **12.4 anni**, che e'
+*esattamente* il numero pubblicato il 25/07 con macchineria diversa. Replica indipendente.
+
+## Quanto vale il versamento iniziale: 0.8 anni
+
+```
+€5.000 subito (il piano)          11.6a
+€5.000 spalmati sul 1° anno       11.7a
+€5.000 al 5° anno                 12.1a
+niente lump, solo €500/mese       12.4a
+```
+
+⚠️ **Meno di quanto suggerisse il "fattore 6" del §3**, e la ragione e' aritmetica: €5.000 sono
+**~10 mesi** di versamenti a €500, quindi comprano ~10 mesi. Il fattore 6 riguardava lo spostamento
+di €60.000 su vent'anni. **Anticipare vale in proporzione a quanto si anticipa** — ovvio a
+posteriori, ma la mia aspettativa era piu' alta e va corretta.
+
+## Le soglie, e la data che compare
+
+```
+$  3,000   GIA' SUPERATA il giorno 1   GTAA01 eseguibile
+$  5,000   GIA' SUPERATA il giorno 1   XSR01 eseguibile (gate pre-registrato 23/10)
+$ 13,000            ~0.9 anni          GTAA01 entra nel book deployable
+$ 20,000            ~1.6 anni          SOGLIA DELLA DECISIONE VENUE
+$117,000            ~7.6 anni          XS01 eseguibile
+```
+
+**La decisione "niente split fino a $20k" smette di essere un'ipotesi e diventa una data: ~19
+mesi.** E le soglie $3k/$5k sono superate il primo giorno — il che NON autorizza ad anticipare il
+gate XSR01 del 23/10 (anticiparlo e' selezione sull'hold-out), ma rende viva la sua domanda di
+eseguibilita'.
+
+## Con il rischio di venue dentro
+
+```
+ p annua   P(traguardo)   P(perso TUTTO)   cap. mediano 25a
+   0.0%        100.0%            0.0%        $2,540,508
+   0.5%         94.3%           11.7%        $2,304,596
+   1.0%         88.0%           23.2%        $2,018,727
+   2.0%         78.8%           39.6%        $1,464,013
+   5.0%         55.4%           72.0%                $0
+```
+
+Il piano regge bene fino a p=2%. A p=5% il capitale mediano e' **zero**: e' la stessa conclusione
+del §3, e vale a maggior ragione ora che il capitale in gioco e' 10x.
+
+## ⚠️ AZIONE OPERATIVA PRIMA DEL VERSAMENTO — il cap fisso diventa una strozzatura
+
+`src/live/book._cap` usa il cap **dinamico** (equity/2) solo quando l'equity reale e' leggibile;
+altrimenti ripiega su `max_notional_per_asset_usd = $300`. **A $597 il fallback era INERTE**
+(equity/2 = $298 ≈ $300). **Dopo il versamento l'equity/2 vale ~$3.023**, quindi un fallback
+strozzerebbe il book a **~10% del target** — silenziosamente, con la sola allerta `eq_fallback`.
+
+E' esattamente l'azione **gia' pre-registrata il 2026-07-02** (*"al deposito alzare il cap a
+equity/2"*). Cablato `test_il_cap_fisso_diventa_una_strozzatura_dopo_un_deposito`: **fallisce** se
+si deposita senza adeguare `max_notional_per_asset_usd`.
+
+**Non eseguita**: e' un cambio di config su soldi veri, decisione dell'operatore.
+
+---
+
+## Il cap: alzato a $3.000, ma il modo conta piu' del numero
+
+L'operatore ha autorizzato *"si alza il cap a 3000"*. Verificato prima di eseguire: **il deposito
+non era ancora arrivato** (equity reale letta dal conto: $596.92). Alzare il cap in quel momento
+sarebbe stato **pericoloso nel verso opposto**.
+
+### Perche' alzarlo prima del deposito e' pericoloso
+
+Quando l'equity reale non e' leggibile, `shadow_report` ripiega su `paper_cap` = **$2.000
+nominali**, che non e' il conto vero. Il sizing diventa `0.5 × 2000 × (...)` = fino a $1.000/asset,
+e **il cap fisso e' l'unica cosa che impedisce a quel nominale di diventare leva reale**:
+
+| cap fisso | fallback su conto da $597 | leva reale |
+|---|---|---|
+| $300 (prima) | $300/asset = $600 lordi | **1.00x** ✅ |
+| $3.000 (alzato a mano) | $1.000/asset = $2.000 lordi | **3.35x** ❌ |
+
+Cioe' il cap sarebbe stato troppo alto **proprio nel momento in cui non si sa quanto c'e' sul
+conto** — e con `disaster_sl_pct` −30% quella e' la configurazione peggiore possibile.
+
+### La correzione: il fallback segue l'ultima equity osservata
+
+Invece di alzare un numero da ricordare, il cap di fallback e' stato **legato al conto**:
+
+```python
+cap_fallback = min(cap_fisso_di_config, ultima_equity_reale_osservata * frac)
+```
+
+con un watermark in `data/live/equity_seen.json`, scritto da `book_report` ogni volta che l'equity
+reale e' leggibile. Il cap di config torna a essere quello che dovrebbe: un **tetto dichiarato**.
+
+Verificato sul conto vero, nei due regimi:
+
+```
+oggi, watermark $596.92     ->   $298.46/asset  = leva 1.00x
+dopo il versamento, $6.047  -> $3,000.00/asset  = leva 0.99x
+```
+
+**Sicuro in entrambi gli ordini di eventi**, e senza dipendere da un'azione manuale al momento del
+deposito. Senza watermark (primo avvio, file cancellato) si usa `CAP_UNKNOWN_USD` = $300: non si sa
+niente del conto, si usa la taglia storicamente sicura.
+
+Questo **chiude l'azione pre-registrata il 2026-07-02** (*"al deposito alzare il cap a equity/2"*),
+rimasta ineseguita per 24 giorni — non eseguendola, ma **rendendola non necessaria**.
+
+Guardie: `tests/test_cap_watermark.py` (11), **a due lati** — il cap non puo' ne' superare il conto
+reale (leva nascosta) ne' restare sotto dopo un deposito (strozzatura).
+
+### Regola trasferibile
+
+**Un parametro di sicurezza che va aggiornato a mano a ogni cambio di scala e' un difetto, non una
+configurazione.** Qui lo stesso numero era sbagliato in un verso prima del deposito e nell'altro
+dopo: la soluzione non era scegliere il valore giusto, era **legarlo alla grandezza che lo
+determina**. Il segnale che serviva questa correzione era gia' visibile: l'azione manuale era stata
+pre-registrata 24 giorni prima e non era mai stata eseguita.
+
+---
+
+# Addendum 2 — "dai per scontato che non perdiamo mai con i trade?"
+
+Obiezione dell'operatore. Si divide in due parti che hanno risposte **opposte**:
+la prima e' infondata, la seconda coglie l'ipotesi piu' fragile di tutto il piano.
+Script `r0726_decadimento.py`.
+
+## Parte 1 — no: le perdite sono nel modello
+
+Il block bootstrap ricampiona i ritorni **reali** del book a blocchi di 20 giorni, quindi conserva
+autocorrelazione e forma dei drawdown.
+
+```
+serie reale (2.692 giorni):     in perdita 35.6% · flat 27.5% · in guadagno 36.9%
+                                giorno peggiore -3.94% · peggior mese -5.76%
+5.000 percorsi simulati (20a):  maxDD mediano 14.4% · p90 19.8% · PEGGIORE 44.2%
+                                anni-calendario in perdita 5.8% (su 95.000 anni)
+```
+
+⚠️ **Errore mio catturato scrivendo questo**: la prima stesura riportava **63.9%** di giorni in
+perdita. Artefatto: il de-luck sottrae una costante a *ogni* giorno (e' cosi' che riduce il drift
+lasciando la vol invariata, come prescrive la misura d'ancora), quindi **trasforma il 27.5% di
+giorni flat in piccoli negativi**. Corretto per il drift, fuorviante per la forma.
+**REGOLA: una correzione uniforme sul drift e' giusta per le domande sul drift e sbagliata per le
+domande sulla distribuzione** — la stessa serie dice 36% o 64% di giorni in perdita a seconda di
+quale delle due si guarda, senza che sia cambiato niente.
+
+## Parte 2 — si', ma l'assunzione e' un'altra: che l'edge continui a esistere
+
+Il bootstrap assume che **il futuro sia il passato rimescolato**. Nessuna parte del progetto misura
+il decadimento dell'alpha. Quanto costa se e' falso (piano €5.000 + €500/mese):
+
+```
+scenario                                    mediana traguardo  P(entro 20a)   cap. mediano 20a
+edge intatto (cio' che ho mostrato finora)              11.6a        99.9%         $1,115,643
+edge DIMEZZATO da subito                                15.8a        76.6%           $342,224
+edge che decade a zero in 20 anni                       14.3a        65.5%           $269,970
+edge che decade a zero in 10 anni                   oltre 20a        18.4%           $157,856
+edge MORTO dall'anno 10 (rende 0)                   oltre 20a        42.0%           $259,553
+edge MORTO dall'anno 5                              oltre 20a         0.0%           $163,377
+```
+
+**Il piano NON e' fragile a un dimezzamento dell'edge** (11.6 → 15.8 anni, P ancora 77%). **Lo e'
+alla morte dell'edge.** E la differenza fra i due casi non e' distinguibile in anticipo — e' la
+ragione per cui il progetto ha gate pre-registrati con date e soglie invece di aspettarsi che le
+cose continuino a funzionare.
+
+## Il limite strutturale del metodo
+
+```
+Peggior BIENNIO dell'intero campione: +3.0%
+Se tutti i 20 anni fossero fatti cosi': P(traguardo) 2.9%, capitale mediano $149.014
+                                        (a fronte di $136.847 versati)
+```
+
+**Il peggior biennio della storia del book e' POSITIVO.** Sette anni di storia crypto contengono
+due mercati toro: un decennio davvero brutto **non e' mai successo**, quindi il bootstrap non lo
+puo' estrarre. Non e' un parametro da alzare, e' il limite del ricampionamento: **non si puo'
+simulare un regime peggiore di qualunque cosa ci sia nel campione.**
+
+Se i prossimi 20 anni somigliassero al peggior biennio gia' visto, il capitale finirebbe **appena
+sopra i soldi versati**: il piano non fallirebbe, semplicemente non renderebbe.
+
+## Cosa se ne fa
+
+Nessun cambio a book, pesi o piano. Cambia **cosa si sorveglia**: la domanda "l'edge c'e' ancora?"
+non ha una risposta nel backtest, ce l'ha solo nel forward — che e' esattamente cio' che i monitor
+paper e i gate pre-registrati esistono per misurare.
+
+---
+
+## Addendum 3 — "+184% sembra alto, da dove arriva?"
+
+Obiezione dell'operatore su un numero che avevo citato io. **Aveva ragione, e l'errore era di
+metodo, non di calcolo.**
+
+### Il numero e' vero
+
+Non e' un bug. Tracciato l'anno estremo: e' composto da 18 blocchi da 20 giorni, e **nessuno di
+essi e' negativo in modo significativo**:
+
+```
++20% +15% +12% +10% +8% +8% +8% +7% +6% +6% +5% +5% +2% +1% +0% -0% -0% -1%
+```
+
+La popolazione da cui pesca lo consente: blocchi 20g reali con mediana **−0.1%**, p95 **+8.5%**,
+max **+22.4%**, **skew +2.15** — la firma classica di un trend-follower (molte perdite piccole,
+poche vincite grandi). E la materia prima esiste davvero: **la miglior finestra 365g della storia
+reale e' +89.8%** (il 2020 fece +58% come anno di calendario).
+
+### Ma citarlo era sbagliato
+
+```
+su   1.000 anni simulati:   max  +96.0%
+su   5.000 anni simulati:   max +135.2%
+su  20.000 anni simulati:   max +135.2%
+su 114.000 anni simulati:   max +184.3%
+```
+
+**Il massimo di N estrazioni cresce con N: descrive la taglia della mia simulazione, non la
+strategia.** Con 1.000 percorsi avrei scritto "+96%" e sarebbe stata la stessa strategia. Il numero
+che avevo dato all'operatore parlava del mio `N_PATHS`, non del book.
+
+I numeri corretti sono i **percentili**, che non dipendono dal campione:
+
+| p0.1 | p1 | p5 | p50 | p95 | p99 | p99.9 |
+|---|---|---|---|---|---|---|
+| −17.6% | −11.9% | −5.5% | **+16.0%** | +51.2% | +71.8% | +99.9% |
+
+Vale simmetricamente per il "peggiore": il **−27.4%** che avevo citato e' anch'esso un minimo
+campionario (a 1.000 percorsi era −19.1%). Il numero onesto per la coda sinistra e' **p1 = −11.9%**.
+
+### Cablato
+
+Corretto anche `r0726_decadimento.py`, che riportava "drawdown PEGGIORE 44.2%" con lo stesso
+difetto: ora stampa **p99 = 26.0%** e dichiara esplicitamente che il 44.2% e' un massimo
+campionario da non citare come "il caso peggiore".
+
+### Regola trasferibile
+
+**Il massimo (o il minimo) di una simulazione non e' una statistica della strategia: e' una
+statistica del numero di simulazioni.** Si citano i percentili. E' la stessa famiglia dell'errore
+gia' codificato oggi ("un percentile stampato a 0 decimali mente esattamente agli estremi"): gli
+estremi sono il posto dove i numeri sembrano piu' informativi e lo sono meno.

docs/diary/2026-07-26-wall-fixedpoint.md

@@ -0,0 +1,132 @@
+# 2026-07-26 — Il muro come PUNTO FISSO: la mia previsione era sbagliata, e il numero pubblicato era giusto per caso
+
+**Richiesta:** *"fai follow up"* — il follow-up dichiarato poche ore prima:
+
+> I muri assumono il book a 2 sleeve da $600 fino a $272k. Il book a 5 sleeve ha Sharpe piu' alto,
+> quindi **il muro vero e' piu' basso di $272k**.
+
+**Script:** `r0726_wall_fixedpoint.py`. **Test:** `tests/test_wall_fixedpoint.py` (11).
+**Book, pesi, cron, config: INVARIATI.**
+
+---
+
+## 0. Esito in una riga
+
+**La previsione era sbagliata: il muro NON scende.** A pari nozionale e' **$273.900** contro i
+**$272.061** pubblicati — **+1%**, cioe' l'estrapolazione col book a 2 sleeve era **giusta per
+caso**. Solo a **iso-rischio** scende, a **$222.406 (−18%)**, e li' serve leva a costo minore
+dell'uplift, che non e' gratis.
+
+---
+
+## 1. La struttura giusta: il muro e' un punto fisso
+
+Il difetto era reale: `book_series(alloc=$600)` e' il book a **2 sleeve**, estrapolato fino a
+$272k. A quella taglia gireresti un altro book — a ~$13k si accende GTAA01 (IB), a ~$118k XS01
+(Hyperliquid, 19 gambe).
+
+E la correzione ha una forma: **serve capitale C per girare il book che determina il muro C**.
+Si itera `C_{n+1} = muro(book(C_n))`.
+
+```
+ iter    capitale ipotesi                 sleeve  Sharpe  rendita     -> muro
+    0            $272,061  TP01+SKH01+GTAA01+XS01    1.94   10.84%   $273,900
+CONVERGE a $273,900 (variazione < 2%)
+```
+
+Converge in **una** iterazione, e il motivo e' istruttivo: il muro cade **sopra** la soglia di
+XS01 ($117k), quindi la composizione del book non cambia fra un'iterazione e l'altra. La struttura
+a punto fisso conta solo se il muro atterra **vicino a una soglia** — qui non succede, ma non si
+poteva sapere prima di iterare.
+
+**Regole di ammissione rispettate** (e' il book *deployable*, non il *migliore*): **VRP01 escluso**
+(regola permanente: niente short-vol da modello in deploy), **XSR01 escluso** (gate pre-registrato
+23/10), pesi = book attivo rinormalizzato, costi **capital-aware** (TP01 haircut min-order, GTAA01
+commissione IB reale a banda+cadenza, SKH01 sul path live), fattore d'ancora **misurato su questo
+book** (×0.860) e non ereditato.
+
+---
+
+## 2. Perche' il muro non scende
+
+```
+sleeve      peso   drift/a    vol/a   Sharpe
+TP01        38%     15.7%    12.2%     1.29
+SKH01       23%     27.6%    23.4%     1.18
+GTAA01      23%      6.1%     5.4%     1.12
+XS01        17%     28.0%    20.9%     1.34
+
+book 2-sleeve (riferimento)  drift 18.6%  vol 11.4%  Sharpe 1.64
+book deployable al p.fisso   CAGR  18.3%  vol  8.9%  Sharpe 1.94
+```
+
+Diversificare **alza lo Sharpe** (1.64 → 1.94) ma abbassa **drift e vol insieme**. La rendita
+perpetua vive sul drift: 10.91% → 10.84%, cioe' **invariata**. Il guadagno di Sharpe finisce tutto
+in **meno rischio**, non in piu' reddito.
+
+E' esattamente il fatto gia' misurato il 25/07 (§3): *"Diversificare NON crea reddito a pari
+nozionale — libera BUDGET DI RISCHIO"*. Non me ne ero ricordato scrivendo il follow-up.
+
+## 3. Il confronto onesto e' a ISO-RISCHIO — e stavo violando una regola del progetto
+
+CLAUDE.md ha una regola codificata il 25/07:
+
+> **Un diversificatore a basso CAGR si giudica a ISO-RISCHIO, mai a iso-nozionale** (e' il null
+> de-levering al contrario).
+
+Il confronto che avevo impostato era **iso-nozionale**: quello sbagliato secondo la regola del
+progetto stesso.
+
+```
+lente                                        rendita        muro
+2 sleeve, ×0.89 (pubblicato)                 10.91%     $272,061
+deployable, ISO-NOZIONALE (leva 1.00x)       10.84%     $273,900   (+1%)
+deployable, ISO-RISCHIO   (leva 1.28x)       13.35%     $222,406   (-18%)
+```
+
+✅ **Replica indipendente:** il 25/07 misurava, con macchineria diversa e su un book diverso,
+iso-rischio → **−19% di muro**. Qui esce **−18%**. Due implementazioni separate, stesso numero.
+
+⚠️ L'iso-rischio vale **solo se la leva e' (a) disponibile e (b) a costo minore dell'uplift** —
+addendum IB del 25/07: su ETF a IB c'e' Reg-T 2x (portfolio margin da ~$110k) e il margine costa
+~5.5%/anno. **Il $222k NON sconta il costo del margine: e' un tetto, non una stima.**
+
+---
+
+## 4. Il bug che ha quasi prodotto un titolo grottesco
+
+La prima corsa dava: Sharpe **0.95**, CAGR 6.7%, muro **$854.013** — cioe' *"diversificare triplica
+il muro"*, un risultato spettacolare e falso. Il numero era plausibile abbastanza da poter essere
+pubblicato.
+
+**Causa:** `CC.gtaa_banded` ritorna la storia GTAA **dal 1996**, mentre lo sleeve di produzione
+(`sleeves._gtaa_daily_returns`) la tronca a `GTAA_BOOK_ACTIVATION` (2019-03). Con la
+rinormalizzazione per-riga di `combine_outer`, per il **75% del campione** (1996-2019) il "book a
+4 sleeve" era **GTAA01 da solo al 100%** — uno sleeve al 4% di drift.
+
+**Come l'ho preso:** non da un test, ma perche' **la somma pesata dei componenti (~18%) non
+tornava col drift del combinato (6.8%)**. Una discrepanza di 11 punti che non sapevo spiegare.
+
+**Diagnostica decisiva:** la copertura per colonna — `TP01 24.6% / SKH01 24.6% / GTAA01 100.0% /
+XS01 8.6%`. Un 100% accanto a tre valori bassi dice tutto in una riga.
+
+**Cablato:** `test_gtaa_e_troncato_all_era_book` (la causa), `test_il_book_deployable_non_parte_dal_1996`
+(l'effetto, per prendere una gamba futura che reintroducesse storia antecedente) e
+`test_il_book_a_4_sleeve_ha_sharpe_superiore_al_singolo_gtaa` (plausibilita').
+
+---
+
+## 5. Regole trasferibili
+
+1. **Un follow-up dichiarato contiene una PREVISIONE, e la previsione va misurata, non assunta.**
+   Avevo scritto in CLAUDE.md "il muro vero e' piu' basso": era una deduzione ragionevole
+   (piu' Sharpe → piu' rendita) e sbagliata, perche' la rendita vive sul **drift**.
+2. **Prima di misurare, rileggere le regole gia' codificate.** La risposta ("diversificare non
+   crea reddito a pari nozionale, si giudica a iso-rischio") era gia' in CLAUDE.md dal 25/07 e ho
+   impostato comunque il confronto sbagliato.
+3. **Quando un aggregato non torna con la somma dei suoi pezzi, fermarsi.** L'11% di discrepanza
+   era l'unico segnale del bug: nessun test lo copriva, nessuna eccezione, output plausibile.
+4. **La copertura per colonna e' la prima diagnostica di un outer-join.** Un 100% accanto a valori
+   bassi = una gamba con storia diversa che domina la rinormalizzazione.
+5. **Un punto fisso converge subito se non e' vicino a una soglia** — ma va iterato lo stesso per
+   saperlo.

docs/diary/2026-07-26-wave-esecuzione-dvolspread-xsr-equity.md

@@ -0,0 +1,255 @@
+# 2026-07-26 — Ondata a 3 filoni: esecuzione SKH01, DVOLSPREAD, XSR01 fuori dal crypto
+
+**Script:** `r0726_skh_onbook.py` · `r0726_dvolspread_gate.py` · `r0726_xsr_equity.py`
+**Test:** `tests/test_wave_0726.py` (11 casi) · suite completa **245 verdi**
+**Book / pesi / cron: INVARIATI.** Una raccomandazione operativa aperta (T1), nessuna modifica fatta.
+
+Tre filoni scelti non per esplorare aree nuove — quelle sono in gran parte sature — ma perché
+il progetto stesso aveva lasciato **tre questioni aperte e decidibili oggi**:
+
+| filone | questione aperta | esito |
+|---|---|---|
+| **T1** | il degrado del path live di SKH01 (~−0.35 Sh) è recuperabile? | ⚠️ **il degrado era a sua volta fortuna d'ancora**; metà del fix funziona, l'altra metà no |
+| **T2** | DVOLSPREAD, in limbo dal 21/06, è sleeve o falso positivo? | ✅ **regge i gate che non esistevano allora** — promosso a forward-monitor con parametri onesti |
+| **T3** | XSR01 regge fuori dal crypto e da 2.6 anni monoregime? | ❌ **no** — e si scopre *perché* |
+
+---
+
+## T1 — Il degrado d'esecuzione di SKH01 era anch'esso un artefatto d'ancora
+
+### La domanda
+
+Il book live gira SKH01 con cron orario e uscite **software**. Costo misurato (audit 02/07,
+riconfermato il 24/07): sleeve FULL 1.46→1.19, HOLD 1.64→1.15, DD 18%→25%. È il buco singolo più
+grande del progetto, e il 24/07 aveva già stabilito che **un cron più veloce non lo recupera**.
+
+L'angolo mai testato è l'unico meccanismo che non è un cron: gli **ordini resting on-book**, dove
+esiste un'asimmetria che nessuno aveva sfruttato:
+
+- il **TP è un limit order**: se il prezzo ci arriva, il fill è al livello **per costruzione**
+  (sei il maker), e per giunta a fee maker invece che taker;
+- lo **SL è uno stop-market**: al trigger diventa un ordine a mercato, e in un gap riempie peggio.
+
+Ipotesi: il grosso del degrado sta sul lato TP, quindi è recuperabile senza rischio nuovo.
+
+### Il risultato, e la trappola che ha nascosto
+
+A **offset 0** — la griglia che gira davvero — il quadro sembrava trionfale: l'on-book completo
+recupera il **94%** del degrado. Ma l'offset 0 è già noto essere al 93-98° percentile dei 23
+offset a priori, quindi la lente onesta è la banda.
+
+E qui c'è stato un mio errore di statistica, corretto in corso: avevo confrontato
+**mediana(canonical) − mediana(hourly)**, che confronta offset *diversi* fra loro. Gli offset sono
+**coppie appaiate**: la statistica giusta è la **mediana delle differenze**. Con quella:
+
+| modalità | ΔFULL mediana [min,max] | ΔHOLD mediana | migliora in |
+|---|---|---|---|
+| canonical (tetto teorico) | **+0.054** [−0.05,+0.12] | +0.099 | — |
+| **solo TP a limite** | **+0.054** [−0.03,+0.07] | **+0.061** | **FULL 19/23 · HOLD 21/23 · DD 19/23** |
+| TP + SL on-book | +0.024 [−0.07,+0.11] | +0.031 | FULL 17/23 · HOLD 14/23 |
+| *contributo del solo lato SL* | **−0.010** [−0.13,+0.08] | — | **11/23 = una moneta** |
+
+**Due conclusioni, entrambe diverse da quella che cercavo.**
+
+**(1) Il "−0.35 del path live" è a sua volta un artefatto dell'offset 0.** L'audit del 02/07 aveva
+de-luckato i numeri *headline* di SKH01 ma aveva misurato il **degrado** solo a offset 0. Sulla
+banda appaiata il degrado massimo recuperabile è **+0.054 di Sharpe sul book**, non +0.35 sullo
+sleeve. Il buco più grande del progetto era in buona parte fortuna d'ancora anche lui.
+
+**(2) Lo stop on-book PEGGIORA.** Mettere lo SL sul book cristallizza la perdita al livello,
+mentre l'uscita software ritardata a volte incassa il rimbalzo: contributo mediano **−0.010**,
+positivo in **11/23** offset = indistinguibile da una moneta. La sensibilità lo conferma: sopra
+lo **0.50%** di slippage sullo stop l'on-book è **peggio del live di oggi**.
+
+Il meccanismo è misurato, non ipotizzato: sulle uscite TP il fill orario batte il livello nel
+**42%** dei casi (vantaggio medio −0.035%) — è quasi una moneta, quindi il limit TP **converte una
+lotteria in una certezza** più che aggiungere ritorno. E solo l'**1% degli SL** gappa davvero
+dentro la barra 5m: il gap-through dei crash è reale ma raro.
+
+### Raccomandazione (NON eseguita)
+
+> **Appoggiare il TP come limit resting reduce-only; NON mettere lo SL strategico sul book.**
+> Guadagno atteso **+0.054 FULL / +0.061 HOLD** sul book, positivo in **19-21 offset su 23**,
+> più il risparmio taker→maker su un quarto dei trade.
+
+È un cambio di **esecuzione**, non di strategia, quindi non passa da `weights_tilt_null`. Ma è
+piccolo, e va pesato contro il costo operativo vero: ordini orfani se il cron muore, gestione
+del reduce-only, doppio fill. **Non l'ho implementato**: è una decisione dell'operatore, non un
+fatto compiuto. Il disaster-SL on-book a −30% resta com'è (è un'altra cosa: protezione, non exit).
+
+---
+
+## T2 — DVOLSPREAD regge i gate che nel giugno non esistevano ✅
+
+### Chi è, e perché era in limbo
+
+`agent_14_dvol_spread` (onda ortho, 21/06) è **l'unico sopravvissuto** al marginal scorer
+indurito: dei 18 book relative-value che facevano ADDS con lo scorer vecchio, l'indurito ne lasciò
+in piedi **uno**, questo. Da allora non è mai stato ripreso — non è nel book, non è in un monitor,
+non è stato rifiutato. Era semplicemente lì.
+
+Il segnale: `log(DVOL_btc) − log(DVOL_eth)`, tilt verso la gamba con **vol implicita più ricca**
+(tesi VRP / fear-reversal), market-neutral per costruzione, eseguibile a $600.
+
+Nel frattempo il progetto ha codificato **due gate che il 21/06 non c'erano**, ed erano proprio
+quelli che colpivano le sue riserve dichiarate:
+
+1. **`deflated_sharpe`** (29/06) — l'agente dichiara *da sé* uno sweep di celle. Nel giugno
+   "72/72 celle ADDS" si leggeva come robustezza; il DSR dice che sono anche 72 tentativi.
+2. **`select_cell_insample`** (29/06) — il plateau dell'agente è descritto in termini di
+   **`uplift_hold`**, cioè la cella è stata guardata **sull'hold-out**. È la firma esatta che il
+   gate selection-on-holdout fu scritto per catturare.
+
+### Esito
+
+⚠️ **Prima osservazione: la griglia dichiarata è sbagliata.** Il docstring dice "72-cell sweep", ma
+il plateau che descrive è 6 assi × 3 valori = **729** combinazioni. Le ho valutate tutte e 729 —
+scelta **conservativa**, perché più trial abbassano il DSR.
+
+**Il plateau è reale e larghissimo:** FULL in [0.60, 0.71], HOLD in [0.68, 0.97], e
+**729/729 celle con hold-out positivo**. Non è una cella fortunata.
+
+**La selection-on-holdout c'è, ma è mite.** La cella pubblicata è **83ª/729 sull'hold-out** ma
+**471ª/729 in-sample** — la firma è inequivocabile. Solo che, essendo il plateau così piatto,
+scegliere onestamente la cella in-sample costa poco:
+
+| cella | FULL | IS | HOLD | DSR (729 trial) |
+|---|---|---|---|---|
+| scelta **IN-SAMPLE** (onesta) | 0.68 | 0.70 | **0.69** | **0.953 PASS** |
+| scelta sull'hold-out (proibita) | 0.68 | 0.58 | 0.97 | — |
+| **pubblicata dall'agente** | 0.66 | 0.57 | 0.93 | 0.947 **FAIL** |
+
+Cioè: **l'hold-out onesto è 0.69, non il 0.93 pubblicato** — un haircut reale — ma resta
+chiaramente positivo. E la cella onesta **passa il deflated-Sharpe (0.953)** mentre quella
+pubblicata lo **fallisce (0.947)**, il che è di per sé una conferma che il gate fa il suo lavoro.
+
+Marginale vs TP01 sulla cella onesta: **ADDS**, `robust_oos` ✓, `multicut_persistent` ✓,
+`is_hedge` ✗, `has_insample_edge` ✓, `beats_noise_null` ✓; corr +0.11, alpha annua **+7.4%**,
+beta a TP01 +0.117, jackknife_min_uplift **+0.069**; dSharpe sul book **+0.08 FULL / +0.17 HOLD**
+a w=15%, **+0.11 / +0.25** a w=25%.
+
+### Verdetto: promosso, ma non nel book
+
+**DVOLSPREAD esce dal limbo e diventa un candidato in forward-monitor con parametri ONESTI**
+(`zwin=180, k=2.0, lw=0.6, zw=1.1, tgt=0.17, svw=60` — la cella in-sample), non quelli pubblicati.
+
+### ✅ Monitor CABLATO (stessa sessione)
+
+`scripts/live/paper_dvolspread.py`, in `cron_daily.sh` dopo `fetch_dvol.py` (quindi con DVOL
+fresco), stato in `data/paper_dvolspread/` (gitignored), test `tests/test_paper_dvolspread.py`
+(10 casi). Inception **2026-07-25**, posizione d'apertura +0.184 → **$111/gamba** (cap $300).
+
+**Strumentazione specifica di questo lead** — la ragione per cui non bastava copiare
+`paper_statarb`: il book va **flat quando il DVOL manca**, quindi un feed rotto produrrebbe una
+fila di zeri che, contati come evidenza, direbbero *"nessuna perdita"* invece di *"nessuna
+misura"*. Il monitor tiene una contabilità a **tre stati** — ATTIVE / flat-da-segnale /
+**flat-senza-dato** — e la finestra forward si misura in **barre attive**, non in giorni di
+calendario. C'è anche una **guardia sulla config**: se `FROZEN` diverge dallo stato salvato il
+monitor esce con codice 1 invece di continuare su una finestra non più valida (verificato; nel
+cron non c'è `set -e`, quindi segnala senza rompere la catena).
+
+**Gate pre-registrato (scritto oggi, prima di vedere qualsiasi barra forward):**
+- **kill anticipato 2026-10-24 (~90g):** Sharpe forward < −0.50 → ritiro;
+- **decisione 2027-01-24 (~180g):** promozione solo se *tutte e quattro* — (a) Sharpe > 0,
+  (b) marginale ancora ADDS + robust_oos + has_insample_edge, (c) deflated-Sharpe ricalcolato
+  sul campione esteso ≥ 0.95, (d) `weights_tilt_null` superato;
+- **veto d'integrità:** barre attive < 80% → la finestra non conta, si **estende** invece di
+  decidere su dati mancanti.
+
+⚠️ La soglia (a) è deliberatamente debole — **necessaria, non sufficiente**. Con ~180 barre attive
+l'errore standard dello Sharpe è ≈1.4: una soglia più alta sarebbe finta precisione. Il peso della
+decisione sta su (c) — se il margine 0.953, già sul filo, **non migliora** con più dati, l'edge
+non c'è.
+
+**Perché NON entra nel book, dichiarato:**
+- **campione ATTIVO 1949 giorni su 2691** (72%): prima del 2021-03 non esiste DVOL e il book è
+  correttamente flat. L'**hold-out attivo è 1.6 anni**;
+- **margine DSR sul filo** (0.953 vs soglia 0.95) — un passaggio, non un'assoluzione;
+- non ha ancora affrontato `weights_tilt_null`, che ogni cambio di pesi deve superare;
+- il numero headline che circolava (HOLD 0.93) era gonfiato dalla selezione: **va citato 0.69**.
+
+---
+
+## T3 — XSR01 non generalizza fuori dal crypto ❌ (e si capisce perché)
+
+### La domanda
+
+XSR01 ha superato tutto ciò che gli è stato chiesto, ma la sua debolezza numero uno è dichiarata:
+**2.6 anni monoregime, con l'edge crescente nel tempo** (Sharpe 2024 1.03 / 2025 1.98 / 2026 3.11).
+Con 2.6 anni non si distingue un meccanismo da un regime fortunato. L'unico modo di guadagnare
+potenza senza aspettare è portare il meccanismo **congelato** su un pannello lungo decenni.
+
+**Non è il test del 25/07.** `r0725_statarb_eq.py` aveva già scartato le azioni, ma testava il
+meccanismo a **coppie**. XSR01 è la versione **DEMEANATA cross-sezionalmente**, ed è proprio il
+demeaning ad aver creato l'edge (ampiezza effettiva 4.5 → 37.4). Testare il demean sulle azioni è
+una domanda diversa, mai posta.
+
+### Esito
+
+Meccanismo congelato (W=45, sgn=+1, residuo OLS causale vs **SPY**, z-score, tanh, vol-target 20%,
+demean giornaliero), split IWM/EFA riparati in lettura, annualizzazione a **√252** (giorni di borsa):
+
+| universo | variante | ampiezza eff. | Sharpe **LORDA** | Sharpe netta | maxDD |
+|---|---|---|---|---|---|
+| **SECT9** (9 settoriali, 1998+, 26 anni) | coppie | 5.3 | −0.05 | −1.67 | −91% |
+| **SECT9** | **DEMEAN (= XSR01)** | **6.2** | **+0.24** | −1.61 | −89% |
+| **ALL28** (tutti gli ETF, 30 anni) | coppie | 8.4 | −0.20 | −1.61 | −92% |
+| **ALL28** | **DEMEAN** | **11.3** | **−0.14** | −1.82 | −91% |
+| *XSR01 crypto (25/07, riferimento)* | *DEMEAN* | ***37.4*** | ***+2.70*** | *+1.82* | *−2.6%* |
+
+Null di permutazione cross-sezionale **a fee zero** (la lezione XSR01: permutare un segnale ne fa
+esplodere il turnover, quindi a fee piena il null perderebbe per *costo* e regalerebbe un p-value
+trionfale e falso): SECT9 candidato +0.24 vs null medio 0.00, **p = 0.193**; ALL28 −0.14, **p = 0.747**.
+
+Per decennio (DEMEAN, lordo): SECT9 −0.88 / +0.49 / +0.29 / +0.74 · ALL28 −0.88 / +0.46 / +0.38 / +0.05.
+Stesso profilo nei due universi: fortemente negativo 1998-2005, debolmente positivo poi — il che
+somiglia più a un cambio di regime che a un edge.
+
+### Il risultato più interessante non è il Sharpe, è l'ampiezza
+
+**Il demeaning non fa sulle azioni quello che fa sul crypto.** Sul crypto porta l'ampiezza
+effettiva da 4.5 a 37.4 (**8×**); sulle azioni da 5.3 a 6.2 e da 8.4 a 11.3 (**1.2-1.35×**).
+
+Il perché è strutturale, e spiega XSR01 meglio di quanto lo spiegasse la sua scoperta: il residuo
+OLS **rimuove già** il beta al fattore comune. Sul crypto, dopo aver residualizzato su BTC, alle
+gambe **resta** un enorme fattore comune (ampiezza 4.5 su 50 gambe = quasi una gamba sola) — ed è
+quello che il demeaning toglie. Sulle azioni il residuo-vs-SPY è **già** quasi indipendente
+(5.3 su 9 gambe), quindi il demeaning non ha molto da togliere e non c'è guadagno.
+
+### Cosa significa per il gate del 2026-10-23
+
+Il 25/07 aveva già scritto che *«il gate non può appoggiarsi all'argomento fenomeno universale»*.
+Questo test **lo conferma e chiude la scappatoia** che il test a coppie lasciava aperta: nemmeno
+la versione demeanata — quella vera di XSR01 — funziona sulle azioni.
+
+**Onestà su cosa NON prova:** non prova che XSR01 sia falso. Prova che è **crypto-specifico**, e
+suggerisce quale sia il meccanismo (l'esistenza di un fattore comune residuo che sopravvive alla
+residualizzazione, cosa che le azioni non hanno). Il gate del 23/10 resta **interamente** appoggiato
+sulla finestra forward e sull'haircut di eseguibilità a $5.000, come pre-registrato.
+Nessuna soglia toccata.
+
+---
+
+## Lezioni da portare avanti
+
+1. **Se si de-lucka una strategia, va de-luckato anche il suo DEGRADO.** L'audit del 02/07 ha
+   corretto i numeri headline di SKH01 per la fortuna d'ancora ma ha misurato il costo
+   d'esecuzione a offset 0 — e quel costo si è rivelato **fortunato quanto i numeri che
+   correggeva**. Ogni Δ fra due varianti misurato su una griglia ancorata eredita la fortuna
+   dell'ancora.
+
+2. **Su una griglia di offset appaiati, la statistica è la mediana delle DIFFERENZE, non la
+   differenza delle mediane.** La seconda confronta offset diversi fra loro e qui ribaltava il
+   verdetto (faceva sembrare l'on-book completo migliore del solo TP, mentre è il contrario).
+
+3. **Un lead lasciato "in forward-monitor" senza monitor e senza data di scadenza è un lead
+   perso.** DVOLSPREAD è stato in limbo 35 giorni. La disciplina che il progetto applica ai
+   candidati nuovi (config congelata + gate pre-registrato + cron) non era stata applicata a lui.
+
+4. **Il claim di multiple-testing di un agente va ricontato, non creduto.** Il docstring diceva
+   72 celle; la griglia descritta ne contiene 729. Ricontare è conservativo e costa poco.
+
+5. **Quando un meccanismo non generalizza, chiedersi PERCHÉ vale più del fatto che non generalizzi.**
+   Il fallimento di XSR01 sulle azioni ha prodotto la spiegazione migliore di come funziona sul
+   crypto: il demeaning vale quanto vale il fattore comune **residuo** dopo la residualizzazione,
+   ed è una proprietà dell'asset class, non del segnale.

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

@@ -0,0 +1,172 @@
+# 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.

docs/diary/2026-07-27-lumpsum-venue-gates.md

@@ -0,0 +1,337 @@
+# 2026-07-27 — Il capitale già fermo, due sorveglianze mancanti, e la banda GTAA validata
+
+Richiesta dell'operatore: *"proposte"*. Delle cinque proposte messe sul tavolo ne sono state
+scelte quattro; questo diario le chiude tutte. **Book, pesi, cron-strategia, config: INVARIATI.**
+Il cron guadagna due sorveglianze (non toccano l'esecuzione).
+
+Script: `r0727_lumpsum_split.py`, `r0727_gtaa_band_gate.py`, `scripts/live/fee_watch.py`,
+`scripts/live/monitor_health.py` + `src/live/monitor_health.py`.
+Test: `test_lumpsum_split.py` (14), `test_gtaa_band_gate.py` (13), `test_fee_watch.py` (13),
+`test_monitor_health.py` (16) = **56 nuovi**.
+
+---
+
+## 1. Il capitale già fermo — la leva mai misurata
+
+### Il buco
+
+Tutte le traiettorie pubblicate il 25 e 26/07 hanno `START = 600.0` **cablato**. Il progetto ha
+misurato con grande cura il *calendario* dei versamenti (fattore 6 fra front e back loading) e
+non ha mai misurato un **versamento iniziale** — mentre sul conto Revolut ci sono ~€10.000, di
+cui €6.043 in XEON che rende ~0% reale netto. Il conto che gira ne ha 600.
+
+### Validazione prima dei numeri
+
+La macchineria è una generalizzazione di `r0726_venue_risk.simulate` (capitale iniziale e
+deposito diventano parametri, tutto il resto identico incluso l'ordine di consumo dell'RNG).
+Con lump=0 e €250/mese deve riprodurre **esattamente** i numeri del 26/07:
+
+```
+p=0.0%  P(arrivare) 0.9487 vs 0.9487 · P(perso tutto) 0.0000 vs 0.0000  -> IDENTICO
+p=1.0%  P(arrivare) 0.8080 vs 0.8080 · P(perso tutto) 0.1842 vs 0.1842  -> IDENTICO
+```
+
+### Cosa compra un versamento iniziale (p=0, 100% Deribit, 20 anni)
+
+| lump | dep/mese | totale versato | anni al muro | P(entro 20a) | cap. mediano | rendita a 20a |
+|---|---|---|---|---|---|---|
+| €0 | €0 | $600 | **mai** | 0.0% | $16.354 | €3.21/g |
+| €2.000 | €0 | $2.780 | 19.0a | 2.5% | $75.773 | €14.89/g |
+| €5.000 | €0 | $6.050 | 18.5a | 22.9% | $164.901 | €32.39/g |
+| **€10.000** | **€0** | **$11.500** | **17.2a** | **61.7%** | **$313.448** | **€61.58/g** |
+| €0 | €250 | $66.818 | 15.7a | 94.9% | $544.645 | €106.99/g |
+| €2.000 | €250 | $68.998 | 15.1a | 96.8% | $605.454 | €118.94/g |
+| €5.000 | €250 | $72.268 | 14.4a | 98.2% | $695.475 | €136.62/g |
+| €10.000 | €250 | $77.718 | **13.3a** | 99.5% | $844.022 | €165.80/g |
+
+La riga che sorprende è la quarta: **€10.000 fermi oggi, senza versare mai più nulla,** portano
+al capitale-rendita in 17.2 anni mediani con P=62%. Il piano da €250/mese senza lump ci arriva in
+15.7 anni con P=95%: più affidabile, ma costa $66.818 di versamenti contro $10.900 una volta sola.
+
+### L'equivalenza — e la metrica che sbagliavo
+
+Prima stesura: *"€10.000 subito risparmiano 30 mesi = €7.414 di versamenti futuri, cioè 0.7x"*.
+Numero giusto, domanda sbagliata, e la conclusione che invita è l'opposto di quella corretta: il
+valore di un lump-sum non è versare *meno*, è arrivare *prima*. La formulazione onesta è a quale
+versamento mensile permanente equivale:
+
+| lump | traguardo | equivale a versare | cioè |
+|---|---|---|---|
+| €2.000 | 15.1a (da 15.7a) | €281/mese | +€31/mese per 15 anni (€5.666) |
+| €5.000 | 14.4a | €327/mese | +€77/mese per 14 anni (€13.241) |
+| **€10.000** | **13.3a** | **€404/mese** | **+€154/mese per 13 anni (€24.523)** |
+
+**€10.000 oggi valgono €24.500 di versamenti futuri: 2.45×.** È lo stesso meccanismo del
+front-loading misurato il 26/07, portato al suo estremo.
+
+### E il rischio di venue, che è la metà scomoda della domanda
+
+Il 26/07 aveva già osservato che il front-loading mette più capitale sull'exchange *prima*.
+Un lump-sum è il front-loading estremo, quindi va misurato col rischio dentro. A €10.000 il conto
+sarebbe $11.500 e lo split diventa **possibile** — a quota IB **26%**, non il 25% preferito: sotto
+$3.000 sulla gamba equity non c'è uno sleeve, c'è cash su un secondo conto.
+
+| p annua | P(arrivare) CONC | SPLIT | SPLIT+costi | **P(perso tutto) CONC** | **SPLIT** |
+|---|---|---|---|---|---|
+| 0.0% | 99.5% | 98.2% | 98.0% | 0.0% | 0.0% |
+| 0.5% | 93.2% | 91.4% | 91.2% | **9.7%** | **0.9%** |
+| 1.0% | 87.1% | 85.2% | 85.0% | **18.4%** | **3.5%** |
+| 2.0% | 76.2% | 73.2% | 73.1% | **33.7%** | **11.2%** |
+| 5.0% | 50.5% | 47.9% | 47.8% | **64.1%** | **40.7%** |
+
+Lo split costa **1.9-2.6pp** di P(arrivare) e taglia P(perso tutto) da 18.4% a 3.5% (a p=1%).
+La colonna "SPLIT+costi" applica alla gamba IB il haircut dichiarato (0.8pp/anno di costi a
+taglia piccola + 0.1pp di drag UCITS): **cambia lo 0.1-0.2pp**, cioè niente. Il costo della
+gamba equity non è ciò che decide.
+
+⚠️ **P(perso tutto) sotto CONC non dipende dal lump** (9.7/18.4/33.7/64.1% a qualunque taglia):
+con un conto solo *"almeno un fallimento"* **coincide** con *"perso tutto"*, e quella probabilità
+è una proprietà del tempo di esposizione. Il lump non la peggiora — moltiplica ciò che porta via.
+
+### La sezione che serviva davvero: e se la seconda gamba fosse solo liquidità?
+
+GTAA01 **oggi non è deployabile** (blocco PRIIPs; la via UCITS su Degiro è verificata ma in
+preparazione). Quindi lo split disponibile *subito* è Deribit + un conto fermo.
+
+| p annua | P(arrivare) CONC | SPLIT-GTAA | **SPLIT-CASSA** | P(perso tutto) CONC | SPLIT |
+|---|---|---|---|---|---|
+| 0.5% | 93.2% | 91.4% | **90.7%** | 9.7% | 0.9% |
+| 1.0% | 87.1% | 85.2% | **84.5%** | 18.4% | 3.5% |
+| 2.0% | 76.2% | 73.2% | **72.6%** | 33.7% | 11.2% |
+
+**Tenere ferma la seconda gamba invece di investirla costa 0.6-0.8pp di P(arrivare) e non toglie
+NULLA alla protezione** — che è identica, perché dipende da *quanti conti* falliscono, non da cosa
+ci sta sopra. **La protezione dalla rovina non è bloccata dal PRIIPs, non aspetta la validazione
+della banda, non richiede che GTAA01 esista: richiede un secondo conto.**
+
+### Soglie
+
+* split a quota **raccomandata** (25%): da **$12.000**
+* split forzando la quota fino al 35%: da **$8.571**
+* con un lump da €10.000 il conto sarebbe **$11.500** → possibile, ma a quota 26%.
+
+La riapertura della decisione di venue è fissata a $20.000. Un lump da €10k porta il conto sotto
+quella soglia ma sopra la fattibilità tecnica — ed è **un cambiamento del piano**, il caso in cui
+CLAUDE.md dice esplicitamente di riaprire prima. Questa tabella è il materiale per farlo; la
+decisione resta dell'operatore, come il 26/07.
+
+⚠️ **Cosa questo filone NON decide:** quanto dei €6.043 in XEON sia un vero fondo d'emergenza.
+Un fondo d'emergenza non è capitale disponibile, e la tabella qui sopra misura *cosa compra ogni
+euro che entra*, non *quali euro debbano entrare*.
+
+---
+
+## 2. Fee Deribit — un sorvegliante invece di un promemoria
+
+Il nuovo schema entra in vigore il **1° agosto** e l'annuncio non contiene numeri. La regola era
+già decisa in anticipo (≤5bps/lato → nulla; >10bps → rivedere il peso di SKH01, 4× più
+fee-sensibile di TP01). Mancava solo il modo di accorgersene.
+
+`public/get_instrument` espone il tier **base** — che è quello che paga un conto da $600, dove
+ogni soglia VIP è fuori portata — senza chiavi:
+
+```
+strumento            taker     maker   liquidaz.
+BTC-PERPETUAL         5.00      0.00      75.00
+ETH-PERPETUAL         5.00      0.00      90.00
+verdetto: [OK] taker 5.0bps <= 5: non si tocca nulla
+```
+
+`scripts/live/fee_watch.py` (in `cron_daily.sh`) confronta con l'ultima lettura, allerta su
+**qualsiasi** cambiamento — taker, maker e liquidation fee, che l'annuncio tocca tutti e tre — e
+applica la regola congelata. Cross-check best-effort sulla fee **realmente pagata** dai trade del
+conto, con `{}` che significa *non misurata* e non *zero*.
+
+`test_baseline_e_quella_dei_backtest` lega `BASELINE_TAKER_BPS` al default `fee_rt=0.001` di
+`backtest_signals`: se un giorno le due divergessero, il confronto smetterebbe di avere senso.
+
+---
+
+## 3. I forward-monitor non erano sorvegliati
+
+**Tre gate pre-registrati** — STATARB **27/09**, XSR01 **23/10**, DVOLSPREAD kill **24/10** — si
+decideranno leggendo serie forward. Di quelle serie **una sola** aveva una guardia d'integrità
+(`paper_dvolspread`, contabilità a 3 stati + veto sotto l'80%). Le altre nessuna: `paper_xsr`,
+`paper_statarb`, `paper_prevday`, `paper_portfolio`, `paper_combo` → 0 controlli.
+
+Un monitor fermo produce silenzio, e **il silenzio in una serie di ritorni si legge come zero**,
+cioè come una misura. È lo stesso schema già pagato con `fresh_5m` (26/07) e col feed-freeze del
+14/07.
+
+`src/live/monitor_health.py` misura **due guasti diversi**, perché una sola misura non basta:
+
+* **coda** — l'ultima barra è vecchia (il monitor si è fermato adesso);
+* **buchi interni** — la serie è più corta del proprio arco temporale. *Una guardia di sola
+  freschezza lascerebbe passare un monitor che ha perso il 30% delle barre di mezzo e ha scritto
+  stanotte* — ed è esattamente il guasto che falsifica un gate senza farsi notare.
+
+Cadenze dichiarate per monitor, perché sbagliarle significa un falso allarme a settimana:
+`paper_prevday` registra a barra **oraria** (864 barre in 36 giorni); `paper_combo` vive sul
+calendario di **borsa** (venerdì è l'ultima barra fino a lunedì). Soglia di copertura **0.80**,
+riusata di proposito dal veto DVOLSPREAD: una soglia diversa per monitor renderebbe i gate non
+confrontabili.
+
+Stati: `OK` / `FERMO` / `BUCATO` / `ASSENTE` / **`NUOVO`** — quest'ultimo per i monitor troppo
+giovani per un giudizio (XSR01 e DVOLSPREAD hanno 2 barre): non allerta, ma **non risulta sano**.
+
+Stato al 27/07: 6/6 monitor giudicati, tutti OK; `paper_combo` al 96% per il 3 luglio — festività
+di borsa che `np.busday_count` non conosce. È un **limite dichiarato** e conservativo (segnala di
+più, non di meno).
+
+I test includono i **controlli positivi** obbligatori (un rilevatore che non ha mai segnalato
+nulla è indistinguibile da uno rotto): monitor fermo → FERMO, serie bucata e fresca → BUCATO,
+stato assente → ASSENTE.
+
+---
+
+## 4. La banda GTAA01 al 25% — validata
+
+La proposta del 27/07 (banda = 25% della gamba invece di $50 assoluti) era dichiarata
+esplicitamente non validata. Griglia **30 celle** (5 cadenze × 6 bande) su **29.9 anni** di path
+di produzione, annualizzazione **√252** (una serie su giorni di borsa passata a 365 esce con lo
+Sharpe ×1.20: l'errore del 25/07).
+
+**(A) Selezione in-sample** (cella scelta sui soli dati pre-2015, letta sul 2015+, l'hold-out
+equity documentato di GTAA01):
+
+```
+cella scelta al buio : cadenza 1, banda 25% -> IS 0.66 · OOS 0.90 · FULL 0.74
+cella proposta 27/07 : cadenza 5, banda 25% -> IS 0.62 · OOS 0.86 · FULL 0.70
+rango della proposta : 4/30 in-sample · 5/30 sull'hold-out
+```
+
+Il rango **non migliora** passando all'hold-out → non è selezione-sull'hold-out (la firma sarebbe
+il contrario). La cella scelta al buio preferisce il controllo **giornaliero**, che vale +0.04 di
+Sharpe e costa **42 ordini/anno con 250 controlli manuali**: il conto d'esecuzione non ha API
+(misurato il 27/07), quindi non è una configurazione, è un'ipotesi. La cadenza settimanale costa
+−0.04 e compra l'eseguibilità a mano.
+
+**(B) Deflated Sharpe** sulle 30 celle, dpy=252: **0.999 PASS** (massimo atteso sotto il nullo
+0.14), sia per la proposta sia per la cella scelta al buio.
+
+**(C) Null de-levering** — e qui il modo di fallire **non è quello atteso**:
+
+| banda | corr col riferimento | vol/rif | Sh FULL | |
+|---|---|---|---|---|
+| 0% | 0.983 | 1.03 | 0.59 | OK |
+| 10% | 0.980 | 1.02 | 0.64 | OK |
+| **25%** | **0.951** | **0.99** | **0.70** | OK (al bordo) |
+| 40% | 0.907 | 1.04 | 0.67 | fuori traccia |
+| 60% | 0.859 | 1.10 | 0.59 | fuori traccia |
+
+Allargando la banda **la volatilità non scende**: il null de-levering classico non morde. Ciò che
+si rompe è il **tracking** — lo sleeve tiene posizioni vecchie e smette di somigliare a sé stesso.
+E i due segnali concordano: oltre il 25% la correlazione cala *e* lo Sharpe smette di migliorare,
+quindi non esiste una zona in cui il numero premia il congelamento. ⚠️ Ma **il 25% è al bordo**
+(corr 0.951 contro una soglia di 0.95), non al centro di un plateau: va citato così.
+
+**Invarianza al capitale** — la ragione per cui la proposta esiste:
+
+| capitale | banda 25% | ord/anno | Sharpe | | banda $50 fissa | ord/anno | Sharpe |
+|---|---|---|---|---|---|---|---|
+| $3.000 | $125 | 25 | **0.66** | | $50 | 65 | 0.52 |
+| $10.000 | $417 | 25 | **0.70** | | $50 | 92 | 0.62 |
+| $50.000 | $2.083 | 25 | **0.71** | | $50 | 134 | 0.66 |
+
+⚠️ **25 ordini/anno, non i 21 citati il 27/07**: stimatore diverso (qui il gate contato sulla
+griglia dei controlli, 30 anni, veicoli USA; lì i cambi di posizione sulla finestra UCITS di 3.2
+anni). L'*invarianza* — che è la proprietà sotto esame — regge in entrambi.
+
+**Impatto sul book: Sharpe FULL 2.221 → 2.221, maxDD 6.08% → 5.94%.** Zero. Il book modella
+GTAA01 a $10.000, dove la banda fissa già funziona: **il valore della proposta è tutto al capitale
+piccolo** (0.52 → 0.66 a $3k), cioè al deploy.
+
+**Verdetto: la proposta passa i tre gate.** Produzione **NON toccata**: cambiare
+`REBAL_BAND_USD` non sposta un solo numero pubblicato, e lo sleeve non è deployabile prima dei
+$20k. Il cambio si applica **al deploy**, insieme alla scelta del broker, con questo diario come
+giustificazione.
+
+---
+
+## 5. Il debito chiuso di straforo
+
+`edge_watch.py` — i criteri di kill del book **live** — è in cron dal 26/07 e **non era in
+CLAUDE.md** (zero occorrenze). Il criterio di morte di ciò che gira con soldi veri non stava nella
+memoria operativa del progetto: la sessione successiva avrebbe ragionato come se non esistesse.
+Aggiunto.
+
+---
+
+## 6. Regole
+
+1. **Un parametro d'esecuzione scelto guardando il risultato è selezione come ogni altra**, e va
+   passato per gli stessi gate — anche quando "è solo esecuzione" e non tocca l'allocazione.
+2. **Quando si misura l'effetto di un vincolo, si misura anche il vincolo del vincolo.** Lo split
+   di venue a $11.500 non è "25% su IB": è 26%, perché sotto $3.000 la gamba equity non esiste.
+   È il capitale a scegliere la quota, non la preferenza.
+3. **Il valore di un versamento iniziale non si misura in versamenti risparmiati** (domanda
+   sbagliata, rapporto 0.7×) ma in **versamento mensile equivalente** (2.45×). La prima
+   formulazione invita alla conclusione opposta.
+4. **Una guardia di freschezza non è una guardia d'integrità.** Il guasto che conta — la serie
+   bucata e fresca — passa la prima e fallisce la seconda.
+5. **Il verdetto pre-scritto va confrontato coi numeri prima di stamparlo.** Il testo di (C)
+   diceva "il numero migliora perché esce dal mercato": la vol misurata *non scendeva*, quindi era
+   falso. Il fallimento vero era un altro (tracking), e dirlo giusto vale più che avere ragione.
+6. **Un rischio non-diversificabile si compra con un secondo conto, non con un secondo sleeve.**
+   La protezione dalla rovina è identica con GTAA01 o con liquidità: dipende da quanti conti
+   falliscono, non da cosa ci sta sopra.
+
+---
+
+## 7. Addendum — "€5k messi dove" (stessa sessione)
+
+Domanda diretta dell'operatore dopo il riassunto. Ha richiesto una misura nuova, perché €5.000
+cade in una zona che la tabella §1 non copriva: a **$6.050** lo split *con GTAA01* è impossibile
+(servirebbe il 50% del conto per fare i $3.000 di gamba minima), ma lo split in **liquidità** non
+ha soglie di eseguibilità.
+
+Due correzioni al volo prima dei numeri:
+
+1. **La configurazione vera non è quella che avevo tabulato.** `config/live.json` è stato alzato
+   il 26/07 *"in previsione del versamento (EUR 5.000 + 500/mese → equity ~$6.050)"*: il piano
+   dell'operatore è **€500/mese**, non i €250 di tutte le tabelle. Rimisurato su quella.
+   Conseguenza operativa: **nessuna azione di config al deposito** — il cap è già `min($3.000,
+   equity_osservata × 0.5)`, quindi a $6.050 vale $3.000/asset = leva lorda ≤1x, ed è protetto dal
+   watermark contro il caso "cap alto su conto piccolo".
+2. **Niente si sblocca a $6.050.** GTAA01 richiede $3.000 *sulla gamba* (50% del conto) e non è
+   comunque deployabile (PRIIPs); XS01 ~$20.000; XSR01 è sotto gate fino al 23/10. Il book resta
+   TP01+SKH01 → **l'unica domanda è quanta parte non sta sull'exchange.**
+
+Seconda gamba = liquidità ferma, due letture del suo rischio ([A] rischiosa come Deribit,
+conservativa; [B] conto bancario con tutela dei depositi, realistica):
+
+| fuori exchange | P(arrivare) | anni | P(perso tutto) [A] | [B] | salvato se cade |
+|---|---|---|---|---|---|
+| 0% | 89.4% | 11.4a | 18.4% | 18.4% | $0 |
+| 10% | 89.0% | 11.8a | 3.5% | **0.0%** | $6.818 |
+| **25%** | **88.5%** | **12.4a** | 3.5% | **0.0%** | **$17.045** |
+| 40% | 87.8% | 13.3a | 3.5% | 0.0% | $27.272 |
+
+*(p exchange = 1%; €5.000 + €500/mese, 20 anni)*
+
+⚠️ **Due letture che il tavolo nasconde, e senza le quali si sceglie male.**
+
+**(a) P(perso tutto) SATURA a qualunque quota > 0** (3.5% al 10, 25 e 40%): la protezione binaria
+si compra col semplice fatto di *avere* un secondo conto, non con quanto ci si mette. Ciò che
+distingue le quote è la colonna del salvataggio.
+
+**(b) ⚠️ Errore mio, corretto in sessione.** La prima versione di quella colonna riportava il
+capitale a 20 anni *condizionato al fallimento*, e dava $77k al 10% — undici volte il valore
+vero. Artefatto della convenzione ereditata dal 26/07: **alla morte di un venue i versamenti
+successivi vengono dirottati ai superstiti, e scartati se non ne resta nessuno.** Quel numero
+attribuiva quindi allo split il valore di *continuare a versare*, che si ottiene comunque
+aprendo un altro conto dopo il guasto. La misura onesta è il **salvataggio istantaneo**: quanto
+resta nel momento in cui l'exchange cade. Congelato in
+`test_il_salvataggio_e_istantaneo_non_a_scadenza`.
+
+**Il prezzo, in chiaro:** tenere fuori il 25% costa **0.9pp** di probabilità di arrivare e **circa
+un anno** di ritardo mediano (11.4 → 12.4), e compra ~$17k mediani nel 18% di percorsi in cui
+l'exchange sparisce (a p=1%), più P(perso tutto) → 0 nella lettura realistica.
+
+**E la parte che non costa nulla:** quei soldi sono *già* fuori dall'exchange, in XEON. Lo split
+non si costruisce spostando denaro su un secondo venue — **si ottiene versandone di meno.** Con
+€6.043 in XEON, deporne €5.000 lascia fuori ~16% del capitale investito: già dentro la banda
+10-25%, a costo operativo zero.
+
+**REGOLA: quando una metrica binaria satura, la decisione va spostata sulla metrica continua** —
+qui P(perso tutto) non distingue il 10% dal 40%, il salvataggio sì.

docs/diary/2026-07-29-feed-skh-causa.md

@@ -0,0 +1,142 @@
+# 2026-07-29 — L'allerta funzionava, la sua CAUSA era una riga cablata
+
+**Fatto operativo del giorno.** Il 29/07 il feed 5m che alimenta il segnale SKH01 e' ricaduto sul
+feed certificato in **6 giri orari su 8** fra le 05:00 e le 12:00 UTC. L'allerta cablata il 26/07 ha
+segnalato **ogni volta** — ha fatto esattamente il suo lavoro. Poi ha stampato una causa che non
+aveva misurato.
+
+**Codice:** `src/live/livefeed.py` (`last_fetch_error`), `src/live/book.py` (`skh_feed_errors` nel
+report), `scripts/live/book_execute.py` (allerta con la causa), `scripts/cron_book.sh` (nota sul
+minuto). **Test:** `tests/test_skh_feed_freshness.py` (11 → **16**). **Book, pesi, config, strategia:
+INVARIATI.** Nessuna posizione aperta durante l'incidente (book flat: TP01 risk-off, SKH01 flat).
+
+---
+
+## 1. Cosa e' successo, misurato
+
+Dal log `logs/cron_book.log` (la VPS si e' riavviata alle **04:11 UTC**, kernel 6.8.0-134 →
+6.8.0-136; il giro delle 04:00 non e' partito perche' la macchina era gia' giu' dalle 03:55):
+
+```
+giro (UTC)   eta' ultima barra 5m     durata del giro
+05:00              265 min                  46 s
+06:00              325                      24
+07:00              385                      29
+08:00              445                      26
+09:00              505                      34
+10:00              565                      25
+11:00                0 (fresco)             16      <- ma qui e' fallita la lettura del CONTO
+12:00              685                      25
+12:07                0 (fresco)             10
+```
+
+L'eta' cresce di **60 minuti a ogni giro**: e' la firma esatta del fallback, cioe' l'ultima barra
+resta quella del feed certificato (rebuild giornaliero delle 00:30) mentre l'orologio avanza. Al
+picco la latenza d'uscita di SKH01 e' passata da **~1 ora a ~11 ore**.
+
+## 2. Cosa ha funzionato e cosa no
+
+**Ha funzionato:** l'instrumentazione del 26/07. `feed_age_minutes` → `skh_feed_age_min` → allerta
+Telegram, 6 volte su 6, con la scelta dichiarata allora (**allerta, non blocca** — bloccare
+fermerebbe anche il ribilancio di TP01, nettato sullo stesso strumento, per un guasto di rete).
+
+**Non ha funzionato:** la riga che diceva *perche'*. Era questa, **cablata**:
+
+```python
+"nota": "fresh_5m e' ricaduto sul feed certificato (fetch pubblico KO)"
+```
+
+Non veniva da nessuna misura: veniva stampata identica in ogni caso, compreso quello in cui la coda
+fresca **era** attaccata e il vecchio era il certificato stesso. E' una presunzione con l'aspetto di
+un dato — la forma di difetto che questo progetto ha gia' pagato tre volte in docstring di
+produzione (26/07, tre correzioni in due giorni).
+
+Peggio: la causa vera **non era recuperabile a posteriori**, per costruzione. In
+`_fetch_recent_5m` l'eccezione di pagina viene ingoiata con un `break` e la funzione ritorna quel
+che ha raccolto; se a fallire e' la **prima** pagina il risultato e' un DataFrame vuoto, che a valle
+e' indistinguibile da "il venue non ha barre". Quando il guasto e' rientrato, non resta niente da
+interrogare — e infatti alle 12:14, provando a mano, `fresh_5m` rispondeva in 1.7 s senza errori.
+
+## 3. La correzione: registrare la causa, non indovinarla
+
+`livefeed._LAST_ERROR` + `last_fetch_error()`. Il fallback resta **silenzioso come comportamento**
+(mai operare a cieco > mai operare, scelta del 26/07 confermata): quello che smette di essere
+silenzioso e' il **perche'**. La causa risale fino al report (`skh_feed_errors`, per asset) e fino
+all'allerta, che ora dice cosa e' successo invece di ipotizzarlo.
+
+Tre guasti che prima erano la stessa riga, e ora sono tre righe diverse:
+
+| caso | cosa si vede oggi |
+|---|---|
+| eccezione al fetch (rete, rate limit, venue) | `RuntimeError: 429 ... (pagina 1, BTC/USD:BTC)` |
+| risposta senza barre, nessuna eccezione | `nessuna barra restituita da BTC/USD:BTC (risposta vuota...)` |
+| **coda attaccata, ma il certificato e' vecchio** | `coda fresca attaccata: il feed certificato stesso e' vecchio` |
+
+La terza riga e' quella che la nota cablata **negava**: e' il caso in cui il colpevole non e' la rete
+ma il rebuild giornaliero, cioe' il feed-freeze del 14/07 in un'altra veste.
+
+⚠️ Il caso intermedio, che un test pigro salta: l'errore a **meta' paginazione**. La coda parziale
+viene attaccata comunque — quindi il feed non e' "caduto", e' solo piu' vecchio del dovuto — e
+siccome la paginazione va **in avanti**, cio' che manca sono le barre **piu' recenti**. E' proprio
+il caso in cui l'eta' da sola direbbe poco. Blindato in
+`test_causa_registrata_anche_con_coda_TRONCATA`.
+
+Blindato anche che la causa **non sopravviva a una chiamata riuscita**: un errore appiccicato
+farebbe allertare su un guasto gia' rientrato, e un'allerta che grida senza motivo e' un'allerta che
+si smette di leggere.
+
+## 4. Sull'onestà della diagnosi: la causa del 29/07 resta IGNOTA
+
+Ed e' importante scriverlo, perche' la tentazione era chiudere il cerchio con una spiegazione
+plausibile. Cio' che si sa e' solo **circostanziale**:
+
+- i giri falliti durano quanto quelli riusciti (**16-46 s in entrambi gli stati**) → errore
+  **immediato**, non timeout;
+- la finestra si apre subito dopo il **riavvio delle 04:11**, ma non si chiude con esso (alle 11:00
+  funziona, alle 12:00 no);
+- lo stesso giorno il percorso del **conto** — rete diversa, via `cerbero-mcp`, stesso venue a valle
+  — rispondeva `ReadTimeout(15s)` / `404` / `502`;
+- i due percorsi falliscono **in alternanza**, non insieme (11:00 feed ok + conto ko; 12:00 conto ok
+  + feed ko).
+
+Ipotesi compatibili e **non distinguibili a posteriori**: rate limit per-IP del venue, contesa di
+rete/CPU sulla VPS al minuto tondo, degrado post-riavvio. Una prima stesura di questa modifica
+scriveva nei commenti "*la causa vera era il rate limit Deribit per-IP saturato da un altro progetto
+sulla stessa VPS*" come se fosse un fatto: **rimossa**. Sarebbe stato lo stesso difetto della riga
+che stavo correggendo, scritto meglio.
+
+## 5. Il ripiego sul cron, dichiarato come tale
+
+Il job e' stato spostato da `0 * * * *` a **`7 * * * *`** durante l'incidente (ultimo giro al minuto
+tondo: 12:00; primo al :07: 12:07, riuscito). Motivo: l'ipotesi della contesa al minuto tondo, che e'
+quando parte tutto il resto della macchina.
+
+⚠️ **Non e' un fix verificato: e' un ripiego da UNA osservazione**, preso perche' costa zero. Un
+giro riuscito al :07 contro sei falliti al :00 non e' un esperimento — e' un punto. Se il feed torna
+stantio anche al :07, l'ipotesi e' morta; e in entrambi i casi la risposta la dara' `skh_feed_errors`
+alla prossima occorrenza, non un altro ragionamento. La nota sta in testa a `scripts/cron_book.sh`,
+perche' la riga di crontab vive fuori dal repo e una mitigazione invisibile e' una mitigazione che
+verra' rimossa per sbaglio.
+
+## 6. Sottoprodotto: anche "conto offline" diceva solo che era offline
+
+Stesso buco, altro ramo. Quando `online` e' falso la ragione c'e' gia' — sta in `mark_src`
+(`"fallback close (<Eccezione>)"`) — ma non veniva **mai** stampata: l'allerta diceva *"conto
+offline, salto l'esecuzione"*, che e' vero e inutile. Ora l'allerta porta `mark_src` per asset. Il
+comportamento (fermarsi, non operare a cieco) e' invariato.
+
+---
+
+## Regole
+
+1. **Una nota di diagnosi cablata e' peggio di nessuna nota.** Nessuna nota manda a guardare i dati;
+   una nota sbagliata manda a guardare la pista sbagliata, e sembra una misura.
+2. **Se un errore viene ingoiato per non bloccare, va registrato nello stesso punto in cui lo si
+   ingoia.** Fra il `break` e la fine dell'incidente non c'e' un secondo momento buono: quando la
+   diagnosi diventa urgente, il guasto e' gia' rientrato.
+3. **Un'allerta risponde a due domande diverse — *cosa* e *perche'*.** La prima decide (si opera o
+   no), la seconda ripara. Misurare solo la prima costa un'intera occorrenza del guasto.
+4. **Una mitigazione basata su un'osservazione sola si applica pure, ma si scrive che lo e'** —
+   altrimenti fra tre mesi e' una scelta di progetto di cui nessuno ricorda la fragilita'.
+5. **Distinguere i guasti anche quando l'azione e' la stessa.** "Rete ko", "venue senza barre" e
+   "certificato vecchio" portano tutti a "non mi fido del segnale", ma a tre riparazioni diverse.

docs/diary/2026-07-30-assorbimento-cerbero-bite.md

@@ -0,0 +1,179 @@
+# 2026-07-30 (2º filone) — cerbero-bite viene eliminato: assorbita la raccolta, non il motore
+
+**Decisione dell'operatore:** `/opt/docker/cerbero-bite` viene smantellato e il suo lavoro passa a
+PythagorasGoal. **Esito:** book, pesi, config e strategia INVARIATI. Cambia solo *chi* raccoglie
+la catena opzioni — e cambia in meglio su tre assi misurati.
+
+## Cosa di bite valeva la pena, e cosa no
+
+L'unica parte **irreversibile** è il dato: una catena opzioni non si ricostruisce a posteriori
+(Deribit non serve book storici, non esiste un secondo venue). Tutto il resto è codice, e il codice
+si riscrive.
+
+| parte | assorbita? | perché |
+|---|---|---|
+| `option_chain_snapshots` (1.23M righe) | **sì** | ha appena falsificato il *f* di VRP01; irrecuperabile |
+| `market_snapshots` (17.402 righe, 26/03+) | **sì** | dealer net gamma, gamma flip, rischio liquidazioni, funding cross: dati che il progetto non ha altrove |
+| raccolta continua | **sì, riscritta** | senza, l'archivio si congela e "aspettare il crash" muore |
+| `dvol_history` | no | `fetch_dvol.py` ha storia **più lunga** (2020+ vs 2026-05): copiarla sarebbe una seconda copia peggiore |
+| motore credit-spread ETH | no | il progetto ha già la regola *niente short-vol da modello in deploy*; e il conto era a $52 contro un minimo di $720 |
+| GUI, kill switch, dead-man, audit chain | no | PythagorasGoal ha già `venue_watch`, `edge_watch`, `monitor_health`, `fee_watch` |
+| `decisions` / `positions` | no | 59 valutazioni d'ingresso, 0 posizioni |
+
+Prima di toccare qualsiasi cosa: snapshot `VACUUM INTO` del DB (461 MB) + `audit.log` + config in
+`/opt/docker/backups/manual/cerbero-bite-20260730/`, con SHA256.
+
+## Il collettore nuovo — tre difetti di bite non replicati
+
+`scripts/live/collect_chain.py`, cron **`25 * * * *`**.
+
+**1. Una chiamata per strumento invece di due.** `public/get_order_book?depth=3` restituisce già
+quote, greche, IV, open interest, volume, book **e** `underlying_price`. Bite chiamava ticker e
+orderbook separatamente: doppio costo, e i due potevano riferirsi a istanti diversi.
+Un `get_book_summary_by_currency` iniziale dà l'OI di tutta la catena in **una** chiamata e
+prefiltra sotto soglia: 551 → **~290 chiamate per asset**.
+
+**2. Pacing invece di raffica.** ⚠️ **Il carico non è mai stato il problema.** ~570 chiamate/ora
+sono **0.16/s** se distribuite; bite le sparava in ~26 secondi (**~44/s**) e si auto-saturava il
+rate limit per-IP — 12.186 risposte 429 in 26 ore, il 96% nel minuto `:00`. Token bucket a 4/s +
+backoff: primo giro reale **574 chiamate, 0 risposte 429**.
+
+Il minuto `:25` è una scelta, non un default: `:00` era la raffica di bite, `:07` è `cron_book`
+(da lì passa il feed 5m di SKH01, la cosa che non deve trovare l'IP occupato).
+
+**3. Stato esplicito della quota.** `quote_status` ∈ {`ok`, `no_quote`, `error`}:
+- `no_quote` = il venue ha risposto, il book è vuoto → **fatto di mercato**
+- `error` = la chiamata è fallita → **fatto di infrastruttura**
+
+Bite li faceva collassare entrambi su "riga con bid/ask NULL", ed è per questo che il guasto del
+29/07 (50% di quote perse per 38 ore) non ha prodotto **nessun** segnale: il conteggio righe non
+cambiava. Per lo stesso motivo `book_depth_top3` ora è **NULL su errore, mai 0** — bite scriveva 0,
+e "chiamata fallita" diventava indistinguibile da "book vuoto".
+
+⚠️ Le righe ereditate portano `quote_status='unknown'`. Bite non registrava il perché e **a
+posteriori non è ricostruibile**: si dichiara l'ignoranza invece di inventare uno stato.
+
+## Il silenzio, di nuovo
+
+Un collettore fermo non produce niente, e il niente si legge come "nessun dato quel giorno" invece
+che come "raccolta rotta" — su una serie irrecuperabile è il modo più caro di sbagliare. Ogni giro
+scrive una riga in `data/chain_collect/runs.jsonl`, **anche quando fallisce**, e
+`monitor_health` la sorveglia con cadenza 1h e `max_age_h=3` (due giri persi). È la stessa lezione
+di `paper_dvolspread` e di `fresh_5m`, applicata prima che serva invece che dopo.
+
+## Un difetto trovato per strada: due formati ISO nella stessa colonna
+
+L'import del contesto restituiva **17.310 righe dal 2026-05-01** contro le 17.402 dal **2026-03-26**
+del database. 92 righe di backfill sono scritte senza microsecondi
+(`2026-03-26T12:00:00+00:00`), le altre con (`2026-05-01T15:45:00.062918+00:00`).
+`pd.to_datetime` senza `format` **inferisce un formato solo** dal primo elemento e manda gli altri
+a `NaT`, che il `dropna` a valle rimuoveva **in silenzio**: la serie perdeva i suoi 5 settimane più
+vecchi e la data d'inizio slittava di un mese senza un messaggio.
+
+Corretto con `format="ISO8601"` **e** con uno scarto rumoroso (`_drop_unparsed` stampa quante righe
+cadono e perché). **REGOLA: `dropna` dopo un parsing è un rilevatore di difetti travestito da
+pulizia — se toglie righe deve dirlo.** Un import silenzioso non è un import pulito, è un import
+che non sai se ha funzionato.
+
+## Eliminazione (stessa sera, 21:20 UTC)
+
+Container rimossi, volume `cerbero-bite_bite-data` rimosso, immagine `cerbero-bite:dev` rimossa,
+`/opt/docker/cerbero-bite` cancellata. **12 GB liberati** (73G → 61G di disco usato).
+
+Prima di cancellare, quattro verifiche — nessuna delle quali era "il backup esiste":
+
+1. **Lo snapshot è *completo*, non solo integro.** SHA256 `OK` su entrambi i file, ma soprattutto
+   conteggi confrontati tabella per tabella fra il volume vivo e lo snapshot: `option_chain_snapshots`
+   1.232.212, `market_snapshots` 17.406, `decisions` 59, `positions` 0 — **4 su 4 identici**, e
+   identici anche ai parquet importati. *Un hash prova che il file non è corrotto, non che contenga
+   tutto.*
+2. **I 10,6 GB di backup interni al volume non contenevano dati unici.** 32 snapshot sqlite storici:
+   la domanda giusta non era la loro dimensione ma *se bite potasse lo storico*. Tutti e tre i
+   campioni controllati (09/06, 01/07, finale) hanno **la stessa riga più vecchia**
+   (`2026-05-01T20:53:49.294928`) e conteggi monotoni crescenti (218.500 → 665.949 → 946.990 →
+   1.232.212) → nessuna potatura, sottoinsiemi stretti del DB finale.
+3. **Nessuna dipendenza a runtime.** Né cron, né systemd, né route traefik, né altri progetti: i
+   soli riferimenti rimasti sono documentazione (questo diario, CLAUDE.md, un commento in
+   `backup.sh` e uno in `health-watch.py`) — cioè memoria storica, che è corretto lasciare.
+4. ⚠️ **`cerbero-mcp` è un progetto DIVERSO e serve a PythagorasGoal** (universo Hyperliquid, e il
+   percorso del conto): progetto compose separato, e la rete `traefik` che condividono è dichiarata
+   `external:` nel compose di bite → `down -v` non la tocca. Verificato dopo: `Up 41 hours
+   (healthy)`. *Due servizi con lo stesso prefisso nel nome sono un incidente che aspetta.*
+
+Il codice non è stato cancellato: era già su Gitea (`Adriano/Cerbero-Bite`), e l'unica modifica
+locale pendente — il ripiego del collector da `:00` a `:20`, superato dal successore — è stata
+committata e pushata come commit di dismissione. **Il dato era l'unica parte irreversibile.**
+
+**REGOLA: prima di cancellare una sorgente si verifica che la copia sia completa, non che
+esista** — e "quanto è grande" non è la domanda da fare a un backup, "cosa contiene che l'originale
+non ha più" sì.
+
+### Il primo giro dopo l'eliminazione, e un modo di leggere male il nostro stesso indicatore
+
+Verificato invece che dedotto (21:25 UTC, il primo giro con bite già cancellato):
+**576 chiamate, 0 risposte 429, 0 errori.** È il controllo che conta, perché il guasto del 29/07
+era esattamente la raffica di bite che saturava il rate limit per-IP.
+
+| giro | righe | ok | no_quote | error | **due lati** |
+|---|---|---|---|---|---|
+| 20:00 | 570 | 552 | 17 | 1 | 71.6% |
+| 20:06 | 570 | 570 | 0 | 0 | 75.8% |
+| 20:22 | 570 | 570 | 0 | 0 | 75.6% |
+| 20:25 | 570 | 570 | 0 | 0 | 75.6% |
+| **21:25** | **572** | **572** | **0** | **0** | **75.5%** |
+
+(Il `1 error / 17 no_quote` delle 20:00 è il primo giro in assoluto, con bite ancora acceso a
+sparare al minuto `:00`: la firma del problema, catturata nel suo ultimo momento di vita.)
+
+⚠️ **`ok = 572` non significa "572 quote complete".** Nel collettore `ok` vuol dire *almeno un lato
+del book* (`bid is not None or ask is not None`); le righe con **entrambi** i lati sono **432 su
+572 (75.5%)**. Il resto sono book a un lato solo, normali sulle opzioni molto OTM. Che sia
+strutturale e non un degrado si vede dal fatto che la percentuale è **identica a tutti i giri**,
+prima e dopo l'eliminazione — non dal fatto che sembri alta.
+
+È la lezione «*una riga presente non è un dato presente*» un livello più in giù, applicata allo
+strumento costruito **per** quella lezione: la battuta di cuore distingue `ok`/`no_quote`/`error`,
+quindi vedrebbe il guasto del 29/07 (quote vuote), ma **non** vedrebbe una deriva più sottile —
+book che diventano progressivamente a un lato solo. Non è cablata una soglia: con cinque giri di
+storia sarebbe inventata, e una soglia inventata è peggio di nessuna soglia. **La colonna da
+guardare quando ci saranno settimane di serie è "due lati %".**
+
+## File
+
+- `scripts/live/collect_chain.py` + `scripts/cron_chain.sh` — la raccolta (cron `25 * * * *`)
+- `scripts/analysis/import_cb_archive.py` — import una-tantum dell'archivio
+- `scripts/analysis/certify_cb_chain.py` — certificazione dello store (era `fetch_cb_chain.py`)
+- `scripts/research/cblib.py` — `load_chain()` ora unisce archivio + raccolta
+- `src/live/monitor_health.py` — nuovo spec `collect_chain`
+- `tests/test_collect_chain.py` (11 casi)
+
+## Addendum (stessa sera) — spegnimento, backup, ripresa dopo un riavvio
+
+**Spegnimento.** Prima di fermare i container ho preso uno snapshot **finale** (bite aveva raccolto
+fino alle 20:15, oltre il backup delle 19:55) e ho reimportato: archivio a **1.232.212 righe**.
+Consegna verificata: ultima riga di bite 20:15:00, prima nostra 20:00:18 → **sovrapposizione, nessun
+buco**. `docker compose stop` (non `down -v`: i volumi restano). Effetto misurato: **0 risposte 429**
+su cerbero-mcp nei minuti successivi, contro ~650 per ogni giro orario.
+
+**Backup.** `data/raw/` è gitignored e il backup rotativo della VPS non copriva PythagorasGoal: dopo
+lo spegnimento di bite l'archivio esisteva in due copie **sullo stesso disco**. Aggiunta
+`do_pythagoras` a `/opt/docker/scripts/backup.sh` con un criterio dichiarato: **si salva ciò che non
+si può riscaricare**. Dentro: catena + contesto, `data/paper_*` e `data/chain_collect` (serie
+forward-only che alimentano i gate pre-registrati — non ricalcolabili per costruzione),
+`options_daily`, `live`, `venue_watch`, `fee_watch`, `config/live.json` → **28 MB**. Fuori: i ~110 MB
+che si riscaricano dai venue.
+
+Due guardie, entrambe provate **nei due versi**: la funzione fallisce se la catena è assente o
+vuota (invece di produrre un archivio che sembra a posto), e verifica che il tar prodotto contenga
+davvero la catena. Il caso negativo produce **0 file**. Per poterlo provare la radice è
+sovrascrivibile via `PYG_ROOT` — *una guardia che non si riesce a far scattare non è distinguibile
+da una rotta.*
+
+⚠️ `/opt/docker/scripts` **non è un repo git**: quella modifica vive solo su disco, e questo diario
+è l'unico posto in cui è scritta.
+
+**Riavvio.** La raccolta riprende da sola: `cron` è `enabled` e `active`, e il collettore non
+dipende da docker né da cerbero-mcp (API pubblica Deribit diretta) — il contrario di bite, che era un
+container. Verificato girando `cron_chain.sh` con `env -i PATH=/usr/bin:/bin`: 574 chiamate, 0
+errori, dato e battuta di cuore scritti. ⚠️ **Finestra scoperta: fino al `:25` successivo, senza
+recupero.** Il collettore non fa catch-up e non potrebbe: le quote passate non sono richiedibili.

docs/diary/2026-07-30-vrp-f-strutture.md

@@ -0,0 +1,99 @@
+# 2026-07-30 (5º filone) — f misurato sul 10g: il mio sospetto era sbagliato, e il campione non basta ancora
+
+**Richiesta dell'operatore:** *«misura f sul 10g quando ci sono abbastanza scadenze».*
+**Esito: misurato oggi (il campione c'era), campione INSUFFICIENTE per la differenza, un mio
+argomento pubblicato oggi REFUTATO. Book, pesi, config INVARIATI.**
+
+Script `scripts/live/vrp_f_watch.py` (in `cron_daily.sh`), test `tests/test_vrp_f_watch.py` (11).
+
+## Il campione c'era già
+
+Prima cosa misurata, non assunta: nella catena (1.235.064 righe, 2026-05-01 → 2026-07-30) ci sono
+**8 scadenze utilizzabili per asset su 8**, per **entrambe** le strutture — quindi 16 osservazioni
+ciascuna. Non serviva aspettare per fare *la misura*; serve aspettare per rispondere alla
+*differenza*, che è un'altra domanda.
+
+## ❌ La correzione: il mio sospetto aveva il meccanismo giusto e la conclusione sbagliata
+
+Nel diario del gate sul tenore, poche ore fa, avevo scritto che la cella vincente
+*«sta plausibilmente massimizzando l'errore di modello, non l'edge»*, perché compra l'ala più
+lontana e il 30/07 aveva misurato quell'ala sottoprezzata ~2.3× dal modello piatto.
+
+Misurato:
+
+| struttura | f_short | f_long | quota ala/corta | **f_net** |
+|---|---|---|---|---|
+| canonico 7g δ−0.10 | 1.013 | 2.233 | **18.4%** | **0.718** |
+| candidato 10g δ−0.05 | 0.972 | **5.846** | **3.2%** | **0.852** |
+
+**Il meccanismo è confermato e più forte del previsto** — l'ala a δ −0.05 costa **5.85×** il
+modello contro 2.23× — **ma la conclusione era rovesciata**: quell'ala pesa il **3.2%** del premio
+corto invece del 18.4%, quindi il suo errore muove molto meno il credito **netto**. Il candidato ha
+un f **migliore**, non peggiore.
+
+L'aritmetica lo rende ovvio a posteriori: con `k = premio_lungo/premio_corto`,
+`f_net = (f_short − k·f_long)/(1 − k)`. Un `f_long` grande fa danno solo se moltiplicato per un `k`
+grande. Avevo guardato il fattore e non il peso.
+
+⚠️ **Artefatto escluso prima di crederci.** Un `f_long` di 5.85 su un'opzione quasi senza valore
+poteva essere solo il tick minimo (0.0001). Misurato: l'ask dell'ala sta a **22 tick di mediana**
+(minimo 15, **0%** delle osservazioni a ≤2 tick). È un prezzo vero, non discretizzazione.
+
+## La differenza NON è stabilita
+
+Confronto **appaiato per (asset, scadenza)** — non due intervalli guardati a occhio:
+
+| | mediana | IC95 bootstrap |
+|---|---|---|
+| f canonico | 0.718 | [0.662, 0.797] |
+| f candidato | 0.852 | [0.809, 0.892] |
+| **differenza appaiata** | **+0.109** | **[−0.047, +0.193]** |
+
+11 coppie su 16 positive, **l'IC contiene lo zero**. Il punto stimato favorisce il candidato; la
+misura non lo stabilisce. ✅ Replica indipendente: il f del canonico esce **0.718** per un percorso
+diverso (finestra DTE e pairing diversi) da quello che stamattina dava 0.73 — le due misure si
+confermano.
+
+Al proprio f misurato: canonico **0.43**, candidato **1.18** (a f=1.00 erano 1.32 e 1.55).
+
+## Criterio pre-registrato, e un sorvegliante invece di un promemoria
+
+Dichiarato **prima** di avere il campione pieno, congelato in un test:
+
+> **≥ 40 coppie appaiate** (oggi 16) **E ampiezza IC95 della differenza ≤ 0.12** (oggi 0.241).
+
+Con ~2 coppie/settimana la prima gamba cade verso **fine ottobre 2026**. `vrp_f_watch.py` gira in
+`cron_daily.sh`, rifà la misura a ogni giro e **manda una notifica una volta sola** quando il
+criterio è soddisfatto. È la disciplina imparata con DVOLSPREAD (35 giorni di limbo): *un lead
+senza sorvegliante e senza data è un lead perso*.
+
+⚠️ **Verificata la calibrazione della soglia prima di fidarsene.** Una soglia sull'*ampiezza* di un
+IC vale solo se l'IC è calibrato. Misurato su differenza vera nulla: lo zero viene escluso nel
+**5.0% / 4.0% / 3.0%** dei casi a n=16/40/60 — esattamente il 5% atteso. (Il test iniziale su un
+seed fisso falliva proprio perché quel seed era uno dei 5% legittimi: sostituito con un test sulla
+**proprietà**, 100 estrazioni.)
+
+## Cosa questa misura NON fa
+
+**Non promuove niente.** Il candidato è bocciato sul **deflated-Sharpe (0.948 < 0.95)**, che non
+dipende da f, e la regola *niente short-vol da modello in deploy* resta. Un f favorevole toglie
+**un argomento di cautela su quattro** — restano il gate pre-registrato, il fatto che la regione
+mai esplorata (>10g) perde comunque, e l'ineseguibilità sotto ~$2.6k.
+
+Ma la decisione ora poggia su **meno gambe di quante ne avevo dichiarate**, e questo va scritto:
+uno dei quattro argomenti era mio, era misurabile, e l'ho misurato sbagliato.
+
+Il valore operativo vero sta sull'altra riga della tabella: **f = 0.718 sul canonico** è il numero
+che rende onesti i conti di uno sleeve che **sta nel book**, non di un candidato.
+
+## Regole
+
+- **Un fattore di errore si giudica moltiplicato per il suo peso.** `f_long` 5.85 sembra
+  devastante e conta il 3%; `f_long` 2.23 sembra mite e conta il 18%. Guardare il fattore senza il
+  peso porta alla conclusione opposta a quella vera.
+- **Prima di credere a un rapporto estremo su un prezzo piccolo, contare i tick.** Un ratio di 5×
+  su qualcosa che vale un tick è aritmetica di griglia, non mercato.
+- **Una soglia su un intervallo di confidenza richiede di verificare la copertura di
+  quell'intervallo** — altrimenti si pre-registra un criterio che non misura ciò che dice.
+- **«Non abbastanza campione» non è «nessuna differenza»**: si aspetta con una data, non si
+  conclude.

docs/diary/2026-07-30-vrp-profit-take.md

@@ -0,0 +1,157 @@
+# 2026-07-30 (3º filone) — profit-take al 50% su VRP01: REFUTED, e una correzione a un numero di stamattina
+
+**Domanda dell'operatore:** *«fai la misura del profit-take al 50%, simula con 3K».*
+**Esito: book, pesi, cron, config INVARIATI.** Il profit-take **non entra**. Ma il filone ha
+prodotto una correzione favorevole a un numero pubblicato **oggi stesso**, e una mia ipotesi
+refutata nella stessa sessione.
+
+Script `scripts/research/r0730_vrp_profit_take.py`, test `tests/test_vrp_profit_take.py` (16 casi).
+
+## Perché questa misura e non un'altra
+
+VRP01 come codificato **tiene fino a scadenza**: in `_vrp_weekly_asset` il payoff è su
+`S1 = px[i + tn]`, non esiste gestione infra-settimana. L'onda 03/07 aveva testato 4 overlay di
+protezione DD (exit-spike, **stop-loss MTM 1.5/2/3×**, ala di coda, cooldown) e li aveva refutati
+4/4 col null del de-levering — ma il profit-take **non era fra quelli**: è un'uscita sul lato del
+*profitto*, non del rischio. Era l'ultimo grado di libertà non misurato su questo sleeve, e la
+misura del 30/07 sulle quote reali diceva che sarebbe scattato in **13 settimane su 15**.
+
+L'idea è la regola 1 del motore di cerbero-bite (`debit <= 50% del credito`), progetto dismesso lo
+stesso giorno. **Non se ne eredita il giudizio: bite non ne ha uno** (59 decisioni, tutte
+`no_entry`, 0 posizioni, in testnet). Si misura.
+
+## Fondazione: replica bit-exact
+
+Prima di ogni delta, la re-implementazione riproduce `_vrp_weekly_asset` a **max|diff| = 0.00e+00
+su entrambi gli asset, zero date non condivise**. Senza questa, ogni numero sotto sarebbe rumore di
+implementazione. Congelata in un test: se qualcuno tocca il sleeve, si rompe.
+
+## Il verdetto
+
+Fee **reali per gamba** (`min(0.03% del sottostante, 12.5% del premio)` = listino Deribit letto da
+`public/get_instruments`), identiche a canonico e variante.
+
+| variante | ShFULL | ShHOLD | maxDD | CAGR | peggior sett. | usciti prima | giorni |
+|---|---|---|---|---|---|---|---|
+| **canonico (a scadenza)** | **1.32** | **0.82** | 10.5% | 10.5% | −7.27% | — | 7.0 |
+| PT 25% | 0.22 | −0.44 | 8.6% | 0.9% | −7.27% | 87% | 2.7 |
+| **PT 50%** | **−0.18** | **−0.65** | 17.3% | −1.3% | −7.27% | 79% | 3.6 |
+| PT 75% | −0.45 | −1.24 | 19.5% | −3.0% | −7.27% | 71% | 4.6 |
+
+**Null del de-levering: REFUTED 6/6** (3 livelli × vol-matched e DD-matched). ⚠️ Nota onesta: sotto
+scalatura moltiplicativa lo Sharpe è **invariante**, quindi il null si riduce a «la variante ha
+Sharpe più alto?». Il `k` dice solo *quanto* de-levering ottiene lo stesso DD: per PT25 basta
+**k=0.818** per avere lo stesso 8.6% di DD **con Sharpe 1.32 invece di 0.22**.
+
+## Il meccanismo — e perché serviva il confronto appaiato
+
+⚠️ **Errore di metodo commesso e corretto in sessione.** Le due varianti sono indicizzate sulla
+**data di uscita**, che il profit-take cambia: un `join="inner"` fra le serie tiene solo le
+settimane *senza* uscita anticipata, dove i valori coincidono per costruzione. La prima
+diagnostica stampava «troncamento 0%, variazione +0%» su tutto — potenza zero, e una conclusione
+esattamente opposta al vero. È la trappola dell'inner-join già codificata due volte nel progetto
+(venue watch, GTAA), qui in veste nuova. Congelata in `test_confrontare_per_data_di_uscita_da_una_risposta_falsa`.
+
+Rifatto **appaiato per ingresso** (stesso trade, due esiti):
+
+| | BTC (71 trade) | ETH (92 trade) |
+|---|---|---|
+| scatta sui **vincenti** | **86%** | **91%** |
+| scatta sui **perdenti** | 25% | 19% |
+| vincenti | +1.419% → +1.023% (**−28%**) | +1.638% → +1.218% (**−26%**) |
+| perdenti | −3.649% → −2.941% (−19%) | −4.248% → −3.505% (−17%) |
+| somma PnL | +60.2% → **+40.9%** | +56.6% → **+36.5%** |
+
+**Il profit-take tronca del 27% i trade che avrebbero vinto comunque e salva un perdente su
+cinque.** La peggior settimana è **identica** (−7.27%) in tutte le varianti: nelle settimane brutte
+lo spread non raggiunge mai +50%, quindi si arriva a scadenza e si prende la perdita piena. È pura
+troncatura dell'upside.
+
+## ❌ Ipotesi mia, nata e refutata nella stessa sessione
+
+Il meccanismo suggeriva una spiegazione: *su 7 giorni chi tocca +50% è proprio chi sarebbe scaduto
+senza valore; a scadenze lunghe — 18g, quella di bite, e i 30-45 DTE dello standard di mestiere —
+la regola dovrebbe pagare.* Testata su 6 tenori:
+
+| tenore | Sh hold | Sh PT50 | ΔSh |
+|---|---|---|---|
+| 7g | 1.32 | −0.18 | −1.50 |
+| 10g | 1.51 | 0.12 | −1.40 |
+| 14g | 1.14 | −0.56 | −1.71 |
+| **18g** (bite) | **1.51** | **0.37** | **−1.14** |
+| 21g | 1.09 | −0.27 | −1.36 |
+| 28g | 1.31 | 0.06 | −1.25 |
+
+**Negativo a tutti e sei.** A 18g è il meno peggio e il DD migliora davvero (7.1% → 3.8%), ma lo
+Sharpe crolla: **firma del de-levering**, non di una protezione. Ipotesi refutata.
+
+⚠️ **La colonna `Sh hold` NON è un risultato.** Sei celle scelte sul campione pieno: il tenore 18
+sembra migliore del 7 (1.51 vs 1.32) ma è esattamente la selezione che `study_family_honest` +
+deflated-Sharpe esistono per uccidere. La griglia 03/07 si fermava a 10 giorni, quindi il buco è
+reale — ma va chiuso con lo strumento giusto, non con questo sweep.
+
+## ✅ Correzione a un numero pubblicato stamattina
+
+Il sleeve modella le fee come **12.5% del credito netto** round-trip. Il listino vero è **0.03% del
+sottostante per gamba** (cap 12.5% *del premio della singola opzione*, che quasi mai morde): su ETH
+sono $1.14 d'ingresso contro i $2.26 del forfait, cioè il modello **sovrastima le fee di ~2×**.
+
+| lente | ShFULL | ShHOLD | maxDD | CAGR |
+|---|---|---|---|---|
+| sleeve ufficiale (forfait) | 1.08 | 0.58 | 11.8% | 8.2% |
+| **fee reali per gamba** | **1.32** | **0.82** | 10.5% | 10.5% |
+
+Combinato col **f = 0.73** misurato stamattina sulle quote reali, il numero onesto di VRP01 è
+**ShFULL 0.47 / DD 14.5%**, non lo **0.31** che ho scritto oggi in CLAUDE.md — che era calcolato
+con le fee forfettarie. Il f resta il difetto dominante; la fee lo attenua di ~+0.16.
+
+**Nessuna azione:** `fee_frac` **non è stato cambiato**. Il forfait è conservativo, e questo
+progetto preferisce i numeri di ammissione conservativi (stessa logica per cui l'audit d'ancora
+del 03/07 su VRP01 è stato accolto come «numeri conservativi, non gonfiati»). Cambiarlo alzerebbe
+i numeri di uno sleeve senza aggiungere edge.
+
+## Rientro immediato dopo l'uscita
+
+Testato come strategia a sé (non è un overlay: cambia la cadenza). PT50 + rientro fa **Sh 1.19**
+contro 1.32 del canonico, CAGR 4.9% contro 10.5%, 200 trade contro 163. Il suo **ShHOLD 2.42** è
+vistoso — ed è precisamente la firma che questo progetto ha imparato a non credere: non è
+selezionabile in-sample (Sharpe FULL più basso), quindi crederci sarebbe selezione sull'hold-out.
+**Non è un lead.**
+
+## $3.000 — la domanda che viene prima
+
+Parametri veri da `public/get_instruments` (30/07): **ETH `min_trade_amount` = 1 contratto = 1 ETH;
+BTC = 0.1 BTC**. Collaterale = strike corto (convenzione cash-secured del sleeve).
+
+| | spot | lotto min | collaterale/lotto | a $3.000 | fee round-trip |
+|---|---|---|---|---|---|
+| BTC | $63.917 | 0.1 | **$6.210** | **0 lotti — FUORI** | $7.67 = 17.8% del credito |
+| ETH | $1.906 | 1.0 | $1.832 | 1 lotto | $2.29 = 12.6% del credito |
+
+Tre conseguenze:
+1. **A $3.000 il sleeve 50/50 diventa ETH-only** — cioè non è più il sleeve misurato.
+2. **Al peso di book (12%) l'allocazione è $360 = 0 lotti.** Per un solo lotto ETH servirebbe il
+   **61% del conto** su un singolo sleeve.
+3. Quindi a $3.000 la domanda «il profit-take migliora VRP01?» **non è la domanda che decide**:
+   VRP01 non è collocabile a quel capitale in nessuna forma sensata.
+
+## Cosa resta
+
+- **Profit-take: REFUTED**, a ogni livello, a ogni f, a ogni tenore, contro il null del de-levering.
+  Con questo il conto degli overlay refutati su VRP01 sale a **5 su 5**, e il filone «gestire VRP01
+  dentro il modello» è chiuso su tutti i lati misurabili.
+- **Buco reale rimasto:** il tenore oltre i 10 giorni non è mai passato per `study_family_honest`.
+  Non è urgente (le opzioni non sono eseguibili prima di ~$2.6k, e a $3k solo ETH e a peso assurdo).
+- **Il vincolo binding non è la ricerca.** Vale la nota del 26/07: qui si è misurato un ΔSharpe che
+  non cambia niente, mentre le leve che decidono restano il capitale che entra e il conto che non
+  sparisce.
+
+## Regole
+
+- **Un'uscita si giudica su un confronto APPAIATO PER INGRESSO**, mai allineando due serie sulla
+  data di uscita: la variante che stai testando è esattamente quella che cambia quella data, e il
+  join tiene solo i casi in cui non è successo niente.
+- **Una regola d'uscita che scatta più spesso sui vincenti che sui perdenti non è protezione, è
+  troncatura** — e si vede in una riga: la peggior settimana non cambia.
+- **Prima di misurare il rendimento a un capitale dato, misurare il lotto minimo del venue.** Qui
+  la risposta operativa («non è collocabile») non dipendeva da nessuno Sharpe.

docs/diary/2026-07-30-vrp-quote-reali.md

@@ -0,0 +1,157 @@
+# 2026-07-30 — VRP01 contro le quote REALI: il f del credito netto è 0.73, non 1.0
+
+**Esito:** nessun cambio a book, pesi, cron o config. Un'ipotesi di VRP01 è **falsificata con
+misura**, e il dataset che l'ha falsificata entra nel progetto (estrattore + certificazione +
+harness + test). Il muro dichiarato per il deploy — il *f* di stress — resta in piedi, intatto.
+
+## Da dove viene il dato
+
+`/opt/docker/cerbero-bite` accumula dal 2026-06-09 la catena opzioni Deribit **mainnet**: entrambe
+le ali, scadenze 1g→3 mesi, ora per ora, con la profondità top-3 del book. È la fonte che il
+progetto cita dal 20/06 (`options_vrp_calibrate.py`) e che finora era stata usata una volta sola,
+via export manuale in `/tmp`.
+
+Il motivo per cui quel dato si **memorizza** invece di richiederlo quando serve: una catena opzioni
+non è ricostruibile a posteriori — Deribit non serve book storici. Un'ora non raccolta è persa per
+sempre. Stessa asimmetria dello storico spot certificato, con l'aggravante che qui non esiste un
+secondo venue da cui recuperarla.
+
+## La domanda
+
+`src/portfolio/sleeves.py:136` — `VRP_CFG` gira a **`f=1.0`**, applicato al credito **NETTO**:
+
+```python
+net_prem = (_bs_put(S0, Ks, T, sig) - _bs_put(S0, Kl, T, sig)) * cfg["f"]
+```
+
+cioè assume che il mercato paghi esattamente ciò che Black-Scholes su DVOL-ATM dice, **per entrambe
+le gambe**. Il caveat di ammissione ("premio MODELLATO su DVOL ATM, skew non esplicito") era
+dichiarato dal 19/06 e mai quantificato, per mancanza di quote vere.
+
+## D1 — copertura: la struttura c'è
+
+Finestra settimanale 4-10 DTE: **8 scadenze su 8** hanno **entrambe** le gambe quotate, per
+entrambi gli asset. Delta realizzati **−0.270** (target −0.280) e **−0.099** (target −0.100): la
+struttura misurata è quella del sleeve, non una sua approssimazione.
+
+## D2 — il numero: f = 0.73
+
+Confronto agli **stessi strike** (così il rapporto isola l'errore di *prezzo*, non la scelta dello
+strike), fill conservativo (vendi al bid, compri all'ask):
+
+| grandezza | mediana | p25 | p75 |
+|---|---|---|---|
+| f gamba **corta** (venduta) | **1.02** | 0.88 | 1.12 |
+| f gamba **lunga** (comprata) | **2.30** | 1.68 | 2.87 |
+| **f credito NETTO** ← quello che entra nel book | **0.73** | 0.71 | 0.82 |
+| f credito netto, a mid | 0.80 | 0.79 | 0.89 |
+
+IC95% bootstrap sulla mediana **[0.698, 0.780]**; **0 osservazioni su 15** arrivano a 1.0.
+
+⚠️ **La calibrazione del 20/06 non è contraddetta, è replicata**: misurava la **sola gamba corta** e
+trovava f ≈ 1.0; qui la stessa quantità, con implementazione indipendente, dà **1.02**. La
+differenza è che VRP01 è uno *spread*, e il problema sta nell'altra gamba.
+
+## Il meccanismo (senza il quale il numero sarebbe un artefatto)
+
+**IV(corta) − DVOL = +0.8 pp**, **IV(lunga) − DVOL = +7.5 pp**. Il modello prezza entrambe le gambe
+a vol ATM; l'ala più OTM — quella che si **compra** — sta 8 punti sopra per skew, quindi costa
+**~2.3× il modello**, e il credito netto si comprime del 27%.
+
+Colpisce esattamente il punto su cui VRP01-v2 era stato promosso: *"(a) defined-risk taglia la coda
+(worst-week −16.6%→−7.4%)"*. Nel modello quell'assicurazione è comprata a vol ATM, cioè quasi
+gratis. Nel mercato costa più del doppio. **Il difetto non è nel premio incassato, è nella
+protezione comprata.**
+
+## Conseguenza, misurata
+
+VRP01 standalone sostituendo **solo** `f` (replica sana a f=1.0: 1.08 / 0.58 / −11.8% contro i
+1.10 / 0.60 / 12% pubblicati):
+
+| f | Sh FULL | DD FULL | CAGR | Sh HOLD-OUT |
+|---|---|---|---|---|
+| **1.00** (assunto) | 1.08 | −11.8% | 8.2% | **+0.58** |
+| **0.80** (misurato a mid) | 0.51 | −14.4% | 3.6% | **−0.02** |
+| **0.73** (misurato, fill conservativo) | 0.31 | −15.3% | 2.0% | **−0.23** |
+
+Book a 5 sleeve (VRP01 al 12%), ancore canoniche: FULL 2.215 → **2.146** (Δ −0.069),
+HOLD 2.347 → **2.244** (Δ −0.103), DD invariato.
+
+**Lettura onesta: il book non crolla** — l'effetto è dentro la banda d'ancora (canonico 2.22 contro
+mediana de-luckata 1.95). Ma il LOO del 26/07 attribuiva a VRP01 **+0.122 di FULL**: **circa metà di
+quel contributo era il prezzo che il modello si faceva da solo.** L'audit d'ancora aveva corretto la
+fortuna di calendario; l'ottimismo di *prezzo* non l'aveva corretto nessuno.
+
+## D3 — ciò che solo questo dato permette
+
+Le stesse due gambe sono riquotate **~164 volte per trade** (orarie) fino a scadenza. Da qui:
+
+- il **50%-profit-take scatterebbe in 13/15 settimane** → la regola di gestione diventa testabile;
+- **peggior mark infra-settimana** (N=13 trade con path): mediana **−6.9%** del capitale, minimo
+  **−81.7%**, su un trade che è finito **in utile**.
+
+⚠️ Il sleeve marca solo a scadenza: quel minimo **non esiste nei suoi numeri**. È la stessa classe
+di errore della lente wick accoppiata del 25/07 — *un rischio valutato sul minimo non si misura
+sulle chiusure*. Il DD 12% di VRP01 è un DD di chiusure settimanali.
+
+## D4 — ciò che il dato NON dice, ed è la ragione per cui si raccoglie
+
+**Nella finestra raccolta VRP01 non avrebbe aperto una sola posizione.** IV-rank mediano 0.12 (ETH)
+e 0.08 (BTC) contro il gate >0.30: **0 settimane su 8** per entrambi. Il massimo di DVOL raccolto
+sta al **24° percentile** (ETH) e **28°** (BTC) della storia.
+
+Quindi il f = 0.73 è misurato nel regime in cui il sleeve **sta flat**. Lo skew è strutturale e in
+stress si irripidisce, quindi la direzione è robusta — ma **la taglia in stress resta non
+misurata**, e il criterio dichiarato il 19/06 ("rivalutare quando cerbero-bite cattura un crash")
+non è stato toccato da questo lavoro.
+
+## Il difetto trovato nel dato, e la certificazione che ora c'è
+
+Il feed ha un guasto **in corso** dal 29/07 05:00 UTC: il collettore persiste la riga anche quando
+il ticker fallisce (rate-limit per-IP), con `bid`/`ask`/`iv`/`delta` NULL. Il **conteggio righe non
+cambia** — 13.000/giorno prima e dopo — quindi ogni controllo di copertura basato sulle righe dice
+"tutto bene". Tasso di quote vuote per settimana: 0.4 · 0.7 · 2.2 · 1.5 · 0.5 · 0.4 · 0.3 → **22%**.
+
+`scripts/analysis/fetch_cb_chain.py` certifica quattro difetti (quote vuote, book incrociato,
+premio non monotono nello strike, `depth==0` ambiguo by design) ed è il posto dove è stata
+imparata la lezione seguente.
+
+⚠️ **La prima stesura della certificazione confrontava "tutto il campione" con "ultimi 7 giorni" —
+e diluiva un guasto di 2 giorni al 13.5%**, cioè commetteva a 7 giorni lo stesso errore che
+dichiarava di voler evitare a 3 mesi. Con la statistica giusta (**giorno peggiore** della finestra)
+lo stesso dato dice **51.7%** e lo status passa da `DEGRADATO` a `QUOTE-VUOTE`.
+**REGOLA: un guasto IN CORSO non si misura con una media su una finestra — si misura al suo giorno
+peggiore. Qualunque finestra è abbastanza lunga da nascondere un guasto abbastanza giovane.**
+Congelata in `test_giorno_peggiore_non_si_lascia_diluire_dalla_media`.
+
+## Cosa NON è stato fatto, e perché
+
+**`VRP_CFG["f"]` non è stato cambiato.** La misura sta su 15 osservazioni, 7 settimane, un solo
+regime — per giunta il regime in cui il sleeve è flat. Sostituire 1.0 con 0.73 significherebbe
+propagare in tutto il book un numero misurato dove il book non opera. La mossa corretta è il
+**caveat quantificato**: i numeri 1.10 / 0.60 / 12% si citano d'ora in poi con "a f=1.0; f misurato
+sulle quote reali 0.73 [0.70, 0.78], a cui l'hold-out standalone è −0.23".
+
+Che VRP01 stia al 12% e non sia deployato è, retroattivamente, la decisione giusta **per il motivo
+giusto**: non "short-vol da modello per prudenza", ma "il modello sovrastima il credito del 27% e
+lo fa sulla gamba che doveva proteggere".
+
+## Regole nuove
+
+1. **Il *f* di una struttura multi-gamba non è il *f* di una sua gamba.** Misurare la sola gamba
+   venduta dà la risposta sbagliata **con segno rassicurante** (1.02 invece di 0.73). Ogni futura
+   calibrazione su quote reali di una struttura a N gambe si fa sul **netto**.
+   Congelata in `test_il_f_della_gamba_corta_non_e_il_f_dello_spread` (3 ali, identità algebrica
+   `f_net = (1 − f_long·k)/(1 − k)` — una soglia sola sarebbe stata una fixture fortunata).
+2. **Un guasto in corso si misura al giorno peggiore, non in media** (sopra).
+3. **Una riga presente non è un dato presente.** Il difetto delle quote vuote è invisibile a
+   qualunque controllo che conti righe: va contato ciò che è **quotato**, non ciò che è **scritto**.
+   È la terza occorrenza della stessa famiglia dopo la contabilità a 3 stati di `paper_dvolspread`
+   (26/07) e il silenzio letto come zero di `fresh_5m` (26/07).
+
+## File
+
+- `scripts/analysis/fetch_cb_chain.py` — estrazione + certificazione → `data/raw/cb_chain.parquet`
+- `scripts/research/cblib.py` — harness (loader, `pick_legs`, `f_factors`, `close_cost_path`)
+- `scripts/research/r0730_vrp_real_quotes.py` — lo studio (D1-D4, meccanismo, sweep f, `--book`)
+- `tests/test_cb_chain_vrp.py` — 14 casi (rilevatori + controlli positivi + guardia di convenzione)

docs/diary/2026-07-30-vrp-tenor-gate.md

@@ -0,0 +1,124 @@
+# 2026-07-30 (4º filone) — il buco del tenore chiuso col gate onesto: nessun cambio a VRP01
+
+**Richiesta dell'operatore:** *«chiudi il buco del tenore con study_family_honest».*
+**Esito: `earns_slot_honest = False`. Book, pesi, cron, config INVARIATI.**
+
+Script `scripts/research/r0730_vrp_tenor_gate.py`, test `tests/test_vrp_tenor_gate.py` (12 casi).
+
+## Il buco, e perché era reale
+
+La griglia strutture del 03/07 (`r0703_vrpimp_structgrid`) cercava su `TENOR_GRID = (3, 5, 7, 10)`:
+**oltre i 10 giorni non è mai stato guardato.** Lo sweep del 30/07 sul profit-take aveva toccato
+14/18/21/28g di passaggio e mostrato che il 18g *sembrava* battere il 7g in hold-to-expiry
+(1.51 vs 1.32) — sei celle scelte sul campione pieno, cioè esattamente la selezione che questo
+gate esiste per uccidere.
+
+## Perché il gate è composto a mano, e non è una scorciatoia
+
+`altlib.study_family_honest` è cablato sui candidati **direzionali**: vuole
+`factory(tf=..., **params) -> target_fn` e passa da `candidate_daily`, che costruisce i rendimenti
+da una serie di *posizioni* su BTC/ETH. VRP01 non è direzionale. Si usano quindi i suoi **tre
+componenti reali**, nello stesso ordine e con le stesse soglie: selezione in-sample-only →
+`altlib.deflated_sharpe` (importato, non riscritto — c'è un test che lo verifica) →
+`altlib.marginal_vs_tp01` (importato).
+
+**Famiglia dichiarata nel docstring PRIMA di guardare i numeri:** 8 tenori × 3 delta corti ×
+3 delta lunghi = **72 celle**. Riaprire il tenore riapre la struttura, e il conteggio dei trial si
+fa **al rialzo** — contarne meno gonfia il deflated-Sharpe.
+
+## Il risultato
+
+| | tenore | δ corto | δ lungo | Sh IS | Sh FULL | Sh HOLD | maxDD | CAGR |
+|---|---|---|---|---|---|---|---|---|
+| **scelta al buio** | 10g | −0.28 | −0.05 | **1.75** | 1.55 | 1.01 | 9.6% | 13.5% |
+| VRP01 canonico | 7g | −0.28 | −0.10 | 1.50 | 1.32 | 0.82 | 10.5% | 10.5% |
+
+Rango del canonico: **17/72 in-sample, 26/72 sul campione pieno**. La selezione al buio sceglie
+un'altra cella, e quella cella batte il canonico sia in-sample sia full.
+
+**Ma il gate si chiude sul deflated-Sharpe:**
+
+| | DSR su 72 trial | esito |
+|---|---|---|
+| cella scelta | **0.948** | **FAIL** (soglia 0.95) |
+| VRP01 canonico | 0.885 | FAIL |
+
+`marginal_vs_tp01` dà **ADDS** a entrambe (corr +0.016, `robust_oos` True, `has_insample_edge`
+True, `is_hedge` False). Quindi il verdetto **non** è «VRP01 è rotto» né «il tenore non conta»:
+è che il vantaggio apparente non sopravvive al conto dei trial.
+
+## Come il buco si chiude davvero: la regione nuova perde
+
+Questo è il punto che rende la chiusura pulita, più del DSR:
+
+| | cella | Sh IS | rango |
+|---|---|---|---|
+| miglior cella **≤10g** (già coperta dal 03/07) | 10g −0.28/−0.05 | 1.75 | 1/72 |
+| miglior cella **>10g** (territorio mai guardato) | 18g −0.28/−0.05 | 1.56 | **8/72** |
+
+Solo **3 celle su 10** nella top-10 in-sample stanno oltre i 10 giorni. **Si è aperta la regione
+mai esplorata e la regione mai esplorata ha perso** contro celle che il 03/07 aveva già visto e
+non promosso. Il buco non è "chiuso perché il gate boccia": è chiuso perché **guardandoci dentro
+non c'è niente**.
+
+## ⚠️ Il vincitore sta dove il modello sbaglia di più
+
+La cella scelta compra l'ala **più lontana** (δ lungo −0.05), e 5 delle 10 celle migliori fanno lo
+stesso. Il 30/07 ha **misurato** che il modello piatto sottoprezza proprio l'ala che si *compra*
+(IV(lunga)−DVOL **+7.5pp** contro +0.8pp della corta, ~**2.3×** il modello), e che l'errore cresce
+con la distanza dallo strike. Una selezione che premia il δ lungo più piccolo sta plausibilmente
+massimizzando **l'errore di modello**, non l'edge.
+
+Onestà su questo punto: è un **sospetto motivato, non una dimostrazione**. Il *mediano* in-sample
+non separa −0.10 da −0.05 (1.37 contro 1.37); a separarsi è la **coda alta** della griglia. Ma
+basta a spostare l'onere della prova, perché `f` **non è misurato** fuori dalla struttura canonica.
+
+⚠️ E la sensibilità a `f` non risolve: applicandolo uniformemente la cella scelta degrada *meno*
+(f=0.73 → 0.84 contro 0.47 del canonico), ma **f uniforme è la lente sbagliata proprio per questa
+struttura**, il cui errore è concentrato in una gamba sola. Un numero rassicurante ottenuto con lo
+strumento sbagliato non è rassicurazione.
+
+## ⚠️ Quanto è robusto il mio stesso verdetto
+
+Il DSR dipende da quanti trial si dichiarano, e qui il verdetto **si ribalta**:
+
+| conteggio | N | DSR | esito |
+|---|---|---|---|
+| solo gli 8 tenori | 8 | 0.983 | **PASS** |
+| **la griglia dichiarata** | **72** | **0.948** | **FAIL** |
+| 72 + 288 simulate del 03/07 | 360 | 0.909 | FAIL |
+
+La griglia è stata dichiarata **prima** di guardare i numeri e il conteggio fatto al rialzo — ma il
+verdetto va citato per quello che è: **fallisce per 0.002**, non è una refutazione netta. (L'ultima
+riga usa trial *simulati* dalla distribuzione osservata, non le Sharpe vere del 03/07, che vengono
+da un motore diverso: indicazione, non misura.) Congelato in
+`test_il_verdetto_dipende_dal_numero_di_trial_dichiarati`, così che nessuno possa farlo passare
+un domani restringendo il conteggio.
+
+## Decisione
+
+**Nessun cambio a VRP01**, per quattro ragioni in ordine di peso:
+
+1. **Il gate pre-registrato fallisce.** Una soglia dichiarata in anticipo che poi si aggira non è
+   una soglia.
+2. **La regione davvero nuova non vince** — quindi questo studio non ribalta il 03/07, lo conferma.
+3. **Il vincitore sta nell'angolo dove abbiamo misurato che il modello è meno affidabile**, e lì
+   `f` non è misurato.
+4. Niente di tutto questo è eseguibile prima di ~$2.6k, e a $3.000 VRP01 è **0 lotti** al peso di
+   book.
+
+**Il seguito giusto non è un altro backtest, è una misura.** Se il 10g/−0.28/−0.05 interessa, la
+domanda che decide è *quanto vale f su quella struttura sulle quote vere* — e da oggi la catena la
+raccogliamo noi ogni ora. Serve però che il collettore accumuli abbastanza scadenze a 10 giorni:
+oggi ci sono 15 osservazioni sul solo canonico.
+
+## Regole
+
+- **Quando si riapre un parametro si riapre la sua famiglia**, e i trial si contano al rialzo: il
+  deflated-Sharpe è l'unico posto dove barare è indolore e invisibile.
+- **Dichiarare la griglia prima di guardare i numeri**, e pubblicare la sensibilità del verdetto al
+  conteggio — un gate che passa solo con la propria griglia preferita non è un gate.
+- **Un buco si chiude meglio mostrando che dentro non c'è niente che bocciando il candidato**: qui
+  la frase che conta non è «DSR 0.948» ma «la regione mai esplorata è ottava».
+- **Se la selezione converge dove un difetto di modello è già misurato, il sospetto vale più del
+  numero** — e si dice che è un sospetto.

docs/diary/2026-08-07-crescita-fisco-etf-scelta.md

@@ -0,0 +1,224 @@
+# 2026-08-07 — La crescita del capitale, il fisco che nessuno aveva contato, e se invece fosse un ETF
+
+**Richieste dell'operatore, in sequenza:** *«stato progetto»* → *«riepiloga piano»* → *«grafico della
+crescita per anno con versamento e con guadagno»* → *«con 800 al mese»* → *«sistema dinamico dove
+imposti valore iniziale, mensile e durata, e calcola la best curva fissando il tempo»* → *«il
+guadagno come viene calcolato? e se mettessi in MSCI World o ETF SP500?»* → *«quale è la miglior
+strategia?»*.
+
+**Esito: book, pesi, cron, config INVARIATI.** Nessuna decisione operativa cambia. Cambiano tre
+numeri pubblicati e cade un'affermazione su GTAA01.
+
+---
+
+## 0. Il buco trovato per primo: quattro risultati mai registrati
+
+Ricostruendo il piano per l'operatore ho scoperto che **quattro commit del 27/07 sera non sono né
+in CLAUDE.md né in un diario**: vivono solo nei messaggi di commit e negli script
+(`r0727_3k_vs_5k.py`, `r0727_orizzonte10.py`, `r0727_tasse.py`). Uno di questi cambia il numero di
+testa del piano — vedi §2. È il motivo per cui questo diario esiste prima ancora del lavoro nuovo.
+
+---
+
+## 1. Come si calcola il «guadagno» — la domanda che andava fatta
+
+Nessuna traiettoria del progetto ipotizza un rendimento. Il meccanismo, ora scritto:
+
+1. si parte dai ritorni giornalieri **veri** del book live (TP01 75% + SKH01 25%), 2.692 giorni dal
+   2019-03-14, già netti di commissioni;
+2. si toglie la fortuna d'ancora: `r − (1−0.89)·media(r)`;
+3. si **rimescolano a blocchi di 20 giorni** (block bootstrap): blocchi, non giorni singoli, per
+   non distruggere il raggruppamento della volatilità;
+4. si compone: `cap *= (1+r)` ogni giorno, deposito ogni 30, imposta a fine anno, su 4.000 percorsi;
+5. **`guadagno = mediana(capitale) − versato`**.
+
+Drift implicito: **17,1% annuo, vol 10,9%**. Non è un'assunzione sul rendimento — è l'assunzione
+che *il futuro somigli a quei 7 anni*. Che è esattamente ciò che §3 mette alla prova.
+
+Script: `scripts/research/r0807_growth_yearly.py` (`--lump`, `--dep`, `--anni`, `--json`).
+
+---
+
+## 2. ⚠️ Il fisco durante l'ACCUMULO — la voce mai contata
+
+`TAX_RATE` compariva in **un solo punto** di tutto il progetto: la lordizzazione del bersaglio in
+fase di *prelievo*. L'accumulo componeva al lordo per dieci o vent'anni. Misurato il 27/07
+(`r0727_tasse.py`) e riprodotto oggi su lump €5.000 + €500/mese:
+
+| | 5 anni | 10 anni | 15 anni |
+|---|---|---|---|
+| costo del fisco d'accumulo | **−15,7%** | **−29,8%** | **−42,6%** |
+
+(27/07, lump €10k: −16,8% / −31% / −44% → replica coerente su lump diverso.)
+
+**L'errore è composto, non una tantum.** Conseguenza da tenere presente: *tutte* le tabelle a 15-20
+anni pubblicate in CLAUDE.md sono al lordo del fisco d'accumulo e vanno lette con questo sconto
+sopra. Assunzioni dichiarate (33% plusvalenze, minusvalenze in carry 4 anni, 0,2% annuo sul valore),
+**non un parere fiscale**.
+
+Piano a €800/mese, 15 anni: capitale mediano **$450.107** netto contro $776.366 lordo.
+
+📌 **Risultato contro-intuitivo:** versare di più **ritarda il sorpasso** (l'anno in cui il guadagno
+cumulato supera tutto il versato): 7º anno a €500/mese, 8º a €800, perché si alza l'asticella che
+il guadagno deve superare. I €300 in più non comprano il sorpasso, comprano il **traguardo**: la
+mediana tocca il bersaglio al 12º anno invece che al 15º, e P(bersaglio) a 15 anni passa da 73,2% a
+99,0%.
+
+⚠️ **€800/mese non bastano per il vincolo dei 10 anni**: P(entro 10 anni) col fisco = **25,5%**.
+Servono ~€880-1.050/mese (27/07), e a quel punto si versano oltre $119.000 per arrivare a $272.061.
+
+---
+
+## 3. E se invece fosse un ETF S&P 500 o MSCI World
+
+Script `scripts/research/r0807_asset_compare.py`. Tre cose andavano rese comparabili:
+
+- **la griglia** — le azioni hanno ~252 barre/anno, il book 365: portate su calendario con **0,0 a
+  borsa chiusa** (convenzione GTAA01). Senza, il Sharpe esce ×1,20 (lezione 25/07);
+- **il fisco** — il book realizza ogni anno al 33%; un UCITS ad accumulazione paga il 26% **alla
+  vendita**. Il differimento è un vantaggio strutturale dell'ETF, ora nel modello (le curve ETF
+  sono valori di *liquidazione*, già al netto dell'imposta latente);
+- **il bersaglio** — $272.061 vale per la rendita perpetua *del book* e per il 33%. Ricalcolato per
+  ciascuno.
+
+| a 15 anni, €5.000 + €500/mese | book | S&P 500 | MSCI World (proxy) |
+|---|---|---|---|
+| rendita perpetua | 11,67% | 4,16% | 3,09% |
+| capitale-rendita necessario | $254.524 | $646.172 | $869.729 |
+| **lente A** — storia piena di ciascuno | $293.823 → **115%** | $204.663 → **32%** | $188.417 → 22% |
+| **lente B** — stessa finestra 2019-26 | $295.540 → **118%** | $343.805 → **110%** | $296.707 → 82% |
+
+**Il risultato che conta non è quale vince, è che le due lenti danno risposte opposte.** Sulla
+storia piena il book stravince; sulla stessa finestra **l'S&P 500 accumula più del book**. Il
+divario della lente A viene interamente dal fatto che i 30 anni dell'indice contengono il 2000 e il
+2008, crolli che la strategia non ha mai vissuto.
+
+📌 **E in una riga della tabella delle serie c'è il fatto più importante:** sulla stessa finestra il
+rendimento è quasi identico — **17,4% contro 16,8%**. Tutta la differenza è nel rischio: vol 11,0%
+contro 19,6%, maxDD 10,5% contro 33,7%. **Il book non guadagna di più, perde di meno** — che è
+precisamente ciò che il progetto scrive di TP01 dal 19/06, qui misurato contro un'alternativa vera.
+E la rendita perpetua vive sul drawdown: per questo il book ha bisogno di **2,5× meno capitale**.
+
+⚠️ MSCI World è un **proxy** (70% SPY + 30% EFA): URTH/ACWI/VT non sono nell'abbonamento dati del
+conto IB. Fra 50% e 80% di quota USA il drift si muove di 0,7 punti e il Sharpe di 0,05.
+
+---
+
+## 4. Quale strategia: book, ETF o un mix
+
+Script `scripts/research/r0807_best_strategy.py`.
+
+⚠️ **Difetto della prima stesura, corretto: un mix esiste solo dove esistono ENTRAMBE le serie.**
+Confrontavo «storia piena» contro «stessa finestra» come due lenti, ma calcolavo i bersagli del mix
+sull'intersezione in entrambe — quindi la lente «storia piena» dichiarava trent'anni e ne usava
+sette (per l'ETF puro dava rendita 8,63% invece del 4,16% vero). **Il confronto fra finestre non è
+disponibile per un portafoglio misto.** Rifatto su una finestra sola, con gli scenari espressi come
+spostamento del **drift**, applicabile simmetricamente ai due lati.
+
+| quota sul book | base | equity a 30 anni | book dimezzato | entrambi cauti | peggiore | **rimpianto max** |
+|---|---|---|---|---|---|---|
+| solo ETF | 68% | 23% | 68% | 23% | 23% | 53% |
+| 25% book | 80% | 41% | 60% | 27% | 27% | 34% |
+| **50% book** | **86%** | 58% | 48% | 27% | 27% | **20%** |
+| 75% book | 84% | 69% | 32% | 23% | 23% | 35% |
+| solo book | 75% | **75%** | 16% | 16% | 16% | 52% |
+
+**Risposta: 50/50**, non perché vinca (vince solo nello scenario base) ma perché ha il **rimpianto
+massimo più basso**. ⚠️ Il criterio del solo caso peggiore **non** distingue 25% da 50% (27,09%
+contro 26,99% = pareggio dentro il rumore): a separarli è il rimpianto.
+
+📌 **L'asimmetria fra i due stress È il risultato.** Quello sull'equity è **misurato** — trent'anni
+esistono e dicono 11,3% invece di 16,5%. Quello sul book è **giudiziale** — metà del drift, scelto a
+mano, perché 7,4 anni sono tutta la storia che ha e *non c'è nulla con cui stressarlo*. Si può
+discutere la taglia del taglio, non lo si può togliere. La sua conseguenza è brutale: col drift
+dimezzato il capitale-rendita del book puro passa da $254k a **$771.646** (rendita 11,67% → 3,85%).
+
+**Perché il mix non è un compromesso:** correlazione book↔S&P **+0,082** nei giorni di borsa aperta,
+**+0,046** nei ribassi; nel 5% di giornate peggiori dell'indice (media −2,94%) il book fa **−0,11%**.
+Il capitale-rendita del 50/50 è **$235.769**, più basso sia del solo ETF ($311.567) sia del solo
+book ($254.524): due motori scorrelati *abbassano l'asticella*.
+
+⚠️ Non c'è il rischio di venue (spingerebbe ancora verso il mix), e la decisione del 26/07 tiene
+tutto su Deribit fino a $20k: questa analisi è **materiale per quella soglia**, non un'indicazione
+di agire adesso.
+
+---
+
+## 5. Il simulatore nel browser, e la sua verifica
+
+`scripts/web/` — motore di accumulo in JavaScript (`engine.js`), serie esportata da
+`export_series.py`, pagine assemblate da `build.py`.
+
+**Il motore JS deve dare la stessa risposta del Python, e lo si prova:** `test_engine.js` confronta
+mediane e probabilità su due configurazioni già calcolate, verifica che il *versato* (deterministico)
+coincida al centesimo, e include un **controllo positivo** (un motore col fisco spento dev'essere
+rilevato fuori tolleranza — un test che non sa fallire non è un test). Il risolutore («quanto serve
+al mese per centrare il bersaglio in N anni») è validato contro `dep_necessario` di `r0727_tasse.py`:
+scarti −0,4% / −0,6% / −1,1% su tre configurazioni.
+
+Misura che ha cambiato una scelta: la banda del versamento suggerito resta **±1% da 1.200 a 3.000
+percorsi** → non domina il Monte Carlo ma la granularità della bisezione (~€5). Percorsi tenuti
+bassi e **incertezza dichiarata**, invece di pagare tempo per una precisione che non arriva.
+
+---
+
+## 6. Quattro errori miei, tutti trovati da un controllo e non a occhio
+
+Sono la parte riutilizzabile del diario.
+
+**(a) Dati inventati in un grafico.** Le righe degli anni 1-2 di una serie erano scritte *a memoria*
+perché l'output del terminale era troncato da `tail`. Le ha trovate il confronto riga-per-riga fra
+il JSON e i dati incollati nella pagina. **Regola: i dati di una pagina si INIETTANO da un file, mai
+si trascrivono** — ora è `build.py` a farlo, e il passaggio manuale non esiste più.
+
+**(b) «Distorsione sistematica» che non esisteva.** Il motore JS sembrava +0,75% sopra il Python su
+8 semi, tutti positivi. Ma erano **8 estrazioni contro UN solo punto Python** (seme 807), che stava
+in basso nella propria distribuzione: 8 segni concordi rispetto a un punto rumoroso non sono 8
+osservazioni indipendenti. Misurato bene (8 semi per parte): **−0,01%, t = −0,04**; e i due
+campionatori cadono entrambi entro 1,7 SE dall'**atteso analitico** della media di blocco.
+**Regola: un confronto punto-contro-distribuzione non produce evidenza di distorsione.**
+
+**(c) Un confronto impossibile per costruzione** — §4, il mix sull'intersezione.
+
+**(d) Una pagina pubblicata rotta.** Python scrive le chiavi dei pesi come `"0.0"`/`"1.0"`, la pagina
+le ricostruiva con `String(0)` → `"0"`: ogni lookup `undefined`, script morto alla prima riga utile.
+I pesi intermedi funzionavano *per caso*. **Il controllo che usavo (`node --check`) valida solo la
+SINTASSI**: ora c'è `smoke.js`, che esegue le pagine con un DOM finto e segnala sia le eccezioni sia
+gli elementi riempiti con `"undefined"`. **Regola: le chiavi di un dizionario Python si LEGGONO dal
+JSON, non si ricostruiscono.**
+
+---
+
+## 7. ⚠️ Effetto collaterale del check: un gate di GTAA01 ora FALLISCE
+
+`tests/test_gtaa_band_gate.py::test_la_proposta_non_e_selezionata_sull_hold_out` — la proposta
+(banda 25%, cadenza 5g) risulta **9ª/30 in-sample e 8ª/30 sull'hold-out**: migliora passando
+all'hold-out, cioè la firma che il test intercetta. CLAUDE.md registra **4/30 e 5/30** (27/07).
+
+Caratterizzato prima di riportarlo:
+
+- i due ranghi sono separati da **0,00116 di Sharpe** su un'ampiezza di griglia di 0,3124 = lo
+  **0,4%**: il criterio non ha mai avuto margine, era una differenza di un rango;
+- il calcolo è **deterministico** (due corse, `max|diff| = 0.0`) e il codice del gate è **invariato**
+  dal 27/07 (nessun commit su `r0727_gtaa_band_gate.py`, `gtaa.py`, `eqlib.py`, `eq_splits.py`);
+- quindi è cambiato **il dato**: `data/raw/` è gitignored e i parquet equity vengono riscritti ogni
+  giorno dal cron con `ADJUSTED_LAST` di IB, che è retroattivo.
+
+📌 **La lezione vale più del test: un gate validato su dati sovrascritti ogni giorno non è
+ri-verificabile.** Il lato cripto non ha questo problema (`rebuild_history.py` ricostruisce da una
+sorgente deterministica); il lato equity sì.
+
+**Il test NON è stato toccato** — allentare una soglia perché ha smesso di passare è ciò che questo
+progetto vieta, e un `xfail` silenzierebbe esattamente il segnale. Nulla di operativo dipende da
+questo (GTAA01 non è deployabile per il blocco PRIIPs e non è nel book live), ma l'affermazione
+*«il rango NON migliora sull'hold-out»* oggi è falsa: **decisione dell'operatore** se correggere
+l'affermazione, ripensare il gate, o congelare uno snapshot dei parquet equity per renderlo
+riproducibile.
+
+---
+
+## Cosa NON cambia
+
+Book, pesi, cron, `config/live.json`, i gate pre-registrati (STATARB 27/09, XSR01 23/10,
+DVOLSPREAD 24/10), la decisione di venue (100% Deribit fino a $20k), il muro pubblicato di
+$272.061. Gli script di questo diario non toccano la produzione.

docs/diary/2026-08-07-gate-gtaa-e-storia-troncata.md

@@ -0,0 +1,180 @@
+# 2026-08-07 — Un gate che falliva, un criterio che non misurava, e una gamba con 13 anni in meno
+
+**Book, pesi, cron, config: INVARIATI.** `REBAL_BAND_USD` resta $50; GTAA01 resta non deployabile
+(PRIIPs) e sotto `GTAA_MIN_CAPITAL`. Cambia un test, cambia un'affermazione in CLAUDE.md, e si
+aggiunge una guardia di certificazione che mancava.
+
+Script: `scripts/research/r0807_gtaa_gate_resolution.py`.
+Test: `tests/test_eq_history_guard.py` (11) + `tests/test_gtaa_band_gate.py` (16, criterio (A)
+sostituito).
+
+---
+
+## Il punto di partenza
+
+Il 07/08, facendo il giro dei test, `test_la_proposta_non_e_selezionata_sull_hold_out` falliva:
+
+```
+la proposta e' 8a sull'hold-out ma 9a in-sample: sta meglio dove non doveva essere guardata
+```
+
+Il gate (A) del 27/07 (`r0727_gtaa_band_gate.py`) era stato registrato cosi': «proposta 4/30
+in-sample, 5/30 hold-out → il rango NON migliora sull'hold-out, quindi non e' selection-on-holdout».
+Il codice non era stato toccato (`git log src/portfolio/gtaa.py` fermo al 26/07). Erano cambiati i
+**dati**: `data/raw/` e' gitignored e il cron ri-scarica ogni notte i sei ETF con `ADJUSTED_LAST`,
+che IB rivede all'indietro a ogni dividendo.
+
+La tentazione ovvia era allentare la soglia o mettere un `xfail`. Sarebbe stato mettere a tacere
+esattamente il segnale. La domanda giusta e' un'altra: **il criterio misura cio' che dichiara?**
+
+---
+
+## (0) Il difetto trovato per strada: TLT ha 13.5 anni in meno
+
+Prima ancora di guardare il criterio, la copertura delle sei gambe:
+
+| gamba | prima barra | quotato dal | mancano | barre | pre-2015 | 2015+ |
+|---|---|---|---|---|---|---|
+| SPY | 1996-08-14 | 1993-01-22 | 3.6a | 7540 | 4625 | 2915 |
+| QQQ | 1999-03-10 | 1999-03-10 | 0.0a | 6896 | 3981 | 2915 |
+| IWM | 2000-05-26 | 2000-05-22 | 0.0a | 6586 | 3671 | 2915 |
+| **TLT** | **2016-02-03** | **2002-07-22** | **13.5a** | 2642 | **0** | 2642 |
+| GLD | 2004-11-18 | 2004-11-18 | 0.0a | 5460 | 2545 | 2915 |
+| HYG | 2007-04-11 | 2007-04-04 | 0.0a | 4861 | 1946 | 2915 |
+
+(SPY parte dal 1996 perche' la richiesta chiede `durationStr="30 Y"`: e' il **tetto**, non un
+difetto. La distinzione conta, senza di essa una guardia segnalerebbe ogni serie lunga.)
+
+**GTAA01 gira su CINQUE gambe prima del 2016**, e la gamba assente e' proprio quella che
+diversifica — le obbligazioni. Conseguenza diretta sul gate (A): l'in-sample (pre-2015) e
+l'hold-out (2015+) **non sono la stessa strategia**.
+
+Non e' successo il 07/08: nel `logs/cron_daily.log` TLT parte dal 2016-02-03 fin dal primo giro
+registrato (24/06), quindi da **prima** della validazione del 27/07. E non e' un fetch da rifare:
+una richiesta retro esplicita (`endDateTime=2016-01-01`, `durationStr="5 Y"`) su questo conto IB
+ritorna **0 barre**. La storia non c'e'.
+
+**Perche' nessuna certificazione l'ha vista.** Il feed equity ha guardie su integrita', gap lunghi,
+spike, split non aggiustati (25/07) e cross-check col gemello UCITS (26/07). **Tutte guardano
+DENTRO la serie.** Una serie troncata e' perfettamente integra: non ha buchi, non ha salti, non ha
+duplicati. E' la terza volta in due settimane che una guardia tarata su una classe di difetto non
+sorveglia le altre (soglia 50% cieca allo split 2:1; soglia sulla deviazione cieca alla
+contaminazione EUR/USD; ora: ogni controllo cieco a cio' che la serie ha perso).
+
+### Cablato
+
+`fetch_ib_equities.certify(sym, df, prev)` ora ha **due** guardie, perche' i due difetti non si
+vedono nello stesso modo:
+
+- **`TRONCATO`** — la serie ha perso storia *rispetto al disco* (parte >10 giorni dopo, o ha >5
+  barre in meno). Prende una troncatura il giorno in cui compare; e' cieca a una gia' presente.
+  **Il file NON viene sovrascritto** — e neppure fuso: `ADJUSTED_LAST` e' ri-aggiustato
+  all'indietro a ogni dividendo, quindi incollare una vintage vecchia a una nuova creerebbe un
+  salto sul giunto, un difetto peggiore di quello che si voleva evitare.
+- **`STORIA-CORTA`** — la serie parte >1 anno dopo la quotazione dello strumento, e non al tetto
+  della richiesta. Prende anche una troncatura presente da sempre, che e' il caso di TLT.
+  Riferimento: `PRIMA_QUOTAZIONE`, sei simboli, **fonte secondaria dichiarata**.
+
+Controlli positivi obbligatori nei test: il giro normale di ogni notte non deve scattare, una
+serie al tetto 30Y non deve scattare, un ETF giovane (HYG) non deve scattare, un simbolo fuori
+tabella non viene giudicato. *Una guardia che non segnala mai e' indistinguibile da una rotta.*
+
+---
+
+## (1) Il criterio non aveva risoluzione — misurato, non argomentato
+
+| | valore |
+|---|---|
+| rango della proposta | 9/30 in-sample · 8/30 hold-out |
+| distanza dal rango precedente | **0.00116** di Sharpe in-sample |
+| spread dell'intera griglia | 0.3124 |
+| il verdetto si decideva su | **0.37% dello spread** |
+
+E la misura che chiude la questione — **il criterio applicato a ogni cella della griglia passa
+14/30 (47%)**. Non e' un caso: la somma dei ranghi e' la stessa nelle due finestre, quindi
+`rank_in <= rank_oos` e' vero per circa **meta' delle celle per costruzione**, qualunque cosa la
+griglia contenga.
+
+> Un gate che una cella a caso passa il 47% delle volte non distingue una proposta onesta da una
+> selezionata sull'hold-out. E' una moneta.
+
+Contorno: lo spostamento tipico fra le due finestre e' di **8 ranghi** (massimo 25), e lo Spearman
+IS/OOS e' **+0.05**. Su questa griglia il rango in-sample non porta informazione sul rango
+hold-out — il che rende il confronto fra i due ranghi doppiamente privo di senso.
+
+---
+
+## (2) Il criterio decidibile
+
+**La proposta del 27/07 e' una BANDA, non una cadenza.** `REBAL_EVERY=5` e' gia' la produzione e
+non era in discussione. Quindi la domanda sulla provenienza della scelta e': *a cadenza di
+produzione, quale banda si sceglie guardando solo il pre-2015?*
+
+| banda | Sh in-sample | Sh hold-out |
+|---|---|---|
+| 0% | 0.5396 | 0.8261 |
+| 5% | 0.5714 | 0.8640 |
+| 10% | 0.5956 | 0.8629 |
+| **25%** | **0.6398** ← argmax | 0.8529 |
+| 40% | 0.6247 | **0.9081** ← argmax |
+| 60% | 0.5874 | 0.7573 |
+
+- banda scelta **sui soli dati pre-2015**: **25%** = la proposta, con margine **+0.0151** sulla 2ª;
+- banda scelta **sull'hold-out**: **40%** — diversa. *(Controllo positivo: se coincidessero, il
+  gate non avrebbe potenza e non andrebbe citato come validazione.)*
+- cella scelta al buio su **tutta** la griglia: cadenza 1, banda **25%** — stessa banda.
+
+**La proposta e' l'esatto contrario di una selezione-sull'hold-out**: e' la cella che si sceglie
+senza guardare l'hold-out, e chi avesse guardato l'hold-out ne avrebbe scelta un'altra. E il
+margine e' **0.0151** contro i **0.00116** su cui si decideva il criterio a ranghi: **13×**.
+
+⚠️ **Cio' che questo criterio NON dice:** che la banda scelta in-sample sia la migliore
+sull'hold-out. Non lo e'. Con lo Spearman IS/OOS a ~0, nessuna cella di questa griglia lo sarebbe
+in modo affidabile. Il gate (A) risponde alla domanda sulla **provenienza** della scelta, non a
+quella sulla **previsione**. Confonderle e' esattamente il modo in cui si finisce a selezionare
+sull'hold-out credendo di validare.
+
+---
+
+## (3) Robustezza al difetto (0)
+
+Rifatto tutto sull'universo a **5 gambe** (senza TLT), coerente fra le due finestre:
+blind **25%**, hold-out **40%**, margine **+0.0164**. Verdetto identico. Il criterio a ranghi
+resta una moneta anche li' (passa 14/30).
+
+Quindi: il difetto dei dati **non e' cio' che decide questo verdetto** — ma resta un difetto, e va
+riparato per suo conto. Che e' cio' che si e' fatto al punto (0).
+
+---
+
+## Cosa cambia
+
+- `tests/test_gtaa_band_gate.py`: il criterio a ranghi e' **ritirato** e sostituito da
+  `test_la_banda_proposta_e_quella_scelta_al_buio` + il suo controllo positivo
+  (`test_chi_guardasse_l_hold_out_sceglierebbe_una_banda_DIVERSA`) + un test sul margine.
+  Il **motivo** del ritiro e' congelato in
+  `test_il_confronto_fra_ranghi_e_una_moneta_ed_e_per_questo_che_e_stato_RITIRATO` — si congela il
+  motivo, non l'esito, che dipende dai dati e si muove da solo.
+- `r0727_gtaa_band_gate.py`: il gate (A) stampa il criterio decidibile; il confronto fra ranghi
+  resta come descrizione, con la data del ritiro.
+- CLAUDE.md: l'affermazione «proposta 4/30 in-sample, 5/30 hold-out → il rango NON migliora» e'
+  corretta.
+- `fetch_ib_equities.py`: le due guardie sulla storia + il riepilogo finale che le elenca.
+
+---
+
+## Regole
+
+1. **Un test che fallisce senza che il codice sia cambiato sta segnalando che i dati non sono
+   versionati.** Prima di toccarlo, si guarda cosa e' cambiato sotto.
+2. **Un criterio va misurato sulla sua risoluzione prima che sul suo esito.** Se decide su una
+   frazione di percento dello spread, il verdetto e' rumore in entrambi i versi — anche quando
+   passa. Il 27/07 quel criterio *passava*, e passava per caso.
+3. **Un gate si valida contando quante volte lo passa un candidato a caso.** Qui: 47%. Il numero
+   si poteva calcolare il 27/07 senza dati nuovi.
+4. **Una certificazione che guarda solo dentro la serie non vede cio' che la serie ha perso.**
+   Una serie troncata e' integra, senza gap, senza spike, senza duplicati: passa tutto.
+5. **Distinguere «giovane», «al tetto della richiesta» e «troncato».** Sono tre cose diverse e
+   solo la terza e' un difetto; senza la distinzione la guardia segnala sempre e viene ignorata.
+6. **Provenienza e previsione sono due domande diverse.** Un gate anti-selezione dice da dove
+   viene la scelta, non se funzionera'.

docs/diary/2026-08-07-piano-al-netto.md

@@ -0,0 +1,164 @@
+# 2026-08-07 — Il piano rifatto al netto: muro, traiettorie, versamenti
+
+**Book, pesi, cron, config: INVARIATI.** Non tocca la produzione: rifa' i numeri del *piano di
+accumulo*, che erano al lordo del fisco.
+
+Script: `scripts/research/r0807_piano_netto.py`. Test: `tests/test_piano_netto.py` (16).
+
+---
+
+## Il debito
+
+Il 07/08 (`r0727_tasse.py`, `r0807_growth_yearly.py`) era stato misurato che l'accumulo composto al
+lordo sovrastima il capitale del **15.7% a 5 anni, 29.8% a 10, 42.6% a 15**. Il fatto era stato
+scritto in memoria — *"TUTTE le tabelle a 15-20 anni pubblicate sopra sono al LORDO"* — ma i numeri
+non erano stati rifatti. Sono numeri che sono serviti a decidere: la traiettoria da $600, la
+tabella «quanto versare per un orizzonte dato», la rendita €/g.
+
+**E il muro stesso non era neutro.** `$272.061` viene da una convenzione **asimmetrica**: il
+prelievo viene lordizzato (€50/g netti → $29.690/anno lordi al 33%) ma il capitale che resta
+investito compone **senza mai pagare imposte**, in accumulo come in prelievo. Le due meta' del
+conto non usano lo stesso fisco.
+
+---
+
+## (0) Il controllo di replica, che ha trovato subito qualcosa
+
+Prima regola: a fisco spento tutto deve riprodurre i numeri pubblicati, altrimenti un numero
+diverso non si distingue da un bug.
+
+| | perpetua | muro |
+|---|---|---|
+| costante pubblicata (`VR.TARGET`, citata ovunque) | — | **$272.061** |
+| questa implementazione, fisco OFF, 4000 path | 10.9131% | **$272.061** |
+| `r0726_capwall_refresh.perp_and_wall` ai suoi **2000** path | 11.0107% | $269.648 |
+| lo stesso, portato a 4000 path | 10.9131% | **$272.061** |
+
+Replica esatta al dollaro fra due implementazioni separate. ⚠️ **Ma trovato per strada:** la
+funzione che ha prodotto il muro gira di default a **2000 path**, e a quella taglia da' $269.648 —
+**0.9% di rumore Monte Carlo**. Il muro pubblicato e' corretto (fu calcolato a 4000), ma **la sua
+terza cifra significativa non e' un'informazione**: si cita **$272k**, non $272.061.
+
+---
+
+## (1) Il muro, nella convenzione coerente
+
+Imposte pagate ogni anno **dentro** il portafoglio (stessa meccanica dell'accumulo: plusvalenza
+annua al netto dei movimenti di cassa, carry 4 anni, patrimoniale 0.2%), prelievo gia' netto:
+
+| convenzione | prelievo/anno | perpetua | muro |
+|---|---|---|---|
+| (a) pubblicata — fisco solo sul prelievo | $29.690 | 10.91% | **$272.061** |
+| (b) coerente, aliquota 33% | $19.892 | **7.70%** | **$258.338** |
+| (b) coerente, aliquota 26% | $19.892 | 8.42% | $236.310 |
+
+**−5.0%.** I due errori della convenzione (a) vanno in versi opposti e **si compensano quasi**:
+lordizzare il prelievo alza il muro, non tassare il capitale investito lo abbassa. Ma si
+compensano *per caso*, non per costruzione — e' il tipo di errore che si vede solo rifacendo il
+conto in modo coerente. Cio' che resta scoperto e' la patrimoniale e la non-linearita' della
+rendita perpetua nel drift.
+
+---
+
+## (2) Le traiettorie — ed e' qui che il fisco morde
+
+Orizzonte 25 anni, 3000 path, seed 725: **esattamente la macchina che ha prodotto la tabella
+pubblicata**, quindi la colonna LORDA e' una replica di controllo.
+
+| €/mese | versato in 20a | LORDO: anni | P(20a) | NETTO: anni | P(20a) |
+|---|---|---|---|---|---|
+| 0 | $600 | mai | 0% | mai | 0% |
+| **250** | $66.818 | **16.3a** *(pubbl. 16.2)* | **92%** *(pubbl. 92%)* | **19.8a** | **52%** |
+| 500 | $133.035 | 12.4a *(pubbl. 12.4)* | 100% | 14.7a | 99% |
+| 800 | $212.496 | 10.0a | 100% | 11.4a | 100% |
+| 1000 | $265.470 | 9.0a *(pubbl. 9.0)* | 100% | 10.0a | 100% |
+| 2000 | $530.340 | 6.0a *(pubbl. 6.0)* | 100% | 6.4a | 100% |
+
+**Il livello €250/mese — quello con cui il 26/07 il piano risultava «P(entro 20a) 92%» — al netto
+diventa una moneta: 52%.**
+
+⚠️ **La colonna «anni» e' la mediana CONDIZIONATA all'arrivo** (convenzione di
+`r0726_capwall_refresh.trajectory`, quindi confrontabile con la tabella pubblicata) e va letta
+insieme alla probabilita' accanto.
+
+> **Errore mio, catturato prima di pubblicare.** La prima stesura calcolava la mediana
+> sull'**intero** vettore, con i non-arrivi codificati `-1`. Risultato: €250/mese risultava passare
+> da 15.7 a **15.3** anni col fisco — *piu' veloce* — mentre la probabilita' crollava da 91% a 53%.
+> Con meta' dei path a `-1` la mediana del vettore cade sui **primi** arrivi. **Un non-arrivo va
+> messo a +∞, non a −1: messo a −1 il numero migliora tanto piu' quanto peggio va la colonna**, ed
+> era abbastanza plausibile da finire in un verdetto.
+
+---
+
+## (3) Quanto versare per un orizzonte dato — al netto
+
+Bersaglio $258.338. Fra parentesi il numero pubblicato (lordo, bersaglio $272.061).
+
+| orizzonte | P=50% | P=75% | P=90% | P=95% | tot. versato @P=90% |
+|---|---|---|---|---|---|
+| **10 anni** | €998/m | €1.162/m | **€1.323/m** *(€1.178)* | €1.424/m | **$175.058** *($155.923)* |
+| 15 anni | €470/m | €570/m | **€672/m** *(€509)* | €725/m | $133.983 *($101.643)* |
+| 20 anni | €245/m | €306/m | **€371/m** *(€237)* | €417/m | $98.762 *($63.406)* |
+
+**Il fisco costa +12% al mese a 10 anni, +32% a 15, +57% a 20.** Cresce con l'orizzonte perche'
+l'errore era composto: piu' tempo, piu' interessi mai maturati sulle imposte non pagate.
+
+E la lettura del 26/07 si **rafforza**: a 10 anni versi **$175k** per arrivare a $258k (il
+rendimento fa il 32%), a 20 anni ne versi **$99k** (il rendimento fa il 62%). *A orizzonti corti
+non fai lavorare la strategia, compri il capitale coi bonifici* — al netto ancora di piu'.
+
+---
+
+## (4) Rendita €/g mediana — al netto
+
+Le imposte sono gia' dentro la perpetua (7.70%): il numero e' netto e **non va lordizzato una
+seconda volta**.
+
+| €/mese | 5a | 10a | 15a | 20a | P(€50/g a 20a) |
+|---|---|---|---|---|---|
+| 0 | 0.20 | 0.34 | 0.59 | 1.01 | 0.0% |
+| **250** | 4.38 | 11.82 | 24.61 | **46.61** *(pubbl. 91.30)* | **42.0%** *(pubbl. 90.0%)* |
+| 500 | 8.56 | 23.31 | 48.65 | 92.11 | 97.6% |
+| 800 | 13.58 | 37.08 | 77.47 | 146.78 | 100.0% |
+| 1000 | 16.93 | 46.26 | 96.67 | 183.18 | 100.0% |
+| 2000 | 33.66 | 92.18 | 192.79 | 365.24 | 100.0% |
+
+A 20 anni la rendita di €250/mese si **dimezza** (91.30 → 46.61 €/g) e P(€50/g) passa da **90% a
+42%**. La non-linearita' resta: da 15 a 20 anni la rendita raddoppia a ogni livello.
+
+---
+
+## Cosa cambia e cosa no
+
+**Cambia:** il livello di versamento che il piano dichiarava sufficiente. €250/mese al lordo
+sembrava «P 92%, il piano funziona»; al netto e' 52%, e per tornare a ~90% servono **€371/mese**
+a 20 anni. Il muro si sposta poco (−5%), i **versamenti** si spostano molto (+57% a 20 anni).
+
+**Non cambia:**
+- senza versamenti il capitale-rendita non si raggiunge **mai**, a qualunque lente fiscale;
+- l'ordine di importanza delle leve (versare > quando > quanto presto si smette > piatto vs
+  crescente > frequenza) e' invariato: il fisco colpisce tutte le colonne allo stesso modo;
+- il rischio di venue resta fuori scala rispetto a tutto questo (a p=5% il risultato mediano e'
+  zero comunque).
+
+⚠️ **Assunzioni fiscali dichiarate, NON un parere fiscale** (33%, sensibilita' a 26%, minusvalenze
+in carry 4 anni, patrimoniale 0.2%/anno). Il modello tassa la variazione **annua** di valore =
+**limite superiore** rispetto alla pura realizzazione, stretto perche' TP01 ribilancia ogni giorno
+e SKH01 chiude round-trip discreti.
+
+---
+
+## Regole
+
+1. **Un modello che tassa una meta' del conto e non l'altra non e' conservativo, e' incoerente** —
+   e i due errori possono compensarsi quasi esattamente, il che li rende invisibili finche' non si
+   rifa' il conto in modo simmetrico.
+2. **Un non-arrivo va codificato +∞, mai −1.** Con −1 la mediana *migliora* quanto piu' la colonna
+   peggiora.
+3. **Una mediana condizionata va sempre stampata accanto alla sua probabilita'**, o dice il
+   contrario di quello che sembra.
+4. **Prima di pubblicare un numero nuovo, far riprodurre alla macchina quello vecchio** — qui la
+   colonna LORDA riproduce 4 righe su 4 della tabella pubblicata, ed e' l'unica ragione per cui la
+   colonna NETTA e' leggibile.
+5. **Un Monte Carlo ha una risoluzione, e va detta.** $272.061 e' esatto quanto $269.648: la
+   differenza fra i due e' la taglia del campione, non un'informazione sul piano.

docs/diary/2026-08-19-venue-watch-disciplina-allarmi.md

@@ -0,0 +1,154 @@
+# 2026-08-19 — Quattro 🚨 per una manutenzione annunciata, e cosa c'era dietro
+
+**Richiesta:** *"su Adp_VPS mi sono arrivati questi messaggi"* — quattro allarmi VENUE WATCH del
+18/08, incollati senza domanda. La domanda vera era: e' successo qualcosa di grave?
+
+**No.** Ma il modo in cui l'ho scoperto ha rivelato tre difetti, e uno riguarda gli ordini.
+
+**Toccati:** `src/live/venue_watch.py`, `src/live/deribit.py` (tabella `_CONTRACT` + `check_specs`),
+`scripts/live/venue_watch.py`. **Test:** `tests/test_venue_watch.py` 23 → **35**; suite intera
+**618 verdi**. **Book, pesi, `config/live.json`, THRESHOLD_BPS, PERSIST_HOURS: INVARIATI.**
+
+---
+
+## 0. Cosa era successo davvero
+
+Manutenzione Deribit **annunciata il 14/08 per il 18/08 alle 09:00 UTC**, downtime dichiarato
+**15–30 minuti**. Il book si e' astenuto ai giri delle 09:07 e 10:07 UTC — `conto non leggibile
+(offline) -> stop, non eseguo a cieco` — e alle 11:07 eseguiva di nuovo. **Il sistema ha fatto la
+cosa giusta.**
+
+I 572 minuti di "feed SKH stantio" non erano una deriva nascosta: con la coda 5m non attaccabile
+il book e' ripiegato sul feed certificato, che e' di suo vecchio di ~9,5 ore. Prima (08:07) e dopo
+(11:07) diceva `fresco (0 min)`.
+
+Ma `venue_watch` ha visto la piattaforma bloccata fino alle **14:07 UTC**: la manutenzione ha
+sforato l'annuncio **di ore, non di minuti**. E ha mandato quattro 🚨 identici, **tutti dopo che
+il book aveva gia' ripreso**.
+
+## 1. Perche' quattro messaggi uguali: l'allarme non aveva memoria
+
+Il rilevatore di dislocazione e' tarato con cura — 100 bps, 4 ore a segno costante, «zero falsi
+allarmi in 8 anni», controllo positivo su Bitfinex 2018-19 — e la macchina a stati `step()`
+allerta **una volta per streak** e poi tace.
+
+Accanto, il blocco piattaforma era un `if` secco senza stato:
+
+```python
+if obs["platform_locked"]:
+    report["alerts"].append("Deribit public/status: PIATTAFORMA BLOCCATA (locked=true)")
+```
+
+Nessuna persistenza, nessuna deduplica, nessuna nozione di manutenzione. Un rilevatore disciplinato
+con accanto uno che grida al lupo ogni ora, **e con lo stesso titolo**: *«PRIMO PASSO: prelievo di
+prova»*. Il costo non e' il fastidio: e' che un allarme massimo speso per un evento atteso e'
+un allarme che non verra' letto il giorno che e' vero — l'unico giorno che conta.
+
+Ora il lock passa da `lock_step()`, pura e testata, con gli stessi livelli degli altri stati:
+
+| condizione | esito |
+|---|---|
+| bloccata + manutenzione dichiarata, entro `MAINT_GRACE_HOURS` (2) | ⚠️ **una volta**, «attesa, non allarme» |
+| manutenzione che **sfora** la tolleranza | 🚨 **una volta**, «ha SFORATO 2h» |
+| bloccata **senza** manutenzione dichiarata | 🚨 subito, una volta |
+| rientrata | avviso di rientro, una volta |
+| `public/status` **illeggibile** | **niente**: le ore restano dove sono |
+
+Rigiocando il 18/08: quattro messaggi identici diventano **⚠️ → 🚨 (ha sforato) → rientrato**. Tre
+messaggi che dicono tre cose diverse.
+
+⚠️ L'ultima riga della tabella e' quella che mi premeva: dichiarare «e' rientrato» perche' non si
+e' riusciti a *guardare* sarebbe la bugia peggiore possibile in questo file. `locked is None` non
+azzera niente e non annuncia niente.
+
+⚠️ E la tolleranza non e' un'assoluzione: la manutenzione declassa l'allarme **solo dentro la
+finestra**, e oltre lo **rialza**. Il 18/08 e' la ragione per cui la regola non poteva essere
+«se e' manutenzione, stai zitto»: Deribit aveva annunciato mezz'ora ed e' rimasta bloccata per ore.
+Una manutenzione che dura sei volte l'annuncio **e' di nuovo una notizia.**
+
+## 2. Il messaggio dichiarava un valore che non aveva letto
+
+Il parser accetta qualunque valore diverso da `false`/`none` — Deribit risponde anche `partial` —
+e il testo era cablato: `(locked=true)`. Il runbook al passo 2 manda a controllare *proprio quel
+campo*: mandarci qualcuno con in testa la stringa sbagliata e' peggio che non dirgliela.
+
+Adesso `platform_status()` restituisce il valore grezzo, il messaggio lo stampa e lo **stato lo
+salva**. Del 18/08 non e' piu' ricostruibile quale fosse: nessuno lo registrava.
+
+## 3. Il difetto che poteva costare: le specifiche contratto
+
+Cercando altro, il confronto con gli annunci Deribit ha trovato una cosa che nessun allarme
+sorvegliava. Il 18/08 dopo le 09:00 UTC Deribit ha aggiornato **tick, contract size e minimum
+order size dei perpetual lineari USDC** (annuncio del 14/08). La tabella `_CONTRACT` di
+`deribit.py`, che e' quella con cui si costruiscono gli ordini, era **cablata a mano** e non se
+n'e' accorta:
+
+| | dichiarato | venue dal 18/08 |
+|---|---|---|
+| BTC tick | 0.5 | **0.1** |
+| ETH tick | 0.05 | **0.01** |
+| ETH min/step | 0.001 | **0.0001** |
+
+Nessun ordine e' stato rifiutato, e la ragione **non e' merito nostro**: i cambi erano *riduzioni*,
+e un valore piu' grosso resta conforme. Il costo effettivo era di granularita' — su ETH
+l'incremento minimo restava **$1.92** invece di **$0.19** su un conto da $597 (0,32% contro 0,03%).
+
+⚠️ Il giorno che Deribit **alza** un minimo, la stessa cecita' fa **rifiutare gli ordini**, e non
+c'e' niente che lo dica prima.
+
+**Scelta di disegno: la tabella dichiarata resta l'autorita' per costruire un ordine; il venue
+diventa il controllore, non la fonte.** Prendere i valori dall'API dentro il percorso di
+esecuzione avrebbe reso l'ordine dipendente da come ha risposto una GET — cioe' non ricostruibile
+dopo. Invece `check_specs()` gira **nel venue_watch orario** (sola lettura, fuori dal percorso
+ordini) e confronta; la tabella si aggiorna a mano, di proposito, in git.
+
+Il confronto dichiara la **direzione**, che e' l'unica cosa che serve per decidere se correre:
+
+- `granularita'` — dichiarato piu' grosso: conforme, si perde precisione → ⚠️, si aggiorna con calma;
+- `rifiuto` — dichiarato piu' fine: **il venue rifiuta** → 🚨, si corregge subito.
+
+⚠️ Uno strumento **non letto** non e' una divergenza e non viene contato come «combacia»: finisce
+in `non_letti`. Silenzio e uguaglianza non sono la stessa cosa, e solo una delle due e' rassicurante.
+
+Tabella aggiornata ai valori veri e verificata: `check_specs()` risponde `divergenze: []`,
+`non_letti: []`. Il floor `min_order_usd = $5` del book e' indipendente, quindi lo step piu' fine
+**non** apre la porta a ordini da 19 centesimi.
+
+## 4. Il difetto piu' lento: la referenza non e' piu' indipendente
+
+`venue_watch` misura Deribit contro un consenso di referenze USD. Erano **due**: Coinbase e
+Bitstamp. Ma le comunicazioni del 12–18/08 dicono «Deribit **by Coinbase**», mettono il **Coinbase
+Index** come riferimento per una parte dei perpetual lineari, e instradano lo spot Deribit su
+**Coinbase Exchange**.
+
+Il rilevatore esiste per rispondere a «Deribit sta scollando dal mondo?». Se una delle due
+referenze e' **la casa madre**, uno shock di Coinbase muove Deribit e la referenza *insieme*, e lo
+scarto in bps resta piccolo **proprio nell'ora in cui dovrebbe aprirsi**. Con due referenze, il
+consenso indipendente si riduceva di fatto a Bitstamp.
+
+Aggiunta **Kraken** come terza. BTC ed ETH restano sul Deribit Index (hanno opzioni quotate), quindi
+oggi la contaminazione e' di *proprieta'*, non ancora di *calcolo*: si interviene finche' e' teorica.
+
+⚠️ **Onesta' sulla taratura.** «Zero falsi allarmi in 8 anni» e' stato misurato con l'insieme di
+referenze di allora. `THRESHOLD_BPS` e `PERSIST_HOURS` non sono stati toccati, ma il consenso ora
+si calcola su tre serie invece di due, e **quel numero non e' stato ri-misurato**. Quello che si
+puo' affermare leggendo il codice e' la *direzione*: con tre referenze il consenso e' la **mediana**
+(robusta a un outlier) invece della media di due, e lo spread max-min si allarga → si va piu'
+spesso in **BLIND**, che e' lo stato morbido. Cioe' il modo in cui questa modifica puo' sbagliare
+e' **«allerta di meno»**, non «grida al lupo». Per il numero vero si rilancia
+`scripts/research/r0726_venue_tripwire.py` con la terza serie.
+
+Misurato subito dopo: BTC +3.0 bps, ETH +2.5 bps, **3 referenze**, spread fra referenze 1.5 e 0.7
+bps. Le tre concordano strettamente: nessuna deriva verso BLIND nella pratica.
+
+## 5. Cosa NON e' stato fatto, e resta aperto
+
+- **Il Rulebook del 12/08 non lo sorveglia nessuno.** Introduce ADL e perdita socializzata,
+  *emergency powers in qualifying circumstances*, la disciplina dei conti dormienti, e la
+  precisazione che Deribit ha *«limited administrative authority, rather than direct control»*
+  sugli asset custoditi da terzi. Per un sistema il cui runbook dice «l'azione giusta e'
+  prelevare», questa e' materia di rischio-venue pura — e il watcher guarda solo i prezzi.
+- **La taratura a tre referenze non e' ri-misurata** (vedi §4).
+- **Il verso della finestra di manutenzione e' euristico**: `MAINT_GRACE_HOURS = 2` non legge gli
+  annunci, li **presume**. Un feed degli annunci Deribit renderebbe la tolleranza esatta invece
+  che ragionevole.

docs/diary/2026-08-21-venue-taratura-tre-referenze.md

@@ -0,0 +1,156 @@
+# 2026-08-21 — «Zero falsi allarmi in 8 anni» non descriveva il sistema che gira
+
+**Richiesta:** *"analizza e fai B1 e B2"* — B1: portare in memoria operativa la sessione del 19/08,
+che stava solo nel diario e nel commit. B2: ri-misurare la taratura del tripwire di venue dopo
+l'aggiunta della terza referenza, debito dichiarato quel giorno e mai chiuso.
+
+**Toccati:** `scripts/research/r0821_venue_refs.py` (nuovo), `tests/test_venue_watch.py` (35 → 37),
+`CLAUDE.md`. **Book, pesi, `config/live.json`, `THRESHOLD_BPS`, `PERSIST_HOURS`: INVARIATI.**
+
+---
+
+## 0. Il debito, come era stato dichiarato
+
+Il 19/08 e' stata aggiunta **Kraken** come terza referenza, perche' Coinbase ha comprato Deribit e
+una referenza che e' la casa madre non misura piu' se Deribit scolla dal mondo. Il diario fu onesto
+sul limite: *«"Zero falsi allarmi in 8 anni" e' stato misurato con l'insieme di referenze di allora
+… quel numero non e' stato ri-misurato»*, e dichiarava la sola **direzione** dell'errore — con la
+mediana di tre il consenso e' piu' robusto e lo spread max-min si allarga, quindi si va piu' spesso
+in BLIND, che e' lo stato morbido: il modo di sbagliare e' «allerta di meno».
+
+La direzione era giusta. Ma ri-misurando salta fuori un fatto piu' grosso, che non era nel verso
+previsto perche' non riguardava la modifica del 19/08 **ma la taratura originale**.
+
+## 1. Il fatto che struttura tutto: la profondita' delle referenze
+
+| asset | venue | barre | da | a |
+|---|---|---|---|---|
+| BTC | coinbase | 69.643 | 2018-08-14 | 2026-07-26 |
+| BTC | bitstamp | 69.663 | 2018-08-14 | 2026-07-26 |
+| BTC | **bitfinex** | 33.000 | 2018-08-14 | **2022-05-21** |
+| BTC | **kraken** | **702** | 2026-06-26 | 2026-07-26 |
+| ETH | coinbase | 64.554 | 2019-03-14 | 2026-07-26 |
+| ETH | bitstamp | 64.572 | 2019-03-14 | 2026-07-26 |
+| ETH | **bitfinex** | **0** | — | — |
+| ETH | kraken | 702 | 2026-06-26 | 2026-07-26 |
+
+Il tetto di Kraken e' stato **ri-verificato oggi sulla rete**, non creduto da un commento del 26/07:
+chieste 70.286 ore, ricevute **704** (l'1,00% del richiesto). L'endpoint OHLC pubblico ritorna le
+ultime ~700 candele qualunque `since`.
+
+**Conseguenza: la taratura a 8 anni con Kraken dentro non e' ottenibile.** Non per pigrizia — per
+struttura della fonte. E non e' un problema per il sorvegliante live, a cui servono le ultime ore.
+
+## 2. Il falso allarme che c'era, e che nessuno aveva visto
+
+Frontiera a zero falsi allarmi, per insieme di referenze, punto in produzione (100 bps, 4h):
+
+| insieme | asset | ore utili | non-BLIND | soglia minima a 4h | falsi allarmi a (100, 4h) |
+|---|---|---|---|---|---|
+| **LIVE-pre (CB+BS)** | BTC | 69.633 | 100,0% | **150 bps** | **1** |
+| | ETH | 64.541 | 100,0% | 100 bps | 0 |
+| CALIB (CB+BS+BF) | BTC | **65.043** | 93,4% | 75 bps | **0** |
+| | ETH | 64.541 | 100,0% | 100 bps | 0 |
+| **LIVE-post (CB+BS+KR)** | BTC | 69.633 | 100,0% | **150 bps** | **1** |
+| | ETH | 64.541 | 100,0% | 100 bps | 0 |
+
+Due cose in questa tabella.
+
+**(a) «Zero falsi allarmi in 8 anni» non ha mai descritto la configurazione in produzione.** Quel
+numero viene dalla riga CALIB, che ha `bitfinex` nel consenso — e il sorvegliante live non l'ha mai
+avuta. Il 65.043 e' la firma: e' esattamente il numero di ore che CLAUDE.md cita al punto (1) del
+bullet VENUE WATCH. Sul consenso reale le ore sono 69.633 e i falsi allarmi sono **1**.
+
+**(b) Aggiungere Kraken non lo ripara**, perche' su 8 anni Kraken porta un mese: LIVE-post e
+LIVE-pre danno numeri **identici** sulla storia lunga.
+
+Il falso allarme e':
+
+```
+2020-03-13 07:00 -> 10:00 UTC   4 ore   picco -418,7 bps   segno -1
+```
+
+Il **crash COVID**. Cioe' proprio l'evento che la memoria elencava come esempio di cio' su cui il
+tripwire *non* scattava: *«zero falsi allarmi inclusi crash COVID 2020-03, maggio 2021, LUNA e
+novembre 2022»*.
+
+## 3. Perche' spariva a tre referenze — e perche' non e' una buona notizia
+
+Nella stessa finestra, con `bitfinex` nel consenso, **1 delle 4 ore diventa BLIND** (utilizzabili
+75%) → il run si spezza, non arriva mai a 4 ore consecutive, l'episodio non esiste. Ma la
+dislocazione **e' ancora li'**: mediana **−343 bps** su quelle ore.
+
+⚠️ **Lo zero non veniva da un consenso piu' accurato, veniva da un'ora buttata.** «Zero falsi
+allarmi» puo' voler dire *piu' preciso* oppure *piu' cieco*, e le due si distinguono solo guardando
+la quota di ore utilizzabili — che nella riga CALIB e' 93,4% contro il 100,0% delle altre.
+
+Congelato in due test puri (`tests/test_venue_watch.py`), perche' e' il meccanismo e non il numero
+a essere trasferibile:
+
+- `test_una_terza_referenza_non_puo_aumentare_le_ore_utilizzabili` — lo spread max-min e' monotono
+  nel numero di referenze, quindi «piu' referenze» non e' gratis: sposta verso BLIND;
+- `test_una_sola_ora_BLIND_spezza_lo_streak_e_impedisce_l_allarme` — con un caso di controllo che
+  DEVE scattare, altrimenti il test non proverebbe nulla.
+
+## 4. La direzione dichiarata il 19/08 e' confermata, e la sua TAGLIA dipende dal venue
+
+Confronto **appaiato** (stesse ore, mai due campioni diversi):
+
+| | ore | non-BLIND 2 ref | 3 ref | Δ | \|scarto\| mediano, differenza appaiata |
+|---|---|---|---|---|---|
+| BTC + bitfinex | 33.000 | 99,95% | 86,04% | **−13,91 pp** | −0,04 bps |
+| BTC + kraken | 702 | 100,00% | 100,00% | **+0,00 pp** | −0,04 bps |
+| ETH + kraken | 702 | 100,00% | 100,00% | +0,00 pp | +0,03 bps |
+
+«Piu' referenze → piu' BLIND» e' vero, ma con Bitfinex costa **14 punti** di ore utilizzabili e con
+Kraken **zero**. Non e' una proprieta' del numero tre: e' una proprieta' di **quanto la terza
+referenza e' d'accordo con le altre**. Bitfinex nel 2018-2022 era il venue con i problemi bancari —
+metterlo nel consenso e' metterci dentro il rumore che il controllo positivo usa come *segnale*.
+
+## 5. Controllo positivo: intatto
+
+Bitfinex 2018-19 come bersaglio, consenso Coinbase+Bitstamp: **22 episodi**, il piu' lungo **2.324
+ore**, picco **1.136 bps = 11,4x** la soglia. Il rilevatore vede i casi veri.
+
+## 6. Decisione: la soglia NON si tocca, ma la giustificazione cambia
+
+Il criterio dichiarato in anticipo il 26/07 aveva tre gambe: **(a) zero falsi allarmi in 8 anni**,
+(b) margine ≥3x sul caso storico piu' debole (FTX ~300 bps) → soglia ≤100 bps, (c) minima latenza.
+**La gamba (a) non e' soddisfatta** dalla configurazione reale. Le altre due reggono, e l'economia
+del 26/07 risolve da sola:
+
+- 1 falso allarme in 8 anni = 0,125/anno × 0,248% di costo = **0,031%/anno** di equity attesa,
+  contro il **100%** che un vero positivo evita → break-even a `p > 0,031%`, e ogni `p` plausibile
+  (0,5-5%) e' 16-160 volte sopra;
+- alzare a 150 bps per ripristinare lo zero porterebbe il margine su FTX da **3,0x a 2,0x**, sotto
+  il vincolo (b) dichiarato prima di guardare i dati.
+
+**Quindi (100 bps, 4h) resta**, ma perche' **un falso allarme ogni 8 anni e' economico**, non
+perche' non ce ne siano. E il numero da citare e' **1 in 8 anni** — che e', ironicamente, proprio
+l'esempio che il punto (4) del bullet usava per il break-even: la memoria si contraddiceva da sola
+e la meta' giusta era quella dell'economia.
+
+## 7. Cio' che resta aperto
+
+- **La terza referenza non e' validabile sulla storia.** Kraken e' verificata su un mese e su quel
+  mese non cambia nulla. Se serve una validazione lunga, va cercata una fonte che pagini davvero
+  (il tetto ~700 e' dell'endpoint pubblico, non di ccxt).
+- **Il Rulebook Deribit del 12/08 non lo sorveglia nessuno** (ADL, perdita socializzata, *emergency
+  powers*, conti dormienti) — invariato dal 19/08.
+- **`MAINT_GRACE_HOURS = 2` presume gli annunci invece di leggerli.** Non e' teorico: due
+  `locked=true` in quattro giorni (18/08 ~4h, 21/08 ~1h).
+
+## REGOLE
+
+- **Un numero di taratura va etichettato con la CONFIGURAZIONE su cui e' stato misurato**, non solo
+  con la finestra. «Zero falsi allarmi in 8 anni» era vero e inutile: descriveva un consenso che la
+  produzione non ha mai avuto, e nessun test poteva accorgersene perche' i due percorsi (ricerca e
+  live) tenevano la lista delle referenze in due posti diversi.
+- **Uno "zero" si legge sempre accanto alla quota di campione utilizzabile.** Meno falsi allarmi
+  perche' si vede meglio e meno perche' si vede di meno hanno lo stesso valore stampato e valore
+  opposto.
+- **Quando due affermazioni della stessa memoria si contraddicono** (qui «zero falsi allarmi» e «a
+  1 ogni 8 anni serve p > 0,031%»), la contraddizione e' un'informazione: una delle due e' stata
+  scritta guardando i dati.
+- **Il debito dichiarato il 19/08 era corretto ma sottodimensionato:** diceva «il numero non e'
+  ri-misurato» e il numero era sbagliato **prima** della modifica che lo aveva fatto dichiarare.

docs/diary/2026-08-22-sol-terza-gamba.md

@@ -0,0 +1,141 @@
+# 2026-08-22 — SOL come terza gamba: tutto il guadagno è un anno solo, e quell'anno il dato non è buono
+
+**Richiesta:** dopo *"hai già provato ad analizzare utilizzo di XRP o SOL o UNI?"* — sì, ma sempre
+dentro panieri cross-sectional su Hyperliquid. SOL è l'**unico dei tre eseguibile su Deribit** e
+TP01/SKH01 non erano mai stati misurati su di lui. *"si fai una analisi"*.
+
+**Esito: SCARTATO.** L'ipotesi a priori (*diluisce*) era registrata prima di guardare, ed è confermata.
+
+**Toccati:** `scripts/research/r0822_sol_leg.py` (nuovo), `tests/test_sol_leg.py` (5), `CLAUDE.md`,
+`data/raw/alt_sol_*.parquet` (namespace nuovo). **Book, pesi, `config/live.json`, cron: INVARIATI.**
+
+---
+
+## 0. Il dato, prima della strategia
+
+Storico ricostruito da Deribit mainnet: `SOL/USDC:USDC`, **466.776 barre 5m dal 2022-03-15**,
+0 gap, coerenza resample maxΔ 0.00 bps. Poi certificato — ed è la certificazione a decidere il
+disegno dell'esperimento, non il contrario.
+
+| | med bps vs Coinbase | p95 | max | >1% |
+|---|---|---|---|---|
+| 2022 | 8.1 | 40.1 | **2478.6** | 1.3% |
+| 2023 | 7.6 | 30.0 | 1010.3 | 0.6% |
+| 2024 | 5.9 | 22.7 | 109.4 | 0.0% |
+| 2025 | 4.0 | 14.4 | 269.1 | 0.0% |
+| 2026 | 3.9 | 12.4 | 51.7 | 0.0% |
+
+Conferma esatta del verdetto del 19/06 (*«SOL 🟡 pulito da ~2024; 2022-23 rumoroso»*). Flat a 1h
+**0,2%** (usabile), a 5m **20,8%** con run fino a 177 barre (~15h) — lontano da LTC (82%) ma non
+è BTC/ETH (~0%).
+
+Da qui **due lenti dichiarate prima di misurare**: `L-FULL` (2022-03+, usa gli anni segnalati) e
+`L-PULITA` (2024+, dato buono ma quasi tutto hold-out).
+
+## 1. Le gambe da sole (meccanismi CONGELATI, nessuna ri-ottimizzazione)
+
+| gamba | Sharpe | maxDD | CAGR | Sh hold-out |
+|---|---|---|---|---|
+| TP01 BTC | 1.13 | −16.2% | 15.2% | +0.28 |
+| TP01 ETH | 1.10 | −15.2% | 15.2% | +0.62 |
+| **TP01 SOL** | **0.91** | −12.7% | 9.8% | **−0.24** |
+| SKH01 BTC | 1.28 | −21.4% | 33.6% | +1.49 |
+| SKH01 ETH | 1.05 | −27.4% | 30.9% | +1.49 |
+| **SKH01 SOL** | **0.51** | **−40.5%** | 11.3% | +1.05 |
+
+⚠️ **SKH01-V2-DD su SOL fa 40,5% di drawdown.** La variante «-DD» esiste *perché* fu selezionata,
+nella 2ª ondata del 23/06, sul criterio **maxDD < 30%** (BTC 21%, ETH 27%). Su un asset nuovo il
+criterio stesso per cui la variante è stata scelta **fallisce**. Non è un dettaglio: è la firma di
+un parametro tarato su due asset e presentato come proprietà del meccanismo.
+
+## 2. Il livello che conta: il book
+
+24 ancore, **mediana delle differenze appaiate** (regola 26/07: un Δ eredita la fortuna d'ancora).
+
+| | L-FULL (2022-03+) | L-PULITA (2024+) |
+|---|---|---|
+| dSharpe FULL | **+0.094** (>0 in **24/24**) | **−0.099** (>0 in **0/24**) |
+| dSharpe hold-out | **−0.166** (>0 in **0/24**) | **−0.166** (>0 in **0/24**) |
+| DD più basso di | +1.435 pp (24/24) | +1.470 pp (24/24) |
+| d CAGR | +0.105 pp (58%) | **−1.339 pp** (0/24) |
+
+All'ancora canonica: 2 gambe Sh 1.44 / DD −9.4% / CAGR 14.7% → 3 gambe Sh 1.48 / DD −7.5% /
+CAGR 13.6% su L-FULL; su L-PULITA 1.54 → **1.30**.
+
+## 3. Il drawdown scende — ma è de-levering (5ª occorrenza)
+
+Aggiungere SOL abbassa DD **e** CAGR insieme. Il null codificato chiede: *lo stesso DD si compra
+più a buon mercato riducendo la size?* Si cerca `k` con `maxDD(k·book_2gambe) = maxDD(book_3gambe)`:
+
+| lente | k | Sh 3 gambe | Sh 2 gambe × k | CAGR 3g | CAGR 2g × k | verdetto |
+|---|---|---|---|---|---|---|
+| L-FULL | 0.793 | 1.48 | 1.44 | 13.6% | 11.5% | SOL aggiunge |
+| **L-PULITA** | 0.886 | **1.30** | **1.54** | 12.6% | 14.5% | **de-levering** |
+
+**L'unica lente in cui SOL aggiunge è quella costruita sui dati che la certificazione segnala.**
+
+## 4. E dentro quella lente, il guadagno è un anno
+
+| anno | 2g Sh | 3g Sh | dSh | dCAGR |
+|---|---|---|---|---|
+| 2022 | 1.37 | 0.46 | **−0.91** | −6.0 pp |
+| **2023** | 1.34 | 2.40 | **+1.06** | **+11.1 pp** |
+| 2024 | 1.65 | 1.36 | −0.29 | −5.6 pp |
+| 2025 | 1.00 | 0.80 | −0.20 | −2.7 pp |
+| 2026 | 2.70 | 2.48 | −0.22 | −2.9 pp |
+
+Gamba SOL da sola: 2022 **−1.99** · 2023 **+2.65** · 2024 +0.45 · 2025 +0.17 · 2026 +1.46.
+
+**4 anni su 5 negativi.** Il 2023 è l'anno in cui SOL risalì da ~$8 a ~$100 dopo il crollo FTX: un
+trend-follower su quel movimento guadagna una fortuna **una volta sola**. Non è un meccanismo che
+trasferisce, è un evento.
+
+E la correlazione col book attuale è **+0.404** (L-FULL) e **+0.561** (L-PULITA) — vicina allo
+0.74 per cui il trend multi-asset fu scartato il 19/06, **e in salita** man mano che il dato
+migliora.
+
+## 5. Ciò che non è il vincolo
+
+**L'eseguibilità non c'entra:** `SOL_USDC-PERPETUAL` ha min 0.001 SOL = **$0.09**, contro il
+pavimento `min_order` di $5 del book. SOL sarebbe tradabile oggi a $644. È la prima volta in questo
+progetto che un candidato viene bocciato **senza** che il muro sia la taglia del conto.
+
+## 6. ⚠️ Effetto collaterale del mio stesso lavoro: un guardrail disattivato in silenzio
+
+CLAUDE.md dichiara: *«`load_data("SOL", ...)` → FileNotFoundError (guardrail: solo dati certi)»*.
+**Non è codice.** `load_data` non ha alcuna whitelist: solleva l'eccezione solo perché il file non
+esiste. Ricostruendo lo storico in `data/raw/sol_1h.parquet` **ho disattivato il guardrail senza
+che nulla lo segnalasse** — e quel file non sarebbe stato rinfrescato dal cron (`--asset BTC ETH`),
+quindi sarebbe diventato dato stantio con l'aspetto di dato attivo.
+
+È la stessa forma dei tre difetti dei giorni scorsi: un controllo che funziona per configurazione,
+non per costruzione.
+
+**Riparato con la convenzione che il progetto già usa** (`hl_`, `eq_`, `eqx_`, `fut_`): SOL vive in
+`data/raw/alt_sol_*.parquet`, fuori dal namespace nudo. Guardrail verificato ripristinato.
+
+⚠️ **Errore mio nel test che doveva sorvegliarlo:** la prima stesura elencava a mano i prefissi
+leciti e bocciava `eqx_`, `fut_`, `vol_term_`, `fundnews_` — namespace veri che non conoscevo.
+Riscritto per **derivare** gli asset a rischio da `rebuild_history.DERIBIT_INSTR`: l'invariante non
+è «quali prefissi esistono» (lista che invecchia) ma «quali asset possono finire nel namespace
+nudo», che sta nel codice. Stessa lezione di `fee_watch` il giorno prima.
+
+## VERDETTO
+
+**SOL come terza gamba direzionale: SCARTATO.** Hold-out negativo a 24/24 ancore in entrambe le
+lenti; sulla finestra pulita peggiora tutto; il DD migliore è de-levering; il guadagno della
+finestra sporca è un anno solo; la correlazione col book sale col migliorare del dato. **Book,
+pesi, universo direzionale invariati.**
+
+## REGOLE
+
+- **Un meccanismo si trasferisce a un asset nuovo con i parametri CONGELATI, o non è un
+  trasferimento ma una nuova famiglia** — e allora servono `study_family_honest` e deflated-Sharpe.
+- **Un criterio di selezione va riprovato sull'asset nuovo:** SKH01-V2-DD fu scelta per maxDD<30%
+  e su SOL fa 40,5%. Il criterio era una proprietà dei due asset su cui fu tarato, non del sistema.
+- **Quando un risultato dipende dalla finestra, guardare quale finestra la CERTIFICAZIONE
+  approva** — qui le due si contraddicono e la lente che promuove è quella non certificabile.
+- **Un contributo positivo si scompone per anno prima di crederci:** +0.094 di Sharpe mediano
+  sembra un plateau (24/24 ancore) ed è un anno solo con quattro anni negativi intorno.
+- **Ricostruire dati per un'analisi può disattivare un guardrail** che vive nell'assenza di un
+  file. Prima di scaricare un asset fuori universo, chiedersi in quale namespace atterra.

docs/diary/2026-08-22-wave-multiagente.md

@@ -0,0 +1,152 @@
+# Ondata multi-agente 2026-08-22 — 20 filoni, branch `research/wave-0822`
+
+**Mandato dell'operatore:** *"metti decine di agenti a fare analisi di nuove strategie possibili.
+Lavora su branch separato. Lo scopo e' sempre lo stesso arrivare ai 50 giornalieri velocemente."*
+
+**Esito in una riga: 0 candidati promossi, 1 difetto di produzione che avrebbe falsato un gate fra
+36 giorni, 3 soglie pubblicate falsificate, 1 leva strutturale che nessun gate del progetto sa
+vedere. Book, pesi, cron, config INVARIATI.**
+
+Ledger completo per filone: `docs/research/RESULTS-0822.md`. Briefing dato agli agenti:
+`docs/research/BRIEF-0822.md`. 21 script in `scripts/research/r0822_*.py` (15.295 righe, compilano
+tutti, ognuno gira da solo).
+
+## 0. Come e' stata condotta (e perche' conta)
+
+Vincolo di macchina: **2 core**, 7 GB, e sulla stessa VPS gira il libro con **soldi veri**
+(`cron_book` al minuto :07). Il briefing imponeva `nice -n 19`, budget 15 min/run, sola lettura su
+`config/`, `data/live/`, `src/live/`, `scripts/live/`, cron. **Ha tenuto**: al picco di carico
+(load 14 su 2 core) il giro delle 17:07 del libro e' girato in **18 secondi**, feed fresco, nessuna
+azione, nessun OOM.
+⚠️ **Fatto operativo da ricordare: il cron gira dal working tree.** Con questo branch attivo,
+stanotte alle 00:30 il cron esegue il codice di QUESTO branch. Verificato che il diff vs `main`
+tocca **solo** `scripts/research/` e `docs/research/` -> produzione identica. **E' anche il motivo
+per cui nessuna riparazione e' stata applicata qui: sarebbe andata live senza una decisione.**
+
+Il briefing dava agli agenti, **in anticipo**, i dieci modi in cui questo progetto si e' gia'
+ingannato (null del de-levering, TP01 travestito, selezione sull'hold-out, fortuna d'ancora, Sharpe
+implausibile, win-rate come knob, ...) e la lista dei filoni morti. **Sette agenti hanno catturato
+un errore proprio prima di pubblicare**, e tre hanno refutato una propria ipotesi in corsa.
+
+## 1. Il risultato che va agito — 4 monitor forward su 6 sono rotti
+
+`fetch_hyperliquid` (e `resample_tf`) scrivono la barra del **giorno in corso**; `advance()` dei
+monitor la consuma e **porta `last_ts` su di essa** -> le ore restanti di ogni giorno non entrano in
+nessun rendimento registrato.
+
+| monitor | barre coincidenti col replay | **min/giorno registrati** | gate |
+|---|---|---|---|
+| `paper_statarb` | **0/46** | **4** | **STATARB 27/09** |
+| `paper_dvolspread` | 0/28 | **2** | DVOLSPREAD 24/10 |
+| `paper_xsr` | 1/28 | **41** | XSR01 23/10 |
+| `paper_portfolio` | 7/56 | 19 | — |
+| `paper_prevday` | 1259/1319 | 1.438 | — |
+| `paper_combo` | 7/37 | 1.402 | — (sano **per caso**: aspetta una borsa) |
+
+**Il gate STATARB del 27/09 si ribalta su 2 criteri su 3**: Sharpe registrato **+1,96** contro
+**−2,02** ricostruito, maxDD **2,2% contro 15,3%** (guardia <10%).
+✅ **Ma la finestra non va persa**, ed e' misurato due volte in modo indipendente: il feed **non
+riscrive le barre chiuse** (`paper_prevday` 1427/1488 barre identiche al bit dopo 62 notti; e le 6
+barre di `paper_statarb` recuperate dopo il guasto EPERM del 09-15/07 coincidono al bit).
+**-> La riparazione e' "riparare `advance()` + RIGENERARE", non "riparare e azzerare": nessuna data
+di gate si sposta.**
+**Guardia raccomandata** (non implementata): `ts_ultima_barra + cadenza <= mtime del file`, grazia
+5 min. O(1), segnala 5/6, **tace sul sano**, controllo positivo sintetico 6/6 nei due versi.
+⚠️ `monitor_health` non poteva vederlo: **una serie fresca, completa e sbagliata passa ogni controllo
+di freschezza**. E `implausible_sharpe` esiste dal 26/07 ma **non e' mai stato puntato sulle serie
+forward** (avrebbe segnalato Sharpe −15,8 su 28 barre).
+
+## 2. Tre soglie pubblicate, falsificate con misure
+
+1. **"XS01 serve ~$20k"** -> **non esiste soglia da min-order**. L'origine del numero era *"rumore di
+   arrotondamento"*, una stima a occhio del 19/06. Haircut ~0 gia' a **$200-600 allocati**.
+   **Meccanismo**: gli ordini sono **due popolazioni** — il ribilanciamento del segnale e' il 13%
+   degli ordini ma il **75% del nozionale** (ticket $13,65, passa sempre); la deriva del vol-target
+   e' l'87% degli ordini ma il **25% del nozionale** (ticket $0,64, il pavimento la taglia **ed e'
+   gratis**). *Contare gli ordini da' 16% e sembra un disastro; contare il nozionale da' 75%.*
+   Due agenti indipendenti ci sono arrivati per strade diverse.
+   ⚠️ **Il "$20k di XS01" e il "$20k della decisione di venue" erano due cose diverse conflate in
+   CLAUDE.md.** Il primo cade; **il secondo regge intatto** — e' una decisione dell'operatore
+   sull'asse della rovina, non sull'eseguibilita'.
+2. **"Slippage = rischio #1 di XSR01"** -> **refutato con margine 21x** al livello di liquidita'
+   odierno (mezzo-spread 0,7-1,0 bps contro i ~16 che servirebbero a uccidere l'edge).
+3. **"BTC opzioni fuori a $3.000 (min 0.1 = $6.210/lotto)"** -> misurato sulla famiglia **inverse**,
+   che il conto (in USDC) **non puo' marginare**. La famiglia USDC-lineare ha lotti **10x piu'
+   piccoli**. Il muro resta, ma per il **prezzo del lotto**, non per quello che si credeva.
+
+## 3. La leva: l'unica variabile che nessun gate del progetto sa vedere
+
+**Lo Sharpe e' invariante alla scala** (misurato: 1,31 a ogni cella del knob) -> `deflated_sharpe` e
+`marginal_vs_tp01` non falliscono sulla leva, **non la vedono**. E' per questo che in due mesi la
+scala non e' mai stata esaminata.
+Il libro gira al **7% di Kelly** e raccoglie il **15%** della crescita massima in log. Il gradino
+eseguibile 1,00x -> 1,25-1,50x vale **14,7 anni -> 12,9-11,6** al capitale-rendita (€500/mese, netto
+fisco). **Lo scettico ha confermato il risultato di testa** e ha tolto la sua condizione bloccante:
+sotto la lente wick accoppiata il maxDD prende un **ricarico moltiplicativo costante del ~3,5%**, non
+un'amplificazione (il maxDD e' multi-giorno, il wick e' di un giorno).
+**Il gradino resta NON autorizzato**: cadono una riserva su tre. Restano il drift stimato su 7,4 anni
+(k* e' lineare nel suo errore) e la **coda assente dal dataset** — un solo giorno a −10% all'anno
+porta k* da ~10x a **2x**.
+📌 **Ma la lezione del 25/07 e' vera e non si trasferisce:** su una regola a **UN giorno**
+(daily-loss, stop di conto) close-only e' **esattamente cieca** — 0,00 breach/anno contro 0,40-1,21
+veri, rapporto **INF**. **Sul canale prop/funded la lente accoppiata resta obbligatoria.**
+
+## 4. Cosa e' morto, e come
+
+**Filoni chiusi con autopsia** (l'elenco per esteso e' nel ledger): adaptive-horizon (il "vincitore
+adattivo" e' un lookback **costante** travestito), dealer-gamma (la gamba tradeable e' **incoerente**:
+BTC non separa, ETH separa **al rovescio**), ortho-screen **7/7**, oi-pin (il max-pain **non batte
+mai** la media a 7 giorni dello spot), term-structure (la pendenza e' un **termometro contemporaneo**),
+skew direzionale (**il prezzo muove lo skew**, t 3,1-9,4 su 8/8 — non il contrario), flow-squeeze,
+basis-calendar (il basis dei datati **E'** il funding del perp), alt-options (alt), xs-lite,
+vrp-quote-vere.
+
+Tre chiusure di famiglia che valgono per le prossime ondate:
+- **Il filone funding si chiude sul QUARTO lato** (affollamento): misurato su **53.430 ore / 3 anni**,
+  non predice ne' direzione ne' volatilita'. E i futures datati non sono un quinto lato: sono lo
+  stesso lato quotato diversamente (+7,33% implicito contro +6,48% realizzato, premio incassabile
+  +0,85%/anno con **IC95 che contiene lo zero**).
+- **La mean-reversion non risorge** sotto due conditioner mai provati (volume, shock 3σ): la selezione
+  in-sample sceglie il ramo di **continuazione** in entrambi i casi.
+- 📌 **Uno screen largo su BTC/ETH direzionale NON PUO' passare il proprio gate.** Su 168 trial il
+  massimo Sharpe atteso dal **puro rumore** e' **1,572**, sopra il soffitto direzionale misurato
+  (~1,3). Non e' sfortuna, e' aritmetica. **Le prossime ondate o dichiarano famiglie molto piu'
+  piccole in anticipo, o cambiano meccanismo.**
+
+⚠️ **Tre volte in questa ondata l'eseguibilita' a $600 NON e' stata il vincolo** (haircut 0,00-0,01;
+lotti $7-242; margine ~$148). Dopo due mesi in cui il muro era sempre il capitale, adesso muoiono
+tutti sull'edge. **E' un'informazione sul dove cercare.**
+
+## 5. Regole nuove, e una ritirata
+
+**Nuove:**
+- **L'open interest non misura la negoziabilita'** — su Deribit USDC sono quasi **anti-correlati
+  (rho di rango −0,77)**: SOL_USDC e' 1ª per OI e ultima per quote a due lati (**9%**); BTC_USDC ha
+  **5** strumenti con OI>=100 e il **93%** dei put quotati.
+- **Il deflated-Sharpe va calcolato DI SCREEN, non solo di famiglia** (168 trial, non 24).
+- **Un placebo si controlla per BILANCIAMENTO DEL SEGNO prima di usarlo**: un null che concorda col
+  segnale solo nel 14% dei casi non e' un null, e' la strategia invertita — e fabbrica celle
+  "significative".
+- **Il null del de-levering e' DEGENERE quando la variante e' una ri-scalatura** (`sh(k*base) ===
+  sh(base)`): il test che serve e' **iso-peso sullo Sharpe**.
+- **Un gate che stampa `None` va verificato prima di dichiararlo "non girato".**
+- **Su una finestra interamente post-hold-out, `marginal_vs_tp01` non puo' dare ADDS per
+  costruzione** — un NEUTRAL li' non e' un giudizio.
+
+**Ritirata (era stata pubblicata poche ore prima, in questa stessa ondata):**
+❌ *"Su equity a gradino un overlay giornaliero e' non-causale"* — **falso su questo motore**:
+`backtest_signals` contabilizza al giorno d'**ingresso** in **291/293** trade, e la "riparazione" e'
+un **no-op bit-exact**. Il "+0,04 fantasma" era la differenza fra due varianti **entrambe causali**,
+e quella scartata era la **migliore sull'hold-out**. *Il costo di una regola derivata da un difetto
+inesistente e' gia' stato pagato.*
+
+## 6. Cio' che resta aperto (decisioni dell'operatore, non mie)
+
+1. **Riparare `advance()` + rigenerare** le serie forward, prima del 27/09.
+2. **Cablare la guardia D2** (`ts_ultima_barra + cadenza <= mtime`) in `monitor_health`.
+3. **Il collettore della catena** raccoglie la famiglia inverse; ETH_USDC costa **+587 chiamate/giro
+   (+90%)** ed e' una decisione sul rate limit per-IP, che il 29/07 e' gia' costata un guasto.
+4. **Rimisurare `f` di VRP01 term-structure-consistent** (il 42% del difetto e' li', e la regola per
+   prenderlo era gia' scritta il 03/07).
+5. **XS01 e' eseguibile a ~$1.300 di conto**, non a $20k. Resta fuori **per la decisione di venue**,
+   che e' un'altra cosa. Se il piano cambia, si riapre prima.

docs/diary/2026-08-22-wave2-xs01-funded.md

@@ -0,0 +1,188 @@
+# 2026-08-22 (sera) — Seconda ondata: XS01 fuori dalla sua finestra, e il canale funded ridimensionato di 5x
+
+**Branch:** `research/wave-0822` · **9 filoni** · **0 candidati promossi** · **libro, pesi, cron,
+config INVARIATI.**
+
+Registro per filone: `docs/research/RESULTS-0822.md` (sezioni 21-29). Briefing: `BRIEF-0822.md`.
+
+---
+
+## Perche' una seconda ondata
+
+La prima (20 filoni) si era chiusa con un risultato di testa — **PROP-ALLOC**: su un conto *funded*
+riallocare per la **barriera di drawdown** invece che per lo Sharpe porta J da 0,335 a 0,738, con
+**P(≥50 €/g) da €600 in 36 mesi = 42%**. Il percorso piu' veloce mai misurato in questo progetto.
+
+E si era chiusa con l'agente che dichiarava contro se stesso il proprio limite: *"tutto il vantaggio
+poggia sul drift di XS01 misurato sulla sua finestra di scoperta"*, con un gate che era **un'attesa di
+anni** (*"non aprire un funded prima che XS01 abbia una finestra fuori dal 2024-2026"*).
+
+La seconda ondata e' stata mirata su quello, piu' sui falsificatori che gli agenti stessi avevano
+**nominato senza poterli eseguire**.
+
+---
+
+## 1. XS01 regge fuori dalla sua finestra — ed e' piu' forte li' (§21)
+
+La finestra esisteva gia': gli stessi 19 ticker su **Binance spot 2021-01 → 2023-12**, che contiene
+**LUNA e FTX**. Meccanismo **congelato**, nessuna griglia cercata.
+
+**Mediana di fase +1,12 fuori campione contro +0,37 nella finestra di scoperta; differenza appaiata
++0,668, positiva in 10/10 fasi**, p=0,013 contro permutazione a fee zero, sopravvive a 30 bps/lato.
+
+L'obiezione ovvia — *"Binance non e' la verita'"* — e' stata **misurata invece che aggirata**: quella
+regola riguarda l'**ancoraggio di prezzo**, non un ranking cross-sezionale, e lo scarto USDT e' un
+**fattore comune** che sparisce nello z-score. Lo stesso sleeve sui due venue da' **corr 0,9991**.
+
+**Null "universo dove non dovrebbe funzionare"** (11 settoriali SPDR, 1998+, meccanismo congelato):
+**−0,45, 0/10 fasi positive** → **terza conferma indipendente che il cross-sectional e'
+crypto-specifico**.
+
+## 2. Il falsificatore che l'autore ha nominato contro se stesso — eseguito, e non falsifica (§28)
+
+La validazione di venue di §21 girava **solo sul 2024+**, cioe' senza il depeg USDT che il fuori
+campione contiene. Soglia dichiarata da lui: `corr ≥ 0,99`.
+
+**Corr mediana 0,9992, minima 0,9921. dSharpe appaiato −0,000. Il titolo passa da +1,12 a +1,11.**
+Guardando il canale del danno — i ribilanciamenti — su 734 solo **10 cambiano una gamba su cinque**, e
+**zero dentro la finestra del depeg**.
+
+**Il punto di metodo:** la divergenza va **scomposta**, perche' le due componenti sono domande diverse.
+La **comune** arriva a −39 bps nel depeg ed e' quella che lo z-score annulla; la **idiosincratica** —
+l'unica che cambia il ranking — sale solo da 2,0 a 3,6 bps mediani. *Riportare solo la prima avrebbe
+dato la risposta rassicurante e sbagliata.*
+
+E ha trovato che **il caso peggiore del campione non e' il depeg: e' il 2025-10-10** (cascata di
+liquidazioni sulle /USDT, INJ a 1.981 bps mentre BTC/ETH stanno a 21). **Il meccanismo temuto e'
+REALE**; e' semplicemente caduto nella finestra di *scoperta*, non nel fuori campione.
+
+## 3. Ma il numero funded si ridimensiona di 5x — e il colpevole non e' la finestra (§29)
+
+Decomposizione a **un grado di liberta' per volta**:
+
+| passo | J | Δ |
+|---|---|---|
+| il pubblicato (HL, 19 gambe, finestra di scoperta) | 0,739 | — |
+| → venue Binance, **date allineate** | 0,732 | **−0,006** |
+| → **13 gambe** | 0,426 | **−0,307** |
+| → pannello lungo | 0,459 | +0,034 |
+| → **fuori campione 2021-2023** | 0,520 | **+0,061** |
+
+**Il 42% del numero pubblicato sta nelle 6 gambe che fuori campione non esistono** (ARB OP SUI APT SEI
+TIA) — **e quelle 6 entrarono nell'universo nel 2026-06 guardando la liquidita' HL del 2024+, cioe'
+dentro la finestra di scoperta.** La finestra, da sola, **migliora**. Allargare l'universo man mano
+che le gambe nascono non recupera nulla.
+
+**Il numero operativo: P(≥50 €/g) da €600 in 36 mesi = 7,8% [7,2–9,1%], P(zero) 25,5%** — contro il
+42% pubblicato stamattina. Il peso 0,50 non sopravvive; la **regione [25%, 38%] e' entro il 3%
+dell'ottimo su tutte e tre le finestre**.
+
+**`GATE PROP-01`** sostituisce l'attesa di anni: **(a)** leggere il **listino della firm** — ≥10 delle
+13 gambe shortabili, verifica a **€0** e **bloccante prima di ogni spesa**, *stessa classe
+dell'errore GTAA01/PRIIPs*; **(b)** banda d'ancora di SKH01 sotto la lente prop, **2026-10-31**, PASS
+se > +0,05; **(c)** un'eval HYRO $100k costa **$579 su un conto di $635**.
+
+## 4. L'allarme sul peso di TP01 e' falsificato NEL VERSO (§26)
+
+L'agente aveva registrato nel docstring, **prima di misurare**, che si aspettava di confermarlo.
+Invece: **TP01 ~0,375 e' l'argmax sia sulla finestra che contiene il 2022 sia su quella che non lo
+contiene**, e nel sinistro il libro con **meno** TP01 fa **meglio** — TP01 va flat mentre **SKH01 si
+gira short e guadagna**. Test dei segni 12/12 (p=0,0005), 8/8 sul solo pre-2024.
+
+**Null del de-levering, 7a occorrenza, in veste nuova** ("protezione dal crash"): a leva comune TP01
+protegge davvero, ma **a iso-sopravvivenza meno TP01 paga di piu'** (payout $4.490 → $2.119,
+monotono).
+
+Tre cose che valgono piu' dell'allarme rimosso:
+- **"2024-2026 non contiene un crash" e' falsa nella forma**: ha buy&hold a −60% di DD. Manca la
+  **taglia** (~2,3x sulla coda). La domanda giusta e' *"e se ne arriva uno due volte piu' grande"*.
+- **Alle leve funded il 2022 non era una minaccia** (min equity −1,4/−2,4% contro barriera −6%): cio'
+  che uccide un conto a barriera e' la **regola a un giorno su una giornata qualunque**.
+- **Il rischio vero dell'ottimo e' XS01, non TP01** — e l'agente ha demolito la propria ipotesi
+  contraria dentro la sessione.
+
+## 5. Tre filoni chiusi con margine
+
+**BOCPD (§23) — l'orizzonte adattivo e' CHIUSO DEFINITIVAMENTE.** Il falsificatore e' stato eseguito
+con i rilevatori che nominava (Adams & MacKay + optimal partitioning causale) e **questa volta ha
+avuto potenza**: 68/96 celle davvero adattive, contro 0 del primo tentativo. Con potenza, **0/68** su
+entrambe le condizioni. **La decomposizione e' il risultato: l'adattivita' spiega il −7% del vantaggio
+su TP01** (+0,326 del miglior lookback costante contro +0,305 dell'adattivo). *Il 100% e' "un
+orizzonte piu' corto", non "adattarlo".*
+
+**MAKER (§22) — il segno dipende da `<` contro `<=`.** Il passivo **vince sul 92-98% degli ordini e
+perde sulla media** (5 ordini su 1535 fanno il 42% del danno). Forma speculare del profit-take di
+VRP01. Tetto **$2,96/anno a $635** nel caso impossibile.
+
+**SURFACE-RV (§27) — chiuso, e il meccanismo vale piu' del verdetto.** Censimento su 1,24 M quote:
+**0 violazioni di monotonia su 1,1 M**, 1 di convessita' su 1,03 M che vale **$0,00**. E `|residuo|`
+cresce **monotonamente col largo del mercato** → **l'incoerenza al mid *e'* la larghezza del mercato
+guardata attraverso il mid.** Questo uccide il controfattuale USDC che l'agente stesso aveva
+costruito.
+
+## 6. BIN-FREQ: la direzione e' reale, la taglia e' selezione (§25)
+
+Argmax **+0,112 in 23/23 ancore**, ma **mediana di famiglia +0,007** con 39/72 celle positive =
+monetina. **L'argmax vale 16x la mediana: punta, non plateau.** Direzione solidissima (0/72 sul segno
+inverso, trasferisce a SKH01_V1).
+
+**Due premesse del mio briefing, misurate e refutate:** *"dimezza gli ordini"* → i nettati calano del
+**17%** e i sotto-min-order **sono di TP01**; *"converti il risparmio di fee"* → **a fee zero
+l'effetto resta l'87-110%**, quindi non e' risparmio di costo ma informazione sul rendimento lordo.
+E la domanda che avevo posto era **il confronto sbagliato** (la banda del livello si cancella in un
+disegno appaiato) — **ma la risposta corretta e' peggiore, non migliore, per il candidato**.
+
+Riapertura pre-registrata: **non una data, una soglia di CAPITALE** ($5.600 / $53.000), perche' cio'
+che fallisce e' il rapporto fra un costo **fisso** e un beneficio **proporzionale**.
+
+## 7. Il critico: i difetti stanno nella CUCITURA, non nei filoni (§24)
+
+**Una regola mia, pubblicata la sera stessa e ritirata poche ore dopo:** avevo scritto che
+`dealer_net_gamma` e' *"il GEX col segno invertito"*. **Falso**, e la fonte gira su questa stessa VPS
+(`cerbero-mcp/.../common/options.py:11-14` **dichiara la convenzione**). Verificato in due comandi.
+La correlazione a −0,95 era esattamente cio' che una convenzione diversa **deve** produrre.
+
+**E il difetto piu' grande dell'ondata: il deflated-Sharpe misurato ai suoi due estremi degeneri lo
+stesso giorno da agenti che non si citano** — e **tre gate pre-registrati** ci poggiano sopra.
+
+---
+
+## Il filo che tiene insieme la giornata: `deflated_sharpe` non ha una regione utile in mezzo
+
+**Tre agenti indipendenti, tre strade diverse, stessa conclusione.**
+
+`altlib.deflated_sharpe` calcola `sr0 = sd(Sharpe dei trial) × mult(N)`: dipende dalla **varianza**
+della griglia, non solo da N.
+
+- **VOL-SIZE** (ondata 1) lo dichiara **VACUO**: 1,000 anche per il baseline.
+- **BOCPD** lo misura dall'altro capo: **0,998 PASS** dentro la famiglia omogenea → **0,555 FAIL** con
+  l'sr0 di screen. *"Gonfiare N col padding alza N e non la varianza."*
+- **CRITICO** trova che l'1,572 di ORTHO-SCREEN implica sd≈0,58, e che **le stesse 168 celle
+  dichiarate come 7 famiglie da 24 danno 1,15** — sotto il soffitto ~1,3: il verdetto *"impossibile
+  per aritmetica"* **si ribalta senza toccare un dato**, e la cura che suggerisce e' la manovra che il
+  progetto ha proibito il 30/07.
+- **BIN-FREQ** chiude il cerchio dall'alto: su una famiglia **binaria** il DSR **riacquista potenza**
+  (0,977 contro baseline 0,834) perche' le celle scartano insiemi di trade molto diversi. *Non e' il
+  candidato a essere piu' solido: e' la famiglia a essere piu' larga.*
+
+**Non basta contare i trial di screen: serve la VARIANZA di screen.** E il numero di trial dichiarati
+resta una scelta dell'autore, cioe' l'unico posto dove barare e' indolore e invisibile — con in piu'
+il fatto che ora sappiamo che **la stessa griglia da' verdetti opposti a seconda di come la si
+partiziona**.
+
+---
+
+## Cosa NON e' stato fatto, e perche'
+
+**Nessuna riparazione applicata.** Il cron esegue dalla **working tree**, che e' su questo branch: una
+riparazione andrebbe live alle 00:30 senza una decisione dell'operatore. Il diff tocca **solo**
+`scripts/research/`, `docs/` e `CLAUDE.md` (verificato).
+
+Restano dell'operatore: **(1)** riparare `advance()` + rigenerare i monitor forward prima del gate
+STATARB del **27/09**; **(2)** decidere del branch; **(3)** la verifica a costo zero che decide il
+canale funded — **leggere il listino di una prop firm**.
+
+📌 **E la risposta onesta al mandato, che al critico era stato chiesto di dare se vera: nessuna misura
+di ricerca di questa giornata batte "versare".** L'effetto piu' grande misurato oggi vale
+**€0,0113/giorno**; versare €500/mese vale **~1456x** quello. La ricerca ha smesso di essere il
+vincolo binding il 26/07, e due ondate da 29 filoni lo hanno **confermato invece che ribaltarlo**.

docs/diary/2026-08-23-libro-di-bordo.md

@@ -0,0 +1,96 @@
+# 2026-08-23 — Libro di bordo: i trade allineati col tempo, il giornale, l'analista
+
+**Libro, pesi, cron di strategia, config: INVARIATI. Nessun ordine.** Tutto ciò che segue è
+sorveglianza e registrazione.
+
+## La domanda che l'ha fatto nascere
+
+*«I trade vengono salvati?»* — sì, in `data/live/book_executions.jsonl`. Ma non allineati col
+tempo: `book_execute.py:213` scriveva
+
+```python
+ts_utc = str(pd.Timestamp(r['last_data']))    # la data della BARRA DI SEGNALE
+```
+
+19 righe su 19 a `00:00:00`. E non era cosmetico: **un trade risultava registrato sei giorni prima
+di essere eseguito** — ETH 0.04 @ 1.869,74, fill vero il **2026-07-14 alle 14:00**, scritto
+**08/07**. La riconciliazione lo isola da sola: 18 fill concordano fra log e jsonl, 1 no, ed è
+quello.
+
+L'ora vera esisteva **solo** in `logs/cron_book.log` — gitignored, fuori dal backup, ruotabile.
+La cronologia reale del libro live viveva in un file che una rotazione avrebbe cancellato senza
+che nessuno se ne accorgesse.
+
+## Cosa c'è adesso
+
+**`data/live/trades.db`** (sqlite, dentro il perimetro del backup rotativo). `fills` con il
+contesto del segnale a quel giro, `roundtrips` **derivati** e ricalcolati da zero, `equity`
+oraria (1.437 letture), `journal`. Sync orario in `cron_book`, subito dopo l'esecuzione.
+
+Tre fonti che **si incrociano e non si sovrascrivono**: il cron log (ora vera + contesto), il
+jsonl (i fill), il venue (autorevole su `order_id` ma **tronca**: 1 trade su BTC, 0 su ETH).
+`reconcile()` riporta le divergenze e non ripara niente da solo.
+
+**`docs/journal/YYYY-MM-DD.md`**, 62 voci ricostruite dall'arming. Quattro livelli separati per
+provenienza, e la separazione è il prodotto:
+
+| livello | chi scrive | può sbagliare? |
+|---|---|---|
+| numeri | feed certificato + DB | è una misura |
+| Lettura | 12 regole dichiarate, ognuna con id | deterministica |
+| Analisi | un modello (`claude-opus-5`) | **sì**, ed è firmata |
+| Nota | l'operatore | — |
+
+L'analisi parte ogni giorno su Telegram con una testata di numeri; se manca, il messaggio parte
+lo stesso **dicendo perché**.
+
+## Cosa ha trovato il lavoro, oltre al difetto iniziale
+
+**P&L del libro dall'arming: +$37,50 su $598,06 (+6,27%) in 64 giorni**, 12 round-trip di cui 11
+in utile, fee totali $0,41. Riconciliazione indipendente: la ricostruzione FIFO dà +$38,15 contro
+i +$37,50 dell'equity del venue — scarto $0,65 (1,7%), coerente col funding pagato sui long.
+
+Ma il numero che conta è un altro: **tutto il P&L è di sei giorni**. Fino al 17/08 il conto era a
+$597,12, cioè **−$0,94 in otto settimane**; l'equity è rimasta invariata nell'**80% delle
+giornate**. Non è un difetto — è cosa sono TP01 e SKH01 — ma significa che +6,27% in due mesi non
+è un tasso di rendimento.
+
+E l'analista ha aggiunto la lettura che le regole non producono: quei sette giorni sono anche gli
+**unici in cui il libro è stato a mercato**, e coincidono con +22,94% su BTC e +29,49% su ETH →
+la finestra **non separa l'edge dal beta** a un rialzo forte, né il trend dal breakout.
+
+## Cinque difetti trovati dai test o leggendo l'uscita, nessuno a occhio
+
+1. **Il tetto di leva era ridichiarato** (`0.5` cablato) invece che letto da `config/live.json` —
+   quinta occorrenza dello schema che il progetto paga da luglio.
+2. **L'IV-rank era la statistica sbagliata col nome giusto**: percentile a un anno etichettato
+   come il gate di VRP01, che usa quello **espandente**. Verdetto **opposto** (0,52 «sopra»
+   contro 0,18 «sotto»); il valore giusto combacia con «0/8 settimane passano il gate» (30/07).
+3. Il renderer cadeva in `KeyError` se mancava il blocco mercato.
+4. «24 giri attesi» su un giorno **in corso** → allarme a ogni esecuzione.
+5. Libro e P&L leggevano **due istanti diversi**: la stessa pagina mostrava due equity.
+
+## Il ciclo di retroazione, e il limite che resta
+
+Al primo giro reale il modello ha letto la **propria analisi precedente** — con l'avviso del
+tripwire — e l'ha commentata. `senza_analisi()` toglie la sua sezione prima di dargli la pagina.
+**Nessun controllo automatico può distinguere il meta-commento da prosa valida: si vede solo
+leggendo l'uscita.**
+
+E il limite dichiarato quando la guardia è stata scritta si è materializzato subito: **due errori
+su due giri con sonnet-5, nessuno dei due con una cifra nuova** — una frase su un merge mai
+raccontato, e un round-trip corretto dichiarato inesistente. `numeri_non_supportati()` prende
+l'invenzione, non il ragionamento. Modello portato a **opus-5** (primo giro pulito, affermazioni
+verificate a mano contro il DB), ma **due osservazioni contro una non provano niente**: è un
+tentativo di abbassare un tasso.
+
+## Regole
+
+- Un **dato operativo non ricostruibile** non può vivere in un file gitignored: si materializza
+  dove il backup arriva.
+- Una **guardia più stretta del contratto** produce allarmi che si impara a ignorare (il tripwire
+  validava sulla sola pagina mentre il prompt include anche lo storico, e bocciava un'equity vera).
+- Una regola che si accende su **$2 di cumulato** insegna a saltare la sezione: serve una soglia
+  di rilevanza.
+- **Chi scrive in un registro va firmato**, o il registro perde il suo valore probatorio.
+- Una **guardia sui numeri non copre il ragionamento**.

docs/diary/2026-08-23-wave-chiusura-critico.md

@@ -0,0 +1,184 @@
+# 2026-08-23 — Ondate 7-8 e il critico di chiusura: 17 filoni, 0 candidati, 3 numeri di testa riscritti
+
+**Branch:** `research/wave-0822` · **Registro per filone:** `docs/research/RESULTS-0822.md` §41-57
+**Libro, pesi, cron, config: INVARIATI.** `git diff main -- src/ config/ scripts/live/ scripts/cron_*.sh tests/` vuoto a ogni checkpoint.
+
+## Perche' esiste questa voce
+
+Il mandato era *"metti decine di agenti a fare analisi di nuove strategie possibili... arrivare ai 50
+giornalieri velocemente"*. Le ondate 1-3 (§1-40) avevano gia' dato 0 candidati. Queste due ne
+aggiungono 17 e chiudono con un agente incaricato di **attaccare l'ondata invece di estenderla**.
+La risposta al mandato e' negativa, ed e' quantificata: **la somma di tutti i lead positivi vale
++0,036 €/giorno**, contro i **+71 punti di probabilita'** che valgono €250 → €500 al mese.
+
+Questa voce non ripete il registro. Tiene le tre cose che il registro, per costruzione, non puo'
+dire: cosa e' cambiato **nella memoria operativa**, cosa ho sbagliato **io**, e cosa resta all'operatore.
+
+## 1. Il risultato che nessun filone cercava
+
+§50 chiedeva *"qual e' il miglior terzo sleeve eseguibile a $635"* e ha trovato che **il candidato
+piu' forte mai misurato dal progetto era gia' in produzione — in monitor da giugno, senza gate
+pre-registrato e senza deflated-Sharpe.** Sette candidati, **sette muri diversi, e nessuno dei sette
+e' una soglia di capitale**: non e' il conto piccolo a fermarli.
+
+§54 gli ha scritto il gate mancante. Passa **8 condizioni su 10**, e le due che mancano sono la
+stessa: **la cella che gira non e' quella che la selezione onesta sceglie** (quella viva fallisce il
+DSR a 0,905), e la selezione onesta compra il libro **long-flat**, cioe' butta via la gamba per cui
+PREVDAY fu promosso. *Non e' un parametro da ritoccare: sono due strategie diverse.*
+
+Verifica mia sopra il filone: la serie e' **intatta, 1512 barre su 1512** — e' l'unico monitor che
+il difetto `advance()` non tocca. Ma la finestra e' **0,172 anni** e li' l'**MDE e' 4,72 di Sharpe**:
+il +2,11 forward **non e' distinguibile da zero** su 26 ingressi. **Qualunque cosa il gate decida,
+non puo' appoggiarsi al numero forward.**
+
+## 2. Il critico, e le tre cose che vanno riscritte
+
+Prima di ogni accusa ha **riprodotto** con macchineria propria: i quattro muri **al dollaro**, il
+funding (−2,1597%/anno), il dShFULL di §42, e che il muro **e'** esattamente `prelievo/perpetua` su
+4 lenti su 4. **Il nucleo quantitativo dell'ondata regge.** Poi ha falsificato **due sue attese
+scritte prima di misurare** e tre miei numeri.
+
+**(a) Il muro non e' $313k: e' la mediana di una banda esplosiva.** SE del drift **5,151%/anno**;
++1 SE → $204.517, −1 SE → $709.753, **−2 SE → il traguardo non esiste a nessun capitale**.
+«€500/mese → P(20a) 85%» diventa **~0% a −1 SE**. Meccanismo: il muro e' un `1/x` su una quantita'
+(la rendita perpetua) che **si annulla prima del drift** → errore asimmetrico verso l'alto.
+Il pezzo che brucia: **per otto ondate ho stampato accanto a quel numero la risoluzione MONTE CARLO
+(0,7%)** — la precisione del simulatore — **e mai quella del suo ingresso, cento volte piu' grande.**
+
+**(b) «Positivo in 24 ancore su 24» vale ~2 osservazioni.** Corr media fra le 24 ancore di TP01
+**0,631 → N_eff 1,55**; fra le 10 fasi di XS01 **0,790 → N_eff 1,23**. E **non si salva sulla
+differenza appaiata**: la componente comune non si cancella (N_eff 1,64-2,24) — era l'attesa a
+priori del critico, **refutata**. Sulla stessa grandezza la **banda d'ancora e' 4,3x piu' stretta
+dell'IC95, che contiene lo zero** (su XS01: 3,8x; due misure indipendenti, stesso fattore ~4).
+⚠️ **Non cadono i verdetti** — poggiano anche su iso-vol, maxDD, selection-on-holdout, edge lordo.
+**Cade la precisione dei numeri, non la direzione delle decisioni.**
+
+**(c) Il gradino di leva a 1,50x era gia' morto.** §53 lo boccia (peggior giorno strutturale
+**21,48% > 20%**) e fissa **k max difendibile 1,40**. Sopravvive solo il **1,25x**, che vale
+**+€144/mese misurati direttamente** (non €164, che veniva da un'interpolazione lineare) e
+**+1,8 anni a muro congelato / +3,0 a muro mobile** — *e la convenzione va sempre detta, perche' le
+due letture distano piu' di quasi tutti gli effetti che questo progetto misura.*
+
+**In piu': tre baseline sotto lo stesso nome «libro 75/25».** `hourly` 1,683/11,22% (la lente di
+**ogni muro e traiettoria**) · `canonical` 1,800/9,56% · mediana d'ancora 1,626/10,4%. **Spread 0,12
+di Sharpe, piu' grande di quasi tutti i Δ dell'ondata**: un Δ accostato al baseline sbagliato cambia
+piu' del Δ. **Ogni numero va scritto con la sua lente attaccata.**
+
+## 3. Cosa ho sbagliato io
+
+Cinque errori, tutti su numeri **gia' pubblicati**, due dei quali stavano in `CLAUDE.md`:
+
+| # | cosa avevo scritto | cos'e' |
+|---|---|---|
+| a | «la convinzione di TP01 sta spesso a 1/3 o 2/3» | **il bucket 2/3 non esiste** — `tsmom_blend` media tre `np.sign()`, la famiglia ha **un** grado di liberta', non tre. Trovato da **due agenti indipendenti** |
+| b | «la catena USDC costa +90% di chiamate» | **+18%** — i 587 erano il conteggio grezzo, senza il filtro OI≥100 che il collettore applica |
+| c | «le opzioni BTC sono fuori a $3.000 per il lotto» | quello e' il **collaterale per VENDERE**; comprare costa il **premio**. Il muro vero e' il **tick da 5,00 USDC** |
+| d | «il gradino vale +1,8a / +€164» | lettura a **muro fermo**, convenzione **mai dichiarata** |
+| e | «la coda muove k\* di 1-2 unita'» | **4,6** |
+
+E uno catturato **prima** di pubblicarlo, che vale la pena tenere perche' e' della famiglia che
+stavo criticando: avevo formulato l'MDE di PREVDAY come *«la precisione apparente viene dal numero
+di mark, non di scommesse»*. **Falso**: la SE dello Sharpe annualizzato va con `1/sqrt(anni)`
+**indipendentemente dalla frequenza**, e infatti barra e trade danno lo stesso 4,72. Il fatto vero
+e' piu' banale: **63 giorni sono 63 giorni.**
+
+Il critico ha fatto lo stesso su di se': la sua prima stesura **de-luckava una serie gia'
+de-luckata** (0,89²) e stampava un finto +31,5% sul muro. *Il controllo che l'ha preso e' stato
+guardare il DRIFT stampato accanto al muro, non il muro.*
+
+## 4. Due difetti di contabilita' nel piano, entrambi a favore
+
+- **«€X/mese» versa ogni 30 GIORNI** → 121/182/243 versamenti invece di 120/180/240
+  (+0,83/+1,11/+1,25%), in **ogni tabella dal 25/07**.
+- **Il contatore `versato` e' uno scalare che non si ferma al traguardo** → il *«a 10 anni i bonifici
+  fanno il 73%»* e' l'intero orizzonte; **fino all'arrivo e' il 61%** ($190.265). *Stessa famiglia
+  del bug `paid` catturato il 25/07 — la lezione era codificata e il difetto era in un altro punto.*
+
+## 5. Cosa e' stato refutato, e perche' e' interessante
+
+Tre meccanismi di protezione, **due caduti sulla premessa prima che sul prezzo**:
+
+- **TAIL-HEDGE (§46):** comprare put deep-OTM fa **SALIRE** il maxDD in **162/162 celle**, a ogni
+  lente di f — perche' il beta del libro al sottostante e' **+0,076**. *Non si assicura un libro che
+  nei crash e' gia' quasi piatto.*
+- **TP01-TWIN (§49):** un ensemble di definizioni di trend protegge **peggio** (0/24 ancore, 3,2x
+  peggio nel 2022) — e i meccanismi **non erano ridondanti** (corr di posizione 0,61): la ridondanza
+  non era il problema.
+- **ANCHOR-ENSEMBLE (§47):** su TP01 il drift **non puo'** cambiare, per **algebra**
+  (`lordo_ens == media(lordi)`, residuo 1,4e-17).
+
+E il lead dello spot (§52) **muore dove servirebbe**: regge a $600, **si annulla a $272k** — sparisce
+esattamente al muro che pretende di spostare.
+
+## 6. MDE: quanti «SCARTATI» sono in realta' «non misurabile»
+
+Il critico ha misurato la finestra della catena opzioni: **77 giorni di superficie** → **MDE 4,3 di
+Sharpe**. Ogni SCARTATO di §4/§5/§7/§11 che poggia su un confronto di Sharpe e' un **non-risultato
+su quell'asse** (le loro parti valide sono lead-lag, placebo e censimenti). L'ondata dichiara il
+proprio MDE in §6, §10, §43, §48, §56 — **disciplina reale** — ma tre etichette restano piu' forti
+della misura, e una conta: 🚨 **§21 XS01 fuori campione, il PILASTRO del canale funded, ha effetto
++1,12 contro un MDE di 1,13.** Sta *esattamente* al proprio limite di rilevabilita', e viene
+propagato fino a P(≥50 €/g) come se fosse noto a due cifre. *(Equita': gira anche un null di
+permutazione a fee zero, p=0,013, che ha piu' potenza del t-stat. Il problema non e' «nessuna
+evidenza», e' la precisione attribuita al livello.)*
+
+## 7. La risposta al mandato
+
+| lead | €/giorno a $635 | eseguibile oggi |
+|---|---|---|
+| gradino di leva 1,25x | **+0,046** | no — la manopola non esiste |
+| spot al posto del perpetual | +0,017 | no — domanda fiscale aperta |
+| PREVDAY al 15% (de-luckato) | +0,014 | no — gira la cella sbagliata |
+| binario di frequenza | +0,011 | no — 3 gate su 4 falliti |
+| esecuzione passiva | +0,005 | no — l'IC contiene lo zero |
+| **funding (costo scoperto)** | **−0,023** | **lo paghi gia'** |
+
+**Somma di tutti i lead positivi, se fossero autorizzati e additivi — non lo sono, e nessuno e'
+eseguibile oggi: +0,036 €/giorno.** Sullo stesso motore e sugli stessi percorsi, **€250 → €500 al
+mese porta P(20a) dal 14% all'85%** e la mediana da 23,4 a 17,3 anni. **Rapporto ~1.400 a 1.**
+
+🚨 **`L'ONDATA NON HA PRODOTTO NIENTE CHE AVVICINI I 50 €/GIORNO.`** Ha prodotto (i) un **costo gia'
+in essere** che porta P(20a) a €250/mese dal 49% al 14% (il funding), (ii) **quattro monitor rotti**
+che avrebbero fatto decidere un gate al contrario, (iii) un **punto singolo di guasto** nel trasporto
+degli allarmi, (iv) **tre lead reali tutti bloccati da qualcosa che non e' la ricerca**.
+**Il suo valore e' difensivo ed e' reale: ha impedito decisioni sbagliate.** E nulla di sepolto sotto
+uno «SCARTATO» merita di essere riesumato.
+
+## 8. A credito dell'ondata
+
+**Quattro auto-correzioni in 24 ore**, ed e' il suo dato piu' sano: §45 «lo spot non si liquida»
+falsificato da §52; §39 «non esiste una linea USDC datata» falsificato lo stesso giorno; la regola
+«overlay non causale» **ritirata** dallo scettico; «`dealer_net_gamma` e' il GEX invertito» ritirata
+**leggendo il sorgente** che gira su questa stessa VPS.
+
+## 9. Cosa resta all'operatore
+
+Sette decisioni, nessuna delle quali richiede altra ricerca. Brief:
+`https://claude.ai/code/artifact/9ca378f7-464a-4ee1-a520-38a026a34fc3`
+
+1. **Riparare `advance()` e rigenerare** prima del gate STATARB del **27/09** (35 giorni) — oggi il
+   gate si deciderebbe **al contrario** (Sharpe +1,96 registrato contro −2,02 vero).
+2. **Che fare del branch** `research/wave-0822` (106 commit, tutti in `scripts/research/` e `docs/`).
+3. **Chiedere alla firm** se ha una lista ristretta propria (costo €0, blocca una spesa di $579).
+4. **Chiedere al commercialista** se i derivati Deribit sono al 26% o al 33% (vale ~$22k di muro).
+5. **Costruire la chiave di scala** in config, se si vuole il gradino **1,25x** (e **solo** quello).
+6. **Riparare il trasporto degli allarmi** — la parte (c) cambia il comportamento, quindi e' una scelta.
+7. **Decidere di `paper_prevday`**: allinearlo alla cella onesta, ritirarlo, o lasciarlo scrivendo
+   che la sua finestra non e' evidenza.
+
+## Regole nuove
+
+1. **Un muro calcolato come `X/y` con `y` stimato va pubblicato con la banda di `y`**, non con la
+   risoluzione del simulatore — e se `y` si annulla prima del suo ingresso, l'errore e' **asimmetrico**
+   e la banda non e' simmetrica attorno al punto.
+2. **«N/N ancore» e' robustezza alla SCELTA dell'ancora, ~2 osservazioni indipendenti — non N prove.**
+   La banda d'ancora **non e' un intervallo di confidenza** e non va usata al posto di uno; e **non si
+   attacca un p-value** a un conteggio di ancore o di finestre sovrapposte.
+3. **Un Δ si scrive con la sua BASELINE attaccata.** Tre lenti dello stesso libro distano 0,12 di
+   Sharpe, piu' della maggior parte dei Δ misurati: la lente sbagliata cambia piu' del risultato.
+4. **Un argomento refutato due volte per due strade indipendenti non va ereditato come regola**
+   (il «soffitto ~1,3» e l'aritmetica del DSR di screen che ne discendeva).
+5. **Prima di chiudere una famiglia, confrontare l'etichetta con il proprio MDE dichiarato** — §48
+   chiude un filone su una branca che dichiara essa stessa un fattore 44 sotto l'MDE.
+6. **Un contatore cumulativo dentro un simulatore va fermato all'evento che sta misurando**, o
+   risponde a una domanda diversa da quella posta (2ª occorrenza in un mese, in due punti diversi).

docs/diary/2026-08-25-manutenzione-deribit-e-resilienza-venue.md

@@ -0,0 +1,271 @@
+# 2026-08-25 — La manutenzione del martedì, e i due difetti che ha scoperchiato
+
+*Scritto da Claude (agente), su richiesta dell'operatore. Firmato come vuole P13: l'analisi in
+prosa è opinione di un lettore fallibile, i numeri qui sotto vengono dai log e sono riproducibili.*
+
+## Come è cominciata
+
+Domanda dell'operatore: «stato trades». Report normale del libro di bordo — 24 fill, equity
+$598,06 → $667,88 (+11,67%), 16 round-trip di cui 15 in utile, netto +39,78. Poi il `--reconcile`
+ha stampato la riga che ha aperto la giornata:
+
+```
+venue: NON LETTO (HTTPError) — non e' 'zero trade', e' 'non misurato'
+```
+
+Non era il gateway. Era **Deribit in manutenzione**: `system_maintenance`, codice 11051, HTTP 503
+sia sul pubblico che sul privato. Iniziata fra le **08:57:40Z** (ultimo 200 OK nei log di
+`cerbero-mcp`) e le **09:01:46Z** (primo 503). Rientrata verso le 09:20 — ~20 minuti, coerenti con
+i 15-30 annunciati da Deribit per le sue release.
+
+## Cosa dicono i log, contati invece che ricordati
+
+1.499 giri di `cron_book` fra il 2026-06-23 e il 2026-08-25:
+
+| esito | n | % |
+|---|---|---|
+| manutenzione Deribit | 3 | 0,20% |
+| traceback duro | 5 | 0,33% |
+| giri senza esito utile | 26 | 1,7% |
+
+E gli episodi di venue non sono sparsi:
+
+```
+2026-07-21T09:00  Tue  502 su get_positions (Deribit giù, vista dal gateway)
+2026-08-11T09:07  Tue  system_maintenance 11051
+2026-08-18T09:07  Tue  system_maintenance 11051   (giù anche alle 10:07)
+2026-08-25T09:07  Tue  system_maintenance 11051
+```
+
+**Quattro martedì su dieci, tutti fra le 09:00 e le 09:07 UTC.** Il supporto Deribit conferma la
+meccanica: le release escono il martedì alle 09:00 UTC. Il minuto `:07` del cron cadeva dentro
+quella finestra — e ci cadeva per costruzione, non per sfortuna.
+
+**Il punto singolo di guasto non è Deribit: siamo noi.** Dei 5 traceback, **4 sono il nostro
+gateway** `cerbero-mcp.tielogic.xyz` (un 404 su `get_positions`, un 502, due `ReadTimeout`).
+
+## I due difetti veri
+
+### 1. Una riga sola per due guasti che vogliono azioni opposte
+
+Fino a oggi qualunque guasto sul percorso Deribit stampava `conto non leggibile (offline)`, con la
+nota di diagnosi **cablata**. Ma "Deribit in manutenzione" (aspetta, rientra da sola) e "il nostro
+gateway è rotto" (ripara) non sono la stessa notizia. È **P4** violata, con l'aggravante di **P4
+seconda metà**: *una nota di diagnosi cablata è peggio di nessuna nota*, perché si legge come una
+misura.
+
+Peggio ancora: il 18/08 **il codice 11051 era già dentro il processo**, nello stesso minuto,
+raccolto da `livefeed`. Semplicemente non arrivava a chi decideva la gravità dell'allarme.
+
+### 2. La finestra scoperta del disaster-SL — e l'asset che sparisce
+
+`ensure_disaster_sl` ricostruisce un bracket incoerente **cancellando prima e ripiazzando dopo**.
+Fra le due chiamate la posizione è senza alcuno stop on-book. Finché il ripiazzamento sollevava,
+quell'eccezione risaliva fino a `main()`: il guasto peggiore (**posizione scoperta**) aveva la
+stessa faccia di un errore qualunque.
+
+E c'è il corollario che è successo davvero. Il **2026-07-21 alle 09:00 UTC** il 502 è arrivato
+dentro `ensure_disaster_sl` su BTC. Nel log di quel giro **ETH non compare**: non è stato
+ribilanciato e — quel che conta — **la sua protezione non è stata verificata**. Un guasto su un
+asset toglieva la rete di sicurezza all'altro.
+
+## Cosa è stato fatto
+
+**`src/live/venue_probe.py` (nuovo).** Interroga l'API **pubblica** Deribit in diretta — niente
+gateway, niente credenziali — e classifica: `VENUE_MANUTENZIONE` / `VENUE_GIU` / `GATEWAY` /
+`IGNOTO`. La sonda parte **solo dopo un guasto**: sul percorso sano costa zero. Rispetta **P1**:
+non ridichiara la firma 11051, la importa da `venue_watch.is_maintenance`.
+
+Su **P9** (*un allarme massimo speso per un evento atteso è un allarme che non verrà letto il
+giorno che è vero*): la manutenzione dentro lo slot declassa il titolo a ℹ️. Ma con due paletti,
+perché il rischio qui è costruire il silenzio proprio nell'ora in cui serve:
+
+- declassa **solo su evidenza** della sonda, mai sull'orologio da solo → un gateway rotto di
+  martedì mattina resta 🛑;
+- declassa **solo dentro la durata annunciata** (30 min) → il 18/08 alle 10:07 la manutenzione
+  aveva sforato, e torna una notizia. Stessa logica di `MAINT_GRACE_HOURS`, altra domanda.
+
+**Isolamento per asset** in `book_execute`: un asset che esplode non ferma il ciclo, e il giro
+esce con codice 2 per essere contabile.
+
+**Stato `naked`** in `ensure_disaster_sl`: due tentativi di ripiazzamento, e se falliscono
+entrambi lo stato è distinto da `place-failed` (**P5**: guasti diversi si distinguono anche quando
+l'azione è la stessa). Non è "non sono riuscito a proteggere": è "**ho tolto la protezione e non
+sono riuscito a rimetterla**" → 🚨 sempre, **mai** declassato da P9.
+
+Non è stata invertita la sequenza in *piazza-poi-cancella*: due STOP `reduce_only` contemporanei
+sono *probabilmente* innocui, ma "probabilmente" non basta per cambiare il ciclo di vita dei
+bracket su un percorso con soldi veri senza misurarlo. **Riparato il silenzio, non toccata la
+sequenza.**
+
+**Cron `:07` → `:47`.** I due vincoli sono entrambi misurati e compatibili: fuori dai ~26s del
+minuto tondo (il collettore catena si auto-satura il rate-limit per-IP: 12.186 risposte 429 in 26
+ore, 96% nel minuto `:00`, misura del 30/07) **e** fuori dallo slot di release. Il commento in
+`cron_book.sh` è stato riscritto: lasciarlo dire `:07` sarebbe stato il difetto §5.7 in versione
+nuova.
+
+**Previsione dichiarata (M12).** Sulle 4 finestre osservate, 3 sono rientrate entro l'ora. Il `:47`
+ne avrebbe scavalcate **3 su 4**. Se martedì prossimo il `:47` becca comunque la manutenzione, la
+previsione è sbagliata e lo slot non è quello che credo.
+
+## Cosa NON è stato fatto, e perché
+
+**Il fallback diretto ai privati Deribit è bloccato, non rinviato.** Le credenziali Deribit
+esistono **solo dentro il gateway**: in locale c'è `CERBERO_TOKEN` e basta. Leggere conto e
+posizioni scavalcando `cerbero-mcp` richiede **chiavi API create dall'operatore** sul conto
+Deribit. È una decisione con una superficie di rischio propria (una chiave in più che può
+trapelare), non un refactor.
+
+È stato fatto il pezzo che non le richiede — la sonda pubblica — e resta a debito in §5.11 il
+resto. Nota onesta: la sonda pubblica **dice di chi è il guasto, non lo aggira**. Con il gateway
+giù il libro continua ad astenersi; sa solo dire perché.
+
+## Test
+
+**19 nuovi** (12 in `test_venue_probe.py`, 7 in `test_book_resilienza_venue.py`), nessuno tocca la
+rete. Suite: **730 passati, 1 fallito** — il fallito è quello già noto di §5.9 (SKH01 `canonical`
+1,9223 contro banda cablata `<1,9`, deriva dei dati, non del codice).
+
+Controllo positivo fatto, perché un test mai visto fallire non dimostra niente: contro il codice
+vecchio **5 dei 7** test di resilienza falliscono. Con una riserva da dichiarare — il test di
+isolamento, sul codice vecchio, fallisce perché il modulo di diagnosi non esiste, non perché
+dimostri l'isolamento rotto. La prova di *quel* difetto è il log del 21/07, dove ETH non compare.
+
+---
+
+## Coda: la suite di test ha mandato un allarme falso sul telefono dell'operatore
+
+Il primo giro al nuovo minuto `:47` è andato bene — entrambi gli asset elaborati, entrambi i
+disaster-SL verificati `ok`, exit 0 — ma nel log c'era una riga che non poteva essere vera:
+
+```
+💰 USCITA DI FONDI: $5,000.00 -> $667.68 (-86.6%) · cap/asset ora $333.84
+```
+
+Il conto non ha mai visto $5.000. Ha visto $598-668 da sempre.
+
+**L'ho causato io**, lanciando `uv run pytest` per verificare le riparazioni di oggi.
+`test_book_live.py::test_la_formula_del_report_ha_potenza_anche_a_libro_flat` prende solo
+`monkeypatch` (niente `tmp_path`), sostituisce `shadow_report` con uno che dichiara
+`real_equity=5000.0`, e chiama `book.book_report()` — che come **effetto collaterale** scrive
+`data/live/equity_seen.json`. Riprodotto isolando il singolo test: watermark $667,68 → **$5.000**.
+
+L'helper `_write_cfg` esisteva già proprio per questo — il difetto gemello è del **2026-07-26** —
+ma quel test, aggiunto il **21/08**, non lo usa. È la terza volta che la stessa scommessa perde.
+
+### Non era cosmetico
+
+Il watermark alimenta il cap di fallback:
+
+```
+cap_fallback = min(cap_fisso_di_config, watermark × frac)
+```
+
+Con $5.000 dentro: `min($3.000, $2.500) = $2.500` per asset invece di `$334`. Su un conto da $668
+sono fino a **$5.000 di nozionale lordo, ~7,5x di leva**. E il ramo che ci arriva è raggiungibile:
+`eq_fallback` in `book_execute` **allerta e NON blocca**, per scelta dichiarata.
+
+Cioè: **lanciare la suite di test poteva armare esattamente il pericolo che il watermark esiste
+per impedire** (nota del 26/07 in `book.py` sul cap fisso e la leva 3,35x).
+
+Danno reale oggi: **nessuno**. Alle 09:47 l'equity era leggibile, quindi il cap è stato calcolato
+sull'equity vera e il watermark è stato riscritto col valore giusto. La finestra scoperta è stata
+~09:25 → 09:47, e in quella finestra non c'è stato nessun giro con equity illeggibile. È andata
+bene per la direzione del caso, non perché ci fosse una protezione.
+
+### Riparazione, e perché è strutturale
+
+`tests/conftest.py` con una fixture **autouse** che devia `EQUITY_WATERMARK` in `tmp_path` per
+**ogni** test. Chiedere a ogni autore di ricordarsi il monkeypatch è la scommessa che ha già perso
+due volte: la protezione deve valere anche per il test che qualcuno scriverà domani senza aver
+letto niente. Un test che vuole davvero pilotare il watermark continua a funzionare — il suo
+monkeypatch esplicito gira dopo e vince.
+
+Più una guardia in `test_cap_watermark.py` che si accende se qualcuno rimuove la fixture:
+controllo positivo, perché una protezione mai vista fallire non è una protezione.
+
+**Resta aperto il principio più largo** (§5.12): un test non dovrebbe poter scrivere in
+`data/live/` *affatto*. Oggi è deviato solo il watermark — `trades.db` e `book_executions.jsonl`
+sono ancora esposti allo stesso errore.
+
+### La lezione
+
+Un **effetto collaterale su file** trasforma un test puro in un attore sul sistema vivo. Qui il
+test non menzionava il watermark, non lo importava, non lo asseriva: lo scriveva passando per una
+funzione di produzione tre livelli più in basso. **Il perimetro di un test non è quello che il test
+dice di toccare: è quello che tocca il codice che chiama.**
+
+---
+
+## Seconda parte della giornata: il versamento, e le tre misure che ne sono uscite
+
+Alle **11:03:35Z** sono atterrati **1.400 USDC**: equity **$667,88 → $2.066,88**. Il giro delle
+11:47 ha ribilanciato correttamente (cap/asset $1.033, BTC +$238, ETH +$319, disaster-SL `placed`
+su entrambi alla taglia nuova) — la prima volta che il ramo riparato al mattino gira sul serio.
+
+Poi l'operatore ha chiesto tre cose in fila, e ognuna ha rotto qualcosa.
+
+### (1) «€500/mese per 10 anni»
+
+Rifatto sul conto vero invece che citare la tabella da $635. **Non centra**: capitale mediano
+$114.934, rendita 18,35 €/g, **P(≥50 €/g) = 0,0%** su 3.000 traiettorie. Il bersaglio con €500/m
+arriva al 17° anno; per averlo a 10 servono €1.718/mese.
+
+Il numero che ordina tutto: **€100/mese in più valgono +4,07%/anno di drift**, cioè +27% su tutto
+il drift del libro. Dettaglio in `30-piano-capitale-fisco.md`.
+
+### (2) «A cosa serve XSR01, allora?» → e poi: «l'abbiamo fatto per la leva»
+
+Due osservazioni dell'operatore, entrambe centrate, che hanno spostato la conversazione dal
+candidato al **disegno**.
+
+XSR01 ha già fallito `weights_tilt_null` (peso ottimo ~0). Ma la risposta vera è che **anche un
+uplift di strategia riuscito vale meno di un bonifico modesto**, e questo si applica a qualunque
+sleeve, non solo a XSR01.
+
+Poi la misura che ha ribaltato la discussione sulla leva: **il libro non è poco levato, è FERMO**.
+Esposizione lorda realizzata in 64 giorni live: mediana **0,00x**, media 0,05x, **max 0,52x** su un
+tetto strutturale di 1,0x, esposto in **14 giorni su 64**. Il cap non ha mai morso: il vincolo è il
+segnale. *Il basso drawdown di TP01 non viene dall'essere piccolo nel mercato — viene dallo stare
+fuori dal mercato.*
+
+⚠️ Correzione che mi sono fatto da solo: quel 78% è il **regime attuale**, non la media. Sull'intera
+storia i giorni flat sono il **28,0%** — 2,7% nel 2021, 77,0% nel 2022, 75,6% nel 2026.
+
+### (3) «Allora usiamo l'ETF quando il libro è flat» → SCARTATO
+
+Test in `r0825_capitale_fermo.py`. **Perde** a iso-rischio (Sharpe 1,01 contro 1,40 del 50/50 e
+1,35 del libro), e il null a maschera casuale lo mette al **30° percentile**: fa peggio di
+commutare a caso.
+
+E qui la parte che vale più del risultato. Stavo per scrivere un meccanismo pulito — *«il libro va
+flat quando anche l'azionario soffre»* — sostenuto da un aggregato netto (SPY 4,91% nei giorni
+flat contro 21,48% negli altri, −16,57%). **La scomposizione per anno lo ha demolito**: il segno
+alterna, 3 anni su e 4 giù, e il **2022** — l'anno che doveva reggerlo — ha il segno **opposto**.
+Artefatto di composizione: i giorni flat stanno negli **anni** brutti per l'azionario, non nei
+**giorni** brutti. M9 ha fatto esattamente il suo lavoro, su di me.
+
+### I due difetti di misurazione trovati addosso
+
+1. **Maschera vuota vestita da risultato.** La prima versione prendeva i giorni flat dalla serie
+   **de-luckata**; ma `deluck` sottrae una costante, quindi lo zero esatto sparisce. Maschera
+   vuota → dinamico identico al book → e lo script ha stampato tabelle piene e un p-value. Lo ha
+   rivelato solo la riga che stampava `0 = 0.0%`.
+   **Regola: stampare la CARDINALITÀ di una maschera prima di usarla.**
+2. **`r0822_slip_audit.py` aveva l'equity CABLATA a `636.0`** con un commento che diceva di leggerla
+   dal watermark — P1 in piena regola. Il giorno del versamento avrebbe continuato a stampare $636,
+   sbagliando di 3,3x proprio la sezione che esiste per dire *quando la misura scade*. Riparato
+   leggendo il watermark — e poi riparato **di nuovo**, perché la prima riparazione divideva tutti i
+   fill per l'equity di oggi mentre i fill del campione sono stati eseguiti a conti diversi
+   ($597–$2.067). Ora la normalizzazione è **per fill**, e a $600 riproduce il 22,0% originale.
+
+### La misura di slippage, rifatta alla taglia vera
+
+26 fill (erano 18), taglia $6–$319. I due più grandi mai eseguiti sono di oggi e hanno preso
+**1,01%** e **0,54%** della loro barra 5m, con il print **a metà del range** (q=0,50). Il caso
+peggiore resta un fill da **$74 del 18/07 al 21,9%** — un sabato, nastro inesistente.
+
+📌 **L'attrito non è funzione della taglia: è funzione di `taglia / volume della barra`.** Un fill
+4,3× più grande in un'ora liquida ha fatto 20× meno partecipazione di uno piccolo in un'ora morta.
+⚠️ Ma non è «assente», è **«non ancora testato»**: nel campione non c'è ancora un fill grande in una
+barra sottile, e il weekend è dove TP01 fa il 38% del proprio gross.

docs/diary/2026-08-25-versamento-3k.md

@@ -0,0 +1,38 @@
+# 2026-08-25 — Il versamento da $3.000: cosa compra, e cosa NON compra
+
+**Domanda dell'operatore:** *"rianalizza e vediamo come procedere. potrei versare a breve altri 3k"*.
+**Script:** `scripts/research/r0825_versamento_3k.py` (lente L3, stessi semi e path del piano:
+tutto appaiato, M22). Assunzioni dichiarate: 3k = $3.000 USDC, lump oggi, start $2.065 (watermark
+18:47:13Z). Controllo M23: da $2.065 il 10a riproduce $114.929 contro i $114.934 pubblicati da
+$2.067 — la macchina riproduce il numero vecchio.
+
+## Cosa compra (€500/mese, appaiato sugli stessi path)
+
+| orizzonte | senza lump | con lump | Δ | €/g con lump | P(≥50€/g) |
+|---|---|---|---|---|---|
+| 5a | $44.921 | $49.730 | +10,7% | 7,94 | 0% |
+| 10a | $114.929 | $122.491 | +6,6% | 19,56 | 0% |
+| 15a | $228.770 | $241.490 | +5,6% | 38,56 | 12,3% → 17,3% |
+| 20a | $408.105 | $427.738 | +4,8% | 68,30 | 79,4% → 83,9% |
+
+Il lump = **5,5 mesi di versamenti anticipati in un colpo** (N3: e' la prima leva, esercitata).
+Pietre miliari con €500/mese: $15k (C\* Hyperliquid) 1,7a → **1,3a**; $20k (si riapre la scelta
+del venue) 2,4a → **1,9a**.
+
+## L'effetto collaterale che conta: il gate XSR01 del 23/10 si RIBALTA
+
+P(capitale ≥$5k al 23/10): **0,0% → 100,0%** (mediana $5.664, p10 $5.417). Senza lump il gate
+moriva da solo sul criterio di capitale e i suoi tre difetti erano accademici. Col lump il
+criterio formale **passa**, e la decisione poggerebbe per intero su:
+(a) il monitor rotto che registra ~41 min/giorno (§5.1); (b) l'haircut col pavimento sbagliato
+di 5-7× (§5.3); (c) un C\* vero $15-20k contro i $1.266 che il 25% di $5.065 mette sul venue.
+**Il lump rende il gate LEGGIBILE senza rendere XSR01 comprabile** — il caso peggiore per un
+criterio scritto male. La scelta fra riscrivere adesso (dichiarandolo) e lasciare-e-citare va
+presa **prima** che il lump atterri, non il 23/10.
+
+## Meccanica live a $5.065 — niente da toccare
+
+cap per-asset $1.032 → $2.532 (equity×0,5, si adegua da solo); min_order $5 dal 0,48% al 0,20%
+del cap (C2); fallback min($3.000, wm×0,5) = $2.532; disaster-SL invariato (e il nome continua a
+ingannare). ⚠️ **Slip-audit da rifare** dopo i primi fill: misurato su $597-2.067, a $5k la taglia
+relativa raddoppia — lo script con normalizzazione per-fill c'e' gia'.

docs/diary/2026-08-25-xsr01-sotto-la-lente-rendita.md

@@ -0,0 +1,114 @@
+# 2026-08-25 — XSR01 sotto la lente della RENDITA: e' un conto deposito con un secondo venue
+
+**Domanda dell'operatore:** *"rendita perpetua ma non ho ancora capito se serve XSR01"*.
+**Script:** `scripts/research/r0825_xsr_rendita.py` (N11: ogni numero qui sotto lo riproduce).
+
+## Perche' era una misura nuova
+
+XSR01 era stato giudicato tre volte — ammissione (25/07), gate di deploy pre-registrato (23/10),
+accumulo (oggi) — e **mai sotto la lente della rendita**. Sono criteri diversi: l'accumulo premia
+il **drift**, la rendita premia la **perpetua** (il prelievo piu' alto che sopravvive a 20 anni con
+P≥90%). Dichiarato l'obiettivo (N6), il criterio cambia, e nessuno aveva rifatto il conto.
+
+## Cosa mi aspettavo prima di misurare (M12)
+
+(a) a iso-nozionale il mix perde drift e **alza** il muro; (b) a iso-rischio (M6) il verdetto puo'
+**ribaltarsi**; (c) il vincolo che decide non sara' ne' (a) ne' (b) ma il **capitale**.
+**Tutte e tre vere** — ma (c) e' arrivata con una gamba che non avevo previsto: il null.
+
+## Le serie, e la finestra in cui esistono entrambe
+
+| serie | finestra | drift/a | vol/a | Sharpe | maxDD | SE drift |
+|---|---|---|---|---|---|---|
+| libro L3 — **tutta** la storia | 2019-03-14 → 2026-08-22 | 15,19% | 11,29% | 1,35 | −12,4% | 5,19% |
+| libro L3 — finestra comune | 2024-01-01 → 2026-08-22 | 10,96% | 10,14% | 1,08 | −8,6% | 7,97% |
+| XSR01 — finestra comune | idem (965 g, 2,64 anni) | **3,72%** | 2,34% | 1,59 | −2,5% | 1,46% |
+
+corr libro↔XSR01 **+0,049**. Finestra comune = **35%** della storia del libro → **il muro calcolato
+qui NON e' il $313k pubblicato**: si confronta solo con se stesso (base $602.660).
+📌 Sharpe di XSR01 a oggi, **lente dei gate, sole barre chiuse: 1,56** — il "1,82" pubblicato e' una
+**terza** lente (XSR-REPRO, 22/08). Si cita sempre la coppia (lente, ultima barra chiusa).
+
+## (2) iso-nozionale — XSR01 ALZA il muro
+
+w 5→50%: muro da $604k a $668k (**+0,3% → +10,8%**). Il mix e' piu' liscio ma piu' povero, e per
+una rendita il drift comanda. **A iso-nozionale XSR01 peggiora l'obiettivo dichiarato.**
+
+## (3) iso-rischio (M6) — si ribalta, e sale il sospetto
+
+Ri-scalando ogni mix a `vol(libro)`: w 25% → k **1,32x**, muro **$478.729 (−20,6%)**.
+⚠️ **L'argmax e' al BORDO** (w=50%, k=1,93x): il muro scende **monotonamente** in w, quindi la
+griglia non indica un ottimo, dice *"il piu' possibile"* — e cio' che si compra in quella direzione
+e' il **k**, non XSR01 (M8). Sopra 1,40x il libro **non puo' eseguire** (decisione 23/08, e in
+`config/live.json` non esiste una chiave di scala). Peso portato avanti: **25%, k 1,32x**.
+
+## (3b) IL NULL — ed e' il risultato della sessione
+
+A iso-vol vale `drift = Sharpe × vol_libro`: la colonna "drift" della sezione (3) **e' la colonna
+"Sharpe" ri-etichettata**. Tutto il guadagno di muro e' guadagno di **Sharpe da diversificazione**.
+Quattro sostituti, stesso peso 25%, stessa ri-scalatura:
+
+| sostituto | muro | Δ vs base |
+|---|---|---|
+| **XSR01 (vero)** | **$478.729** | **−20,6%** |
+| N1 mescolato — stessi rendimenti, ordine casuale (3 semi) | $475.933 / $483.846 / $484.421 | −21,0 / −19,7 / −19,6% |
+| N2 rumore gaussiano, media e vol di XSR01 (3 semi) | $457.751 / $499.263 / $531.158 | −24,0 / −17,2 / −11,9% |
+| N3 rumore, **drift ZERO** (3 semi) | $558.080 / $617.270 / $662.436 | −7,4 / **+2,4** / **+9,9%** |
+| **N4 conto remunerato 3,72%, vol 0** | **$477.607** | **−20,8%** |
+| N4 conto remunerato 4,0%, vol 0 | $469.353 | −22,1% |
+
+📌 **Il MECCANISMO di XSR01 vale 0,8% di muro** — dentro la risoluzione Monte Carlo (spread fra semi
+0,151% di perpetua ≈ $17k di muro, M23). **Mescolare i suoi rendimenti non cambia niente.**
+📌 **N3 (drift zero) non paga**: mediana $617k **sopra** la base. La sola riduzione di varianza non
+compra rendita. Quindi **cio' che si compra e' il DRIFT scorrelato**, non la scorrelazione.
+🚨 **N4 e' la riga che risponde alla domanda.** Un **conto remunerato** allo stesso tasso (3,72%),
+**vol zero, corr zero, nessun secondo venue**, da' $477.607 contro i $478.729 di XSR01: **identici
+dentro la risoluzione**. Al 4,0% e' **meglio**. Ed e' un confronto **in svantaggio per il conto**:
+la lente L3 gli applica il **33%** di `c-sexies`, mentre un BOT paga 12,5% e un deposito 26%.
+
+## (4)-(5) gate e risoluzione
+
+`weights_tilt_null` (XSR01 25% vs 0%): Δ_is +0,061 · Δ_hold +0,162 · pctl 25,8 < 90,0 → **PASS**.
+⚠️ hold-out del gate = 2025-01-01 → la gamba in-sample e' **un solo anno**: gira, ma e' un indizio.
+Differenza appaiata di drift **+1,16%/anno, SE 0,48% → t +2,40**. Drift XSR01 **+3,72%, SE 1,46%,
+t +2,55**. Risolto, ma di poco, e su 2,64 anni.
+
+## (6) il vincolo che non e' nelle tabelle
+
+XSR01 gira su **Hyperliquid**: il suo peso e' capitale che **esce** da Deribit, non che si aggiunge.
+A $2.067 il 25% sono **$517**, contro un **C\* misurato di $15.000-20.000** (il gate 23/10 e' tarato
+su ~$3.000, §5.3). Per un 25% sopra C\* servono **$60.000 sul conto totale**.
+E l'haircut mangia **proprio la cosa che il null dice di star comprando**:
+
+| haircut | netto/anno | vs conto 4,0% | vs conto 2,0% |
+|---|---|---|---|
+| 0% | 3,72% | SOTTO | sopra |
+| 20% | 2,97% | SOTTO | sopra |
+| 40% (soglia del gate) | 2,23% | SOTTO | sopra |
+| 60% | 1,49% | SOTTO | **SOTTO** |
+
+**Pareggio con un conto al 2%: haircut 46%. Con un conto al 4%: non pareggia nemmeno a haircut ZERO.**
+E l'haircut pubblicato ($14,41 di ticket) e' **~2,4x ottimista e senza script che lo riproduca**.
+
+## VERDETTO
+
+**4/6 condizioni** — ma il conteggio non e' la lettura. La lettura e':
+
+> Sotto la lente **rendita perpetua**, XSR01 fa una cosa reale — porta un **drift scorrelato a bassa
+> vol** — e la fa in modo **non proprietario**: mescolarlo non cambia il risultato, e un conto
+> remunerato allo stesso tasso lo **eguaglia a vol zero e senza un secondo venue**.
+> Il vincolo binding non e' il rendimento: e' il **capitale** ($60.000 per un 25% sopra C\*), e sotto
+> quella soglia la domanda *"serve XSR01?"* **non ha una risposta comprabile**.
+
+**Cosa NON dice.** Non dice che XSR01 e' morto: lo Sharpe standalone 1,56 e il DSR 0,983 reggono, e
+sotto la lente **accumulo** il conto va rifatto (li' il drift comanda in modo diverso). Dice che
+**per la rendita non e' lo strumento**, e che il gate del 23/10 sta per decidere su una gamba che a
+questo capitale non e' comprabile.
+
+## Cosa e' cambiato in me mentre misuravo
+
+Ho copiato in questo script **lo stesso difetto che avevo riparato stamattina** in
+`r0825_capitale_fermo.py`: la maschera dei giorni flat presa dalla serie **de-luckata**, dove gli
+zeri esatti non esistono piu' perche' `deluck` sottrae una costante. Stampava `0.0%` e non si sarebbe
+notato senza la riga che conta i giorni. Riparata con l'`assert` che manca(va) a monte: la maschera
+si prende dalla **serie grezza**. *Riparare un difetto in un file non lo ripara nella testa.*

docs/diary/2026-08-26-advance-riparato-e-debiti.md

@@ -0,0 +1,95 @@
+# 2026-08-26 — `advance()` riparato e rigenerato, quattro debiti chiusi in un giorno
+
+Quattro debiti di CLAUDE.md §5 chiusi: **§5.1** (advance + rigenerazione + guardia),
+**§5.12** (isolamento test esteso), **§5.5** (test di leva cancellato con nota),
+**§5.9** (test rosso indagato e ancorato). Suite: **751 passati, 0 falliti** — tutta verde
+per la prima volta dal ~24/08.
+
+## §5.1 — advance() consuma solo barre CHIUSE, e le serie sono RIGENERATE
+
+**Il fix** (`src/live/paper_guard.py` + 6 monitor): la riga
+`new = [i for i in range(len(ts)) if ts[i] > last_ts]` diventa `PG.nuove_chiuse(ts, last_ts,
+cadenza)` — una barra open-labeled e' chiusa quando `ts + cadenza <= adesso`. Filtro condiviso,
+importato da tutti e sei i monitor (anche `paper_combo`, che era sano *per caso*: ora e' sano
+*per costruzione*).
+
+⚠️ **D6 pagata DI NUOVO scrivendo il fix:** la prima stesura di `indice_chiuso` usava `asi8`
+assumendo nanosecondi — pandas 3 usa `us` di default, e l'intero nella scala sbagliata dava
+"chiusa" la barra del giorno in corso **senza eccezioni**. Beccata dal test di fumo, riparata
+con la sottrazione dall'epoca (la forma di `resample_tf`), e blindata da un test che prova
+`ns/us/s`. *La regola che stavo cablando e' quella che stavo violando.*
+
+**La guardia** (era "raccomandata e non cablata"): `monitor_health` ha ora lo stato
+**PREMATURO** — ultima barra che chiude DOPO l'mtime del file, grazia 5 min. Derivata dalle
+spec esistenti (P1), con `open_labeled=False` per `collect_chain` che timbra i giri, non barre
+(P14: senza il flag avrebbe allertato sempre). Controllo positivo sul dato vivo: **ha segnalato
+esattamente i 5 rotti e taciuto sui 2 sani** prima della rigenerazione; dopo, 7/7 OK.
+
+**La rigenerazione** (`scripts/live/paper_regen.py`): stesso `start_ts` pre-registrato, config
+congelata, replay del codice di produzione riparato — il metodo validato due volte dall'audit
+del 22/08 (0 barre chiuse cambiate su 1.427/1.488 + 6/6 al bit). Vecchi file archiviati come
+`*.pre_regen_20260826.*` (evidenza del difetto, nel perimetro di backup). **Nessuna data di
+gate si sposta.**
+
+| monitor | barre | Sharpe rotto → vero |
+|---|---|---|
+| `paper_statarb` (gate **27/09**) | 58 → 57 | **+1,95 → −1,61** — il ribaltamento previsto dall'audit |
+| `paper_dvolspread` (kill 24/10) | 32 → 31 | −14,73 → −4,41 |
+| `paper_xsr` (gate 23/10) | 32 → 31 | −4,98 → −2,72 |
+| `paper_prevday` | 1584 → 1584 | +0,39 → +0,40 |
+
+`paper_portfolio` **non** rigenerato (gamba GTAA su ADJUSTED_LAST ri-aggiustato: il replay non
+sarebbe la serie registrata — P12); tolta la sola coda non chiusa, cosi' la guardia non resta
+accesa per sempre su un difetto gia' riparato (P14). Storia pre-fix dichiarata corrotta.
+
+## §5.12 — un test non puo' piu' scrivere nel libro di bordo vivo
+
+`tests/conftest.py`: oltre al watermark, ora deviati **`trades.db`** (wrapper su `connect` —
+il default e' catturato alla definizione, patchare la costante non serviva a niente) e
+**`docs/journal/`** (pagine tracciate da git). Per `book_executions.jsonl`, che i test caricano
+ad-hoc con importlib e conftest non puo' raggiungere prima: **impronta a inizio suite, verifica
+a fine suite**, col falso positivo possibile (fill reale del cron :47 durante la suite)
+dichiarato nel messaggio.
+
+## §5.5 — il test di leva e' CANCELLATO, non aggiustato
+
+`test_leva_massima_da_config_resta_sotto_o_uguale_a_1x` misurava `frac x n_asset`: con una
+chiave di scala la grandezza vera diventerebbe `frac x n_asset x scala` e il test avrebbe
+continuato a passare smettendo di controllare. Al suo posto una nota che rimanda al tetto sul
+PRODOTTO di GATE SCALA-01, da cablare nel codice che leggera' la chiave, quando esistera'.
+
+## §5.9 — il test rosso non segnalava un guasto: segnalava una banda scritta male
+
+`r0826_skh_band_drift.py` — feed tagliato a date crescenti, stesso codice di produzione:
+
+| taglio | Sharpe hold-out |
+|---|---|
+| 02/07 (audit) | **1,6376** — riproduce l'audit |
+| 25/07 (banda cablata) | 1,5751 |
+| 01→15/08 | 1,566 → 1,547 (scivola piano) |
+| **22/08** | **1,8966** |
+| oggi | 1,9306 — riproduce il rosso |
+
+**Il dato regge** (in-sample 1,424 **identico su ogni taglio**; il taglio all'epoca riproduce
+l'epoca). Il codice non c'entra. 📌 **La scoperta vera: la SOLA settimana 15-22/08 (rally ETH
+con SKH01 long) vale +0,35 di Sharpe hold-out** — il numero e' cosi' fragile, e chi cita
+"hold-out 1,9" oggi citerebbe 1,55 di una settimana fa. Coerente con §2: l'hold-out canonico
+di SKH01 era gia' il numero da non citare.
+
+**La riparazione:** il test ora **taglia il feed al 02/07** e verifica la riproduzione stretta
+(±0,02) di full/in-sample/hold-out/maxDD. Si rompe se cambiano codice o dato sulla finestra
+congelata — e per nessun altro motivo. La deriva del vivo non e' affare suo: per quella ci
+sono i monitor (e da oggi la guardia PREMATURO).
+
+Nel farlo, un altro inciampo istruttivo: la prima esecuzione del drift stampava **sette righe
+identiche** — `run_asset` memoizza in un dict di modulo (`_CACHE`), non in `lru_cache`, e lo
+svuotamento non lo toccava. Anche il test riparato ora pulisce quel dict, prima E dopo, per
+non avvelenare gli altri test.
+
+## Conseguenze sui gate (nessuna data si muove)
+
+- **STATARB 27/09**: il monitor ora misura la serie vera (**−1,61** a oggi). Coi criteri
+  pre-registrati invariati, a oggi punta al RITIRO — si legge quel giorno, non prima.
+- **XSR01 23/10 / DVOLSPREAD 24/10**: metrica primaria finalmente su serie reali.
+  Restano i difetti dichiarati (§5.3 pavimento del gate XSR01; veto DVOLSPREAD ora sorvegliato
+  dalla guardia).

docs/diary/2026-08-26-usdc-rewards.md

@@ -0,0 +1,58 @@
+# 2026-08-26 — USDC Rewards su Deribit: il prodotto esiste, il conto NON li riceve
+
+**Domanda dell'operatore:** *"con 5k non si possono far partire altre strategie/investimenti?"*
+→ unica pista compatibile con "100% Deribit fino a $20k": rendimento sull'USDC fermo (il libro
+e' flat il 75% dei giorni del 2026, e la misura del 25/08 dice che un 3,7-4% su quel capitale
+vale quanto tutto XSR01).
+
+## Il prodotto (verificato SUL VENUE prima che sulle fonti, N10)
+
+- API pubblica `public/get_currencies`, 2026-08-26: **USDC `apr: 3.4`** · USDE `apr: 4.0` ·
+  USYC nel pool cross-collateral · haircut cross-collateral USDC **0%** → il saldo matura
+  MENTRE fa da margine, nessun lock.
+- Fonti (Deribit Insights): programma "USDC Rewards" dal 15/07/2025 — Deribit custodisce
+  presso Coinbase, Coinbase paga, Deribit gira agli **utenti di giurisdizioni autorizzate**
+  (lista non pubblicata). Maturazione sul **minimo di equity USDC delle 24h** (00:00 UTC),
+  pagamento mensile in unica soluzione nei primi ~14 giorni del mese successivo. Tasso
+  variabile (4% a lug 2025, 3,4% oggi).
+
+## La verifica empirica: il conto NON li riceve
+
+L'operatore era da cellulare → verifica indiretta sulla NOSTRA serie equity oraria
+(`data/live/trades.db`), che su libro flat e' piatta salvo accrediti:
+
+| finestra | letture | equity | salti orari ≥$0,40 | reward atteso |
+|---|---|---|---|---|
+| 01-14 lug (paga giugno) | 326 | $598,06 → $598,49 | 1 (= il fill ETH del 14/07) | ~$0,65 — **assente** |
+| 01-14 ago (paga luglio) | 334 | $596,92 → $597,12 | **0** | **~$1,70-2,00 — assente** |
+
+Un accredito da $2 su una serie che si muove di $0,20 in due settimane sarebbe stato
+inequivocabile. **Due mesi indipendenti, stesso esito: nessun reward.**
+
+## VERDETTO (stesso giorno, poche ore dopo): l'Italia e' ESCLUSA PER LEGGE — pista chiusa
+
+La causa non era il conto ma **MiCA**: il regolamento UE vieta la remunerazione dei token di
+moneta elettronica, e **Coinbase — che e' chi paga i reward del programma Deribit — ha cessato
+i reward USDC in tutta l'EEA dal 2024-12-01** proprio per questo. Conferme indipendenti:
+(a) l'espansione Deribit del 2026-08-01 aggiunge **80 paesi, nessuno EEA**; (b) il transaction
+log del conto non ha MAI avuto una voce reward (misurato stamattina su due mesi). **Nessun
+ticket necessario: la risposta e' normativa, non di supporto.** Cade anche la domanda fiscale.
+
+⚠️ **Episodio di sicurezza, registrato perche' non si ripeta.** L'operatore ha chiesto dei
+reward in una chat dove due sedicenti agenti ("Matt Andreas [MOD]", "Tom Mavencourt") hanno
+risposto a copione — stessa domanda fuori tema due volte, scuse per un "guasto" mai segnalato,
+l'avviso "beware of impersonators" usato per comprarsi fiducia — e l'affermazione
+**"Yes, Italy is supported for USDC rewards": FALSA** (un agente Deribit vero sa che l'EEA e'
+esclusa). Pattern coerente con lo script dei wallet-drainer: trattenere in chat, poi chiedere
+"verifica" (link/2FA/chiavi API/schermo). Regola permanente: il supporto passa SOLO
+dall'app ufficiale o da support.deribit.com; nessun codice, chiave o link, mai; una
+risoluzione vera non richiede azioni dell'utente.
+
+## Cosa resta della pista "rendimento sul capitale fermo"
+
+- **USDC rewards: morta** per residenti EEA finche' MiCA resta cosi'.
+- **USDE (Ethena, apr 4.0 dall'API)** come collaterale: non e' un EMT, MiCA non lo vieta allo
+  stesso modo — ma ha rischio proprio (depeg, basis-trade, Ethena GmbH chiusa dopo BaFin).
+  Se si apre, va da candidato: misura + gate + verifica C6 sul NOSTRO conto.
+- **USYC**: probabile riservato a istituzionali — da verificare prima di parlarne.
+- Altrimenti vale N3: a questo capitale la leva vera restano i versamenti.

docs/diary/2026-08-26-usde-analisi.md

@@ -0,0 +1,105 @@
+# 2026-08-26 — USDE come collaterale a rendimento: analisi da candidato
+
+**Domanda dell'operatore:** *"analizziamo usde"* — dopo la chiusura della pista USDC rewards
+(Italia esclusa da MiCA). **Script:** `scripts/research/r0826_usde_scenari.py` (N11).
+
+## Verificato SUL VENUE (API pubblica, oggi — N10)
+
+- `apr: 4.0` per USDE (era "fino a 9%" al lancio 03/2025: tasso = APR settimanale Ethena − 5%
+  di fee Deribit; comprime coi funding) · reward **giornalieri** ~12:00 UTC sul minimo di
+  equity USDE, voce nel Transaction Log → **falsificazione in 24-72h**
+- spot `USDE_USDC` attivo: spread osservato **~3 bps**, fee spot **zero**
+- **haircut cross-collateral 10%** (USDC 0%): il 90% fa margine — al nostro profilo di leva
+  (max realizzata 0,52x su tetto 1,0x) **non morde**
+- **indice `usde_usd` multi-exchange con mediana e clamp ±0,5%** — NON il book interno:
+  è la differenza strutturale dal caso Binance del 10/10/2025 ($0,65 dall'oracle sul proprio
+  book da $8M mentre USDe quotava ~$0,99 altrove, riscatti regolari, peg tornato in 8h)
+- eligibilità **per residenza, lista non pubblica** → si verifica sul CONTO, non sui documenti
+  (la lezione USDC di stamattina)
+
+## Rischi dichiarati (p non stimabile → si controlla con la QUOTA, N4)
+
+R1 **emittente**: basis trade (staking + short perp); fallimento = fino a −100% della quota —
+si SOMMA al rischio venue accettato il 26/07, non lo sostituisce. R2 **marcatura in crash**
+(P10: l'accoppiamento — il mark scende proprio quando il libro è lungo). R3 **tasso**: 9→4%
+in 17 mesi; funding negativi prolungati → ~0. R4 **regolatorio EU** (Ethena GmbH liquidata
+dopo BaFin; USDe non è EMT MiCA — per questo PUÒ pagare dove USDC non può).
+📌 Nota a favore da misurare se si procede: il rendimento USDe sale coi **funding positivi**,
+cioè quando il nostro libro long li PAGA (−2,16%/anno): sconto parziale correlato sulla tassa
+di funding.
+
+## L'aritmetica (dallo script)
+
+| equity | quota 50% rende | −100% costa | note |
+|---|---|---|---|
+| $2.065 | $41/anno | $1.032 | conversione ripagata in ~3 giorni |
+| $5.065 | $101/anno | $2.532 | scenario post-versamento |
+| $20.000 | $400/anno | $10.000 | dove la posta diventa seria |
+
+Mark −1% = 3 mesi di resa · −3,5% = 11 mesi · **−100% = 25 anni: non si recupera mai**
+→ la leva di controllo è la **quota**, non il tasso.
+
+## PROPOSTA (pre-registrata qui, esito da scrivere sotto)
+
+**Test di eligibilità sul conto**: convertire **~$500 USDC→USDE** (costo <$0,20 totale),
+tenere **3 giorni**, guardare il Transaction Log alle ~12:00 UTC (reward atteso ~$0,05/g).
+Regola dichiarata PRIMA di vedere l'esito: **≥1 voce reward in 3 giorni → idoneo**, e si apre
+la decisione di quota (con un gate: quota massima, chi la decide, cosa la riapre);
+**0 voci → non idoneo**, si riconverte e la pista si chiude come l'USDC.
+L'esecuzione è dell'operatore (app: Spot → USDE/USDC) o autorizzata esplicitamente via gateway.
+Il libro non c'entra: nessun codice del percorso soldi viene toccato dal test.
+
+## ESECUZIONE DEL TEST (stesso giorno, 13:04 UTC — autorizzata dall'operatore: "fai test")
+
+Ordine via gateway, limit marcabile con banda di sicurezza sul prezzo (0,995-1,005):
+**500 USDE @ 1,0003, filled, fee 0** (`USDE_USDC-8977542793`). Costo totale ~$0,15.
+Prima finestra utile di reward: ~**28/08 12:00 UTC** (il calcolo usa il minimo di equity
+USDE della finestra); verifica finale il **29/08**: ≥1 voce reward nel Transaction Log →
+idoneo; 0 voci → si riconverte e la pista si chiude.
+
+🚨 **DIFETTO TROVATO E RIPARATO DURANTE IL TEST — il test valeva gia' per questo.**
+`shadow._equity` leggeva SOLO il conto USDC: dopo la conversione il book avrebbe visto
+$1.556 (−24,3%) al giro delle 13:47 → falso 💰 "USCITA DI FONDI" **e vendita indesiderata
+di ~$140 di posizioni** (i target scalano con l'equity). Riparato in 35 minuti, prima del
+giro: `_collaterale_usde()` valuta l'USDE all'**indice pubblico** `usde_usdc` (mediana
+multi-exchange — la lezione Binance 10/10), con tre proprieta' blindate da 6 test nuovi
+(`tests/test_shadow_usde.py`): un **depeg PASSA nel sizing** (mai nascosto), sopra la pari
+si **clampa a 1,0**, indice illeggibile → **1,0 dichiarato, mai 0** (contare 0 ricreerebbe
+il falso −24%: il fallback si sceglie sul danno, P5). Verificato live: equity vista dal
+book $2.055,88 ("mainnet USDC + USDE 500 @ 0.9999").
+*Un test da $500 progettato per misurare l'eligibilita' ha scoperto che il book era cieco
+al cross-collateral: se la prima conversione fosse stata fatta a quota vera, l'errore
+sarebbe costato caro. I test piccoli esistono per questo.*
+
+*Esito eligibilita': (da scrivere entro il 29/08)*
+
+## STRUTTURA (stesso giorno, ~14:20 UTC — "struttura il progetto per gestire subito usde")
+
+La patch d'emergenza delle 13:07 e' diventata struttura di prima classe:
+
+- **`config/live.json` sezione `usde`** — l'unica autorita' sui parametri (P1): `index_name`,
+  `haircut` 0.10, `quota_max_frac` 0.50 (tetto di ALLERTA — la quota effettiva la decide
+  l'operatore), `depeg_warn` 0.99 / `depeg_crit` 0.95 coi **criteri dichiarati** in `_nota_usde`
+  (P6: warn = fuori dalla banda spot ~3 bps e oltre il clamp ±0,5% per fonte dell'indice;
+  crit = meta' del buffer di haircut consumata).
+- **`src/live/usde.py`** — modulo unico per config, catena di prezzo (indice pubblico → ticker
+  spot → 1,0 dichiarato) e valutazione `valuta()` PURA. `shadow._collaterale_usde` ora DERIVA
+  da qui (niente ridichiarazioni); i 6 test di shadow passano invariati.
+- **`scripts/live/usde_watch.py`** + `cron_usde.sh` alle **12:35 UTC** (dopo la finestra reward
+  ~12:00, fuori da :00/:25/:47) — sola lettura: (1) **reward per DELTA di equity al netto dei
+  trade spot** (il gateway non espone il Transaction Log; un delta con trade nel mezzo si
+  dichiara, trade illeggibili → delta NON attribuito, P12); (2) **depeg**: 🚨 solo sotto crit
+  e ripetuto, ⚠️ warn/quota/BLIND solo alla transizione (P9); (3) **quota sul totale**, che
+  allerta anche per deriva PASSIVA (il libro perde → la quota sale da sola, N4). Applica il
+  **verdetto pre-registrato** (≥1 reward entro il 29/08 → IDONEO; zero → riconvertire) invece
+  di lasciarlo a un promemoria. Limite dichiarato: cadenza giornaliera, un depeg intraday puo'
+  sfuggire all'ALLERTA — ma non al SIZING, che legge l'indice a ogni giro orario del book.
+- **Serie `data/live/usde_watch.jsonl`** — dentro il perimetro di backup, `ts` in ms epoch →
+  sorvegliata da **`monitor_health`** (max_age 30h, `open_labeled=False`): un watch fermo
+  spegnerebbe gli allarmi depeg e il silenzio si leggerebbe come "va tutto bene" (P5).
+- **Baseline registrata alle 14:17:52Z**: 500 USDE @ 1,0000 (indice) = $500,00 · quota 24,3%
+  (tetto 50%) · margine utilizzabile ~$2.008 · verdetto IN_ATTESA. E' la lettura che rende
+  misurabile il delta del 28/08.
+- **Test: 775 passati** (+17 nuovi in `tests/test_usde_watch.py`: valutazione condivisa,
+  rilevatore reward, verdetto — incluso che NON anticipa la scadenza del 29/08 —, condizioni
+  di allerta, `px=None` che non finge un depeg).

docs/diary/2026-08-26-xsr01-gate-riscritto.md

@@ -0,0 +1,44 @@
+# 2026-08-26 — Gate XSR01 (23/10): riscrittura DICHIARATA, decisa dall'operatore
+
+**Decisione dell'operatore** (oggi, discussione in sessione): opzione **A** fra le tre proposte —
+riscrivere ora il gate, dichiarandolo, invece di lasciarlo e citare i difetti (B) o ritirare
+XSR01 in anticipo (C, che avrebbe violato la pre-registrazione).
+
+Il docstring del gate prescrive: *"ogni modifica va motivata nel diario come violazione"*.
+Questa e' quella motivazione. **Scritta a 58 giorni dalla decisione, prima di vederne l'esito,
+e in direzione che STRINGE i criteri** — le tre proprieta' che rendono una riscrittura
+difendibile invece che selection-on-forward.
+
+## Le tre modifiche
+
+1. **Capitale per il deploy: $5.000 → $20.000.** Non e' tuning: il gate fu scritto il 25/07,
+   e il 26/07 l'operatore ha preso la decisione vincolante *"100% Deribit fino a $20k"* —
+   posteriore, quindi governa (M28: quando due impegni si contraddicono, la contraddizione e'
+   informazione). Il criterio a $5k autorizzava capitale su Hyperliquid che un'altra decisione
+   gia' vietava. Ora il deploy di XSR01 e la riapertura della scelta del venue coincidono a
+   $20k: **una decisione sola, un punto solo**.
+2. **Gamba haircut: il numero decisivo viene da uno script committato** —
+   `r0826_xsr_haircut.py` (N11: il "$14,41" dell'ammissione non aveva script ed era ~2,4x
+   ottimista), **a pavimento $10** (il pavimento vero misurato da HL-EXEC; il libro REAL-$5000
+   del monitor gira a $5 ed e' ottimista per costruzione), **citato accanto alla frazione di
+   ordini eseguiti** (P7). Misurato oggi, ed e' la conferma empirica del difetto dello
+   strumento: sul FULL a pavimento $10 l'haircut e' **−1,1%** con **il 22% di ordini
+   eseguiti** — la guardia non puo' quasi scattare per costruzione, perche' un libro che non
+   si muove ha haircut piccolo. **La soglia resta il 40% pre-registrato: nessuna soglia nuova
+   viene scritta oggi coi dati in mano.**
+3. **Contesto corretto:** il riferimento `IS_SHARPE_NET = 1.82` era una terza lente
+   (XSR-REPRO): ora cita **1,79**, lente dei gate alla scoperta. Il criterio non cambia.
+
+## I numeri di oggi (58 giorni alla decisione — NON decidono niente)
+
+- forward rigenerato (serie vera dal 26/08): **31 barre, Sharpe −2,72**, maxDD 0,8%
+- ticket per gamba a $5.000: mediano **$3,34**, medio $5,99, 63% sotto $5, **84% sotto $10**
+  (46.200 ordini replay) — riproduce XSR-REPRO e sostituisce il $14,41
+- haircut forward a pavimento $10: −10,7% (dentro la guardia), **ordini eseguiti 38%**
+- FULL 968 barre: MODELED Sharpe 2,12; floor $10 → haircut −1,1%, eseguiti **22%**
+
+## Cosa riaprirebbe XSR01 (registrato qui perche' non vada riscoperto)
+
+Capitale ≥$60k (per un 25% sopra C\*) · un venue con C\* più basso di $15-20k · una misura che
+mostri nel meccanismo qualcosa oltre la coppia (media, vol) — il null del 25/08
+(`r0825_xsr_rendita.py`) ha detto che oggi non c'e'.

docs/diary/2026-08-28-gtaa-fase-e-allarmi.md

@@ -0,0 +1,158 @@
+# 2026-08-28 — La fase che ruota, gli allarmi che si perdevano, e una risposta fiscale
+
+*Scritto il 2026-08-28. Numeri riprodotti dagli script citati; le letture in prosa sono firmate
+come tali (P13).*
+
+## In una riga
+
+Un test rosso su GTAA01 non parlava di GTAA01: parlava del fatto che **la finestra "congelata"
+pre-2015 rotola da sola ogni notte**. Nel frattempo si e' chiuso il debito del trasporto degli
+allarmi, e la prima delle due domande al commercialista ha trovato una risposta alla fonte.
+
+---
+
+## 1. Il gate (A) della banda GTAA01 e' una moneta — la finestra rotola
+
+`r0828_gtaa_band_phase.py`. Replica bit-exact della produzione verificata (max|Δ| = 0.00e+00 su
+7.544 barre). Codice fermo dal 07/08: nessun commit su `src/portfolio/gtaa.py` ne' su
+`r0727_gtaa_band_gate.py`. Si e' mosso il DATO.
+
+**(0) La finestra in-sample non e' ferma.** IB serve una finestra **rotolante di 30 anni**. SPY e'
+l'unica gamba al muro (30,0 anni) e nel `logs/cron_daily.log` la sua data d'inizio avanza di un
+giorno di borsa ogni notte: `1996-07-02` il 24/06 → `1996-09-04` oggi. QQQ e IWM arriveranno allo
+stesso muro fra **2,5 e 3,7 anni**.
+
+**(1) L'amplificatore e' la fase.** `_gated_returns` ribilancia su `i % every == 0`, dove `i` e' la
+**posizione nell'array**. Se la prima barra scivola, si ri-fasa ogni decisione di ribilanciamento
+di trent'anni di storia.
+
+| misura | valore |
+|---|---|
+| spostamento max dello Sharpe in-sample dal 07/08 (finestra CHIUSA, codice fermo) | **0,076** |
+| banda scelta al buio in 10 notti consecutive | 25% · 40% · 60% |
+| notti col margine sotto il pavimento dichiarato (0,01) | **4/10** (minimo 0,0026) |
+| a dato FISSO, muovendo solo la fase | 25% su 3 fasi, 60% su 2 |
+
+Il criterio decideva su ~0,007-0,015 di Sharpe mentre il rumore che lo scuote vale fino a 0,076.
+E' lo stesso modo di fallire del criterio a ranghi ritirato il 07/08 (che decideva su 0,00116), in
+un costume nuovo.
+
+## 2. Criterio (C): la mediana delle 5 fasi
+
+`r0828_gtaa_band_median_phase.py`. ⚠️ **Scelto DOPO aver visto la tabella delle fasi**: misura lo
+strumento, non valida la banda. Pavimento tenuto a 0,01, invariato.
+
+- (i) scelta stabile su 10 notti: **SI** — `60%` in tutte e dieci
+- (ii) margine sempre ≥ 0,01: **SI** — minimo 0,0197
+- (iii) potenza (al buio ≠ hold-out): **SI** — 60% contro 40%
+
+Escursione dello Sharpe in-sample su 10 notti: **−74/−99%** per ogni banda. Lo strumento regge.
+**Ma la cella che sceglie non e' la proposta:** al buio esce il 60%, il 25% vince **0 notti su 10**.
+Da tenere accanto: sull'hold-out il 60% e' **penultimo** (0,7430 contro 0,9315 del 40%), coerente
+con lo Spearman IS/OOS ~0 misurato il 07/08 — la scelta in-sample **non predice**.
+
+**Contorno che vale piu' del verdetto:** le 5 serie di fase correlano **0,988** → **N_eff 1,01**.
+La mediana di 5 fasi e' UNA osservazione: toglie l'artefatto, non compra precisione.
+
+### Le due domande che erano state confuse
+
+Il gate (A) puo' chiedere due cose diverse, e il 07/08 coincidevano **per fortuna di fase**:
+
+| forma | difetto | quanto e' grave |
+|---|---|---|
+| «la banda e' la scelta che si fa al buio?» | **non ha risoluzione** | cambia verdetto ogni notte |
+| «la banda non e' stata selezionata sull'hold-out?» | **non ha potenza** | 1 cella su 30 e' l'argmax dell'hold-out → **29/30 lo passano per costruzione** |
+
+📌 *Lettura (agente, fallibile).* Il 25% non viene dalla griglia affatto: viene dall'argomento
+**strutturale** del 27/07 — una banda in dollari assoluti degenera al variare del capitale, una
+frazione no. Sotto la mediana delle fasi il 25% e' **2° in-sample e 3° sull'hold-out**: decente
+ovunque, primo da nessuna parte, che e' la firma di un parametro NON selezionato sui dati. A un
+parametro scelto per ragioni strutturali non si applica un gate di *selezione* ma uno di
+*robustezza* — «fa danno da qualche parte?». Risposta: no.
+
+**Esito:** gate (A) **ritirato** come pass/fail, congelando il MOTIVO (come il 07/08), piu' una
+guardia sulla CAUSA che si rompe il giorno che la fase venisse ancorata al calendario.
+
+## 3. Cosa cambia togliendo GTAA01 — e la decisione dell'operatore
+
+`r0828_senza_gtaa.py`. Portafoglio di **ricerca** a 5 sleeve; NON il book live.
+
+| | Sharpe | CAGR | maxDD | vol |
+|---|---|---|---|---|
+| CON GTAA01 | **2,28** | +19,2% | 6,1% | 7,8% |
+| SENZA, iso-nozionale | 2,16 | **+23,8%** | 7,8% | 10,1% |
+| SENZA, **iso-rischio** (×0,77) | 2,16 | +18,0% | 6,0% | 7,8% |
+
+A iso-nozionale togliendolo si guadagna **drift** e si compra **volatilita'**. A iso-rischio — la
+sola lente onesta per un diversificatore a basso CAGR (M6) — **Δ Sharpe +0,121**, maxDD invariato.
+Hold-out 2025+: **Δ +0,247**. Aiuta in **6 anni su 8**. Correlazione col resto **+0,087**: e'
+davvero altro. Standalone Sharpe 1,06, CAGR +5,8%.
+
+⚠️ **Con la sua fascia di fase:** il Δ sulle 5 fasi va da **+0,095 a +0,124** e supera la soglia
+dichiarata (0,12) in **2 fasi su 5**. Il **segno e' stabile**, il verdetto **binario** no.
+
+### La decisione: rinviata a $15k di book
+
+Discussa con l'operatore. L'argomento che ha deciso non e' «GTAA01 non contribuisce» — la misura
+dice il contrario — ma che **a questo capitale lo sleeve non e' accendibile**: `GTAA_MIN_CAPITAL`
+e' **$3.000 allocati**, che al peso 20% significa **$15.000 di book** contro i **$2.068** attuali.
+Sotto quella soglia e' manutenzione senza beneficio incassabile.
+
+Due ragioni registrate **contro** il blocco immediato, entrambe regole del progetto:
+- **N7** — uno sleeve difensivo si giudica **sul sinistro, non sul premio**, e la finestra
+  2019-2026 non contiene il sinistro per cui esiste un GTAA a sei gambe;
+- **N4** — il rischio di venue si compra con un **conto**, non con uno sleeve: togliere GTAA01
+  renderebbe il portafoglio di ricerca **100% cripto su un venue solo**.
+
+E un costo che sarebbe andato pagato, non saltato: GTAA01 e' uno dei **quattro** nomi di
+`r0726_wall_fixedpoint.W_DEPLOY`, da cui escono i **$313k** e tutta la pianificazione da €500/mese.
+
+**Perche' la decisione non si dimentichi** (N9), la soglia e' sorvegliata dal giornale:
+`journal.SOGLIE_CAPITALE` legge l'equity ogni giorno e il giorno che supera $15k la voce lo dice,
+con la domanda da rispondere accanto. Stessa tabella, seconda riga: **$20k**, dove si riapre
+«100% Deribit fino a $20k».
+
+## 4. Allarmi: il marcatore «gia' detto» si scrive DOPO l'invio
+
+Debito §5.2 chiuso su decisione dell'operatore. `venue_watch.run_once` salvava lo stato coi
+marcatori `alerted` gia' a True e l'invio lo faceva il chiamante **dopo**: col 6,9% di invii
+falliti misurato (2/29), un 🚨 perso restava perso per l'**episodio intero** (200-2.324 ore).
+
+Ora il sender e' **iniettato** (la funzione resta testabile senza rete d'uscita, che era la ragione
+del disegno precedente) e su fallimento si disfano i **soli marcatori**, non le misure:
+asset in ALERT → ri-allerta l'ora dopo; lock MAINT/ALERT → flag azzerati **ma le ore continuano a
+correre**, cosi' una manutenzione che sfora la grazia sale ad ALERT anche col trasporto giu';
+lock RIENTRATO → stato ripristinato, perche' il rientro si annuncia una volta sola.
+`notify()` accetta `tentativi` (venue_watch: 3) e l'esito finisce nel log del cron.
+
+⚠️ Resta scoperto **ogni altro chiamante di `notify()`**: la disciplina e' oggi solo in venue_watch.
+
+## 5. L'analista del 27/08, e la riga di diagnosi che mancava
+
+La voce del 27/08 era senza analisi. Causa, dal transcript della sessione headless:
+`Failed to authenticate: OAuth session expired and could not be refreshed`, exit 1 alle
+`00:37:00.98Z`. La meccanica aveva retto (nessuna analisi vecchia spacciata per nuova, esito nel DB,
+notifica partita) ma il motivo registrato era `uscita 1: ` — vuoto: `interroga()` leggeva il solo
+**stderr**, e la CLI aveva scritto su **stdout**. Riparato (`motivo_uscita`), analisi recuperata.
+Guasto **transitorio**: il refresh token era valido, unico caso su 24 sessioni.
+
+## 6. Fisco: la domanda (a) ha una risposta alla fonte
+
+Circolare AdE **30/E del 27/10/2023**, letta direttamente dal PDF ufficiale. **I derivati con
+sottostante cripto stanno in `c-quater` → 26%**, non in `c-sexies` → 33%, e la circolare dice
+esplicitamente che la riforma 2023 non sposta nulla. Il **collaterale** sconta il **2‰** al 31/12
+(intermediario non residente → imposta sul valore delle cripto-attivita', ~$4/anno a questo
+capitale). E la conversione **USDC→USDE non e' fattispecie realizzativa**. Dettaglio e citazioni
+verbatim in CLAUDE.md §5.4. La (b), i payout di una prop firm, **resta aperta**.
+
+## Cosa cambia
+
+- `CLAUDE.md`: §3 nuova riga (GTAA01 rinviato a $15k) · §5.2 risolto · §5.4 riscritto · §5.13 nuovo
+  debito (la fase che ruota, quantificata e innocua oggi).
+- `src/live/journal.py`: `SOGLIE_CAPITALE` + regola `soglia_capitale`.
+- `src/live/venue_watch.py`, `src/live/notifier.py`, `scripts/live/venue_watch.py`: commit dopo l'invio.
+- `src/live/analista.py`: `motivo_uscita` da stdout E stderr.
+- `tests/test_gtaa_band_gate.py`: gate (A) ritirato, motivo e causa congelati.
+- Script nuovi: `r0828_gtaa_band_phase.py`, `r0828_gtaa_band_median_phase.py`, `r0828_senza_gtaa.py`.
+
+**Suite: 789 passati, 0 falliti.**

docs/diary/2026-08-29-usde-idoneo-e-ib.md

@@ -0,0 +1,67 @@
+# 2026-08-29 — USDE idoneo, la quota rinviata a lunedì, e il fix IB confermato
+
+*Scritto il 2026-08-29. Numeri letti dalle serie citate.*
+
+## 1. GATE USDE-01: CHIUSO **IDONEO**
+
+Il 2026-08-28 alle 12:35Z `usde_watch` ha rilevato il primo reward:
+
+```
+equity USDE : 500.0521 @ 1.0001 (indice) -> $500.05
+delta       : +0.052055 USDE dall'ultima lettura
+verdetto    : IDONEO — reward rilevato il 2026-08-28T12:35:01Z
+```
+
+La regola era pre-registrata il 26/08, **prima** dell'esito: ≥1 reward entro il 29/08 → IDONEO,
+e si apre la decisione di QUOTA, che è dell'operatore. Il gate ha fatto quello che doveva.
+
+## 2. Il tasso, e perché la quota è stata rinviata
+
+| lettura | tasso implicito |
+|---|---|
+| il solo pagamento (0,052055 su 500) | **3,80% annuo** |
+| su **due** finestre — il 27/08 ha pagato **zero** | **1,90% annuo** |
+| annunciato da Deribit (ricerca 26/08) | 9% |
+
+**Decisione dell'operatore (29/08): la quota si decide lunedì 31/08**, su tre-quattro finestre
+invece che su una. Il motivo è nella tabella: fra 3,80% e 1,90% c'è tutta la decisione, e il
+campione è **un pagamento**. Il costo dell'attesa è zero — i 500 USDE rendono comunque.
+
+📌 Perché il numero non venga letto male: `usde_watch.rendimento()` calcola l'APR sulle finestre
+**osservate**, col denominatore sul **tempo vero** e non sul numero di finestre pagate — così una
+finestra che non paga **abbassa** la stima invece di sparire (P5: quel silenzio è uno zero). Le
+letture con trade nel mezzo si escludono (P12). L'APR si stampa sempre **col suo `n`**, e sotto
+4 finestre la riga dice *«un pagamento non è un tasso»*. Sulle letture vere di oggi:
+**1,97% annuo su 1,9 giorni, 1/2 finestre pagate**.
+
+📌 Perché la decisione non si dimentichi (N9): `quota_da_decidere()` è vera **solo** se il conto è
+IDONEO **e** il rinvio è scaduto. Da lunedì il watch manda il 📌 **ogni giorno** — con quota
+attuale, tetto di allerta e APR osservato accanto — finché non si decide. Si smette togliendo
+`DECISIONE_QUOTA_DAL`. È lo stesso schema della soglia $15k di GTAA01, con la data al posto
+del capitale.
+
+⚠️ Nota di contorno che vale una lezione: il 📌 dell'IDONEO era partito su Telegram il 28/08 alle
+12:35Z, **in mezzo ai messaggi-spazzatura dei test** delle 14:47 e 14:52 (difetto riparato lo
+stesso giorno). L'unico messaggio che contava è arrivato nel giorno in cui il canale era sporco.
+È P9 in forma concreta.
+
+## 3. Il fix IB è confermato
+
+Il giro del cron delle 00:30 di stanotte: **zero** righe `open orders request timed out` (erano
+2 per giro, 63 giri su 63) e tutti e sei gli ETF scaricati — `SPY n=7541`, `QQQ n=6912`,
+`IWM n=6602`, `TLT n=2658`, `GLD n=5476`, `HYG n=4877`, aggiornati al 28/08. Il `readonly=True`
+resta.
+
+📌 E una conferma involontaria del debito §5.13: **SPY è passato da `1996-09-04` a `1996-09-05`**.
+La finestra rotolante ha perso un altro giorno di borsa in una notte, esattamente come misurato
+il 28/08 — il difetto si legge a occhio nudo nel log del cron.
+
+## Cosa cambia
+
+- `scripts/live/usde_watch.py`: `rendimento()` (APR sulle finestre osservate, col suo n) ·
+  `quota_da_decidere()` · `DECISIONE_QUOTA_DAL = "2026-08-31"` · il 📌 giornaliero da lunedì.
+- `tests/test_usde_watch.py`: 6 test nuovi, incluso il controllo positivo (*la finestra sola
+  darebbe il doppio*) che è la ragione per cui l'APR si stampa col suo `n`.
+- `CLAUDE.md`: §1 e §4 aggiornati — gate CHIUSO IDONEO, quota rinviata a lunedì.
+
+**Suite: 795 passati, 0 falliti.**

docs/diary/2026-08-30-usde-quota-tetto-venue.md

@@ -0,0 +1,318 @@
+# 2026-08-30 — "porta in USDE tutto il capitale che non viene usato": il venue dice 31%
+
+**Richiesta dell'operatore**, verbatim: *"porta in usde tutto il capitale che non viene usato"*.
+Arriva il 30/08, cioè **un giorno prima** della data a cui l'operatore stesso aveva rinviato la
+decisione di quota (gate USDE-01, rinvio al 31/08). L'anticipo è esplicito e vale come decisione.
+
+## 1. "Il capitale che non viene usato" non è una quantità piccola: è quasi tutto
+
+Stato letto dal gateway alle 19:50Z: USDC **$1.563,09** (di cui **$11,36** impegnati a margine),
+USDE 500,1757 → **$500,18**, totale **$2.063,26**, quota **24,2%**. Posizioni BTC $354,72 + ETH
+$213,36 = **$568,08** lordi (0,275x).
+
+Il margine consuma **$11 su $2.063**, e l'USDE è cross-collateral: convertirlo non lo toglie
+dall'uso. Anche a piena esposizione del libro (lordo 1,0x) il margine sarebbe ~$41. Presa alla
+lettera la richiesta è una quota **~99%** — il 100% che il gate esclude per nome ("mai 100%: R1
+emittente non recuperabile"). Le due letture plausibili ("non a margine" e "non esposto dal libro")
+convergono entrambe su ~97-99%: non è un'ambiguità che si risolve scegliendo, è una che si porta
+all'operatore.
+
+## 2. Il vincolo che `r0830_usde_quota` non aveva guardato: il cuscino di REGOLAMENTO
+
+L'analisi del 30/08 aveva misurato il **margine** e concluso — correttamente — che l'haircut non
+morde a nessuna quota fino al 90%, nemmeno a leva 1,50x con USDE a 0,95. Vero, e irrilevante:
+il P&L e il funding dei perp **USDC-lineari si regolano in USDC**, non nel collaterale. Lo si vede
+nel conto: `equity − balance = $7,24` di floating, tutto nel secchio USDC.
+
+A quota ~99% resterebbero **$41 di USDC** contro un libro che, col disaster-SL a −30% sulla massima
+esposizione, può perderne **~$619**: il saldo va negativo e Deribit lo finanzia a interesse, che si
+mangia la resa che si stava comprando. **Il vincolo non è il margine, ma non è nemmeno assente.**
+
+> 📌 **Corretto e QUANTIFICATO il 31/08** (KB *Cross collateral specifications*): «*a collateral fee
+> will be charged […] **default = 0.05% per day***», al secondo, sulla valuta negativa — cioè
+> **18,25%/anno, 4,3× la resa USDE** che si starebbe comprando. Il ribilanciamento automatico non
+> salva: scatta a **$1M** assoluti o al **100% della cross equity**, soglie irraggiungibili a $2k.
+> Qui il 30/08 avevo scritto «lo finanzia a interesse» **senza il numero**: il numero rende il
+> criterio del cuscino più giustificato, non meno.
+
+Criterio dichiarato: cuscino USDC ≥ disaster-SL sulla massima esposizione lorda del libro =
+`n_asset × frac × disaster_sl_pct` = 2 × 0,5 × 0,30 = **30% dell'equity** — tutto derivato da
+`config/live.json` e `src/live/book.py`, mai ridichiarato (P1). Che lascia esattamente **70%**.
+Non è un argmax (M8): la quota massima e il criterio coincidono per costruzione, e infatti il 70%
+cade **esattamente sul limite, con zero slack**.
+
+Tabella portata all'operatore (APR allora creduta 3,26% [1,13-4,51], n=4 — vedi §5, è sbagliata):
+
+| quota | converti | USDC che resta | resa/anno | evento emittente vs maxDD libro |
+|---|---|---|---|---|
+| 24,2% (allora) | — | $1.563 | $16 | 3,1× |
+| 50% | $531 | $1.032 | $34 | 6,3× |
+| **70%** | **$944** | **$619** | **$47** | **8,8×** |
+| ~99% | $1.522 | $41 | $66 | 12,3× |
+
+**Scelta dell'operatore: 70%**, il massimo compatibile col cuscino.
+
+## 3. Esecuzione: da 500 a 644 USDE, poi il muro
+
+Nuovo attrezzo **`scripts/live/usde_convert.py`** (dry-run di default). Non passa da
+`DeribitTrader`: `execution.ALLOWED` ammette solo i due perp del libro ed è il guardrail
+anti-fat-finger del percorso soldi — **non si allarga** per farci entrare uno spot che col libro
+non c'entra. Lo script porta le proprie guardie: banda prezzo [0,995 – 1,005], tetto HARD di quota
+0,95, il cuscino di regolamento, dry-run.
+
+Convertiti **+144 USDE** (500,1757 → **644,175691**), quota **24,24% → 31,21%**, tutti i fill a
+1,0002-1,0003, **fee 0**. Poi ogni acquisto ha smesso di passare.
+
+## 4. `not_enough_funds_in_currency` è un messaggio FUORVIANTE — la cronaca delle ipotesi sbagliate
+
+Si tiene apposta, perché chi rilegge non deve rifare questo giro. Tre ipotesi, tutte plausibili,
+tutte sbagliate:
+
+1. **"È la taglia."** 943,98 rifiutato per `Invalid params` → vero: `min_trade_amount: 1` e
+   `contract_size: 1`, il passo è **intero** (confermato da `public/get_instrument`; il gateway
+   non espone quel tool, la risposta è arrivata dall'API pubblica). Quantizzato a intero: 933
+   rifiutato per **fondi**, con **$1.541 disponibili**. Falso indizio.
+2. **"È il rate-limit."** 100 passava e 300 no; poi anche **1** rifiutato otto volte di fila.
+   Aggiunto backoff sul tempo fino a 90s: rifiutato lo stesso. Falso.
+3. **"È il prezzo."** Diagnosi a tre ordini da 1 USDE: SELL @1,0000 OK, BUY **@1,0003 OK**,
+   BUY @1,0002 e BUY market rifiutati. Vero **in parte**: il book REST pubblico è in **ritardo**
+   sul matching engine, e un limite a `ask+1 tick` a volte non incrocia davvero. Difetto mio, e
+   istruttivo: prezzavo l'ordine sull'**indice** invece che sul **book**. Sono due prezzi con due
+   mestieri — l'indice **marca** il collaterale (`usde.valuta`, mediana multi-exchange: la lezione
+   Binance 10/10), il book **prezza** lo scambio. Corretto con 5 tick di margine e tetto duro
+   1,0010: il fill avviene al prezzo del libro, quindi il margine non si paga.
+
+Ma corretto il prezzo, **200 e 800 continuavano a fallire con 4.552 di profondità all'ask**.
+
+## 5. 🚨 Il fatto vero: un TETTO DEL VENUE sull'USDE, a 644,175691 (31,21%)
+
+Esperimento **a saldo neutro**, quattro ordini di fila (20:14Z):
+
+```
+BUY  20 @1.0007 -> not_enough_funds_in_currency    USDE 644.1757
+SELL 20 @0.9996 -> OK                              USDE 624.1757
+BUY  20 @1.0007 -> OK                              USDE 644.1757
+BUY   5 @1.0007 -> not_enough_funds_in_currency    USDE 644.1757
+```
+
+È un **tetto sul LIVELLO**: non taglia, non prezzo, non liquidità, non cadenza, non fondi
+($1.408 disponibili). Lo stesso ordine che viene rifiutato passa subito dopo una vendita di pari
+taglia. **La quota del 70% non è raggiungibile**, e nemmeno il 50%.
+
+La formula del tetto **non è leggibile da qui**: `public/get_currencies` non espone un cap
+(`in_cross_collateral_pool: true`, nient'altro), e il gateway non espone né `get_order_book` né
+`available_withdrawal_funds` — è il debito #11, il gateway è l'unico pezzo della catena che
+possediamo e si ha solo quel che espone. Registrato come fatto misurato, non spiegato (D5: un buco
+quantificato è un risultato, uno taciuto è un debito).
+
+## 6. 🚨 E la resa non è quella che credevamo: **l'USDC paga 3,40%**
+
+`public/get_currencies`, letta oggi:
+
+| valuta | APR pubblicata |
+|---|---|
+| USDE | **4,1071%** |
+| USDC | **3,4000%** |
+
+I nostri reward USDE misurati (+0,052055 · +0,061815 · +0,061821 al giorno su 500 → **~4,5%/anno**)
+**confermano** che la APR pubblicata di USDE è reale. Il che rende credibile anche l'altra riga.
+
+Se l'USDC frutta già 3,40%, il guadagno del passaggio a USDE **non è il tasso: è lo spread**,
+**0,71 punti**. Sui $644 che teniamo vale **~$4,6/anno**, non $21; sui $144 convertiti oggi,
+**~$1,0/anno**. Il gate USDE-01 ha misurato con cura il reward dell'USDE e **non ha mai chiesto
+cosa facesse l'USDC fermo**: è il controfattuale mancante — M1 in un'altra veste, si giudica il
+**marginale**, non il livello. E cambia il verso della decisione: si prende un rischio emittente
+**non recuperabile** (a 31,2% vale 3,9× il maxDD dell'intero libro) per **0,71 punti**.
+
+⚠️ **Quello che NON è dimostrato:** che la APR USDC sia effettivamente accreditata *sul nostro
+conto*. Sull'USDE l'abbiamo vista arrivare per delta; sull'USDC il P&L di trading copre $0,13/giorno
+di interesse e il gateway non espone il Transaction Log. **Va verificato su un giorno senza trade
+prima di trattarlo come misura** — qui è una APR pubblicata dal venue più una conferma indiretta,
+non un reward osservato.
+
+## 7. Cosa resta a terra
+
+- **Conto**: USDC $1.419,61 · USDE 644,175691 ($644,18) · totale **$2.063,79** · quota **31,21%**.
+  Nessun ordine spot appeso (restano i due `tp01-disaster` reduce_only). Posizioni invariate.
+  Equity vista dal book **$2.063,86** ("mainnet USDC + USDE 644 @ 1.0000"): sizing corretto,
+  nessun falso "uscita di fondi".
+- **`config/live.json`**: aggiunto `quota_target: 0.70` (la decisione dell'operatore, oggi bloccata
+  dal venue). `quota_max_frac` alzato a 0,85 e **rimesso a 0,50** nella stessa sessione: la soglia
+  larga presupponeva un 70% che non esiste, e lasciarla avrebbe **disarmato la guardia per uno
+  scenario che non si è verificato. Con la quota reale al 31%, il 50% morde di nuovo.**
+- **Non fatto**: portare la quota al 70%. Il venue non lo consente. Non è una rinuncia
+  discrezionale, è un rifiuto misurato e riproducibile.
+
+---
+
+# APPENDICE (stessa sera, 23:40-23:55Z) — **l'USDC NON frutta sul nostro conto: §6 era sbagliata**
+
+Richiesta dell'operatore: *"verifica se l'USDC frutta davvero sul nostro conto"*. Verificato.
+**La risposta ribalta la §6 di questo stesso diario**, che va letta con questa appendice accanto.
+
+## Perché la domanda sembrava dover aspettare, e invece no
+
+Il gateway non espone il Transaction Log (provati `get_transaction_log`, `get_settlement_history`,
+`get_deposits`, `get_transfers`, `get_interest_history`: **tutti 404** — debito #11). L'unica serie
+storica del conto è `trades.db.equity`: **oraria ma arrotondata a 2 decimali**, e contiene il P&L
+non realizzato, che a posizioni aperte oscilla di ±$2-8/ora. $0,13/giorno di interesse ci sparisce.
+
+Poi la fonte ufficiale Deribit ha spostato il problema dal *rumore* al *calendario*:
+
+> «Every day at 00:00 UTC, Deribit calculates the **minimum equity** of USDC that a user has been
+> holding over the previous 24 hours. […] After the month is over, the rewards from each day are
+> summed together and **paid out as a single monthly payment early in the following month**.»
+> — `insights.deribit.com/education/usdc-rewards-now-paid-on-deribit/`
+
+**I reward USDC si pagano UNA VOLTA AL MESE**, non ogni giorno come quelli USDE. Ecco perché non li
+avevamo mai visti: guardavamo a cadenza giornaliera, dove l'USDE si vede e l'USDC per costruzione no.
+E un accredito mensile da qualche dollaro **si vede benissimo anche a 2 decimali** — purché il libro
+sia FLAT, perché allora `equity == balance == USDC` e ogni scalino è un accredito.
+
+## La misura: due confini di mese, entrambi a libro flat
+
+| finestra | punti orari | equity min | equity max | ore senza alcun movimento | scalini >1 cent | reward atteso se idoneo |
+|---|---|---|---|---|---|---|
+| **29/06 → 08/07** | 238 | **598,06** | **598,06** | **237 / 237** | **0** | $0,45 (8 gg dal 23/06) |
+| **31/07 → 03/08** | 96 | **596,92** | **596,92** | **tutte** | **0** | **$1,72** (luglio intero) |
+
+Il secondo è il caso decisivo: **$1,72 attesi contro una risoluzione di $0,01 — 172×** — e l'equity
+non si muove di un centesimo per quattro giorni pieni, coprendo tutta la finestra "early in the
+following month". Non è un'assenza sotto la soglia di rilevabilità: è uno zero misurato.
+
+⇒ **Il conto NON riceve i reward USDC.** N=2 confini indipendenti, entrambi puliti per costruzione.
+
+## Perché, e perché è coerente col fatto che l'USDE invece paga
+
+Deribit: *«A user's eligibility to receive USDC is based on their location»*. L'ipotesi che spiega
+entrambe le osservazioni è **MiCA**: USDC è un *e-money token* regolamentato, e a un residente UE
+non se ne può corrispondere rendimento; **USDe non è un EMT**, e infatti i suoi reward arrivano
+(li abbiamo visti per delta: +0,052055 · +0,061815 · +0,061821). ⚠️ *Questa è la spiegazione
+plausibile, non una fonte normativa verificata* (P13/M27: una norma citata si verifica come un
+numero). **Il fatto misurato è lo zero, non il suo motivo.**
+
+## Cosa cambia (e cosa la §6 aveva sbagliato)
+
+- **La premessa originale del gate USDE-01 è RESTAURATA.** Il guadagno di tenere USDE **non è lo
+  spread 0,71 punti: è il tasso pieno ~4,1%**, perché l'alternativa sul nostro conto rende **0**.
+  Sui $644 che teniamo: **~$26/anno** (e ~$29 al ritmo misurato di ~4,5%), non i ~$4,6 di §6.
+- **Cosa avevo sbagliato, e la lezione.** Ho letto `apr: 3.4` in `public/get_currencies` e l'ho
+  trattato come una proprietà **del nostro conto**. È una proprietà **del venue**: un listino, non
+  un accredito. La conferma indiretta che invocavo ("i reward USDE misurati coincidono con la loro
+  APR pubblicata") provava che il listino è reale **per l'USDE**, e non diceva nulla sull'idoneità
+  dell'USDC. 📌 **Un tasso pubblicato non è un tasso incassato: si verifica sul CONTO, e la verifica
+  costava una query sulla serie che avevamo già.** È N10 in una veste nuova — la verifica a €0 va
+  fatta *prima*, e si fa **sul venue, non sul sito**; qui perfino il venue non bastava, serviva il
+  conto.
+- Resta vero e non toccato: il **tetto del venue al 31,21%**, il **cuscino di regolamento** (30%
+  dell'equity, che lascia il 70%), e che a 31,2% l'evento emittente vale ~3,9× il maxDD del libro.
+  La decisione "tenere o no i $644" cambia però di segno rispetto a come l'avevo chiusa: si compra
+  **$26/anno**, non $4,6.
+
+## Strumento lasciato in piedi
+
+**`scripts/live/balance_watch.py`** + **`scripts/cron_balance.sh`** (orario al minuto **:42**, libero
+fra :25/:35/:47; sola lettura). Registra il **balance a 8 decimali** per valuta — la serie che
+mancava — con il conteggio dei fill dall'ultimo campione e il nozionale lordo, così una finestra
+sporca si riconosce invece di essere mediata dentro. Etichetta PULITA le finestre a 0 fill e libro
+flat, dove il Δ USDC **è** l'interesse, e ne stampa l'APR implicita accanto a quella attesa.
+Serve a sorvegliare che lo zero resti zero (o che cambi, se l'idoneità cambia): l'inizio di
+settembre è il prossimo confine di mese, ed è già strumentato.
+
+---
+
+# APPENDICE 2 (2026-08-31) — la fonte ufficiale: **due correzioni alle mie conclusioni**
+
+L'operatore ha passato l'articolo `support.deribit.com/.../Yield-reward-bearing-coins`. WebFetch lo
+prende 403 (Cloudflare); si legge dall'**API Help Center** in JSON:
+`support.deribit.com/api/v2/help_center/en-us/articles/31424939199261.json` → HTTP 200.
+*Aggiornato dal venue il 2026-08-20.* Contiene tre cose che il progetto non sapeva.
+
+## 1. L'ITALIA è nella lista degli esclusi dai reward USDC — e non è MiCA
+
+> «The following jurisdictions are **not eligible** to receive USDC rewards: Austria, Belarus,
+> Belgium, Bulgaria, Canada, […] **Italy**, Japan, […]»
+
+Lo zero misurato è **confermato dalla fonte**. Ma l'ipotesi che avevo scritto — MiCA, USDC è un
+e-money token e USDe no — **è sbagliata**: la lista contiene Canada e Giappone, non è il perimetro
+MiCA. È policy di giurisdizione di Deribit. *M27: una fonte normativa citata si verifica come un
+numero — e io l'avevo dedotta invece di leggerla.*
+
+## 2. La finestra di pagamento è di DUE SETTIMANE, non di tre giorni — il «172×» era sovra-affermato
+
+> «The monthly USDC rewards payment is then made **within the first two weeks** of the following
+> month.»
+
+Avevo verificato su 29/06→08/07 e 31/07→03/08: **8 giorni su 14 e 3 su 14**. Rifatto sulle finestre
+vere:
+
+| accredito | finestra vera | letture | escursione TOTALE equity | scalini ≥70% dell'atteso | esito |
+|---|---|---|---|---|---|
+| giugno ($0,45) | 01→16/07 | 374 | **$2,74** | 7 | ❌ **NON conclusivo** |
+| luglio ($1,72) | 01→16/08 | 382 | **$0,48** | **0** | ✅ **conclusivo** |
+
+Luglio regge da solo: il credito atteso è **3,6× l'intera escursione dell'equity** su due settimane.
+Giugno no — il libro ha iniziato a operare a metà mese e il rumore ha la taglia del segnale.
+⇒ La conclusione **non cambia** (una finestra conclusiva + la lista ufficiale), ma l'evidenza è
+**una** finestra, non due. *Avevo citato la sotto-finestra piatta e chiamato «zero misurato» ciò che
+la finestra completa non copriva: scegliere la sotto-finestra che fa vedere lo zero è la stessa
+mossa che il progetto vieta a un backtest.*
+
+## 3. Il tetto NON è un livello: è una FRAZIONE dell'equity, e scala col conto
+
+L'articolo documenta un **Cap ETHENA** che diluisce il **tasso** a livello di exchange —
+`User APR = min(min_exchange_USDe_balance, Ethena Cap) / min_exchange_USDe_balance × Ethena APR` —
+e **nessun limite sulle quantità detenibili da un conto**. Quindi il muro non aveva base
+documentale, e andava ri-sondato. Fatto (31/08, giorno UTC nuovo → non è un limite giornaliero):
+
+```
+BUY   5              -> not_enough_funds_in_currency   USDE 644.175691   (muro ancora li')
+SELL 10              -> OK                             USDE 634.175691
+BUY  10              -> not_enough_funds_in_currency   USDE 634.175691   <-- ieri 644,18 passava!
+BUY   5              -> OK                             USDE 639.175691
+BUY   3              -> OK                             USDE 642.175691
+BUY   1              -> OK                             USDE 643.175691
+BUY   1              -> not_enough_funds_in_currency   USDE 643.175691
+```
+
+**Ieri si tornava a 644,18 e oggi no**, con l'equity scesa di $8. Il tetto si è mosso con lei:
+
+| | tetto | equity | frazione |
+|---|---|---|---|
+| 30/08 | [644,18 · 645,18) | $2.063,79 | 31,21% – 31,26% |
+| 31/08 | [643,18 · 644,18) | $2.055,56 | 31,29% – 31,34% |
+
+I bracket distano **0,05pp**, dentro il rumore dell'equity (±$2-8/ora). Candidato pulito **5/16 =
+31,25%**, ma con questa risoluzione non si distingue da una regola sul collaterale scontato
+dell'haircut (~29%): **non si sceglie quella che conviene, si cita la banda** (M25).
+
+⇒ **Il tetto SCALA col conto.** La quota resta ~31% per sempre, il valore in dollari cresce col
+capitale, e il 70% non è raggiungibile né ora né mai. Conseguenza che ieri non avevo visto: essendo
+pinnati al tetto, **il rischio emittente resta una frazione COSTANTE del conto** — non si diluisce
+crescendo, a meno di vendere apposta.
+
+## 4. E l'USDe ha un fee del 5% che non avevamo mai nominato
+
+> «Deribit Fee: A percentage deducted from the reward before distribution (**currently 5%**)»
+> · reward su **minima equity 00:00→24:00 UTC**, distribuiti **~12:00 UTC**, «visible inside
+> Transaction Log» (che il gateway non espone: da lì il metodo per delta).
+
+Il nostro **misurato** (~4,5%/anno) è già netto del fee: è quello che arriva sul conto, ed è
+l'unico numero da citare. La `apr` di `get_currencies` (4,1071%) è un listino, non un incasso —
+la stessa confusione che mi era costata la §6.
+
+## 5. Cablato, così il tetto smette di vivere in prosa
+
+Alla domanda dell'operatore «dove è scritto il valore del tetto» la risposta era: **in tre note di
+testo e in nessun posto che il codice legga**, tanto che `usde_convert --quota 0.70` dichiarava
+«piano valido» per un ordine che il venue avrebbe rifiutato. Ora:
+
+- `config/live.json` → `usde.venue_cap_frac` **0.312** (bordo BASSO dei bracket: fa fallire il
+  piano *prima* dell'ordine invece che dopo il rifiuto) + `venue_cap_misurato` con la data;
+- `src/live/usde.py` lo porta nei default — unica autorità, come tutto il resto della sezione (P1);
+- `usde_convert.piano()` rifiuta il bersaglio sopra il tetto e stampa il massimo raggiungibile.
+  Verificato: `--quota 0.70` → *«TETTO DEL VENUE: bersaglio $1.438,90 sopra $641,34 (31,2%
+  dell'equity, misurato 2026-08-31)»*, nessun ordine inviato.
+
+**Stato finale**: USDE **643,175691** (quota **31,29%**, cioè al tetto), USDC $1.412,40,
+totale $2.055,57.

docs/diary/2026-08-30-usde-quota.md

@@ -0,0 +1,128 @@
+# 2026-08-30 — La quota USDE: l'EV non puo' sceglierla, e aspettare costa $1,33
+
+*Scritto 2026-08-30T17:32:57Z. Script: `scripts/research/r0830_usde_quota.py` (verdetto a runtime, N11).
+Stato conto congelato nello script alla lettura del 2026-08-30T17:05Z.*
+
+## La domanda
+
+Il gate USDE-01 e' **chiuso IDONEO** dal 28/08. Resta la decisione di **quota**, rinviata
+dall'operatore a **lunedi' 31/08**: quanto del conto tenere in USDE.
+
+## Il risultato strutturale — dichiarato prima di guardare i numeri
+
+Il valore atteso e' **lineare in q**. Un massimo lineare sta sempre in un **angolo** (0% o
+100%). ⇒ **l'EV non puo' scegliere una quota interna**: puo' solo dirne il segno. Ogni quota
+intermedia nasce da un criterio sulla **coda**, che va **dichiarato**, non ottimizzato (M8).
+
+Per questo lo script non sceglie: mette il **prezzo accanto a ogni criterio**.
+
+## (A) Il rendimento, col suo n
+
+| | |
+|---|---|
+| finestre misurabili | **4** (pagate 3) |
+| per finestra | 0,00% · 3,80% · 4,51% · 4,51% |
+| APR di `usde_watch` | **3,26%** annuo (tempo vero, 3,93 giorni) — *il numero che gira* |
+| APR per-finestra | 3,21% (n finestre, 4,00 giorni) |
+| banda bootstrap 95% | **[1,13% – 4,51%]** (200.000 ricampionamenti) |
+
+📌 La banda e' larga **3,4 punti** su un livello di 3,2%: a n=4 il tasso **non e' misurato, e'
+abbozzato**. La divergenza fra i due denominatori (0,06 punti) e' **dichiarata, non appianata**
+(P12), e il punto stimato si **deriva** da `usde_watch.rendimento()` invece di essere
+ridichiarato (P1).
+
+## (B) L'hazard di pareggio — l'unico criterio che non richiede un criterio
+
+Perdita totale **non recuperabile**, resa 3,26%/anno ⇒ **hazard annuo di pareggio = APR**.
+
+- **3,26%/anno** (banda 1,13% – 4,51%)
+- recupero di una perdita totale con la sola resa: **30,6 anni**, *indipendente dalla quota*
+- ⇒ la quota e' EV-positiva **se e solo se** si crede che Ethena abbia meno del **3,3% annuo**
+  di probabilita' di evento catastrofico. Quel numero e' **assunto, non stimato** — esattamente
+  come il `p` di Deribit della decisione 26/07.
+
+## (C) Il rischio marginale, dato il 100%-Deribit gia' accettato
+
+Framework **ereditato** dalla decisione 26/07, non re-inventato: `P = 1-(1-p)^20`. Lo script lo
+**riproduce** (M23: far riprodurre alla macchina il numero vecchio prima di pubblicarne uno nuovo):
+10/18/33/64% contro i 10/18/34/64% registrati — **OK** a 1,5 punti.
+
+Due letture che **non si annullano**, e la contraddizione e' informazione (M28):
+
+- ✅ L'USDE fa perdere soldi **solo** nel mondo in cui Ethena salta **e Deribit sopravvive**. Nel
+  mondo in cui salta Deribit, USDC e USDE si perdono insieme e la quota e' irrilevante. Il rischio
+  **aggiunto** e' quindi di **secondo ordine** rispetto a quello gia' accettato.
+- ⚠️ Ma e' un **terzo strato sullo stesso conto**, e **N4** dice che un rischio di venue si compra
+  con un **secondo CONTO**, non aumentando l'esposizione al primo.
+
+La prima dice che la quota costa poco; la seconda che **non e' li' che si compra sicurezza**.
+
+## (D) I vincoli operativi: nessuno morde
+
+Il libro gira al **2,00% di margine** ($11,37 su $568,64 di nozionale lordo). Al tetto di leva
+1,00x servirebbero ~$41 su un collaterale di ~$2.000.
+
+| quota | margine utilizzabile | serve al tetto | morde? |
+|---|---|---|---|
+| 24,2% | $2.014 | $41 | no |
+| 50,0% | $1.961 | $41 | no |
+| 90,0% | $1.878 | $41 | no |
+
+⇒ **l'haircut 10% non morde a nessuna quota testata**, tre ordini di grandezza di margine. D5:
+buco quantificato e innocuo. **Il vincolo non e' il margine.**
+
+Churn da depeg: a soglia critica 0,95 l'equity cala di 5%·q ⇒ a quota 50% sono **2,50%**, cioe'
+~$52 di nozionale da girare. Il libro **de-risca mentre l'USDE e' a sconto e ri-carica al ritorno
+del peg** — compra alto e vende basso — ma per importi di **secondo ordine**. Non e' il vincolo.
+
+## (E) Il menu dei criteri, ciascuno col suo prezzo
+
+| criterio | quota | USDE | resa $/a | drift libro | == €/mese | mesi di bonifico a rischio |
+|---|---|---|---|---|---|---|
+| **C0** status quo | 24,2% | $500 | $16 | 0,79% | 19 | **2,0** |
+| **C1** ≤ maxDD del libro (7,94%) | 7,9% | $164 | $5 | 0,26% | 6 | 0,7 |
+| **C2** ≤ 6 mesi di versamento | 72,7% | $1.500 | $49 | 2,37% | 58 | 6,0 |
+| **C3** ≤ 12 mesi di versamento | 100% | $2.064 | $67 | 3,26% | 80 | 8,3 |
+| **C4** tetto di ALLERTA di config | 50,0% | $1.032 | $34 | 1,63% | 40 | 4,1 |
+
+⚠️ **Due monete, non si sommano** (N8): *resa $/a* e' **cassa** vera; *== €/mese* e' l'equivalente
+in **versamento** via l'equivalenza registrata (100 €/mese == +4,07%/anno di drift), che e' una
+capitalizzazione a 10 anni, **non un flusso**. Semplificazione dichiarata: EUR e USD 1:1 (a ~1,08
+sposta i mesi di ~8%, non muove nessuna soglia).
+
+## (F) Cosa costa aspettare — il numero decisivo
+
+La conversione e' su spot `USDE_USDC`: **fee 0, spread ~3 bps** ⇒ andata+ritorno **~6 bps**. La
+decisione e' **reversibile a costo quasi nullo** — non e' una porta a senso unico e va decisa come
+tale.
+
+| attendere | finestre | andata/ritorno | resa persa | costo totale |
+|---|---|---|---|---|
+| 0 sett | 4 | $0,32 | $0,00 | $0,32 |
+| 2 sett | 18 | $0,32 | $0,67 | $0,98 |
+| **4 sett** | **32** | $0,32 | $1,33 | **$1,65** |
+| 8 sett | 60 | $0,32 | $2,66 | $2,98 |
+
+📌 **Portare la quota a 50% fra quattro settimane invece che domani costa $1,33 di resa non
+incassata e compra 8× le finestre** (n da 4 a 32), stringendo la banda di ~2,8× — da ~3,4 punti a
+~1,2. **$1,33 per sapere se il tasso e' 1,1% o 4,5%.** E' l'applicazione diretta di N10: una data
+si giustifica col **costo della misura**, non con la sua difficolta' percepita.
+
+## Verdetto (calcolato a runtime)
+
+- **RISOLUZIONE INSUFFICIENTE PER ALZARE** — n=4, banda larga 3,4 punti. Alzare ora e' comprare un
+  tasso che non e' ancora misurato.
+- **NESSUN VINCOLO OPERATIVO** — l'haircut non morde a nessuna quota; il vincolo non e' il margine.
+- **SCALA** — la resa alla quota di oggi vale **$16/anno**, meno di **un mese** di versamento. La
+  leva binding resta il **bonifico** (N1/N3), non la quota.
+- **ASIMMETRIA** — gia' a 24,2% l'evento emittente vale **3,1× il maxDD dell'intero libro** (7,94%),
+  che e' il rischio che il progetto ha passato due anni a limare.
+- **REVERSIBILE E QUASI GRATIS DA RIMANDARE** — $1,33 + 6 bps per 8× il campione.
+
+## Cosa NON dice questa analisi
+
+- Non stima `p` per Ethena. Nessuna fonte qui lo misura: e' **assunto**, e lo script lo tratta come
+  parametro, non come risultato.
+- Non sceglie la quota. **La scelta e' dell'operatore** (N4).
+- Il tasso osservato viene da un metodo **indiretto** (delta di equity al netto dei trade): il
+  gateway non espone il Transaction Log. Vale col suo limite gia' dichiarato in `usde_watch`.

docs/diary/2026-08-31-buidl-test-eligibilita.md

@@ -0,0 +1,181 @@
+# 2026-08-31 — GATE BUIDL-01: test di eligibilità sul collaterale BlackRock
+
+⚠️ **Questo documento è scritto PRIMA di eseguire e PRIMA di conoscere l'esito, e committato
+separatamente dall'esecuzione**: l'ordine dei fatti è verificabile in git, non sulla mia parola.
+È la stessa disciplina che ha reso valido il test USDE del 26/08 (M13, N11).
+
+## Da dove nasce
+
+L'operatore chiedeva se convenisse aggiungere **stETH** e i custodi Fireblocks/Sygnum/Komainu.
+Risposta: no a entrambi — stETH rende **2,2254%** (metà dell'USDE) e non è un dollaro ma **ETH**,
+quindi è esposizione direzionale che `book.py` non netta e che nessun gate autorizza; coprirla con
+uno short perp è **CC01**, già misurato il 26/06 e parcheggiato come *"LEAD a scala ~$20k+"*.
+I custodi sono istituzionali, fuori portata a $2k e coperti dalla decisione *"100% Deribit fino a
+$20k"* — e comunque **nessuna via custodiale restituisce i reward USDC**, perché l'esclusione
+italiana è per giurisdizione.
+
+Ma la ricerca ha trovato la voce che conta. Le valute a rendimento su Deribit sono quattro:
+
+| valuta | APR pubblicata | emittente / natura | note |
+|---|---|---|---|
+| USDE | 4,2143% | Ethena, sintetico delta-hedged | **al tetto** (~31,2% dell'equity) |
+| USDC | 3,4000% | Circle / custodia Coinbase | **Italia esclusa → 0 sul nostro conto** |
+| **BUIDL** | **3,2018%** | **BlackRock, Treasury USA tokenizzati** | `BUIDL_USDC` liquido |
+| STETH | 2,2254% | Lido | è ETH, non un dollaro |
+
+**Il punto non è il tasso, è l'emittente.** Oggi il conto ha **$1.412,71 di USDC che rendono
+esattamente zero** e un rischio emittente concentrato al 100% su Ethena. BUIDL è un R1
+**completamente diverso** (Treasury USA): non aggiunge un grammo di esposizione Ethena e va
+esattamente nella direzione che N4 indica — *la quota è l'unica leva contro il rischio emittente*.
+
+## Cosa si compra e cosa resta
+
+- USDC $1.412,71 · USDE 643,175691 ($643,18) · **totale $2.055,88**
+- cuscino di regolamento richiesto (`n_asset × frac × disaster_sl_pct` = 30% dell'equity): **$616,76**
+- **USDC libero sopra il cuscino: $795,94**
+
+**Taglia del test: 500 BUIDL (~$500)** — la stessa del test USDE, per confrontabilità. Lascia USDC
+a ~$912, cioè **$295 di slack sopra il cuscino**: il vincolo di regolamento resta rispettato con
+margine. Costo: spread 4 bps ≈ **$0,20**, reversibile.
+
+## Meccanica dichiarata (dall'articolo ufficiale, non dedotta)
+
+> «BUIDL rewards are paid based on the **minimum equity** of BUIDL held in an account over the
+> preceding day. The minimum equity held over the preceding day must be **at least 1 BUIDL**.
+> The minimum equity calculation period is the **24 hours up to 20:00 UTC** each day. […] BUIDL
+> rewards are **only paid on weekdays** […] between **20:00 UTC and 23:00 UTC**. […] Deribit
+> charges an administrative fee of **5%**.»
+
+Comprando **lunedì 31/08 mattina**, la finestra 20:00 dom → 20:00 lun ha minimo **0** (prima
+dell'acquisto non tenevamo BUIDL): **nessun reward atteso lunedì sera**. La prima finestra piena è
+20:00 lun → 20:00 mar, pagata **martedì 01/09 fra le 20:00 e le 23:00 UTC**.
+
+Reward atteso su 500 BUIDL: `500 × 3,2018%/365` = **0,04386/giorno** lordo, ~**0,0417 netto** del
+fee 5%. BUIDL ha **6 decimali**: il segnale è ~40× la soglia di rumore che usiamo per l'USDE (1e-3).
+⚠️ *La APR pubblicata è un listino, non un incasso* — lezione pagata il 30/08 sull'USDC. Il numero
+da citare sarà quello **misurato**, con il suo `n`.
+
+## 🔒 CRITERI PRE-REGISTRATI — dichiarati adesso, prima dell'esito
+
+**GATE BUIDL-01, si legge il 2026-09-04.**
+
+1. **ELIGIBILITÀ** *(la domanda primaria: la giurisdizione italiana esclude l'USDC, e per BUIDL
+   l'articolo non pubblica alcuna lista — quindi è ignoto, non noto)*
+   **≥1 reward BUIDL rilevato entro le 23:00 UTC del 2026-09-03 → IDONEO**; si apre la decisione
+   di quota, che è dell'**operatore**. **Zero reward → NON IDONEO**: si riconverte in USDC e la
+   pista si chiude, come si sarebbe chiusa quella USDE.
+   Finestra: tre giorni feriali pieni (mar 01, mer 02, gio 03), robusta a una finestra mancata.
+   Rilevazione **per delta** sull'equity BUIDL al netto dei trade — il gateway non espone il
+   Transaction Log (debito #11), stesso metodo dichiarato dell'USDE, coi suoi limiti.
+   Soglia di rilevazione **1e-3 BUIDL** (il reward atteso è 40×).
+
+2. **TETTO DEL VENUE** — si sonda subito, col metodo **a saldo neutro** già validato sull'USDE
+   (BUY rifiutato → SELL → BUY riaccettato → BUY rifiutato). Si registra il bracket **con l'equity
+   del momento**, perché sull'USDE il tetto si è rivelato una **frazione** e non un livello: senza
+   l'equity accanto il numero non è interpretabile (P7).
+
+3. **HAIRCUT**: **dichiarato NON misurabile a questa taglia** e non vincolante — sull'USDE è stato
+   misurato che non morde fino al 90% di quota, e qui il margine impegnato è ~$11 su $2.056.
+   Non lo si stima al buio: si scrive che non lo sappiamo (D5).
+
+**Cosa NON decide questo test**: la quota. Decide solo se la pista esiste. La quota è
+dell'operatore, e sull'USDE si è vista arrivare comunque dal venue.
+
+## Sorveglianza
+
+`balance_watch.py` (orario, minuto :42) viene esteso a **BUIDL**: registra il balance a 6-8
+decimali accanto a USDC e USDE, col conteggio dei fill dall'ultimo campione. È già dentro il
+perimetro di backup. La finestra dei reward BUIDL (20:00-23:00 UTC) è coperta da 4 campioni orari.
+
+*Esito: da scrivere dopo il 2026-09-03.*
+
+---
+
+## ESITO (stesso giorno, 07:35-07:45Z) — **GATE BUIDL-01 CHIUSO: NON ENTRABILE**
+
+Il gate si chiude in dieci minuti, e con un esito che **non era fra i due previsti**. I criteri
+pre-registrati contemplavano *"≥1 reward → IDONEO"* e *"zero reward → NON IDONEO"*. La realtà è una
+terza cosa: **non si riesce a comprare BUIDL affatto**, quindi la domanda sull'eligibilità ai reward
+è priva di oggetto. *Un gate può fallire sulla sua precondizione invece che sul suo criterio, e va
+scritto così invece di essere forzato in una delle caselle previste.*
+
+### La misura
+
+Undici ordini rifiutati, tutti con `not_enough_funds_in_currency`:
+
+```
+BUY 500 · 250 · 125 · 62 · 31 · 15 · 7 · 3   @1.0009   -> rifiutati (scala per dimezzamento)
+BUY 1 @1.0006   (ask 1.0004 x 10.730)        -> rifiutato
+BUY 1 @1.0024   (ask 1.0004 x 10.730)        -> rifiutato
+BUY 1 @1.0100   (ask 1.0004 x 10.730)        -> rifiutato
+```
+
+Con **BUIDL 0,000000 in mano** e **USDC $1.412,32 disponibili**, per comprare **$1**. Esclusi uno
+per uno tutti i sospetti che sull'USDE avevano portato fuori strada:
+
+| sospetto | escluso perché |
+|---|---|
+| prezzo non marcabile | limite **1,0100** contro ask **1,0004** — incrocia di 96 bps |
+| liquidità | **10.730** unità al miglior ask, 23.416 tre livelli sotto |
+| taglia | rifiutata **1 unità**, il minimo dello strumento |
+| fondi | **$1.412** disponibili per un ordine da **$1** |
+| tetto sul livello | **teniamo zero**: non c'è nulla da superare |
+| wallet inesistente | `account_summary("BUIDL")` risponde, equity 0.0 |
+
+⇒ **Il conto non è abilitato ad acquisire BUIDL.** Costo del test: **$0** (nessun fill).
+
+### 🚨 E la frase pubblicata è FALSA per il nostro conto
+
+> «**All Deribit users are permitted to buy and sell BUIDL tokens in the spot markets on Deribit,
+> with no extra requirements.**» — `insights.deribit.com/education/buidl-launches-on-deribit/`
+
+Non per noi. **Il fatto misurato è il rifiuto, non il suo motivo** (stessa disciplina dello zero
+USDC). Le spiegazioni candidate sono due, e da fuori **non sono distinguibili**:
+
+- **(a) giurisdizione** — BUIDL è un **titolo** (fondo BlackRock emesso via Securitize), la cui
+  distribuzione è ristretta a monte dell'exchange. L'articolo di marketing non lo dice.
+- **(b) limiti di spot per TIER DI CONTO** — la documentazione BUIDL, sezione *Limits and
+  Requirements*: «*Default non-margin spot order limits apply across assets. Check your account
+  tiers […] for specific maximum open order size configurations.*» Un tier che per questo asset
+  vale **zero** produrrebbe esattamente ciò che vediamo.
+
+⚠️ Ma i nostri dati **restringono**: lo **spot USDE funziona** — ne abbiamo comprati 644 lo stesso
+giorno, sullo stesso conto, con lo stesso codice. Quindi **non è un blocco generale sullo spot né
+un limite di tier trasversale: è SPECIFICO DELL'ASSET.** Il che è compatibile con entrambe le
+ipotesi (una giurisdizione per-asset, o un tier per-asset a zero) e non ne elegge nessuna.
+*Restringere le ipotesi con l'evidenza che si ha vale più che sceglierne una con l'evidenza che
+non si ha.*
+
+Irrilevante per noi ma registrato: «*Deribit only supports the ERC-20 version of BUIDL on the
+Ethereum blockchain*» — riguarda i trasferimenti on-chain, e la nostra uscita sarebbe comunque
+una vendita sullo spot, non un prelievo.
+
+📌 **Due affermazioni pubblicate di Deribit smentite dal conto in due giorni**: la APR USDC al
+3,40% (30/08) e ora «all users can buy BUIDL». Non è sfortuna, è una **regola**:
+
+> **Una capacità pubblicata dal venue non è una capacità del conto. Si verifica sul CONTO, prima
+> che entri in un piano — e costa un ordine da $1.**
+
+È N10 portata un passo più in là: la verifica a €0 va fatta prima, si fa **sul venue e non sul
+sito** — e adesso si sa che nemmeno il venue basta: serve il **conto**.
+
+### Il sottoprodotto che vale più del test
+
+`not_enough_funds_in_currency` è il **messaggio generico di Deribit per «non puoi acquisire altra
+di questa valuta»**, qualunque sia il motivo — permesso, giurisdizione, o tetto. Lo si è visto ora
+su BUIDL (permesso assente, zero in mano) e il 30-31/08 su USDE (tetto a ~31,2% dell'equity). Il
+messaggio parla di **fondi** e i fondi non c'entrano mai. Chi lo incontra in futuro deve saltare
+direttamente alla domanda giusta — *questa valuta la posso acquisire, e fino a quanto?* — invece di
+inseguire taglia, cadenza e prezzo come è successo il 30/08.
+
+### Cosa resta
+
+- **Pista BUIDL chiusa.** Non riapribile da noi: dipende da un permesso del venue, non da una
+  nostra scelta. La riapre solo un cambio lato Deribit.
+- **`balance_watch` tiene BUIDL nella lista** (costo: una lettura oraria). Se l'accesso si aprisse,
+  un balance diverso da zero lo direbbe da solo — la stessa logica per cui l'USDC resta sorvegliato
+  malgrado lo zero misurato.
+- **L'USDE resta l'unico collaterale a rendimento che il conto può usare**, al suo tetto di ~31,2%,
+  e i **$1.412 di USDC continuano a rendere zero**. Non per mancanza di alternative: perché le tre
+  alternative sono chiuse una per giurisdizione (USDC), una per permesso (BUIDL) e una perché non è
+  un dollaro (stETH).

docs/diary/2026-08-31b-venue-news-annunci.md

@@ -0,0 +1,426 @@
+# 2026-08-31 — Fine della Proof of Reserves, e il guardiano che mancava
+
+L'operatore ha passato l'annuncio *Deribit to Discontinue Daily Proof of Reserves Publication*.
+La notizia in sé vale poco per noi. Quello che è emerso cercandola vale molto di più.
+
+## 1. La notizia: frequenza giù, sostanza su, per noi nulla cambia
+
+Dal **1 settembre 2026** la pagina Proof of Reserves sparisce e gli aggiornamenti quotidiani
+cessano. Al loro posto, sotto il regime **VARA** di Dubai: audit **annuale** indipendente delle
+riserve, audit annuale del bilancio, obbligo di **copertura 100%** e **segregazione** degli attivi
+dei clienti. E: «*approximately 90% of client assets have been migrated to Coinbase, which acts as
+a custodian for Deribit*».
+
+**Non è un peggioramento netto, ed è importante non raccontarlo come tale.** Si perde un segnale
+**ad alta frequenza e debole** (una PoR auto-pubblicata prova che gli attivi esistono in un istante,
+non che coprano le passività, ed è aggirabile attorno allo snapshot) e si guadagna un segnale **a
+bassa frequenza e più forte** (audit indipendente obbligatorio invece di pubblicazione volontaria),
+più un miglioramento **sostanziale** di custodia: 90% degli attivi presso un custode terzo regolato
+invece che nei wallet dell'exchange.
+
+**Per noi non cambia nulla di operativo**, e per una ragione che va detta: *la PoR non l'abbiamo
+mai sorvegliata*. Zero occorrenze in tutto il codice. `venue_probe` legge se il venue **risponde**,
+non cosa **dichiara**. Si perde un segnale che non stavamo usando.
+
+Ho provato a catturare l'ultimo dato prima che la pagina sparisse — è la mossa giusta per un dato
+non ricostruibile con una scadenza. **Rinunciato di proposito**: la pagina è una SPA e
+`get_proof_of_reserves` non esiste come metodo API («Method not found»), ma soprattutto uno
+snapshot singolo e auto-riportato non regge lo standard di prova di questo progetto e **non
+permetterebbe comunque di stimare `p`**. Un dato che non cambierebbe una decisione non vale il
+lavoro per prenderlo.
+
+## 2. 📌 La conseguenza vera: il riapritore della decisione più grande si è ristretto
+
+La decisione vincolante **«100% Deribit fino a $20k»** (26/07) ha come riapritori dichiarati:
+*«**$20k**, o un cambio di piano, o `p` che diventa **stimabile** invece che assunto»*.
+
+Dal 1 settembre il segnale pubblico di solvibilità passa da **quotidiano ad annuale**. Il terzo
+riapritore non è formalmente chiuso — un audit indipendente è semmai evidenza più forte — ma
+diventa **praticamente irraggiungibile**: da una serie giornaliera si può costruire una stima, da
+un punto all'anno no. ⇒ **In pratica quella decisione è ora gated SOLO dal capitale**: si riapre a
+$20k, o non si riapre. Non cambia la decisione di oggi (fu presa con `p` esplicitamente **assunto**,
+non osservato), ma chiude l'unica uscita non-capitale che aveva.
+
+## 3. 🚨 Quello che ho trovato cercando: quattro annunci materiali che nessuno leggeva
+
+Il debito #8 dice, testuale: *«Resta scoperto il Rulebook vero e proprio: la sonda legge se il
+venue RISPONDE, non cosa il venue ANNUNCIA»*. Esiste un feed RSS pubblico
+(`insights.deribit.com/exchange-updates/feed/`) con 10 voci. Alla prima lettura:
+
+| data | annuncio | perché ci tocca |
+|---|---|---|
+| 27/08 | Discontinue Daily Proof of Reserves | §1 e §2 di questo diario |
+| **14/08** | **Contract Specifications change for Linear USDC Perpetuals** | **i nostri due strumenti** |
+| 05/08 | New SM Margin Model On Deribit | leva per taglia, tiered |
+| **31/07** | **USDC Rewards Available In More Countries** | tocca una conclusione viva |
+| 29/06 | New Fee Schedule On Deribit | `fee_watch` esiste per questo |
+
+**Il caso che decide la questione è il 14/08.** Le specifiche dei perpetual USDC sono cambiate il
+**18/08**; l'annuncio è del **14/08**. Il codice lo racconta già con onestà: la tabella «*non se
+n'era accorta […] è andata bene per la direzione del cambiamento, non perché ce ne fossimo
+accorti*» — i cambi erano **riduzioni** (tick BTC 0,5→0,1, ETH 0,05→0,01, min/step ETH
+0,001→0,0001) e un valore più grosso resta conforme. `check_specs()` è **nato da quella svista** e
+oggi gira ogni ora. Ma rileva la deriva **dopo**; il feed l'avrebbe detta **quattro giorni prima**.
+*Il giorno che Deribit ALZA un minimo, «dopo» significa ordini rifiutati.*
+
+Il 31/07 chiude un cerchio aperto ieri: l'espansione delle giurisdizioni idonee ai reward USDC
+**non contiene l'Italia**, né alcun paese UE — mentre **San Marino e Città del Vaticano** (i due
+microstati europei fuori dall'UE) **sono idonei**. La lista che avevo letto (aggiornata 20/08) è
+posteriore all'espansione: **la conclusione dello zero USDC è confermata due volte**. Il pattern
+UE-fuori/microstati-dentro suggerisce un driver regolatorio, ma la lista contiene anche Canada e
+Giappone: **non asserisco una causa**, il fatto è l'esclusione.
+
+## 4. Costruito: `venue_news.py`
+
+Sorveglianza giornaliera del feed, dentro `cron_daily.sh` accanto a `fee_watch` (suo parente
+stretto). Scelte che contano:
+
+- **NON interpreta.** Dice *«è uscito questo, guardalo»*. Nessun automatismo su un testo di
+  marketing: P13 — una guardia sui NUMERI non copre il RAGIONAMENTO, e la prosa si legge come
+  opinione di un lettore fallibile. L'unica cosa che classifica è l'**urgenza**.
+- **Le parole-chiave sono DERIVATE, non ridichiarate** (P1, il difetto più ricorrente del
+  progetto): gli strumenti vengono da `deribit._CONTRACT`, la valuta di collaterale da
+  `config/live.json`. *Chi aggiunge un asset al book allarga la sorveglianza senza toccare questo
+  file* — ed è esattamente il test che lo blinda.
+- **Primo giro semina senza allertare** (P9: l'allarme massimo non si spende per un arretrato di
+  10 voci, o non verrà letto il giorno che è vero).
+- **Feed illeggibile → codice 2 e nessun silenzio implicito** (P5: «non vedo» non è «niente di
+  nuovo»).
+
+5 test sulle funzioni pure. La rete no: `scarica()` ritorna `None` su qualunque errore, ed è quello
+il contratto.
+
+**Cosa NON copre**, e va detto: il **Rulebook** vero e proprio (ADL, perdita socializzata,
+*emergency powers*, conti dormienti) non ha un feed. Il debito #8 si restringe, non si chiude.
+
+---
+
+## 5. La Knowledge Base risponde a due domande aperte — e corregge due cose mie
+
+L'operatore ha passato anche *yield-generating-collateral-usde-buidl-and-more*, che **non** documenta
+tetti né haircut ma rimanda alla Knowledge Base. Interrogata via API Zendesk
+(`support.deribit.com/api/v2/help_center/articles/search.json`), l'articolo giusto è
+**«Cross collateral specifications»** (aggiornato 2026-02-20).
+
+### (a) 🚨 Il costo del saldo negativo: **0,05% al GIORNO**
+
+> «*While the equity of a currency in an account remains negative, a **collateral fee** will be
+> charged to that account. This fee is charged daily in the same currency as the negative balance
+> (**default = 0.05% per day**). The fee is charged based on the amount of time the negative equity
+> is held, down to a granularity of seconds.*»
+
+**18,25% annuo**, cioè **4,3× la resa USDE** che si starebbe comprando tenendo meno USDC. Il 30/08
+avevo scritto «Deribit lo finanzia a interesse» **senza il numero** — l'affermazione era giusta e
+vuota. Con il numero il criterio del **cuscino di regolamento** smette di essere prudenza e diventa
+aritmetica: scendere sotto il cuscino per tenere più USDE è **−14 punti**.
+
+E il ribilanciamento automatico **non salva**: scatta solo oltre **$1.000.000** assoluti o il
+**100% della cross equity** (default tabulati), soglie che a $2k non si toccano mai. Non veniamo
+ribilanciati: **sanguiniamo la fee**. *La cosa che sembrava un paracadute è, alla nostra taglia,
+esattamente l'assenza di un paracadute.*
+
+### (b) 🚨 Haircut USDe: la fonte dice **5%**, noi abbiamo registrato **10%**
+
+| valuta | haircut X:PM | X:SM |
+|---|---|---|
+| BTC · ETH · **USDC** | — | — |
+| USDT · USYC · **BUIDL** | 2% | 2% |
+| PAXG | 2,5% | 5% |
+| **USDe** | **5%** | **5%** |
+| stETH | 7,5% | 7,5% |
+| SOL | — | 15% |
+
+`config/live.json` dice `haircut: 0.10`, e il diario del 26/08 lo dà per «verificato sul venue»
+senza lasciare traccia di **come**. L'articolo è **anteriore** a quella data, quindi non si sa
+quale delle due sia stale.
+
+**Non l'ho riparato** (P12: fra due fonti che non concordano, una riparazione silenziosa è
+un'invenzione; M28: la contraddizione è informazione). Si tiene **0,10** per tre ragioni dichiarate:
+è il lato **conservativo** (sottostima il margine utilizzabile), **non è sul percorso soldi** (non
+entra nel sizing — lo usa solo il report di `usde_watch`), ed è già misurato che **non morde a
+nessuna quota fino al 90%**. Si chiude leggendo la pagina margini del conto, che è dove Deribit
+stesso dice di guardare.
+
+### (c) Un dato di lato che vale per il futuro
+
+**BUIDL ha haircut 2%** — sarebbe stato il *miglior* collaterale a rendimento del listino (contro
+il 5% dell'USDe), se solo lo si potesse comprare. E **stETH 7,5%**, il peggiore: terza ragione
+indipendente per lasciarlo stare, dopo il tasso dimezzato e l'esposizione ETH.
+
+📌 **Nessuna delle due fonti documenta un tetto sulle quantità detenibili.** Il ~31,2% sull'USDE
+resta **misurato e non spiegato** — e ora si sa che non è una svista di lettura: non è scritto da
+nessuna parte.
+
+### (d) Tentata la chiusura della divergenza sull'haircut: **non è raggiungibile da qui**
+
+Deribit dice: «*Haircut rates can be seen on the margin page in your account*». Quella pagina è web
+UI, e le credenziali vivono solo dentro il gateway (debito #11). Provato comunque:
+
+- `account_summary` per la valuta **USD** (la "riga USD" che il doc menziona) → `Invalid currency`;
+- parametro **`extended`** (che su Deribit apre i dettagli di margine) → **ignorato**;
+- il gateway filtra a **8 campi**: niente `initial_margin`, niente `maintenance_margin`.
+
+E non è che si sia guardato nel secchio sbagliato — **la contabilità torna esatta senza haircut**:
+
+```
+USDC  equity 1412.281074  available 1400.728093   riservato  11.5530
+USDE  equity  643.175691  available  643.175691   riservato   0.0000
+posizioni lorde $577.65
+
+riservato in USDC ........... $11.5530
+IM di posizione al 2% ....... $11.5530
+RESIDUO ..................... $-0.0000
+```
+
+Un haircut al **5%** chiederebbe **$32,16** accantonati, al **10%** ne chiederebbe **$64,32**: non
+ci sono, e il secchio USDE riserva `0.000000`. ⇒ **L'haircut non è osservabile in alcun campo
+esposto.** O è applicato solo nella vista cross/USD che il gateway filtra via, o non è applicato al
+nostro conto: da qui **le due cose non si distinguono**, e non le si sceglie tirando a indovinare.
+
+**La divergenza resta APERTA**, ma ora con la ragione misurata invece che supposta. La chiudono due
+cose, entrambe dell'operatore: **30 secondi sulla pagina margini** della web UI, oppure delle
+**chiavi API Deribit** — che è la decisione già dichiarata nel debito #11, non un refactor.
+Nel frattempo **non morde nulla di osservabile**: l'IM è il 2% del nozionale e il valore pieno
+dell'USDE resta disponibile, quindi 5% o 10% non cambia una singola cifra operativa.
+
+📌 **Sottoprodotto non cercato**: $11,5530 / $577,65 = **2,0000% = esattamente 1/50**. È il
+`C1 = 50` (start leverage, tier 1) del **nuovo modello di margine SM** annunciato il 05/08 — quello
+che `venue_news` ha appena tirato fuori dal feed. **Confermato sul nostro conto senza averlo
+cercato**, ed è la prima volta che un annuncio del venue viene verificato contro il conto invece
+che creduto.
+
+### (e) L'operatore dichiara: il conto è **Standard Margin** — due conferme incrociate
+
+Lo screenshot della pagina margini non è arrivato fin qui (sta sul desktop dell'operatore, non
+sulla VPS: il percorso non esiste su questa macchina). Ma il fatto dichiarato — **«è attivo
+Standard margin»** — aggancia due cose che erano sospese:
+
+1. **Quale colonna leggere.** La tabella KB ha `Haircut (X:PM)` e `Haircut (X:SM)`. Il conto è
+   **X:SM**, quindi vale la seconda — che per USDe dice **5%**, come la PM. La divergenza col
+   nostro `0.10` resta quindi intatta, ma ora si sa con certezza *quale* numero ufficiale la
+   contraddice, invece di doverne scegliere uno fra due colonne.
+2. **Perché l'IM misurata era esattamente 1/50.** Il nuovo modello di margine del 05/08 si applica,
+   testuale, ai *«standard margin accounts»*. Il conto è standard margin, e noi abbiamo misurato
+   IM = **2,0000%** del nozionale = **1/50** = il `C1 = 50` di tier 1. **Le due cose si confermano
+   a vicenda**: un fatto dichiarato dall'operatore e una misura fatta sul conto senza conoscerlo.
+
+*Vale la pena notarlo perché è raro: in tutta questa settimana ogni affermazione pubblicata dal
+venue si è rivelata falsa per il nostro conto (APR USDC, «all users can buy BUIDL»). Questa è la
+prima che il conto conferma.*
+
+**Cosa manca ancora**, e resta l'unica cosa che chiude la divergenza: il numero di haircut per USDe
+**mostrato sulla pagina Standard Margin del conto**. Se dice 5%, la nostra config è stale e il 26/08
+registrò male; se dice 10%, la KB è stale e la config ha ragione. Finché non c'è, si tiene 0.10 —
+lato conservativo, fuori dal percorso soldi, e **senza un solo effetto operativo misurabile**.
+
+---
+
+## 6. La pagina margini arriva davvero — e la seconda cosa che dice vale più della prima
+
+Lo screenshot era su **Wasabi** (`rclone` remote `wasabi:`, bucket `adp-work`, cartella `_scambio`),
+non sulla VPS: per questo il percorso non esisteva. Scaricato e letto.
+Riconciliazione riproducibile in **`scripts/research/r0831_margini_conto.py`** (N11).
+
+### (a) ✅ Haircut = **5%**. La nostra config aveva torto.
+
+La pagina **non espone l'haircut come numero**: si ricava per differenza, perché il modello CROSS
+conta l'USDE scontato e il SEGREGATO non lo conta affatto.
+
+```
+S:SM (attivo)   USDC Available 1,400.86   ·  USDC equity 1,412.28 − IM 11.55 = 1,400.73  (scarto $0.13)
+X:SM            CROSS Available 2,011.73
+contributo USDE al cross = 2,011.73 − (1,412.28 + 0.20 − 11.55) = $610.81  su $643.05 di valore
+  → haircut implicito 5,0137%
+     ipotesi  5% (KB)     → atteso $610.89   scarto $ 0.09   ✅
+     ipotesi 10% (nostra) → atteso $578.74   scarto $32.06   ❌
+```
+
+`config/live.json` passa da `0.10` a **`0.05`**. Il 26/08 il 10% fu registrato come «verificato sul
+venue» **senza lasciare traccia di come**, e non lo era. *Una nota di provenienza che dice «verificato»
+senza dire con quale lettura non è provenienza: è la stessa parola usata come garanzia.*
+
+### (b) 🚨 Il conto **non è cross-collateral**. È `Segregated: Standard Margin`.
+
+Lo dice la schermata in cima — *Current status: **Segregated: Standard Margin*** — e la tabella del
+modello attivo elenca **BTC, ETH, USDC. L'USDE non c'è.**
+
+⇒ **L'USDE non fa margine per i perp USDC-settled del book**, e l'haircut **oggi non si applica
+affatto**. Il che spiega, a posteriori e in modo pulito, perché la misura di stamattina trovava
+**$0,0000** accantonati: non stavo guardando nel secchio sbagliato, *stavo cercando un parametro
+che sul nostro conto non è in vigore*.
+
+**NON MORDE**, e va detto subito per non allarmare: al massimo lordo del libro (1,0x ≈ $2.056 di
+nozionale) l'IM sarebbe ~$41 contro **$1.400 di USDC disponibile** — 34× di copertura. Nessuna
+decisione operativa cambia oggi.
+
+**Ma la premessa scritta in CLAUDE.md era falsa**, e il modo in cui era falsa è istruttivo. Diceva:
+*«l'equity del book è il TOTALE cross-collateral»*. Sono due cose diverse messe sotto un nome solo:
+
+- come **ricchezza**, sommare USDC+USDE è **giusto** — ed era il punto della riparazione del 26/08,
+  che evitò il falso «USCITA DI FONDI −24%» e una vendita indesiderata;
+- come **capacità di margine**, è **sbagliato**: nel modello attivo l'USDE vale zero.
+
+Finché il margine non morde le due coincidono nell'uso, e infatti non è mai emerso. *Un errore che
+non ha conseguenze finché una terza cosa resta vera è un debito, non un'assoluzione.* Corretto in
+CLAUDE.md, e corretta anche la riga di `usde_watch` che stampava «margine utilizzabile ~$2.013
+(haircut 10%)»: era falsa due volte insieme.
+
+### (c) Come cambia il modo di pensare alla quota USDE
+
+Non è «collaterale diversificato»: è **cassa messa da parte a rendimento, fuori dal sistema di
+margine**. Il che rende il tetto del venue al ~31,2% meno una limitazione e più un caso fortunato —
+tiene automaticamente dentro al 31% la parte di conto che non lavora come margine.
+
+E apre una **decisione dell'operatore**, non mia: passare a **X:SM** aggiungerebbe **$610,87** di
+margine utilizzabile, ma porta con sé la meccanica cross — *collateral fee 0,05%/giorno* sul saldo
+negativo e ribilanciamento automatico. Oggi non serve (34× di copertura); servirebbe solo a leve
+che non sono autorizzate.
+
+📌 **Ipotesi nuova sul tetto del ~31,2%**, non verificata: potrebbe dipendere proprio dal modello
+segregato. Si saprebbe passando a X:SM e ri-sondando — un esperimento che ora ha un senso, dove
+prima non si sapeva nemmeno cosa variare.
+
+---
+
+## 7. Passaggio a X:SM e ri-sondaggio del tetto — l'ipotesi regge tecnicamente e cade in pratica
+
+L'operatore è passato a **Cross: Standard Margin** e ha chiesto di ri-sondare, per verificare
+l'ipotesi lasciata aperta in §6(c): *il tetto del ~31,2% dipende dal modello segregato?*
+
+### Il passaggio è verificabile dal gateway, senza fidarsi di una dichiarazione
+
+`available_funds` USDC è passato da **~$1.400** a **$2.011,09**, contro **$2.010,90** attesi
+sommando l'USDE scontato al 5% — **scarto $0,19**. È anche la **seconda conferma indipendente
+dell'haircut al 5%**, da una lettura completamente diversa dallo screenshot: due strade, stesso
+numero.
+
+### Il risultato
+
+| modello | tetto misurato | equity | frazione |
+|---|---|---|---|
+| Segregato **S:SM** (31/08) | [643,18 – 644,18) | $2.055,56 | 31,29% – 31,34% |
+| Cross **X:SM** (31/08, dopo) | [654,18 – 655,18) | $2.054,90 | **31,84% – 31,88%** |
+
+**+0,55pp = +11 USDE ≈ $11.** ⇒ **L'ipotesi è vera e inutile**: il modello di margine *entra* nel
+tetto, ma non lo spiega. Per arrivare al 70% mancano ancora ~38 punti, un fattore **2,2×**.
+*Un'ipotesi confermata al terzo decimale e falsa all'ordine di grandezza va archiviata come falsa:
+il tetto resta misurato e non spiegato.*
+
+### 🚨 La lezione di metodo, che vale più del risultato
+
+Il **primo probe fu un BUY 20, rifiutato**. Da solo avrebbe chiuso la questione con *"tetto
+invariato, l'ipotesi è refutata"* — e sarebbe stato **falso**. Il tetto si era mosso di 11, cioè
+meno della taglia del probe. È stato il test a **saldo neutro con passi piccoli** (BUY 1 → SELL 10
+→ BUY 10 → BUY 1, tutti accettati) a rivelarlo.
+
+📌 **Un probe unico di taglia sbagliata produce un falso negativo che si legge come risultato.**
+La taglia del sondaggio va scelta **sulla risoluzione dell'effetto che si cerca**, non su ciò che
+è comodo — ed è M13 in una veste nuova: *un criterio si misura sulla sua risoluzione prima che sul
+suo esito*.
+
+### Cosa ha comprato il passaggio, e cosa è costato
+
+- **Comprato**: **$611** di margine utilizzabile — inutile a 0,28x di leva, serve solo sopra ~1,4x
+  che non è autorizzata — più **$11** di capienza sul tetto.
+- **Costato**: sotto segregato l'USDE era **ring-fenced** dalle perdite del libro (solo il silo
+  USDC rispondeva delle posizioni); sotto cross **risponde l'intero conto**. Non morde oggi (perdita
+  massima plausibile ~$617 col disaster-SL, dentro il solo USDC), ma **il rischio strutturale ha
+  cambiato verso**. Se un giorno il cross non servisse più, tornare a S:SM ri-recinta l'USDE.
+
+`config`: `venue_cap_frac` 0.312 → **0.318** (bordo basso del bracket CROSS, che è il modello
+attivo). Se si torna a S:SM va rimesso a 0.312.
+
+## 8. **X:PM valutato e SCARTATO** — la risposta era già nello screenshot
+
+L'operatore ha chiesto di provare **Cross: Portfolio Margin**. Non serve provarlo: il confronto è
+nella schermata di §6.
+
+| modello | Available Balance | IM | MM |
+|---|---|---|---|
+| **X:SM** (attivo) | **$2.011,73** | 2,13% | **0,37%** |
+| **X:PM** | **$1.935,14** | 5,85% | **3,43%** |
+
+Sulla colonna il cui significato è inequivocabile — stessa riga, stesse unità — **X:PM dà $76,59
+di collaterale utilizzabile in MENO**, e chiede più margine. ⚠️ *La frase «su entrambe le misure»
+è stata corretta in §9: l'«IM %» stampata dalla pagina non è il margine delle posizioni.
+La conclusione non cambia — migliora.*
+
+**Perché**, ed è strutturale e non contingente: il Portfolio Margin è **basato su scenari di
+rischio** e premia i portafogli in cui il rischio si **compensa**, tipicamente i book di opzioni.
+Il nostro è **due long direzionali nudi senza nulla che compensi** — il caso peggiore per PM, che
+addebita lo scenario di stress invece di un'aliquota piatta.
+
+**La riga che decide è la MM: 3,43% contro 0,37%, ~9×.** Il maintenance margin è ciò che innesca la
+liquidazione: non morde a 0,28x, ma sposta il punto di liquidazione molto più vicino su un libro
+con soldi veri. E il beneficio atteso sul tetto è noto per analogia: il salto S:SM→X:SM ne ha
+comprato **$11**.
+
+⇒ **SCARTATO.** ⚠️ *Non "PM è peggio", ma "PM è peggio PER QUESTO portafoglio"*:
+**cosa lo riapre** — il giorno che VRP01 o un altro sleeve di opzioni entra in deploy, il rischio
+inizia a compensarsi e quel confronto **cambia di segno**. Va rifatto allora, non prima.
+
+---
+
+## 9. X:SM attivo: la pagina si ricostruisce dal gateway — e una mia lettura era sbagliata
+
+L'operatore ha incollato la riga CROSS col modello **attivo** invece che proiettato:
+`Available $2.010,81 · IM 2,15% · MM 0,37%`. Il gateway, letto **allo stesso minuto** (08:34Z), dice
+`available_funds` = **2010,82299383**. **Scarto $0,01.**
+
+### (a) Lo screenshot non serve più
+
+⇒ **La riga CROSS della pagina È `available_funds`**, che leggiamo da soli a ogni giro. Ieri quella
+schermata era l'**unica** fonte per l'haircut e per il modello attivo, e per averla è servito un
+passaggio dall'operatore e da Wasabi. Oggi non serve a niente: `r0831_margini_conto.live()` la
+ricostruisce.
+
+### (b) Terza conferma del 5%, e la prima ESATTA
+
+    1.400,71 + 0,95 × 654,176 + 0,20 dust − 11,553 IM = $2.010,82     pagina $2.010,81
+
+**Scarto $0,007.** E il 10% della vecchia config non è *improbabile*: invertendo la stessa riga dà
+**IM = −$21,16**, cioè **aritmeticamente impossibile**. Le tre strade — differenza fra le righe
+della pagina (31/08 07:50), salto di `available_funds` al passaggio S:SM→X:SM ($0,19), e ora questa
+ricostruzione al centesimo — sono indipendenti e danno lo stesso numero.
+
+### (c) 🚨 L'«IM %» della pagina NON è il margine delle posizioni — mia lettura sbagliata
+
+`(margin_balance − available)/margin_balance = 2,1532%`, ed è **esattamente** ciò che la pagina
+stampa come «IM 2,15%». Ma si scompone così:
+
+| voce | USD | % di margin_balance |
+|---|---|---|
+| haircut sull'USDE (5% × 654,18) | $32,71 | **1,592%** |
+| IM vera delle due posizioni | $11,55 | 0,562% |
+| **totale riservato** | **$44,26** | **2,153%** |
+
+⇒ **il 74% di quella percentuale è haircut, non rischio.** È salita da 2,13% a 2,15% **perché
+abbiamo comprato collaterale a rendimento** — cioè per un motivo che con l'esposizione del libro
+non c'entra nulla. *Letta come misura di rischio direbbe che ieri sera abbiamo alzato la leva
+comprando USDE: l'opposto di quello che è successo.*
+
+La **MM invece è pulita**: 0,37% = $7,60, e non può contenere l'haircut ($32,71 da solo la
+renderebbe negativa). **Le due colonne hanno basi diverse**, e la pagina non lo dice.
+
+📌 Regola: *una percentuale letta da una schermata va **invertita nella sua definizione** prima di
+essere confrontata.* Due colonne affiancate, con la stessa unità e lo stesso aspetto, possono avere
+denominatori — e qui numeratori — diversi. È P7 su una superficie nuova: un numero si etichetta
+con la sua configurazione, e una pagina del venue non è obbligata a farlo per noi.
+
+### (d) La decisione su X:PM esce RAFFORZATA
+
+La KB dà **USDe al 5% sotto entrambi i modelli** (§6b): nel confronto l'haircut **si cancella**, e
+l'inversa restituisce il margine di posizione puro sulle stesse due posizioni, stesso istante:
+
+| modello | available | **IM di posizione** |
+|---|---|---|
+| X:SM | $2.011,73 | **$11,64** |
+| X:PM | $1.935,14 | **$88,23** |
+
+**PM chiede 7,6× il margine iniziale e 9,3× la MM.** Due misure ora pulite, stesso verso: la
+bocciatura di §8 **regge, meglio fondata di quando l'ho scritta**.
+
+E c'è una conferma che ieri mancava: la riga X:SM era una **proiezione** di un modello **inattivo**,
+e oggi che è attivo la stessa aritmetica la riproduce al centesimo. ⇒ **anche la riga X:PM, che
+resta una proiezione, è affidabile**: la decisione presa senza provare il modello era presa su un
+numero buono. *Non provare X:PM è stato corretto, e ora si sa perché e non solo che.*

docs/diary/2026-09-01-collar-btc.md

@@ -0,0 +1,238 @@
+# 2026-09-01 — COLLAR01: il collar riduce il DD, il tetto lo paga troppo, e ciò che vince è VRP01 travestito
+
+> ⚠️ **Titolo corretto lo stesso giorno.** Diceva *«il pavimento funziona»*: la riduzione di DD è del
+> **collar**, non del pavimento — la put da sola lo peggiora in 16/16 celle (§72, sezione A1 sotto).
+
+*Scritto il 2026-09-01. Ogni numero è riprodotto da `scripts/research/r0901_btc_collar.py`.
+**Libro, pesi, cron, config INVARIATI. Nessun ordine.***
+
+## 0. La domanda, come è arrivata
+
+> *«crea una strategia di hold BTC in long o short con copertura con options (max 15gg)»*
+> *«opzione deve essere al max di 15gg»*
+> *«voglio ridurre la vincita, ma bloccare la perdita»*
+> *«ovviamente l'entrata deve essere gestita da una strategia confortata da indicatori (es. è in forte bull)»*
+> *«dalle opzioni dobbiamo uscire prima del termine (tra 50% e 75% del tempo)»*
+
+Le tre precisazioni cambiano l'oggetto, e vanno lette insieme: **non è una put protettiva, è un
+COLLAR** (pavimento comprato, tetto venduto per finanziarlo), su un **hold gated da indicatori**,
+con **scadenza ≤15 giorni**.
+
+## 1. Perché questo filone si poteva riaprire
+
+§46 (TAIL-HEDGE, 2026-08-23) è **REFUTATO** e la memoria dice di battere il motivo, non di
+ripetere la misura. Il motivo di §46, verbatim:
+
+> *il maxDD **SALE in 162/162 celle**, a ogni lente di f, perché il **beta del libro al sottostante
+> è +0,076**: non si assicura un libro che nei crash è già quasi piatto.*
+
+**Quel motivo non si applica qui.** §46 assicurava il *libro* (TP01+SKH01, piatto il 28% dei
+giorni); qui il sottostante è un **hold di BTC, beta 1,0 per costruzione**. E §46 dichiara di non
+aver provato proprio questo: *«Nessuna copertura dinamica (gated su regime) è stata provata: la
+domanda era la statica»*.
+
+Riusati e non rimisurati: metriche e `k_for_same_dd` da `r0823_tail_hedge`, il listino fee opzioni
+Deribit, la catena via `cblib.load_chain()`.
+
+## 2. L'entrata, presa dal progetto invece che inventata
+
+`trend_portfolio.tsmom_blend` media tre `np.sign()` sugli orizzonti (30, 90, 180), quindi assume
+**solo** i valori {−1, −1/3, +1/3, +1} (il bucket 2/3 non esiste — errore già corretto in §57).
+Questo dà a **"forte bull" una definizione che non aggiunge nemmeno un parametro nuovo**:
+
+- **gate FORTE** = `|blend| == 1`, tutti e tre gli orizzonti concordi → a mercato **52,5%** dei giorni
+- **gate LARGO** = `|blend| ≥ 1/3`, confronto dichiarato → a mercato **97,1%** dei giorni
+
+Il segno dà la direzione, quindi **long e short** sono entrambi coperti come chiesto. Si entra il
+giorno **dopo** il segnale (eseguibile, §8.1).
+
+## 3. La calibrazione: quello che il modello non poteva assumere
+
+161.964 quote a due lati su 95 giorni (2026-05-07 → 2026-09-01), scadenze 1-15 giorni.
+
+**Lo skew, ed è il fatto strutturale del filone:**
+
+| \|δ\| | IV put / ATM | IV call / ATM | la put costa |
+|---|---|---|---|
+| 0,10 | 1,249 | 0,959 | **+30%** della call |
+| 0,20 | 1,132 | 0,950 | **+19%** |
+| 0,30 | 1,072 | 0,960 | **+12%** |
+
+**Un collar delta-simmetrico è un debito netto**: compro l'ala cara e vendo quella a buon mercato.
+Non è un dettaglio di prezzo, è la ragione per cui "gratis" non esiste a delta simmetrici.
+Spread (mezza forchetta / mid): put 1,9-8,3%, call 2,1-10,0% secondo il delta. Struttura a termine
+IV/DVOL30 ≈ 0,92-0,94 a 2-14 giorni.
+
+📌 **A5 confermata, e corregge un muro di §46:** il tick da **5 USDC** che lì era «il secondo muro,
+strutturale» vale per la famiglia **USDC**. La catena che raccogliamo è **100% inverse**
+(`BTC-31JUL26-45000-P`), col tick in BTC. Il muro di §46 **non si applica a questo filone**.
+
+## 4. Il risultato, in ordine di come uccide
+
+Lente lunga 2021-03-24 → 2026-09-01 (1.988 giorni, 5,44 anni). BTC buy&hold nudo: Sharpe 0,413 ·
+maxDD 76,73% · drift +7,82%/a. Griglia dichiarata prima: 3 δput × 3 δcall × 2 tenor × 2 gate = **48
+celle**, più 12 varianti zero-cost dichiarate a parte.
+
+### ✅ A1 CONFERMATA — il COLLAR riduce il maxDD (36/48) — ⚠️ ma NON è il pavimento a farlo
+
+**maxDD scende in 36/48 celle.** Con beta 1,0 la put para davvero: è il risultato che §46 non
+poteva ottenere.
+
+🚨 **CORREZIONE (stesso giorno, `r0901c_pavimento_leva.py`, §72).** Questa riga diceva *«il
+pavimento funziona davvero»* e attribuiva la riduzione al pavimento. **È il COLLAR a ridurre il DD,
+non il pavimento**: la put **da sola**, a premio reale, **peggiora il maxDD in 16/16 celle**
+(FORTE 51,83% → 55,4-75,8%, LARGO 71,94% → 74,8-81,7%). Nel collar la riduzione viene dal **tetto**
+— il suo premio compensa il bleed della put, e cappare l'upside **abbassa il picco** da cui il DD si
+misura. Il pavimento pareggerebbe il DD nudo solo se le put costassero il **36-79% del reale**.
+Quindi: *il motivo di §46 (beta) non si applica, ma il suo verdetto — il maxDD SALE — si riproduce
+a beta 1,0 per un motivo diverso:* **i drawdown di BTC sono grind di 290-818 giorni, e una put a
+≤15 giorni copre una finestra.** Dettaglio in `2026-09-01c-pavimento-leva.md`.
+
+### ❌ A3 CONFERMATA — ma il de-levering lo fa meglio in 45/48 celle
+
+| gate | base gated senza opzioni | |
+|---|---|---|
+| FORTE | Sharpe 0,442 · maxDD **51,83%** · drift **+10,04%**/a | ← il null da battere |
+| LARGO | Sharpe 0,578 · maxDD **71,94%** · drift **+17,37%**/a | |
+
+Il null è **lo stesso hold gated, senza opzioni, scalato a iso-maxDD** — generato dallo stesso
+motore, non ridichiarato (P1). Il collar lo batte in **3 celle su 48**.
+
+### ❌ A2 CONFERMATA — ogni punto di DD risparmiato costa 2-8 punti di drift
+
+Δdrift/ΔmaxDD mediano: **7,90** col gate FORTE, **1,98** col LARGO. Il tetto costa più di quanto
+il pavimento renda, e non di poco.
+
+### 🚨 C9 — non è protezione, è troncatura
+
+Cella migliore, 196 cicli: **il tetto taglia nel 46,2% dei cicli vincenti, il pavimento para nel
+6,7% dei cicli perdenti.** Scatta **7 volte più spesso sui vincenti che sui perdenti** — la
+definizione letterale di C9. *La regola dell'operatore («ridurre la vincita, bloccare la perdita»)
+è implementata fedelmente: il problema è che su BTC quel baratto è pagato male.*
+
+### ❌ M1 — dentro il libro non aggiunge nulla
+
+Collar Sharpe 0,508 contro TP01 **0,852**, corr +0,486. TP01 + 10% di collar: Sharpe **+0,000** e
+maxDD **+2,32pp**. A 25%: **−0,065** di Sharpe e **+6,57pp** di maxDD. *Peggiora proprio la cosa
+che dovrebbe proteggere.*
+
+## 5. 🚨 Il fatto che vale più del verdetto
+
+**Tutte e 3 le celle vincenti stanno sul BORDO** della griglia (δput al minimo, δcall al massimo).
+M8: un argmax sul bordo non è una decisione. Ho esteso la famiglia (M4) con 36 trial dichiarati
+verso l'angolo — e lì **vince in 35/36 celle**, con il massimo *nell'angolo*:
+
+> gate FORTE, 7 giorni, **δput 0,02 · δcall 0,50** → Sharpe **1,471** · maxDD **18,12%** · drift **+29,99%**/a
+
+Il limite di quell'angolo è *nessun pavimento, tetto ATM*: **una covered call**. Cioè **la pendenza
+porta fuori da ciò che l'operatore ha chiesto e dentro lo short-vol.**
+
+E quel Sharpe 1,471 non è una scoperta — **è il mio prezzatore che si paga da solo**:
+
+| | DVOL / RV-forward | DVOL sta sopra |
+|---|---|---|
+| a 7 giorni | **1,320** | **76,9%** dei giorni |
+| a 14 giorni | **1,253** | **74,8%** dei giorni |
+
+Riprezzando le opzioni alla **volatilità effettivamente realizzata** (diagnostica con look-ahead
+dichiarato — è il valore equo ex-post, non una strategia):
+
+| cella | a DVOL | a vol realizzata | il VRP valeva |
+|---|---|---|---|
+| FORTE 7g δ0,02/0,50 | Sh **1,471** · +29,99% | Sh **0,511** · +8,45% | **+21,54 pp (72%)** |
+| LARGO 7g δ0,02/0,50 | Sh **1,141** · +32,17% | Sh **0,114** · **−1,10%** | **+33,26 pp (tutto)** |
+| FORTE 7g δ0,10/0,30 | VINCE | **perde** | +6,75 pp |
+| LARGO 14g δ0,10/0,30 | perde | perde | +8,02 pp |
+
+**Il 72-100% dell'edge dell'angolo è il premio di varianza**, non la struttura. E ciò che
+sopravvive alla riprezzatura — **Sharpe 0,511** — è, entro il rumore, **il numero che il progetto
+ha già**: VRP01 a f=0,73 vale **Sharpe 0,47**. *Non ho trovato una strategia nuova: ho ri-scoperto
+VRP01 per una strada più lunga.* E §3 lo blocca comunque: **«niente short-vol da modello in
+deploy»** — questo è esattamente short-vol da modello.
+
+## 5-bis. L'uscita anticipata: chiesta, implementata, e costa
+
+L'operatore ha chiesto di **uscire dalle opzioni fra il 50% e il 75% del tempo**. Implementato come
+`exit_frac`, su tenor 14 giorni (⇒ uscita a 7 / 9 / 10 giorni). **La mia ipotesi a priori era che
+migliorasse**: uscire presto recupera valore temporale sulla put e rinuncia al theta più veloce
+sulla call, cioè proprio alla parte che stampava il premio di varianza. **Metà giusta, metà no.**
+
+| cella `δ0,10/0,30`, gate FORTE | uscita | Sharpe | drift | null | esito | VRP residuo |
+|---|---|---|---|---|---|---|
+| a scadenza | 1,000 | 0,488 | **+9,48%** | +8,07% | VINCE | +3,38pp |
+| 75% | 0,750 | 0,457 | +8,59% | +7,72% | VINCE | +4,93pp |
+| 62,5% | 0,625 | 0,366 | +6,11% | +7,98% | **perde** | +2,51pp |
+| 50% | 0,500 | 0,278 | **+3,84%** | +8,04% | **perde** | **+1,27pp** |
+
+**Il meccanismo previsto c'è** — il VRP residuo scende da +3,38 a +1,27pp, quindi uscire presto
+*davvero* rinuncia allo short-vol — **ma lo spread lo travolge**: −5,6 punti di drift sul gate
+FORTE, −10,2 sul LARGO (12,06% → 1,88%), e su `δ0,20/0,20` da −4,37% a −8,58%.
+
+🚨 **E qui §46 va corretto nella sua applicazione.** §46 misurò: *«f si paga solo sulla parte di
+valore che converge a intrinseco, quindi un roll anticipato non lo paga»*. **Vero per una copertura
+SOLO LONG.** In un collar c'è una **gamba venduta da ricomprare**: uscire prima paga f *esattamente*
+sulla parte che a scadenza si sarebbe regolata gratis, e si fa ~2× più spesso per unità di tempo.
+**L'asimmetria di §46 si inverte quando la struttura ha una gamba corta.** È il risultato
+trasferibile di questa richiesta.
+
+**Nella banda chiesta (50-75%) il verdetto si spacca:** a **0,75** la cella onesta passa ancora il
+null (di poco); a **0,625 e sotto** non lo passa più. Nessun `exit_frac` ribalta il verdetto del
+filone — lo peggiora.
+
+## 6. I controlli dell'apparato (M15) — 3/3
+
+§46 insegna che *«un controllo positivo rotto dichiara guasto l'apparato»*. Prima di credere a un
+verdetto negativo ho verificato che l'apparato sappia riconoscere un successo:
+
+| controllo | atteso | misurato | |
+|---|---|---|---|
+| pavimento a **premio zero** (pranzo gratis) | deve VINCERE | maxDD 51,83%→**36,76%**, drift +10,04%→**+35,69%** | ✅ |
+| premio **×10** | deve PERDERE | drift **−33,96%**/a | ✅ |
+| zero-cost costruibile e finito | non NaN | drift −3,50%/a | ✅ |
+
+## 7. Tre difetti miei, catturati dai controlli e non a occhio
+
+1. **Bisezione dello zero-cost invertita** (`hi = md` dove serve `lo = md`): il premio cresce col
+   delta, quindi se incasso troppo poco il tetto va *avvicinato*. Dava Sharpe −3,0/−3,9 e drift
+   −53%/a — spazzatura che al primo giro avevo quasi pubblicato.
+2. **`dcall=NaN`** nella variante zero-cost propagava NaN nella cassa allo smontaggio anticipato.
+3. **C9 non consapevole della direzione:** usavo `S1 > S0` come proxy di "ciclo vincente", ma per
+   un ciclo **short** un prezzo che sale è una **perdita**. Era la causa del risultato impossibile
+   *«il pavimento para nello 0,0% dei cicli perdenti»* con una put a 10 delta.
+
+E due difetti di contabilità trovati prima di misurare, che avrebbero **adulato il collar**:
+la base senza opzioni rollava lo spot ogni `tenor` giorni pagando ~3,6%/anno di fee inesistenti;
+e al roll delle opzioni chiudevo e riaprivo anche lo spot, che non ha motivo di muoversi.
+
+## 8. Cosa NON ho misurato, dichiarato
+
+- **La lente reale (quote vere, 2026-05→09) non è stata girata come backtest.** 123 giorni = ~8
+  cicli non sovrapposti: sotto-potenziata per costruzione, e su una finestra in cui BTC è salito da
+  ~64,7k a ~77,5k — **avversa a un collar per costruzione**. La catena è servita a **calibrare**
+  (skew, termine, spread), che è l'uso in cui 161.964 quote hanno potenza.
+- **Nessun DSR, nessun `study_family_honest`.** Non servono: il filone cade al **primo** gate (M5),
+  e M2 si spende su ciò che il primo gate lascia in piedi.
+- **A6 e A7 non verificate** (lente reale non girata; il verso short è dentro i gate ma non
+  separato). Restano previsioni non misurate, non risultati.
+- **Il funding dei perp non è nel motore**, come in ogni backtest del progetto: −2,16%/a di drift.
+  Colpisce base e collar quasi allo stesso modo (stessa esposizione spot), quindi **non cambia il
+  segno del confronto**, ma abbassa entrambi.
+
+## 9. Verdetto
+
+> **`IL PAVIMENTO FUNZIONA — E' IL TETTO CHE NON SI PUO' PAGARE. E CIO' CHE VINCE SUL BORDO NON E'
+> LA PROTEZIONE: E' IL PREMIO DI VARIANZA, CIOE' VRP01`** — **REFUTATO come chiesto.**
+
+Con una postilla che è il vero risultato trasferibile: **la domanda «bloccare la perdita» ha
+risposta positiva sul maxDD (36/48) e negativa sul prezzo (45/48).** Su BTC il pavimento si compra
+meglio **tenendo meno BTC** che comprando una put e vendendo una call — e il de-levering, a
+differenza del collar, non tocca il rendimento nella coda destra dove BTC vive.
+
+## 10. Cosa lo riaprirebbe
+
+- Un **f di stress misurato su un crash catturato** — la stessa condizione che §3 pone allo
+  short-vol. Con quello, l'angolo covered-call diventa discutibile invece che escluso.
+- Un sottostante **senza coda destra grassa**: il tetto costa perché BTC vive lì. Su un asset a
+  distribuzione più simmetrica il baratto cambia di segno, e il conto va rifatto.
+- **Non** lo riapre un tenor diverso, un delta diverso o una griglia più fine: la pendenza è
+  monotona verso l'angolo short-vol, e l'angolo è già misurato.

docs/diary/2026-09-01-stato-trades.md

@@ -0,0 +1,92 @@
+# 2026-09-01 — Stato trades, e la riparazione che non si è propagata
+
+*Scritto il 2026-09-01, misure lette fra le 09:35Z e le 16:47Z. Numeri dalle serie citate.*
+
+## 1. Lo stato, in breve
+
+| | valore | fonte |
+|---|---|---|
+| fill registrati | **45**, dal 2026-07-14T14:00 al **2026-08-31T15:47** | `trades.db` |
+| round-trip chiusi | **29** (21 in utile) — lordo +41,43 · fee allocate 0,66 · **netto +40,77** | `trades.db` |
+| fee totali pagate | **$0,8617** | `trades.db` |
+| equity (lettura 16:47Z) | **$2.051,84** · picco $2.073,59 | serie `equity`, 1.657 letture |
+| posizione BTC | 0,0045 @ medio $79.208,11, dal 25/08 | libro di bordo |
+| posizione ETH | 0,0872 @ medio $2.473,04, dal 25/08 | libro di bordo |
+| non realizzato (mark 16:38Z) | **−$11,72** — BTC −7,91 (−2,22%) · ETH −3,80 (−1,76%) | gateway |
+| gross nozionale | $560,36 → **leva 0,27x** su un tetto di 1,0x | gateway |
+
+**Nessun fill da 25 ore, e non è un blocco.** Il log del cron lo dice a ogni giro fino alle 15:47:
+`=> Nessuna azione: conto gia' al target netto del book`. TP01 fermo a +0,461 (BTC) e +0,278 (ETH),
+SKH01 flat su entrambi, scarto posizione-target sotto il `min_order_usd` di $5 ($356 contro $351,
+$214 contro $213). Feed SKH fresco (0 min), disaster-SL armati a $55.428,0 e $1.708,9.
+
+`monitor_health`: **8/8 OK**, coperture 98-129%. Riconcilio a 3 fonti: **44/45 concordano, 0 prezzi
+divergenti**; l'unica coppia scoperta è il difetto già noto — stesso fill (ETH buy 0,04 @ 1869,74)
+timbrato `2026-07-14T14:00` nel log del cron e `2026-07-08` nel jsonl, i sei giorni di scarto della
+lezione già registrata. Non è un fill perso.
+
+## 2. Il difetto: `--report` stampa un rendimento che non è un rendimento
+
+`scripts/live/trades_db.py --report` stampa questa riga:
+
+```
+equity : $598.06 -> $2,051.84  (+1453.78, +243.08%) | picco $2,073.59 | 1657 letture
+```
+
+Accanto a una riga di P&L che dice `netto +40,77`. **Il +243% non è rendimento: è quasi tutto un
+versamento.** La serie di 1.657 letture orarie contiene **un solo salto**, il 2026-08-25 alle 11:47Z:
+$667,49 → $2.066,88, **+$1.399,39**.
+
+Non è una mia classificazione a occhio: è quella del progetto. `journal.movimenti_capitale()`, che
+importa la soglia viva da `book.EQUITY_JUMP_ALERT` (0,10) e confronta il salto col massimo che il
+**mercato misurato** avrebbe potuto produrre in quell'ora a tetto di leva, restituisce
+`certi 1399.39 · ambigui 0.0`, un solo evento, classe `movimento`.
+
+Al netto:
+
+| lettura | valore |
+|---|---|
+| periodo 1 — 23/06 22:00Z → 25/08 10:47Z ($598,06 → $667,49) | **+11,61%** |
+| periodo 2 — 25/08 11:47Z → 01/09 16:47Z ($2.066,88 → $2.051,84) | **−0,73%** |
+| **TWR spezzato sul versamento** | **+10,80%** |
+| crescita di equity al netto del versamento, 69 giorni | **+$54,39** |
+
+**Il numero regge al controllo incrociato.** Il giornale del 31/08, che lo scorporo lo fa già,
+scrive: *«cumulato dall'arming: $+1.461,39 di equity — di cui $+1.399,39 versati/prelevati ->
+trading $+62,00»*. Stessa base ($598,06), stesso versamento; la differenza fra i suoi +62,00 e i
+miei +54,39 è **−7,61 di marcatura** fra l'ultima lettura del 31/08 e quella di oggi. Le due misure
+concordano.
+
+### Perché è un difetto e non un dettaglio di stampa
+
+La riparazione **esiste già, e in questo stesso repo**. `src/live/journal.py:121` la porta scritta
+nel docstring, col caso d'origine:
+
+> *«Il P&L di giornale e' un delta di equity, quindi un versamento ci finisce dentro come se fosse
+> profitto: la voce del 2026-08-25 dichiarava «giorno: +$1.414,57» quando $1.399 erano un deposito
+> USDC, e il «cumulato dall'arming» avrebbe mentito per sempre.»*
+
+Quel difetto fu trovato e riparato nel giornale. **`trades_db.py:83` non ha mai ricevuto la
+riparazione**: calcola `100*(e1/e0-1)` sulla serie grezza e non chiama `movimenti_capitale()`, che
+è a un import di distanza e restituisce già `certi` e `ambigui` pronti da scorporare.
+
+È una variante di **P1** — non un sorvegliante che ridichiara il proprio bersaglio, ma **una
+riparazione che non ha attraversato il confine fra due lettori della stessa serie**. Il primo
+strumento dice la verità; il secondo, interrogato con lo stesso comando pubblicato in CLAUDE.md §13
+(`trades_db.py --report`), stampa un numero che si legge come una performance ed è per il **96,3%**
+un bonifico.
+
+**Danno oggi: nessuno sui soldi** — `--report` è in sola lettura e non decide niente. Il danno è di
+citazione: è esattamente la classe di numeri che §2 raccoglie sotto *«non citare»*, ed è l'unico che
+il progetto produce **su richiesta esplicita di un comando documentato**.
+
+## 3. Cosa NON ho fatto
+
+**Non ho toccato il codice.** La riparazione è piccola — chiamare `movimenti_capitale()` e stampare
+la riga scorporata accanto a quella grezza, come fa il giornale — ma sta su uno script che legge il
+libro di bordo vivo, e la richiesta era di aggiornare i documenti. Registrata come debito aperto.
+
+Non ho scomposto la differenza fra il P&L dei round-trip (+$40,77) più il non realizzato (−$11,72)
+= **+$29,05** e i +$54,39 di equity al netto del versamento. Lo scarto di ~$25 sta in voci che il
+conteggio round-trip non copre — funding dei perp (non modellato in nessun backtest, §2), reward
+USDE, marcatura dell'USDE all'indice. A questa taglia non vale il costo della misura: si dichiara.

docs/diary/2026-09-01b-chiave-di-scala.md

@@ -0,0 +1,166 @@
+# 2026-09-01 — La chiave di scala esiste, ed è inerte
+
+*Scritto il 2026-09-01. Implementazione dei punti 1-4 di `docs/research/SPEC-scale-key.md` §8.*
+**Nessun ordine. `config/live.json` NON è stato toccato: il libro che gira è bit-exact quello di ieri.**
+
+## 0. Da dove nasce
+
+Il progetto aveva una regola — *«ogni cambio di scala passa dal cap di config, non da `target_vol`»* —
+e CLAUDE.md la accompagnava da settimane con questa nota:
+
+> ⚠️ **NON È IMPLEMENTABILE COME SCRITTA:** in `config/live.json` non esiste una chiave di scala.
+
+Era un debito preciso: la regola prescriveva un percorso che non esisteva, quindi qualunque cambio
+di scala sarebbe finito su `WEIGHT`/`W_TP01`/`W_SKH` in `src/live/book.py` — cioè codice su un
+percorso con soldi veri, e per giunta nel posto sbagliato (`W_TP01`/`W_SKH` sono il **rapporto**
+75/25, non la taglia: moltiplicarli romperebbe la parità coi pesi del backtest).
+
+La specifica era già scritta, 618 righe, con nove condizioni di gate e il prototipo che ne dimostra
+la meccanica. **Non ho progettato niente: ho eseguito.**
+
+## 1. Il rischio che l'implementazione doveva rendere impossibile
+
+La §0 della specifica lo dice meglio di come lo direi io:
+
+> *Una chiave di scala è esattamente il tipo di parametro che si alza «solo un po'» dopo un mese
+> buono. È un numero, sta in un file di config, non richiede di capire niente per cambiarlo, e il
+> suo effetto è immediato e piacevole.*
+
+E il motivo per cui il progetto non aveva già una guardia non è dimenticanza, è **aritmetica**:
+**lo Sharpe è invariante alla scala.** `deflated_sharpe` e `marginal_vs_tp01` leggono un numero che
+a k=1,00 e a k=2,00 è identico. Non falliscono: **non vedono**.
+
+## 2. Cosa ho costruito
+
+| pezzo | dove | cosa fa |
+|---|---|---|
+| `book_scale_k` | `config/live.json` — **assente** | la chiave. Assente = 1,00 = libro di sempre |
+| `_scala()` | `src/live/book.py` | legge, **valida sempre**, applica solo sul percorso fidato |
+| `book_net_target(..., scala=)` | `src/live/book.py` | applica la scala **DOPO il clamp** |
+| `LEVA_LORDA_MAX` 1,25 · `SCALA_LADDER` (1,00 · 1,25) · `DISASTER_SL_BUDGET` 0,50 | `src/live/book.py` | **costanti di CODICE** |
+| `ScalaNonAutorizzata` | `src/live/book.py` | eccezione, **non** un clamp |
+| riga «scala libro» + stop-e-allerta | `scripts/live/book_execute.py` | la scala è visibile a ogni giro |
+| `scale_watch` | `src/live/` + `scripts/live/` + `cron_daily.sh` | 3 domande, 3 azioni, 3 stati |
+| `scale_history.jsonl` | `data/live/` | giornale append-only (già nel backup) |
+| T1-T11 | `tests/test_book_scale.py` | **18 test, tutti verdi** |
+
+### 2.1 Le quattro decisioni che non sono di comodo
+
+**(a) La scala si applica DOPO il clamp.** Applicandola prima, il cap se la mangerebbe *proprio nei
+giorni di massima convinzione*: a `tp=1, sg=+1` il grezzo vale esattamente `cap`, quindi `k_eff`
+tornerebbe a 1,00 a ogni k. Il risultato non sarebbe «il libro a leva k» ma un libro che alza i
+giorni piccoli e lascia fermi i grandi — un cambio di **forma** travestito da cambio di taglia. E
+allora la curva `g(k)` con cui il gradino viene autorizzato **non descriverebbe quel libro**.
+*Autorizzare con una curva e implementarne un'altra è il modo più silenzioso di sbagliare.*
+Il prezzo, dichiarato: il cap smette di essere il tetto assoluto del nozionale e diventa il tetto
+del libro **unitario**. La guardia sulla leva lorda è ricostruita esplicitamente altrove.
+
+**(b) Il tetto è sul PRODOTTO, e sta nel CODICE.** Un tetto sulla sola chiave lascia aperta la porta
+accanto: `frac` 0,625 × scala 1,25 = **1,562x**, che passerebbe. E un tetto in config sarebbe
+modificabile dalla stessa mano, nello stesso file, nello stesso momento — *un lucchetto con la chiave
+attaccata*. Con `LEVA_LORDA_MAX` in `src/live/book.py`, il gradino 1,25 → 1,50 richiede una modifica
+di codice, quindi una review. **Il tetto è basso apposta: è il meccanismo del cricchetto.**
+
+**(c) Fuori scaletta o fuori tetto = STOP, non clamp.** `book_execute` si ferma, non invia, allerta.
+Tagliare silenziosamente farebbe girare una config che *dichiara* un numero e un libro che ne
+*esegue* un altro. E `SCALA_LADDER` esiste perché **una scala a gradini rende inesprimibile «solo un
+po'»**: 1,05 non è un valore prudente, è un valore fuori scaletta, e viene rifiutato.
+
+**(d) La scala vive solo sul percorso fidato.** Equity reale illeggibile ⇒ scala 1,00. *Una scala è
+una decisione di rischio presa conoscendo il conto; quando non si sa quanto vale il conto, non si
+prende.* Così «il fallback non è più permissivo» è vero **per costruzione**, non per aritmetica.
+⚠️ Ma la **validazione** avviene comunque, anche sul percorso degradato: una config rotta è un
+errore di configurazione, non una condizione di mercato, e non deve nascondersi dietro un giro in
+cui l'equity non era leggibile.
+
+### 2.2 La guardia che morde per prima, e non è quella che sembra
+
+Il disaster-SL è un movimento di **prezzo** (−30% sul mark), ma il suo impatto in equity è quel
+movimento **moltiplicato per il lordo** — quindi cresce con k anche se `disaster_sl_pct` non cambia:
+
+- dal peggior giorno possibile: `k ≤ 3,49x`
+- **dal costo di un disaster-SL: `k ≤ 1,67x`** ← **2,1× più stringente**
+
+Da qui l'invariante `n_asset · frac · scala · disaster_sl_pct ≤ 0,50`, che scatta anche se qualcuno
+allarga lo stop invece di alzare la scala.
+
+## 3. Il test che conta più degli altri
+
+**T1b**, e la ragione per cui la specifica gli dedica un paragrafo: **a k=1 l'implementazione
+simmetrica e quella asimmetrica danno lo stesso identico numero.** Un test di simmetria scritto sul
+caso di default passa sempre e non controlla niente — potenza **zero**, la stessa firma dei test di
+`book_live` scoperti senza potenza a libro flat.
+
+T1b quindi verifica due cose: *(a)* che a k=1 le due implementazioni siano davvero indistinguibili
+(cioè che il rischio sia reale), e *(b)* che fuori da k=1 l'asserzione di T1 le **separi**. Nel test
+c'è scritta un'implementazione asimmetrica apposta perché fallisca.
+
+Gli altri: T2/T3 i due tetti letti da config coi bersagli **importati** dalla produzione; T4 il
+fallback mai più permessivo in ogni stato degradato; T5 il cap che morde ancora; T6 lo stop non
+clampato (più T6b sul prodotto e T6c sul disaster-SL); **T7 l'inerzia bit-exact**; T8 il report che
+la dichiara; T9 i bersagli derivati e non ridichiarati; T10 il **controllo positivo del
+sorvegliante** (con una config non autorizzata deve parlare, con config e giornale concordi deve
+tacere) più T10b sulla disciplina degli allarmi e T10c sui tre stati; T11 che il vecchio test sia
+stato **sostituito, non rilassato**.
+
+## 4. Il sorvegliante, e cosa non può fare
+
+`scale_watch` gira in `cron_daily` e risponde a tre domande che hanno **tre azioni diverse**:
+
+| domanda | azione se 🚨 |
+|---|---|
+| la config dichiara una scala che il **giornale** non ha mai autorizzato? | ricostruire come ci si è arrivati, scendere a k0 |
+| il criterio che autorizzò la scala **corrente** passa ancora oggi? | scendere di un gradino |
+| il **prodotto** `frac · scala · n_asset` ha superato il tetto? | bloccare l'esecuzione |
+
+Tre stati (`OK` / `ALLARME` / **`NON MISURABILE`**), una allerta per streak, e il marcatore «già
+detto» scritto **solo dopo un invio riuscito** (il debito #2 del 28/08: un 🚨 perso prima era perso
+per l'episodio intero).
+
+Riporta anche la **frequenza del ramo di fallback**, che se superasse il 2% in 90 giorni
+invaliderebbe la regola (d): il libro girerebbe a una leva **mista** e `g(k)` smetterebbe di
+descriverlo. Misurata oggi: **0 giri su 1.676**. ⚠️ I 19 giri senza equity reale sono tutti
+«paper capital», cioè **pre-finanziamento**, dove il libro non invia affatto — il sorvegliante li
+conta e li dichiara separatamente invece di gonfiare la quota.
+
+🚨 **Ciò che il sorvegliante NON può fare: impedire la modifica.** Chi ha accesso al file può
+scriverci dentro. Rende la modifica visibile entro 24 ore e attribuibile. È la stessa onestà di
+`venue_watch`: non protegge il saldo, **compra tempo**.
+
+## 5. Verifica che il libro non è cambiato
+
+```
+  sizing base     : $2,052.22 | cap/asset $1026 | min $5 | disaster-SL -30%
+  scala libro     : 1.00x (tetto 1.25x) | leva lorda max 1.000x dell'equity  [chiave assente o 1,00 = libro invariato]
+  BTC TP +0.461 · SKH +0(flat) -> net $+355 | pos $+357 -> HOLD (a target)
+  ETH TP +0.278 · SKH +0(flat) -> net $+214 | pos $+212 -> HOLD (a target)
+```
+
+Gli stessi target del cron delle 15:47. **Suite: 825 passati** (807 + 18 nuovi).
+
+## 6. Cosa NON ho fatto, ed è deliberato
+
+**Non ho scritto la chiave in config.** Il punto 2 della checklist lo prescrive esplicitamente, e T7
+dimostra bit-exact che senza la chiave il libro è quello di prima.
+
+**Non ho eseguito GATE SCALA-01**, e non era possibile: A2 richiede che k0 sia in produzione con il
+criterio passato ogni giorno, e il punto 5 impone **≥30 giorni a 1,00 col sorvegliante attivo prima**
+di eseguire il gate. Cito la specifica perché la frase è il motivo:
+
+> *Il punto 5 non è burocrazia: è l'unico modo di scoprire che il sorvegliante è rotto mentre la
+> leva è ancora 1,00.*
+
+**Non ho rifatto `r0726_fee_sensitivity`** (A7). Serve solo *se* e *quando* il gradino viene chiesto:
+la sua conclusione «liquidation fee 1% irrilevante» era condizionata a lordo ≤1x, e a 1,25x una
+liquidazione costerebbe **1,25%** dell'equity. Non è un problema, è un numero da ricalcolare — e
+ereditarlo sarebbe l'errore.
+
+📌 **A6 (anti-recency) oggi non morde**: `k_ammesso ≈ 3,5x` contro un gradino di 1,25x, e il vincolo
+che morde è il disaster-SL. È scritto adesso **perché adesso non è comodo per nessuno** — che è
+l'unico momento in cui una regola del genere si può scrivere onestamente.
+
+## 7. Stato del gate
+
+`GATE SCALA-01` è ora in CLAUDE.md §4 con data **non prima del 2026-10-01**. A8 e A9 sono fatti;
+A2 matura col tempo; A1/A4/A5 sono aritmetica già cablata; A3/A6/A7 si eseguono il giorno del gate,
+sui dati di quel giorno, non su questi.

docs/diary/2026-09-01c-pavimento-leva.md

@@ -0,0 +1,137 @@
+# 2026-09-01 — PAVIMENTO-LEVA: il pavimento non licenzia taglia, e corregge quanto scritto stamattina
+
+*Scritto il 2026-09-01. Ogni numero è riprodotto da `scripts/research/r0901c_pavimento_leva.py`,
+che riusa il motore di `r0901_btc_collar.py`. **Libro, pesi, cron, config INVARIATI. Nessun ordine.***
+
+## 0. La domanda
+
+> *«possiamo usare quanto conosciamo del pavimento per studiare una strategia»*
+
+Cosa sapevamo, da COLLAR01 (§71, poche ore prima): il collar riduce il maxDD in 36/48 celle; a
+premio **zero** il pavimento vale moltissimo (maxDD 51,83% → 36,76%, drift +10,04% → +35,69%); ciò
+che uccise il collar fu il **tetto**, non il pavimento (C9); la put è l'ala cara.
+
+**L'inversione.** COLLAR01 chiese *«quanto DD mi risparmia il pavimento a taglia fissa?»* e perse
+contro il de-levering. La domanda speculare è *«quanta TAGLIA mi autorizza il pavimento a DD
+fisso?»*. Non è la stessa, per due ragioni misurabili:
+
+1. de-levare riduce taglia e rischio **in proporzione**; un pavimento cambia la **forma** — se taglia
+   la coda sinistra più di quanto costi, scalare *in su* la struttura protetta può battere la base
+   nuda alla stessa DD. È l'unica cosa che il de-levering **non può** comprare;
+2. il tetto di leva del progetto non è fissato dallo Sharpe ma dal **costo di un episodio** di
+   disaster-SL (`n · frac · scala · sl ≤ 0,50` ⇒ k ≤ 1,67x). Il disaster-SL è **rotolante** e non
+   limita la perdita (peggior DD dall'ingresso misurato −60,6%). Una put la limita per costruzione —
+   *dentro la sua finestra*.
+
+Quattro attese scritte prima di misurare (B1-B4). **Tutte e quattro confermate.**
+
+## 1. Il risultato: 0 celle su 16
+
+Griglia dichiarata: 4 δput × 2 tenor × 2 gate. Struttura: hold gated + **sola put**, premio reale
+(DVOL × skew × termine dalla catena — realistico per chi *compra*: M29 corregge chi vende a
+modello, non chi compra).
+
+| gate | base nuda | pavimento a premio reale (16 celle) |
+|---|---|---|
+| FORTE | maxDD **51,83%** · drift +10,04% | maxDD **55,4% → 75,8%** · drift +3,8% → −17,0% |
+| LARGO | maxDD **71,94%** · drift +17,37% | maxDD **74,8% → 81,7%** · drift +9,9% → −13,9% |
+
+**Il pavimento peggiora il maxDD in 16 celle su 16.** Quindi `k_f = 1,000` ovunque: non c'è taglia
+da licenziare, perché non c'è DD da spendere. Il null M5 classico concorda (0/16). Monotono nella
+protezione: più la put è vicina, peggio va — il bleed del premio *è* il drawdown.
+
+## 2. 🚨 La correzione a COLLAR01
+
+Stamattina ho scritto, in A1: *«il pavimento funziona davvero (e §46 è battuto sul suo motivo)»*.
+**La prima metà è sbagliata nell'attribuzione.** Il DD lo riduce **il collar**, non il pavimento:
+
+- la put da sola, a premio reale, **peggiora** il DD (questo filone);
+- a premio zero lo riduce (il controllo del pranzo gratis) — quindi **tutto il beneficio del
+  pavimento è mangiato dal suo premio, e oltre**;
+- nel collar la riduzione viene dal **tetto**: il suo premio compensa il bleed della put, e cappare
+  l'upside **abbassa il picco** da cui il DD si misura — che non è protezione, è un picco più basso.
+
+**Il premio di pareggio** lo quantifica: il pavimento inizia a ridurre il DD nudo solo se le put
+costano il **36-79% del reale** (secondo la cella). Il DVOL sta 1,32× sopra la vol realizzata, quindi
+un prezzo *equo* sarebbe ~76% del reale: **anche a prezzo equo il pareggio si sfiora nelle celle
+migliori e si manca nelle altre**. E il mercato non vende a prezzo equo.
+
+La seconda metà della frase regge, ma va detta con precisione: **il motivo di §46 non si applica**
+(a beta 1,0 la put paga davvero: para nel 2-20% dei cicli), **ma il verdetto di §46 — *il maxDD
+SALE* — si riproduce a beta 1,0 per un motivo diverso.** Il motivo è la sezione seguente.
+
+Corretti stesso giorno: il diario di COLLAR01 (titolo e A1), RESULTS §71, la memoria. M28:
+*quando due affermazioni della stessa memoria si contraddicono, la contraddizione è informazione* —
+qui erano due mie affermazioni a poche ore di distanza, e la seconda ha corretto la prima.
+
+## 3. B2 — Il meccanismo: la put copre una finestra, BTC scende in grind
+
+| gate | maxDD della base | da → a | durata |
+|---|---|---|---|
+| FORTE | −51,83% | 2021-07-20 → 2022-05-06 | **290 giorni** |
+| LARGO | −71,94% | 2021-07-20 → 2023-10-16 | **818 giorni** |
+
+Una put a 7-14 giorni copre **una** finestra. Il drawdown che conta è lungo **20-60 finestre**. In
+un grind la put scade OTM settimana dopo settimana — il pavimento para nel **0-9%** dei cicli col
+gate FORTE — mentre il premio sanguina. E non protegge nemmeno la finestra peggiore: peggior 14
+giorni FORTE **−22,9% nudo → −23,6% col pavimento**, perché la put a 5 delta sta a ~22% dallo spot,
+cioè esattamente al bordo di ciò che è successo, e il premio la rende netta negativa.
+
+**Su BTC il pavimento compra protezione contro la cosa sbagliata**: i crolli veloci dentro una
+finestra, mentre le perdite che definiscono il maxDD sono grind di mesi. Questo è ciò che §46 non
+poteva vedere (a beta 0,076 il libro non aveva né crolli né grind da proteggere) e che a beta 1,0
+diventa il fatto dominante.
+
+## 4. B3 — La licenza del disaster-SL è di carta
+
+L'invariante `n · frac · scala · sl ≤ 0,50` con `sl = 0,30` dà **1,67x**. Con la put a 5δ/14g il
+pavimento sta a **21,9%** dallo spot: sostituire `sl` con quella distanza darebbe **2,28x** —
+*1,4× in più*. È la proposta che qualcuno farà, e va uccisa ora:
+
+| finestre consecutive | giorni | peggior perdita col pavimento | la put… |
+|---|---|---|---|
+| 1 | 14 | −23,6% | copre |
+| 2 | 28 | −25,9% | **non copre** |
+| 4 | 56 | −28,8% | **non copre** |
+| 8 | 112 | **−33,6%** | **non copre** |
+
+L'invariante limita **un episodio**; la put limita **una finestra**; il massimo su finestre
+consecutive **non è limitato da nulla**. A 2,28x un grind di 112 giorni costerebbe il **77%
+dell'equity**. ⇒ **`disaster_sl_pct` non si sostituisce con la distanza di un pavimento**, e va
+scritto prima che sia comodo per qualcuno.
+
+## 5. B4 — Il pavimento gated sull'IV: migliora, non basta
+
+§46 dichiarava *«nessuna copertura dinamica gated su regime è stata provata»*. Provata: put ON solo
+quando DVOL/RV trailing sta sotto il 25° o 50° percentile dell'anno (il premio di varianza è
+sottile).
+
+| gate | soglia | ON (giorni a mercato) | drift | vs base |
+|---|---|---|---|---|
+| FORTE | 25° pctl | 27% | **+8,39%** | +10,04% → **perde** |
+| FORTE | 50° pctl | 47% | +6,77% | perde |
+| LARGO | 25° pctl | 25% | **+15,31%** | +17,37% → **perde** |
+| LARGO | 50° pctl | 50% | +13,93% | perde |
+
+Migliora molto rispetto al pavimento sempre acceso (+3,8% → +8,4% col gate FORTE) e il DD resta
+≥ della base (k_f = 1,000). ⚠️ L'incollatura ignora lo spread delle transizioni ON/OFF, **a favore**
+del gated: se perde così, perde a maggior ragione.
+
+## 6. Cosa NON ho fatto, dichiarato
+
+- Nessun DSR, nessun `study_family_honest`: il filone cade al primo gate, 0/16.
+- Nessuna lente reale (123 giorni, ~8 cicli): stessa ragione di COLLAR01.
+- Non ho provato il pavimento **a scadenza lunga** (30-90 giorni), che coprirebbe più di una
+  finestra di grind — perché l'operatore ha vincolato la scadenza a **≤15 giorni**. È l'unica
+  variante che B2 lascia aperta, e sta fuori dal vincolo dichiarato. Va detto: se il vincolo cadesse,
+  sarebbe la prima cosa da misurare, e la memoria di §46 ha già l'apparato (tenor 30).
+
+## 7. Verdetto
+
+> **`IL PAVIMENTO NON LICENZIA TAGLIA A PREMIO REALE: 0/16. Ciò che il de-levering non può comprare,
+> la put lo vende a un prezzo che nessuna cella ripaga — e su BTC compra protezione contro i crolli
+> mentre le perdite sono grind.`** — REFUTATO.
+
+**Cosa lo riapre:** una scadenza che copra il grind (fuori dal vincolo ≤15g), o un mercato che venda
+la put al 36-79% del prezzo attuale — cioè un premio di varianza *negativo*, che su BTC non si è
+mai misurato. Non lo riaprono delta, tenor ≤15 o gate sull'IV: sono misurati.

docs/diary/2026-09-01d-soldi-fermi.md

@@ -0,0 +1,91 @@
+# 2026-09-01 — Soldi fermi: i modi esistono, valgono €5/mese, e uno di loro distruggerebbe lo split
+
+*Scritto il 2026-09-01. Numeri da `scripts/research/r0901d_soldi_fermi.py`; tassi dal web con fonte e
+data (cutoff del modello 05/2026: non li sapevo). **Non sono pareri fiscali.** Nessun ordine.*
+
+## 0. La domanda
+
+> *«troviamo altri modi per fare guadagnare con soldi che sarebbero fermi. non per forza trading»*
+
+## 1. Dove sta il capitale fermo — e cosa NON lo è
+
+**Deribit (lettura 20:42Z):** USDC $1.406 · USDE 654 · libro a 0,27x. ⚠️ **L'USDC non è fermo**: è
+la base di sizing del libro (cap = equity × 0,5) e il cuscino di regolamento del disaster-SL. Spostarlo
+fuori rimpicciolisce le posizioni, non libera capitale.
+
+**Fuori:** ~€6.043 in XEON «a ~0% reale netto» (memoria 27/07). È lo **split-cassa** — la protezione
+dal rischio venue, P(perso tutto) 18% → 3,5% a p=1% — e la memoria dichiara di non sapere quanto sia
+fondo d'emergenza. **Assunzione dichiarata: €6.000 investibili a 12+ mesi.**
+
+## 2. On-venue: chiuso, e stavolta con l'elenco intero
+
+`public/get_currencies` oggi: **4 valute su 50** con APR > 0 — USDE 4,32 · USDC 3,40 · BUIDL 3,20 ·
+STETH 2,22. Sono esattamente le quattro chiuse il 31/08 (al tetto · Italia esclusa · non
+acquistabile · è ETH). Non era un campione: era la lista.
+
+## 3. I modi, in euro netti l'anno su €6.000
+
+| opzione | lordo | fisco | **netto/anno** | vs XEON | rischio | split |
+|---|---|---|---|---|---|---|
+| XEON (status quo) | 2,10% | 26% | **€81** | — | ~0 | intatto |
+| **BOT 12 mesi** | 2,77% | **12,5%** | **€133** | **+€52** | ~0 (Stato) | intatto |
+| **Conto deposito vinc. 12m** | 3,50% | 26% | **€143** | **+€62** | ~0 (FITD) | intatto |
+| sUSDe diretto (Ethena) | ~9% | 33% | €350 | +€269 | **emittente + smart contract** | **distrutto** |
+| versare sul libro | ~10% atteso | — | ~€600 | +€519 | maxDD 11%, venue | **distrutto** |
+
+Fonti: BOT 2,768% asta agosto 2026 (Banca d'Italia 14/08); BCE DFR 2,25% (23/07) ⇒ €STR ~2,2%;
+conti deposito 3,25-3,50% (Aidexa, Banca Progetto, Cherry, settembre 2026); sUSDe «high single
+digits» Q2 2026 (9,4% 7g / 11,8% 90g ad aprile). Bollo 0,2% su tutto.
+
+## 4. La lettura
+
+- **Fra le opzioni che lasciano intatto lo split, la migliore vale +€62/anno = €5/mese.** BOT e conto
+  deposito distano €10/anno: il 12,5% del BOT compensa quasi tutto il lordo in meno. Dentro il
+  rumore di *una* asta.
+- **sUSDe diretto rende ~2× Deribit** (che trattiene metà dell'APR Ethena) — ma metterebbe i €6k
+  sullo **stesso emittente** dei 654 USDE già in conto. Lo split-cassa esiste per non essere
+  correlato al venue e al crypto: questa opzione lo trasforma in concentrazione. Già a 24,2% di quota
+  l'evento emittente vale 3,1× il maxDD dell'intero libro (memoria 30/08).
+- **Versare sul libro** è l'alternativa che la memoria indica come dominante (€10k = 2,45× in 13
+  anni) — ma è trading, e distrugge lo split. Non risponde alla domanda: la cambia.
+
+## 5. La taglia
+
+Il miglior guadagno *sicuro* sullo status quo è **€62/anno**. **€100/mese di bonifico valgono
++4,07%/anno di drift.** Il modo esiste, è reale, ed è due ordini di grandezza sotto la leva che il
+progetto ha misurato sei volte come binding.
+
+## 6. Cosa resta all'operatore
+
+1. **Quanto dei €6.043 è fondo d'emergenza.** Con quello, la tabella si applica al resto.
+2. Fra BOT e conto deposito: **preferenza di liquidità** (MOT vs vincolo 12 mesi) e di controparte
+   (Stato vs FITD), non di rendimento — la differenza è €10/anno.
+3. On-venue non c'è niente da decidere. La chiave di scala a 1,25x (GATE SCALA-01, ottobre)
+   libererebbe ~$400 → ~$10/anno: lo dico perché è l'unica via strutturale, non perché valga.
+
+## 7. La conclusione dell'operatore (02/09, 06:00Z) — e le tre precisazioni
+
+> *«quindi la miglior cosa è mettere gli XEON su deribit con il nostro sistema attivo»*
+
+**Sì, ed è la conclusione che la memoria aveva già scritto il 27/07** (`r0727_lumpsum_split.py`:
+piano «€5.000 dei €6.043 in XEON + €500/mese»; il 25/08 sono entrati $1.399, non €5.000). La
+lettura della tabella è quella giusta: versare batte tenere fermo, ed è la leva binding. Ma il
+*come* ha tre vincoli, tutti già misurati:
+
+1. **Non tutti: €5.000, non €6.043.** La protezione dal rischio venue **satura a qualunque quota
+   > 0** (P(perso tutto) 18% → 3,5% tenendo fuori il 10%, e resta 3,5% al 25% e al 40%). L'ultimo
+   migliaio dentro compra ~€100/anno attesi e butta via l'intera assicurazione. **~€1.000 restano
+   fuori: è lo split, e costa zero.**
+2. **Il «~€600» non è un tasso.** È un'attesa a banda larga su una strategia a mercato il 22% dei
+   giorni (live: 14/64, leva mediana 0,00x). Numeri onesti: TWR **+10,8% in 70 giorni**, Sharpe
+   hold-out TP01 **~+0,05**, fisco d'accumulo **−30% a 10 anni**. Un anno piatto è possibile; il
+   conto deposito non lo ha.
+3. **Il fondo d'emergenza** — non dichiarato dall'operatore, non noto alla memoria. Se una parte
+   dei €6.043 lo è, resta fuori.
+
+**Operativamente non serve nulla:** il sistema è live dal 20/06, il cap è dinamico (`equity × 0,5`),
+il rilevatore di salti ha già gestito il 25/08 senza falsi allarmi. Il deposito viene assorbito al
+giro successivo delle :47. Resta da scrivere **una riga di giornale con data e importo** — la fonte
+del cumulato dall'arming va scritta prima, non ricostruita dopo (debito #14). **In attesa di importo
+e data dall'operatore.** N9: le opzioni sicure (+€52-62/anno) sono state viste e messe da parte
+*con motivo*, non ignorate.

docs/diary/2026-09-02-debito-14-report-twr.md

@@ -0,0 +1,76 @@
+# 2026-09-02 — Debito 14: il report stampa il TWR, non il bonifico
+
+*Scritto il 2026-09-02 fra le 14:16Z e le 14:22Z (commit `2f701b8`, 14:22:50Z; la prima stesura diceva «fino alle 14:30Z» senza averlo letto — corretto in revisione). Numeri dalla lettura di equity delle 13:47:01Z (1.678 letture) e dal report rilanciato dopo la riparazione.*
+
+## Cosa c'era
+
+`trades_db.py --report` calcolava `100*(e1/e0-1)` sulla serie grezza di equity e lo stampava come
+performance: **+243%**. La serie contiene un solo salto, il versamento di $1.399,39 del 25/08
+11:47Z: il 96,3% di quel numero era un bonifico. Il classificatore che lo scorpora esisteva già
+(`journal.movimenti_capitale`, dal 25/08) e non era mai arrivato al secondo lettore della stessa
+serie. Trovato e registrato il 01/09 (`2026-09-01-stato-trades.md`), non riparato perché lo script
+legge il libro vivo.
+
+## Cosa ho fatto
+
+| pezzo | dove | cosa |
+|---|---|---|
+| funzione unica | `src/live/journal.py` → `rendimento_twr(con, fino_ts)` | chiama `movimenti_capitale`, spezza la serie all'equity PRIMA e DOPO ogni movimento **certo**, moltiplica i segmenti. Gli **ambigui non spezzano** (P12): restano nel rendimento, dichiarati. Tre stati: numero, o `None` con `motivo` |
+| il report | `scripts/live/trades_db.py` → `report()` | chiama `rendimento_twr` (P1: non rifà il conto). Stampa TWR con i segmenti datati, i movimenti elencati con la classe, `trading da arming`, e il delta $ grezzo etichettato «movimenti di capitale INCLUSI». Il `%` grezzo non compare più |
+| test | `tests/test_journal.py` (+5) · `tests/test_trades_report.py` (+2) | versamento spezzato e grezzo no · senza movimenti = rendimento semplice · ambiguo non spezza · serie vuota → `None` con motivo · **riproduzione del +10,80% del diario 01/09** (M23) · il testo stampato contiene TWR e non il grezzo · `connect()` nudo deviato in tmp (conftest), verificato nel test |
+
+## Il report, prima e dopo
+
+```
+prima:  equity : $598.06 -> $2,051.84  (+1453.78, +243.08%)
+
+dopo:   equity             : $598.06 -> $2,048.40  (+1,450.34 di equity, movimenti di capitale INCLUSI) | picco $2,073.59 | 1678 letture
+        movimenti capitale : +1,399.39 certi | +0.00 ambiguo/i (restano nel P&L, dichiarati)
+            2026-08-25T11:47  +1,399.39  [movimento]
+        trading da arming  : +50.95  (equity al netto dei movimenti certi)
+        TWR                : +10.61%  = +11.61% [2026-06-23 -> 2026-08-25] x -0.89% [2026-08-25 -> 2026-09-02]
+```
+
+Il giornale del giorno concorda: «cumulato dall'arming $+1.450,34 — di cui $+1.399,39 versati ->
+trading **$+50,95**». Stessa base, stesso versamento, stessa funzione.
+
+## Una cosa imparata riparando
+
+Quattro test sono nati rossi con scenari a **+10% di trading** fra due letture: la soglia del
+rilevatore (`book.EQUITY_JUMP_ALERT`) è esattamente 0,10, e a mercato piatto un +10% supera «2× il
+massimo che il mercato poteva fare» (che è zero) — viene classificato **movimento**. Non è un difetto
+della riparazione: è il limite già dichiarato del rilevatore live (D5, nel docstring di
+`movimenti_capitale`). Nella serie vera non morde — fra due letture orarie consecutive il trading non
+fa +10% — ma un test che lo tocca lo rende visibile. I test ora usano +5%, e il limite è scritto
+nel test, nel CLAUDE.md e qui.
+
+## Cosa NON ho fatto
+
+- Il giornale (`pnl_giorno`, pagina markdown) **non stampa il TWR**: stampa già lo scorporo in
+  dollari e la sua pagina ha una forma testata. Aggiungerlo è una riga, ma non era il debito.
+- Non ho scomposto lo scarto (~$25) fra round-trip + non realizzato e il trading al netto: era già
+  fuori scope il 01/09 e lo resta.
+
+## Revisione del codice, prima tornata (15:15Z, commit `835e0c8` 15:17:05Z) — tre cose trovate, tutte riparate
+
+| trovato | vero? | riparazione |
+|---|---|---|
+| l'intervallo che contiene un movimento certo esce intero dal rendimento: il suo P&L di mercato finisce in `certi` e fuori da `trading`, e nessun documento lo diceva | sì, per costruzione. Errore massimo = metà del movimento riconosciuto (margine del classificatore). Il 25/08: ~$263 lordi a ±0,2% → ~$0,5 | dichiarato nel docstring, nel report, in CLAUDE.md §5.14 e in memoria 40. Non si stima (P12) |
+| a base di equity zero `trading` era un numero mentre `twr` era None, e sbagliato: il salto 0→X è invisibile al classificatore, `trading` valeva l'intero conto sotto l'etichetta "al netto dei versamenti" | sì. Non raggiungibile dal cron (non scrive mai 0), ma raggiungibile da un backfill | tre stati veri: `twr` e `trading` entrambi None con motivo; il report stampa n/d. Test in `test_journal.py` e `test_trades_report.py` |
+| movimento nel primo intervallo o due consecutivi → segmento `+0.00% [x -> x]` | sì, cosmetico | i segmenti a lunghezza zero non si producono; nessun tempo a mercato → TWR 0,0 dichiarato numero. Test |
+
+Il numero pubblicato non cambia: +10,61% alle 14:02Z, +10,56% alle 14:47Z per la marcatura.
+
+## Seconda tornata (15:30Z) — la piu' importante di tutte
+
+| trovato | vero? | riparazione |
+|---|---|---|
+| il classificatore dei movimenti era **cieco ~23 ore al giorno**: il feed 1h si ferma alle 00:00, `asof` dava la stessa barra alle due letture, mercato «fermo» = 0, qualunque calo ≥10% del giorno diventava «movimento». Riprodotto dalla revisione su copia del DB: −12% appeso alle 14:47 → `certi` 1.399 → 1.153, TWR invariato invece di −2,71% | si'. Verificato: ultima barra 00:00, adesso 15:26 | nuovo stato **«mercato non misurabile»** (feed fermo, assente, o barra mancante) ⇒ `ambiguo` con la ragione; `twr` e `trading` None con motivo |
+| con `data/raw` assente (host ripristinato prima del rebuild) tutto era «ambiguo», `certi` 0, e il report stampava **+243% sotto l'etichetta TWR** | si' | stesso stato: n/d, mai il grezzo |
+| «`rendimento_twr` e' la funzione che entrambi chiamano» era **falso**: `pnl_giorno` rifaceva `cum − certi`, e la testata Telegram mandava il cumulato grezzo | si' | `pnl_giorno` chiama `rendimento_twr`; la pagina stampa il TWR accanto al cumulato; la testata dice «di cui versati → trading» |
+| `leva_tetto` del classificatore ridichiarava `frac × n` ignorando `book_scale_k` e `LEVA_LORDA_MAX` (P1) | si' | `min(frac × n × scala, LEVA_LORDA_MAX)`; fallback = tetto di codice |
+| il «limite ereditato: +10% di trading a mercato fermo» scritto la mattina era un **artefatto della fixture piatta** (a mercato misurato il trading non supera 2·max_mkt) | si' | cancellato ovunque; il limite vero e' quello sopra |
+| il bound di mercato guarda solo BTC/ETH, ma il 31% dell'equity e' USDE: un depeg pieno sarebbe un «prelievo» | si' | **non riparato**: l'indice USDE e' registrato una volta al giorno. Debito **§5.15** |
+| l'ora del report scritta in §2 (14:02Z) era l'ora di esecuzione, non quella della lettura (13:47:01Z); i tempi «scritto» dei diari erano posteriori ai commit | si' | corretti coi tempi veri |
+
+Il numero pubblicato: TWR +10,61% alla lettura delle 13:47Z; +10,56% alle 14:47Z.

docs/diary/2026-09-02b-debito-7-cadenza-docstring.md

@@ -0,0 +1,67 @@
+# 2026-09-02 — Debito 7: il docstring diceva 230 minuti, il cron gira ogni ora
+
+*Scritto il 2026-09-02 fra le 14:36Z e le 14:38Z (commit `861cc7f`, 14:38:53Z; la prima stesura diceva «alle 14:45Z» senza averlo letto — corretto in revisione). Cadenza misurata dal log (`r0823_sl_anchor.py`: 1.443 giri in
+1.442 ore) e dalla crontab installata, letta dal test.*
+
+## Il difetto
+
+| fonte | cosa diceva | dal |
+|---|---|---|
+| `scripts/live/book_execute.py`, docstring | «va lanciato ogni ~230 minuti» | 20/06 |
+| `scripts/cron_book.sh`, intestazione | cadenza ORARIA, `47 * * * *` | 25/08 (prima `:07`, sempre orario) |
+| crontab della VPS | `47 * * * *` | 25/08 |
+
+Era il **docstring** a sbagliare. E non era una svista innocua: sulla riga 4h (la più vicina ai 230
+minuti) BTC **raddoppia** gli scatti del disaster-SL rotolante (2 contro 1; a 24h ETH arriva a 5, con
+2 in 30 giorni). Il rischio era un lettore diligente che "allineasse" il cron al docstring.
+
+## La riparazione
+
+1. **Docstring riscritto**: `CADENZA: ORARIA`, la riga di crontab citata, la ragione (giro
+   idempotente → girare più fitto della griglia non costa ordini; latenza ≤1h sugli ingressi/uscite
+   software di SKH01; ri-ancoraggio orario del rotolante) e il divieto esplicito, con la data.
+2. **`tests/test_book_cadenza.py`, 10 test.** P1: non ridichiara «60 minuti», **deriva** le tre
+   fonti e le confronta fra loro:
+   - il docstring non contiene più «ogni ~230» e dichiara ORARIA;
+   - la riga di crontab citata nel docstring è quella dichiarata in `cron_book.sh`;
+   - la riga dichiarata è oraria (parser a 5 campi, solo casi regolari, rifiuta il resto),
+     sotto i 230 della griglia e lontana dai 240 della riga peggiore, e fuori dal minuto `:00`;
+   - **la crontab installata** (`crontab -l`) coincide con la dichiarata. Dove la crontab non è
+     leggibile il test è **saltato**, non verde (P5). Sulla VPS oggi gira e passa.
+
+## Numeri
+
+| | |
+|---|---|
+| test nuovi | 10, tutti verdi; suite dei moduli che toccano `book_execute`: 231 verdi |
+| cadenza dichiarata / installata | 60 min / 60 min |
+| griglia SKH01 | 230 min (la riga da non usare) |
+| riga peggiore misurata | 240 min (BTC 2 scatti contro 1) |
+
+## Cosa NON ho fatto
+
+- Non ho toccato il cron né `cron_book.sh`: la configurazione che gira era quella giusta.
+- Non ho aggiunto un sorvegliante a runtime sulla cadenza (contare i giri per ora nel log): il
+  giornale già stampa «giri mancanti» ogni giorno, e il test copre la deriva di configurazione.
+
+## Revisione del codice, prima tornata (15:15Z, commit `835e0c8`) — due cose trovate, tutte riparate
+
+| trovato | vero? | riparazione |
+|---|---|---|
+| il docstring nuovo diceva «il disaster-SL rotolante si ri-ancora ogni ora»: falso. `ensure_disaster_sl` lascia il bracket com'è finché lo stop voluto è entro il 5% da quello piazzato e la taglia entro il 10%; il giro orario **controlla**, ri-ancora oltre la tolleranza (mark +5,263% / −4,762%). I «BTC 0 / ETH 1» di `r0823` sono misurati **con** questa isteresi | sì, verificato in `execution.py:233-235`. Propagato anche a CLAUDE.md §5.7 e memoria 40 | riscritto in tutti e tre i posti: «controllato ogni ora, ri-ancorato solo oltre la tolleranza; lo stop siede fra −26,3% e −33,3% dal mark corrente». Frase sbagliata su un meccanismo di sicurezza vivo: era la segnalazione più importante |
+| la guardia del test cercava due letterali («ogni ~230»): «ogni quattro ore» sarebbe passato | sì | la guardia estrae **ogni** prescrizione «ogni/every N unità» e pretende 60 minuti; controllo positivo (M15) su cinque frasi. Limite dichiarato (P13): una prosa che prescrive senza «ogni» passa |
+
+## Seconda tornata (15:30Z)
+
+| trovato | vero? | riparazione |
+|---|---|---|
+| la frase nuova di CLAUDE.md §5.7 era **invertita** («chi lo avesse corretto nel verso del cron»): correggere il docstring verso il cron e' proprio la riparazione; il pericolo e' correggere il CRON verso il docstring | si' | riscritta nel verso giusto |
+| la banda dello stop era sbagliata: con isteresi 5% sullo stop (0,70·mark) lo stop siede a 0,665–0,735 × mark, cioe' **−33,5% / −26,5%**, non −26,3/−33,3 | si' | corretta in docstring, CLAUDE.md, memoria |
+| «BTC raddoppia gli scatti» leggeva male `r0823`: il «2 contro 1» e' rotolante contro pavimento **dentro la riga 4h**; a 1h il rotolante ne fa 0, e la riga peggiore misurata e' **24h** (ETH 5) | si' (la revisione ha eseguito `r0823.simula`) | riscritto ovunque coi conteggi; nel test `RIGA_4H_MIN`, non «peggiore»; `LTF_MIN` importato da `skyhook` (P1) |
+| «girare piu' fitto non costa ordini» era falso: 22 dei 48 ordini live sono ri-taglie |Δ|≤$10 a segnale invariato; il deadband e' in valuta assoluta (C2) | si' (contati) | riscritto: «costa solo micro-ordini di ri-taglia», con la regola C2 |
+| «latenza ≤1h» senza condizione: vale solo con la feed 5m fresca; `fresh_5m` ripiega in silenzio sul giornaliero e `skh_feed_max_age_min` allerta e basta | si' | condizione scritta |
+| `_cron_installato` leggeva la **prima** riga: una seconda riga attiva sotto (`17 * * * *`, dentro lo slot di release) era invisibile | si' (simulato) | si contano **tutte** le righe attive, e devono essere una |
+| lo skip collassava tre stati: crontab illeggibile, leggibile senza il progetto, leggibile col progetto ma senza `cron_book.sh` attivo (= libro non schedulato) | si' | tre stati: SALTATO, SALTATO, **ROSSO** |
+| solo il vincolo 1 del `:47` era testato (minuto ≠ 00); il vincolo 2 (fuori dallo slot di release del martedi') no | si' | test con `venue_probe.in_release_window`, il :07 come controllo positivo |
+| `_cron_dichiarato` accettava solo `N * * * *` e falliva come «assente» su `*/30`; `cadenza_minuti` accettava `*/45`, `0 */5`, `*/0` | si' | regex a 5 campi qualunque, regolarita' e passo > 0 imposti, parametrizzati |
+| `r0823_sl_anchor.py` si rifiutava di girare nella finestra del **vecchio** `:07` e stampava a runtime che il docstring «prescrive ~230 min»; `cron_chain.sh` giustificava il :25 «fuori dal :07» | si' | guardia sul :47, prosa al passato, commento aggiornato |

docs/diary/2026-09-02c-flag-e-pulizia.md

@@ -0,0 +1,103 @@
+# 2026-09-02 — Un flag sconosciuto non è l'azione di default
+
+*Scritto fra le 15:45Z e le 16:05Z. Il difetto è stato misurato, non ipotizzato: la revisione del
+codice di questa sessione ha eseguito `trades_db.py --help` come sonda di tempi e lo ha visto
+sincronizzare il DB.*
+
+## 1. Il difetto
+
+Nessuno dei 18 script di `scripts/live/` usava argparse. Leggevano gli argomenti così:
+
+```python
+if "--reconcile" in args: ...
+elif "--report" in args: ...
+else: sync()            # <- qui finiva QUALUNQUE cosa non riconosciuta
+```
+
+Un flag sbagliato non era un errore: era il ramo finale. Costo osservato e costi possibili:
+
+| script | `--help` faceva | gravità |
+|---|---|---|
+| `trades_db.py` | `sync()`: riscriveva `meta.ultimo_sync` | osservato oggi, danno nullo |
+| `journal.py` | scriveva la pagina di oggi e una riga nel DB | non osservato, ma scrive |
+| `analista.py` | spendeva una chiamata al modello e mandava un Telegram | non osservato, ma spende |
+
+## 2. La riparazione, e perché non è argparse
+
+`src/live/cli.valida(nome, uso, flag=..., con_valore=...)`, chiamata come **prima istruzione** di
+ogni blocco `__main__` — prima di `connect()`, prima del sync, prima della rete.
+
+- `--help` / `-h` → stampa l'uso, esce **0**;
+- flag non dichiarato, o valore mancante, o posizionale → stderr con **cosa** e **cosa si poteva**
+  (P4), esce **2** (errore d'uso, distinto dall'1 con cui gli script segnalano un esito negativo);
+- tutto il resto invariato.
+
+**Argparse no.** Cambierebbe messaggi d'errore, codici d'uscita e il comportamento di `--help` su
+18 script che il cron già invoca: romperebbe ciò che gira per riparare ciò che non gira mai. Qui
+serviva l'opposto — lasciare intatti i flag esistenti e rifiutare solo l'ignoto.
+
+## 3. Il test guarda entrambe le metà del contratto
+
+`tests/test_cli_flag.py`, 30 test:
+
+- **l'elenco degli script si deriva dalla cartella** (P1): uno script nuovo che legge `sys.argv` a
+  mano e non chiama `valida` fa fallire il test, non passa inosservato perché nessuno ha aggiornato
+  una lista;
+- `valida` dev'essere la **prima istruzione** di `__main__` (uscire dopo l'effetto non è uscire);
+- l'uso deve **nominare** i flag che lo script accetta;
+- **i flag che il cron usa davvero devono restare accettati** (P15/P16, letti dai `cron_*.sh`): una
+  guardia che ferma il libro di bordo la notte stessa sarebbe peggio del difetto;
+- end-to-end sui tre script che scrivono: `--help` esce 0 e **non tocca `trades.db`**; un flag
+  ignoto esce 2 e non lo tocca (M15: il caso che ha causato il difetto, non un caso vicino).
+
+Verificato a mano anche il contrario: `monitor_health.py --quiet`, `trades_db.py --sync --quiet`
+e `book_execute.py` in dry-run escono 0 come prima.
+
+## 4. Il resto della sessione
+
+**Indice USDE orario** (debito §5.15, primo passo). Il classificatore dei movimenti di capitale
+confronta due letture di equity a un'ora di distanza e il suo bound guarda solo BTC/ETH, mentre il
+31% dell'equity è USDE: un depeg sarebbe scorporato come un prelievo. `usde_watch` registra
+l'indice una volta al giorno — troppo rado. Ora `balance_watch` (orario, sola lettura) lo registra
+a ogni campione, `None` con la ragione se non leggibile, mai 1,0. Il cablaggio nel bound viene
+quando la serie ha storia: prima serve il dato, poi la regola.
+
+**Pulizia lasciata dalla revisione.** `tests/helpers.carica_script` sostituisce la dodicesima copia
+del caricatore `importlib` (15 in giro, con nomi di modulo diversi per lo stesso file e differenze
+silenziose su `sys.modules`); il fill di prova si scrive con `upsert_fills` invece che con un
+`INSERT` a mano che lasciava `verified` NULL, una forma che la produzione non produce; le
+asserzioni sul testo del report non sono più ancorate al padding; `movimenti_capitale` accetta le
+righe già lette, così il report non fa due SELECT sulla stessa tabella a un'ora del cron — due
+letture ai due lati di una scrittura descriverebbero due istanti diversi.
+
+## 5. Il README era fermo a quindici giorni prima del reset
+
+Chiesto un aggiornamento della documentazione, ho aperto il README e ho trovato un documento del
+**2026-06-04**. Il reset v2.0.0 è del **19 giugno**. Per 75 giorni la prima pagina del repository ha
+descritto la libreria pre-reset come se fosse il presente:
+
+| cosa diceva | stato vero |
+|---|---|
+| famiglie FADE / HONEST / PAIRS / TSMOM / SHAPE, strategie MR01…SH01 | archiviate in `Old/`, artefatto di feed contaminato |
+| PORT06: Sharpe **7,84 / 10,06**, DD 2,60%, CAGR ~79% | numeri che `CLAUDE.md` §2 elenca sotto «non citare» |
+| paper trader su `strategies.yml`, portafogli in `portfolios.yml` | **file inesistenti** |
+| `scripts/waste/`, `scripts/portfolios/`, `src/live/multi_runner.py` | **inesistenti** |
+| esecuzione shadow su Deribit **testnet** | il testnet è *la causa del reset*; oggi si esegue su mainnet con soldi veri |
+
+Riscritto contro lo stato vero: cosa gira adesso, i numeri nella lente di §2 (TWR +10,6%, non la
+crescita del conto), il metodo e i sei requisiti, la struttura verificata file per file, i gate con
+le loro date, l'obiettivo con la sua onestà. Ogni percorso citato è stato controllato: esiste.
+Da 423 righe a 152.
+
+**La lezione che ho registrato non è «aggiornare il README».** È che un reset invalida anche i
+documenti che nessuno rilegge, e l'inventario di cosa cita numeri morti va fatto il giorno del
+reset — non 75 giorni dopo, per caso, mentre si fa altro.
+
+## 6. Cosa NON ho fatto
+
+- I loader `importlib` dei test sulla **ricerca** (moduli in `scripts/research/`) restano come
+  sono: sono a livello di modulo, con radici diverse, e toccarli non ripara niente.
+- Il bound USDE nel classificatore: manca la storia, non il codice.
+
+- Non ho cercato altri documenti fermi al pre-reset fuori da `README.md` e `docs/`: l'inventario
+  completo (ogni file che cita un numero morto) resta da fare, ed è la vera coda di questa scoperta.

docs/diary/2026-09-06-usde-quota-topup.md

@@ -0,0 +1,91 @@
+# 2026-09-06 — USDE: dal 14,6% al 68,7%. Il tetto del venue del 30-31/08 non c'era piu'; il versamento di prova del 25/08 dichiarato
+
+**Ore:** 20:56-21:16Z. **Autorizzazioni dell'operatore, in sessione:** *«usa piu' USDE se ne hai bisogno»*,
+poi *«cerca % massima raggiungibile in USDE»*, sulla decisione gia' presa il 30/08 (quota bersaglio 70%,
+`usde.quota_target`). E, a meta' sessione: *«i 25 euro erano un versamento di prova»*.
+
+## 1. Il versamento del 04/09 aveva dimezzato la quota
+
+Il versamento di **$2.410,14 del 04/09 14:47Z** (riconosciuto dal classificatore: mercato max 0,56% a leva
+piena contro un salto del +116,8%) ha portato l'equity a **~$4.495** e la quota USDE da 31,3% a **14,6%**.
+Nessun automatismo la riportava su.
+
+## 2. Primo passo: al tetto di config (31,8%) — e la lettura SBAGLIATA che ne ho dato
+
+`usde_convert.py --quota 0.318 --esegui`: 774 USDE in 8 ordini @ 1,0005 medio, zero rifiuti, quota 31,79%.
+Ho scritto in CLAUDE.md «il tetto ha tenuto la stessa frazione a equity 2,2× maggiore: terza conferma».
+**Falso**: nessun rifiuto fino al 31,8% dimostra che il tetto e' **≥** 31,8%, non che e' **=** 31,8%. Il
+dato non conteneva la conferma; l'ho letta perche' me l'aspettavo. Corretto venti minuti dopo, quando
+l'operatore ha chiesto la % massima e la sonda ha mostrato che la conferma non c'era.
+
+## 3. La sonda: nessun tetto fino al 68,7%
+
+`scripts/research/r0906_usde_tetto_sonda.py` — a saldo crescente, passi piccoli, stesso metodo dei diari
+30-31/08 (un probe unico di taglia sbagliata produce un falso negativo): sale finche' il venue non rifiuta,
+ripete il rifiuto dopo aver riletto il book (il messaggio `not_enough_funds_in_currency` e' lo stesso di un
+limite che non incrocia), scende di passo a ogni doppio rifiuto, e conferma il muro a saldo neutro
+(SELL 1 → BUY 1 ok → BUY 1 rifiutato). Guardie: prezzo dal book (ask+5 tick, tetto 1,0010), quota mai oltre
+il 70% e **USDC mai sotto il cuscino di regolamento** derivato da config (`usde_convert.cuscino_richiesto_usd`).
+
+| corsa | passi | da → a (USDE) | quota | rifiuti |
+|---|---|---|---|---|
+| 21:02-21:09 | 30 × 2 | 1.428,7 → 1.488,7 | 31,8% → 33,1% | **0** (fermata dal mio limite +60) |
+| 21:11-21:15 | 16 × 100 | 1.488,7 → **3.088,7** | 33,1% → **68,7%** | **0** (fermata dal cuscino: +100 avrebbe superato il 70%) |
+
+**Totale del giorno: 2.434 USDE in 39 ordini @ 1,0005, ~$1,2 di spread.** Conto finale: USDC **$1.407,40** +
+USDE **3.088,72** = $4.496; cuscino richiesto $1.349 → slack **+$58**. Registro: `data/live/usde_convert.jsonl`
+(due record `sonda_tetto`, con ogni ordine).
+
+## 4. Cosa dice il risultato — e cosa non dice
+
+1. **Il tetto del 30-31/08 era vero allora ed e' sparito ora.** Tre bracket riproducibili a 1 USDE (31,21-31,26% ·
+   31,29-31,34% · 31,84-31,88%) contro 2.434 USDE accettati oggi senza un rifiuto. **Non e' scalato, e'
+   sparito**: la frase del 31/08 «il 70% non e' raggiungibile ne' ora ne' mai» e' falsificata.
+2. **Non spiegato** (D5). Ipotesi non verificabili da qui (il gateway non espone il transaction log ne' i
+   parametri del cap): un'allocazione per-conto del Cap ETHENA che varia col saldo aggregato dell'exchange;
+   un vincolo sui fondi depositati di recente (ma l'USDC del 04/09 e' stato convertibile a 2 giorni); un
+   cambio di policy. **Il tetto puo' tornare**: quando tornera', bloccherebbe gli ACQUISTI, mai le vendite
+   (tutte le SELL sono sempre passate). `venue_cap_frac` → **null** con la misura in `venue_cap_misurato`;
+   `usde_convert` si affida al chunk+backoff sui rifiuti, che e' cio' che ha sempre fatto.
+3. **Il limite che morde e' NOSTRO: il cuscino di regolamento.** P&L e funding dei perp si regolano in USDC;
+   a 68,7% restano $58 sopra il cuscino. ⚠️ **Nessuno sorveglia il cuscino**: `usde_watch` allerta sulla
+   quota (`quota_max_frac`, riportata a **0,85**, il valore che l'operatore aveva scelto il 30/08 «in previsione
+   della quota al 70%»), non sull'USDC. Una perdita del libro fa salire la quota da sola: a −$58 il cuscino e'
+   scoperto, e Deribit finanzia un saldo USDC negativo allo 0,05%/giorno (18%/anno). Debito nuovo, §5.17.
+4. **Rischio emittente**: a 24,2% l'evento Ethena valeva 3,1× il maxDD del libro (30/08); a 68,7% vale **~8,8×**.
+   E' la decisione del 30/08 presa con l'informazione completa (r0830_usde_quota), oggi eseguita. Resa attesa
+   ~4,1% × $3.089 ≈ **$127/anno** (era $26): ancora meno di un mese di versamento.
+
+## 5. Il versamento di prova del 25/08: dichiarato, scorporato, e il TWR scende di 4 punti
+
+Trovato stamattina per differenza (equity 07:07→08:07 **+$21,11** con le posizioni a **−$3,3/−4,3**) e
+confermato dall'operatore: **€25 di prova** prima del bonifico da $1.399,39 delle 11:47. Il rilevatore non
+poteva vederlo (+3,3% contro soglia 10%) e abbassare la soglia farebbe di ogni ora di mercato un candidato:
+**l'unica fonte che sa l'importo e' l'operatore**. Costruito il canale:
+
+- `data/live/movimenti_dichiarati.jsonl` (append-only, nel perimetro di backup — P11), letto da
+  `journal.movimenti_dichiarati()`; `movimenti_capitale` lo fonde coi rilevati: fonte `dichiarato`, importo
+  dell'operatore (non il salto), `dopo = prima + importo` cosi' il mercato dell'ora **resta** nel rendimento;
+  se coincide con un salto rilevato l'importo dichiarato vince (`dichiarato+rilevato`); fuori dalle letture →
+  `avvisi`, non applicato; riga rotta → `avvisi`, le altre restano (P3).
+- Importo registrato **$24,90 ± 0,50**: stimato per differenza (salto +21,11, mercato −3,3/−4,3 dal log del
+  book, fee 0,03) — il gateway non espone `get_deposits`, quindi il numero USDC esatto non e' leggibile; la
+  banda sta nel record e nel report (P12).
+- `tests/test_journal.py`: +6 (scorporo sotto soglia · dichiarato+rilevato · fuori letture · riga rotta ·
+  senza file niente cambia · la nota di giornale lo dice); `conftest` isola il file nei test.
+
+| | prima (20:47Z) | dopo (21:14Z) |
+|---|---|---|
+| movimenti certi | $3.809,53 | **$3.834,43** |
+| trading da arming | +$87,35 | **+$62,45** |
+| TWR | +11,98% | **+7,83%** = +8,14% × −0,62% × −0,12% × +0,46% |
+
+**Un terzo del «trading» era un bonifico da 25 euro.** Regola nuova (CLAUDE.md §2): ogni versamento, anche
+di prova, si dichiara nel file il giorno stesso.
+
+## 6. File toccati
+
+`config/live.json` (usde: venue_cap_frac null, quota_max_frac 0.85, nota) · `src/live/journal.py` ·
+`scripts/live/trades_db.py` · `tests/conftest.py` · `tests/test_journal.py` (+6) ·
+`scripts/research/r0906_usde_tetto_sonda.py` (nuovo) · `data/live/movimenti_dichiarati.jsonl` (nuovo) ·
+`CLAUDE.md` §1 §2 §4 §5.

docs/diary/2026-09-09-crolli-opzioni-monete.md

@@ -0,0 +1,219 @@
+# 2026-09-09 — Guadagnare nei crolli: revisione dei sistemi, il crollo catturato, piu' monete su Deribit
+
+**Richiesta dell'operatore:** *"fai analisi e revisione dei sistemi adottati e trova soluzione per
+guadagnare anche nei crolli (usa le opzioni se serve), anche + monete ma sempre in deribit"*.
+Analisi e revisione col modello `fable` (revisore fresco, agente separato), test con Opus.
+
+**Esito in una riga:** nel **giorno** del crollo il libro live **perde** (−0,48%/g, positivo nel 18%
+dei giorni ≤ −5%); per **finestra** e' immune-o-positivo e **dal 2022 chiude in utile 8/8 peggiori
+finestre**, tutte per la gamba SHORT di SKH01 marcata all'uscita; la sola leva che aumenterebbe quel
+guadagno e' il peso di SKH01, che il gate del progetto boccia su una condizione in-sample; le
+opzioni, misurate per la prima volta su un **crollo catturato a quote vere**, danno un rapporto di
+credito identico al rally (f_net 0,74 vs 0,714) — **non** il `f` di stress che la regola del 19/06
+aspettava (crollo a vol bassa, gate di VRP01 chiuso, famiglia inverse); XRP, l'unica "altra
+moneta" liquida e non misurata di Deribit, **diluisce** esattamente come SOL. **Libro, pesi,
+config, cron INVARIATI. Nessun ordine.**
+
+## 0. Prima di misurare: cosa era gia' morto (memoria letta, non riaperta)
+
+| meccanismo "guadagnare nei crolli" | esito | perche' e' morto (chi riapre deve battere questo) |
+|---|---|---|
+| gamba short del trend a 1d (§42) | SCARTATO | −1,91%/anno di drift in 0/24 ancore; il 2022 lo tiene a galla a meta' |
+| put deep-OTM statica (§46) | REFUTATO 0/162 | beta del libro +0,076: non si assicura un libro gia' piatto |
+| collar ≤15g (§71) · pavimento come licenza (§72) | REFUTATI | il DD lo riduce il TETTO (troncatura, C9); la put sola peggiora il DD 16/16 |
+| gamma scalping long-vol | SCARTATO | paga il VRP ogni anno, ogni frequenza |
+| DVOL direzionale · gate macro · skew de-risk | HEDGE / RIDONDANTI | TP01 e' gia' flat nei crolli (Δ 0,00) |
+| SOL terza gamba (22/08) | ESCLUSO dall'operatore | hold-out −0,166 in 0/24; un anno solo (2023) |
+| XS01 su Deribit (§50) | MORTO per ampiezza | 11 gambe con ≥1 anno: 1,265 → 0,116 |
+
+Condizione di riapertura scritta tre volte (§3 short-vol, §71, §72): **un `f` di stress reale su
+un crash catturato**. E' la cosa che oggi si poteva misurare e non era stata misurata.
+
+## 1. Il libro nei crolli — `r0909_libro_nei_crolli.py`
+
+Lente: sleeve di ricerca, ancora canonica, fee 0,10% RT, funding fuori; pesi importati da
+`src/live/book` (P1). ⚠️ **SKH01 e' marcato all'USCITA del trade** (`harness.backtest_signals`):
+la serie giornaliera e' zero nell'87,7% dei giorni, e uno short aperto nella finestra e chiuso
+fuori e' accreditato fuori — per questo la tabella per GIORNO mostra SKH01 ≈ 0 e quella per
+FINESTRA il guadagno. Indice 50/50 BTC/ETH; giorno di crollo ≤ −5%; episodio = 12 peggiori
+finestre di 20 giorni non sovrapposte + 9 episodi nominati prima. Classi ESCLUSIVE nell'ordine
+dichiarato: immune (|libro| < |idx|/10, col segno) → POSITIVO → PERDE.
+
+| misura | valore |
+|---|---|
+| beta del libro all'indice | **+0,0769 sulla finestra di §46** (2021-03-24+; memoria +0,076: riprodotto al millesimo) · +0,086 su tutta la storia · +0,002 nei giorni ≤ −3% |
+| 160 giorni ≤ −5% (indice −7,76%/g) | libro **−0,48%/g**: TP01 −0,63, SKH01 +0,15; **libro > 0 nel 18%** dei giorni; somme per anno: 2024 −11,9%, 2025 −7,3%, 2022 +8,2%, 2026 +4,7% |
+| 24 giorni ≤ −10% (indice −14,4%/g) | libro −0,51%/g: TP01 −0,93, SKH01 **+0,42** |
+| 12 peggiori finestre 20g | **4 POSITIVO / 6 immune (4 col segno +) / 2 PERDE**; libro > 0 in 8/12; **dal 2022 in 8/8** (mediana +3,3% contro indice −29%); le 2 perdite sono 2019 e maggio 2021 (TP01 ancora long: il trend non si era girato) |
+| 9 episodi nominati | libro > 0 in LUNA (+4,3%), giugno 2022 (+3,1%), FTX (+0,7%), agosto 2024 (+0,4%), 5/02/2026 (+4,4%), 1-5/06/2026 (+3,3%); COVID −0,04%, feb 2025 −1,5%, maggio 2021 −3,4% |
+| da dove viene il guadagno | la gamba **SHORT di SKH01 = 108%** dei guadagni negli episodi con libro > 0 (scomposizione ESATTA: long + short == intera su 2735/2735 giorni, verificato con assert; TP01 contribuisce in negativo); per anno al peso 0,25: 2022 **+10,7%**, 2026 **+7,7%** |
+| peggior giorno del libro (lente canonica) | 2025-10-10 −3,38%, tutto TP01 con esposizione **0,505**, indice −9,7%: **e' un giorno di crollo con TP01 mezzo long** (lo squeeze di §33 sta sulla lente hourly e qui non si riproduce: dichiarato nel docstring) |
+| riga informativa 37,5/62,5 (§26) | batte il 75/25 in 12/12 episodi, **ma** Sharpe 1,81 vs 1,82 e maxDD 12,1% vs 9,4%: paga i crolli con gli squeeze |
+
+🚨 **Errore catturato in revisione (fable):** la prima stesura provava "GUADAGNA" prima di
+"immune" e stampava **8/12 GUADAGNA**; con le classi nell'ordine dichiarato sono **4 POSITIVO +
+6 immune**. *L'ordine delle regole era il verdetto.* Ora il verdetto e' tre affermazioni separate
+(giorno / finestra / provenienza) e il conteggio nudo libro > 0 e' stampato accanto.
+
+📌 **Il meccanismo "guadagnare nei crolli" esiste ed e' in produzione: e' SKH01 short** — ma
+guadagna **dopo** il giorno del crollo (marcato all'uscita), non dentro. Nel senso stretto della
+domanda dell'operatore il libro **perde nel giorno** e recupera nella finestra. Le due perdite
+storiche per finestra sono di TP01 nei crolli che arrivano *dentro* un trend rialzista (2019,
+2021): e' il costo del long-flat (§42 ha misurato che la short del trend lo aggrava).
+
+**La leva che aumenterebbe il guadagno e' il peso di SKH01, e il gate la boccia:**
+`r0726_reeval_live_weight.py` rilanciato: argmax 0,35, plateau [0,25-0,50] (il live e' dentro),
+`weights_tilt_null` 0,25→0,35: `delta_insample −0,0026`, `pctl_hold 31,2`, **`gate_pass False`**.
+⚠️ Precisazione della revisione: lo script legge la cache `data/_cache/skh_sigtab/*` **ferma al
+2026-07-25** — sono le stesse cifre del diario 26/07, non un ri-esame coi segnali di oggi. La
+condizione che fallisce e' pero' **in-sample (pre-2025)**, che 46 giorni di dati nuovi non possono
+cambiare: la decisione 75/25 resta vincolante e la sua condizione di riapertura resta non
+soddisfatta, ma la data da citare e' il 26/07.
+
+## 2. Il crollo catturato — `r0909_crash_catturato.py`
+
+**Fatto nuovo:** `bite_archive.parquet` copre con bid E ask il crollo del **1-5 giugno 2026**
+(BTC −25% / ETH −30% dal 31/05 al minimo; ETH −11,1% il 05/06) su una scadenza (19/06, 14-21
+DTE). Il campione del 22/08 (§11) partiva **dopo**, dal fondo. Limiti dichiarati prima: n = 1
+crollo, 1 scadenza, tenor 14-21 g (VRP01 e' a 7), spot dal feed 1h certificato, regolamento allo
+spot dell'ora di scadenza, **famiglia INVERSE** (premi in ETH: VRP01 opererebbe sulla USDC-lineare,
+che il conto margina e che NON e' nell'archivio). Ancora d'ingresso = ogni snapshot 30/05-04/06;
+mediana e banda.
+
+⚠️ **Non e' un crollo a vol alta:** DVOL pre 37 (BTC) / 49 (ETH) all'IV-rank 0,05 / 0,10; il
+**picco** del crollo (49 / 69) sta al **29° / 46° percentile storico** — sotto la mediana. Il gate
+IV-rank ≥ 0,30 di VRP01 e' **chiuso in tutte le ore** e il modello del sleeve segna 0,0 su tutte le
+settimane di giugno: VRP01 non sarebbe stato a mercato.
+
+| ETH, ingressi PRE-crollo (286 snapshot = **4 strutture** di strike, δ −0,27/−0,09, larghezza 200) | reale | modello (BS su DVOL) | f |
+|---|---|---|---|
+| credito del put credit spread | | | **0,74** [0,65-0,82] — 22/08 in rally: 0,714 |
+| P&L a scadenza per unita' | **−$174** | −$168 | 1,04 — **tautologico nell'83%** dei trade: entrambe le gambe ITM ⇒ payoff = larghezza per reale e modello, resta solo f_net |
+| perdita sul rischio (fee incluse) | 101% [65-102] | | = perdita **MASSIMA** dello spread (+ fee); 65% per la 1900/1600 |
+| peggior MTM, chiusura **tagliata alla larghezza** | **−$172** | −$161 | **1,08** [1,07-1,31]; a quell'ora IV corta 68 = DVOL 68 |
+| put δ−0,10 comprata all'ask: costo | | | **1,92×** il modello (§46 a δ−0,10 su BTC_USDC: 1,27 — punto NUOVO e piu' alto, ETH inverse) |
+| put δ−0,10 a scadenza (ITM di $4: K 1700, ST 1694) | −$6 | ≈ $0 | 0,96 sul solo sottoinsieme con payoff modellato ≥ $5 |
+| put δ−0,10 al picco del percorso (look-ahead, limite sup.) | +$163 | +$173 | 0,94 |
+| debit spread −0,28/−0,10 a scadenza | +$169 | +$163 | 1,04 (stessa tautologia, specchio) |
+| ingressi DURANTE il crollo (02-04/06, 283 snapshot) | mediana +$5, **perde nel 46%**, p10 −$133 / p90 +$26 | | bimodale: la mediana nasconde le perdite |
+
+BTC: **non misurabile pre-crollo** — la griglia di strike dell'archivio il 30/05-01/06 non
+contiene la δ−0,10 (78 snapshot fuori geometria, 0 in geometria prima del 02/06). Durante:
+247 snapshot, f_net 0,79, perde nel 37% (p10 −$1.718 / p90 +$818 su larghezza 5000).
+
+🚨 **Tre correzioni della revisione, applicate:**
+1. *"Il percorso costa 2,6× il modello (f_mtm 2,58), la IV della gamba corta e' esplosa a 108 per lo
+   skew"* — **artefatto di quote.** Il costo di chiusura `(ask corta − bid lunga)` superava la
+   **larghezza** dello spread (una quota 0,208/0,376 ETH su un intrinseco di $296: 158% di spread
+   relativo, a T→0) e `min()` pescava li'; uno spread a rischio definito non costa mai piu' della
+   larghezza per chiudere. Tagliato: **f_mtm 1,08**. E la IV 108 e' del **18/06 alle 17:00** (deep
+   ITM, T→0), non del crollo: all'ora del peggior MTM la IV e' 68 = DVOL.
+2. *"f a scadenza 1,04: il modello prezza bene la perdita"* — **tautologia**: con entrambe le gambe
+   ITM il payoff e' la larghezza per entrambi; f_exp e' una funzione di f_net. E la "banda su 286
+   snapshot" sono 4 strutture (N_eff = 1 crollo × 4).
+3. `S.asof(ts)` sul feed 1h **guardava un'ora avanti**: la barra e' etichettata all'apertura (la
+   20:00 chiude col 5m delle 20:55). Corretto con `spot_causale` (indice +1h). ⚠️ **`cblib.spot_series`
+   ha lo stesso difetto** → il f 0,714 di §11 e ogni numero di `cblib` con `asof` sullo spot; qui
+   innocuo (ambo le gambe ITM per ogni ST < 1700) e nel MTM giocava contro l'autore. **Debito nuovo,
+   registrato in CLAUDE.md §5.** Non toccato: cambierebbe numeri pubblicati.
+
+📌 **Cosa dice davvero il crollo catturato (n = 1):** il **rapporto di credito reale/modello non
+cambia col regime** (0,74 nel crollo contro 0,714 nel rally); la put comprata paga nel crollo
+cio' che il modello dice (0,94-1,04) ma **costa 1,9× il modello all'ingresso** — il bleed e' dove
+il modello sbaglia, il payoff no (e' il motivo di §46/§72 visto dal lato del sinistro); il gate di
+VRP01 lo ha tenuto fuori. **La condizione di riapertura di §3 e' soddisfatta nella forma** (un
+archivio bite con bid/ask su un crollo) **e non nella sostanza**: crollo a vol bassa, sotto il gate,
+tenor 14-21, famiglia inverse, e l'unico f non tautologico (MTM) vale 1,08 su 4 strutture. **Non si
+riapre.** Primo punto di una distribuzione che `collect_chain` riempira' da solo; il secondo punto
+utile e' un crollo **con IV-rank > 0,30**.
+
+## 3. Piu' monete, sempre in Deribit — `r0909_deribit_universo.py` · `r0909_xrp_terza_gamba.py`
+
+**Il venue letto oggi (15:05Z):** 32 perpetual USDC-lineari aperti (+6 non aperti, fra cui **APT
+inactive**: e' il mancante rispetto al 23/08). Volume 24h ≥ $10M solo per **XRP ($38M, il piu'
+scambiato del venue, spread 4 bps, listato 2022-03-16), ETH, BTC, SOL ($13M)**; tutto il resto fra
+$0,01M e $7M (TAO, HYPE, ADA, AVAX, NEAR…) con spread 2-20 bps. XS01: **13/19** gambe — mancano
+ARB, OP, APT, INJ, TIA, SEI → §50 resta: morto per ampiezza. Opzioni USDC-lineari su 7 sottostanti
+(SOL 676, HYPE 442, XRP 442, TRX, AVAX) con la liquidita' misurata il 22/08 (SOL: 9% delle put a
+due lati). Trovati dalla revisione, registrati perche' il controllo costa €0 e nessuno li riapra:
+**`BTCDVOL_USDC-30SEP26`** (l'unico strumento long-vol diretto del venue: volume 0, OI 132, bid/ask
+39,1/43,9 = spread 12% → non negoziabile, e in contango sanguina come la put) e **PAXG perpetual**
+(oro, dal 2024-12: $0,18M/g, OI $8,3M — non misurato, non morto, stessi muri di SOL/XRP: 9 mesi di
+storia contro i 3 anni della decisione 22/08).
+
+⇒ **L'unica "altra moneta" liquida su Deribit mai misurata come gamba direzionale e' XRP.** Misurata
+col harness di `r0822_sol_leg` (TP01 e SKH01 **congelati**, 24 ancore, differenze appaiate,
+de-levering, per anno), ipotesi a priori dichiarata: diluisce.
+
+Certificazione (Coinbase dal rilisting 2023-07, Bitstamp prima — Coinbase aveva delistato XRP per
+la causa SEC): >1% dal riferimento 0,06% (2022) · **0,57% (2023)** · 0,01-0,02% (2024+); mediana
+5-6 bps. ⇒ **L-PULITA dal 2024** (stessa soglia e stesso anno sporco di SOL). ⚠️ Barre 5m flat
+**27-61%** (BTC/ETH 2021+: 0,1-2%; SOL 21%): il 5m su cui gira SKH01 e' 20-100× piu' flat.
+
+| | L-FULL (2022-03+) | L-PULITA (2024+) |
+|---|---|---|
+| dSharpe FULL (mediana, 24 ancore) | **−0,206** [−0,26, −0,16], >0 in 0% | −0,066, >0 in 12% |
+| dSharpe hold-out | **−0,169** [−0,32, −0,15], **>0 in 0%** | −0,169, 0% |
+| dCAGR | −2,27 pp, 0% | −1,32 pp, 4% |
+| null del de-levering | Sh 3g 1,23 vs 2g×0,974 **1,44** → de-levering | 1,54 vs 1,53 → pari |
+| per anno (dSh) | 2022 −0,55 · 2023 −0,66 · **2024 +0,54** · 2025 −0,44 · 2026 −0,25 → **1/5** | |
+| corr(gamba XRP, book) | +0,35 / +0,37 (SOL 0,40-0,56) | |
+
+**XRP DILUISCE** — lo stesso −0,17 di hold-out di SOL, in 0/24 ancore, con **un anno buono** (2024).
+TP01 XRP da solo: Sharpe −0,01, hold-out −0,49; SKH01 XRP maxDD 40,1% (il criterio di selezione di
+SKH01-V2-DD, maxDD<30%, fallisce anche qui, come SOL). Eseguibilita' non e' il vincolo (min 1 XRP =
+$1,42). Non misurato: **SKH01 solo-short su una terza moneta** (la domanda riguarda i crolli, dove
+paga lo short) — ma il filtro di direzione e' una famiglia nuova (M20) e il 5m di XRP e' peggio di
+SOL: il muro e' lo stesso. **Nessuna proposta.** Il dato vive in `data/raw/alt_xrp_*` (namespace di
+ricerca, non rinfrescato dal cron, `load_data("XRP")` fallisce; `tests/test_sol_leg.py` lo presidia
+via `DERIBIT_INSTR`). La cache del riferimento in `data/_cache` e' gitignored e fuori backup: la
+certificazione si riproduce **con rete** (N11 vale con rete).
+
+## 4. Cosa cambia una decisione — niente; cosa si registra
+
+| voce | prima | oggi |
+|---|---|---|
+| il libro nei crolli | "immune, beta 0,076" | perde nel GIORNO (−0,48%/g, 18% positivi), immune-o-positivo per finestra, **> 0 in 8/8 dal 2022** per SKH01 short marcato all'uscita; beta 0,0769 riprodotto |
+| f di stress delle opzioni | non misurato ("serve un crash catturato") | crollo catturato **a vol bassa, sotto il gate, inverse**: f_net 0,74 = rally; f_mtm 1,08; ali 1,92×. **Condizione non soddisfatta nella sostanza** |
+| peso SKH01 | gate fallisce (26/07) | invariato: la condizione che fallisce e' in-sample; cache segnali ferma al 25/07 |
+| XRP | mai misurato | diluisce come SOL (−0,169 hold-out, 0/24) |
+| universo Deribit | 14/19 (23/08) | 13/19 (APT inactive); liquidi solo BTC/ETH/XRP/SOL; BTCDVOL future non negoziabile; PAXG non misurato |
+| debito nuovo | — | `cblib.spot_series` + `asof` guarda un'ora avanti (feed 1h etichettato all'apertura) |
+
+**Cosa riaprirebbe qualcosa:** (a) un secondo crollo catturato **a IV-rank > 0,30** (VRP01 a
+mercato), sulla famiglia USDC-lineare, per il f di stress; (b) `weights_tilt_null` che passa — si
+rigenera `skh_sigtab` e si rilancia `r0726_reeval_live_weight`, non si ridiscute; (c) per le
+"altre monete", un meccanismo che non sia TP01/SKH01 congelati, o 3 anni di dato 5m liquido.
+
+## 5. Errori catturati in sessione (prima della revisione)
+
+- Percorso ora per ora in un ciclo `groupby` per ancora: >10 minuti; riscritto su una tabella
+  ora×strumento (`Quote`), ~3 minuti.
+- BTC "in geometria" senza guardia: la griglia rada faceva scegliere a `pick_legs` una δ−0,02 al
+  posto della δ−0,10 (K72000/55000). Guardia `TOL_D` (±0,08/±0,06), scritta dopo aver visto BTC ma
+  che per ETH scarta 2/288 e non cambia nessun verdetto (verificato dal revisore).
+- Coinbase restituiva un batch vuoto per XRP 2022 e il ciclo si fermava: certificazione vuota.
+  Riscritto con avanzamento su batch vuoto e riferimento Bitstamp dove Coinbase manca.
+
+## 6. Revisione (`fable`, agente fresco) — 21 segnalazioni, tutte verificate
+
+Applicate: #1 artefatto del MTM (taglio alla larghezza; IV 108 e' a T→0) · #2 f_exp tautologico
+(quota stampata, N_eff = strutture) · #3 "101%" = perdita massima + fee · #4 `asof` un'ora avanti
+(`spot_causale`; debito su `cblib`) · #5 famiglia inverse dichiarata · #8 "durante" bimodale (p10/p90,
+quota che perde) · #9 ordine delle classi (immune → POSITIVO → PERDE, tre affermazioni nel verdetto)
+· #10 peggior giorno = crollo con TP01 0,505, docstring (c) corretto · #11 beta sulla finestra di §46
+(0,0769, tolleranza 0,01) · #12 scomposizione esatta con assert · #13 lente "marcata all'uscita"
+dichiarata · #14 confronto bit-exact con `_skyhook_returns` · #15 cache `skh_sigtab` ferma al 25/07
+· #16 1,92 e' un punto nuovo, non "gia' noto" · #17 il crollo e' sotto la mediana del DVOL: verdetto
+riscritto · #18-19 BTCDVOL future e PAXG registrati · #21 APT inactive, cache con rete.
+Non applicate: nessuna. Il revisore ha trovato **due conclusioni che non reggevano** (il 2,6× e
+l'"8/12 guadagna") e le ha smontate con numeri riprodotti: la regola *"chi rivede non e' chi ha
+scritto"* ha pagato in una sessione.
+
+**Test (Opus, agente separato): `tests/test_r0909_*.py`, 92 test, suite intera 1008/1008 verdi**
+(erano 916). Coprono: ordine delle classi e riproduzione verbatim dei verdetti, `spot_causale` col
+controllo positivo sul difetto che ripara, taglio alla larghezza, geometria `in_geom` derivata da
+`VRP_CFG`, regola L-PULITA (anno pulito isolato ignorato), `_fetch_1h` su batch vuoti, P1 per
+identita' (`W_TP01`, `XS_UNIVERSE`), zero rete e zero scritture in `data/`. **Due difetti trovati da
+Opus nel verdetto di XRP, corretti:** un campione vuoto stampava "DILUISCE" (ora "NON MISURABILE",
+P5) e il criterio per anno era cablato al 2024 invece che derivato dall'anno della lente (P1).

docs/diary/2026-09-09b-debito-18-cblib-causale.md

@@ -0,0 +1,182 @@
+# 2026-09-09b — Debito §5.18 riparato: `cblib` causale (spot +1h, DVOL +1 giorno) e §11 rimisurato
+
+**Richiesta dell'operatore:** *"ripara il debito §5.18 su cblib e rimisura §11"*. Revisione col modello
+`fable` (agente fresco), come da regola.
+
+**Esito in una riga:** riparato in `cblib` — spot e DVOL escono **gia' causali** — e §11 rimisurato allo
+stesso taglio: **0,714 [0,690-0,779] → 0,712 [0,664-0,732]** (n=19). Il numero non si muove perche' le due
+correzioni hanno **segno opposto**; **nessun verdetto cambia**; riparando la prima serie ne e' uscita una
+**seconda con lo stesso difetto** (il DVOL giornaliero, fino a 24 ore avanti); il DVOL orario resta un
+passo aperto **con costo misurato**. Libro, config, cron: invariati. Nessun ordine.
+
+## 0. Il difetto, verificato prima di ripararlo (D6: si controlla col lag, non si assume)
+
+| serie | come e' etichettata | prova | look-ahead di `asof(ts)` |
+|---|---|---|---|
+| feed 1h certificato | all'**apertura**: la barra T contiene la chiusura di T+1h | chiusura 1h a T == chiusura 5m a **T+55** nel **100%** delle barre (BTC ed ETH, 1-5/06); a T−5 nell'1,7% / 0% | **+1 ora** |
+| `dvol_{asset}.parquet` (giornaliero, `fetch_dvol`, `resolution=86400`) | al giorno D contiene la **chiusura delle 23:00 di D** | API pubblica a risoluzione 1h, 1-4/06: `close` 1D del giorno D == `close` 1h delle 23:00 di D, e `open` 1D di D+1 == `close` di D | **fino a +24 ore** |
+
+La seconda riga non era nel debito: e' uscita controllando la convenzione dell'altra serie di
+contesto che `cblib` legge con lo stesso `asof`. Il sleeve (`_vrp_weekly_asset`) **non ha il difetto**:
+lavora a cadenza giornaliera e accosta la chiusura del giorno D al DVOL del giorno D, che a quella
+cadenza e' coerente. Il difetto e' solo di chi entra **a un'ora** con una serie giornaliera.
+
+## 1. La riparazione
+
+`cblib.causale(s, cadenza)` sposta le **etichette** (mai i valori) dall'apertura all'istante in cui la
+chiusura e' nota. `spot_series` → `causale(·, "1h")`, `dvol_series` → `causale(·, "1D")`. Conseguenze:
+
+- `asof(ts)` = ultima chiusura **conosciuta** a ts (prima della prima chiusura nota: NaN, non un valore).
+- il regolamento `ST = S.asof(exp)` alle 08:00 e' ora la chiusura della barra 07:00, cioe' **il prezzo
+  delle 08:00** — prima era la chiusura della barra 08:00, cioe' il prezzo delle **09:00**, un'ora dopo la
+  scadenza. Deribit regola su una TWAP dei 30 minuti prima delle 08:00: l'approssimazione e' ora dalla
+  parte giusta dell'ora.
+- `r0909_crash_catturato` **non ri-sposta** (lo `spot_causale` locale della mattina e' rimosso: applicato
+  due volte darebbe la chiusura di **due** ore prima — lo stesso errore col segno opposto). Test di
+  non-regressione sul sorgente.
+- chi usa `cblib`: `r0822_vrp_real_quotes` (§11), `r0822_skew` (§5), `r0909` (§75), **`vrp_f_watch`**
+  (cron giornaliero, `data/vrp_f_watch/state.json`), e — trovati dal revisore, non da me —
+  **`r0730_vrp_real_quotes`** (il f 0,73 [0,706-0,805] di CLAUDE.md §2: rigirato stampa **0,71
+  [0,680-0,756]**, n=27, 0/27 ≥ 1, f gamba lunga 1,66 → 1,49; verdetto invariato, numero dichiarato in §2)
+  e **`r0901_btc_collar`** (join del DVOL **per giorno**: con la serie causale avrebbe accostato l'IV di D
+  al DVOL di D−1 — riallineato con `causale(·, "-1D")`, bit-exact a prima, §71 non si muove).
+  `options_vrp_calibrate.py` ha una **copia propria** di `spot_series` (numeri del 20/06): **non toccato**,
+  dichiarato.
+- la sezione di REGIME di `r0822` (date di calendario: «ultimo giorno aperto», IV-rank per anno) e la
+  tabella di contesto di `r0909` usano `causale(V, "-1D")`: li' serve il DVOL **del** giorno, non
+  l'etichetta causale — altrimenti ogni data stampata slitta di un giorno (trovato dal revisore).
+- `r0822_vrp_real_quotes` ha ora il flag `--al <data>` (taglio delle scadenze) per riprodurre una misura
+  a una data: senza, "riprodurre il 22/08" era impossibile perche' la catena cresce ogni ora.
+
+## 2. Prima di pubblicare il numero nuovo, la macchina ha riprodotto quello vecchio (M23)
+
+Worktree di HEAD (`git worktree add`, `data/raw` in symlink), stesso script con `--al 2026-08-22`:
+**pooled 0,714 (IC95 [0,690, 0,779], n=19)** — al millesimo, IC compreso. Poi lo stesso comando sul
+codice riparato.
+
+## 3. Scomposizione: due correzioni di segno opposto (M26) e un controllo orario
+
+| taglio | spot | DVOL | pooled f | IC95 | n |
+|---|---|---|---|---|---|
+| 22/08 | grezzo | grezzo (com'era) | **0,714** | [0,690, 0,779] | 19 |
+| 22/08 | causale | grezzo | 0,721 | [0,685, 0,758] | 19 |
+| 22/08 | grezzo | causale (giornaliero) | 0,693 | [0,670, 0,748] | 19 |
+| 22/08 | causale | causale (giornaliero) = **`cblib` oggi** | **0,712** | [0,664, 0,732] | 19 |
+| 22/08 | causale | causale **orario** (controllo, API pubblica) | 0,717 | [0,667, 0,732] | 19 |
+| 09/09 | grezzo | grezzo | 0,720 | [0,717, 0,952] | 23 |
+| 09/09 | causale | causale (giornaliero) | **0,712** | [0,677, 0,741] | 23 |
+| 09/09 | causale | causale orario | 0,726 | [0,680, 0,738] | 23 |
+
+Il DVOL di fine giornata **alzava** f: nel rally la vol scende dentro il giorno, la chiusura di D sta
+**sotto** quella di D−1 (+1,05 pt di vol mediana su 19/19 trade, misura del revisore) → denominatore piu'
+basso → f piu' alto; causale: −0,021. Lo spot di un'ora dopo, invece, **non e' un meccanismo ma rumore**:
+lo scarto per trade ha segno misto (mediana −0,02% BTC / −0,11% ETH, banda −0,6…+0,9%) e sposta f fino a
+**±0,15 per trade** (lo spread δ−0,28/−0,10 ha delta netto ~0,18: 0,5% di spot vale 15-20% del credito
+modellato); il +0,007 netto e' la somma di 19 segni. ⚠️ Corollario: lo spot causale resta **stantio fino
+a 25 minuti** (snapshot al :25, chiusura nota al :00), cioe' ±0,05-0,10 di f per osservazione; il feed
+**5m certificato** lo porterebbe a ≤5 minuti. Non fatto: dichiarato in §6. Il DVOL giornaliero causale e' **stantio fino a
+23 ore** (agli ingressi delle 08:00: 8 ore): scarto mediano dall'orario **0,2 punti di vol**, max 1,1
+(22/08) / 3,0 (oggi). Su §11 vale 0,005 di f.
+
+## 4. Cosa cambia in §11 (taglio 22/08, stesso campione)
+
+| grandezza | prima | dopo | perche' |
+|---|---|---|---|
+| f pooled | 0,714 [0,690-0,779] | **0,712 [0,664-0,732]** | §3 |
+| f BTC / ETH | 0,706 / 0,715 | 0,720 / 0,692 | |
+| Sharpe canonico BTC (titolo, non citabile) | 32,58 | 29,61 | regolamento alle 08:00 |
+| **mediana onesta** BTC (9 ancore) | 1,45 | **2,12** | banda [−0,19, 29,61] (era [−0,35, 32,58]) |
+| Sharpe canonico ETH → mediana onesta | 3,90 → 2,41 | 7,64 → 3,35 | una settimana ETH cambia taglia: 26/06 −27,38 → −12,84 $ (BTC: 31/07 19,88 → 31,69, 14/08 12,94 → 8,68) |
+| media BTC fra le ancore | −1,35% → +11,22% | −0,66% → +11,44% | **cambia ancora segno**; sd 11,1× → 9,2× |
+| forfait fee vs listino | 1,44× / 1,80× | 1,51× / 1,87× | credito modellato a DVOL causale |
+| peggior mark: mediana / minimo / minimo fra le vincenti | −6,4% / −91,0% / −56,9% | −6,4% / −91,5% / −55,2% | |
+| P&L somma 19 settimane | $2.733 | $2.822 (+3,3%) | tutto dal regolamento |
+| sottostante nel campione | +25,1% / +44,2% | +21,1% / +40,1% | il vecchio regolamento del 21/08 era il prezzo delle **09:00**, che sta **+3,9%** sopra quello delle 08:00 (76.311 → 79.316): un numero a due estremi pesa un'ora intera. (La prima stesura diceva «−1,8%»: avevo letto l'ora dopo, 09:00 → 10:00. Corretto dal revisore) |
+
+**Verdetto di §11: SCARTATO, per le stesse quattro ragioni** (il campione non contiene la strategia; il
+titolo non sopravvive all'ora d'ingresso; la famiglia con storia non e' quella eseguibile; lo spread e'
+il costo dominante). Nessuna delle quattro dipende da un'ora di spot. Il testo del verdetto nello script
+riporta i numeri nuovi con i vecchi accanto.
+
+## 5. Effetti collaterali, misurati (tutto cio' che legge `cblib`)
+
+**§75, crollo catturato** (`r0909`, rigirato): ETH pre-crollo f_net **0,74 [0,65-0,82] → 0,76
+[0,71-0,86]**; peggior MTM 1,08 [1,07-1,31] → 1,08 [1,06-1,27]; put δ−0,10 1,92× → 1,98×; al picco 0,94 →
+0,99; BTC durante **0,79 → 0,89 [0,74-1,05]**, ETH durante 0,71 → 0,78. Con il DVOL **orario** BTC durante fa **0,83**: nel crollo
+il DVOL sale di 5-6 punti al giorno, quindi il giornaliero di fine giornata (com'era) sottostima f e
+quello del giorno prima (causale) lo sovrastima — **−0,04/+0,06 di f e' il prezzo della stantiezza in un
+crollo**, ed e' l'argomento per il feed orario. DVOL "pre" 37,3 → **36,4** (BTC): il 37,3 era la chiusura
+del **primo giorno di crollo** (01/06, −3,5%), non del giorno prima — IV-rank pre 0,05 → 0,03. Picco e
+percentili **invariati** (49,1 / 69,2; 29° / 46°) dopo aver corretto la tabella di contesto (§7).
+Verdetto invariato.
+
+**§5, skew** (`r0822_skew`, rigirato, 66 s): la scomposizione sul panel si muove di **≤0,005** per fattore
+(term 0,880 · skew 0,917 · spread 0,910 · fit 0,995 · f_tot 0,729); Q1/Q2 (lag prezzo/skew) **non si
+toccano** (serie proprie ancorate a `ts_max`). Agli ingressi il controllo `f_markfit` passa da 1,045 a
+**0,991** e le osservazioni che lo superano da 22/28 a **25/28**: l'ora di spot in piu' stava **nel
+controllo**, non nell'effetto — riparare ha reso il controllo piu' pulito, non il risultato diverso.
+
+**`vrp_f_watch`** (sorvegliante in `cron_daily`, criteri pre-registrati il 30/07 e **non toccati**):
+
+| | prima (state.json del 09/09 mattina) | dopo |
+|---|---|---|
+| coppie | 28 | 28 |
+| f canonico | 0,732 [0,702-0,784] | **0,706 [0,678-0,745]** |
+| f candidato | 0,803 [0,741-0,842] | 0,805 [0,771-0,840] |
+| differenza | +0,054 [−0,027, +0,105], 18/28 > 0 | **+0,097 [+0,042, +0,140]**, 21/28 > 0 |
+| ampiezza IC95 (b ≤ 0,12) | 0,131 — no | **0,098 — OK** |
+| coppie (a ≥ 40) | no | no |
+| `ready` | False | False |
+
+Lo `state.json` e' stato **riscritto** dal mio lancio (21:14Z, senza `--quiet`; nessun Telegram: notifica
+solo a `ready`); il «prima» completo e' la colonna qui sopra (n_positive 18, `esclude_zero` False), e il
+cron lo rigenera domani. La differenza ora **esclude lo zero**. Non decide niente: (a) non e' soddisfatto e il candidato resta
+bocciato sul deflated-Sharpe, che non dipende da f. Si registra perche' fra un mese qualcuno leggera'
+"esclude lo zero" e deve sapere da quando e perche'.
+
+## 6. Cosa resta aperto, col suo costo
+
+| voce | costo di non farlo | costo di farlo |
+|---|---|---|
+| **DVOL orario** nel feed (`fetch_dvol --res 3600`, riga in `cron_daily`, `cblib` che lo legge) | su §11 0,005 di f; **su un crollo ±0,05**; ogni misura oraria su opzioni a DVOL giornaliero eredita lo scarto | un fetch pubblico gratuito (3.163 barre da maggio in 2 chiamate), una riga di cron, e una decisione: e' un feed nuovo dentro il perimetro (D1, certificazione, backup) |
+| **spot causale stantio ≤25 min** (snapshot :25, chiusura :00): ±0,05-0,10 di f per osservazione | `cblib.spot_series` sul feed **5m** certificato (`causale(·, "5m")`): cambia di nuovo ogni numero di `cblib`, quindi con rimisura dichiarata |
+| `options_vrp_calibrate.spot_series` (copia, 20/06) | i numeri del 20/06 (f 0,73) restano con l'ora in piu'; §11 li ha gia' sostituiti | riscriverlo su `cblib` |
+| la tabella pubblicata di §5 (x0,869 / x0,904 / x0,920) | ≤0,005 per fattore: sotto la risoluzione del campione (14+14 scadenze) | nulla: nota aggiunta |
+
+## 7. Errori dell'autore in sessione
+
+- **`asi8` in microsecondi** scrivendo il test della causalita' (pandas 3): i timestamp sintetici finivano
+  nel 1970 e il test falliva per la fixture, non per il codice. E' la trappola del debito 1, ripagata
+  scrivendo un test *sul* debito 18. Corretto con `(idx − epoch) // Timedelta(ms)`, la convenzione di
+  `load_tf`.
+- **La tabella di contesto di `r0909` si e' spostata di un giorno** dopo la riparazione: mostrava il DVOL
+  del giorno D−1 accanto al prezzo del giorno D, e il picco del crollo cambiava (69,2 → 68,3, 46° → 43°)
+  non per una misura ma per un'etichetta. Trovato **col diff degli output**, non da un test: una tabella
+  per umani non ha test. Ora il contesto usa la chiusura *del* giorno (`causale(V, "-1D")`, dichiarato
+  nel commento) e `dvol_pre` / `ivr_pre` restano causali.
+- Il verdetto §7 di `r0822_vrp_real_quotes` era **prosa con numeri cablati**: sarebbe rimasto a 0,714 per
+  sempre (N11 al contrario). Aggiornato con i vecchi accanto; il difetto di forma resta (i numeri del
+  verdetto andrebbero calcolati, non scritti).
+
+## 8. Revisione (`fable`, agente fresco) — 16 segnalazioni, verdetto «correggi e committa»
+
+Ha **riverificato in proprio** la convenzione delle due serie (1h vs 5m su 120 barre: 100%; DVOL contro
+l'API oraria) e riprodotto ogni numero dei documenti lanciando gli script. Applicate: **#2** «−1,8% in
+un'ora» era falso (avevo letto 09:00 → 10:00; il fatto e' +3,9% 08:00 → 09:00) · **#3** due delle tre
+settimane «ETH» erano BTC · **#4** la parentesi sul DVOL era invertita (la chiusura di D e' piu' BASSA,
+non piu' alta) · **#5** lo spot non e' un meccanismo ma rumore, e resta stantio ≤25 min · **#6/#7** due
+lettori di `cblib` non dichiarati: `r0730` (0,73 → 0,71, ora in CLAUDE.md §2) e `r0901` (riallineato) ·
+**#8** le date di calendario di `r0822` §1 slittavano di un giorno · **#9** il test anti-doppio-shift non
+catturava `causale(spot_series, "1h")`: ora conta i `causale(` · **#10** ancora 0,74 → 0,76 nel test
+d'integrazione · **#11** teste di §75 e memoria 20 §5 con i numeri vecchi come correnti (M28) · **#12**
+«±0,05» → «−0,04/+0,06» · **#13** `state.json` riscritto: dichiarato · **#15** lo skew agli ingressi cambia
+piu' del panel (correlazioni che cambiano segno): dichiarato in §5. Non applicate: nessuna. Confermati
+senza rilievo (#1, #14, #16): verso e taglia degli shift, nessun doppio spostamento, `ST` alle 08:00
+coerente con la TWAP 07:30-08:00, tutti i numeri di §3-§5.
+
+## 9. Test
+
+`tests/test_cb_chain_vrp.py`: +3 (causale; `spot_series` causale sul feed 1h con controllo positivo sulla
+serie grezza; `dvol_series` causale sul giornaliero). `tests/test_r0909_crash_catturato.py`: il test dello
+shift locale diventa "lo script usa le serie di `cblib` senza ri-spostarle" (sorgente + controllo positivo
+su `cblib.causale`). Suite intera: **1011 passati, 0 falliti** (erano 1008), rilanciata dopo le correzioni della revisione: 1011/1011.

docs/diary/2026-09-09c-revisione-settimanale.md

@@ -0,0 +1,98 @@
+# 2026-09-09c — Revisione settimanale in sola lettura: cosa si costruisce e cosa no
+
+**Richiesta dell'operatore:** *«schedulare ogni x tempo un processo di auto revisione dei dati e della
+configurazione del sistema in modo che migliori con il tempo … autoregolazione e autoaggiornamento dei
+sistemi o anche creare nuovi sistemi … valutando dati macroeconomici … e poi informa me tramite
+Telegram»*. Dopo la discussione: *«fai»*.
+
+**Esito in una riga:** costruita la **rilettura settimanale in sola lettura** con revisore diverso
+dall'autore (`claude-fable-5-1`), rapporto firmato in `docs/revisioni/` e Sintesi su Telegram, lunedi'
+06:15 UTC; **scartati** — con la memoria del progetto, non per prudenza generica — autoregolazione dei
+parametri, generazione automatica di strategie e macro da internet. Libro, config, pesi: invariati.
+
+## 1. Perche' tre pezzi su quattro sono no
+
+| pezzo | cosa dice la memoria | esito |
+|---|---|---|
+| auto-revisione periodica | nove sorveglianti, ognuno sulla sua grandezza; nessuno rilegge l'insieme; la revisione col secondo modello ha trovato oggi due conclusioni false e un look-ahead | **si'** |
+| autoregolazione dei parametri | TP01/SKH01 congelati (M20), 75/25 confermato 3 volte, `weights_tilt_null` fallisce; `scale_watch` esiste per rendere visibile ogni cambio di config; A8: una riga di config + una di giornale, decisione dell'operatore | **no** |
+| generazione e test di strategie nuove | 69 filoni in 6 ondate; ogni candidato e' un trial (M3) e deflaziona tutto; la ricerca non e' il vincolo binding dal 26/07 (+0,046 €/g il miglior lead contro +4,07%/anno per €100/mese) | **no, salvo freno**: prima si apre la memoria e si batte il motivo della morte; i candidati vanno in forward-monitor con gate e data, mai nel book |
+| dati macro da internet | gate macro / DVOL direzionale / skew de-risk: HEDGE o ridondanti (TP01 gia' flat nei crolli); un dato dal web non e' certificato (D1-D4; la APR USDC 3,40% pubblicata e mai incassata) | **no** |
+
+Il centro dell'argomento: **il progetto ha gia' misurato che piu' ricerca non sposta il traguardo, i
+bonifici si'**. Un ciclo automatico che cerca strategie ottimizza la leva sbagliata e paga in trial bruciati.
+
+## 2. Cosa gira
+
+`scripts/cron_review.sh` (lunedi' **06:15 UTC**: fuori dal :00, fuori dal martedi' 09:00, dopo il
+`cron_daily` delle 00:30 cosi' il giornale di domenica e' chiuso) → `scripts/live/revisione.py --quiet`
+→ `src/live/revisione.scrivi`. Riga installata in crontab (`15 6 * * 1`), letta dal test.
+
+**Materiale** (sola lettura, ~195k caratteri, 27 voci): CLAUDE.md intero · `config/live.json` ·
+`crontab -l` · `git log` 14 g + `git status` · `monitor_health` · stato dei sorveglianti (scale, vrp_f,
+usde, balance, venue_news, movimenti dichiarati, watermark) · 7 pagine di giornale · diari della
+settimana. Gli stati stanno **prima** delle voci grandi: alla prima stesura il tetto totale (320k) aveva
+tagliato `usde_convert.jsonl` a 2 caratteri — un sorvegliante invisibile per un limite di lunghezza.
+
+**Prompt**: dieci regole vincolanti (sola lettura · ogni segnalazione cita la fonte · solo numeri del
+materiale · le decisioni di §3 non si ripropongono se la colonna «cosa la riapre» non e' soddisfatta ·
+un'idea nuova solo citando la memoria che ha ucciso la simile · i gate con data e criterio, senza
+anticipare · misurato ≠ dedotto · niente previsioni · URGENTE per cio' che serve all'operatore subito ·
+cinque titoli fissi, ~1.000 parole). L'ultimo titolo, «Cosa ho letto e cosa mi mancava», e' l'elenco da
+cui il materiale della settimana dopo migliora: e' l'unico «miglioramento col tempo» che questo sistema
+si concede, e passa da una modifica al codice, cioe' da una revisione.
+
+**Uscita**: `docs/revisioni/<data>.md` firmato (modello, ora, «SOLA LETTURA», «lettore fallibile P13»,
+guardia sui numeri come `analista` con soglia 12, tabella del materiale letto). Telegram: la sola
+Sintesi, taglio dichiarato sotto i 4.096. Modello muto o risposta senza i titoli → rapporto «NON
+eseguita» col motivo e 🚨: il silenzio non e' una revisione (P5).
+
+**Cosa non puo' fare, per costruzione**: scrivere altro che il rapporto (test sull'albero dei file:
+`--secco` non scrive niente, un giro scrive UN file), eseguire proposte, cambiare config. Il modello e'
+`claude-fable-5-1` per costante, e un test verifica che sia diverso da `analista.MODELLO_DEFAULT`.
+
+## 3. Test — `tests/test_revisione.py` (16)
+
+Finestra del materiale e file assenti dichiarati · ordine stati-prima-delle-voci-grandi · troncamento
+dichiarato · regole nel prompt · guardia (vuoto, titoli mancanti, numeri fuori con controllo positivo) ·
+rapporto firmato · modello muto → rapporto + 🚨 · Telegram con HTML neutralizzato e taglio dichiarato ·
+`--secco` non chiama e non scrive · un giro scrive un solo file · `--no-telegram` · revisore ≠ autore ·
+cadenza: il `.sh` dichiara «lunedi' HH:MM UTC», minuto ≠ 0, fuori dallo slot di release, e la crontab
+installata ha gli stessi cinque campi (skip se illeggibile). `test_cli_flag` ha preso lo script da solo
+(guardia `valida`, USO coi flag, flag del cron accettati).
+
+## 4. Errori in sessione
+
+- `_tronca(testo, n=MAX_CHARS_VOCE)`: il default e' catturato alla definizione, il test che patchava la
+  costante non vedeva niente — la stessa trappola del debito 12 (`connect`). Letto a runtime.
+- Il tetto totale tagliava in coda: i sorveglianti erano gli ultimi e i primi a sparire. Riordinato, e
+  il test lo presidia.
+
+## 5. Primo giro reale (22:03Z) — e i tre difetti che solo il giro reale poteva trovare
+
+Il primo lancio e' **morto prima di chiamare il modello**: `OSError: Argument list too long` — 195k
+caratteri di prompt passati come argomento alla CLI superano il limite del sistema, e `analista.interroga`
+non lo catturava: zero rapporto, zero Telegram, **il silenzio che il modulo esiste per vietare**. Nessun
+test l'avrebbe trovato (i test iniettano `interroga`): e' un difetto di trasporto, e il trasporto si valida
+sul trasporto (P2). Tre correzioni: (1) `revisione.interroga` proprio, prompt su **stdin**, ogni eccezione
+restituita come errore; (2) `scrivi` incapsula chiamata e invio: un'eccezione diventa un rapporto «NON
+eseguita» + 🚨; (3) `_cmd` (crontab, git) dichiara qualunque eccezione invece di propagarla. Test con
+controllo positivo su `OSError(7)`. Terzo difetto, trovato dal test: `analista.pulisci` **toglie le righe
+che iniziano con `#`**, cioe' i cinque titoli che la guardia richiede — usarlo avrebbe reso ogni revisione
+«rifiutata: titoli mancanti». Sostituito con `strip()`.
+
+Secondo lancio: **rapporto scritto, stato `sospetta`**, 1.435 parole, `docs/revisioni/2026-09-09.md`.
+La guardia ha segnato 11 numeri «non nel materiale»: sono cifre in **formato italiano** («4.477,46»,
+«1.341») contro il materiale in formato USA («$4,477.46») — la normalizzazione di `analista` conosce una
+convenzione sola. E' un limite dichiarato, non un errore del revisore: si aggiusta quando si vede quanto
+spesso scatta. Contenuto: **nessun URGENTE**; tre verifiche in cima (una possibile attribuzione a reward di
+400 USDE che erano un acquisto in `usde_watch` del 07/09 — `n_trades` fermo a 50 contro 54 ordini nel
+registro; il cuscino USDC del debito §5.17 senza definizione balance/equity; il versamento del 04/09 non
+dichiarato in `movimenti_dichiarati.jsonl`); una contraddizione in CLAUDE.md §1 sull'haircut (M28); la data
+di arming che differisce fra §0, config e TWR; quattro sorveglianti senza timestamp o fuori da
+`monitor_health`; e, come richiesto dalla regola 5, **zero idee di strategia**. «Cosa mi mancava»: stati
+con ora di `edge/fee/venue/scale_watch`, l'output di `usde_watch.rendimento()`, i paper a oggi,
+`cron_daily.sh`, il registro fill della settimana — l'elenco da cui il materiale della prossima settimana
+migliora. Le segnalazioni sono dell'operatore e della prossima sessione: **nessuna e' stata applicata qui**
+(sarebbe l'agente che esegue le proposte del revisore nello stesso giro, cioe' il ciclo che si e' scartato).
+Costo: una chiamata, ~4 minuti.

docs/diary/2026-09-10-cinque-punti-revisione.md

@@ -0,0 +1,216 @@
+# I cinque punti della revisione del 09/09 — decisi e fatti
+
+**Data:** 2026-09-10 (sessione 12:08Z → 13:10Z; i timestamp qui dentro sono letti, non ricordati)
+**Origine:** la prima revisione settimanale (`docs/revisioni/2026-09-09.md`, revisore `fable`) e il
+giornale del 09/09. Ogni punto e' stato spiegato all'operatore con pro e contro e **deciso da lui**
+(§3-style: decisioni con l'informazione completa). Issue sul Gitea di casa #2-#6, chiuse con la
+soluzione scritta (regola globale del 10/09).
+
+## Le decisioni, in una tabella
+
+| # | punto | decisione dell'operatore | issue |
+|---|---|---|---|
+| 1 | `usde_watch` contava 400 USDE come reward (07/09) | ripara ora + issue | #2 bug |
+| 2 | cuscino USDC senza sorvegliante (§5.17) | **equity USDC, riconverte da solo** | #3 sviluppo |
+| 3 | versamento 04/09 solo rilevato; piano €5.000 «in attesa» | **e' l'INTERO versamento previsto**: dichiarato, piano chiuso | #6 sviluppo |
+| 4 | SCALA-01 A2: da quando contano i 180 giorni | **dal 01/09** (sorvegliante attivo) → gate non prima del **2027-02-28** | #5 bug |
+| 5 | PREVDAY-01 «senza data» | **tieni 21/06/2027, cabla kill e veto, correggi §4** | #4 bug |
+
+Sul punto 5 la domanda giusta e' stata «ricorda dove dobbiamo arrivare (50 €/g)»: PREVDAY
+de-luckato al 15% vale +0,10 di Sharpe sul libro e la somma di *tutti* i lead dell'ondata di agosto
+vale +0,036 €/giorno. Verso i 50 €/g il candidato vale centesimi in qualunque esito del gate:
+non si spende una sessione di ricerca per anticipare (a)+(b), e non si butta l'unica gamba short
+scorrelata oltre a SKH01 per risparmiare un cron. Costo scelto: mezza giornata, una volta.
+
+## Punto 1 — il lettore dei trade spot aveva DUE limiti, non uno
+
+Il primo era noto dalla revisione: `trade_history(limit=50)` con 54 ordini. Il secondo l'ho
+trovato sondando il gateway per ripararlo: `get_user_trades_by_instrument` chiamato senza
+`historical` restituisce **solo le ultime ~24 ore** — il fill BTC dell'08/09 06:47Z e' invisibile
+alle 12:55Z del 10/09, quello del 09/09 21:47Z si vede. Il cron gira ogni 24h alle 12:35: sta
+dentro la finestra per pochi secondi. Un giro saltato avrebbe reso invisibili i trade fra 48h e
+24h fa, e il delta sarebbe stato attribuito al reward *esattamente come il 07/09*, con un
+meccanismo diverso.
+
+Ora `trade_copertura()` dichiara **non leggibile** (somma `None`, e `analizza` non attribuisce:
+P12) in entrambi i casi — lista lunga quanto il limite (troncata) o ultima lettura oltre 24h+5min —
+e il record porta `trades_motivo` (P4: il perche'). `TRADE_LIMIT = 1000` e' il `count` massimo di
+Deribit. Controllo positivo nei test: 54 ordini si sommano tutti.
+
+La riga del 07/09 in `data/live/usde_watch.jsonl` e' **corretta in loco** con campo `correzione`
+(originale conservato dentro, copia del file in `usde_watch.jsonl.pre_fix_20260910`): 54 ordini
+= 8 + 30 + 16 dal registro `usde_convert.jsonl`, 2.434 USDE, reward 0,080934. Il tasso non
+cambia — la riga era gia' esclusa per `con_trade` — e `rendimento()` oggi da' **3,94% su 14
+finestre, 12 pagate**.
+
+## Punto 2 — `cuscino_watch`: la grandezza che nessuno guardava
+
+Il cuscino richiesto e' `2 × 0,5 × 0,30 × equity_tot` = 30% dell'equity, **derivato** da
+config e `book.WEIGHT`. La formula e' passata da `usde_convert.py` a `src/live/usde.py`, e
+`usde_convert` la importa da li': due lettori, una formula (P1 — cinque occorrenze nel
+progetto di sorveglianti puntati su un bersaglio ridichiarato).
+
+| stato | criterio | azione |
+|---|---|---|
+| OK | slack ≥ 10% del cuscino | niente |
+| PREAVVISO | 0 ≤ slack < 10% | ⚠️ alla transizione |
+| SCOPERTO | slack < 0 | 🚨 + `usde_convert --quota 0,64 --esegui` (cuscino + 20% di margine, alzato dal 10% in revisione) |
+| BLIND | conto non leggibile | ⚠️ alla transizione |
+
+Guardie della riconversione: `execution_enabled` del libro (un solo interruttore), niente vendita
+sotto `depeg_warn` (li' decide l'operatore, e l'allarme lo dice), un tentativo ogni 6h, le guardie
+proprie di `usde_convert` (banda di prezzo, book leggibile, tetto HARD) ereditate lanciando lo
+script vero (P15). Il marcatore «gia' detto» e' l'esito di `notify`: un invio fallito non consuma
+la transizione (lezione del debito §5.2). Cron `:53` = dopo il giro del book (`:47`), fuori dal
+minuto tondo. `monitor_health` lo sorveglia (max 3h).
+
+📌 **Primo giro a secco (13:00Z): gia' PREAVVISO.** USDC equity $1.361,23 contro $1.335,26
+richiesti: **slack +$25,97**. Il 09/09 il revisore aveva stimato +$41/+$59; la marcatura del
+libro dal picco del 06/09 ne aveva consumati altri 15-30 senza che nessuno lo vedesse. E' il
+caso d'uso del sorvegliante, arrivato prima del sorvegliante.
+
+## Punto 3 — il versamento del 04/09, dal balance e non dall'equity
+
+Il salto di equity 13:47→14:47Z diceva +$2.410,14 col mercato dell'ora dentro. Il **balance
+USDC** di `balance_watch` (cambia solo per P&L realizzato, fee, funding e movimenti) dice
+1.417,73455581 → 3.832,41432481 = **+$2.414,68**, nessun fill nella finestra, funding su $541
+di nozionale ~$0,01. Dichiarato con banda $0,05. Il report ora lo mostra come dichiarato e
+il TWR passa a **+6,66%** (era +7,22% stamattina, +7,83% il 06/09): la coda −0,63% dal 04/09 e'
+marcatura delle due long, trading da arming **+$13,82**.
+
+L'operatore ha detto che era **l'intero versamento previsto**: la voce «in attesa di importo e
+data» di §1 e' chiusa. Resta la lezione di §2: per sei giorni il movimento e' stato solo
+rilevato, la regola diceva il giorno stesso.
+
+## Punto 4 — SCALA-01: la data era il punto 5 della SPEC scambiato per il gate
+
+«Non prima del 2026-10-01» erano i 30 giorni di sorvegliante del punto 5 (§7 della SPEC); A2
+chiede **≥180 giorni** col criterio passato ogni giorno, e il criterio lo misura solo
+`scale_watch`, attivo dal 01/09. Le tre letture possibili, con pro e contro, sono nel diario di
+sessione; l'operatore ha scelto **dal 01/09 → 2027-02-28**. Contare dall'arming avrebbe dato
+un criterio ricostruito a posteriori, che non prova nulla sul sorvegliante; ridurre A2 a 30 giorni
+avrebbe allentato un gate senza un costo d'attesa che lo giustifichi (il gradino 1,25x vale meno
+di €100/mese di versamento).
+
+Riconciliata anche la data d'arming: **20/06 = TP01 da solo** (commit `4650aa7`), **23/06 = il
+BOOK** (commit `db738bc`, prima lettura di equity 23/06 22:00Z). CLAUDE.md §0 diceva solo la
+prima, `config/live.json` e il TWR usano la seconda: erano due eventi, non un errore.
+
+## Punto 5 — PREVDAY-01 aveva la data; non l'aveva la tabella
+
+`RESULTS-0822` §54: decisione **2027-06-21**, kill, veto. La tabella §4 diceva «scritto 23/08 ·
+10 condizioni», e il revisore ha letto quella. Ora la riga ha data, kill, veto e stato (5/7:
+(a) e (b) sono strutturali, nessun forward le cambia).
+
+Cablato in `paper_prevday.py` (prima esisteva solo nel testo, a differenza di `paper_dvolspread`):
+
+| misura | valore al 10/09 |
+|---|---|
+| Sharpe forward **giornaliero** (lente del kill; l'oraria +1,19 non si cita, §54) | **+0,95** su 81 giorni, 81 attivi |
+| kill (< −0,50 su ≥180 g attivi) | **NON MATURO**, leggibile dal ~18/12/2026 |
+| barre ricostruibili dal feed di oggi | **1.942/1.943** (99,9%); l'unica divergente e' il 26/08 00:00, il giorno del fix di `advance()` |
+| veto | ok |
+
+⚠️ **Errore mio, catturato prima di committare:** la prima stesura del veto leggeva «divergenze
+non crescenti» come `tasso_recente > tasso_totale`, e con UNA barra divergente negli ultimi 30
+giorni (0,03/g contro 0,01/g) dichiarava VETO. Una guardia piu' stretta del contratto produce
+allarmi che si impara a ignorare (P14): ora la crescita richiede **≥5 barre recenti E tasso
+doppio**, dichiarato nel codice e provato nel test con i numeri della serie vera.
+
+La ricostruzione al 99,9% contro il 95,6% di §54: la misura del 23/08 era stata fatta *prima*
+del fix di `advance()` del 26/08 (le 67 barre divergenti erano «all'ora del cron», cioe' barre
+parziali); oggi il feed rivisto e la serie coincidono tranne quella barra.
+
+## Cose trovate per strada
+
+- Due timestamp «di comodo» scritti a mano (13:05Z e 13:07Z) invece dell'ora letta (12:57:43Z e
+  13:04:09Z): corretti subito. E' esattamente la regola globale «la data si LEGGE» — vale anche per
+  chi la scrive nel campo `correzione`.
+- `issue --json` va **prima** del sottocomando; il percorso nella regola globale era
+  `/opt/docker/AI-OS` invece di `/opt/AI-OS` (corretto la mattina, nel test dello strumento).
+
+## Verifica
+
+`uv run pytest`: **1060 passati** (erano 1031). Nuovi: `test_cuscino_watch.py` (14),
+`test_paper_prevday_gate.py` (8), +5 in `test_usde_watch.py`. Revisione del diff affidata a
+`fable` (agente fresco): esito e correzioni applicate in coda a questo diario.
+
+## Revisione `fable` (13:10-13:18Z): 15 segnalazioni, 4 medie — tutte verificate, 12 applicate
+
+| # | segnalazione | verifica | esito |
+|---|---|---|---|
+| 1 | `puo_riconvertire` contava anche i NON tentativi (`tentata=False`): un giro `--secco` o un prezzo illeggibile bloccava la riconversione vera per 6h | riprodotta | filtro su `tentata` + test |
+| 2 | il tetto del venue in `usde_convert.piano` bloccava anche la **vendita**: con `venue_cap_frac` rimesso in config la riconversione automatica sarebbe stata morta | riprodotta (`side=sell`, `ok=False`) | vale solo in acquisto |
+| 3 | `MARGINE_RIPRISTINO` 10% == `PREAVVISO_FRAC` 10%: dopo ogni 🚨 un ⚠️ per costruzione (P14) | riprodotta col floor di 1 USDE | margine **20%** → quota **0,64**, test |
+| 4 | `--secco` scriveva nel registro vivo (veicolo del punto 1, e maschera un cron fermo) | riprodotta (riga 13:00:15Z) | non scrive; riga tolta |
+| 5 | due bersagli di quota: `quota_target` 0,70 in config contro 0,64 del ripristino; il ripristino e' un **ratchet verso il basso** | letto | dichiarato in CLAUDE.md §5.17 e nel docstring: decisione dell'operatore (N9) |
+| 7 | buco di ≤5 min dentro la tolleranza della finestra 24h | letto | dichiarato (D5) + fonte Deribit documentata |
+| 8 | `giorni_attivi` legge posizioni REAL, il kill e' MODELED | letto | dichiarato nel docstring (81/81 oggi) |
+| 10 | il test del cron leggeva un commento nello `.sh`, non la crontab | letto | legge `crontab -l` come `test_book_cadenza` |
+| 11 | `prevday_target` patchato senza `monkeypatch` | letto | `monkeypatch` |
+| 13 | «QUATTRO movimenti» in §2: sono TRE, in quattro tratti | letto | corretto |
+| 14 | «5/7» contro «8/10» di §54: base diversa non dichiarata | letto | dichiarata |
+| 6, 9, 12, 15 | verifiche che reggono (`sys.executable`, `cwd`, `piano()` in SCOPERTO, ricostruzione ≡ `advance`) | — | — |
+
+Non applicato: il lock fra cron e conversione a mano (DUBBIO 2) — dichiarato come limite nel
+docstring. Il DUBBIO 1 (ratchet) e' la domanda aperta per l'operatore.
+
+## Coda (13:55Z →): il riacquisto automatico — issue #7
+
+Alla domanda aperta (ratchet verso il basso) l'operatore ha risposto «crea una strategia per
+riportarla a quota in autonomia». La risposta ingenua — ricomprare fino a `quota_target` 0,70 —
+e' sbagliata per costruzione: a 0,70 lo slack e' zero, la prima ora in perdita vende, il
+riacquisto ricompra, e cosi' via a 6 bps al giro. Serve **isteresi con un bersaglio unico**:
+
+| slack / cuscino | stato | azione |
+|---|---|---|
+| < 0 | SCOPERTO | 🚨 vende USDE → 0,20 |
+| 0 – 0,10 | PREAVVISO | ⚠️ |
+| 0,10 – 0,40 | OK | — |
+| > 0,40 | **ECCEDENTE** | 📌 compra USDE → 0,20 |
+
+Bersaglio 0,20 ⇒ quota **0,64**. Per oscillare lo slack deve muoversi di ±0,20×cuscino = ±6%
+dell'equity, cioe' **±8,6% di equity USDC (~$380)** perche' slack = 0,7·USDC − 0,3·USDE (la prima
+stesura diceva ±6%/$270: corretta in revisione): a leva 0,26x sono ~33% di mercato. Un bonifico alza lo slack di
+0,7×importo: sopra ~9% dell'equity (~$380) il riacquisto scatta da solo — la regola di §1
+«dopo un bonifico si rilancia `usde_convert`» non dipende piu' da qualcuno che se ne ricordi.
+Le tre frazioni vivono in `config/live.json` (`usde.bande_cuscino` verifica 0 < preavviso <
+margine < riacquisto), `quota_target` 0,70 e' stato tolto. Soglie dichiarate, non ottimizzate
+(M8): il costo di un giro e' ~$0,2, la frequenza attesa qualche giro al mese nei tratti mossi.
+
+📌 **Trovato al primo giro vero del cron (13:53Z): l'allerta PREAVVISO non e' partita.** Il token
+era valido (`getMe` ok); il testo conteneva «(< 10% del cuscino)» e Telegram in `parse_mode=HTML`
+rifiuta un `<` nudo. Testi riscritti senza `<`, `allerta_errore` registrato nel record (P3),
+test che legge il sorgente delle `notify`. Un sorvegliante nuovo che non riesce a parlare al
+primo giro e' il caso di P2: si valida sul segnale E sul trasporto.
+
+Stato al giro a secco delle 14:0xZ: quota 69,3%, slack +$30 = PREAVVISO. Il piano a 0,64 e'
+valido (SELL 237 USDE, slack dopo +$267): il sorvegliante lo esegue alla prima ora sotto zero;
+allinearlo subito e' una riga a mano.
+
+### Seconda revisione `fable` (14:04Z): 10 segnalazioni, 1 ALTA, 3 MEDIE — applicate 9
+
+| # | segnalazione | esito |
+|---|---|---|
+| 1 ALTA | il `<` arrivava ancora a Telegram dal campo `motivo` («(< 6h)») dentro l'allerta 🚨: il 🚨 piu' importante perso fino a 4h | escape nel **sink** `notifier.notify` (`html.escape` su titolo e valori; nessuno dei 45 chiamanti passa tag: grep) + motivi senza `<` |
+| 2 MEDIA | il test sul sorgente era parziale (codice morto, cieco ai valori interpolati) | sostituito: cattura la POST e verifica `&lt;` |
+| 3 MEDIA | ECCEDENTE con guasto persistente = «acquisto FALLITA» ogni 6h per sempre | da ECCEDENTE dopo un fallimento si riprova ogni 24h; da SCOPERTO resta 6h |
+| 4 MEDIA | bande fuori ordine ⇒ traceback ingoiato dal cron, nessun record, «fermo» invece di «rotto» | `giudica` ⇒ BLIND con motivo; record e allerta scritti |
+| 5-7 | CLAUDE.md §1 diceva ancora «nessuno sorveglia»; §5.17 «tre stati»; `_nota_usde` con `quota_target` | corretti |
+| 8 | «±6% di equity USDC» sbagliato di 0,7: slack = 0,7·USDC − 0,3·USDE ⇒ ±8,6% (~$380) | corretto in 4 posti |
+| 9 | `TOLL` ridichiarato nel test | importato da `usde_convert` |
+| 10 | esempi `--quota 0.70` nel docstring di `usde_convert` | 0,64 |
+
+Verifiche numeriche del revisore (loop su `piano()` con passo 1 USDE, TOLL, min order): bonifico
++$2.000 → 11 acquisti → OK, slack +$387; perdita −$50 → 3 vendite → OK, +$264; conto tutto USDC →
+20 acquisti → OK. **Nessuna sequenza vendita→acquisto→vendita.** Non applicato: `min(q*, cap)` con
+il tetto del venue (dubbio 3: un conto al tetto resta ECCEDENTE e ora allerta una volta al giorno).
+Dubbio 4, che vale una riga in §5.17: **0,64 e' una derivazione dell'autore, non la quota decisa
+dall'operatore il 30/08 (0,70)**; ~$10/anno di resa di differenza; da confermare.
+
+### Allineamento eseguito (14:16:38Z, ordine dell'operatore «allinea subito a 0.64, esegui»)
+
+`usde_convert --quota 0.64 --esegui`: SELL 100 + 100 + 38 USDE a 1,0000 medio (limite 0,9995,
+fill al book), quota 69,4% → **64,02%**, conto USDC $1.602,79 + USDE 2.851,95 = $4.454,74.
+Slack dopo **+$266** su $1.336 di cuscino: `cuscino_watch --secco` dice **OK** (era PREAVVISO a
++$29). Costo: ~$0,1 di spread, fee zero. Registro in `data/live/usde_convert.jsonl`.

docs/diary/2026-09-10b-macro-riskoff.md

@@ -0,0 +1,52 @@
+# Risk-off ±2h intorno a FOMC e CPI su TP01 — REFUTED, e il segno e' l'opposto
+
+**Data:** 2026-09-10 14:52-14:55Z · **Script:** `scripts/research/r0910_macro_riskoff.py` (N11: il
+verdetto lo calcola lo script) · **Issue:** #9 · **Origine:** domanda dell'operatore da un articolo su
+EA forex a griglia con «agente fondamentale» che approva/rifiuta i segnali intorno ai dati macro.
+
+## Cosa si e' misurato
+
+TP01 canonico (posizione decisa alla chiusura giornaliera, tenuta 24 barre 1h), 2019-03 → 2026-09,
+65.676 ore. Variante RISK-OFF: esposizione zero nelle barre che intersecano [t−2h, t+2h] intorno a
+**61 dichiarazioni FOMC** (14:00 ET, piu' le due d'emergenza di marzo 2020, notation vote esclusi) e
+**88 release CPI** (08:30 ET), con fee di chiusura e riapertura. Calendario **letto dal web** (Fed e
+BLS), non ricordato; l'archivio BLS raggruppa per anno di riferimento e le release di gennaio/febbraio
+vanno spostate di +1 anno (verificato sulla schedule 2026). 684 ore in finestra = **1,04%** del tempo.
+
+Verdetto pre-registrato prima del primo numero: LEAD solo se (a) ΔSharpe con fee > 0, (b) Δ al ≥95°
+percentile del null location-matched (stessi conteggi per anno, stesse ore del giorno, giorni a caso,
+1.000 estrazioni — M18), (c) Δ > 0 in ≥70% degli anni (M9).
+
+## Numeri
+
+| | Sharpe giornaliero | drift/anno |
+|---|---|---|
+| TP01 base | 1,302 | +15,73% |
+| risk-off con fee | 1,205 | +14,49% |
+| risk-off senza fee | 1,228 | +14,77% |
+| **Δ** | **−0,097** | **−1,24%** ≈ **−0,14 €/giorno** a $4.455 |
+
+Per tipo: FOMC ΔSh −0,012 (P&L rinunciato +0,79%), **CPI −0,084 (+6,36%)**. Per anno: Δ negativo in
+6/8, positivo solo 2024 e 2026 (+0,02/+0,03).
+
+Null location-matched: ΔSh mediana −0,033 [p05 −0,095, p95 +0,027]. **Il Δ vero sta al 4,2°
+percentile**: le finestre vere sono fra le PEGGIORI da appiattire, cioe' fra le migliori in cui
+essere esposti. Dentro la finestra TP01 fa **+1,05 bp/ora contro +0,17 fuori** (t = 1,57 su 684 ore).
+
+(a) FAIL · (b) FAIL · (c) 2/8 FAIL ⇒ **REFUTED**.
+
+## Lettura
+
+1. **Il risk-off toglie P&L, non rischio.** TP01 e' long-flat vol-targeted: nelle ore dei dati macro
+   il trend che sta cavalcando accelera piu' spesso di quanto si rovesci, e l'1% del tempo in finestra
+   porta il 7% del guadagno cumulato. E' la stessa lezione del weekend (§3, 17/07: il 38% del gross
+   nel 31% del tempo): **la coda del trend vive nelle ore «pericolose»**.
+2. **Il segno opposto non e' un lead.** «Esporsi DI PIU' intorno ai dati» sarebbe un'ipotesi nuova
+   (M12), con t = 1,57 e 684 ore: sotto qualunque MDE, e la selezione sull'esito la vieta. Non si apre.
+3. Il gate «fondamentale» dell'articolo, applicato al nostro libro, costerebbe **−1,24%/anno di drift**
+   — la stessa taglia del funding non modellato (−2,16%), ma con segno scelto da chi lo propone.
+4. Coerente con `macro-regime-gate` (29/06, ridondante col trend) e con la conclusione di §3: **ogni
+   risk-off parte REFUTED** e questo lo e' rimasto.
+
+Non modellato (dichiarato): funding (identico nelle due varianti salvo l'1% delle ore); slippage
+della finestra (rende il risk-off *piu'* costoso, non meno). Costo: 3 minuti di calcolo, 0 ordini.

docs/journal/2026-06-23.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-06-23
+
+*Scritto 2026-08-23T13:34:09+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $62,684.00 | -1.99% | -4.48% | -18.57% | 42.8% | ↓ ↓ ↓ (0/3 su) | 41.6 (27° pctl 1a) |
+| **ETH** | $1,665.60 | -3.52% | -7.05% | -20.59% | 63.4% | ↓ ↓ ↓ (0/3 su) | 56.2 (21° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-06-23 · 2 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (2 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 2/24 — **22 mancanti**
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 41.6 contro realizzata 30g 42.8 (sotto); DVOL al 27° pctl di un anno; IV-rank espandente 0.14 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 56.2 contro realizzata 30g 63.4 (sotto); DVOL al 21° pctl di un anno; IV-rank espandente 0.15 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[giri]` ⚠️ **22 giri di `book_execute` mancanti** su 24: in quelle ore il libro non ha ne' letto ne' eseguito.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-06-24.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-06-24
+
+*Scritto 2026-08-23T13:34:10+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $60,977.50 | -2.72% | -5.39% | -21.09% | 43.3% | ↓ ↓ ↓ (0/3 su) | 45.1 (51° pctl 1a) |
+| **ETH** | $1,619.90 | -2.74% | -7.43% | -23.29% | 63.6% | ↓ ↓ ↓ (0/3 su) | 58.8 (28° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-06-24 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 45.1 contro realizzata 30g 43.3 (sopra); DVOL al 51° pctl di un anno; IV-rank espandente 0.22 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 58.8 contro realizzata 30g 63.6 (sotto); DVOL al 28° pctl di un anno; IV-rank espandente 0.19 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **1 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-06-25.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-06-25
+
+*Scritto 2026-08-23T13:34:10+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $59,702.00 | -2.09% | -5.08% | -21.25% | 43.3% | ↓ ↓ ↓ (0/3 su) | 46.6 (57° pctl 1a) |
+| **ETH** | $1,564.90 | -3.40% | -8.47% | -24.43% | 64.1% | ↓ ↓ ↓ (0/3 su) | 60.8 (33° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-06-25 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 46.6 contro realizzata 30g 43.3 (sopra); DVOL al 57° pctl di un anno; IV-rank espandente 0.24 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 60.8 contro realizzata 30g 64.1 (sotto); DVOL al 33° pctl di un anno; IV-rank espandente 0.22 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **2 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-06-26.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-06-26
+
+*Scritto 2026-08-23T13:34:10+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $60,017.00 | +0.53% | -5.47% | -19.28% | 43.4% | ↓ ↓ ↓ (0/3 su) | 45.5 (52° pctl 1a) |
+| **ETH** | $1,576.05 | +0.71% | -7.82% | -22.08% | 64.1% | ↓ ↓ ↓ (0/3 su) | 59.8 (30° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-06-26 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 45.5 contro realizzata 30g 43.4 (sopra); DVOL al 52° pctl di un anno; IV-rank espandente 0.23 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 59.8 contro realizzata 30g 64.1 (sotto); DVOL al 30° pctl di un anno; IV-rank espandente 0.20 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **3 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-06-27.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-06-27
+
+*Scritto 2026-08-23T13:34:10+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $59,956.00 | -0.10% | -6.67% | -18.47% | 43.4% | ↓ ↓ ↓ (0/3 su) | 45.2 (52° pctl 1a) |
+| **ETH** | $1,570.80 | -0.33% | -9.67% | -21.76% | 64.2% | ↓ ↓ ↓ (0/3 su) | 59.9 (31° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-06-27 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 45.2 contro realizzata 30g 43.4 (sopra); DVOL al 52° pctl di un anno; IV-rank espandente 0.22 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 59.9 contro realizzata 30g 64.2 (sotto); DVOL al 31° pctl di un anno; IV-rank espandente 0.20 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **4 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-06-28.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-06-28
+
+*Scritto 2026-08-23T13:34:10+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $59,503.50 | -0.75% | -5.92% | -18.92% | 43.4% | ↓ ↓ ↓ (0/3 su) | 47.7 (63° pctl 1a) |
+| **ETH** | $1,569.20 | -0.10% | -8.01% | -22.04% | 64.1% | ↓ ↓ ↓ (0/3 su) | 61.3 (37° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-06-28 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 47.7 contro realizzata 30g 43.4 (sopra); DVOL al 63° pctl di un anno; IV-rank espandente 0.27 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 61.3 contro realizzata 30g 64.1 (sotto); DVOL al 37° pctl di un anno; IV-rank espandente 0.23 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **5 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-06-29.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-06-29
+
+*Scritto 2026-08-23T13:34:10+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $60,166.50 | +1.11% | -5.92% | -18.46% | 43.6% | ↓ ↓ ↓ (0/3 su) | 42.6 (33° pctl 1a) |
+| **ETH** | $1,611.20 | +2.68% | -6.68% | -20.24% | 65.1% | ↓ ↓ ↓ (0/3 su) | 57.9 (26° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-06-29 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (23 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 42.6 contro realizzata 30g 43.6 (sotto); DVOL al 33° pctl di un anno; IV-rank espandente 0.16 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 57.9 contro realizzata 30g 65.1 (sotto); DVOL al 26° pctl di un anno; IV-rank espandente 0.18 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **6 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-06-30.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-06-30
+
+*Scritto 2026-08-23T13:34:10+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $58,546.50 | -2.69% | -6.60% | -20.44% | 44.2% | ↓ ↓ ↓ (0/3 su) | 44.5 (46° pctl 1a) |
+| **ETH** | $1,570.55 | -2.52% | -5.71% | -21.67% | 65.4% | ↓ ↓ ↓ (0/3 su) | 59.0 (29° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-06-30 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 44.5 contro realizzata 30g 44.2 (sopra); DVOL al 46° pctl di un anno; IV-rank espandente 0.20 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 59.0 contro realizzata 30g 65.4 (sotto); DVOL al 29° pctl di un anno; IV-rank espandente 0.19 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **7 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-01.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-01
+
+*Scritto 2026-08-23T13:34:11+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $59,961.50 | +2.42% | -1.67% | -15.93% | 44.6% | ↓ ↓ ↓ (0/3 su) | 42.9 (36° pctl 1a) |
+| **ETH** | $1,607.95 | +2.38% | -0.74% | -19.81% | 66.3% | ↓ ↓ ↓ (0/3 su) | 56.9 (23° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-01 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 42.9 contro realizzata 30g 44.6 (sotto); DVOL al 36° pctl di un anno; IV-rank espandente 0.17 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 56.9 contro realizzata 30g 66.3 (sotto); DVOL al 23° pctl di un anno; IV-rank espandente 0.16 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **8 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-02.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-02
+
+*Scritto 2026-08-23T13:34:11+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $61,518.50 | +2.60% | +3.04% | -7.71% | 40.0% | ↓ ↓ ↓ (0/3 su) | 40.5 (21° pctl 1a) |
+| **ETH** | $1,698.60 | +5.64% | +8.54% | -8.57% | 64.9% | ↓ ↓ ↓ (0/3 su) | 55.1 (16° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-02 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 40.5 contro realizzata 30g 40.0 (sopra); DVOL al 21° pctl di un anno; IV-rank espandente 0.12 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 55.1 contro realizzata 30g 64.9 (sotto); DVOL al 16° pctl di un anno; IV-rank espandente 0.14 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **9 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-03.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-03
+
+*Scritto 2026-08-23T13:34:11+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $62,542.00 | +1.66% | +4.21% | -2.28% | 38.1% | ↓ ↓ ↓ (0/3 su) | 39.5 (14° pctl 1a) |
+| **ETH** | $1,757.15 | +3.45% | +11.49% | -2.98% | 65.6% | ↓ ↓ ↓ (0/3 su) | 53.5 (8° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-03 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 39.5 contro realizzata 30g 38.1 (sopra); DVOL al 14° pctl di un anno; IV-rank espandente 0.10 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 53.5 contro realizzata 30g 65.6 (sotto); DVOL al 8° pctl di un anno; IV-rank espandente 0.12 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **10 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-04.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-04
+
+*Scritto 2026-08-23T13:34:11+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $63,080.00 | +0.86% | +5.21% | -1.15% | 38.2% | ↓ ↓ ↓ (0/3 su) | 39.2 (13° pctl 1a) |
+| **ETH** | $1,779.40 | +1.27% | +13.28% | +0.56% | 65.3% | ↑ ↓ ↓ (1/3 su) | 53.0 (6° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-04 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 39.2 contro realizzata 30g 38.2 (sopra); DVOL al 13° pctl di un anno; IV-rank espandente 0.09 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 53.0 contro realizzata 30g 65.3 (sotto); DVOL al 6° pctl di un anno; IV-rank espandente 0.11 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **11 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-05.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-05
+
+*Scritto 2026-08-23T13:34:11+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $63,624.00 | +0.86% | +6.92% | +4.22% | 34.9% | ↑ ↓ ↓ (1/3 su) | 38.7 (10° pctl 1a) |
+| **ETH** | $1,784.95 | +0.31% | +13.75% | +12.77% | 51.3% | ↑ ↓ ↓ (1/3 su) | 53.1 (6° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-05 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 38.7 contro realizzata 30g 34.9 (sopra); DVOL al 10° pctl di un anno; IV-rank espandente 0.08 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 53.1 contro realizzata 30g 51.3 (sopra); DVOL al 6° pctl di un anno; IV-rank espandente 0.12 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **12 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-06.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-06
+
+*Scritto 2026-08-23T13:34:11+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $64,012.00 | +0.61% | +6.39% | +5.19% | 34.8% | ↑ ↓ ↓ (1/3 su) | 37.3 (4° pctl 1a) |
+| **ETH** | $1,798.85 | +0.78% | +11.65% | +14.67% | 51.1% | ↑ ↓ ↓ (1/3 su) | 52.6 (6° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-06 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 37.3 contro realizzata 30g 34.8 (sopra); DVOL al 4° pctl di un anno; IV-rank espandente 0.05 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 52.6 contro realizzata 30g 51.1 (sopra); DVOL al 6° pctl di un anno; IV-rank espandente 0.11 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **13 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-07.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-07
+
+*Scritto 2026-08-23T13:34:11+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $63,322.00 | -1.08% | +8.16% | +0.03% | 32.3% | ↑ ↓ ↓ (1/3 su) | 38.9 (12° pctl 1a) |
+| **ETH** | $1,770.30 | -1.59% | +12.72% | +4.79% | 45.0% | ↑ ↓ ↓ (1/3 su) | 53.3 (7° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-07 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (23 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 38.9 contro realizzata 30g 32.3 (sopra); DVOL al 12° pctl di un anno; IV-rank espandente 0.09 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 53.3 contro realizzata 30g 45.0 (sopra); DVOL al 7° pctl di un anno; IV-rank espandente 0.12 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **14 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-08.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-08
+
+*Scritto 2026-08-23T13:34:11+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $62,259.00 | -1.68% | +3.83% | -1.27% | 32.8% | ↓ ↓ ↓ (0/3 su) | 39.5 (16° pctl 1a) |
+| **ETH** | $1,742.25 | -1.58% | +8.35% | +3.14% | 45.4% | ↑ ↓ ↓ (1/3 su) | 53.4 (8° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-08 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 39.5 contro realizzata 30g 32.8 (sopra); DVOL al 16° pctl di un anno; IV-rank espandente 0.11 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 53.4 contro realizzata 30g 45.4 (sopra); DVOL al 8° pctl di un anno; IV-rank espandente 0.12 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **15 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-09.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-09
+
+*Scritto 2026-08-23T13:34:11+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $63,200.00 | +1.51% | +2.73% | +2.42% | 32.3% | ↑ ↓ ↓ (1/3 su) | 37.3 (5° pctl 1a) |
+| **ETH** | $1,744.25 | +0.11% | +2.69% | +6.49% | 43.9% | ↑ ↓ ↓ (1/3 su) | 52.0 (5° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-08 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (15 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 37.3 contro realizzata 30g 32.3 (sopra); DVOL al 5° pctl di un anno; IV-rank espandente 0.05 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 52.0 contro realizzata 30g 43.9 (sopra); DVOL al 5° pctl di un anno; IV-rank espandente 0.11 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **16 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-10.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-10
+
+*Scritto 2026-08-23T13:34:12+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $64,136.00 | +1.48% | +2.55% | +4.36% | 32.6% | ↑ ↓ ↓ (1/3 su) | 36.2 (2° pctl 1a) |
+| **ETH** | $1,796.05 | +2.97% | +2.21% | +10.82% | 44.7% | ↑ ↓ ↓ (1/3 su) | 49.8 (4° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-08 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 36.2 contro realizzata 30g 32.6 (sopra); DVOL al 2° pctl di un anno; IV-rank espandente 0.03 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 49.8 contro realizzata 30g 44.7 (sopra); DVOL al 4° pctl di un anno; IV-rank espandente 0.10 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **17 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-11.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-11
+
+*Scritto 2026-08-23T13:34:12+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $63,804.50 | -0.52% | +1.15% | +0.36% | 30.5% | ↑ ↓ ↓ (1/3 su) | 36.8 (4° pctl 1a) |
+| **ETH** | $1,787.15 | -0.50% | +0.44% | +6.93% | 43.7% | ↑ ↓ ↓ (1/3 su) | 50.6 (4° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-08 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 36.8 contro realizzata 30g 30.5 (sopra); DVOL al 4° pctl di un anno; IV-rank espandente 0.04 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 50.6 contro realizzata 30g 43.7 (sopra); DVOL al 4° pctl di un anno; IV-rank espandente 0.10 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **18 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-12.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-12
+
+*Scritto 2026-08-23T13:34:12+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $63,759.50 | -0.07% | +0.21% | +0.33% | 30.5% | ↑ ↓ ↓ (1/3 su) | 37.2 (5° pctl 1a) |
+| **ETH** | $1,805.70 | +1.04% | +1.16% | +8.40% | 43.7% | ↑ ↓ ↓ (1/3 su) | 51.0 (5° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-08 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 37.2 contro realizzata 30g 30.5 (sopra); DVOL al 5° pctl di un anno; IV-rank espandente 0.05 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 51.0 contro realizzata 30g 43.7 (sopra); DVOL al 5° pctl di un anno; IV-rank espandente 0.11 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **19 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-13.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-13
+
+*Scritto 2026-08-23T13:34:12+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $62,265.50 | -2.34% | -2.73% | -3.34% | 31.2% | ↓ ↓ ↓ (0/3 su) | 37.8 (8° pctl 1a) |
+| **ETH** | $1,775.55 | -1.67% | -1.30% | +5.67% | 44.2% | ↑ ↓ ↓ (1/3 su) | 51.1 (6° pctl 1a) |
+
+## Libro
+
+Equity **$598.06** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-08 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+0.00**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 37.8 contro realizzata 30g 31.2 (sopra); DVOL al 8° pctl di un anno; IV-rank espandente 0.06 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 51.1 contro realizzata 30g 44.2 (sopra); DVOL al 6° pctl di un anno; IV-rank espandente 0.11 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **20 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-14.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-14
+
+*Scritto 2026-08-23T13:34:12+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $65,012.00 | +4.41% | +2.67% | -1.08% | 34.1% | ↓ ↓ ↓ (0/3 su) | 36.5 (3° pctl 1a) |
+| **ETH** | $1,889.60 | +6.42% | +6.74% | +9.53% | 48.3% | ↑ ↓ ↓ (1/3 su) | 49.5 (3° pctl 1a) |
+
+## Libro
+
+Equity **$598.49** · nozionale lordo $75 · leva lorda 0.13x · barra dati 2026-07-08 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | LONG @ 1,868.9 | $+75 | $+75 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.43** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 1 fill · fee 0.0374
+- cumulato dall'arming: **$+0.43**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` A mercato su ETH $+75 (TP01 +0.000, SKH01 long).
+- `[leva]` Leva lorda **0.13x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 0.87x.
+- `[pnl]` Equity $+0.43 con 1 fill e 0 round-trip chiusi (realizzato $+0.00 netto).
+- `[vol]` BTC: implicita 36.5 contro realizzata 30g 34.1 (sopra); DVOL al 3° pctl di un anno; IV-rank espandente 0.03 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 49.5 contro realizzata 30g 48.3 (sopra); DVOL al 3° pctl di un anno; IV-rank espandente 0.10 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evento]` 📌 BTC: giornata a +4.41%, **2.5 deviazioni** giornaliere (sd implicita dalla RV30 = 1.78%).
+- `[evento]` 📌 ETH: giornata a +6.42%, **2.5 deviazioni** giornaliere (sd implicita dalla RV30 = 2.53%).
+- `[evidenza]` 📌 Campione a oggi: **21 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-15.md

@@ -0,0 +1,45 @@
+# Giornale di bordo — 2026-07-15
+
+*Scritto 2026-08-23T13:34:12+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $64,734.50 | -0.43% | +3.98% | -2.35% | 34.0% | ↓ ↓ ↓ (0/3 su) | 36.0 (1° pctl 1a) |
+| **ETH** | $1,916.70 | +1.43% | +10.01% | +6.73% | 46.6% | ↑ ↓ ↓ (1/3 su) | 49.0 (2° pctl 1a) |
+
+## Libro
+
+Equity **$600.14** · nozionale lordo $77 · leva lorda 0.13x · barra dati 2026-07-15 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | LONG @ 1,868.9 | $+75 | $+77 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+1.65** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$+2.08**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` A mercato su ETH $+77 (TP01 +0.000, SKH01 long).
+- `[leva]` Leva lorda **0.13x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 0.87x.
+- `[pnl]` Equity $+1.65 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 36.0 contro realizzata 30g 34.0 (sopra); DVOL al 1° pctl di un anno; IV-rank espandente 0.02 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 49.0 contro realizzata 30g 46.6 (sopra); DVOL al 2° pctl di un anno; IV-rank espandente 0.09 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **22 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-16.md

@@ -0,0 +1,45 @@
+# Giornale di bordo — 2026-07-16
+
+*Scritto 2026-08-23T13:34:12+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $63,804.50 | -1.44% | +0.96% | -2.77% | 34.1% | ↓ ↓ ↓ (0/3 su) | 36.4 (3° pctl 1a) |
+| **ETH** | $1,863.55 | -2.77% | +6.84% | +4.00% | 47.7% | ↑ ↓ ↓ (1/3 su) | 49.2 (2° pctl 1a) |
+
+## Libro
+
+Equity **$597.93** · nozionale lordo $75 · leva lorda 0.13x · barra dati 2026-07-16 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | LONG @ 1,868.9 | $+75 | $+75 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$-2.21** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-0.13**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` A mercato su ETH $+75 (TP01 +0.000, SKH01 long).
+- `[leva]` Leva lorda **0.13x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 0.87x.
+- `[pnl]` Equity $-2.21 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[vol]` BTC: implicita 36.4 contro realizzata 30g 34.1 (sopra); DVOL al 3° pctl di un anno; IV-rank espandente 0.03 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 49.2 contro realizzata 30g 47.7 (sopra); DVOL al 2° pctl di un anno; IV-rank espandente 0.09 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **23 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-17.md

@@ -0,0 +1,46 @@
+# Giornale di bordo — 2026-07-17
+
+*Scritto 2026-08-23T13:34:12+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $63,904.00 | +0.16% | -0.36% | -0.85% | 33.6% | ↓ ↓ ↓ (0/3 su) | 36.3 (3° pctl 1a) |
+| **ETH** | $1,841.00 | -1.21% | +2.50% | +5.21% | 47.1% | ↑ ↓ ↓ (1/3 su) | 49.0 (2° pctl 1a) |
+
+## Libro
+
+Equity **$596.77** · nozionale lordo $74 · leva lorda 0.12x · barra dati 2026-07-17 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | LONG @ 1,868.9 | $+75 | $+74 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$-1.16** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-1.29**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` A mercato su ETH $+74 (TP01 +0.000, SKH01 long).
+- `[leva]` Leva lorda **0.12x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 0.88x.
+- `[pnl]` Equity $-1.16 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[drawdown]` 📌 Equity **-0.63%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 36.3 contro realizzata 30g 33.6 (sopra); DVOL al 3° pctl di un anno; IV-rank espandente 0.03 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 49.0 contro realizzata 30g 47.1 (sopra); DVOL al 2° pctl di un anno; IV-rank espandente 0.09 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **24 giorni, 0 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-18.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-18
+
+*Scritto 2026-08-23T13:34:12+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $64,810.00 | +1.42% | +1.58% | +3.04% | 32.8% | ↑ ↓ ↓ (1/3 su) | 35.7 (1° pctl 1a) |
+| **ETH** | $1,861.75 | +1.13% | +4.17% | +8.89% | 46.4% | ↑ ↓ ↓ (1/3 su) | 49.3 (4° pctl 1a) |
+
+## Libro
+
+Equity **$596.92** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-18 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.15** di equity (24 letture)
+- realizzato: -1.10 netto su 1 round-trip chiusi · 1 fill · fee 0.0369
+- cumulato dall'arming: **$-1.14**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.15 con 1 fill e 1 round-trip chiusi (realizzato $-1.10 netto).
+- `[drawdown]` 📌 Equity **-0.60%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 35.7 contro realizzata 30g 32.8 (sopra); DVOL al 1° pctl di un anno; IV-rank espandente 0.02 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 49.3 contro realizzata 30g 46.4 (sopra); DVOL al 4° pctl di un anno; IV-rank espandente 0.10 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **25 giorni, 1 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-19.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-19
+
+*Scritto 2026-08-23T13:34:13+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $64,704.50 | -0.16% | +1.48% | +1.92% | 32.7% | ↑ ↓ ↓ (1/3 su) | 36.1 (3° pctl 1a) |
+| **ETH** | $1,871.60 | +0.53% | +3.65% | +9.47% | 46.4% | ↑ ↓ ↓ (1/3 su) | 49.7 (6° pctl 1a) |
+
+## Libro
+
+Equity **$596.92** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-19 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-1.14**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[drawdown]` 📌 Equity **-0.60%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 36.1 contro realizzata 30g 32.7 (sopra); DVOL al 3° pctl di un anno; IV-rank espandente 0.03 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 49.7 contro realizzata 30g 46.4 (sopra); DVOL al 6° pctl di un anno; IV-rank espandente 0.10 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **26 giorni, 1 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-20.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-20
+
+*Scritto 2026-08-23T13:34:13+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $65,216.50 | +0.79% | +4.74% | +1.52% | 32.5% | ↑ ↓ ↓ (1/3 su) | 36.3 (4° pctl 1a) |
+| **ETH** | $1,903.45 | +1.70% | +7.20% | +9.46% | 46.4% | ↑ ↓ ↓ (1/3 su) | 50.4 (7° pctl 1a) |
+
+## Libro
+
+Equity **$596.92** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-20 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-1.14**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[drawdown]` 📌 Equity **-0.60%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 36.3 contro realizzata 30g 32.5 (sopra); DVOL al 4° pctl di un anno; IV-rank espandente 0.03 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 50.4 contro realizzata 30g 46.4 (sopra); DVOL al 7° pctl di un anno; IV-rank espandente 0.11 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **27 giorni, 1 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-21.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-21
+
+*Scritto 2026-08-23T13:34:13+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $66,532.50 | +2.02% | +2.34% | +5.19% | 32.7% | ↑ ↓ ↓ (1/3 su) | 37.3 (10° pctl 1a) |
+| **ETH** | $1,929.10 | +1.35% | +2.09% | +13.09% | 45.8% | ↑ ↓ ↓ (1/3 su) | 51.0 (8° pctl 1a) |
+
+## Libro
+
+Equity **$596.92** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-21 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-1.14**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[drawdown]` 📌 Equity **-0.60%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 37.3 contro realizzata 30g 32.7 (sopra); DVOL al 10° pctl di un anno; IV-rank espandente 0.06 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 51.0 contro realizzata 30g 45.8 (sopra); DVOL al 8° pctl di un anno; IV-rank espandente 0.11 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **28 giorni, 1 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-22.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-22
+
+*Scritto 2026-08-23T13:34:13+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $66,081.00 | -0.68% | +2.08% | +3.32% | 32.6% | ↑ ↓ ↓ (1/3 su) | 38.0 (12° pctl 1a) |
+| **ETH** | $1,933.70 | +0.24% | +0.89% | +12.00% | 45.7% | ↑ ↓ ↓ (1/3 su) | 51.6 (10° pctl 1a) |
+
+## Libro
+
+Equity **$596.92** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-22 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-1.14**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[drawdown]` 📌 Equity **-0.60%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 38.0 contro realizzata 30g 32.6 (sopra); DVOL al 12° pctl di un anno; IV-rank espandente 0.07 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 51.6 contro realizzata 30g 45.7 (sopra); DVOL al 10° pctl di un anno; IV-rank espandente 0.12 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **29 giorni, 1 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-23.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-23
+
+*Scritto 2026-08-23T13:34:13+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $65,060.00 | -1.55% | +1.97% | +3.79% | 32.3% | ↑ ↓ ↓ (1/3 su) | 38.5 (14° pctl 1a) |
+| **ETH** | $1,877.45 | -2.91% | +0.75% | +12.72% | 45.1% | ↑ ↓ ↓ (1/3 su) | 51.6 (10° pctl 1a) |
+
+## Libro
+
+Equity **$596.92** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-23 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-1.14**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[drawdown]` 📌 Equity **-0.60%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 38.5 contro realizzata 30g 32.3 (sopra); DVOL al 14° pctl di un anno; IV-rank espandente 0.08 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 51.6 contro realizzata 30g 45.1 (sopra); DVOL al 10° pctl di un anno; IV-rank espandente 0.12 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **30 giorni, 1 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-24.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-24
+
+*Scritto 2026-08-23T13:34:13+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $64,103.50 | -1.47% | +0.31% | +5.13% | 31.1% | ↑ ↓ ↓ (1/3 su) | 37.0 (7° pctl 1a) |
+| **ETH** | $1,860.50 | -0.90% | +1.06% | +14.85% | 43.9% | ↑ ↓ ↓ (1/3 su) | 50.5 (7° pctl 1a) |
+
+## Libro
+
+Equity **$596.92** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-24 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-1.14**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: non misurata
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[drawdown]` 📌 Equity **-0.60%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 37.0 contro realizzata 30g 31.1 (sopra); DVOL al 7° pctl di un anno; IV-rank espandente 0.05 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 50.5 contro realizzata 30g 43.9 (sopra); DVOL al 7° pctl di un anno; IV-rank espandente 0.11 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **31 giorni, 1 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-25.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-25
+
+*Scritto 2026-08-23T13:34:13+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $64,327.50 | +0.35% | -0.74% | +7.75% | 30.0% | ↑ ↓ ↓ (1/3 su) | 37.7 (11° pctl 1a) |
+| **ETH** | $1,873.45 | +0.70% | +0.63% | +19.72% | 41.5% | ↑ ↓ ↓ (1/3 su) | 51.5 (10° pctl 1a) |
+
+## Libro
+
+Equity **$596.92** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-25 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-1.14**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: 0 min
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[drawdown]` 📌 Equity **-0.60%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 37.7 contro realizzata 30g 30.0 (sopra); DVOL al 11° pctl di un anno; IV-rank espandente 0.06 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 51.5 contro realizzata 30g 41.5 (sopra); DVOL al 10° pctl di un anno; IV-rank espandente 0.12 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **32 giorni, 1 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*

docs/journal/2026-07-26.md

@@ -0,0 +1,47 @@
+# Giornale di bordo — 2026-07-26
+
+*Scritto 2026-08-23T13:34:13+00:00. Numeri misurati; nessuna interpretazione automatica.*
+
+## Mercato
+
+| | chiusura | 1g | 7g | 30g | RV30 ann. | TSMOM 30/90/180 | DVOL |
+|---|---|---|---|---|---|---|---|
+| **BTC** | $65,357.50 | +1.60% | +1.01% | +8.90% | 30.4% | ↑ ↓ ↓ (1/3 su) | 37.3 (10° pctl 1a) |
+| **ETH** | $1,953.65 | +4.28% | +4.38% | +23.96% | 43.4% | ↑ ↓ ↓ (1/3 su) | 51.7 (11° pctl 1a) |
+
+## Libro
+
+Equity **$596.92** · nozionale lordo $0 · leva lorda 0.00x · barra dati 2026-07-26 · 24 giri
+
+| | TP01 | SKH01 | target | posizione | azione |
+|---|---|---|---|---|---|
+| **BTC** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+| **ETH** | +0.000 | flat | $+0 | $+0 | HOLD (a target) |
+
+## P&L
+
+- giorno: **$+0.00** di equity (24 letture)
+- realizzato: +0.00 netto su 0 round-trip chiusi · 0 fill · fee 0.0000
+- cumulato dall'arming: **$-1.14**
+
+## Salute
+
+- giri di `book_execute`: 24/24
+- eta' feed SKH all'ultimo giro: 0 min
+
+## Lettura
+
+*Generata da regole dichiarate in `src/live/journal.py` — combina i numeri qui sopra e nient'altro. L'id fra parentesi quadre dice quale regola ha parlato. Non e' un giudizio: quello sta nella Nota.*
+
+- `[stato]` Libro **flat** su entrambe le gambe: nessun capitale a mercato.
+- `[perche_flat]` Motivo, componente per componente — BTC: TP01 a zero (trend giu' o misto) e SKH01 senza breakout; ETH: TP01 a zero (trend giu' o misto) e SKH01 senza breakout. Per una strategia long-flat stare fuori **e'** una decisione.
+- `[leva]` Leva lorda **0.00x** su un tetto di 1.00x (`max_notional_per_asset_frac` 0.50 x 2 asset, letto da `config/live.json`): margine 1.00x.
+- `[pnl]` Equity $+0.00 **senza operare**: e' mark-to-market sulle posizioni gia' aperte.
+- `[drawdown]` 📌 Equity **-0.60%** sotto il picco ($600.53). ⚠️ e' un DD su letture ORARIE, non sul minimo intra-giorno.
+- `[vol]` BTC: implicita 37.3 contro realizzata 30g 30.4 (sopra); DVOL al 10° pctl di un anno; IV-rank espandente 0.06 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[vol]` ETH: implicita 51.7 contro realizzata 30g 43.4 (sopra); DVOL al 11° pctl di un anno; IV-rank espandente 0.12 sotto la soglia 0.30 del gate di VRP01 (sleeve fermo).
+- `[evidenza]` 📌 Campione a oggi: **33 giorni, 1 round-trip**. A questa taglia il P&L non distingue l'edge dalla fortuna — il criterio di morte del libro (`edge_watch`) lavora su una finestra di 36 mesi.
+
+## Nota
+
+*(vuota — campo dell'operatore)*