Non prosa libera: dodici regole, ognuna con un id stampato accanto alla riga
che ha prodotto. Combinano solo numeri gia' presenti nella pagina, tacciono
sul non misurato e non prevedono niente. Il campo `nota` resta l'unico posto
dove puo' finire un giudizio umano.
Le regole: stato del libro e PERCHE' e' flat (componente per componente),
disaccordo fra orizzonti del trend contro esposizione TP01, incoerenza
(trend su ma libro fuori), leva contro il tetto, P&L del giorno, costo che
supera il movimento, concentrazione del cumulato, drawdown dal picco,
implicita contro realizzata col gate IV-rank di VRP01, giornata oltre 2
deviazioni, giri mancanti e feed vecchio, e la taglia del campione.
Ogni regola ha DUE test: uno che la accende e uno che la tiene spenta. Una
regola che si accende sempre non sta leggendo niente, una che non si accende
mai e' indistinguibile da una rotta.
Tre difetti corretti prima di pubblicare, tutti trovati scrivendo i test:
- 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: un sorvegliante che ridichiara il proprio bersaglio continua a
passare il giorno che il bersaglio cambia. Ora deriva, e se il config non
si legge lo dice invece di inventare un tetto.
- l'IV-rank era il percentile a UN ANNO etichettato col nome del gate di
VRP01, che usa un percentile ESPANDENTE. Due statistiche diverse, e oggi
danno il verdetto OPPOSTO: 0.52 (sopra la soglia, "il sleeve venderebbe")
contro 0.18 (sotto, sleeve fermo). Il valore giusto combacia con quanto
gia' misurato il 30/07: 0/8 settimane passano il gate.
- la concentrazione si accendeva su $2,08 di cumulato: vera e inutile. Ora
ha una soglia di rilevanza, o e' una riga che insegna a saltare la sezione.
62 voci rigenerate. Strategia, pesi, config INVARIATI. 675 test passano.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
Adriano Dal Pastro