`trades_db.py --report` stampa `$598,06 -> $2.051,84 (+243,08%)` accanto a `netto +40,77`. La serie di 1.657 letture orarie contiene UN SOLO salto: il versamento di $1.399,39 del 25/08 11:47Z. Confermato dal classificatore ufficiale del progetto (`journal.movimenti_capitale`: certi 1399.39, ambigui 0.0, classe `movimento`). Al netto: TWR +10,80% spezzato sul versamento (+11,61% fino al 25/08, -0,73% dopo), equity +$54,39 in 69 giorni. Il giornale, che lo scorporo lo fa gia', concorda: $+62,00 al 31/08, -7,61 di marcatura fino a oggi. Il difetto non e' nuovo — e' la stessa riparazione che NON ha attraversato il confine. `journal.py:121` porta il caso d'origine nel docstring (la voce del 25/08 che dichiarava «+$1.414,57» di giornata); `trades_db.py:83` calcola `100*(e1/e0-1)` sulla serie grezza e non chiama `movimenti_capitale()`, che e' a un import di distanza. Variante di P1: non un sorvegliante che ridichiara il bersaglio, ma una riparazione che non si e' propagata al secondo lettore della stessa serie. Danno sui soldi nessuno (sola lettura); danno di citazione si', ed e' l'unico numero fuorviante che il progetto produce su richiesta di un comando pubblicato in §13. Codice NON toccato: sta su uno script che legge il libro vivo. Debito #14. Stato del libro al 01/09 16:47Z, per il resto invariato: 45 fill (ultimo 31/08 15:47), 29 round-trip (21 in utile, netto +40,77), posizioni BTC 0,0045 @ $79.208,11 e ETH 0,0872 @ $2.473,04, non realizzato -$11,72, leva lorda 0,27x. Nessun fill da 25 ore = banda morta del min_order_usd $5, non un blocco (il cron logga «gia' al target» a ogni giro). monitor_health 8/8 OK, riconcilio 44/45 con 0 prezzi divergenti (l'unica coppia scoperta e' il difetto noto dei sei giorni fra log e jsonl sullo stesso fill). - CLAUDE.md §2: riga nella tabella dei numeri da non citare - CLAUDE.md §5: debito #14 - docs/diary/2026-09-01-stato-trades.md - docs/journal/2026-08-31.md (voce del cron, non era committata) Suite: 800 passati, 0 falliti. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5.3 KiB
2026-09-01 — Stato trades, e la riparazione che non si è propagata
Scritto il 2026-09-01, misure lette fra le 09:35Z e le 16:47Z. Numeri dalle serie citate.
1. Lo stato, in breve
| valore | fonte | |
|---|---|---|
| fill registrati | 45, dal 2026-07-14T14:00 al 2026-08-31T15:47 | trades.db |
| round-trip chiusi | 29 (21 in utile) — lordo +41,43 · fee allocate 0,66 · netto +40,77 | trades.db |
| fee totali pagate | $0,8617 | trades.db |
| equity (lettura 16:47Z) | $2.051,84 · picco $2.073,59 | serie equity, 1.657 letture |
| posizione BTC | 0,0045 @ medio $79.208,11, dal 25/08 | libro di bordo |
| posizione ETH | 0,0872 @ medio $2.473,04, dal 25/08 | libro di bordo |
| non realizzato (mark 16:38Z) | −$11,72 — BTC −7,91 (−2,22%) · ETH −3,80 (−1,76%) | gateway |
| gross nozionale | $560,36 → leva 0,27x su un tetto di 1,0x | gateway |
Nessun fill da 25 ore, e non è un blocco. Il log del cron lo dice a ogni giro fino alle 15:47:
=> Nessuna azione: conto gia' al target netto del book. TP01 fermo a +0,461 (BTC) e +0,278 (ETH),
SKH01 flat su entrambi, scarto posizione-target sotto il min_order_usd di $5 ($356 contro $351,
$214 contro $213). Feed SKH fresco (0 min), disaster-SL armati a $55.428,0 e $1.708,9.
monitor_health: 8/8 OK, coperture 98-129%. Riconcilio a 3 fonti: 44/45 concordano, 0 prezzi
divergenti; l'unica coppia scoperta è il difetto già noto — stesso fill (ETH buy 0,04 @ 1869,74)
timbrato 2026-07-14T14:00 nel log del cron e 2026-07-08 nel jsonl, i sei giorni di scarto della
lezione già registrata. Non è un fill perso.
2. Il difetto: --report stampa un rendimento che non è un rendimento
scripts/live/trades_db.py --report stampa questa riga:
equity : $598.06 -> $2,051.84 (+1453.78, +243.08%) | picco $2,073.59 | 1657 letture
Accanto a una riga di P&L che dice netto +40,77. Il +243% non è rendimento: è quasi tutto un
versamento. La serie di 1.657 letture orarie contiene un solo salto, il 2026-08-25 alle 11:47Z:
$667,49 → $2.066,88, +$1.399,39.
Non è una mia classificazione a occhio: è quella del progetto. journal.movimenti_capitale(), che
importa la soglia viva da book.EQUITY_JUMP_ALERT (0,10) e confronta il salto col massimo che il
mercato misurato avrebbe potuto produrre in quell'ora a tetto di leva, restituisce
certi 1399.39 · ambigui 0.0, un solo evento, classe movimento.
Al netto:
| lettura | valore |
|---|---|
| periodo 1 — 23/06 22:00Z → 25/08 10:47Z ($598,06 → $667,49) | +11,61% |
| periodo 2 — 25/08 11:47Z → 01/09 16:47Z ($2.066,88 → $2.051,84) | −0,73% |
| TWR spezzato sul versamento | +10,80% |
| crescita di equity al netto del versamento, 69 giorni | +$54,39 |
Il numero regge al controllo incrociato. Il giornale del 31/08, che lo scorporo lo fa già, scrive: «cumulato dall'arming: $+1.461,39 di equity — di cui $+1.399,39 versati/prelevati -> trading $+62,00». Stessa base ($598,06), stesso versamento; la differenza fra i suoi +62,00 e i miei +54,39 è −7,61 di marcatura fra l'ultima lettura del 31/08 e quella di oggi. Le due misure concordano.
Perché è un difetto e non un dettaglio di stampa
La riparazione esiste già, e in questo stesso repo. src/live/journal.py:121 la porta scritta
nel docstring, col caso d'origine:
«Il P&L di giornale e' un delta di equity, quindi un versamento ci finisce dentro come se fosse profitto: la voce del 2026-08-25 dichiarava «giorno: +$1.414,57» quando $1.399 erano un deposito USDC, e il «cumulato dall'arming» avrebbe mentito per sempre.»
Quel difetto fu trovato e riparato nel giornale. trades_db.py:83 non ha mai ricevuto la
riparazione: calcola 100*(e1/e0-1) sulla serie grezza e non chiama movimenti_capitale(), che
è a un import di distanza e restituisce già certi e ambigui pronti da scorporare.
È una variante di P1 — non un sorvegliante che ridichiara il proprio bersaglio, ma una
riparazione che non ha attraversato il confine fra due lettori della stessa serie. Il primo
strumento dice la verità; il secondo, interrogato con lo stesso comando pubblicato in CLAUDE.md §13
(trades_db.py --report), stampa un numero che si legge come una performance ed è per il 96,3%
un bonifico.
Danno oggi: nessuno sui soldi — --report è in sola lettura e non decide niente. Il danno è di
citazione: è esattamente la classe di numeri che §2 raccoglie sotto «non citare», ed è l'unico che
il progetto produce su richiesta esplicita di un comando documentato.
3. Cosa NON ho fatto
Non ho toccato il codice. La riparazione è piccola — chiamare movimenti_capitale() e stampare
la riga scorporata accanto a quella grezza, come fa il giornale — ma sta su uno script che legge il
libro di bordo vivo, e la richiesta era di aggiornare i documenti. Registrata come debito aperto.
Non ho scomposto la differenza fra il P&L dei round-trip (+$40,77) più il non realizzato (−$11,72) = +$29,05 e i +$54,39 di equity al netto del versamento. Lo scarto di ~$25 sta in voci che il conteggio round-trip non copre — funding dei perp (non modellato in nessun backtest, §2), reward USDE, marcatura dell'USDE all'indice. A questa taglia non vale il costo della misura: si dichiara.