fix(live): cap di fallback legato all'ultima equity osservata + cap config 300 -> 3000

L'operatore ha autorizzato "si alza il cap a 3000". Verificato PRIMA di eseguire: il deposito non era ancora arrivato (equity reale $596.92), e alzare il cap in quel momento sarebbe stato pericoloso NEL VERSO OPPOSTO. IL PROBLEMA. Quando l'equity reale non e' leggibile, shadow_report ripiega su paper_cap = $2.000 NOMINALI, che non e' il conto vero: il sizing diventa 0.5 x 2000 x (...) = fino a $1.000/asset, e il cap fisso e' l'unica cosa che impedisce a quel nominale di diventare leva reale. cap $300 -> fallback $600 lordi su $597 = 1.00x OK cap $3000 -> fallback $2.000 lordi su $597 = 3.35x NO Cioe' il cap sarebbe stato troppo alto proprio nel momento in cui non si sa quanto c'e' sul conto, e con disaster_sl_pct -30% quella e' la configurazione peggiore possibile. LA CORREZIONE. Invece di alzare un numero da ricordare, il cap di fallback e' legato al conto: cap_fallback = min(cap_fisso_di_config, ultima_equity_reale_osservata * frac), con watermark in data/live/equity_seen.json scritto da book_report ogni volta che l'equity reale e' leggibile. Il cap di config torna a essere un TETTO DICHIARATO. Senza watermark (primo avvio, file cancellato) -> CAP_UNKNOWN_USD = $300: non si sa niente del conto, si usa la taglia storicamente sicura. VERIFICATO SUL CONTO VERO, nei due regimi: oggi, watermark $596.92 -> $298.46/asset = leva 1.00x dopo il versamento, $6.047 -> $3,000.00/asset = leva 0.99x Sicuro in entrambi gli ordini di eventi, senza dipendere da un'azione manuale al deposito. Questo CHIUDE l'azione pre-registrata il 2026-07-02 ("al deposito alzare il cap a equity/2"), rimasta ineseguita per 24 giorni — non eseguendola, ma rendendola non necessaria. REGOLA: un parametro di sicurezza che va aggiornato a mano a ogni cambio di scala e' un difetto, non una configurazione. Lo stesso numero era sbagliato in un verso prima del deposito e nell'altro dopo: la soluzione non era scegliere il valore giusto, era legarlo alla grandezza che lo determina. Guardie: tests/test_cap_watermark.py (11), A DUE LATI — il cap non puo' ne' superare il conto reale (leva nascosta) ne' restare sotto dopo un deposito (strozzatura). Dry-run sul conto reale: cap/asset $298, book flat, nessun ordine. 391 test verdi (+11). Strategia, pesi, cron INVARIATI. Cambia solo config/live.json e il calcolo del cap di fallback. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-26 20:44:27 +00:00
parent eb7c3af636
commit b023cc2bdf
4 changed files with 231 additions and 7 deletions
@@ -235,3 +235,61 @@ equity/2"*). Cablato `test_il_cap_fisso_diventa_una_strozzatura_dopo_un_deposito
 si deposita senza adeguare `max_notional_per_asset_usd`.

 **Non eseguita**: e' un cambio di config su soldi veri, decisione dell'operatore.
+
+---
+
+## Il cap: alzato a $3.000, ma il modo conta piu' del numero
+
+L'operatore ha autorizzato *"si alza il cap a 3000"*. Verificato prima di eseguire: **il deposito
+non era ancora arrivato** (equity reale letta dal conto: $596.92). Alzare il cap in quel momento
+sarebbe stato **pericoloso nel verso opposto**.
+
+### Perche' alzarlo prima del deposito e' pericoloso
+
+Quando l'equity reale non e' leggibile, `shadow_report` ripiega su `paper_cap` = **$2.000
+nominali**, che non e' il conto vero. Il sizing diventa `0.5 × 2000 × (...)` = fino a $1.000/asset,
+e **il cap fisso e' l'unica cosa che impedisce a quel nominale di diventare leva reale**:
+
+| cap fisso | fallback su conto da $597 | leva reale |
+|---|---|---|
+| $300 (prima) | $300/asset = $600 lordi | **1.00x** ✅ |
+| $3.000 (alzato a mano) | $1.000/asset = $2.000 lordi | **3.35x** ❌ |
+
+Cioe' il cap sarebbe stato troppo alto **proprio nel momento in cui non si sa quanto c'e' sul
+conto** — e con `disaster_sl_pct` −30% quella e' la configurazione peggiore possibile.
+
+### La correzione: il fallback segue l'ultima equity osservata
+
+Invece di alzare un numero da ricordare, il cap di fallback e' stato **legato al conto**:
+
+```python
+cap_fallback = min(cap_fisso_di_config, ultima_equity_reale_osservata * frac)
+```
+
+con un watermark in `data/live/equity_seen.json`, scritto da `book_report` ogni volta che l'equity
+reale e' leggibile. Il cap di config torna a essere quello che dovrebbe: un **tetto dichiarato**.
+
+Verificato sul conto vero, nei due regimi:
+
+```
+oggi, watermark $596.92     ->   $298.46/asset  = leva 1.00x
+dopo il versamento, $6.047  -> $3,000.00/asset  = leva 0.99x
+```
+
+**Sicuro in entrambi gli ordini di eventi**, e senza dipendere da un'azione manuale al momento del
+deposito. Senza watermark (primo avvio, file cancellato) si usa `CAP_UNKNOWN_USD` = $300: non si sa
+niente del conto, si usa la taglia storicamente sicura.
+
+Questo **chiude l'azione pre-registrata il 2026-07-02** (*"al deposito alzare il cap a equity/2"*),
+rimasta ineseguita per 24 giorni — non eseguendola, ma **rendendola non necessaria**.
+
+Guardie: `tests/test_cap_watermark.py` (11), **a due lati** — il cap non puo' ne' superare il conto
+reale (leva nascosta) ne' restare sotto dopo un deposito (strozzatura).
+
+### Regola trasferibile
+
+**Un parametro di sicurezza che va aggiornato a mano a ogni cambio di scala e' un difetto, non una
+configurazione.** Qui lo stesso numero era sbagliato in un verso prima del deposito e nell'altro
+dopo: la soluzione non era scegliere il valore giusto, era **legarlo alla grandezza che lo
+determina**. Il segnale che serviva questa correzione era gia' visibile: l'azione manuale era stata
+pre-registrata 24 giorni prima e non era mai stata eseguita.