Files

T

Adriano Dal Pastro 214599e0a8 docs: libro di bordo in CLAUDE.md + diario del 23/08

CLAUDE.md: bullet del libro di bordo (il difetto dell'ora dei fill, il DB a
tre fonti incrociate, i quattro livelli della pagina, l'analista e i suoi
limiti, le due riparazioni al notifier), piu' i file nuovi nella Struttura e
i quattro comandi nella sezione Comandi.

Diario `2026-08-23-libro-di-bordo.md`: la storia per esteso, i numeri del
libro live dall'arming (+$37,50 in 64 giorni, ma l'80% delle giornate a
equity invariata e tutto il P&L in sei giorni), i cinque difetti trovati dai
test e il ciclo di retroazione dell'agente.

Le due cose che un lettore futuro deve trovare scritte: che l'analisi in
prosa NON e' parte del registro (una guardia sui numeri non copre il
ragionamento — due errori su due giri con sonnet-5, nessuno con una cifra
nuova), e che il modello e' stato cambiato su un campione di due
osservazioni, quindi e' un tentativo di abbassare un tasso e non una
garanzia.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-23 19:50:56 +00:00

5.2 KiB

Raw Blame History

2026-08-23 — Libro di bordo: i trade allineati col tempo, il giornale, l'analista

Libro, pesi, cron di strategia, config: INVARIATI. Nessun ordine. Tutto ciò che segue è sorveglianza e registrazione.

La domanda che l'ha fatto nascere

«I trade vengono salvati?» — sì, in data/live/book_executions.jsonl. Ma non allineati col tempo: book_execute.py:213 scriveva

ts_utc = str(pd.Timestamp(r['last_data']))    # la data della BARRA DI SEGNALE

19 righe su 19 a 00:00:00. E non era cosmetico: un trade risultava registrato sei giorni prima di essere eseguito — ETH 0.04 @ 1.869,74, fill vero il 2026-07-14 alle 14:00, scritto 08/07. La riconciliazione lo isola da sola: 18 fill concordano fra log e jsonl, 1 no, ed è quello.

L'ora vera esisteva solo in logs/cron_book.log — gitignored, fuori dal backup, ruotabile. La cronologia reale del libro live viveva in un file che una rotazione avrebbe cancellato senza che nessuno se ne accorgesse.

Cosa c'è adesso

data/live/trades.db (sqlite, dentro il perimetro del backup rotativo). fills con il contesto del segnale a quel giro, roundtrips derivati e ricalcolati da zero, equity oraria (1.437 letture), journal. Sync orario in cron_book, subito dopo l'esecuzione.

Tre fonti che si incrociano e non si sovrascrivono: il cron log (ora vera + contesto), il jsonl (i fill), il venue (autorevole su order_id ma tronca: 1 trade su BTC, 0 su ETH). reconcile() riporta le divergenze e non ripara niente da solo.

docs/journal/YYYY-MM-DD.md, 62 voci ricostruite dall'arming. Quattro livelli separati per provenienza, e la separazione è il prodotto:

livello	chi scrive	può sbagliare?
numeri	feed certificato + DB	è una misura
Lettura	12 regole dichiarate, ognuna con id	deterministica
Analisi	un modello (`claude-opus-5`)	sì, ed è firmata
Nota	l'operatore	—

L'analisi parte ogni giorno su Telegram con una testata di numeri; se manca, il messaggio parte lo stesso dicendo perché.

Cosa ha trovato il lavoro, oltre al difetto iniziale

P&L del libro dall'arming: +$37,50 su $598,06 (+6,27%) in 64 giorni, 12 round-trip di cui 11 in utile, fee totali $0,41. Riconciliazione indipendente: la ricostruzione FIFO dà +$38,15 contro i +$37,50 dell'equity del venue — scarto $0,65 (1,7%), coerente col funding pagato sui long.

Ma il numero che conta è un altro: tutto il P&L è di sei giorni. Fino al 17/08 il conto era a $597,12, cioè −$0,94 in otto settimane; l'equity è rimasta invariata nell'80% delle giornate. Non è un difetto — è cosa sono TP01 e SKH01 — ma significa che +6,27% in due mesi non è un tasso di rendimento.

E l'analista ha aggiunto la lettura che le regole non producono: quei sette giorni sono anche gli unici in cui il libro è stato a mercato, e coincidono con +22,94% su BTC e +29,49% su ETH → la finestra non separa l'edge dal beta a un rialzo forte, né il trend dal breakout.

Cinque difetti trovati dai test o leggendo l'uscita, nessuno a occhio

Il tetto di leva era ridichiarato (0.5 cablato) invece che letto da config/live.json — quinta occorrenza dello schema che il progetto paga da luglio.
L'IV-rank era la statistica sbagliata col nome giusto: percentile a un anno etichettato come il gate di VRP01, che usa quello espandente. Verdetto opposto (0,52 «sopra» contro 0,18 «sotto»); il valore giusto combacia con «0/8 settimane passano il gate» (30/07).
Il renderer cadeva in KeyError se mancava il blocco mercato.
«24 giri attesi» su un giorno in corso → allarme a ogni esecuzione.
Libro e P&L leggevano due istanti diversi: la stessa pagina mostrava due equity.

Il ciclo di retroazione, e il limite che resta

Al primo giro reale il modello ha letto la propria analisi precedente — con l'avviso del tripwire — e l'ha commentata. senza_analisi() toglie la sua sezione prima di dargli la pagina. Nessun controllo automatico può distinguere il meta-commento da prosa valida: si vede solo leggendo l'uscita.

E il limite dichiarato quando la guardia è stata scritta si è materializzato subito: due errori su due giri con sonnet-5, nessuno dei due con una cifra nuova — una frase su un merge mai raccontato, e un round-trip corretto dichiarato inesistente. numeri_non_supportati() prende l'invenzione, non il ragionamento. Modello portato a opus-5 (primo giro pulito, affermazioni verificate a mano contro il DB), ma due osservazioni contro una non provano niente: è un tentativo di abbassare un tasso.

Regole

Un dato operativo non ricostruibile non può vivere in un file gitignored: si materializza dove il backup arriva.
Una guardia più stretta del contratto produce allarmi che si impara a ignorare (il tripwire validava sulla sola pagina mentre il prompt include anche lo storico, e bocciava un'equity vera).
Una regola che si accende su $2 di cumulato insegna a saltare la sezione: serve una soglia di rilevanza.
Chi scrive in un registro va firmato, o il registro perde il suo valore probatorio.
Una guardia sui numeri non copre il ragionamento.

5.2 KiB Raw Blame History Unescape Escape