Files

T

Adriano Dal Pastro 835e0c8666 revisione 02/09: il rotolante si CONTROLLA ogni ora (non "si ri-ancora"), TWR con limiti dichiarati e tre stati

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

2026-09-02 15:17:05 +00:00

4.7 KiB

Raw Blame History

2026-09-02 — Debito 14: il report stampa il TWR, non il bonifico

Scritto il 2026-09-02 fra le 14:16Z e le 14:30Z. Numeri dalla serie equity di trades.db (1.678 letture) e dal report rilanciato dopo la riparazione.

Cosa c'era

trades_db.py --report calcolava 100*(e1/e0-1) sulla serie grezza di equity e lo stampava come performance: +243%. La serie contiene un solo salto, il versamento di $1.399,39 del 25/08 11:47Z: il 96,3% di quel numero era un bonifico. Il classificatore che lo scorpora esisteva già (journal.movimenti_capitale, dal 25/08) e non era mai arrivato al secondo lettore della stessa serie. Trovato e registrato il 01/09 (2026-09-01-stato-trades.md), non riparato perché lo script legge il libro vivo.

Cosa ho fatto

pezzo	dove	cosa
funzione unica	`src/live/journal.py` → `rendimento_twr(con, fino_ts)`	chiama `movimenti_capitale`, spezza la serie all'equity PRIMA e DOPO ogni movimento certo, moltiplica i segmenti. Gli ambigui non spezzano (P12): restano nel rendimento, dichiarati. Tre stati: numero, o `None` con `motivo`
il report	`scripts/live/trades_db.py` → `report()`	chiama `rendimento_twr` (P1: non rifà il conto). Stampa TWR con i segmenti datati, i movimenti elencati con la classe, `trading da arming`, e il delta $ grezzo etichettato «movimenti di capitale INCLUSI». Il `%` grezzo non compare più
test	`tests/test_journal.py` (+5) · `tests/test_trades_report.py` (+2)	versamento spezzato e grezzo no · senza movimenti = rendimento semplice · ambiguo non spezza · serie vuota → `None` con motivo · riproduzione del +10,80% del diario 01/09 (M23) · il testo stampato contiene TWR e non il grezzo · `connect()` nudo deviato in tmp (conftest), verificato nel test

Il report, prima e dopo

prima:  equity : $598.06 -> $2,051.84  (+1453.78, +243.08%)

dopo:   equity             : $598.06 -> $2,048.40  (+1,450.34 di equity, movimenti di capitale INCLUSI) | picco $2,073.59 | 1678 letture
        movimenti capitale : +1,399.39 certi | +0.00 ambiguo/i (restano nel P&L, dichiarati)
            2026-08-25T11:47  +1,399.39  [movimento]
        trading da arming  : +50.95  (equity al netto dei movimenti certi)
        TWR                : +10.61%  = +11.61% [2026-06-23 -> 2026-08-25] x -0.89% [2026-08-25 -> 2026-09-02]

Il giornale del giorno concorda: «cumulato dall'arming $+1.450,34 — di cui $+1.399,39 versati -> trading $+50,95». Stessa base, stesso versamento, stessa funzione.

Una cosa imparata riparando

Quattro test sono nati rossi con scenari a +10% di trading fra due letture: la soglia del rilevatore (book.EQUITY_JUMP_ALERT) è esattamente 0,10, e a mercato piatto un +10% supera «2× il massimo che il mercato poteva fare» (che è zero) — viene classificato movimento. Non è un difetto della riparazione: è il limite già dichiarato del rilevatore live (D5, nel docstring di movimenti_capitale). Nella serie vera non morde — fra due letture orarie consecutive il trading non fa +10% — ma un test che lo tocca lo rende visibile. I test ora usano +5%, e il limite è scritto nel test, nel CLAUDE.md e qui.

Cosa NON ho fatto

Il giornale (pnl_giorno, pagina markdown) non stampa il TWR: stampa già lo scorporo in dollari e la sua pagina ha una forma testata. Aggiungerlo è una riga, ma non era il debito.
Non ho scomposto lo scarto (~$25) fra round-trip + non realizzato e il trading al netto: era già fuori scope il 01/09 e lo resta.

Revisione del codice (15:20Z) — tre cose trovate, tutte riparate

trovato	vero?	riparazione
l'intervallo che contiene un movimento certo esce intero dal rendimento: il suo P&L di mercato finisce in `certi` e fuori da `trading`, e nessun documento lo diceva	sì, per costruzione. Errore massimo = metà del movimento riconosciuto (margine del classificatore). Il 25/08: ~$263 lordi a ±0,2% → ~$0,5	dichiarato nel docstring, nel report, in CLAUDE.md §5.14 e in memoria 40. Non si stima (P12)
a base di equity zero `trading` era un numero mentre `twr` era None, e sbagliato: il salto 0→X è invisibile al classificatore, `trading` valeva l'intero conto sotto l'etichetta "al netto dei versamenti"	sì. Non raggiungibile dal cron (non scrive mai 0), ma raggiungibile da un backfill	tre stati veri: `twr` e `trading` entrambi None con motivo; il report stampa n/d. Test in `test_journal.py` e `test_trades_report.py`
movimento nel primo intervallo o due consecutivi → segmento `+0.00% [x -> x]`	sì, cosmetico	i segmenti a lunghezza zero non si producono; nessun tempo a mercato → TWR 0,0 dichiarato numero. Test

Il numero pubblicato non cambia: +10,61% alle 14:02Z, +10,56% alle 14:47Z per la marcatura.

4.7 KiB Raw Blame History Unescape Escape