journal: i versamenti non sono piu' P&L — movimenti di capitale scorporati dal trading

Il P&L di giornale era un delta di equity: la voce del 25/08 dichiarava +$1.414,57
di "giorno" quando $1.399,39 erano il deposito USDC, e il cumulato dall'arming
avrebbe mentito per sempre. Nuova `movimenti_capitale()`:
- soglia IMPORTATA da book.EQUITY_JUMP_ALERT, non ridichiarata (P1);
- "movimento" solo se il salto supera di >2x il massimo che il mercato MISURATO
  (feed certificato, tetto di leva da config) poteva produrre fra le due letture;
- altrimenti AMBIGUO: dichiarato con attenzione e NON scorporato (P12 -- un crash
  vero a tutta leva non deve diventare "prelievo"); idem a feed illeggibile (P5).
Scansione dell'intera storia: 1 evento, esattamente il deposito (+209,6% contro
mercato max 0,22%), zero falsi positivi. `concentrazione` ora lavora sul cumulato
di TRADING; le regole sui movimenti stanno sopra l'early-return "nessun giro".
Limite dichiarato (D5): un movimento sotto il 10% dell'equity resta nel P&L.
7 prove nuove (31 -> 37), incluso il controllo M15 al contrario. Voce del 25/08
rigenerata: giorno -> trading +$15,18; cumulato -> trading +$59,14.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1

docs/memory/40-produzione-e-deploy.md

@@ -790,6 +790,28 @@ SORGENTE** di `cron_daily.sh` — ogni chiamata a `journal.py` deve avere `--gio
 perche' `journal.py` **senza argomenti scrive OGGI**. La guardia **non vieta** di rigenerare
 spesso: vieta di scrivere la pagina **una volta e lasciarla li'**.
 
+🚨 **RIPARATO (2026-08-26): il P&L di giornale contava i VERSAMENTI come profitto.**
+Il «giorno» era un delta di equity fra letture: la voce del 25/08 dichiarava **+$1.414,57 di
+P&L** quando $1.399,39 erano il deposito USDC dell'operatore, e il «cumulato dall'arming»
+avrebbe mentito per sempre (e al prossimo versamento da $3.000 avrebbe stampato «+$3.000 di
+giorno»). Riparazione in `src/live/journal.py::movimenti_capitale` con tre proprieta':
+(1) la **soglia e' importata** da `book.EQUITY_JUMP_ALERT`, non ridichiarata (P1 — il rilevatore
+di movimenti del progetto e' quello); (2) un salto e' `movimento` solo se supera di >2x il
+massimo che il **mercato misurato** (feed certificato, tetto di leva da config) avrebbe potuto
+produrre nell'intervallo fra le due letture; (3) altrimenti e' **`ambiguo`: dichiarato e NON
+scorporato** (P12 — un crash vero a tutta leva non deve trasformarsi in "prelievo").
+Scansione dell'intera storia reale: **1 evento, esattamente il deposito** (+209,6% contro un
+massimo di mercato di ±0,22%), zero falsi positivi. Anche la regola `concentrazione` ora
+lavora sul cumulato di **trading** (il 25/08 leggeva "il 100% del P&L viene dagli ultimi 7
+giorni" su un P&L che era il bonifico). Due scelte di design da non perdere: le regole sui
+movimenti stanno **sopra** l'early-return "nessun giro di book" (un versamento in un giorno
+senza giri esiste lo stesso: viene dal DB equity, non dal log del libro), e il **limite e'
+dichiarato** (D5): un movimento sotto soglia — es. $150 su un conto da $2.000 — non si
+distingue dal mercato e resta nel P&L, come nel rilevatore live. 7 prove nuove in
+`test_journal.py` (31 → 37), incluso il controllo M15 al contrario: un crash −14% a tutta
+leva resta AMBIGUO. Voce del 25/08 **rigenerata**: giorno +$1.414,57 di equity → trading
+**+$15,18**; cumulato +$1.458,53 → trading **+$59,14**.
+
 ⚠️ **Trovato girando la suite completa, NON riparato — e' un'altra cosa:**
 `tests/test_wave_0726.py::test_t1_canonical_riproduce_il_backtest_ufficiale` **fallisce**, e
 falliva gia' prima di questa modifica (verificato con `git stash`: stesso fallimento sull'albero