feat(report): ledger reale vs backtest — il gate per scalare il capitale

Per gli sleeve eseguiti sim==backtest per costruzione -> reale vs backtest = fuga di esecuzione (slippage + fee + netting/phantom/sim_fallback). Misura LEAKAGE sim-reale per-trade, slippage ingressi/uscite, fee reali, sim_fallback, ledger per-sleeve; verdetto verde/giallo/rosso. Clean-start --since 2026-06-13 (la finestra mobile includerebbe l'incidente testnet pre-fix). Cron host giornaliero 08:30 UTC --telegram. Read-only, niente rete. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-13 11:24:19 +00:00
parent 6fe45867f0
commit dc22256e0e
2 changed files with 222 additions and 0 deletions
@@ -0,0 +1,49 @@
+# 2026-06-13 — Report ricorrente LEDGER REALE vs BACKTEST (il gate per scalare)
+
+## Perché
+
+Domanda dell'utente: "come cresco il capitale a 12k". Risposta: il prerequisito
+prima di mettere soldi veri è che il **ledger reale combaci col backtest** —
+soprattutto lo slippage del 15m appena deployato. Questo report rende quel gate
+un dato osservabile, non un'opinione.
+
+Insight chiave: per gli sleeve eseguiti (6 fade 15m, DIP01, 6 pairs, SH01) il
+**sim del worker == backtest canonico PER COSTRUZIONE** (validato). Quindi
+"reale vs backtest" = "reale vs sim" = la **fuga di esecuzione**: slippage +
+fee reali vs assunte + effetti netting/phantom/sim_fallback.
+
+## Cosa misura
+
+`scripts/analysis/ledger_vs_backtest.py` (read-only: solo trades.jsonl +
+status.json, nessuna rete → affidabile in cron):
+- PnL realizzato sim vs reale (Σ e per-trade) → **LEAKAGE** € e per-trade (bottom line)
+- slippage ingressi (REAL_OPEN) e uscite-a-mercato (REAL_CLOSE; escluse le uscite
+  da TP resting, fill maker al livello = no slippage)
+- fee reali vs assunte (0.10% RT)
+- trade `sim_fallback` (reale mai eseguito/fillato) = quota NON coperta dal reale
+- ledger per-sleeve: real_capital vs capital (sim)
+- **verdetto** 🟢/🟡/🔴: <10 trade = campione piccolo; leakage basso+slippage ≤15bps
+  = verde (si può pensare a scalare); slippage >40bps = rosso (edge erode, NON scalare)
+
+## Clean-start (importante)
+
+Una finestra mobile pura includerebbe l'**incidente testnet pre-fix**: a 7g il
+report dà sim +82 vs reale +5 (🔴) — ma è gonfiato dai +4% FANTASMA che il sim
+bookava e il reale no, prima di TP_PHANTOM (v1.1.23), netting (v1.1.25) e
+ribilancio-conservativo (v1.1.31). Lo scheduler usa **`--since 2026-06-13`** →
+accumula SOLO dati post-fix, e diventa statisticamente significativo coi giorni.
+Finestra pulita oggi: 1 trade, leakage +0.07, slippage ingresso 12-29 bps.
+
+## Scheduling
+
+Cron host (come reconcile/hourly_report), **giornaliero 08:30 UTC**:
+`ledger_vs_backtest.py --since 2026-06-13 --telegram` → Telegram + log in
+`~/port06_ledger_vs_backtest.log`. Invio verificato.
+
+## Come usarlo
+
+Quando il campione supera ~10-20 trade reali e il verdetto è 🟢 stabile per
+qualche giorno (leakage per-trade piccolo, slippage medio ≤15 bps), allora il
+15m regge l'esecuzione e si può passare da testnet a piccolo reale → poi scalare.
+Se resta 🔴/🟡, l'edge si erode sui fill e NON va scalato: prima si capisce dove
+perde (slippage ingressi? uscite a mercato? sim_fallback frequenti?).