46 Commits

Author	SHA1	Message	Date
Adriano Dal Pastro	ec8478308f	GATE SCALA-01: la chiave di scala esiste, ed e' INERTE (SPEC §8 punti 1-4) ... Chiude il debito che CLAUDE.md dichiarava da settimane: la regola "ogni cambio di scala passa dal cap di config, non da target_vol" NON era implementabile perche' una chiave di scala non esisteva — qualunque cambio sarebbe finito su WEIGHT/W_TP01/W_SKH, cioe' codice su un percorso con soldi veri e per giunta nel posto sbagliato (W_TP01/W_SKH sono il RAPPORTO 75/25, non la taglia). Specifica gia' scritta in docs/research/SPEC-scale-key.md (618 righe, 9 condizioni di gate, prototipo). Non ho progettato: ho eseguito i punti 1-4. 🚨 config/live.json NON E' STATO TOCCATO. La chiave e' assente, vale 1,00, e T7 dimostra bit-exact che il libro e' quello di ieri (max|diff| = 0.0). Verificato anche a runtime: book_execute in dry-run da' gli stessi target del cron delle 15:47 (BTC $+355, ETH $+214). LE QUATTRO DECISIONI CHE NON SONO DI COMODO - La scala si applica DOPO il clamp. Prima, il cap se la mangerebbe proprio nei giorni di massima convinzione (a tp=1/sg=+1 il grezzo vale esattamente cap => k_eff tornerebbe a 1,00 a ogni k): sarebbe un cambio di FORMA travestito da cambio di taglia, e la curva g(k) con cui il gradino viene autorizzato non descriverebbe quel libro. Prezzo dichiarato: il cap diventa il tetto del libro UNITARIO, e la guardia sulla leva lorda va ricostruita. - Il tetto e' sul PRODOTTO e sta nel CODICE. Sulla sola chiave lascerebbe aperta la porta accanto (frac 0,625 x scala 1,25 = 1,562x); in config sarebbe un lucchetto con la chiave attaccata. LEVA_LORDA_MAX 1,25 in src/live/book.py => il gradino a 1,50 richiede codice, quindi review. - Fuori scaletta o fuori tetto = STOP, non clamp. book_execute si ferma, non invia, allerta (ScalaNonAutorizzata). E SCALA_LADDER (1,00 · 1,25) rende INESPRIMIBILE "solo un po'": 1,05 non e' prudente, e' fuori scaletta. - La scala vive solo sul percorso fidato (equity illeggibile => 1,00), cosi' "il fallback non e' piu' permissivo" e' vero per costruzione. Ma la VALIDAZIONE avviene sempre: una config rotta non si nasconde dietro un giro in cui l'equity non era leggibile. LA GUARDIA CHE MORDE PER PRIMA non e' il peggior giorno (k <= 3,49x) ma il COSTO di un disaster-SL (k <= 1,67x, 2,1x piu' stringente): l'invariante n_asset x frac x scala x disaster_sl_pct <= 0,50 scatta anche se qualcuno allarga lo stop invece di alzare la scala. TEST T1-T11 (tests/test_book_scale.py, 18 verdi). Il piu' importante e' T1b: a k=1 l'implementazione simmetrica e quella asimmetrica danno lo STESSO numero, quindi un test di simmetria scritto sul caso di default ha potenza ZERO. T1b verifica che le due coincidano a k=1 (il rischio e' reale) e che fuori da k=1 l'asserzione le SEPARI, con un'implementazione asimmetrica scritta nel test apposta perche' fallisca. SORVEGLIANTE scale_watch (cron_daily, 3 domande / 3 azioni / 3 stati, una allerta per streak, marcatore scritto solo dopo invio riuscito — debito #2). Riporta la frequenza del ramo di fallback, che sopra il 2% in 90 giorni invaliderebbe la regola: misurata 0/1.676, coi 19 giri "paper capital" (pre-finanziamento, dove il libro non invia) contati e dichiarati a parte. Non puo' impedire la modifica: la rende visibile entro 24h e attribuibile. CHIUDE il debito #5 di §5: T2/T3 sostituiscono il vecchio test_leva_massima_da_config (che misurava frac x n_asset mentre la grandezza vera e' frac x n_asset x scala), e T11 verifica che sia rimasto cancellato. NON FATTO, deliberato: la chiave in config (punto 2 lo vieta), GATE SCALA-01 (A2 richiede >=30 giorni a 1,00 col sorvegliante attivo — "l'unico modo di scoprire che il sorvegliante e' rotto mentre la leva e' ancora 1,00"), r0726_fee_sensitivity rifatto (A7: serve solo al gradino; a 1,25x una liquidazione costerebbe 1,25% non 1,00%, e ereditarlo sarebbe l'errore). Nessun ordine. Suite: 825 passati. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 17:44:02 +00:00
Adriano Dal Pastro	fd7595e819	margini: haircut 5% (la config aveva torto) — e il conto NON e' cross-collateral ... Lo screenshot della pagina margini era su Wasabi (rclone remote wasabi:, bucket adp-work, cartella _scambio), non sulla VPS: per questo il percorso non esisteva. Riconciliazione riproducibile in scripts/research/r0831_margini_conto.py (N11). (a) HAIRCUT = 5%. La pagina non lo espone come numero: si ricava per differenza, perche' il CROSS conta l'USDE scontato e il SEGREGATO non lo conta affatto. S:SM (attivo) USDC Available 1.400,86 vs equity 1.412,28 - IM 11,55 = 1.400,73 X:SM CROSS Available 2.011,73 contributo USDE al cross = $610,81 su $643,05 -> 5,0137% 5% (KB) atteso $610,89 scarto $ 0,09 TORNA 10% (nostra) atteso $578,74 scarto $32,06 NON torna config/live.json: haircut 0.10 -> 0.05. Il 26/08 il 10% fu registrato come "verificato sul venue" senza traccia di COME, e non lo era. (b) 🚨 IL CONTO NON E' CROSS-COLLATERAL: modello attivo "Segregated: Standard Margin" (S:SM). Nella tabella del modello attivo l'USDE NON COMPARE: non fa margine per i perp USDC-settled del book, e l'haircut oggi non si applica. Il che spiega a posteriori perche' la misura di stamattina trovava $0,0000 accantonati: non stavo guardando nel secchio sbagliato, cercavo un parametro che sul nostro conto non e' in vigore. NON MORDE: al massimo lordo del libro (1,0x = ~$2.056 di nozionale) l'IM sarebbe ~$41 contro $1.400 di USDC disponibile, 34x di copertura. Nessuna decisione operativa cambia oggi. Ma la premessa in CLAUDE.md era falsa, e il modo in cui lo era e' istruttivo: "l'equity del book e' il TOTALE cross-collateral" metteva due cose sotto un nome solo. Come RICCHEZZA sommare USDC+USDE e' giusto ed era il punto della riparazione del 26/08 (evito' il falso "USCITA DI FONDI -24%"); come CAPACITA' DI MARGINE e' sbagliato, perche' nel modello attivo l'USDE vale zero. Finche' il margine non morde le due coincidono nell'uso, e infatti non era mai emerso. Corretta anche la riga di usde_watch che stampava "margine utilizzabile ~$2.013 (haircut 10%)": era falsa due volte insieme. Ora stampa il solo silo USDC e, accanto, cosa darebbe il cross. La quota USDE non e' "collaterale diversificato": e' cassa a rendimento FUORI dal sistema di margine. Passare a X:SM aggiungerebbe $610,87 di margine utilizzabile ma porta la meccanica cross (collateral fee 0,05%/giorno sul saldo negativo, ribilanciamento automatico): decisione dell'operatore, oggi non serve. Ipotesi nuova e non verificata: il tetto del ~31,2% potrebbe dipendere proprio dal modello segregato. Si saprebbe passando a X:SM e ri-sondando. Suite: 800 passati. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-31 08:01:21 +00:00
Adriano Dal Pastro	30286ea033	venue_news: sorvegliare cosa il venue ANNUNCIA — e due correzioni dalla KB ... Nasce dall'annuncio sulla fine della Proof of Reserves. La notizia in se' vale poco: si perde un segnale ad alta frequenza e DEBOLE (una PoR auto-pubblicata prova che gli attivi esistono in un istante, non che coprano le passivita') e si guadagna un audit annuale indipendente sotto VARA piu' il 90% degli attivi presso Coinbase come custode. E non l'abbiamo mai sorvegliata: zero occorrenze nel codice. Rinunciato di proposito a catturare l'ultimo dato — uno snapshot singolo auto-riportato non regge lo standard di prova e non permetterebbe di stimare `p`. CONSEGUENZA VERA: la decisione "100% Deribit fino a $20k" ha fra i suoi riapritori "`p` che diventa stimabile invece che assunto". Dal 1/9 il segnale pubblico passa da quotidiano ad ANNUALE: da una serie si stima, da un punto all'anno no. Quel riapritore diventa praticamente irraggiungibile => la decisione e' ora gated SOLO dal capitale. TROVATO CERCANDO: esiste un feed RSS degli exchange-update, e conteneva quattro annunci materiali che nessuno leggeva. Il caso che decide: le specifiche dei perp USDC sono cambiate il 18/08, ANNUNCIATE IL 14/08. check_specs() e' nato da quella svista e gira ogni ora, ma rileva la deriva DOPO; il feed l'avrebbe detta quattro giorni PRIMA. La prima volta e' andata bene solo perche' i cambi erano RIDUZIONI. Costruito scripts/live/venue_news.py (in cron_daily accanto a fee_watch): - NON interpreta: dice "e' uscito questo, guardalo". Nessun automatismo su un testo di marketing (P13). Classifica solo l'urgenza. - parole-chiave DERIVATE da deribit._CONTRACT e config/live.json, non ridichiarate (P1): chi aggiunge un asset allarga la sorveglianza da solo, ed e' il test che lo blinda. - primo giro semina senza allertare (P9); feed illeggibile -> exit 2, mai silenzio implicito (P5). Debito #8 si RESTRINGE, non si chiude: il Rulebook non ha un feed. Confermato due volte lo zero USDC: l'espansione del 31/07 non contiene l'Italia ne' alcun paese UE, mentre San Marino e Citta' del Vaticano SONO idonei. Non asserisco una causa (ci sono anche Canada e Giappone). DUE CORREZIONI dalla KB "Cross collateral specifications": (a) Il saldo negativo costa una collateral fee dello 0,05% AL GIORNO = 18,25%/anno, al secondo — 4,3x la resa USDE. Il 30/08 avevo scritto "lo finanzia a interesse" SENZA il numero: giusto e vuoto. Col numero, il criterio del cuscino di regolamento diventa aritmetica (-14 punti). E il ribilanciamento automatico non salva: scatta a $1M assoluti o al 100% della cross equity, irraggiungibili a $2k. Non veniamo ribilanciati: sanguiniamo la fee. (b) L'haircut USDe ufficiale e' 5%, noi abbiamo 0.10 registrato come "verificato sul venue" il 26/08 senza traccia di come. NON riparato (P12/M28): si tiene 0.10 perche' e' il lato conservativo, non e' sul percorso soldi e non morde fino al 90% di quota. Divergenza dichiarata in config. Di lato: BUIDL haircut 2% (sarebbe stato il miglior collaterale del listino, se si potesse comprare), stETH 7,5% (terza ragione indipendente per lasciarlo stare). Nessuna fonte documenta un tetto sulle QUANTITA': il ~31,2% resta misurato e non spiegato — e ora si sa che non e' una svista di lettura. Suite: 800 passati (5 nuovi su venue_news). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-31 07:47:15 +00:00
Adriano Dal Pastro	41f83b5dd8	BUIDL-01 CHIUSO: non entrabile — e la frase pubblicata da Deribit e' falsa per noi ... Esito del test pre-registrato dieci minuti prima (7b8e356). Si chiude con un esito che NON era fra i due previsti: i criteri contemplavano ">=1 reward -> IDONEO" e "zero reward -> NON IDONEO", ma non si riesce a comprare BUIDL affatto, quindi la domanda sull'eligibilita' ai reward e' priva di oggetto. Un gate puo' fallire sulla sua PRECONDIZIONE invece che sul suo criterio, e va scritto cosi'. Undici ordini rifiutati con not_enough_funds_in_currency, fino a 1 unita' a limite 1,0100 contro ask 1,0004 con 10.730 di profondita', tenendo ZERO BUIDL e avendo $1.412 disponibili per comprarne $1. Esclusi uno per uno tutti i sospetti che sull'USDE avevano portato fuori strada: prezzo (incrocia di 96 bps), liquidita', taglia (il minimo dello strumento), fondi, tetto sul livello (teniamo zero), wallet (account_summary risponde). Costo del test: $0, nessun fill. 🚨 "All Deribit users are permitted to buy and sell BUIDL tokens in the spot markets on Deribit, with no extra requirements" — insights.deribit.com. NON per noi. Motivo plausibile e non verificato: BUIDL e' un titolo (fondo BlackRock via Securitize), distribuzione ristretta a monte dell'exchange. Il fatto misurato e' il rifiuto, non il suo motivo. REGOLA (due affermazioni pubblicate smentite dal conto in due giorni — APR USDC 3,40% e "all users can buy BUIDL"): 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. E' N10 un passo piu' in la': non basta il sito, non basta il venue, serve il conto. SOTTOPRODOTTO che vale piu' del test: not_enough_funds_in_currency e' il messaggio GENERICO di Deribit per "non puoi acquisire altra di questa valuta" — permesso (BUIDL, zero in mano) o tetto (USDE, ~31,2% dell'equity), mai i fondi. Chi lo incontra salti subito alla domanda giusta invece di inseguire taglia, cadenza e prezzo come e' successo il 30/08. => L'USDE resta l'unico collaterale a rendimento che il conto puo' usare, ed e' al suo tetto; i $1.412 di USDC continuano a rendere zero. Non per mancanza di alternative: le tre alternative sono chiuse per giurisdizione (USDC), per permesso (BUIDL) e perche' non e' un dollaro (stETH). balance_watch esteso a BUIDL: se l'accesso si aprisse, un balance non nullo lo direbbe da solo. Suite: 795 passati. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-31 07:35:32 +00:00
Adriano Dal Pastro	f151316bdf	usde: il tetto e' una FRAZIONE dell'equity (~31,2%), non un livello — e ora e' in config ... Fonte: articolo ufficiale Deribit "Yield/reward bearing coins" (WebFetch lo prende 403, si legge dall'API Help Center in JSON). Tre correzioni alle conclusioni di ieri. 1) L'ITALIA e' nella lista delle giurisdizioni escluse dai reward USDC. Lo zero misurato e' confermato dalla fonte, ma la mia ipotesi MiCA era SBAGLIATA: la lista contiene Canada e Giappone, non e' il perimetro MiCA. E' policy di giurisdizione Deribit. M27: una fonte normativa si verifica, non si deduce. 2) La finestra di pagamento USDC e' di DUE SETTIMANE ("within the first two weeks of the following month"), non tre giorni. Avevo verificato su 8/14 e 3/14 giorni. Rifatto sulle finestre vere: LUGLIO conclusivo (atteso $1,72 contro un'escursione TOTALE dell'equity di $0,48 in 1-16/08, zero scalini compatibili), GIUGNO no (il libro opera da meta' mese, rumore della taglia del segnale). La conclusione non cambia, ma l'evidenza e' UNA finestra piu' la lista ufficiale, non due: il "172x" del 30/08 era sovra-affermato. 3) IL TETTO NON E' UN LIVELLO, E' UNA FRAZIONE. L'articolo documenta un Cap ETHENA che diluisce il TASSO a livello di exchange e nessun limite sulle quantita' detenibili: il muro non aveva base documentale e andava ri-sondato. Fatto il 31/08 (giorno UTC nuovo -> non e' un limite giornaliero): ieri si tornava a 644,18, oggi no, con l'equity scesa di $8. 30/08 tetto [644,18 · 645,18) equity $2.063,79 = 31,21-31,26% 31/08 tetto [643,18 · 644,18) equity $2.055,56 = 31,29-31,34% 0,05pp di scarto, dentro il rumore dell'equity (+-$2-8/ora). Candidato pulito 5/16 = 31,25%, ma a questa risoluzione non si distingue da una regola sul collaterale scontato dell'haircut (~29%): si cita la banda (M25). => Il tetto SCALA col conto: la quota resta ~31%, il valore in dollari cresce col capitale, il 70% non e' raggiungibile ne' ora ne' mai. E, essendo pinnati al tetto, il rischio emittente resta una frazione COSTANTE del conto. Cablato (rispondeva a "dove e' scritto il valore del tetto": in tre note di testo e in nessun posto che il codice leggesse, tanto che usde_convert --quota 0.70 dichiarava "piano valido" per un ordine che il venue rifiuta): - config/live.json usde.venue_cap_frac 0.312 + venue_cap_misurato - src/live/usde.py lo porta nei default (unica autorita', P1) - usde_convert.piano() rifiuta il bersaglio sopra il tetto PRIMA di sparare e stampa il massimo raggiungibile. Verificato su entrambi i rami. Anche: l'USDe ha un fee Deribit del 5% mai nominato prima. Il nostro misurato (~4,5%/anno) e' gia' netto: e' l'unico numero da citare. Stato: USDE 643,175691 (31,29%, al tetto), USDC $1.412,40, totale $2.055,57. Suite: 795 passati. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-31 07:27:23 +00:00
Adriano Dal Pastro	c250c04371	usde: l'USDC NON frutta sul nostro conto — misurato, e §6 di stasera era sbagliata ... Domanda dell'operatore: "verifica se l'USDC frutta davvero sul nostro conto". Sembrava dover aspettare: il gateway non espone il Transaction Log (get_transaction_log, get_settlement_history, get_deposits, get_transfers, get_interest_history: tutti 404 — debito #11) e l'unica serie storica e' trades.db.equity, oraria ma arrotondata a 2 decimali e sporcata dal P&L non realizzato (+-$2-8/ora a posizioni aperte), dove $0,13/giorno sparisce. La fonte ufficiale Deribit ha spostato il problema dal rumore al calendario: i reward USDC si pagano UNA VOLTA AL MESE ("paid out as a single monthly payment early in the following month"), accrual alle 00:00 UTC sulla minima equity — non ogni giorno come l'USDE. Ecco perche' una sorveglianza giornaliera non poteva vederli. E un accredito mensile da qualche dollaro si vede benissimo anche a 2 decimali, purche' il libro sia FLAT: allora equity == balance == USDC e ogni scalino e' un accredito. MISURA, due confini di mese entrambi a libro flat: 29/06 -> 08/07 equity 598,06 costante, 237/237 ore ferme, 0 scalini (attesi $0,45) 31/07 -> 03/08 equity 596,92 costante per 4 giorni pieni (attesi $1,72) Il secondo e' decisivo: $1,72 contro una risoluzione di $0,01, 172x. Zero MISURATO, non zero sotto soglia. => La premessa originale del gate USDE-01 e' RESTAURATA: il guadagno di tenere USDE e' il tasso pieno ~4,1%, non lo spread 0,71 punti che avevo scritto poche ore fa. Sui $644: ~$26/anno, non ~$4,6. Cosa avevo sbagliato: ho letto `apr: 3.4` in public/get_currencies e l'ho trattato come una proprieta' del NOSTRO CONTO. Era un listino del VENUE. La "conferma indiretta" che invocavo provava che il listino e' reale per l'USDE e non diceva nulla sull'idoneita' dell'USDC. Un tasso pubblicato non e' un tasso incassato: si verifica sul conto — ed e' costato una query su una serie che avevamo gia'. Esclusione plausibile ma NON verificata: MiCA (USDC e' e-money token, USDe no); Deribit dice solo "eligibility is based on their location". Il fatto misurato e' lo zero, non il suo motivo. Nuovo: scripts/live/balance_watch.py + scripts/cron_balance.sh (orario al minuto :42, libero fra :25/:35/:47, sola lettura). Registra il BALANCE a 8 decimali per valuta — la serie che mancava — col conteggio dei fill dall'ultimo campione e il nozionale lordo, cosi' una finestra sporca si riconosce invece di essere mediata dentro. Etichetta PULITA le finestre a 0 fill e libro flat, dove il delta USDC E' l'interesse, e ne stampa l'APR implicita. Suite: 795 passati. L'ERROR di teardown e' il falso positivo dichiarato dalla guardia stessa: il cron :47 ha scritto un fill reale (ETH BUY $+9, 23:47:19) mentre la suite girava. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-30 23:48:52 +00:00
Adriano Dal Pastro	a45794d2cb	usde: il venue mette un TETTO al 31,21% — e l'USDC paga gia' 3,40% ... Richiesta dell'operatore: "porta in usde tutto il capitale che non viene usato". Il margine consuma $11 su $2.063 e l'USDE e' cross-collateral: preso alla lettera vale una quota ~99%, cioe' il 100% che il gate esclude. Portata all'operatore con le cifre, ha scelto 70%. Il 70% non e' un argmax (M8): e' il massimo compatibile col CUSCINO DI REGOLAMENTO, il vincolo che r0830_usde_quota non aveva guardato. P&L e funding dei perp USDC-lineari si regolano in USDC, non nel collaterale, quindi la quota non la limita l'haircut ma il saldo USDC che deve reggere il disaster-SL sulla massima esposizione: 2 x 0,5 x 0,30 = 30% dell'equity, che lascia il 70%. ESEGUITO +144 USDE (500,1757 -> 644,175691), quota 24,24% -> 31,21%, fee 0. Poi il muro. (a) TETTO DEL VENUE, misurato e non documentato da nessuna parte. Provato a saldo neutro: BUY 20 rifiutato, SELL 20 OK, BUY 20 OK, BUY 5 rifiutato, con $1.408 disponibili. E' un tetto sul LIVELLO. Il messaggio del venue (not_enough_funds_in_currency) e' fuorviante e ha fatto inseguire tre ipotesi sbagliate: taglia (falso, ma min_trade_amount=1 e' vero), rate-limit (falso), prezzo (vero in parte: il book REST pubblico e' in ritardo sul matching engine e prezzavo l'ordine sull'INDICE invece che sul BOOK — l'indice marca il collaterale, il book prezza lo scambio). La cronaca resta nel diario: chi rilegge non deve rifare il giro. (b) L'USDC PAGA 3,40%. public/get_currencies: USDE 4,1071%, USDC 3,4000%, e i nostri reward USDE misurati (~4,5%/anno) confermano che quelle APR sono reali. Il guadagno non e' il tasso, e' lo SPREAD: 0,71 punti, ~$4,6/anno sui $644 che teniamo, non i $21 che il gate implicava. Il gate ha misurato il reward dell'USDE e non ha mai chiesto cosa facesse l'USDC fermo: manca il controfattuale, M1 in un'altra veste. NON dimostrato che sia accreditato sul nostro conto — da verificare su un giorno senza trade. Nuovo attrezzo scripts/live/usde_convert.py: dry-run di default, banda prezzo, tetto hard di quota, cuscino di regolamento derivato da config. NON passa da execution.ALLOWED, che resta ai soli due perp. config: quota_target 0.70 registrato; quota_max_frac alzato a 0.85 e RIMESSO a 0.50 nella stessa sessione — la soglia larga presupponeva un 70% che non esiste, e lasciarla avrebbe disarmato la guardia per uno scenario che non si e' verificato. Suite: 795 passati, 0 falliti. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-30 20:18:31 +00:00
Adriano Dal Pastro	993d17556a	usde: gate CHIUSO IDONEO, quota rinviata a lunedi' — l'APR si legge col suo n ... Il 2026-08-28 12:35Z `usde_watch` ha rilevato il primo reward (+0.052055 USDE su 500), e la regola pre-registrata il 26/08 PRIMA dell'esito ha chiuso il gate USDE-01 su IDONEO. Si apre la decisione di QUOTA, che e' dell'operatore. DECISIONE DELL'OPERATORE (29/08): la quota si decide lunedi' 31/08, su tre-quattro finestre invece che su una. Il motivo e' un numero: sul solo pagamento il tasso implicito e' 3,80% annuo, su DUE finestre — il 27/08 aveva pagato ZERO — e' 1,90%. Fra i due c'e' tutta la decisione, e il campione e' UN pagamento. `rendimento()`: APR sulle finestre OSSERVATE, col denominatore sul TEMPO VERO e non sul numero di finestre pagate — cosi' una finestra che non paga ABBASSA la stima invece di sparire (P5: quel silenzio e' uno zero). Le letture con trade nel mezzo si escludono, non si riparano in silenzio (P12). L'APR si stampa sempre col suo `n`, e sotto 4 finestre la riga dice «un pagamento non e' un tasso». Sulle letture vere: 1,97% annuo su 1,9 giorni, 1/2 finestre pagate. `quota_da_decidere()`: vera SOLO se IDONEO E il rinvio e' scaduto. Da lunedi' il watch manda il 📌 OGNI giorno — quota attuale, tetto di allerta, APR osservato — finche' non si decide (N9: una decisione rinviata senza promemoria e' rinviata per sempre). Stesso schema della soglia $15k di GTAA01, con la data al posto del capitale. Si smette togliendo `DECISIONE_QUOTA_DAL`. 6 test nuovi, incluso il controllo positivo — «la finestra sola darebbe il doppio» — che e' esattamente la ragione per cui l'APR non si cita senza il suo n. CONFERMATO il fix IB di ieri: il giro delle 00:30 ha 0 righe `orders request timed out` (erano 2 per giro, 63 su 63) e tutti e sei gli ETF scaricati. E una conferma involontaria del debito §5.13: SPY e' passato da 1996-09-04 a 1996-09-05 — la finestra rotolante ha perso un altro giorno in una notte, come misurato. Diario: docs/diary/2026-08-29-usde-idoneo-e-ib.md Suite: 795 passati, 0 falliti. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-29 06:45:47 +00:00
Adriano Dal Pastro	801bd13f10	allarmi: il marcatore "gia' detto" si scrive DOPO l'invio, non prima ... Debito §5.2 chiuso su decisione dell'operatore. `run_once` salvava lo stato coi marcatori `alerted` gia' a True e l'invio lo faceva il chiamante DOPO: col 6,9% di invii falliti misurato (2 su 29), un 🚨 perso restava perso per l'EPISODIO INTERO — l'ora dopo lo stato diceva "gia' detto" e usciva WATCH/MUTO. Gli episodi storici durano 200-2.324 ore, quindi il buco non era teorico. - `run_once(state_path, sender=None)`: il sender e' INIETTATO, non importato — e' cio' che tiene la funzione testabile senza rete d'uscita, che era la ragione del disegno precedente. Senza sender il comportamento resta quello di prima e il report lo DICE (`invio`), invece di lasciar credere che qualcosa sia partito. - Su invio fallito si disfano SOLO i marcatori "gia' detto", non le misure: · asset in ALERT -> alerted=False, l'ora dopo ri-allerta; · lock MAINT/ALERT -> alerted_soft/hard=False ma le ORE restano a correre, cosi' una manutenzione che sfora la grazia sale ad ALERT anche col trasporto giu' (disfare anche le ore congelerebbe l'escalation proprio mentre non si riesce a parlare); · lock RIENTRATO -> si ripristina l'intero LockState, perche' il rientro si annuncia una volta sola e senza le ore non ci sarebbe piu' niente da dire. - `notify(..., tentativi=)`: il retry esisteva in `send` e non arrivava qui. venue_watch ora manda con 3 tentativi. - L'esito dell'invio finisce nel log del cron invece di sparire. 5 test nuovi. Il primo e' quello che conta — dopo un invio fallito, l'ora dopo ri-allerta — col suo controllo positivo (un invio riuscito consuma l'allarme UNA volta sola), senza il quale "ri-allerta sempre" passerebbe. Suite: 782 passati, 2 falliti (i due del gate GTAA, non toccati qui). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-28 12:34:44 +00:00
Adriano Dal Pastro	e5052a690f	usde: da patch d'emergenza a struttura — config, modulo unico, sorveglianza ... - config/live.json sezione `usde` (unica autorita', P1): indice, haircut 10%, tetto allerta quota 50%, soglie depeg 0.99/0.95 coi criteri dichiarati (P6) - src/live/usde.py: config + catena di prezzo (indice pubblico -> ticker -> 1.0 dichiarato) + valutazione PURA; shadow._collaterale_usde ora deriva da qui - scripts/live/usde_watch.py + cron_usde.sh (12:35 UTC, dopo la finestra reward): reward per delta netto trade (P12: senza inventare attribuzioni), depeg (crit ripetuto, resto a transizione, P9), quota anche per deriva passiva (N4); applica il verdetto di eligibilita' pre-registrato (>=1 reward entro 29/08) - serie data/live/usde_watch.jsonl sotto monitor_health (max 30h, P5: un watch fermo non deve leggersi come "va tutto bene"); baseline 14:17Z registrata - GATE USDE-01 in CLAUDE.md §4; test 775 (+17 in tests/test_usde_watch.py) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1	2026-08-26 15:11:44 +00:00
Adriano Dal Pastro	d597fc64e8	monitor: advance() consuma solo barre CHIUSE — serie rigenerate, guardia PREMATURO, 4 debiti chiusi ... S5.1 RIPARATO E RIGENERATO. Filtro condiviso src/live/paper_guard.py (barra open-labeled chiusa = ts + cadenza <= adesso) importato da tutti e 6 i monitor; serie rigenerate dallo stesso start_ts con scripts/live/paper_regen.py (evidenza in *.pre_regen_20260826.*): statarb +1,95 -> -1,61 (il ribaltamento del gate 27/09 previsto dall'audit), dvolspread -14,73 -> -4,41, xsr -4,98 -> -2,72, prevday invariato. Nessuna data di gate si sposta. Guardia cablata in monitor_health: stato PREMATURO (ultima barra che chiude dopo l'mtime, grazia 5 min, open_labeled=False per collect_chain) — sul dato vivo segnala i 5 rotti e tace sui 2 sani; dopo la rigenerazione 7/7 OK. paper_portfolio non rigenerato (GTAA su ADJUSTED_LAST: replay != serie registrata, P12), tolta la coda non chiusa. D6 pagata di nuovo nel fix: asi8 in pandas 3 e' in us, non ns — blindata con test su tre risoluzioni. S5.12 ESTESO: conftest devia anche trades.db (wrapper su connect: il default e' catturato alla definizione) e docs/journal/; book_executions.jsonl sorvegliato con impronta inizio/fine suite. S5.5 FATTO: test_leva_massima cancellato con nota (misurava frac*n_asset: con una chiave di scala avrebbe continuato a passare smettendo di controllare). S5.9 INDAGATO E RIPARATO (r0826_skh_band_drift): il dato regge (taglio 02/07 riproduce l'audit 1,6376, in-sample identico su ogni taglio); la deriva era la finestra hold-out — e la sola settimana 15-22/08 vale +0,35 di Sharpe hold-out. Il test ora taglia il feed al 02/07 e verifica la riproduzione stretta. Suite: 751 passati, 0 falliti. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1	2026-08-26 10:12:23 +00:00
Adriano Dal Pastro	426735448e	live: diagnosi del guasto venue, disaster-SL scoperto, isolamento per asset, cron :47 ... Nato da "stato trades" durante una manutenzione Deribit (system_maintenance 11051, 08:57-09:20 UTC). Contati i log invece che ricordarli: 1.499 giri dal 23/06, 3 con manutenzione, 5 traceback duri — e 4 dei 5 sono il NOSTRO gateway, non il venue. Le release Deribit escono il martedi' alle 09:00 UTC: il cron al :07 ci cadeva dentro per costruzione (21/07, 11/08, 18/08, 25/08). DIAGNOSI (src/live/venue_probe.py, nuovo) Sonda l'API PUBBLICA Deribit senza gateway e senza credenziali, e classifica il guasto: VENUE_MANUTENZIONE / VENUE_GIU / GATEWAY / IGNOTO. Prima ogni causa stampava la stessa riga ("conto non leggibile (offline)") con nota di diagnosi CABLATA — P4 violata, e il 18/08 il codice 11051 era gia' dentro il processo senza arrivare a chi decideva la gravita'. Parte solo dopo un guasto: sul percorso sano costa zero. P1 rispettata: la firma 11051 si importa da venue_watch.is_maintenance, non si ridichiara. P9: la manutenzione dentro lo slot declassa il titolo a info, ma solo su EVIDENZA della sonda (mai sull'orologio) e solo dentro la durata annunciata — oltre, RIALZA. Un gateway rotto di martedi' mattina resta al massimo. DISASTER-SL SCOPERTO (src/live/execution.py) ensure_disaster_sl cancella i bracket incoerenti PRIMA di ripiazzarne uno: fra le due chiamate la posizione e' senza stop. Se il ripiazzamento sollevava, l'eccezione risaliva a main() e il guasto peggiore aveva la faccia di un errore qualunque. Ora: due tentativi, poi stato `naked`, distinto da `place-failed` (P5). Non e' "non sono riuscito a proteggere": e' "ho tolto la protezione e non sono riuscito a rimetterla" -> allarme massimo, mai declassato. La SEQUENZA non e' stata invertita: piazza-poi-cancella sembra piu' sicuro ma "sembra" non basta con soldi veri senza misurarlo. ISOLAMENTO PER ASSET (scripts/live/book_execute.py) Il 21/07 un 502 dentro ensure_disaster_sl su BTC ha ucciso il giro intero: nel log ETH non compare — ne' ribilanciato ne' verificato nella protezione. Ora un asset che esplode non ferma il ciclo, e il giro degradato esce con codice 2. CRON :07 -> :47 Il vincolo vero non era ":07" ma "fuori dai ~26s del minuto tondo" (rate-limit per-IP auto-saturato dal collettore catena, misura del 30/07). Il :47 lo soddisfa e in piu' sta fuori dallo slot di release. PREVISIONE DICHIARATA (M12): 3 delle 4 finestre osservate sono rientrate entro l'ora -> il :47 ne avrebbe scavalcate 3 su 4; se martedi' prossimo becca comunque la manutenzione, la previsione e' sbagliata. WATERMARK AVVELENATO DAI TEST (tests/conftest.py, nuovo) Trovato addosso: lanciando la suite, data/live/equity_seen.json passava a $5.000 e il giro successivo mandava un allarme Telegram FALSO ("USCITA DI FONDI -86,6%"). Non cosmetico: cap_fallback = min(cap_config, watermark x frac) sarebbe passato da $334 a $2.500/asset, ~7,5x di leva su un conto da $668, sul ramo eq_fallback che allerta e NON blocca — cioe' i test potevano armare il pericolo che il watermark esiste per impedire. Riparato con una fixture AUTOUSE, non per-test: chiedere a ogni autore di ricordarsene ha gia' perso il 26/07 e il 21/08. Resta esposto lo stesso errore su trades.db e book_executions.jsonl. BLOCCATO, NON RINVIATO Il fallback diretto ai privati Deribit richiede chiavi API create dall'operatore: in locale esiste solo CERBERO_TOKEN. Il gateway resta un punto singolo di guasto non aggirabile (CLAUDE.md 5.11). La sonda dice di chi e' il guasto, non lo aggira. Test: 20 nuovi, nessuno tocca la rete; controllo positivo fatto (5 su 7 falliscono contro il codice vecchio). Suite 730 passati, 1 fallito — quello gia' noto di 5.9 (deriva dati). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1	2026-08-25 10:27:36 +00:00
Adriano Dal Pastro	782c0ce4bc	analista: manda l'analisi giornaliera su Telegram, con l'esito registrato ... La notifica porta una testata coi numeri che si leggono senza aprire nulla (equity, delta del giorno, cumulato, posizioni, leva, fill e round-trip) e sotto l'analisi del modello. Il trasporto Telegram e' pero' il punto singolo di guasto gia' misurato in questo progetto: un tentativo, nessun retry, esito mai registrato, 6,9% di invii persi (2/29). Su un messaggio al giorno sono ~25 messaggi persi all'anno, quindi qui sono state fatte due delle tre riparazioni dichiarate il 2026-08-23 e mai eseguite: (a) `send(text, tentativi=1)` — retry OPZIONALE con backoff. Il default resta 1, cosi' il comportamento e' invariato per tutti i chiamanti esistenti: alzarlo per tutti cambierebbe la latenza degli allarmi di venue_watch e book_execute su un percorso con soldi veri, e non e' una modifica da fare di straforo dentro un'altra funzionalita'. L'analista chiede 3. (b) `ultimo_errore()` — il motivo si registra nel punto in cui l'eccezione veniva ingoiata, e NON sopravvive a un invio riuscito. Regola gia' codificata il 29/07 su un altro percorso e mai applicata al notifier. La terza (marcare `alerted=True` solo a invio riuscito in venue_watch) cambia il comportamento degli allarmi e resta una decisione dell'operatore. L'esito finisce nel DB in tre stati: inviata / non configurato / FALLITA col motivo. Un invio perso che non lascia traccia, il giorno dopo, non si distingue da "non e' successo niente". E se l'analisi manca, il messaggio parte lo stesso dicendo PERCHE': senza quel ramo un guasto del modello si leggerebbe come una giornata senza nulla da dire. Taglio a 4096 caratteri dichiarato, mai silenzioso; HTML del modello neutralizzato. 708 test passano. Strategia, pesi, config INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 19:40:56 +00:00
Adriano Dal Pastro	f5d9409213	analista di bordo: un modello scrive la prosa del giorno, in un campo suo ... Aggiunto il quarto livello della pagina, tenuto separato dagli altri tre: numeri -> misurati dal feed e dal DB Lettura -> regole deterministiche, ognuna col suo id Analisi -> questo: prosa di un modello, che puo' sbagliare Nota -> l'operatore NON scrive dentro `nota`, che era la richiesta letterale: quel campo e' dell'operatore, ed e' cio' che a rileggere il giornale fra sei mesi permette di sapere chi ha scritto cosa. L'agente ha `analisi`, marcato col modello, con l'ora e con l'esito del controllo sui numeri. Gira via `claude -p` (verificato con env -i che risponda nell'ambiente nudo di cron), una chiamata al giorno sul giorno CHIUSO, tolte le tool. Tre guardie, una per ogni modo in cui una prosa generata rovina un registro: - NUMERO INVENTATO: numeri_non_supportati() estrae ogni cifra dall'analisi e verifica che compaia in cio' che il modello ha ricevuto. Oltre tre numeri liberi l'analisi e' RIFIUTATA e la pagina resta senza. E' un controllo debole per costruzione, e lo dichiara: prende l'invenzione, non il ragionamento sbagliato. - COMMENTO DI SE': senza_analisi() toglie dalla pagina la sezione dell'agente prima di dargliela. Al primo giro reale il modello aveva letto la propria uscita precedente e prodotto un paragrafo sull'avviso che si era preso il giorno prima — un ciclo di retroazione che in poche settimane avrebbe riempito il giornale di meta-commento, e che nessun controllo automatico puo' distinguere da prosa valida. - ANALISI DI IERI SPACCIATA PER OGGI: se il modello non risponde, la pagina resta VUOTA e il perche' viene registrato (stato + motivo). Il silenzio non diventa continuita'. Corretto anche un falso positivo mio: il tripwire validava sulla sola pagina mentre il prompt include anche il blocco storico, quindi bocciava un'equity vera. Una guardia piu' stretta del contratto produce allarmi che si impara a ignorare. Ogni guardia ha un test in entrambe le direzioni. 695 test passano. Strategia, pesi, config INVARIATI. Nessun ordine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 17:46:29 +00:00
Adriano Dal Pastro	10c373075c	libro di bordo: DB dei trade allineato col tempo + giornale giornaliero ... I trade erano salvati, ma non allineati col tempo: book_execute.py scriveva ts_utc = pd.Timestamp(r['last_data']), cioe' la data della BARRA DI SEGNALE. 19 righe su 19 a 00:00:00, e un trade (ETH 0.04 @ 1869.74) registrato SEI GIORNI prima di essere eseguito — fill vero 2026-07-14T14:00, scritto 08/07. L'ora vera esisteva solo in logs/cron_book.log, che e' gitignored, fuori dal backup e ruotabile: la cronologia reale del libro live viveva in un file che una rotazione avrebbe cancellato senza che nessuno se ne accorgesse. - src/live/tradesdb.py: parser del cron log (ora vera + contesto del segnale), FIFO con fee pro-quota, riconciliazione a tre fonti, sqlite in data/live/ (dentro il perimetro del backup). Le tre fonti si INCROCIANO e non si sovrascrivono: reconcile() riporta le divergenze e non ripara niente da solo. Il venue e' autorevole ma TRONCA (1 trade su BTC, 0 su ETH): dichiarato. - scripts/live/trades_db.py: --sync (idempotente, in cron_book ogni ora), --report, --reconcile. - src/live/journal.py + scripts/live/journal.py: una voce al giorno in docs/journal/YYYY-MM-DD.md — mercato (ritorni, RV30, TSMOM sugli orizzonti di produzione, DVOL con eta'), libro (TP01/SKH01, target, posizione, leva), P&L (equity del venue come autorita', scomposizione locale), salute. NIENTE narrativa automatica: il campo `nota` e' l'unico posto per il testo libero ed e' dell'operatore, mai riscritto da un ricalcolo. - book_execute.py: ts_utc = ora vera del fill, bar_ts = barra. Test di regressione sulla sorgente: se qualcuno rimette last_data, il test lo dice. - 62 voci di giornale ricostruite dall'arming a oggi. Tre difetti trovati dai test mentre scrivevo, non a occhio: il renderer cadeva in KeyError se mancava il blocco mercato (un giornale che non si scrive non e' un giornale); "24 giri attesi" su un giorno IN CORSO produceva un allarme a ogni esecuzione; e libro e P&L leggevano due istanti diversi, quindi la stessa pagina mostrava due equity. Strategia, pesi, config INVARIATI. Nessun ordine. 659 test passano. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 13:13:02 +00:00
Adriano Dal Pastro	8cfe15cbd5	fee_watch: sorvegliava i perpetual INVERSE mentre il book trada i LINEARI USDC ... Trovato in un check generale. INSTRUMENTS era la tupla cablata ("BTC-PERPETUAL","ETH-PERPETUAL") — gli inverse, regolati in BTC/ETH — mentre src.live.book.INSTRUMENT punta a BTC_USDC-PERPETUAL / ETH_USDC-PERPETUAL. Due conseguenze, e la seconda era gia' visibile ogni giorno nel log: 1. Il tier sorvegliato era di un prodotto che il book non tratta. Oggi coincidono (3.50/1.50 su entrambe le linee) ma la prova che si muovono in modo indipendente e' nel progetto: il cambio del 18/08 tocco' tick e size dei SOLI lineari USDC (inverse ancora tick 0.5 / min 10.0, lineari 0.1 / 0.0001). Un aumento sulla sola linea lineare sarebbe stato invisibile, e la regola decisa in anticipo (<=5bps nulla / >10bps rivedere il peso SKH01) applicata al numero sbagliato. 2. Il cross-check sui trade REALI — la fonte autorevole, cioe' quanto abbiamo davvero pagato — non poteva misurare nulla per costruzione: chiedeva la storia di uno strumento con zero fill. Stampava "NON MISURATO (nessun trade recente leggibile)" anche in un giorno con 4 esecuzioni. Verificato sul conto: inverse 0 trade, _USDC-PERPETUAL 3 (BTC) e 1 (ETH). FIX. INSTRUMENTS si DERIVA da src.live.book.INSTRUMENT: la divergenza non e' piu' un rischio da ricordare, e' impossibile. E non era un rename di due stringhe: le due famiglie hanno unita' DIVERSE. Inverse amount = nozionale USD e fee in valuta base; lineare amount = quantita' base e fee gia' in USDC. Ripuntare senza correggerle avrebbe dato, su un fill vero (0.001 BTC @ 74.305,80, fee 0,02600703 USDC), ~2,6e8 bps invece di 3,50 — senza sollevare nulla. Aggiunte convenzione() (lineare / inverse / IGNOTA: una famiglia non nota non si indovina, si dichiara) e fee_bps_di_un_fill(), entrambe pure. Il cross-check ora gira e da' 3,50 bps effettivi = il tier esatto; il report stampa lo scarto effettivo-tier con ⚠️ oltre 1 bps. Test 13 -> 17, verificati per MUTAZIONE: rimettendo la tupla cablata fallisce test_sorveglia_esattamente_gli_strumenti_DEL_BOOK; scambiando le convenzioni fallisce test_le_due_famiglie_hanno_unita_DIVERSE_e_scambiarle_non_fa_rumore, che contiene il controllo positivo (la convenzione sbagliata NON solleva niente, mente). 3a occorrenza in un giorno della stessa forma di difetto, dopo i test di book_live (potenza zero a libro flat) e la taratura di venue_watch (misurata con bitfinex mentre il live girava senza): un controllo puntato su una configurazione diversa da quella che gira passa sempre, e non sta controllando niente. REGOLA: un sorvegliante DERIVA il proprio bersaglio dal codice sorvegliato, mai lo ridichiara. Book, pesi, config, cron, soglie fee: INVARIATI. Suite 625 verdi, 1 rosso noto (test_gtaa_band_gate). NB: la prima corsa dopo il fix ha inviato una notifica Telegram legittima ("strumento nuovo nella sorveglianza"); lo stato e' poi assestato. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 19:19:22 +00:00
Adriano Dal Pastro	c932fab304	venue_watch: disciplina degli allarmi, specifiche contratto controllate, terza referenza ... Il 18/08 sono usciti quattro 🚨 identici con 'PRIMO PASSO: prelievo di prova' per una manutenzione Deribit annunciata, e tutti e quattro DOPO che il book aveva gia' ripreso a eseguire. Il book si era comportato bene (due giri di astensione, 'non eseguo a cieco'); il difetto era negli allarmi. 1. Il blocco piattaforma era un if secco senza memoria, accanto a un rilevatore tarato con cura che allerta una volta per streak. Ora passa da lock_step(), pura e testata: manutenzione entro tolleranza = un solo avviso morbido, che sfora = un solo 🚨 ('ha SFORATO'), blocco inspiegato = 🚨 subito, rientro annunciato una volta. public/status illeggibile NON e' un rientro. 2. Il messaggio diceva 'locked=true' cablato mentre il parser accetta anche 'partial': dichiarava un valore che non aveva letto, e il runbook manda a controllare proprio quel campo. Ora stampa e salva il valore grezzo. 3. Deribit ha cambiato tick e size dei perpetual lineari USDC il 18/08 e la tabella _CONTRACT, cablata a mano, non se n'era accorta. Nessun ordine rifiutato solo perche' i cambi erano riduzioni: e' andata bene per la direzione, non perche' ce ne fossimo accorti. Tabella aggiornata ai valori verificati e aggiunto check_specs(), che gira nel venue_watch orario (fuori dal percorso ordini) e dichiara la direzione: 'granularita'' = conforme, 'rifiuto' = il venue rifiuta. La tabella dichiarata resta l'autorita' per costruire un ordine, il venue e' il controllore. 4. Aggiunta Kraken come terza referenza: Coinbase ha comprato Deribit, e una referenza che e' la casa madre non misura piu' se Deribit scolla dal mondo. THRESHOLD_BPS e PERSIST_HOURS invariati, ma il consenso ora e' su tre serie e quel numero non e' ri-misurato: dichiarato nel codice e nel diario. La direzione dell'errore e' 'allerta di meno', non 'grida al lupo'. Test 23 -> 35 su venue_watch, suite intera 618 verdi. Book, pesi e config invariati; dry-run del book verificato. Diario: docs/diary/2026-08-19-*. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 10:10:55 +00:00
Adriano Dal Pastro	fb01c5714c	research(vrp): f misurato sul 10g — il mio sospetto era sbagliato, e il campione non basta ancora ... Book, pesi, config INVARIATI. Nuovo sorvegliante in cron_daily. IL CAMPIONE C'ERA GIA': 8 scadenze utilizzabili per asset su 8, entrambe le strutture, 16 osservazioni ciascuna. Non serviva aspettare per fare la misura; serve aspettare per rispondere alla DIFFERENZA, che e' un'altra domanda. CORREZIONE A UN ARGOMENTO PUBBLICATO POCHE ORE FA. Nel gate del tenore avevo scritto che la cella vincente 'sta massimizzando l'errore di modello' perche' compra l'ala piu' lontana. Misurato: il meccanismo e' confermato e piu' forte del previsto (f_long 5.85 contro 2.23) ma la conclusione era ROVESCIATA — quell'ala pesa il 3.2% del premio corto invece del 18.4%, quindi sul credito NETTO l'effetto e' minore: f_net 0.852 contro 0.718, il candidato ha un f MIGLIORE. Con f_net = (f_short - k*f_long)/(1-k), un f_long grande fa danno solo moltiplicato per un k grande: avevo guardato il fattore e non il peso. La decisione (nessun cambio) regge, ma su tre gambe invece di quattro. Artefatto di tick escluso prima di crederci: l'ask dell'ala sta a 22 tick mediani, minimo 15, 0% delle osservazioni a <=2 tick. LA DIFFERENZA NON E' STABILITA: appaiata per (asset, scadenza) fa +0.109 con IC95 [-0.047, +0.193], 11/16 positive -> contiene lo zero. Replica indipendente del canonico: 0.718 per un percorso con finestra DTE e pairing diversi da quello che stamattina dava 0.73. CRITERIO PRE-REGISTRATO, congelato in un test: >=40 coppie E ampiezza IC95 <=0.12 (oggi 16 e 0.241), prima gamba verso fine ottobre 2026. Il sorvegliante rifa' la misura ogni giorno e notifica una volta sola quando basta — lezione DVOLSPREAD, un lead senza sorvegliante e senza data e' un lead perso. Calibrazione della soglia verificata prima di fidarsene: con differenza vera nulla lo zero e' escluso nel 5.0/4.0/3.0% dei casi a n=16/40/60, cioe' il 5% atteso. Il test iniziale su seed fisso falliva perche' quel seed era uno dei 5% legittimi: sostituito con un test sulla proprieta'. REGOLE: (a) un fattore di errore si giudica moltiplicato per il suo peso; (b) prima di credere a un rapporto estremo su un prezzo piccolo, contare i tick; (c) una soglia sull'ampiezza di un IC richiede di verificarne la copertura; (d) 'non abbastanza campione' non e' 'nessuna differenza'. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 22:17:11 +00:00
Adriano Dal Pastro	d55eb13533	feat(chain): assorbita la raccolta catena opzioni, cerbero-bite dismesso ... cerbero-bite viene eliminato. L'unica sua parte irreversibile e' il DATO: una catena opzioni non si ricostruisce a posteriori (Deribit non serve book storici, non c'e' un secondo venue). Il codice si riscrive; le ore non raccolte no. ASSORBITO - scripts/live/collect_chain.py + scripts/cron_chain.sh (cron 25 * * * *): raccolta propria, ~570 strumenti/giro, ~3 min. - scripts/analysis/import_cb_archive.py: archivio 1.23M righe (2026-05-01+) + market_snapshots 17.402 righe (2026-03-26+: dealer gamma, gamma flip, rischio liquidazioni, funding cross — dati che non abbiamo altrove). - snapshot sqlite integrale in /opt/docker/backups/manual/ (SHA256). NON ASSORBITO, con motivo: motore credit-spread ETH (regola "niente short-vol da modello in deploy", conto a $52 contro minimo $720), GUI, kill switch/dead-man/audit (abbiamo venue_watch/edge_watch/monitor_health/ fee_watch), dvol_history (fetch_dvol.py ha storia PIU' LUNGA: 2020+ contro 2026-05), decisions/positions (0 posizioni). TRE DIFETTI DI BITE NON REPLICATI, tutti misurati il 30/07: 1. una chiamata per strumento invece di due (get_order_book?depth=3 da' gia' quote+greche+IV+OI+book+underlying) + prefiltro OI in una chiamata sola: 551 -> ~290 chiamate per asset; 2. pacing invece di raffica. Il carico non e' mai stato il problema: 570 chiamate/ora = 0.16/s DISTRIBUITE; bite le sparava in 26s (~44/s) e si auto-saturava il rate limit per-IP (12.186 risposte 429 in 26h, 96% al minuto :00). Primo giro reale: 574 chiamate, 0 risposte 429. Il minuto :25 e' scelto: :00 era la raffica, :07 e' cron_book (feed 5m di SKH01). 3. quote_status esplicito {ok, no_quote, error} e book_depth NULL su errore mai 0. "Book vuoto" e "chiamata fallita" sono cose diverse: e' per questo che il guasto del 29/07 (50% di quote perse, 38 ore) non produsse alcun segnale. Le righe ereditate restano 'unknown': bite non lo registrava e a posteriori non e' ricostruibile. Battuta di cuore in data/chain_collect/runs.jsonl anche a giro fallito, sorvegliata da monitor_health (1h, max_age 3h): un collettore fermo non produce niente, e il niente si legge come "nessun dato quel giorno". Difetto trovato per strada: due formati ISO nella stessa colonna (92 righe di backfill senza microsecondi). pd.to_datetime senza `format` ne inferisce uno solo e manda gli altri a NaT -> il dropna a valle li toglieva in silenzio, e la serie di contesto perdeva 5 settimane slittando dal 26/03 al 01/05. Corretto con format="ISO8601" e scarto RUMOROSO. Book, pesi, config, strategia INVARIATI. 537 test verdi. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 20:14:34 +00:00
Adriano Dal Pastro	7d64dd4c2b	live(feed): l'allerta funzionava, la sua CAUSA era una riga cablata ... Il 29/07 il feed 5m di SKH01 e' ricaduto sul certificato in 6 giri orari su 8 (eta' 265->685 min, +60 a ogni giro = firma esatta del fallback): latenza d'uscita da ~1h a ~11h, book flat, nessuna posizione esposta. L'allerta del 26/07 ha segnalato 6/6, poi ha stampato un perche' che non aveva misurato — la nota "fetch pubblico KO" era cablata, identica in ogni caso, compreso quello in cui la coda fresca E' attaccata e il vecchio e' il certificato. E la causa vera non era recuperabile per costruzione: _fetch_recent_5m ingoia l'eccezione di pagina con un break e a prima pagina fallita ritorna un frame vuoto, indistinguibile da "il venue non ha barre". Cablato: livefeed.last_fetch_error() (registra E logga nel punto in cui l'errore viene ingoiato) -> book_report.skh_feed_errors -> allerta con la causa. Stesso buco chiuso sul ramo gemello "conto offline", che la ragione l'aveva gia' in mark_src e non la stampava mai. La causa del 29/07 resta IGNOTA e va citata cosi': una prima stesura la attribuiva a un rate limit per-IP come se fosse un fatto -> rimossa, sarebbe stato lo stesso difetto che stavo correggendo scritto meglio. Cron spostato al minuto :07 come ripiego da UNA osservazione, dichiarato tale. Test 11 -> 16 (incluso il caso a meta' paginazione: coda parziale attaccata, mancano le barre PIU' recenti). Book/pesi/config/strategia INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:20:42 +00:00
Adriano Dal Pastro	fd05307c96	research(capitale): il lump-sum vale 2.45x, e la protezione dalla rovina non passa da GTAA01 ... Quattro filoni chiesti dall'operatore ("proposte"). Book, pesi, config: INVARIATI. 1. LUMP-SUM + VENUE (r0727_lumpsum_split.py). Tutte le traiettorie del 25-26/07 avevano START=600 cablato: mai misurato un versamento iniziale, mentre ~10k EUR stanno fermi altrove. Macchineria validata: con lump 0 riproduce IDENTICI i numeri del 26/07. - 10k EUR oggi e mai piu' nulla -> traguardo 17.2a, P 62%, rendita 61.58 EUR/g - equivalenza onesta: +154 EUR/mese per 13 anni = 24.523 EUR, cioe' 2.45x (la prima stesura misurava i versamenti risparmiati: numero giusto, domanda sbagliata) - col rischio venue: a 11.500$ lo split e' possibile (quota IB 26%, non 25%) e taglia P(perso tutto) da 18.4% a 3.5% a p=1%, costando 1.9-2.6pp di P(arrivare) - SPLIT-CASSA: seconda gamba ferma costa altri 0.6-0.8pp e protegge IDENTICO -> la protezione non e' bloccata dal PRIIPs: serve un CONTO, non uno sleeve 2. FEE WATCH (scripts/live/fee_watch.py). Nuovo schema Deribit dal 1 agosto senza numeri pubblicati -> sorvegliante invece di promemoria. Legge il tier base dall'endpoint pubblico (oggi taker 5.00 bps), applica la regola congelata e allerta sui cambiamenti. 3. MONITOR HEALTH (src/live/monitor_health.py). Tre gate pre-registrati si decidono su serie forward di cui una sola era sorvegliata. Misura coda E buchi interni: una serie bucata ma fresca passa qualunque guardia di freschezza. 4. BANDA GTAA01 25% VALIDATA (r0727_gtaa_band_gate.py). 30 celle, 29.9 anni, dpy=252. Non e' selection-on-holdout (4/30 IS, 5/30 OOS), DSR 0.999, tracking OK ma AL BORDO. Il modo di fallire non e' il de-levering (la vol non scende) ma la perdita di tracking. Impatto sul book: zero -> REBAL_BAND_USD non toccato, si applica al deploy. Aggiunto anche il bullet edge_watch, cablato il 26/07 e mai finito in CLAUDE.md. Test: 56 nuovi, 504/504 verdi. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 14:14:39 +00:00
Adriano Dal Pastro	95caeb87da	feat(live): allerta sul salto di equity — conferma il versamento, segnala un prelievo ... La verifica "il cap si adegua?" esisteva solo come sorveglianza di sessione, e il versamento slitta di giorni: una verifica che vive in una chat non e' una verifica. Resa permanente e generalizzata. `write_equity_watermark` ora ritorna {prev, new, pct} quando il salto fra due letture consecutive supera EQUITY_JUMP_ALERT = 10%; `book_report` lo espone come `equity_jump` e `book_execute` manda un Telegram con il NUOVO DIMENSIONAMENTO accanto (cap/asset, nozionale lordo, leva), cosi' il messaggio si legge senza aprire il repo. Il book ha vol ~0.4%/giorno: un salto del 10% fra due giri orari non puo' venire dal trading. Quindi l'allerta copre DUE casi con un meccanismo solo: - VERSAMENTO: conferma che e' atterrato e che il sizing lo ha seguito; - USCITA DI FONDI: un prelievo che non hai chiesto, o una perdita anomala. E' questo il caso che conta di piu', ed e' il motivo per cui la soglia e' a due code. Prima lettura in assoluto -> nessun allarme (senza un "prima" non c'e' un salto). Il watermark si aggiorna ANCHE quando allerta, o il cap resterebbe indietro (test cablato). 411 test verdi (+7). Strategia, pesi, cron, config INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 21:23:28 +00:00
Adriano Dal Pastro	a1b4416ac0	feat: EDGE WATCH — criteri di kill pre-registrati per il book LIVE ... "Come faccio a capire se l'edge e' morto?" scopre un buco: il progetto ha gate di kill pre-registrati per i CANDIDATI (DVOLSPREAD 24/10, XSR01 23/10, STATARB 27/09) e NESSUNO per il book che gira con soldi veri. La risposta implicita era "si vedra'", cioe' quello che il progetto non accetta dai candidati. LA RISPOSTA SCOMODA: non si puo' sapere in fretta. Sharpe rolling a 12 mesi: il 56% dei casi "edge morto" e' indistinguibile da uno vivo. Un anno brutto e' rumore, non informazione. CRITERIO A (ritorno, book intero): Sharpe rolling 36 mesi sotto -0.5. Tarato sul nullo (edge intatto) -> falso kill 1.8% in 10 anni; controllo positivo (edge morto) -> lo riconosce nel 91% dei casi, rilevamento mediano 3.8 anni. La lentezza non e' un difetto della regola ma statistica: a 12 mesi la stessa regola ucciderebbe un edge VIVO nell'80% dei casi. Non esiste una versione veloce e onesta. CRITERIO B (TP01, che e' DIFENSIVO): serve un criterio diverso perche' il LOO del 26/07 ha misurato il contributo hold-out di TP01 negativo nel 99.1% delle configurazioni d'ancora — firma dell'assicurazione, che paga premio negli anni senza incendio. "Non ha guadagnato" NON e' evidenza di morte. Criterio: in un anno con DD buy&hold > 10%, il DD di TP01 deve restare sotto il 75%. Storico 8 anni di sinistro, 8/8 superati (protezione 1.8x-34.4x). Negli anni SENZA sinistro il criterio non si valuta: non c'e' informazione. Questo criterio e' VELOCE dove l'altro e' lento. COSA SUCCEDE SE SCATTANO (dichiarato ora per non deciderlo nel momento sbagliato): (A) il book NON si spegne da solo -> revisione con weights_tilt_null + deflated-Sharpe sui dati nuovi; spegnere e' decisione dell'operatore. (B) fallito in DUE anni di sinistro consecutivi -> TP01 non assicura piu' e il peso 75% va rimesso in discussione. CABLATO: scripts/live/edge_watch.py in cron_daily.sh, allerta Telegram, non tocca l'esecuzione. Stato oggi: Sharpe 36m +1.51, protezione 8/8. IL LIMITE, DETTO: il criterio A rileva la morte ~4 anni dopo, e non e' riparabile con una regola migliore (e' il contenuto informativo dei dati). La difesa vera e' che il piano regge a un edge dimezzato (11.6 -> 15.8 anni, P(20a) ancora 77%) e che i rischi VELOCI (venue, esecuzione, feed) hanno sorveglianze che scattano in ore. 404 test verdi (+11). Book, pesi, config INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 21:14:53 +00:00
Adriano Dal Pastro	ab5bcace16	feat: VENUE WATCH — tripwire di fallimento exchange, cablato live ... Risposta a "trova un sistema di protezione da fallimento exchange" SOTTO IL VINCOLO della decisione appena presa (100% Deribit fino a $20k). Se non si puo' ridurre l'ESPOSIZIONE, l'unica leva e' il TEMPO: il modello di rischio del mattino assumeva il salto a zero istantaneo, ma i fallimenti reali non lo sono (Mt.Gox mesi, FTX ~72h, e misurato qui: Bitfinex 2018-19 dislocato per 2.324 ore consecutive). SEGNALE: un venue che gata i prelievi rompe l'ARBITRAGGIO -> il prezzo si stacca dal consenso e ci resta. E' |scarto|, non il segno (Mt.Gox a premio, un venue in fuga a sconto: stessa cosa). Consenso = venue USD indipendenti (Coinbase, Bitstamp), mai USDT. Deribit sta a 3 bps dal consenso in mediana su 8 anni (65.043 ore BTC + 64.541 ETH). TARATURA CONGELATA: 100 bps persistenti 4h a segno costante. Criterio DICHIARATO PRIMA, perche' i due ovvi sbagliano in versi opposti (provati entrambi): "minimi bps" -> 25/24h consuma 24 delle ~72h di FTX; "minime ore" -> 500/2h MANCA FTX (margine 0.6x). Regola: zero falsi allarmi in 8 anni + margine >=3x sul caso storico piu' debole -> soglia <=100bps -> poi minima latenza. Margine 3x FTX / 5x Quadriga / 10-20x Mt.Gox, zero falsi allarmi con crash COVID, maggio 2021, LUNA e novembre 2022 inclusi. CONTROLLO POSITIVO SUPERATO (un rilevatore tarato per non segnalare e' indistinguibile da uno rotto): puntato su Bitfinex 2018-19 scatta 22 volte, episodio piu' lungo 2.324h a +447bps. 22 dove il problema c'era, 0 su Deribit. E la durata risponde alla domanda vera: un venue gated resta dislocato per settimane, quindi 4h di latenza sono trascurabili. ECONOMIA: falso allarme = 0.248% atteso (flat 3g misurato sul book reale a ogni data d'inizio); vero positivo = 100% salvato. Break-even p > (falsi/anno) x 0.00248: a 1 ogni 8 anni serve p > 0.031%. Il valore sta nella SPECIFICITA', non nella sensibilita'. CABLATO: src/live/venue_watch.py (nucleo puro) + scripts/live/venue_watch.py, in cron_book.sh PRIMA di book_execute (se Deribit e' in stress l'allarme deve partire anche quando l'esecuzione fallisce per la stessa ragione). Tre stati OK/ALERT/BLIND — "non vedo" non e' "va bene". ALLERTA, NON BLOCCA: l'azione e' prelevare (manuale; una chiave con permesso di prelievo sarebbe essa stessa un rischio) e bloccare non protegge un saldo che e' a rischio anche stando flat. Runbook pre-deciso nel docstring. NON COPRE, e non e' un argomento per riaprire il 26/07: un fallimento SENZA finestra (furto chiavi, sequestro, exit-scam) non lo prende nessun tripwire. ERRORI CATTURATI IN SESSIONE: - break-even calcolato sul p5 invece che sulla media (8.3x piu' severo, conclusione ribaltata); - ipotesi meccanica sbagliata: credevo che i crash dislocassero a segno ALTERNATO. Falso, sono a segno costante anche loro (perp sotto spot per ore in cascata). A separare sono ampiezza e durata, non il segno; - la prima corsa tronco' il campione da 8 anni a 29 GIORNI per un inner-join con Kraken (che serve solo ~700 candele) e la copertura era gia' stampata a video: una diagnostica stampata NON e' un controllo. Ora c'e' una guardia che ferma lo script. 2a occorrenza in un giorno dopo GTAA01; - il controllo positivo era finito dentro il ramo `else` -> non girava mai, cioe' esattamente il difetto che doveva prevenire. Book, pesi, config INVARIATI. 359 test verdi (+23). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 19:38:19 +00:00
Adriano Dal Pastro	031b71bf54	ops(live): sorveglianza freschezza feed SKH + correzione dei docstring sulla latenza d'uscita ... T1 (TP di SKH01 come limit resting on-book) NON e' stato implementato, per misura. Leggendo il codice di produzione: TP01 e SKH01 tradano lo stesso strumento con una sola posizione netta Deribit, quindi un ordine on-book al livello di SKH chiuderebbe anche quota TP01. Misurati i due ostacoli: (A) segno compatibile nel 97% dei trade che escono in TP = risolvibile; (B) divergenza modello/live apparentemente bloccante. Ma (B) non esiste: resample_5m NON scarta il bin 230m in corso (21 barre 5m su 46 nell'ultimo bin) e _skyhook_positions ci itera dentro -> il live rileva gia' SL/TP intra-barra, entro ~1h dal tocco. I docstring che dicevano "usa solo barre chiuse" e "latenza fino alla chiusura della barra 230m" erano FALSI e hanno guidato tre analisi (02/07, 24/07, T1). Corretti sul posto. Conseguenza: la lente `hourly` sottostima il path live di +0.081 Sharpe FULL di book (23/23 offset, banda appaiata); il live vero sta sopra il canonical sul FULL, e il fix richiesto sarebbe un declassamento (+0.054 vs +0.081) in cambio di ordini parziali sul netto in un percorso con soldi veri. Cablato invece il problema vero trovato per strada: fresh_5m fallisce in SILENZIO (fallback al certificato, rigenerato 1x/giorno) -> la latenza d'uscita di SKH01 passa da ~1h a ~1 giorno senza segnalazione, e nessun controllo esistente scatta (il gate di staleness guarda il feed di TP01). Stesso schema del feed-freeze del 14/07. * livefeed.feed_age_minutes: pura, eta' dalla CHIUSURA della barra, None = non misurata, clamp sugli skew d'orologio * book_report espone skh_feed_age_min (max fra gli asset) * book_execute stampa lo stato e allerta su Telegram sopra skh_feed_max_age_min (30m) Scelta dichiarata: ALLERTA, NON blocca. Bloccare fermerebbe anche TP01 (nettato sullo stesso strumento) per un guasto di rete; forzare SKH flat chiuderebbe posizioni buone su un glitch. Follow-up dichiarato: la stessa barra parziale tocca gli INGRESSI (ent[n-1] da breakout non confermato). Disaccordo in 1 bin su 112, ma con 3 entry nel campione la taglia non e' stimabile. E' un cambio di strategia, non di strumentazione -> misura dedicata prima. Strategia, pesi e cadenza del cron INVARIATI. Nessun ordine inviato. Suite 266 verdi. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 20:20:01 +00:00
Adriano Dal Pastro	841f48c319	ops(live): cabla il forward-monitor DVOLSPREAD nel cron + gate pre-registrato ... Chiude la lezione (c) dell'ondata 26/07: "un lead in forward-monitor senza monitor e senza scadenza e' un lead perso" — DVOLSPREAD era in limbo da 35 giorni. Ora ha config congelata, monitor nel cron e gate con data. Config congelata = la cella scelta IN-SAMPLE (zwin=180 k=2.0 lw=0.6 zw=1.1 tgt=0.17 svw=60), NON quella pubblicata dall'agente: quella era 83a/729 sull'hold-out ma 471a/729 in-sample e fallisce il deflated-Sharpe (0.947), la congelata lo passa (0.953). Riusa make_book di r0726_dvolspread_gate, nessuna reimplementazione. Strumentazione specifica: il book va flat quando manca il DVOL, quindi un feed rotto produrrebbe zeri che contati come evidenza direbbero "nessuna perdita" invece di "nessuna misura". Contabilita' a 3 stati (attive / flat-da-segnale / flat-senza-dato), finestra misurata in barre ATTIVE, e guardia che esce 1 se FROZEN diverge dallo stato salvato. Gate pre-registrato: kill 2026-10-24 se Sharpe < -0.50; decisione 2027-01-24 solo se Sharpe>0 E marginale ADDS E deflated-Sharpe>=0.95 E weights_tilt_null; veto d'integrita' se barre attive <80% (si estende, non si decide su dati mancanti). La soglia su Sharpe e' debole di proposito: con ~180 barre SE(Sharpe)~1.4, una soglia alta sarebbe finta precisione. Inception 2026-07-25, apertura +0.184 = $111/gamba (cap $300). Book/pesi INVARIATI. Suite 255 verdi. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 20:05:30 +00:00
Adriano Dal Pastro	71b39c2c86	ops(live): staleness-gate bloccante + report Telegram giornaliero ... Presa in carico operativa del conto Deribit (delega dell'utente). Nessun cambio a strategie, pesi o sizing: il libro resta TP01 0.75 + SKH01 0.25. 1) STALENESS-GATE (protezione di capitale, era un follow-up mai cablato) Il 2026-07-14 alle 14:00 UTC il book ha COMPRATO ETH $75 con l'ultima barra del feed certificato ferma al 2026-07-08: feed congelato da 6 giorni (diario 2026-07-15-feed-freeze). I due gate esistenti non potevano vederlo — il conto ERA online e la posizione ERA leggibile: proteggono dai problemi di CONTO, non da un feed morto. Il diario raccomandava un alert; qui il gate e' BLOCCANTE, coerente con gli altri due ("non opero a cieco"), col disaster-SL on-book come rete su eventuali posizioni gia' aperte. - config/live.json: max_data_age_days = 2; - book_execute: _data_age_days() + blocco PRIMA di costruire DeribitTrader (nessuna sessione autenticata aperta su dati morti) + alert Telegram con il comando di sblocco; data illeggibile => trattata come stantia; - letto con cfg.get(default): una config priva della chiave ricade sulla soglia sicura invece di sollevare KeyError dentro il percorso con soldi veri; - tests/test_book_staleness_gate.py: 8 casi, incluso il funzionale che riproduce la situazione del 14/07 (online + posizione leggibile + ordine pronto) e verifica che DeribitTrader NON venga costruito. - tests/test_book_live.py: i 3 report finti avevano last_data="2026-07-01" hardcoded -> ora data fresca calcolata. Quei test riguardano skh_error / pos_error / eq_fallback, non la staleness: con la data fissa sarebbero marciti al superamento della soglia. 2) REPORT TELEGRAM GIORNALIERO (scripts/live/telegram_daily.py, in cron_daily.sh) Gli alert esistenti scattano solo su ordine o errore: con il libro flat — stato normale e corretto col trend giu' — significava silenzio per settimane, indistinguibile da un sistema morto. Il report dice ogni giorno dove sta il conto, perche' non opera e quanto manca perche' operi (con la convenzione TP01 corretta: media dei SEGNI, quindi servono 2 orizzonti su 3, non basta il piu' breve). Sola lettura: un test verifica che il modulo non possa inviare ordini. Stato al commit: equity $596.92, flat e a target, disaster-SL -30% verificato (placed @ $1,308.7 sull'ultima posizione). TP01 0.00 su entrambi: accensione a BTC $78.680 (+22,7%) / ETH $2.370 (+27,2%). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 10:05:47 +00:00
Adriano Dal Pastro	b8c9430bd7	feat(research): XSR01 "Cross-Sectional Residual" — candidato nuovo in forward-monitor ... Primo candidato da molte ondate a superare marginale-ADDS, deflated-Sharpe 0.95, tre null avversariali e il test di lag, con corr ~0 a TUTTI e 5 gli sleeve attivi. COS'E'. Il meccanismo congelato di STATARB-RESID (W=45, sgn=+1, residuo OLS causale su BTC, z-score, tanh, vol-target 20%) applicato ai 50 alt HL, con posizioni DEMEANATE cross-sezionalmente ogni giorno. Il demeaning annulla ALGEBRICAMENTE la gamba BTC comune — sum(p_i-p̄)(r_i-r_btc) = sum(p_i-p̄)r_i — quindi non e' un paniere di coppie ma una strategia cross-sectional dollar-neutral, e l'ampiezza effettiva passa da 4.5 a 37.4. NB: non e' nato da un'idea nuova ma dalla DIAGNOSI di un fallimento (l'ampiezza effettiva 4.5 indicava un fattore comune da togliere). NUMERI (2.6 anni): Sharpe netta 1.82 (lorda 2.70), maxDD -2.6%, vol 2.3%. GATE: marginale ADDS (robust_oos + beats_noise_null + non-hedge + has_insample_edge); deflated-Sharpe 0.985 PASS; corr TP01 0.060 / XS01 -0.019 / VRP01 -0.001 / SKH01 0.001 / GTAA01 0.071; book a w=15% HOLD 2.36 -> 2.51, DD invariato. SCETTICO (r0725_statarb_demean_skeptic.py): 3 null A FEE-NEUTRALE (permutazione cross-sezionale / casuale / temporale a blocchi) centrati a ~0.01, candidato lordo 2.70 sopra il MASSIMO di 300 estrazioni (p<0.004); lag 1.82/1.19/0.81/0.51 a +0/1/2/3g = decadimento dolce di segnale lento, non firma di look-ahead; non ridondante con XS-momentum semplice (corr 0.17-0.29). Nota di metodo: i null vanno confrontati A FEE ZERO — permutare un segnale ne fa esplodere il turnover, quindi a fee piene il null perderebbe per COSTO invece che per assenza di informazione (p-value trionfale e falso). NON NEL BOOK, 3 motivi dichiarati: (a) storia 2.6a monoregime e CRESCENTE (Sh 2024 1.03 / 2025 1.98 / 2026 3.11) -> edge recente; (b) weights_tilt_null FALLITO (gate_pass=False a 10% e 15%); (c) margine di costo sottile — 1.82 a 0.05%/gamba, 0.93 a 0.10%, NEGATIVA a 0.20%, turnover 38.5% del lordo/g su 50 alt anche illiquidi con slippage NON modellato (rischio #1). ESEGUIBILITA': ticket/gamba $1.73 a $600 (sotto min-order $5 -> STAT-MODE oggi), $5.76 a $2000, $14.41 a $5000 -> diventa reale a ~$5k, non ai ~$20k di XS01. CABLATO: scripts/live/paper_xsr.py (config CONGELATA, 3 libri MODELED $2000 / REAL $600 / REAL $5000 con min-order per gamba, stato append-only) in cron_daily.sh; gate PRE-REGISTRATO a forward-day 0 (r0725_xsr_deploy_gate.py): decisione 2026-10-23, deploy solo se Sharpe>=1.0 E haircut di eseguibilita' a $5000 <=40% (se sfonda -> RITIRO a prescindere dallo Sharpe). tests/test_paper_xsr.py: 7 casi che bloccano config, dollar-neutralita', causalita' dello step, min-order e la trappola dei timestamp tz-aware (astype int64 -> epoche 1970, gemella di quella dell'ondata 2026-07-01). Book e pesi INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 09:48:11 +00:00
Adriano Dal Pastro	7ebb1b8c37	feat(goal50): CC01 regime watch (funding 30g HL, trigger 10/15% ann.) + diario R1 yield/basis ... R1 (web): carry al fondo del ciclo (BTC 0-4%, ETH negativo), Aave 4-5% = pavimento, 0k -> 2.5-4 eur/g; MiCA lascia a IT esattamente Deribit+HL; fisco 33% dal 2026 (muro capitale x1.5). Watcher read-only, oggi: BTC +8.4% / ETH +7.4% 30g = QUIET. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 20:57:13 +00:00
Adriano Dal Pastro	67f7b89e4c	chore(live): ritira paper_trend inerte -> Old/ — sostituito da paper_portfolio ... Il paper trader standalone TP01 (paper_trend.py) era inerte dal 2026-06-19 (n_bars=0), non in cron, e sostituito da paper_portfolio (TP01+XS01, gira ogni giorno). Archiviato in Old/scripts/live/ e stato congelato rimosso. Book live INTATTO: shadow.py legge PAPER_STATE con guardia .exists() -> degrada a FALLBACK_CAPITAL=2000 (identico allo stato congelato) e paper_pos=None. Dry-run di book_execute identico prima/dopo (conto online, HOLD su BTC/ETH). - git mv scripts/live/paper_trend.py -> Old/scripts/live/paper_trend.py - rm data/paper_trend/ (state inerte, gitignored) - CLAUDE.md: 3 riferimenti -> paper_portfolio + nota di ritiro - live_trend.py + shadow.py: hint/commento fallback legacy aggiornati Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:42:29 +00:00
Adriano Dal Pastro	567046953d	fix(book): gate fail-safe posizione + diagnostica equity — niente errori silenziosi nel path live ... Terza+quarta chiusura del pattern "eccezione ingoiata -> stato safe silenzioso" in src/live, dopo skh_error (31369b3). Emerse durante la verifica del gate SKH01. Opzione A (gate fail-safe posizione): - shadow._positions: se la read della posizione reale Deribit lancia, assume flat MA ora ritorna un pos_error esplicito (prima solo una note mai propagata). - Propagato shadow_report -> book_report -> book_execute: se ONLINE ma posizione IGNOTA, l'esecutore NON opera a cieco (return + alert), come gia' per 'online'. Opzione B (diagnostica equity, no halt): - shadow._equity/shadow_report: se ONLINE ma equity reale non leggibile, il book ripiega su paper_cap (~$2000) invece del conto reale (~$598) -> sovradimensiona ~33%, ma l'hard-cap $300/asset limita il downside. Nuovo flag eq_fallback -> book_execute stampa warning + alert Telegram MA prosegue (niente gate: la scelta e' solo diagnostica, l'hard-cap gia' protegge). Test: +8 (4 gate A, 4 diagnostica B). Suite 156/156. Path live pulito (skh_error/pos_error/eq_fallback = None). Diario 2026-07-01-book-live-error-surfacing.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-01 22:39:59 +00:00
Adriano Dal Pastro	31369b358c	fix(book): esponi skh_error nel book live — niente flat SKH silenzioso ... book_report scriveva skh_error in un dict locale MAI incluso nel return -> r.get("skh_error") era sempre None. E book_execute non lo leggeva comunque. Risultato: se il feed SKH (fresh_5m) fallisse, il book forzava SKH a flat in silenzio, indistinguibile da un flat legittimo -> entry SKH reale mancato, nessun alert. Fix: - src/live/book.py: skh_error come variabile esplicita, esposta nel dict di ritorno (None normalmente). Il fail-safe (SKH->flat, TP01 indipendente sul suo feed certificato) resta invariato. - scripts/live/book_execute.py: emette la riga di log + alert Telegram quando skh_error e' presente. - tests: book_report cattura-e-flagga l'errore; book_execute lo fa emergere (log + notify). Suite 148/148. Contesto: verifica del gate SKH01 dopo 193 run flat dal 06-23 (gate SANO — 335/341 entry storici, shorta i crash; flat legittimo: ultimo entry 06-06 chiuso ~06-08 pre-arming). Questo chiude il rischio latente scoperto durante la verifica. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-01 22:26:02 +00:00
Adriano Dal Pastro	c52e0ab3f8	feat(forward): cabla STATARB-RESID nel forward-monitor PAPER (lead ortogonale ETH/BTC) ... Forward-monitor del LEAD dello sweep 2026-06-29 (relative-value ETH/BTC, dollar-neutral 2 gambe), il primo stream insieme ORTOGONALE (corr->book 0.027, beta-mkt 0.013) ED eseguibile a $600. - scripts/live/paper_statarb.py: forward-only, doppio libro MODELED($2000)/REAL-$600 (haircut fill), riusa il segnale ESATTO di orthogonal_signals.py (niente reimplementazione). Config CONGELATA W=45 sgn=+1. - Cablato in scripts/cron_daily.sh accanto a paper_prevday. Stato runtime in data/paper_statarb/ (gitignored). - test tests/test_paper_statarb.py (frozen config + advance forward/idempotente + haircut $600 basso). Correzione di etichetta (verificata): la cella vincente e' sgn=+1 -> NON mean-reversion ma relative-MOMENTUM sul residuo (dislocazioni ETH-vs-BTC continuano a 1d; sgn=-1 perde -1.4 IS). Diario + CLAUDE.md aggiornati. Test 146/146. Nessun deploy, forward-only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 20:58:29 +00:00
Adriano Dal Pastro	db738bce3b	feat(live): arma il BOOK DERIBIT (TP01+SKH01 nettati in software) ... Estende l'esecuzione live da TP01-only al book Deribit-only completo. TP01 e SKH01 tradano lo STESSO strumento (una sola posizione netta per conto su Deribit) -> netting in software: un solo ordine/asset verso il target netto. - src/live/book.py: target NETTO per asset = clamp(0.5*E*(0.75*tp_frac + 0.25*skh_sign), ±cap). Riusa current_target (TP01, causale) + _skyhook_positions (segno L/S, book 230m) + conto reale. - src/live/execution.py: rebalance_signed() — reconcile CON SEGNO (long/short, flip via close+open, reduce reduce_only). La close resta sempre permessa (si esce da qualunque posizione). - src/live/livefeed.py: fresh_5m() — feed 5m certificato + coda recente EFFIMERA da Deribit pubblico (stesso simbolo inverse, in-memory, NON scrive su disco -> dati certificati intatti; fallback al certificato su errore). Solo SKH01 ne ha bisogno (e' a 230m); TP01 e' giornaliero. - scripts/live/book_execute.py: executor doppio-gate (config + --execute), disaster-SL on-book sulla posizione netta, log in data/live/book_executions.jsonl. Feed SKH fresco (live_feed=True). - scripts/cron_book.sh + crontab ORARIO: book idempotente ogni ora (riconcilia al netto corrente); rimossa la riga live_execute.py (TP01-only) dal cron daily per non far collidere i due. - config/live.json: ARMATO (execution_enabled=true). cap/asset $300 split 75/25, disaster-SL -30%. Tutto flat all'arming -> nessun ordine finche' un segnale non arma. - tests/test_book_live.py: 20 test (sizing 75/25, cap, flip/close/reduce, parita' pesi backtest, gate-safety, reconcile con trader fittizio, merge/dedup feed + fallback, loader onorato). 76/76 pass. CAVEAT: exit SKH SOFTWARE (latenza fino a fine barra 230m; solo disaster-SL on-book); TP01 scende a peso 0.75 (max $225/asset); SKH01 resta research-grade (equity daily-step, margine DD ETH sottile). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 21:43:27 +00:00
Adriano Dal Pastro	010d1f0733	feat(combo): paper combo NUDO vs PROTETTO (guardia-DD -4%) affiancati + dashboard ... paper_combo traccia forward entrambe le versioni; dashboard mostra nudo + protetto. Guardia-DD: de-risk 0.4x a DD>-4%, ri-rischia a -1.6% (backtest MaxDD 8.4->5.8%, 2022 -4.4->-1.8%). Opzioni escluse (non aiutano il grind). Container ricostruito. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 12:59:07 +00:00
Adriano Dal Pastro	3b552a92da	feat(combo): paper-trade cross-venue TP01 (Deribit) + GTAA (IB), forward-only ... L'unica cosa vera/deployabile della ricerca: diversificazione TP01+GTAA (corr 0.21, blend Sharpe ~1.5, DD dimezzato). Si va in PAPER cross-venue. - src/portfolio/gtaa.py: GTAA sleeve di prima classe (trend difensivo TSMOM vol-target 12% su SPY/QQQ/IWM/TLT/GLD/HYG). gtaa_returns() Sharpe 0.64; gtaa_weights() = pesi ETF correnti azionabili. - scripts/live/paper_combo.py: tracker forward-only blend 50/50 TP01+GTAA (crypto compoundato su grid giorni-di-borsa), mostra posizioni azionabili su entrambi i venue. Solo gambe eseguibili. - fetch_ib_equities.py --only: refresh mirato dei 6 ETF GTAA per il cron. - cron_daily.sh: up gateway IB + refresh ETF GTAA + avanza paper_combo (dipendenza cross-venue gestita). Init 2026-06-23: TP01 flat (risk-off), GTAA SPY13/QQQ8/IWM9/TLT17/GLD2/HYG17/cash34. Catena gateway->refresh->paper testata end-to-end. PAPER (rischio zero), valida l'operativita' cross-venue. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 12:26:51 +00:00
Adriano Dal Pastro	5cce7acfe1	live(monitor): prevday-breakout in FORWARD-MONITOR (paper, non deploy) ... Il lead ortogonale a TP01 sopravvissuto all'onda intraday entra in forward-monitor (stesso trattamento di XS01 STAT-MODE / STA05), NON in esecuzione reale. - src/strategies/prevday_breakout.py: segnale CONGELATO (params fissi anchor=1, k=0.30, simmetrico, vol-target 0.20/30/2.0), self-contained. Bit-identico all'agent di ricerca (max diff 0.0): BTC full Sh 1.18/hold 0.92, ETH 1.09/1.42; marginal ADDS, earns_slot, corr_hold -0.01, non-hedge. - scripts/live/paper_prevday.py: forward-only paper, traccia DUE libri — MODELED ($2000 continuo) e REAL-$600 (salta i ribilanciamenti < min-order $5) -> il gap = haircut di fill reale che lo scettico aveva segnalato. Inizializzato forward-only da oggi. - cron_daily.sh: avanza il monitor ogni giorno. - test: param congelati + causale + bounded + long-short. Suite intera verde. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-21 15:37:41 +00:00
Adriano Dal Pastro	bf84bc91e2	feat(live): alert Telegram su esecuzione ed errori ... src/live/notifier.py (stdlib, no-op se non configurato): legge TELEGRAM_BOT_TOKEN/CHAT_ID da env o .env(.mainnet) gitignored. live_execute.py invia alert su: ordine eseguito (✅), ordine non verificato (⚠️), disaster-SL piazzato/fallito (🛡️/⚠️), conto offline, e qualsiasi eccezione (🛑). Nessun alert nei giorni flat/HOLD (no rumore). Config gia' presente in .env -> alert attivi. Test config: uv run python -m src.live.notifier "msg". Test 28/28. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 16:09:09 +00:00
Adriano Dal Pastro	e5e2d3ec9b	feat(live): disaster-SL on-book con lifecycle completo (idempotente) nel loop di esecuzione ... ensure_disaster_sl(): garantisce UN solo STOP_MARKET reduce_only a ~-30% coerente con la posizione, ad ogni run del loop, per asset: - flat -> cancella i bracket orfani; - long -> assicura lo stop (size = posizione, prezzo al tick); - gia' coerente (1 bracket, amount~=, stop entro 5%) -> lascia com'e' (niente churn ne' gap di protezione fra cancel e place). - deribit.py: open_orders (merge type all+trigger_all), disaster_stop_price. - execution.py: cancel_order + ensure_disaster_sl. - live_execute.py: gestione bracket ogni run, gated come l'esecuzione. Validato armato: flat -> disaster-SL 'flat' (cleanup), zero ordini. Test 28/28. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 15:47:30 +00:00
Adriano Dal Pastro	bc9e322d0d	feat(live): loop di esecuzione GATED di TP01 (execution_enabled + --execute, default OFF) ... scripts/live/live_execute.py porta il conto reale al target di TP01 (min(0.5*frazione*equity, cap/asset)): apre/riduce/chiude via DeribitTrader.rebalance_to(). DOPPIO GATE: config/live.json execution_enabled=true (master, default false) E flag --execute; senza entrambi e' dry-run. Reconciliation post-ordine + log in data/live/executions.jsonl. TP01 flat -> 0 azioni. - execution.py: rebalance_to() (open/reduce/close al target); MAX_AMOUNT alzato a tetto hard anti-fat-finger (~$630/$430 su conto ~$600), il sizing operativo lo decide config max_notional. - config/live.json: master switch + cap/asset $300 + min ordine $5 + disaster_sl_pct. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 15:37:51 +00:00
Adriano Dal Pastro	cddea50c5a	feat(live): conto USDC -> strumenti lineari; entrata/uscita da Old; dashboard LIVE separato da PAPER ... Correzione post-micro-test (il conto e' USDC, non BTC/ETH): - deribit.py: INSTRUMENT -> BTC/ETH_USDC-PERPETUAL (lineari, gli unici eseguibili sul conto USDC); notional_to_amount gestisce i lineari (amount in base-coin = notional/price); + quantize_price; trade_history (read-only) per i trade reali. build_rebalance_order passa il prezzo. - shadow.py: sizing col prezzo; espone live_trades (trade reali eseguiti su Deribit). Entrata/uscita verificate (logica presa da Old/src/live/execution.py): - execution.py: open() market verificato (state=='filled' + trade, fill/fee reali, filled_amount autorevole), close() market reduce_only (le CHIUSURE si tentano SEMPRE, senza cap), disaster-SL STOP_MARKET reduce_only. Cap di size SOLO sulle aperture. Fill dataclass. - microtest.py: usa open()/close(); safe-close se l'apertura non e' verificata. Dashboard: sezione PAPER (backtest+forward) separata da sezione LIVE (conto reale Deribit: shadow TP01 + Trades REALI eseguiti). Test 27/27. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 15:15:45 +00:00
Adriano Dal Pastro	c00f6016df	feat(live): micro-test esecuzione REALE su Deribit mainnet (USDC linear) — round-trip validato ... Primo ordine reale post-reset, a rischio ~0 ($6 notional, leva 0.011x). Scoperto che il conto e' USDC -> strumento eseguibile = perp LINEARE BTC_USDC-PERPETUAL (l'inverse BTC-PERPETUAL fallisce 'not_enough_funds'). Round-trip BUY/SELL reduce_only verificato: fill reali, fee reali (0.0064 USDC), posizione tornata a FLAT, costo totale $0.0071. - src/live/execution.py : DeribitTrader (estende DeribitRead) con market order + verifica posizione, GUARDRAIL hard (solo BTC_USDC-PERPETUAL, amount <= 0.0002 BTC). Niente leva per-ordine (Deribit non la accetta: l'esposizione la decide la SIZE). - scripts/live/microtest.py : runner round-trip, default DRY-RUN, --live per inviare. Pre-flight ABORT se posizione preesistente; chiusura reduce_only; verifica ritorno a FLAT. - src/live/deribit.py : aggiunti spec contratto LINEARI USDC (BTC/ETH_USDC-PERPETUAL). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 15:06:53 +00:00
Adriano Dal Pastro	9c48cdd884	feat(live): SHADOW MODE TP01 su Deribit mainnet (sola lettura) + dashboard 3-way ... Validazione esecuzione di TP01 a RISCHIO ZERO: gira il loop live contro dati/conto/posizioni REALI del mainnet, costruisce gli ordini di ribilancio esatti e li STAMPA invece di inviarli. Niente testnet (e' la causa del reset v2.0.0: feed farlocco) -> shadow su mainnet reale + micro-test a size minima come unica via per il fill (passo successivo). - src/live/deribit.py : client Deribit mainnet SOLA LETTURA (ticker/conto/posizioni via Cerbero MCP) + costruttore ordini deterministico (notional->contratti, step BTC $10/ETH $1, quantizzazione, delta vs posizione). Nessun metodo di trading, by design. - src/live/shadow.py : shadow_report() condiviso CLI+dashboard (niente drift); degrada con grazia se il mainnet non risponde. - scripts/live/live_trend.py : CLI shadow (--no-net offline, --equity override). Verificato su mainnet reale: conto $598.07, posizioni flat, TP01 flat -> 0 ordini, parita' col paper OK. - src/live/dashboard.py : box "Shadow live" + titolo/note al 3-way (TP01+XS01+VRP01). - tests/test_live_shadow.py : 9 test deterministici (quantizzazione, sizing 50/50, entry/exit/None, parita' live==backtest). Suite 26/26. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 14:01:12 +00:00
Adriano Dal Pastro	26e977d338	feat(monitor): dashboard PAPER del portafoglio attivo (TP01+XS01) + paper forward loop ... src/live/dashboard.py: web UI stdlib (:8787) che mostra metriche (FULL/HOLD Sharpe, DD, CAGR), per-sleeve, posizioni correnti, equity (backtest + paper forward), ultimo dato. Solo MONITOR, esecuzione REALE disabilitata. scripts/live/paper_portfolio.py: forward-only del portafoglio (StrategyPortfolio su active_sleeves), stato persistente in data/paper_portfolio (gitignored). Dockerfile + docker-compose.yml minimali (solo servizio dashboard; runner/esecuzione restano in Old/). Container pythagoras-dashboard ricostruito col codice nuovo (il vecchio mostrava dati pre-reset). Mount data/ read-only. .dockerignore esclude Old/data/.venv/.git/.env. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 08:57:55 +00:00
Adriano Dal Pastro	12754c4908	fix(TP01): bug look-ahead ffill mixed-TF -> deploy a >=12h (1d), strategia DIFENSIVA ... Segnalato: ffill MIXED-TIMEFRAME su barre open-labeled (resample label="left") gonfiava il 4h (~1.60 -> reale ~1.1). Ri-verifica per-SINGOLO-TF leak-free (guard prefix-recompute, leak=0 su 4h/6h/12h/1d): FULL Sh piatto ~1.3, hold-out 2025-26 MIGLIORE a 1d (Sh 0.31 / +3.5% vs buy&hold -39%). Conclusione adottata: NON scendere sotto le 12h (sotto, costi+overfit dominano senza vantaggio). - trend_portfolio.py: canonica PORT LF1d; resample_tf/resample_1d (resample_4h deprecato deploy); docstring con nota look-ahead + natura DIFENSIVA (taglia DD ~6x, non alpha). - paper_trend.py: deploy a 1d (resample_1d, build_bars). 5 test passano. - CLAUDE.md: TP01 ridescritta (>=12h/1d, gotcha ffill mixed-TF, difensiva). - tp01_lowfreq.py + diario 2026-06-19-tp01-lookahead-fix-lf.md. Gotcha: mai ffill/combine mixed-TF su timestamp open-labeled (close propagata indietro = leak). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 19:04:38 +00:00
Adriano Dal Pastro	d152941360	integra(TP01): merge ricerca branch strategy-research-2026-06 (squash) — strategia vincente + harness + track A-E ... Integra il lavoro della linea di ricerca parallela (AdrianoDev), verificato indipendentemente col mio gauntlet onesto (regge il hold-out 2025-26 su entrambi gli asset, plateau 1h/4h/1d): - src/strategies/trend_portfolio.py TP01 (TSMOM 30/90/180 vol-target 20% lev2x long-flat, 50/50 BTC+ETH) - src/backtest/harness.py harness onesto (load + backtest_signals no-leakage + OOS) - scripts/research/track{A,B,C,D,E}_*.py + trackD_timing.py (le 5 track della ricerca) - scripts/live/paper_trend.py paper trader forward-only di TP01 (no esecuzione reale) - tests/test_trend_portfolio.py (5 test, passano) + 6 diari trackA-E + synthesis - CLAUDE.md aggiornato con l'esito ricerca (TP01 vincente, mean-rev morto, onesta su €50/g) Squash (non merge) per NON portare in git i ~68MB di data/_feed_backup/*.bak che il branch aveva committato per errore: esclusi + data/_feed_backup/ e data/paper_trend/ ora gitignorati. Storia granulare del branch conservata sul ref origin/strategy-research-2026-06. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 18:55:04 +00:00