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

⚠️ 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.

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

📌 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
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	costruire prima una chiave di scala esplicita in config e rifare r0726_fee_sensitivity

⚠️ La regola "ogni cambio di scala passa dal cap di config, non da target_vol" NON E' IMPLEMENTABILE COME SCRITTA: verificato che in config/live.json non esiste una chiave di scala — servirebbe toccare WEIGHT/W_TP01/W_SKH in src/live/book.py, cioe' codice su un percorso con soldi veri. Specifica pronta in docs/research/SPEC-scale-key.md (GATE SCALA-01, 9 condizioni, con il tetto sul PRODOTTO n_asset · frac · scala · disaster_sl_pct ≤ 0,50 — non sulla singola chiave).

---

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
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 a $5.000 ≤40% (se sfonda → ritiro a prescindere), poi weights_tilt_null e capitale ≥$5k	🚨 legge un monitor mal tarato (§5.3), e P(capitale ≥$5k quel giorno) = 0,0% (mediana $2.635) → il criterio di capitale non e' raggiungibile. Sotto la lente RENDITA il sleeve e' 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)
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. 🚨 Il trasporto degli allarmi e' un punto singolo di guasto — 6,9% di invii falliti (2/29). Fatte il 23/08: retry opzionale in send() e registrazione del motivo nel punto in cui veniva ingoiato. Resta: alerted=True marcato prima dell'invio → un 🚨 perso e' perso per l'episodio intero (gli episodi storici durano 200-2.324 ore). Cambiarlo cambia il comportamento → decisione dell'operatore.
3. 🚨 Il gate XSR01 del 23/10 legge un monitor tarato sul pavimento del venue sbagliato (C* vero $15.000-20.000, non ~$3.000). Due sole vie pulite: riscrivere la soglia adesso dichiarando che la si riscrive prima di vedere l'esito, oppure lasciarla e citare il difetto alla decisione. Decisione dell'operatore.
4. ❓ Due domande al commercialista, aperte (valgono ~$22k di muro e ~€30/mese di versamento): (a) i derivati Deribit (inverse, margine e regolamento in cripto, sede extra-UE) stanno in c-sexies (33%) o c-quater (26%)? E il collaterale sconta il 2‰ al 31/12? (b) i payout di una prop firm: ne' c-sexies ne' c-quater — le fonti convergono su lavoro autonomo, nessuna prassi ufficiale. Non sono pareri fiscali: sono domande da porre.
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. La guardia giusta e' il tetto sul PRODOTTO di GATE SCALA-01, da cablare nel codice che leggera' la chiave quando esistera'.
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. ⚠️ Il docstring di book_execute.py prescrive "ogni ~230 minuti", il cron gira OGNI ORA. Il docstring e' sbagliato e la configurazione che gira e' quella giusta — chi lo "correggesse" sposterebbe il libro sulla riga 4h, dove BTC raddoppia gli scatti del disaster-SL.
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: 751 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.

---

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).
• 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.

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.
• 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,
                               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
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 (751, tutti verdi dal 26/08)

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.