PythagorasGoal/CLAUDE.md

PythagorasGoal — Istruzioni per agenti

Come si usa questo file. Qui sta solo cio' che serve per non sbagliare una decisione: stato, book, numeri citabili, decisioni vincolanti, gate con la loro data, debiti aperti, regole. Il racconto completo — 69 filoni di ricerca, le misure, i controesempi, gli errori corretti — sta in docs/memory/, estratto verbatim da questo file il 2026-08-25 (nulla riscritto, nulla perso).

⚠️ Prima di riaprire un tema, apri il file di memoria che lo copre. Quasi tutto e' gia' stato misurato, e il motivo per cui una cosa e' morta vale piu' dell'esperimento che l'ha uccisa: chi la riapre deve battere il motivo, non ripetere la misura.

file	contiene	aprilo quando
docs/memory/10-sleeve-e-candidati.md	TP01 · XS01 · VRP01 · SKH01 · GTAA01 · XSR01, portafoglio	tocchi uno sleeve o i pesi
docs/memory/20-ondate-e-scartati.md	69 filoni, ogni scartato col suo perche'	hai un'idea "nuova"
docs/memory/30-piano-capitale-fisco.md	muri, versamenti, rischio venue, fisco, prop firm	parli di soldi, rendita, orizzonti
docs/memory/40-produzione-e-deploy.md	esecutore, tripwire, monitor, libro di bordo, PRIIPs/UCITS	tocchi cio' che gira con soldi veri
docs/memory/50-dati-e-feed.md	difetti del dato trovati e riparati, catena opzioni	tocchi i feed
docs/memory/60-metodo-e-gate.md	i gate codificati in altlib.py	valuti un candidato
docs/research/RESULTS-0822.md	registro per filone §1-73	vuoi il dettaglio di un filone
docs/diary/ (123 voci)	la sessione originale, per data	vuoi il contesto completo

---

0. Stato — v2.0.0 RESET (2026-06-19)

LEGGERE PRIMA DI TUTTO. Il progetto fu resettato dopo aver scoperto che l'intera libreria di strategie "validata OOS" era artefatto di uno storico contaminato (print fantasma del feed Cerbero testnet + storico Binance/USDT). Ri-testate sul feed reale, tutte perdono ogni anno. Documento di fondazione: docs/diary/2026-06-19-deribit-history.md.

• Lo storico e' ricostruito da Deribit mainnet e certificato. Universo affidabile = solo BTC/ETH (tutti i TF); gli alt sono esclusi (illiquidi/divergenti/non certificabili).
• Tutto il codice pre-reset e' archiviato in Old/ (preservato in git, non cancellato).
• L'esecuzione e' ARMATA e LIVE su Deribit mainnet dal 2026-06-20. Capitale reale ~$635 (NON i €2.000 nominali del paper trader).
• Si riparte dalla ricerca di strategie NUOVE, su dati certi, con la metodologia della §8.

📌 La riga che chiude sei ondate e 69 filoni: la ricerca ha smesso di essere il vincolo binding il 2026-07-26, e sei ondate lo hanno confermato invece che ribaltarlo. I vincoli binding sono il capitale che entra e il conto che non sparisce. Il miglior lead misurato vale +0,046 €/giorno; versare €500/mese invece di €250 porta P(traguardo a 20 anni) dal 14% all'85%.

---

1. Il book

