Non e' verificato sotto quale valuta Deribit elenchi lo spot USDE_USDC: la
quotazione (USDC) o la base (USDE). cancella_residui interroga entrambe e
unisce per order_id prima di applicare il filtro instrument+label, cosi' un
residuo elencato sotto USDE non si accumula in eterno per non essere mai
letto. Se una delle due letture solleva, solleva come prima (nessun try
aggiunto attorno al giro).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
hasattr perche' U1 e U2 si uniscono dopo questo rilascio: DeribitTrader oggi non ha
set_open_cap, e l'hasattr evita che l'unione dei due rami rompa in un senso o nell'altro.
Si toglie l'hasattr al merge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
open_orders solleva RuntimeError se 'all' o 'trigger_all' falliscono, invece di ritornare []
(un bracket disaster-SL perso su 'trigger_all' e' lo stesso difetto di una posizione persa su
'all'). ensure_disaster_sl avvolge la lettura di posizione+open_orders in try/except: su
eccezione ritorna {"state": "unknown", "notes": ...} senza cancellare ne' piazzare, distinto
da "naked" (protezione tolta e non rimessa). shadow.shadow_report chiama open_orders gia'
dentro try/except (non toccato).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Prima, con equity reale non leggibile il giro dimensionava comunque un ordine sul paper_cap
($2.000 nominali) e lo mandava; con SKH ignoto il target restava quello (fail-safe solo nel
segno). Ora: se non si sa quanto vale il conto o qual e' il segnale, nessun rebalance_signed —
ma il disaster-SL si controlla LO STESSO per ogni asset (dipende da posizione/mark, non da
equity/segnale). Giro degradato -> exit 2, solo se armato (non in anteprima dry-run).
Fill persi: rebalance_signed puo' eseguire un fill (es. il close di un flip) e poi sollevare nel
passo successivo (l'open dall'altra parte) — quel fill spariva perche' la lettura di `newpos`,
PRIMA del giro che lo registrava, andava in eccezione a sua volta. Estratta la registrazione in
_registra_fill(...), chiamata SUBITO dopo ogni fill (anche quelli di RebalanceParziale, nuova
eccezione di execution.py con .fills/.causa) e PRIMA di leggere la posizione; la lettura ora e'
in un try separato, non fatale (pos_after=None + "reconcile: pos illeggibile" se fallisce).
Aggiornati due test che assumevano il comportamento vecchio (eq_fallback "prosegue" sul paper
capital) e il guard sulla sorgente di test_tradesdb.py (bar_ts ora e' un parametro di
_registra_fill, non piu' `r['last_data']` inline).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
DeribitTrader.set_open_cap(instrument, usd_cap, mark) deriva amount_max = 1,10*usd_cap/mark
dal cap di config del libro; _submit lo usa quando presente, MAX_AMOUNT resta il DEFAULT per
chi non lo chiama (il micro-test). Firma per chi la richiama prima di rebalance_signed (U2):
trader.set_open_cap(inst, r["cap_per_asset"] * r["scala"], mark).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
#29 B2: lo stato si salvava PRIMA dell'invio e il ritorno di notify() non si
leggeva — un invio fallito restava "gia' detto" per l'episodio intero. Schema
di cuscino_watch.py: nuove_condizioni()/rec["allertati"] contano una
condizione come "gia' detta" solo se l'invio precedente e' RIUSCITO; un
record vecchio senza `allertati` vale come "tutto allertato" (nessun rispam
retroattivo). Lo stato si scrive una volta sola, a fine giro.
#35 B3/B4: la quota non e' piu' una decisione dell'operatore rinviata a
lunedi' — dal 10/09 (issue #7) e' DERIVATA dal cuscino USDC
(usde._nota_cuscino) — quindi tolti DECISIONE_QUOTA_DAL, quota_da_decidere()
e la notify "la decisione di QUOTA e' dovuta". Il tetto di allerta IDONEO
legge c["quota_max_frac"] invece del 50% cablato. La riga "margine" non dice
piu' "conto SEGREGATO" (il modello e' Cross X:SM dal 31/08): stampa il totale
USDC + USDE scontato del cross, coi numeri che la funzione ha gia'.
Le due modifiche toccano lo stesso blocco (allarmi + STATE write + stampa) e
non si possono separare per hunk senza rischio: un solo commit per il file.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Con un asset BLIND e nessun ALERT, severity restava None e il titolo del
runner cadeva sul default piu' forte ("PRIMO PASSO: prelievo di prova") per
un episodio che e' "non vedo", non "stress misurato". run_once ora assegna
severity="blind" quando c'e' un BLIND senza ALERT (ALERT resta piu' forte, P9);
_titolo distingue il caso con "venue_watch CIECO — referenze non leggibili,
nessun giudizio sul venue". La ripetizione oraria di BLIND non e' toccata.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
save_state girava sempre dopo l'eventuale notify, anche quando l'invio
falliva: il giro dopo diff_vs confrontava lo stato nuovo con se stesso e il
cambiamento (o il livello AZIONE) spariva senza essere mai stato detto. Ora
lo stato si salva solo se non serviva un invio, o se l'invio e' riuscito.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Il gateway cerbero-mcp non accetta time_in_force (PlaceOrderReq non ha il
campo): un limit riempito solo in parte restava APERTO per sempre e si
accumulava a ogni giro. cancella_residui() pulisce lo spot USDE_USDC dai
residui con label "usde-quota-*" prima del ciclo; nel ciclo, un ordine con
filled < amt viene cancellato subito dopo, e una cancellazione fallita ferma
il ciclo (mai un secondo ordine con un residuo vivo).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
scrivi() chiamava J.salva() prima del controllo su --secco: un giro "a secco" scriveva
comunque le sezioni misurate nel giornale. Ora salva() (e scrivi_file, che era gia' dopo
il return) girano solo quando non e' secco; rendi_markdown() tollera l'assenza della riga
in DB (nota/analisi vuote, verificato).
Test nuovo in tests/test_analista.py (non c'e' un test_analista_u4.py: l'analisi indicava
i due file journal/tradesdb, questo fix e' su analista.py e segue la convenzione un
file-di-test-per-modulo del resto della suite).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Il gateway manda size/size_currency in assoluto e il segno a parte in direction:
letta com'era, uno short risultava un long e close()/ensure_disaster_sl decidevano
lato ordine e prezzo dello stop dal segno sbagliato.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
C2: fifo_roundtrips ora apre un lotto SHORT quando un sell non trova lotti long da chiudere
(prima il resto spariva in silenzio), chiude prima il lato opposto e apre l'eccedenza nel
segno del fill — anche a meta' dello stesso fill (inversione long<->short). stato_aperto e
report() portano la direzione del lotto residuo.
C10: un fill "NON VERIFICATO" a qty 0 (place_order error) non entra piu' nel FIFO ne' in
stato_aperto (WHERE qty > 0 in rebuild_roundtrips/stato_aperto); resta nel DB marcato
(verified=0), non e' scomparso.
test_fifo_non_mescola_gli_asset aggiornato: una vendita ETH senza lotti long ora apre uno
short invece di sparire (era il comportamento che C2 corregge). Test nuovi in
tests/test_tradesdb_u4.py.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
#27: due movimenti dichiarati nello stesso intervallo si sommavano al posto di sovrascriversi
(l'aggancio "dichiarato+rilevato" ora cerca solo fonte=="rilevato").
#35 C9: salute() non conta piu' il giro dell'ora corrente prima che scatti (minuto :47 +
margine, MINUTO_GIRO costante di modulo).
#35 C15: la finestra "ultimi 7 giorni" della concentrazione ora copre 7 giorni di calendario,
non 8 (baseline = ultima lettura al o prima di giorno-7 fine giornata).
#35 C7: il drawdown si calcola sulla serie equity al netto dei movimenti di capitale certi,
cosi' un prelievo non si legge come perdita di trading e un versamento non alza il picco.
Test nuovi in tests/test_journal_u4.py; tests/test_journal.py aggiornato (l'orologio del
test su salute() era reale e non deterministico, ora e' fissato).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Un'eccezione sulla lettura del conto USDE valeva 0 USDE: se il conto ne aveva davvero, l'equity
totale risultava sottostimata senza che nulla lo dicesse. Ora _collaterale_usde ritorna None +
la nota dell'eccezione, e _equity propaga l'ignoto (real_eq None -> eq_fallback, non un numero
falso). shadow_report.online guardava solo il mark di BTC: con ETH in fallback il giro si
considerava comunque online. Ora richiede TUTTI i mark da mainnet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
src/live/giri.registra_giro: una riga jsonl {ts ms, campi} dopo una misura completata,
mai un'eccezione. edge_watch, fee_watch, scale_watch, vrp_f_watch, venue_news (cron_daily)
e venue_watch (cron_book, orario) scrivono data/<dir>/runs.jsonl; niente riga senza misura.
monitor_health: sei MonitorSpec (30h i giornalieri, 3h venue_watch), open_labeled=False.
Stessa riparazione di cc01 (#10, #12), generalizzata. Primo giro notturno: NUOVO, non allerta.
Test: incrocio P1 percorso/RUNS, misura -> una riga, non-misura -> nessuna. Suite: 1098 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ISTRUZIONI diceva «capitale ~$635» (equity reale ~$4.5k dal 04/09): valore ridichiarato,
forma di P1, e fuori pagina per la regola 1 delle istruzioni stesse. Ora il capitale e'
l'equity in pagina. Aggiunto che fifo_roundtrips chiude un round-trip per lotto: piu'
round-trip che fill nello stesso giorno e' atteso (l'analista lo segnalava come anomalia).
Test: nessun importo in ISTRUZIONI; FIFO e lotto nominati.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- §1: «tetto ALLERTA quota 50%» contro config usde.quota_max_frac 0.85 (dal 06/09;
0.50 resta default di codice in src/live/usde.py). Frase «dopo un bonifico si» troncata
dal 10/09 (37d1565), ricucita.
- §1 OMBRA: dal 21/09 il token dell'ombra e' a scope di sola lettura (Adriano/TradingBook#19),
misura del 21/09 riportata; il segreto resta pieno, la chiave read-only la crea l'operatore.
- §4 STATARB: regola del 24/07 copiata verbatim da scripts/research/r0724_statarb_deploy_gate.py
(esiti, guardie, addendum 25/07 non binding). Nessun verdetto anticipato.
Autorizzato da Adriano il 21/09 dopo la revisione settimanale.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Commit di soli dati dalla produzione: le pagine le scrive cron_daily e la
revisione cron_review, nessun cron le committa (commit a mano da sempre).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- CLAUDE.md §1 OMBRA: cron :44 sulla stessa crontab, legge il conto con la STESSA chiave live di
cerbero-mcp (verificato per hash), scrive solo nel suo albero (3 giri misurati, nessun file di
data/ o logs/ di qui cambiato), non invia per assenza di codice e non per permesso. §12 rimanda.
- cc01: ogni giro con entrambi gli asset misurati scrive data/cc01_regime/runs.jsonl (ts ms,
stato, funding 30g/7g); se non vede, non scrive e lo dice. monitor_health: MonitorSpec
giornaliera, max_age 30h, percorso incrociato con cc01.RUNS da un test (P1).
- tests/test_cc01_regime_watch.py (4, rossi prima). Suite completa: 1074 passed.
Autorizzato da Adriano il 16/09 dopo la revisione settimanale.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Solo documenti generati da cron_daily e revisione.py, nessun codice. Su richiesta di Adriano 16/09.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Eccezione alla regola «PG non si tocca» autorizzata da Adriano il 16/09, solo questo file.
Verificato: --help exit 0, giro completo QUIET (BTC 30g +9,0%, ETH +9,4%), test_cli_flag 55 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Calendario letto dal web (Fed 61 riunioni + BLS 88 release CPI, 2019-2026), TP01 orario dalla stessa
held di sleeves, null location-matched 1000 estrazioni (Δ vero al 4,2° pctl), per anno 2/8.
Registro §78, memoria 20-ondate (D-bis), diario 2026-09-10b.
Fixes#9
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016kqvff47UBGeYfj1QeN4zE
Decisione dell'operatore 10/09 («riportarla a quota in autonomia»). Verificato da revisione fable
(10 segnalazioni, 9 applicate; loop numerico su usde_convert.piano: nessuna sequenza vendita→acquisto).
- quarto stato ECCEDENTE: slack > cuscino_riacquisto_frac (0,40) x cuscino => acquisto di USDE fino
allo stesso bersaglio della vendita, q* = 1 - 0,30 x (1 + cuscino_margine_frac 0,20) = 0,64.
Isteresi [0 ; 0,40] x cuscino con bersaglio unico 0,20: per oscillare servono +-8,6% di equity
USDC (~$380); un bonifico alza lo slack di 0,7 x importo e sopra ~9% dell'equity ricompra da solo.
- le tre frazioni (preavviso/margine/riacquisto) in config/live.json sezione usde, lette da
usde.bande_cuscino() che verifica l'ordine; quota_target 0,70 TOLTO (slack zero per costruzione).
- notifier.notify: html.escape su titolo e valori — la prima allerta vera (13:53Z) era andata persa
per un '<' nudo; allerta_errore registrato nel record (P3).
- da ECCEDENTE un fallimento si ritenta ogni 24h (non 4 Telegram/giorno per sempre); bande fuori
ordine => BLIND con motivo, non un traceback ingoiato dal cron.
- CLAUDE.md §1/§4/§5.17, config _nota_usde/_nota_cuscino, diario. 0,64 e' una DERIVAZIONE
dell'autore, non la quota decisa il 30/08 (0,70): dichiarato, da confermare.
- test: 1070 (+8 netti).
Fixes#7
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016kqvff47UBGeYfj1QeN4zE
Decisi dall'operatore il 2026-09-10, verificati da revisione fable (15 segnalazioni, 12 applicate).
- usde_watch: TRADE_LIMIT 1000 (count max Deribit) e trade_copertura(): lista troncata o ultima
lettura oltre la finestra di 24h del gateway => somma NON leggibile, reward non attribuito (P12).
Riga del 07/09 corretta nel log con campo `correzione` (400 USDE erano acquisti, non reward).
- cuscino_watch.py (cron :53, monitor_health): equity USDC contro cuscino derivato da
usde.cuscino_richiesto_usd (formula spostata in src/live/usde.py, usde_convert la importa);
OK/PREAVVISO/SCOPERTO/BLIND; sotto zero lancia usde_convert --quota quota_ripristino(0.20)=0.64
--esegui con guardie (execution_enabled, depeg_warn, 1 tentativo/6h). Primo giro: PREAVVISO, +$26.
- usde_convert: il tetto del venue vale solo in ACQUISTO (bloccava la vendita).
- paper_prevday: GATE PREVDAY-01 cablato (2027-06-21, kill Sharpe giornaliero < -0,50 su >=180 g
attivi, veto >=80% barre ricostruibili + divergenze non crescenti con soglia materiale).
Oggi: +0,95 su 81 g, 1942/1943 ricostruibili, kill NON MATURO.
- CLAUDE.md: arming 20/06 (TP01) / 23/06 (BOOK); piano EUR 5.000 chiuso col versamento 04/09
($2.414,68 dal balance, dichiarato); SCALA-01 non prima del 2027-02-28 (A2 dal 01/09);
PREVDAY-01 con data, kill, veto; §5.17 riparato con i limiti dichiarati (ratchet, slack zero a 0,70).
- test: 1062 (+31): test_cuscino_watch (16), test_paper_prevday_gate (8), test_usde_watch (+5).
Fixes#2Fixes#3Fixes#4Fixes#5Fixes#6
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016kqvff47UBGeYfj1QeN4zE
- src/live/revisione.py: materiale (CLAUDE.md, config, crontab, git, monitor_health, stati dei
sorveglianti, 7 g di giornale e diari, ~195k caratteri), prompt con dieci regole (sola lettura, fonte
per ogni segnalazione, solo numeri del materiale, §3 non si ripropone, idee nuove solo citando la
memoria, gate con data e criterio), guardia sui numeri, rapporto firmato (P13), Telegram = Sintesi
con taglio dichiarato; modello muto o risposta senza titoli -> rapporto «NON eseguita» + 🚨 (P5).
- scripts/live/revisione.py (guardia cli.valida, --secco/--no-telegram/--quiet/--giorno/--modello),
scripts/cron_review.sh, crontab `15 6 * * 1`.
- primo giro reale: il prompt su argv moriva con `Argument list too long` senza rapporto ne' allerta ->
prompt su stdin, ogni eccezione diventa errore dichiarato; `analista.pulisci` toglieva i titoli.
Secondo giro: docs/revisioni/2026-09-09.md, stato sospetta (cifre in formato italiano), nessun URGENTE.
- scartati con la memoria: autoregolazione dei parametri, generazione automatica di strategie, macro
da internet (diario 2026-09-09c, memoria 40).
- test: tests/test_revisione.py (18) + 2 in test_cli_flag; suite 1031/1031.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjj5vPEBoAJrB23P6RjKzs
- cblib.causale(s, cadenza): spot_series e dvol_series escono causali (asof = ultima chiusura NOTA);
il DVOL giornaliero era una seconda serie con lo stesso difetto (fino a 24h avanti), verificato contro
l'API pubblica a 1h. Regolamento ST alle 08:00 invece delle 09:00.
- §11 riprodotto al millesimo su worktree HEAD (0,714 [0,690-0,779], n=19, flag --al) e rimisurato:
0,712 [0,664-0,732]; solo spot 0,721, solo DVOL 0,693, DVOL orario di controllo 0,717. Mediana onesta
BTC 1,45 → 2,12, fee 1,51x/1,87x. r0730: 0,73 → 0,71. §75: ETH pre 0,76, BTC durante 0,89 (orario 0,83).
skew panel ≤0,005. vrp_f_watch: f canonico 0,732 → 0,706, differenza +0,097 [+0,042, +0,140].
- r0909 senza doppio shift, contesto sul DVOL del giorno; r0822 regime su date di calendario; r0901
join riallineato (bit-exact). Aperti con costo: DVOL orario (−0,04/+0,06 nel crollo), spot 5m (≤25 min).
- test: +3 causalita' in test_cb_chain_vrp, anti-doppio-shift in test_r0909; suite 1011/1011.
- revisione fable: 16 segnalazioni, tutte applicate (fra cui un «−1,8% in un'ora» che era +3,9%).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjj5vPEBoAJrB23P6RjKzs
Quattro misure (r0909_*), nessun cambio a libro/pesi/config:
- libro nei crolli: −0,48%/g nei 160 giorni ≤ −5%, positivo per finestra dal 2022
per la gamba short di SKH01 (108% dei guadagni); beta 0,0769 riprodotto (§46);
il peso di SKH01 resta chiuso dal gate (in-sample).
- crollo catturato 1-5/06/2026 a quote vere: f_net 0,74 = rally; put δ−0,10
1,92× il modello; a vol bassa e fuori dal gate di VRP01 → §3 non si riapre.
- XRP terza gamba (harness r0822_sol_leg): hold-out −0,169 in 0/24, un anno buono.
- universo Deribit: liquidi solo BTC/ETH/XRP/SOL; XS01 13/19; BTCDVOL future
non negoziabile; PAXG non misurato.
Revisione fable: due conclusioni smontate (MTM 2,6× era un artefatto di quote;
«8/12 guadagna» era l'ordine delle classi). Debito §5.18: cblib.spot_series
+ asof guarda un'ora avanti (feed 1h etichettato all'apertura).
Test Opus: 92 nuovi, suite 1008/1008; due difetti del verdetto XRP corretti.
Docs: diario, RESULTS §74-77, CLAUDE.md, memoria 20/50, README; journal 07-08/09.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017zJjHUS7mf4pnGE6pq9RTt
Su autorizzazione dell'operatore («usa piu' USDE», «cerca % massima raggiungibile»):
- usde_convert al 31,8% (774 USDE), poi sonda a saldo crescente r0906_usde_tetto_sonda.py
(passi 100->20->4->1, doppio rifiuto prima di scendere, conferma a saldo neutro): da 31,8%
a 68,7% in 39 ordini @ 1,0005, ZERO rifiuti. Fermata dal cuscino di regolamento (70%,
derivato da config), non dal venue. «Il 70% non e' raggiungibile ne' ora ne' mai» (31/08)
e' falsificato: il tetto e' sparito, non scalato. Non spiegato, puo' tornare.
- config: venue_cap_frac -> null (misura in venue_cap_misurato), quota_max_frac 0,50 -> 0,85
(il valore scelto dall'operatore il 30/08 per questo scenario).
- debito §5.17: nessuno sorveglia il cuscino USDC (slack $58; una perdita del libro lo consuma
da sola).
Versamento di prova di EUR 25 il 25/08 08:00Z (dichiarato dall'operatore): +3,3% su $647, sotto
la soglia del 10% del rilevatore, contato per 12 giorni come trading.
- data/live/movimenti_dichiarati.jsonl (append-only, nel backup) letto da
journal.movimenti_dichiarati; movimenti_capitale lo fonde coi rilevati (fonte dichiarato,
importo dell'operatore, dopo = prima + importo; dichiarato+rilevato se coincide; fuori
letture o riga rotta -> avvisi). Report e nota di giornale lo dicono.
- trading da arming +87,35 -> +62,45; TWR +11,98% -> +7,83%. CLAUDE.md §2 aggiornato.
- tests: +6 in test_journal (conftest isola il file). Suite 916 verdi.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KSnordG9FT4q8M4MVm85GQ
Ultimo commit del README: 2026-06-04. Reset v2.0.0: 2026-06-19. Per 75 giorni la prima pagina
del repo ha pubblicato la libreria pre-reset (FADE/HONEST/PAIRS/TSMOM/SHAPE, PORT01-06) con
Sharpe 7,84/10,06 e CAGR ~79% come risultati correnti — cioe' esattamente i numeri che §2
elenca sotto "non citare", dalla libreria che il reset aveva dichiarato artefatto. Meta' dei
file citati non esiste piu' (strategies.yml, portfolios.yml, scripts/waste, scripts/portfolios,
src/live/multi_runner.py), e l'esecuzione descritta era su TESTNET, che e' la causa del reset.
- README riscritto (423 -> 152 righe): cosa gira adesso (TP01+SKH01 75/25, ~$2.050, cadenza
oraria :47), i numeri nella lente di §2 (TWR +10,6%, non la crescita del conto), la riga che
ordina il piano, il metodo e i suoi sei requisiti, il dato, la struttura VERIFICATA file per
file, i comandi, i gate con le loro date, l'obiettivo con la sua onesta'.
- CLAUDE.md §0 e memoria 40: registrato il difetto e la lezione — un reset invalida anche i
documenti che nessuno rilegge; l'inventario di cosa cita numeri morti va fatto il giorno del
reset, non 75 giorni dopo per caso.
- Diario 02/09c: sezione col confronto riga per riga; coda dichiarata (l'inventario completo
degli altri documenti pre-reset non e' stato fatto).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XDJsH3iDSaBns3ccpPBwiu
MISURATO oggi durante la revisione: `trades_db.py --help` non stampava l'uso, cadeva in sync()
e riscriveva meta.ultimo_sync. Nessuno dei 18 script di scripts/live/ usava argparse: un flag
sbagliato era il ramo else. Su journal.py avrebbe scritto pagina e riga di DB, su analista.py
avrebbe speso una chiamata al modello e mandato un Telegram.
- src/live/cli.valida: prima istruzione di ogni __main__, prima di connect()/sync/rete.
--help -> 0 con l'uso; flag ignoto, valore mancante o posizionale -> 2 con l'elenco dei
previsti (P4). NIENTE argparse: cambierebbe messaggi, codici d'uscita e --help di script
che il cron gia' chiama.
- 18 script cablati (i 3 che scrivono + 14 + cc01), flag invariati.
- tests/test_cli_flag.py (30): elenco DERIVATO dalla cartella (P1), valida come prima
istruzione, uso che documenta i flag, e i flag che il CRON usa davvero restano accettati
(P15/P16); end-to-end su --help e flag ignoto con trades.db non toccato (M15).
Verificato a mano: monitor_health --quiet, trades_db --sync --quiet, book_execute dry-run.
Debito §5.15, primo passo: balance_watch (orario) registra `usde_usdc` a ogni campione — None
con la ragione se illeggibile, mai 1,0. Il cablaggio nel bound quando la serie ha storia.
Pulizia dalla revisione: tests/helpers.carica_script al posto della 15a copia del loader
importlib (5 file del libro live); il fill di prova via upsert_fills invece di un INSERT che
lasciava verified NULL; asserzioni non ancorate al padding; movimenti_capitale accetta le
righe gia' lette (una SELECT invece di due ai due lati di una scrittura del cron).
Test 910 verdi (+52). Diario 2026-09-02c.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XDJsH3iDSaBns3ccpPBwiu
Il feed 1h certificato si ferma alle 00:00: per le letture successive `asof` dava la stessa
barra a t0 e t1, mercato "fermo" = 0, e qualunque calo >=10% del giorno sarebbe stato un
"movimento" scorporato come prelievo (giornale dal 25/08, report da oggi). Con feed assente
tutto era "ambiguo" e il report stampava e1/e0-1 sotto l'etichetta TWR.
- journal.movimenti_capitale: stato "mercato non misurabile" (feed fermo/assente/barra
mancante) => ambiguo con la ragione; leva_tetto = min(frac x n x scala, LEVA_LORDA_MAX) (P1).
- journal.rendimento_twr: salto non classificabile => twr E trading None con motivo.
- journal.pnl_giorno CHIAMA rendimento_twr (prima rifaceva cum - certi: "entrambi la chiamano"
era falso); la pagina stampa il TWR; analista qualifica il cumulato "di cui versati".
- trades_db --report: la classe di ogni salto con la sua misura (mercato max a leva piena).
- book_execute docstring: banda dello stop -33,5%/-26,5% (era invertita), "non costa ordini"
-> micro-ordini di ri-taglia (22/48, C2), latenza <=1h solo con feed fresca, conteggi di
r0823 al posto di "raddoppia" (2 contro 1 e' rotolante vs pavimento sulla riga 4h; la
peggiore misurata e' 24h).
- test_book_cadenza: LTF_MIN importato da skyhook; tutte le righe attive della crontab (una
sola); tre stati dello skip (col progetto ma senza cron_book => ROSSO); slot di release
testato con venue_probe (il :07 come controllo positivo); parser regolare, passo > 0.
- r0823_sl_anchor: guardia sul :47 (era sul vecchio :07), prosa al passato; cron_chain.sh idem.
- CLAUDE.md: §5.7 frase invertita corretta, §5.14 limite vero (non l'artefatto della fixture),
§2 ora della LETTURA (13:47Z), nuovo debito §5.15 (USDE fuori dal bound di mercato).
- diari: tempi "scritto" corretti coi commit; sezione "Seconda tornata".
Test +11 (858 verdi).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XDJsH3iDSaBns3ccpPBwiu
Quattro segnalazioni della revisione sui commit di oggi, tutte verificate e riparate.
1. book_execute.py (+ CLAUDE.md §5.7, memoria 40): «il disaster-SL rotolante si ri-ancora ogni
ora» era falso — ensure_disaster_sl lascia il bracket finche' lo stop e' entro il 5% e la
taglia entro il 10%; il giro orario CONTROLLA, ri-ancora oltre la tolleranza (mark
+5,263%/-4,762%). Lo stop siede fra -26,3% e -33,3% dal mark corrente.
2. journal.rendimento_twr: limite dichiarato (D5) — l'intervallo che contiene un movimento
certo esce intero dal rendimento, il suo P&L di mercato va in `certi`; errore massimo meta'
del movimento per costruzione (25/08: ~$0,5). Non si stima (P12). Segmenti a lunghezza zero
non prodotti; nessun tempo a mercato -> 0,0 dichiarato numero.
3. base di equity zero: `twr` E `trading` None con motivo (il salto 0->X e' invisibile al
classificatore, `trading` valeva l'intero conto); il report stampa n/d.
4. test_book_cadenza: la guardia estrae ogni prescrizione «ogni/every N unita'» e pretende 60
minuti, con controllo positivo (M15); limite P13 dichiarato.
Test +5 (847 verdi). Diari 02/09 e 02/09b con la sezione "Revisione".
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RziUCB336YPUUyDJ29x4Ke
Il docstring di book_execute.py prescriveva «ogni ~230 minuti» mentre il cron gira ogni ora
(47 * * * *). Era il docstring a sbagliare: sulla riga 4h BTC raddoppia gli scatti del
disaster-SL rotolante (r0823_sl_anchor.py), e chi avesse "corretto" il cron verso il
docstring avrebbe spostato il libro sulla riga peggiore.
- scripts/live/book_execute.py: CADENZA: ORARIA, la riga di crontab, la ragione (giro
idempotente, latenza SKH01 <=1h, ri-ancoraggio orario) e il divieto esplicito con la data.
- tests/test_book_cadenza.py (10): deriva e confronta docstring, intestazione di
cron_book.sh e crontab installata (crontab -l; SALTATO se illeggibile, non verde);
parser a 5 campi solo per cadenze regolari; 60 < 230 < 240; minuto != :00.
- docs: CLAUDE.md §5.7 chiuso, §13 conteggio 842; memoria 40; diario 02/09b.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RziUCB336YPUUyDJ29x4Ke
`trades_db.py --report` calcolava e1/e0-1 sulla serie grezza di equity: il 96,3% del
numero era il versamento di $1.399,39 del 25/08. La riparazione (journal.movimenti_capitale)
esisteva e non aveva attraversato il confine fra i due lettori della stessa serie (P1).
- src/live/journal.py: `rendimento_twr` — funzione unica, spezza la serie sui movimenti
CERTI e moltiplica i segmenti; gli ambigui restano dentro, dichiarati (P12); tre stati.
- scripts/live/trades_db.py: report() la chiama; stampa TWR con segmenti datati, movimenti
elencati, trading al netto, delta $ etichettato "movimenti INCLUSI"; il % grezzo sparisce.
- test: +5 in test_journal.py (incl. riproduzione del +10,80% del diario 01/09, M23),
+2 in test_trades_report.py sul testo stampato con connect() deviato in tmp. 832 verdi.
- docs: CLAUDE.md §5.14 chiuso, §2 e §13 aggiornati; memoria 40; diario 02/09.
Limite ereditato e dichiarato (D5): +10% di trading fra due letture consecutive tocca la
soglia del rilevatore e a mercato fermo verrebbe classificato movimento.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RziUCB336YPUUyDJ29x4Ke
Conclusione dell'operatore (02/09): "mettere gli XEON su Deribit col
sistema attivo". Si', ed e' cio' che la memoria aveva scritto il 27/07.
Tre precisazioni, tutte gia' misurate e ora registrate:
- €5.000, non €6.043: la protezione venue satura a qualunque quota > 0,
l'ultimo migliaio dentro compra ~€100/anno e butta via l'assicurazione;
- il "~€600" e' un'attesa a banda larga, non un tasso (libro a mercato il
22% dei giorni, TWR +10,8% in 70g, hold-out TP01 ~+0,05, fisco −30%/10a);
- fondo d'emergenza da dichiarare.
Nessuna azione di config (cap dinamico, rilevatore collaudato il 25/08).
In attesa di importo e data; al deposito una riga di giornale, scritta
prima e non ricostruita dopo. N9: le opzioni sicure (+€52-62/anno) sono
state viste e messe da parte con motivo.
- CLAUDE.md §1: riga "soldi fermi" + indice §1-73
- RESULTS §73 + riga d'indice
- memoria 30-piano-capitale-fisco: voce
- diario 2026-09-01d: §7 la conclusione dell'operatore
- docs/journal/2026-09-01.md (voce del cron, non era committata)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
On-venue chiuso con l'elenco intero: 4/50 valute remunerate = le 4 gia'
chiuse il 31/08. L'USDC su Deribit non e' fermo (base di sizing + cuscino).
I €6k in XEON sono lo split-cassa. Tassi dal web con fonte (BOT 2,768%
asta 08/2026, DFR 2,25%, conti deposito 3,25-3,50%, sUSDe ~9%). In euro
netti su €6k: XEON 81, BOT 133, conto deposito 143, sUSDe 350 (ma stesso
emittente dell'USDE: split distrutto), libro ~600 (trading, split
distrutto). Miglior guadagno sicuro: +€62/anno. €100/mese di bonifico =
+4,07%/anno di drift. Non sono pareri fiscali. Nessun ordine.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Domanda dell'operatore: "possiamo usare quanto conosciamo del pavimento per
studiare una strategia". L'inverso di COLLAR01: non "quanto DD mi risparmia
il pavimento a taglia fissa" (perdeva contro il de-levering) ma "quanta
TAGLIA mi autorizza a DD fisso" — l'unica cosa che il de-levering non puo'
comprare (cambia la FORMA, non la proporzione), e la grandezza su cui vive
il tetto di leva del progetto (n·frac·scala·sl <= 0,50 => 1,67x).
RISULTATO: 0/16. La sola put a premio reale PEGGIORA il maxDD in 16/16 celle
(FORTE 51,83% -> 55,4-75,8%; LARGO 71,94% -> 74,8-81,7%), quindi k_f = 1,000
ovunque: niente da licenziare. Monotono nella protezione: piu' la put e'
vicina, peggio va — il bleed del premio E' il drawdown.
🚨 CORREGGE §71 (stesso giorno). Stamattina A1 diceva "il pavimento funziona
davvero". E' il COLLAR a ridurre il DD, non il pavimento: a premio zero la
put lo riduce (51,83 -> 36,76, il controllo), a premio reale lo peggiora =>
tutto il beneficio e' mangiato dal premio, e oltre. Nel collar la riduzione
viene dal TETTO: il suo premio compensa il bleed, e cappare l'upside abbassa
il picco da cui il DD si misura — un picco piu' basso, non protezione.
Premio di pareggio: 36-79% del reale; il DVOL sta 1,32x sopra la RV, quindi
un prezzo equo (~76%) sfiora il pareggio nelle celle migliori e lo manca
nelle altre. Il motivo di §46 (beta) non si applica — a beta 1,0 la put
paga davvero — ma il verdetto di §46, "il maxDD SALE", si riproduce per un
motivo diverso. Corretti il diario di §71 (titolo e A1), RESULTS, memoria.
IL MECCANISMO (B2), trasferibile: i drawdown di BTC sono GRIND. maxDD FORTE
2021-07-20 -> 2022-05-06 = 290 giorni; LARGO fino al 2023-10-16 = 818. Una
put a 7-14g copre UNA finestra; il DD che conta dura 20-60 finestre; la put
scade OTM ogni settimana (para nel 0-9% dei cicli) mentre il premio sanguina.
Non protegge nemmeno la finestra peggiore: 14g FORTE -22,9% nudo -> -23,6%
col pavimento. Su BTC il pavimento compra protezione contro la cosa sbagliata.
LA LICENZA DEL DISASTER-SL E' DI CARTA (B3), scritto prima che sia comodo:
con la put a 5d/14g a 21,9% dallo spot, sostituire sl con quella distanza
darebbe 2,28x. Ma l'invariante limita UN episodio, la put limita UNA
finestra, e il massimo su finestre consecutive non e' limitato da nulla:
1 finestra -23,6% (coperta), 8 finestre -33,6% (non coperte) => a 2,28x un
grind di 112 giorni costerebbe il 77% dell'equity. disaster_sl_pct NON si
sostituisce con la distanza di un pavimento. Aggiunto a CLAUDE.md §3.
GATED SULL'IV (B4) — la copertura dinamica che §46 non aveva provato: put
ON solo sotto il 25°/50° pctl di DVOL/RV. Migliora molto (FORTE +3,8% ->
+8,4%) ma resta sotto la base (+10,04%) e il DD resta >=. L'incollatura
ignora lo spread delle transizioni A FAVORE del gated: perde a maggior ragione.
Quattro attese a priori (B1-B4) scritte prima, tutte confermate.
NON MISURATO, dichiarato: nessun DSR (cade al primo gate); nessuna lente
reale; nessun pavimento a scadenza lunga (30-90g, che coprirebbe piu'
finestre di grind) perche' l'operatore ha vincolato a <=15 giorni — e'
l'unica variante che B2 lascia aperta, e sta fuori dal vincolo.
Libro, pesi, cron, config INVARIATI. Nessun ordine. Test 25/25 sui filoni.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adriano
Adriano Dal Pastro