LIVE (soldi veri). Deribit mainnet, TP01 + SKH01 a 75/25, nettati in software su una sola posizione per asset (src/live/book.py: W_TP01=0.75, W_SKH=0.25, WEIGHT=0.5 → 50/50 BTC/ETH). Esecutore scripts/live/book_execute.py, cron orario scripts/cron_book.sh (minuto :47 dal 2026-08-25; era :07). Due vincoli, entrambi misurati: fuori dai ~26s del minuto tondo (rate-limit per-IP) e fuori dallo slot di release Deribit (martedi' 09:00 UTC, 15-30 min annunciati), che il :07 beccava — 4 volte in 63 giorni. GTAA01, XS01, VRP01, XSR01 NON sono nel book live.

RICERCA (paper). Portafoglio a 5 sleeve src/portfolio/sleeves.active_sleeves: TP01 33 / XS01 15 / VRP01 12 / SKH01 20 / GTAA01 20. Non e' il book live — quasi tutti i numeri di portafoglio del progetto sono su questa serie, non su quella che gira.

Guardrail live (config/live.json, unica autorita' — non ridichiararli nel codice): cap per-asset equity × 0.5, SENZA tetto assoluto, quando l'equity reale e' leggibile; min($3.000, watermark × 0.5) solo nel fallback a equity illeggibile (watermark data/live/equity_seen.json). ⚠️ Fino al 2026-08-25 questa riga dichiarava min($3.000, …) come se valesse sempre: falso — max_notional_per_asset_usd non morde mai sul percorso normale (verificato in src/live/book._cap). Conseguenza: il book scala all'infinito a leva lorda massima 1,0x, e nessun livello di capitale cambia il profilo di rischio relativo. · min_order_usd 5 · disaster_sl_pct 0.30 on-book sulla posizione netta · staleness-gate feed 2 giorni (blocca) · skh_feed_max_age_min 30 (allerta, non blocca) · alert Telegram.

📌 Modello di margine: Cross: Standard Margin (X:SM) dal 2026-08-31, cambiato dall'operatore. Prima era Segregated (S:SM), e sotto quello l'USDE non faceva margine: e' il motivo per cui la misura dell'haircut trovava $0,0000 accantonati — si cercava un parametro non in vigore. Il passaggio e' verificabile dal gateway: available_funds USDC e' passato da ~$1.400 a $2.011,09, contro $2.010,90 attesi con haircut 5% (scarto $0,19 — seconda conferma indipendente del 5%). ⚠️ Cosa ha comprato, misurato: $611 di margine utilizzabile — inutile a 0,28x di leva, serve solo sopra 1,4x che non e' autorizzata — e **+11 USDE ($11)** di capienza sul tetto. Cosa e' costato: sotto segregato l'USDE era ring-fenced dalle perdite del libro (solo il silo USDC rispondeva delle posizioni); sotto cross l'intero conto risponde. Non morde oggi (perdita massima plausibile ~$617 col disaster-SL, dentro il solo USDC), ma il rischio strutturale e' cambiato verso: se un giorno il cross non servisse piu', tornare a S:SM ri-recinta l'USDE. 📌 X:PM valutato e SCARTATO il 31/08 senza provarlo — la risposta era gia' nella pagina margini: Available Balance $1.935,14 contro $2.011,73 di X:SM (−$76,59) e margini piu' alti su entrambe le misure, MM 3,43% contro 0,37% (~9×). Il PM e' basato su scenari e premia il rischio che si compensa: due long direzionali nudi sono il suo caso peggiore, e paga lo scenario di stress invece dell'aliquota piatta. Cosa lo riapre: il deploy di VRP01 o di un altro sleeve di opzioni — allora il rischio inizia a compensarsi e il confronto cambia di segno. ✅ Confermato il 31/08 a X:SM attivo e su misure pulite: la KB da' l'USDe al 5% sotto entrambi i modelli, quindi l'haircut si cancella e l'inversa della riga CROSS da' il margine di POSIZIONE — $88,23 sotto PM contro $11,64 sotto SM, 7,6×, e 9,3× la MM. La riga X:SM era una proiezione di un modello inattivo e oggi si riproduce al centesimo ⇒ anche la riga X:PM era affidabile: decidere senza provare era corretto. 🚨 L'«IM %» della pagina margini NON e' il margine delle posizioni: e' (margin_balance − available)/margin_balance, e da noi e' 74% haircut (e' salita da 2,13% a 2,15% perche' abbiamo comprato USDE, non perche' sia salito il rischio). La MM e' pulita e ha base diversa. 📌 La pagina margini non serve piu' come schermata: la riga CROSS e' available_funds del gateway (scarto $0,01) e r0831_margini_conto.live() la ricostruisce, haircut compreso. 📌 L'equity che il book somma e' la RICCHEZZA, non la capacita' di margine — giusta per accorgersi di un'uscita di fondi (il difetto del 26/08), sbagliata se la si usasse per dire quanto margine c'e'.

📌 Dal 2026-08-26 l'equity del book somma USDC + USDE (valutato all'indice pubblico usde_usdc): il conto tiene 643 USDE (IDONEO dal 28/08; portati da 500 a 644 il 30/08 su decisione dell'operatore, quota 31,21% — e li' si e' fermato: 🚨 il venue ha un TETTO sull'USDE e ogni acquisto oltre quel livello e' rifiutato. GATE USDE-01 in §4). Autorita' dei parametri: sezione usde di config/live.json (haircut 5% — ✅ divergenza chiusa il 31/08, la config diceva 10% ed era sbagliato (r0831_margini_conto.py); oggi comunque non si applica, vedi sopra — tetto ALLERTA quota 50%, soglie depeg 0,99/0,95 coi criteri in _nota_usde), letta da src/live/usde.py — shadow (sizing orario) e usde_watch (sorveglianza 12:35 UTC, cron proprio, sotto monitor_health) derivano entrambi da li'. ⚠️ Il difetto d'origine: shadow._equity leggeva SOLO il conto USDC — la prima conversione avrebbe causato un falso "USCITA DI FONDI −24%" e vendite indesiderate. Chi aggiunge una valuta di collaterale DEVE passare da usde.py/shadow.

🚨 Una capacita' PUBBLICATA dal venue non e' una capacita' del CONTO: si verifica sul conto, prima che entri in un piano — e costa un ordine da $1. Due affermazioni di Deribit smentite dal conto in due giorni: la APR USDC 3,40% (l'Italia e' nella lista delle giurisdizioni escluse → i nostri $1.412 di USDC rendono zero) e «all Deribit users are permitted to buy and sell BUIDL» (11 ordini rifiutati, fino a 1 unita' a limite 1,0100 contro ask 1,0004 con 10.730 di profondita', tenendo zero BUIDL e $1.412 disponibili → GATE BUIDL-01 chiuso: NON ENTRABILE, costo $0, diario 2026-08-31-buidl-test-eligibilita). ⇒ L'USDE e' l'unico collaterale a rendimento che il conto puo' usare, ed e' al suo tetto: le altre tre vie sono chiuse per giurisdizione (USDC), permesso (BUIDL) e perche' non e' un dollaro (stETH 2,23%, che e' ETH: coprirlo e' CC01, gia' parcheggiato a scala ~$20k+). 📌 not_enough_funds_in_currency e' il messaggio GENERICO di Deribit per "non puoi acquisire altra di questa valuta" — permesso o tetto, mai i fondi. Chi lo incontra salti subito a questa valuta la posso acquisire, e fino a quanto? invece di inseguire taglia, cadenza e prezzo come il 30/08.

⚠️ Il nome "disaster-SL −30%" inganna: e' rotolante e simmetrico, non un massimo di perdita per trade. Su cicli a ingresso proprio lascia passare perdite oltre −30% senza scattare, e il peggior DD dall'ingresso misurato e' −60,6% BTC / −61,5% ETH. Dettaglio in 40-produzione.

📌 Soldi fermi (01-02/09): on-venue chiuso con l'elenco intero — Deribit remunera 4 valute su 50, le quattro gia' chiuse il 31/08. L'USDC sul conto non e' fermo (base di sizing + cuscino). Il fermo vero sta fuori (~€6k in XEON = lo split-cassa): le opzioni sicure valgono +€52-62/anno (BOT 12,5% / conto deposito 26%), sUSDe rende 2x ma e' lo stesso emittente dell'USDE e distrugge lo split. ✅ L'operatore ha scelto di VERSARE (piano 27/07: €5.000 dentro, ~€1.000 fuori — la protezione venue satura a qualunque quota > 0). Nessuna azione di config. In attesa di importo e data; al deposito va una riga di giornale, non ricostruita dopo. r0901d_soldi_fermi.py.

Candidati in forward-monitor (nessuno nel book): XSR01 · DVOLSPREAD · STATARB · PREVDAY.

---

2. I numeri da citare — e quelli da NON citare

Ogni numero di questo progetto va scritto con la sua lente e la sua banda. Le stime canoniche sono all'ancora fortunata; le stime oneste sono la mediana della banda d'ancora.

grandezza	❌ non citare	✅ citare
Sharpe FULL book 5-sleeve	2,222 (canonico, 97° pctl)	1,95 [1,81 – 2,12]
Sharpe HOLD-OUT book	2,364 (canonico, 99,6° pctl)	1,54 [1,11 – 1,91]
maxDD FULL book	6,07%	6,85% [5,99 – 7,94]
TP01 hold-out	0,31	~+0,05 — il valore di TP01 e' il taglio del DD ~6× vs buy&hold, non il ritorno
XS01 standalone	1,50 / 1,71 / DD 11%	ensemble di fase 1,25 / 1,31 / 10,9%; maxDD fuori campione 21%
SKH01	i numeri di ammissione	de-luckato e' il meno affidabile dei cinque (l'ancora regala 2/3 del FULL)
VRP01	f = 1,00	f = 0,73 misurato sulle quote reali (IC95 [0,698; 0,780])
muro capitale-rendita	$272k (lordo)	$313k al netto di fisco e funding — banda [$187k – $1,14M]
P(≥50 €/g), canale funded, 36 mesi	42%	2,6% [1,5 – 4,7], P(zero) 40,3%
XSR01	Sharpe 1,82 (e' una terza lente, divisore fisso 50)	1,79 alla scoperta / 1,56-1,63 a oggi — lente dei gate, sole barre chiuse. Citare sempre la coppia (lente, ultima barra chiusa)
soffitto direzionale BTC/ETH	~1,3	~1,15 col funding dentro
performance del libro LIVE	«+243%» di equity (e' 96,3% un bonifico)	TWR +10,61% spezzato sul versamento — +11,61% fino al 25/08, −0,89% dopo (02/09 14:02Z). Dal 02/09 lo stampa trades_db.py --report (debito 14 chiuso)

📌 Il libro a k=1 rende MENO dell'S&P 500 (15,19% contro 17,40%, stessa finestra): il vantaggio sta nello Sharpe (1,35 vs 0,89), e senza leva non si converte in rendimento. A iso-rischio farebbe +9,0 punti sopra l'indice; a k=1,40 (max difendibile) +3,9 con meno vol. ⇒ senza leva il libro non si giustifica come veicolo di ACCUMULO, si giustifica come veicolo di RENDITA — dove serve 2,5× meno capitale ($254k contro $646k) perche' la perpetua vive sul drawdown (misura 2026-08-25, r0825_piano_10a_500.py). E tutta la leva autorizzabile vale quanto €100-150/mese: k=1,25 (+15,6% a 10 anni) vale meno di €100/mese in piu' (+19,1%).

📌 L'equivalenza che ordina il piano: €100/mese in piu' == +4,07%/anno di drift (+27% su tutto il drift del libro). A 10 anni i bonifici fanno il 59% del risultato.

📌 Il libro e' FLAT il 28,0% dei giorni sull'intera storia (2,7% nel 2021, 77,0% nel 2022, 75,6% nel 2026); live, esposto 14 giorni su 64, leva lorda mediana 0,00x e max 0,52x su un tetto di 1,0x. Il cap non ha mai morso: il vincolo e' il segnale. Riempire quel vuoto con l'ETF e' stato misurato e SCARTATO il 25/08 (20-ondate).

🚨 Tre baseline diverse girano sotto lo stesso nome "libro 75/25", e lo spread fra loro (0,12 di Sharpe, 1,7pp di maxDD) e' piu' grande di quasi tutti gli effetti che il progetto misura: hourly 1,683 / 11,22% (la lente di ogni muro e ogni traiettoria) · canonical 1,800 / 9,56% · mediana d'ancora 1,626 / 10,4%. Un Δ accostato al baseline sbagliato cambia piu' del Δ stesso.

🚨 «Positivo in N/N ancore» NON e' N osservazioni. Correlazione 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 (N_eff 1,64-2,24). La banda d'ancora e' ~4× piu' stretta dell'IC95 bootstrap, che CONTIENE LO ZERO. Si cita come robustezza alla scelta dell'ancora (~2 osservazioni), mai come N prove, mai come intervallo di confidenza, e mai con un p-value attaccato a un conteggio di ancore. Cade la precisione dei numeri, non la direzione delle decisioni.

🚨 Il funding dei perpetual non e' modellato in NESSUN backtest (verificato: zero occorrenze in harness.py, trend_portfolio.py, sleeves.py, portfolio.py, src/live/). Costo misurato: −2,16%/anno di drift (2019-2026), −1,39% sulla finestra dello strumento vero, −0,55% sul 2025+. Esposizione e funding sono positivamente correlati → il prodotto ingenuo esposizione media × tasso medio sottostima di ~2×. E' una tassa sul drift, quindi colpisce i muri molto piu' dello Sharpe.

---

3. Decisioni vincolanti dell'operatore

Prese con l'informazione completa, non sviste da correggere. Se qualcuno le ripropone "come da CLAUDE.md", la risposta e' la colonna cosa la riapre.

decisione	data	non si ri-discute	cosa la riapre
100% Deribit fino a $20k — accettato P(perso tutto) 10/18/34/64% a p=0,5/1/2/5% invece di 0/0/4/27%	26/07	la soglia $3k	$20k, o un cambio di piano, o p che diventa stimabile invece che assunto
SOL escluso — universo direzionale resta BTC/ETH (presidiato da un test)	22/08	SOL su un book a 2 gambe con questi dati	~3 anni di storia SOL certificata (non prima del 2028), o un meccanismo che non sia TP01/SKH01 congelati
Niente short-vol da modello in deploy — e niente long-vol scalp da modello	19/06	—	un f di stress reale misurato su un crash catturato
Non de-esporre il weekend (porta il 38% del gross di TP01 nel 31% del tempo)	17/07	—	ogni proposta "risk-off weekend" parte REFUTED salvo null de-levering superato
Peso 75/25 confermato 3 volte (24/07, 26/07, 24/07-follow-up)	26/07	—	weights_tilt_null superato, che finora fallisce
Fee Deribit: ≤5 bps/lato → non si tocca nulla; >10 bps → rivedere il peso SKH01 (regola decisa prima di vedere il numero)	26/07	—	il sorvegliante fee_watch allerta da solo
GTAA01: decisione tenere/bloccare RINVIATA a $15k di book — sotto quella soglia lo sleeve non e' deployabile (GTAA_MIN_CAPITAL $3.000 allocati al peso 20%), quindi finora e' manutenzione senza beneficio incassabile. Contributo misurato a iso-rischio +0,095 / +0,124 di Sharpe secondo la fase: reale e sempre positivo, e delle stesse dimensioni dello spread fra le baseline (0,12)	28/08	«GTAA01 non contribuisce» — la misura dice il contrario	il book a $15k, che il giornale sorveglia da solo (journal.SOGLIE_CAPITALE)
Gradino di leva NON autorizzato oggi. 1,25x autorizzabile a condizione; 1,50x BOCCIATO (peggior giorno strutturale 21,48% > 20%); k max difendibile 1,40	23/08	il 1,50x	✅ la chiave di scala e' costruita (01/09, inerte a 1,00): restano GATE SCALA-01 (§4) e il rifacimento di r0726_fee_sensitivity al nuovo lordo — la sua conclusione "liquidation fee 1% irrilevante" era condizionata a lordo ≤1x, a 1,25x costerebbe 1,25%

✅ La chiave di scala ESISTE dal 2026-09-01 (era il debito che rendeva la regola "ogni cambio di scala passa dal cap di config" non implementabile). book_scale_k, letta da src/live/book._scala e applicata DOPO il clamp in book_net_target — l'ordine non e' di comodo: applicandola PRIMA il cap se la mangerebbe proprio nei giorni di massima convinzione (k_eff tornerebbe a 1,00 a ogni k), cioe' sarebbe un cambio di FORMA travestito da cambio di taglia, che la curva g(k) con cui il gradino viene autorizzato non descrive. 🚨 La chiave e' INERTE: assente = 1,00 = il libro di sempre, bit-exact (T7, max|diff| = 0.0) — config/live.json non e' stato toccato. Guardie: LEVA_LORDA_MAX 1,25 e SCALA_LADDER (1,00 · 1,25) sono costanti di CODICE, non di config (un tetto nello stesso file della chiave sarebbe un lucchetto con la chiave attaccata: il gradino a 1,50 richiede una modifica di codice, quindi una review); il tetto e' sul PRODOTTO n_asset · frac · scala e l'invariante del disaster-SL e' n_asset · frac · scala · disaster_sl_pct ≤ 0,50 (la guardia che morde per prima: da' scala ≤ 1,67x e scatta se qualcuno allarga lo stop — 🚨 e disaster_sl_pct NON si sostituisce con la distanza di un pavimento di put: darebbe 2,28x sulla carta, ma la put limita UNA finestra e i drawdown di BTC sono grind di 290-818 giorni, su 8 finestre −33,6% → 77% dell'equity a 2,28x. Misurato in §72, scritto qui prima che sia comodo); una scala fuori scaletta o fuori tetto NON viene tagliata — book_execute si ferma, non invia e allerta (ScalaNonAutorizzata); e la scala vive solo sul percorso fidato (equity reale illeggibile ⇒ 1,00, cosi' "il fallback non e' piu' permissivo" e' vero per costruzione). Sorvegliante src/live/scale_watch.py (giornaliero in cron_daily, 3 domande / 3 azioni / 3 stati, una allerta per streak, marcatore scritto solo dopo invio riuscito), giornale append-only data/live/scale_history.jsonl. Test T1-T11 in tests/test_book_scale.py (18, tutti verdi). 📌 Cio' che il sorvegliante NON puo' fare: impedire la modifica — la rende visibile entro 24h e attribuibile. Come venue_watch: non protegge il saldo, compra tempo.

---

4. Gate pre-registrati — con la loro data

Un gate si decide alla data, coi criteri scritti prima. Anticiparlo e' selezione sull'hold-out; cambiarne le soglie guardando l'esito, pure.

gate	data	criterio	stato
USDE-01 (eligibilita' reward)	2026-08-29	≥1 reward entro il 29/08 → IDONEO e si apre la decisione di QUOTA (dell'operatore; tetto allerta 50%, mai 100% — R1 emittente non recuperabile); zero → si riconverte e la pista si chiude	✅ CHIUSO IDONEO il 2026-08-28 12:35Z: primo reward +0,052055 USDE rilevato per delta al netto dei trade, coi criteri pre-registrati il 26/08 PRIMA dell'esito. QUOTA DECISA il 30/08 (l'operatore ha anticipato il rinvio: "porta in usde tutto il capitale che non viene usato"): bersaglio 70%, usde.quota_target in config. Tasso a 4 finestre (30/08): 3,26% annuo, banda bootstrap [1,13% – 4,51%] — 3/4 hanno pagato (0,00 · 3,80 · 4,51 · 4,51%), e la banda larga 3,4 punti e' il risultato: a n=4 il tasso non e' misurato. usde_watch.rendimento() lo stampa col suo n; quota_da_decidere() lo chiede ogni giorno da lunedi'. 🚨 L'EV non puo' scegliere la quota — e' lineare in q, quindi il suo argmax e' sempre un angolo (0% o 100%): ogni quota interna nasce da un criterio sulla coda, dichiarato non ottimizzato (M8). Il resto e' misurato (r0830_usde_quota.py, diario 30/08): hazard di pareggio = l'APR (EV-positiva sse Ethena sta sotto il 3,3%/anno, numero assunto come il p di Deribit) · l'haircut non morde a nessuna quota fino al 90%, nemmeno a leva 1,50x con USDE marcato a 0,95 (29× di cuscino): il vincolo non e' il margine · la resa di oggi vale $16/anno, meno di UN mese di versamento ⇒ la leva binding resta il bonifico · gia' a 24,2% l'evento emittente vale 3,1× il maxDD dell'intero libro. 📌 Aspettare costa $1,33: alzare a 50% fra 4 settimane invece che subito lascia sul tavolo $1,33 di resa (conversione reversibile a ~6 bps) e porta il campione da 4 a 32 finestre, stringendo la banda 2,8×. 🚨 DUE FATTI DEL 30/08 CHE CAMBIANO IL GATE (diario 2026-08-30-usde-quota-tetto-venue). (a) TETTO DEL VENUE ≈31-32% dell'equity — e' una FRAZIONE, non un livello. Ogni acquisto oltre il tetto e' rifiutato con not_enough_funds_in_currency pur avendo $1.400 disponibili: messaggio fuorviante, che ha fatto inseguire tre ipotesi sbagliate (taglia, cadenza, prezzo). Che sia un tetto e non un problema d'ordine e' provato a saldo neutro (BUY rifiutato → SELL OK → BUY riaccettato → BUY rifiutato); che sia una frazione e' provato il 31/08 lasciando scendere l'equity di $8: il tetto e' sceso con lei — 30/08 in [644,18·645,18) con equity $2.063,79 = 31,21-31,26%, 31/08 in [643,18·644,18) con equity $2.055,56 = 31,29-31,34% (0,05pp di scarto, dentro il rumore dell'equity che oscilla ±$2-8/ora). ⚠️ Ri-sondato il 31/08 dopo il passaggio a X:SM (l'ipotesi era che il tetto dipendesse dal modello segregato): [654,18-655,18) con equity $2.054,90 = 31,84-31,88%. Il modello ENTRA nel tetto ma non lo spiega — ha comprato **+0,55pp = +11 USDE ($11), non le centinaia che servirebbero. ⇒ il tetto SCALA col conto: la quota resta 31% e il valore in dollari cresce col capitale, ma il 70% non e' raggiungibile ne' ora ne' mai. 🚨 Deribit non lo documenta: l'articolo ufficiale Yield/reward bearing coins descrive un Cap ETHENA che diluisce il TASSO a livello di exchange (User APR = min(bal_exchange, cap)/bal_exchange × Ethena APR) e nessun limite sulle quantita' detenibili da un conto. Ora e' in config (usde.venue_cap_frac 0.312, bordo basso dei bracket) e usde_convert rifiuta il piano prima di sparare invece di scoprirlo dal venue. (b) L'USDC NON frutta SUL NOSTRO CONTO — misurato, e la premessa del gate e' RESTAURATA. public/get_currencies dice USDC 3,4000% (USDE 4,1071%) e per qualche ora quel numero e' stato scritto qui come se fosse nostro: era un listino del venue, non un accredito. Deribit paga i reward USDC una volta al MESE («paid out as a single monthly payment early in the following month», accrual 00:00 UTC sulla minima equity) — non ogni giorno come l'USDE, ed e' per questo che una sorveglianza giornaliera non poteva vederli. Verificato sui due confini di mese a libro FLAT, dove equity == balance == USDC e ogni scalino sarebbe un accredito: 29/06→08/07 equity 598,06 costante, 237/237 ore ferme, 0 scalini (attesi $0,45) e 31/07→03/08 equity 596,92 costante per 4 giorni (attesi $1,72 contro una risoluzione di $0,01, 172×). Zero misurato, non zero sotto soglia. ⇒ il guadagno di tenere USDE e' il tasso pieno ~4,1%, non uno spread: **$26/anno sui $644. 🚨 Il motivo ora e' DOCUMENTATO, e non e' MiCA come avevo ipotizzato: l'articolo ufficiale elenca le giurisdizioni escluse dai reward USDC e l'ITALIA c'e' (con Canada e Giappone: non e' una lista MiCA, e' policy di giurisdizione Deribit). ⚠️ E la finestra di pagamento e' piu' larga di quella che avevo controllato: «within the first two weeks of the following month». Rifatta la verifica sulle due settimane vere: luglio e' conclusivo (atteso $1,72 contro un'escursione TOTALE dell'equity di $0,48 in 1-16/08, zero scalini compatibili), giugno NO (il libro ha iniziato a operare a meta' mese e il rumore e' della taglia del segnale). Quindi: una finestra conclusiva piu' la lista ufficiale, non due finestre — il «172× la risoluzione» del 30/08 era sovra-affermato. 📌 Un tasso pubblicato non e' un tasso incassato: si verifica sul CONTO — ed e' costato una query su una serie che avevamo gia'. Strumento: scripts/live/balance_watch.py + cron_balance.sh (orario :42, sola lettura) registra il balance a 8 decimali, la serie che mancava. 📌 Il vincolo che l'analisi del margine non aveva guardato: P&L e funding dei perp USDC-lineari si regolano in USDC, quindi la quota massima difendibile non e' data dall'haircut ma dal cuscino di regolamento = disaster-SL sulla massima esposizione lorda (n_asset × frac × disaster_sl_pct = 30% dell'equity), che lascia esattamente il 70% — coincidenza per costruzione, zero slack (M8: non e' un argmax). 📌 Il costo del NON averlo e' ora documentato e vale il criterio: un'equity negativa in una valuta paga una collateral fee dello 0,05% AL GIORNO — 18,25%/anno, addebitata al secondo, 4,3× la resa USDE che si starebbe comprando (fonte: KB Cross collateral specifications). Il ribilanciamento automatico NON salva: scatta solo a $1M assoluti o al 100% della cross equity, soglie che a $2k non si toccano mai — si sanguina la fee e basta. Il 30/08 avevo scritto «Deribit lo finanzia a interesse» senza il numero: il numero e' questo, e rende il cuscino piu' giustificato, non meno. Attrezzo: scripts/live/usde_convert.py (dry-run di default, guardie proprie; NON passa da execution.ALLOWED, che resta ai soli due perp)
STATARB	2026-09-27	soglie 24/07 (non toccate) + diagnostica statica sempre-short	✅ monitor riparato e rigenerato il 26/08: la serie vera da' Sharpe −1,61 a oggi → coi criteri invariati punta al RITIRO. Si legge il 27/09, non prima
XSR01	2026-10-23	Sharpe ≥1,0 E haircut ≤40% — dal 26/08 il numero decisivo e' r0826_xsr_haircut.py a pavimento $10, citato con la frazione di ordini eseguiti — poi weights_tilt_null e capitale ≥$20k	✅ riscritto il 26/08 su decisione dell'operatore (dichiarato prima dell'esito, stringe: diario 2026-08-26-xsr01-gate-riscritto): capitale allineato a "100% Deribit fino a $20k"; serie forward rigenerata (31 barre vere, Sharpe −2,72). Sotto la lente RENDITA il sleeve resta eguagliato da un conto remunerato (📌 sotto)
DVOLSPREAD	kill 2026-10-24 se Sh<−0,50; decisione 2027-01-24	(a) Sharpe>0 (b) marginale ADDS+robust_oos+insample_edge (c) DSR ≥0,95 (d) weights_tilt_null; veto se barre attive <80% → si estende, non si decide	✅ serie rigenerata il 26/08 (−4,41 a oggi, era −14,73 sulla serie rotta); il veto barre-attive ora conta barre VERE e la guardia PREMATURO sorveglia il monitor
GATE PROP-01	chiuso 22-23/08	(a) listino 13/13 ✅ (b) ancora SKH01 23/23 ✅ (c) economica+sopravvivenza 2/2 ✅	chiuso 3/3 — ma il numero operativo e' sceso 42% → 7,8% → 4,4% → 2,6%
GATE PREVDAY-01	scritto 23/08	10 condizioni	8/10: la cella che GIRA non e' quella che la selezione onesta sceglie, e quella viva fallisce il DSR (0,905)
GATE SCALA-01 (portare book_scale_k da 1,00 a 1,25)	non prima del 2026-10-01	9 condizioni tutte necessarie (SPEC-scale-key §6.2): A1 gradino di SCALA_LADDER · A2 k0 in produzione ≥180g col criterio passato ogni giorno · A3 C1-C5 di WORST-DAY ricalcolati OGGI, non ereditati · A4 invariante disaster-SL · A5 tetto sul prodotto · A6 ANTI-RECENCY (il criterio deve passare anche escludendo gli ultimi 90 giorni) · A7 r0726_fee_sensitivity rifatto · A8 la modifica e' una riga di config + una di giornale, zero codice · A9 T1-T11 verdi	◐ A8/A9 FATTI il 01/09 (chiave inerte + 18 test); A2 non maturo — la specifica impone ≥30 giorni a 1,00 col sorvegliante attivo prima di eseguire il gate: «l'unico modo di scoprire che il sorvegliante e' rotto mentre la leva e' ancora 1,00». 📌 A6 oggi NON morde (k ammesso ~3,5x contro un gradino di 1,25x): il vincolo che morde e' il disaster-SL. E' scritto ora perche' non e' comodo per nessuno, non quando servira'
edge_watch (kill del book live)	continuo	(A) Sharpe rolling 36m < −0,5 → si riapre weights_tilt_null+DSR, il book non si spegne da solo; (B) in un anno con DD buy&hold >10%, il DD di TP01 deve restare <75% di quello	stato 27/07: Sharpe 36m +1,51, protezione 8/8

📌 XSR01 sotto la lente RENDITA (25/08): il meccanismo vale ~0. Mescolarne i rendimenti da' lo stesso muro ($476-484k contro $478,7k), e un conto remunerato allo stesso tasso (3,72%, vol 0, corr 0, nessun secondo venue) da' $477,6k — identico dentro la risoluzione MC, e meglio al 4,0%. Cio' che si compra e' un drift scorrelato, non la scorrelazione (a drift zero il muro SALE). E l'haircut lo mangia: non pareggia un conto al 4% nemmeno a haircut ZERO; pareggia il 2% solo sotto il 46%. Per un 25% sopra il C* vero servono $60.000 di conto. r0825_xsr_rendita.py.

📌 Un gate superato non e' un numero confermato: differenze e livelli ereditano la fortuna d'ancora in modo diverso (nella differenza si cancella in parte, nel livello per niente).

---

5. Debiti aperti — difetti noti NON riparati

1. ✅ RIPARATO E RIGENERATO (2026-08-26). advance() consumava la barra del giorno in corso: ora tutti e 6 i monitor filtrano con src/live/paper_guard.nuove_chiuse (barra chiusa = ts + cadenza ≤ adesso), le 4 serie rotte sono rigenerate dallo stesso start_ts (scripts/live/paper_regen.py, vecchi file in *.pre_regen_20260826.*): statarb +1,95 → −1,61, dvolspread −14,73 → −4,41, xsr −4,98 → −2,72, prevday +0,39 → +0,40. Nessuna data di gate si sposta. La guardia e' cablata: monitor_health stato PREMATURO (ultima barra che chiude dopo l'mtime, grazia 5 min; open_labeled=False per collect_chain). paper_portfolio NON rigenerato (GTAA su ADJUSTED_LAST: replay ≠ serie registrata, P12) — storia pre-fix dichiarata corrotta, coda non chiusa tolta. ⚠️ Nel fix, D6 pagata di nuovo: asi8 in pandas 3 e' in us, non ns — blindato con test su tre risoluzioni.
2. ✅ RISOLTO (2026-08-28, decisione dell'operatore). Il trasporto degli allarmi era un punto singolo di guasto — 6,9% di invii falliti (2/29) e alerted=True marcato prima dell'invio, quindi un 🚨 perso era perso per l'episodio intero (200-2.324 ore). Ora venue_watch.run_once riceve il sender iniettato e il marcatore «gia' detto» si scrive solo dopo un invio riuscito; su fallimento si disfano i soli marcatori — non le misure — e per il lock le ore continuano a correre, cosi' una manutenzione che sfora la grazia sale ad ALERT anche col trasporto giu'. notify() accetta tentativi (venue_watch: 3) e l'esito finisce nel log. ⚠️ Resta scoperto ogni altro chiamante di notify(): la disciplina «commit dopo l'invio» e' oggi solo in venue_watch.
3. ✅ RISOLTO (2026-08-26, decisione dell'operatore: opzione "riscrivere adesso"). Gate XSR01 riscritto in modo dichiarato, prima dell'esito, in direzione che stringe: capitale $5k → $20k (riconcilia con la decisione 26/07, che e' posteriore e governa), gamba haircut letta da r0826_xsr_haircut.py a pavimento $10 con la frazione di ordini eseguiti accanto (misurata: haircut FULL −1,1% con 22% di eseguiti — la guardia da sola era vacua), soglie numeriche INVARIATE. Diario 2026-08-26-xsr01-gate-riscritto.md.
4. ◐ (a) RISPOSTA TROVATA ALLA FONTE (2026-08-28), (b) resta aperta. Non sono pareri fiscali. (a) I derivati stanno in c-quater → 26%, non in c-sexies → 33%. Circolare AdE 30/E del 27/10/2023, §2.3.2 e §3, verbatim: «In generale, i redditi derivanti da contratti derivati, ancorche' aventi come sottostante cripto-attivita', costituiscono redditi diversi ai sensi dell'articolo 67, comma 1, lettera c-quater)» e «qualora le cripto-attivita' costituiscano il sottostante di un contratto derivato (ad es. contract for difference o future) i redditi derivanti da tali strumenti finanziari costituiscono redditi diversi ai sensi dell'articolo c-quater)». La circolare conferma esplicitamente che la riforma 2023 non sposta nulla: «tali contratti non rientrano nell'ambito di applicazione della lettera c-sexies». ⚠️ Conseguenza: le minusvalenze su derivati NON si compensano con le plusvalenze cripto (categorie diverse) e non c'e' franchigia. Il collaterale sconta il 2‰: Deribit non e' intermediario residente, quindi non applica il bollo e scatta l'imposta sul valore delle cripto-attivita' sul valore al 31/12, in RW (a $2.068 fa ~$4/anno: obbligo dichiarativo, non un costo). 📌 E la conversione USDC→USDE non e' fattispecie realizzativa — §3.1: «dal 1° gennaio 2023 non costituisce fattispecie realizzativa lo scambio di una cripto-valuta con un'altra», col valore di carico che si trasferisce. Resta da chiedere: se il perpetual inverse regolato in cripto sia il caso letterale della circolare (che nomina CFD e future) o serva un passaggio in piu'. (b) I payout di una prop firm: ancora aperta. Le fonti convergono su lavoro autonomo (partita IVA, ATECO, forfettario 5% per i primi 5 anni poi 15%, imponibile da coefficiente di redditivita'), non redditi diversi al 26%. Nessuna prassi ufficiale, e il coefficiente esatto dipende dal codice ATECO.
5. ✅ FATTO (2026-08-26): test_leva_massima_da_config... cancellato con nota in tests/test_fee_sensitivity.py — misurava frac · n_asset, con una chiave di scala avrebbe continuato a passare smettendo di controllare. ✅ CHIUSO il 2026-09-01: la chiave esiste e la sostituzione e' cablata — T2 (tetto sul PRODOTTO n_asset · frac · scala ≤ LEVA_LORDA_MAX) e T3 (invariante disaster-SL) in tests/test_book_scale.py, che importano i bersagli da src.live.book invece di ridichiararli (P1). Il vecchio test resta cancellato, non rilassato, e T11 lo verifica.
6. ⚠️ TLT ha 13,5 anni di storia in meno (parte 2016-02 invece del 2002) → GTAA01 gira su CINQUE gambe prima del 2016, e l'assente e' quella obbligazionaria. Non e' un fetch da rifare (IB ritorna 0 barre). ⇒ in-sample e hold-out di GTAA01 non sono la stessa strategia.
7. ✅ RIPARATO (2026-09-02). Il docstring di book_execute.py prescriveva "ogni ~230 minuti" mentre il cron gira ogni ora (47 * * * *): era il docstring a essere sbagliato, e chi lo avesse "corretto" nel verso del cron avrebbe spostato il libro sulla riga 4h, dove BTC raddoppia gli scatti del disaster-SL (r0823_sl_anchor.py). Ora il docstring dichiara CADENZA: ORARIA con la ragione (giro idempotente: latenza SKH01 ≤1h; il rotolante e' controllato ogni ora e ri-ancorato solo oltre la tolleranza di ensure_disaster_sl, mark +5,263%/−4,762% o taglia >10% — «si ri-ancora ogni ora» era una frase sbagliata, corretta in revisione il 02/09) e il divieto esplicito. tests/test_book_cadenza.py (10 test) tiene d'accordo le tre dichiarazioni — docstring, riga in cron_book.sh, crontab installata (letta con crontab -l; dove non e' leggibile il test si dichiara SALTATO, non verde) — e verifica che la cadenza dichiarata sia 60 min, sotto la griglia 230m e lontana dai 240 della riga peggiore. Diario 2026-09-02b-debito-7-cadenza-docstring.md.
8. ⚠️ Il Rulebook Deribit (ADL, perdita socializzata, emergency powers, conti dormienti) non lo sorveglia nessuno; MAINT_GRACE_HOURS=2 presume gli annunci invece di leggerli. ✅ Ridotto in parte il 2026-08-25: src/live/venue_probe.py interroga l'API pubblica Deribit e distingue manutenzione / venue giu' / NOSTRO gateway / non vedo, e lo slot di release (martedi' 09:00 UTC) e' ora una costante dichiarata e testata. Resta scoperto il Rulebook vero e proprio: la sonda legge se il venue risponde, non cosa il venue annuncia.
9. ✅ INDAGATO E RIPARATO (2026-08-26, r0826_skh_band_drift.py). Il dato regge (taglio al 02/07 riproduce l'audit: 1,6376; in-sample 1,424 identico su ogni taglio); la deriva era la finestra hold-out che si allunga — e 📌 la SOLA settimana 15-22/08 vale +0,35 di Sharpe hold-out (rally ETH con SKH01 long): il numero e' fragile, coerente con §2. Il test ora taglia il feed al 02/07 e verifica la riproduzione stretta (±0,02): si rompe solo se cambiano codice o dato sulla finestra congelata. Suite: 775 passati, 0 falliti (26/08).
10. ⚠️ Nessuna tabella pubblicata prima del 22/08 contiene fisco E funding insieme. L'unica congiunta e' quella in 30-piano-capitale-fisco.md — le altre vanno lette con lo sconto.
11. 🚨 Le credenziali Deribit esistono SOLO dentro il gateway (cerbero-mcp): in locale c'e' solo CERBERO_TOKEN. Quindi il gateway e' un punto singolo di guasto non aggirabile — 4 dei 5 traceback in 63 giorni sono suoi (404 su get_positions, 502, due ReadTimeout), ed e' l'unico pezzo della catena che possediamo. Un fallback diretto ai privati Deribit (conto/posizioni/ordini) richiede chiavi API create dall'operatore sul conto Deribit: e' una decisione, non un refactor. Fatto intanto il pezzo che non le richiede: la sonda pubblica, che almeno dice di chi e' il guasto.
12. ⚠️ Un test scriveva nel watermark VIVO (data/live/equity_seen.json): lanciare la suite ci metteva $5.000 e il giro successivo del book mandava un allarme falso "USCITA DI FONDI −86,6%". Non era cosmetico: cap_fallback = min(cap_config, watermark × frac) sarebbe passato da $334 a $2.500/asset — ~7,5x di leva su un conto da $668, per giunta sul ramo eq_fallback che allerta e NON blocca. ✅ Riparato il 2026-08-25 con una fixture autouse in tests/conftest.py (strutturale: non si chiede a ogni autore di ricordarsene — quella scommessa ha gia' perso il 26/07 e il 21/08) + guardia in test_cap_watermark.py. ✅ Esteso il 2026-08-26: deviati anche trades.db (wrapper su connect — il default e' catturato alla definizione, patchare la costante non bastava) e docs/journal/; per book_executions.jsonl (caricato ad-hoc via importlib, irraggiungibile da conftest) impronta a inizio suite e verifica a fine suite, col falso positivo possibile (fill reale del cron :47) dichiarato nel messaggio.
13. ⚠️ GTAA01 gira su una finestra che ROTOLA, e la fase di ribilanciamento cambia da sola ogni notte (misurato 2026-08-28, r0828_gtaa_band_phase.py). IB serve una finestra di 30 anni e SPY e' al muro: la sua prima barra avanza di un giorno di borsa ogni notte (1996-07-02 il 24/06 → 1996-09-04 il 28/08). gtaa._gated_returns ribilancia su i % every == 0, cioe' sulla posizione nell'array: se la prima barra scivola si ri-fasa ogni decisione di trent'anni. Effetto misurato: su una finestra chiusa (pre-2015) lo Sharpe si e' mosso fino a 0,076 a codice fermo, e la banda scelta al buio cambia fra 25% / 40% / 60% da una notte all'altra. Ha gia' ucciso due criteri del gate (A) (07/08 e 28/08). Quantificato e innocuo OGGI (D5): a livello di portafoglio l'escursione sulle 5 fasi vale 0,029 di Sharpe, dentro la banda dichiarata [1,81-2,12]. QQQ e IWM arriveranno allo stesso muro fra 2,5 e 3,7 anni. Riparazione (ancorare la fase al calendario) rinviata con la decisione su GTAA01: cambierebbe tutti i numeri registrati dello sleeve.
14. ✅ RIPARATO (2026-09-02). trades_db.py --report stampava e1/e0-1 sulla serie grezza — «+243%», per il 96,3% un bonifico (il versamento di $1.399,39 del 25/08 11:47Z; misurato il 01/09, diario 2026-09-01-stato-trades.md). La riparazione esisteva gia' nel giornale (journal.movimenti_capitale) e non aveva attraversato il confine fra i due lettori della stessa serie — variante di P1. Ora journal.rendimento_twr e' la funzione che entrambi chiamano: spezza la serie sui movimenti CERTI (gli ambigui restano dentro, dichiarati) e il report stampa TWR +10,61% = +11,61% × −0,89%, trading da arming +$50,95, i movimenti elencati, e il delta $ grezzo etichettato «movimenti INCLUSI» — il % grezzo non compare piu'. Test: 5 in test_journal.py (fra cui la riproduzione del +10,80% del diario 01/09, M23) + 2 in test_trades_report.py sul testo stampato, con connect() deviato in tmp. Diario 2026-09-02-debito-14-report-twr.md. ⚠️ Due limiti dichiarati dalla revisione del 02/09 (D5): (a) l'intervallo che contiene un movimento certo esce INTERO dal rendimento — il suo P&L di mercato finisce in certi e fuori da trading, con errore massimo pari a META' del movimento riconosciuto per costruzione del classificatore (il 25/08: ~$0,5 su $1.399); non si stima, si dichiara (P12); (b) a base di equity zero twr E trading sono None: il salto 0→X del primo versamento e' invisibile al classificatore e trading varrebbe l'intero conto. ⚠️ Limite ereditato (D5): un +10% di trading fra due letture consecutive tocca la soglia del rilevatore e, a mercato fermo, verrebbe classificato «movimento» — e' lo stesso limite del rilevatore live, non un difetto nuovo.

---

6. Le regole di prim'ordine

Estratte dai 69 filoni. Ognuna e' stata pagata almeno una volta. Testo completo e caso d'origine nei file di memoria.

Sul dato

• D1 La verita' e' Deribit mainnet; Binance/Coinbase solo come audit indipendente, mai come ancora per "ripulire".
• D2 Una riga presente non e' un dato presente, e una barra presente non e' una giornata presente: contare cio' che e' quotato/chiuso, non cio' che e' scritto.
• D3 Una certificazione che guarda solo dentro la serie non vede cio' che la serie ha perso (split 2:1, contaminazione EUR/USD, troncatura: tutte passano integrita', gap, spike, duplicati).
• D4 Ogni soglia di certificazione tarata su un valore tondo va controllata contro il difetto che genera esattamente quel valore (una soglia al 50% non puo' sorvegliare gli split 2:1).
• D5 Quando un buco non si puo' chiudere senza generare falsi positivi, si misura il danno del caso non rilevato: un buco quantificato e innocuo e' un risultato, uno taciuto e' un debito.
• D6 Due serie dello stesso progetto possono avere convenzioni di etichettatura diverse: verificare col lag, non fidarsi dell'indice. DatetimeIndex.view/astype("int64") su risoluzioni miste produce look-ahead senza eccezioni e senza NaN.
• D7 Un guasto in corso si misura al giorno peggiore, non in media. E prima di cancellare una sorgente si verifica che la copia sia completa, non che esista.

Sul metodo

• M1 Una strategia direzionale si giudica su earns_slot (Sharpe marginale vs TP01), mai sullo Sharpe assoluto: gli overlay-su-TSMOM ereditano lo Sharpe del trend.
• M2 Una famiglia grid-searched si giudica con study_family_honest (cella scelta in-sample-only + deflated-Sharpe ≥0,95), mai chiamando lo scorer sulla cella a max hold-out.
• M3 🚨 Non basta contare i trial: serve la VARIANZA di screen — e la stessa griglia da' verdetti opposti a seconda di come la si partiziona. La partizione e' un secondo posto dove barare e' indolore e invisibile: dichiararla prima, contare al rialzo, e pubblicare la sensibilita' del verdetto al conteggio.
• M4 Quando si riapre un parametro si riapre la sua famiglia.
• M5 Null del de-levering (7 occorrenze): ogni claim "meno drawdown" si testa a iso-rischio prima di crederci — e' il primo test, non l'ultimo. Se la variante e' una pura ri-scalatura il null e' degenere (sh(k·base) ≡ sh(base)): serve iso-peso sullo Sharpe.
• M6 Un diversificatore a basso CAGR si giudica a iso-rischio, mai a iso-nozionale.
• M7 Su offset/ancore appaiate la statistica e' la mediana delle differenze, non la differenza delle mediane. E se si de-lucka una strategia va de-luckato anche il suo DEGRADO.
• M8 Un argmax dentro un plateau non e' una decisione; e la mediana da sola puo' nascondere il fatto decisivo (p90 su, p10 giu' = si compra dipendenza dall'ancora, non Sharpe). E un argmax sul BORDO della griglia non e' una cella: e' una pendenza — si segue fino al suo limite prima di leggerne il valore, perche' il limite puo' essere un oggetto diverso da quello che si stava studiando (COLLAR01: le 3 celle vincenti su 48 stavano tutte sul bordo, e il limite era una covered call, cioe' fuori dalla domanda posta).
• M9 Un contributo positivo si scompone per anno prima di crederci: "24/24 ancore positive" puo' essere un anno solo.
• M10 Due punti non fanno una tendenza nemmeno quando la meccanica sembra spiegarla.
• M11 Un blocco dichiarato e' un'ipotesi, non un fatto: si ri-verifica prima di costruirci sopra o di rimandare (3 occorrenze, ogni volta il blocco non esisteva).
• M12 Un follow-up dichiarato contiene una previsione, che va misurata non assunta.
• M13 Un criterio si misura sulla sua risoluzione prima che sul suo esito, e un gate si valida contando quante volte lo passa un candidato a caso.
• M14 Un null di permutazione va confrontato a fee zero (permutare un segnale ne fa esplodere il turnover: il null perderebbe per costo invece che per assenza di informazione) e controllato per bilanciamento del segno.
• M15 Un rilevatore tarato per non segnalare va validato su un controllo positivo — e un controllo positivo finito dentro un ramo else non gira mai.
• M16 Un self-check su eventi rari si campiona sugli eventi, non sulla popolazione (altrimenti confronta zeri con zeri: potenza zero).
• M17 Il win rate di uno schema parziale+BE non e' merito (≈ 1/(1+rr1)): convertire ogni claim "WR X%" in expectancy R netto fee.
• M18 Vs claim su livelli "speciali" (Fibonacci, max-pain, expiry) il test e' il null location-matched; vs claim di calendario, il day-boundary robustness.
• M19 Mettere nella griglia una variabile che si sa gia' morta trasforma "il candidato perde" in "il dato non contiene nient'altro di selezionabile" — l'unica forma in cui un inventario conclude qualcosa su un'assenza.
• M20 Un meccanismo si trasferisce a un asset nuovo coi parametri congelati, o e' una famiglia nuova; e il criterio di SELEZIONE va riprovato sull'asset nuovo.
• M21 Quando un meccanismo non generalizza, chiedersi perche' vale piu' del fatto che non generalizzi.
• M22 Un confronto appaiato eredita tutti i parametri della riga in cui compare; un'uscita si giudica appaiata per INGRESSO (allineare sull'uscita tiene solo i casi in cui non e' successo niente — 3 occorrenze).
• M23 Un Monte Carlo ha una risoluzione e va detta; e prima di pubblicare un numero nuovo, far riprodurre alla macchina quello vecchio.
• M24 Un non-arrivo si codifica +∞, mai −1; una mediana condizionata si stampa sempre accanto alla sua probabilita'; un percentile a 0 decimali mente esattamente agli estremi.
• M25 Quando due stimatori di coda non concordano si cita la banda, non quello che conviene.
• M26 Non contare su una compensazione fra correzioni misurate separatamente — la si misura, e in piu' di una moneta (un'interazione piccola cambia segno con la moneta).
• M27 Prima di dichiarare che un campo di un dataset e' sbagliato, aprire il codice che lo produce. E una fonte normativa citata in un commento si verifica come un numero.
• M28 Quando due affermazioni della stessa memoria si contraddicono, la contraddizione e' informazione: una delle due e' stata scritta guardando i dati.
• M29 🚨 Un edge da opzioni prezzate a modello si riprezza alla volatilita' REALIZZATA prima di crederci: se sparisce, non era la struttura — era il premio di varianza, cioe' VRP01, che il progetto ha gia'. Su BTC il DVOL sta il 32% sopra la RV-forward a 7 giorni (77% dei giorni), quindi qualunque struttura che vende vol stampa per costruzione del prezzatore: in COLLAR01 il 72-100% del drift della cella migliore era questo, e l'angolo cadeva da Sharpe 1,471 a 0,511 — che e' il 0,47 gia' pubblicato di VRP01. Vale anche al contrario: un edge che compra vol a modello e' sottostimato dallo stesso fattore.

Sui costi e l'eseguibilita'

• C1 Il costo di un venue va modellato nella sua FORMA (fisso vs proporzionale), non solo nel livello: un pavimento fisso e' una tassa regressiva e due venue a pari "costo medio" danno esiti opposti al variare del capitale.
• C2 Un parametro d'esecuzione espresso in valuta assoluta ha effetto che dipende dal capitale: il controllo non e' lo Sharpe ma la quota di tempo a mercato.
• C3 Prima di misurare il rendimento a un capitale dato, misurare il lotto minimo del venue — e sapere quale famiglia di strumenti si sta guardando (inverse vs USDC-lineare: lotti 7,5× diversi).
• C4 Un fattore di errore si giudica moltiplicato per il suo peso (5,85 al 3% fa meno danno di 2,23 al 18%). Il f di una struttura multi-gamba non e' il f di una sua gamba. E il segno dell'asimmetria di f dipende dal VERSO della gamba: "un roll anticipato non paga f" (§46) vale per una copertura solo LONG — se c'e' una gamba VENDUTA da ricomprare, uscire prima paga f esattamente sulla parte che a scadenza si regolava gratis, e piu' spesso. L'asimmetria si INVERTE (COLLAR01: uscire al 50% del tempo costa 5,6 punti di drift col gate forte, 10,2 col largo).
• C5 L'open interest NON misura la negoziabilita' (su Deribit USDC sono quasi anti-correlati). Prima di credere a un rapporto estremo su un prezzo piccolo, contare i tick.
• C6 La negoziabilita' sul conto reale va verificata quando lo sleeve entra in RICERCA, non quando entra nel book (PRIIPs costo': 5 settimane di misure). "Non posso comprare" ≠ "non posso vedere": il segnale puo' girare su una serie che non si puo' negoziare.
• C7 Si cerca per ISIN, non per ticker; si prende la linea nella valuta del proprio saldo; un costo di conversione e' proprieta' della coppia strumento-conto, non dello strumento.
• C8 La deviazione fra due veicoli sullo stesso indice si misura sul rapporto cumulato, mai sulla media delle differenze. Il carry si misura sul log del rapporto dei prezzi, mai sulla media aritmetica delle differenze.
• C9 Una regola d'uscita che scatta piu' spesso sui vincenti che sui perdenti non e' protezione, e' troncatura — si vede in una riga: la peggior settimana non cambia.
• C10 Una capacita' mancante (es. API di un broker) si valuta sul costo di non averla, non sulla sua assenza.

Sulla produzione e le sorveglianze

• P1 🚨 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. 5 occorrenze: e' il difetto piu' ricorrente del progetto.
• P2 Un rilevatore si valida sul segnale E sul trasporto.
• P3 Se un errore si ingoia per non bloccare, si registra nel punto in cui lo si ingoia — non c'e' un secondo momento buono: quando la diagnosi serve, il guasto e' rientrato.
• P4 Un'allerta risponde a due domande: cosa (decide) e perche' (ripara). Una nota di diagnosi cablata e' peggio di nessuna nota.
• P5 Distinguere guasti diversi anche quando l'azione e' la stessa; e prevedere lo stato "non vedo" (BLIND, flat-senza-dato, NUOVO): "non vedo" non e' "va tutto bene", e il silenzio in una serie di ritorni si legge come zero.
• P6 Una soglia si sceglie con un criterio dichiarato prima (i criteri ovvi sbagliano in versi opposti); la persistenza richiesta E' latenza e va confrontata con la durata del fenomeno; un break-even si calcola sulla media, non sulla coda.
• P7 Un numero di taratura si etichetta con la CONFIGURAZIONE, non solo con la finestra; e uno "zero" si legge accanto alla quota di campione utilizzabile (meno falsi allarmi perche' si vede meglio e perche' si vede di meno hanno lo stesso valore stampato e valore opposto).
• P8 Un veto d'integrita' sorveglia l'asse su cui e' stato scritto: contare se il dato c'era non dice quanto del giorno copriva.
• P9 Un allarme massimo speso per un evento atteso e' un allarme che non verra' letto il giorno che e' vero.
• P10 Un modello di rischio intraday non si valida sulla marginale del wick ma sul suo accoppiamento al rendimento del giorno: close-only non e' conservativa, e' cieca (0,00 breach da daily-loss su ogni configurazione).
• P11 Un dato operativo non ricostruibile non puo' vivere in un file gitignored — si materializza dove il backup arriva.
• P12 Fra due fonti che non concordano, una riparazione silenziosa e' un'invenzione: si riporta la divergenza.
• P13 Una guardia sui NUMERI non copre il RAGIONAMENTO: l'analisi in prosa si legge come opinione di un lettore fallibile, mai come parte del registro. Chi scrive in un registro va firmato.
• P14 Una guardia piu' stretta del contratto produce allarmi che si impara a ignorare; una regola che si accende su $2 di cumulato insegna a saltare la sezione.
• P15 Una regola operativa va provata contro il codice che dovrebbe eseguirla, o si discute per mesi di un knob che non esiste.
• P16 Il cron gira dal working tree: con un branch di ricerca attivo, il cron esegue quel branch.

Sul piano e sulle decisioni

• N1 Il piano si dimensiona sul VERSAMENTO, che e' certo, non sul muro — il muro e' prelievo/perpetua, cioe' un 1/x su una quantita' che va a zero: l'errore e' asimmetrico verso l'alto e la banda e' esplosiva.
• N2 Un piano di accumulo si giudica sulle sue deviazioni, non sul caso nominale (piatto/ininterrotto/per sempre e' l'unico scenario che non succede). Piani di taglia diversa si confrontano su $ finale / $ versato.
• N3 Ordine delle leve, da citare quando si parla del piano: versare o no (da mai a ~16 anni) > quando (6×) > quanto presto si smette (i primi 5 anni sono il 25% dei soldi e il 58% del risultato) > piatto vs crescente (24%) > frequenza (1-3%). A orizzonte corto non fai lavorare la strategia: compri il capitale coi bonifici.
• N4 Un rischio non-diversificabile dagli sleeve (venue) si prezza a parte, e si compra con un secondo CONTO, non con un secondo sleeve. P(successo) puo' nascondere P(rovina): per una rendita la metrica e' la seconda, perche' zero e' assorbente.
• N5 Quando una metrica binaria satura, la decisione si sposta sulla metrica continua.
• N6 Un obiettivo si dichiara nella sua definizione operativa PRIMA di ottimizzarlo: flusso e ricchezza sostenibile sono entrambe difendibili e differiscono di cento volte (33,9% contro 0,33%).
• N7 Uno sleeve difensivo si giudica sul sinistro, non sul premio: hold-out negativo non e' evidenza di morte.
• N8 Una rivalutazione parte dall'elenco di cosa cambia una decisione, non dal riassunto di cosa si e' scoperto; quando due correzioni puntano in versi opposti si misura; quando le leve hanno ordini di grandezza diversi, dirlo.
• N9 Quando una raccomandazione viene respinta con motivo, si registra cosa e' stato accettato in cambio — altrimenti la stessa analisi la ripropone fra tre mesi come se fosse nuova.
• N10 Una data in un gate va giustificata col COSTO della misura, non con la sua difficolta' percepita (due gate d'attesa da mesi eliminati in una sera perche' nessuno aveva contato i secondi). Una verifica esterna a €0 va fatta PRIMA di qualunque misura che ne dipenda, e si fa sul venue, non sul sito di chi la dichiara.
• N11 Un numero pubblicato in un diario deve avere uno script committato che lo riproduce, e ogni script deve calcolare il proprio verdetto a runtime (e' cio' che ha salvato un'ondata interrotta).

---

7. IL DATO — fonte di verita' (regola di prim'ordine)

• La verita' e' Deribit mainnet, perche' e' dove eseguiamo. Cross-check multi-venue: Deribit mainnet e' a 0-1 bps dal consenso. Binance NON e' la verita' (e' USDT, ~10 bps fuori, fino al 3% sotto depeg) → audit indipendente, mai ancora per "ripulire" i dati.
• Aggiornare lo storico SOLO con rebuild_history.py (ccxt Deribit mainnet, base 5m unica + resample). MAI il vecchio downloader Cerbero (token testnet = feed farlocco: e' la causa del reset).
• Certificare sempre dopo un rebuild con certify_feed.py (integrita' OHLC, zero gap, coerenza resample maxΔ≈0, spike = solo crash reali, accordo cross-venue per-anno vs Coinbase USD).

Universo ricercabile certificato

• BTC / ETH — puliti (2-6 bps vs Coinbase USD), liquidi (~0% barre flat a 1h), storia 2018/2019→oggi, ogni timeframe (5m/15m/1h). E' l'unico dato in data/raw/ col namespace nudo.
• Alt Deribit: FUORI (illiquidi/divergenti). SOL vive in data/raw/alt_sol_*.parquet, fuori dal namespace nudo e non rinfrescato dal cron — vedi §3 e la lezione: ricostruire dati per un'analisi puo' disattivare un guardrail che vive nell'assenza di un file.
• Hyperliquid (Cerbero MCP MAINNET): 51 certificati, 19 major usati da XS01, 1d dal 2024. Storia nativa ~2,5 anni. ⚠️ Cerbero col token testnet e' farlocco; col mainnet e' reale ma sempre da certificare, e il rivelatore del backfill sintetico e' il VOLUME, non il flat ne' il cross-venue.
• Catena opzioni Deribit mainnet — raccolta propria dal 2026-07-30 (scripts/live/collect_chain.py, cron :25). Dettaglio, archivio ereditato, difetti e buchi di colonna in docs/memory/50-dati-e-feed.md. Perche' si memorizza invece di interrogarla: una catena opzioni non e' ricostruibile a posteriori — un'ora non raccolta e' persa per sempre.

Backup. data/raw/ e' gitignored → il dato non ricostruibile (catena, data/paper_*, data/chain_collect, data/live, venue_watch, fee_watch, config/live.json) e' salvato da do_pythagoras in /opt/docker/scripts/backup.sh (daily 04:00). ⚠️ /opt/docker/scripts non e' un repo git: quella modifica vive solo su disco.

---

8. Metodologia obbligatoria per ogni nuova strategia

1. Ingresso eseguibile: direzione e prezzo decisi con dati fino a close[i], mai close[i-1] con direzione presa da i; mai entry sull'estremo (high/low) di una candela.
2. Backtest NETTO dopo fee realistiche Deribit (0.10% RT taker, conservativo: il tier reale e' 3,50 bps/lato dal 2026-08-01) + leva. ⚠️ Il funding NON e' nel motore — vale −2,16%/anno di drift.
3. Out-of-sample held-out + robustezza su griglia parametri (entrambi gli asset, tutte le celle positive) + sweep fee (0.00-0.20% RT).
4. Liquidita' & plausibilita': incrociare ogni edge con la liquidita' reale del book (quota di barre flat) e con la plausibilita' del prezzo (cross-venue). Un edge full+OOS robusto su un book fermo o su wick fantasma non e' un edge.
5. I gate di altlib.py (dettaglio in docs/memory/60-metodo-e-gate.md): study_marginal / marginal_vs_tp01 (ADDS·NEUTRAL·REDUNDANT·HEDGE·NOISE, con persistenza multi-cut, edge in-sample, hedge-vs-alpha) · study_family_honest (+ deflated_sharpe ≥0,95, select_cell_insample) · day_boundary_robust · eval_weights_smallcap · implausible_sharpe · anchor_luck_band / anchor_luck_delta · weights_tilt_null (ogni proposta di cambio pesi).
6. Strategia in scripts/strategies/ (codice univoco), test in tests/, diario aggiornato.

---

9. Lezioni critiche storiche (da NON ripetere)

• Feed contaminato → libreria fasulla (v2.0.0). Print fantasma testnet + Binance/USDT hanno prodotto edge inesistenti (+201%/+1238%/+16492% "OOS"), tutti spariti sul feed reale. Il dato viene prima della strategia.
• Look-ahead squeeze. Accuratezze 76-82% erano artefatto: direzione dalla candela i, ingresso a close[i-1]. Con ingresso onesto: lancio di moneta.
• Entry sugli estremi di candela. ETH 2024: +30.848% → +2.725% rimuovendoli.
• Data leakage con rendimenti log: returns[k] = log(close[k+1]/close[k]) usa close[k+1]; i feature devono fermarsi a returns[i-2] se il prezzo corrente e' close[i-1].
• Fee = vincolo di prim'ordine; leva: 5x raddoppia il drawdown, i numeri a leva alta non sono il caso base.
• Onesta' sul target €50/giorno. Non e' raggiungibile a questo capitale: serve ~$313k (banda [$187k – $1,14M]) o €1.733/mese per 10 anni a P=90%. La leva non e' la scorciatoia; la via e' target-vol + capitale + tempo.

---

10. Obiettivo

Ricerca: riconoscimento pattern frattali per trading algoritmico su crypto. Target dichiarato €50/giorno partendo da €1.000. Onesta' prima di tutto: nessun numero va creduto finche' non e' netto fee, out-of-sample, robusto su griglia, e su dati certificati + liquidi + eseguibili.

11. Stack

• Linguaggio: Python 3.11+ — Package manager: uv (pyproject.toml, uv.lock)
• Dati: Parquet in data/raw/ (gitignored). Solo BTC/ETH (5m/15m/1h) nel namespace nudo.
• Analisi/ML: numpy, pandas, scipy, scikit-learn
• Fonte dati storici: Deribit mainnet via ccxt (pubblico, tokenless)

12. Struttura

src/data/downloader.py       → load_data(asset, tf): legge i parquet certificati
src/strategies/              → base.py (Strategy/Signal/BacktestResult), indicators.py,
                               trend_portfolio.py (TP01), skyhook.py (SKH01)
src/portfolio/               → portfolio.py (combina N sleeve + weights_tilt_null),
                               sleeves.py (REGISTRY: aggiungere uno sleeve = una riga), gtaa.py
src/backtest/harness.py      → harness ONESTO (load BTC/ETH, backtest_signals no-leakage, OOS)
src/live/                    → book.py (esecutore netto TP01+SKH01), shadow.py, deribit.py,
                               livefeed.py, venue_watch.py, monitor_health.py, notifier.py,
                               scale_watch.py (chiave di scala: 3 domande, 3 stati),
                               tradesdb.py · journal.py · analista.py (libro di bordo)
src/data/eq_splits.py, eq_crosscheck.py → guardie sul feed equity
scripts/research/            → ricerca (r<data>_*.py). Harness condiviso: alt/altlib.py
scripts/analysis/            → SOLO tool sui dati certificati: rebuild_history, certify_feed,
                               audit_feed, multi_source_check, fetch_* , certify_cb_chain
scripts/live/                → book_execute · venue_watch · fee_watch · edge_watch ·
                               monitor_health · collect_chain · paper_* · trades_db ·
                               journal · analista
scripts/cron_{book,daily,chain,opt_snapshot,vol_term}.sh
docs/memory/                 → LA MEMORIA (indice in testa a questo file)
docs/research/               → BRIEF-0822 · RESULTS-0822 (§1-69) · SPEC-scale-key
docs/diary/YYYY-MM-DD.md     → una voce per esperimento (123)
docs/journal/YYYY-MM-DD.md   → libro di bordo, una voce al giorno, 4 livelli per provenienza
data/live/trades.db          → i trade allineati col tempo (dentro il perimetro di backup)
Old/                         → ARCHIVIO pre-reset
VERSION                      → semver

13. Comandi

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 [--local]         # certifica i feed
uv run python scripts/portfolio/run_portfolio.py                 # report del portafoglio (ricerca)
uv run python scripts/live/paper_portfolio.py                    # avanza il paper (forward-only)
uv run python scripts/live/trades_db.py --report                 # stato libro di bordo + P&L (TWR, non e1/e0)
uv run python scripts/live/trades_db.py --reconcile              # incrocio delle 3 fonti sui fill
uv run python scripts/live/journal.py                            # voce del giorno (numeri + lettura)
uv run python scripts/live/analista.py --secco                   # analisi del giorno, senza salvare
uv run pytest                                                    # test (847, tutti verdi al 02/09)

from src.data.downloader import load_data
df = load_data("BTC", "1h")   # load_data("SOL", ...) -> FileNotFoundError (guardrail: solo dati certi)

14. Convenzioni

• Strategie in scripts/strategies/ con codice univoco; le scartate si documentano (memoria + diario).
• Diario in docs/diary/YYYY-MM-DD.md dopo ogni esperimento significativo; registro per filone in docs/research/RESULTS-0822.md.
• Quando un risultato cambia una decisione, aggiorna questo file; quando aggiunge racconto, va in docs/memory/. Questo file non deve tornare a crescere senza limite.
• Nessun segreto nei commit (token/chiavi). .env e .env.mainnet sono gitignored.
• Versionamento: VERSION (semver) + scripts/bump_version.py; src/version.py lo legge.

15. Archivio Old/

Tutto il lavoro pre-reset (preservato in git): strategie, stack live e portafogli, ricerca/gate, dati non certificati, 60+ diari, test. Consultabile come riferimento ("come facevamo X"), ma nessun edge li' dentro e' fidato finche' non e' ri-validato su dati certi.