equity illeggibile -> sizing su FALLBACK_CAPITAL $2.000 paper: il libro vende meta' posizione #21
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Revisione 2026-09-27 (goldrake): rilievo Opus 5.5, verifica avversariale fable. Sola lettura, nessun codice toccato.
Rilievo A3 [bug]
FILE: PG:src/live/shadow.py:157 + scripts/live/book_execute.py:223-226
COSA: nel percorso eq_fallback (online, posizioni leggibili, equity illeggibile) il book NON si ferma: dimensiona su FALLBACK_CAPITAL $2.000 (paper, file di stato ritirato) mentre il conto vale $4.583 -> vende meta' delle posizioni per un guasto di lettura.
SCENARIO: get_account_summary(USDC) risponde con errore o equity<=1, positions ok -> equity = 2000, cap = min(3000, 45830,5)=2291 -> target BTC 0,520000,750,4733 = $355 contro posizione $810 -> SELL reduce_only $455; ETH idem ~$425. Il giro successivo ricompra. Il commento "l'hard-cap limita il downside" copre solo il sovradimensionamento, non il sottodimensionamento che genera ordini veri.
PROVA: VERIFICATO: lettura shadow.py:153-164, book.py:199-208 (_cap usa il watermark ma l'EQUITY no), book_execute.py:223 (solo notify, niente return). Mai accaduto (grep "EQUITY FALLBACK" logs/cron_book.log -> 0).
PROPOSTA: in eq_fallback usare come equity il watermark (gia' letto per il cap) oppure non inviare ordini d'apertura/riduzione e fare solo ensure_disaster_sl.
Verifica fable A3 VERDETTO: CONFERMATO
GRAVITA': alto
PERCHE': shadow.py:153
paper_cap = FALLBACK_CAPITAL(=2000, :21) perche' data/paper_trend/state.json NON esiste (ls -> No such file); :157equity = real_eq if real_eq else paper_cap; book.py book_report :263-266 usaequity(2000) per il net target e il watermark solo per il cap; book_execute.py:223-226 su eq_fallback stampa e notifica, NON return. Con posizioni $813/$756 e target su $2.000 (0,5 x 2000 x 0,75 x 0,47 = $355) -> SELL reduce_only ~$455 BTC / ~$425 ETH reali. Mai accaduto (grep "EQUITY FALLBACK" -> 0).CORREZIONE: ok (in eq_fallback: equity = watermark, oppure niente ordini e solo ensure_disaster_sl — la seconda e' coerente con pos_error e col principio "non opero a cieco").
ANALISI (passo 1, Opus) — unita' U2, ramo lavoro/goldrake-u2, repo gitea:Adriano/PythagorasGoal
RIF: #20 (A2), #21 (A3), #22 (A10), #25 (A6), #23 (A4)
FILE: src/live/shadow.py, src/live/book.py, scripts/live/book_execute.py, src/live/execution.py (SOLO rebalance_signed, per #23), tests/
Principio unico (dichiarato): quando il giro non sa QUANTO vale il conto o QUALE e' il segnale, NON manda ordini di ribilancio ma CONTROLLA LO STESSO il disaster-SL di ogni asset (la protezione dipende da posizione e mark, non da equity o segnale). Come gia' fa pos_error, ma senza saltare la protezione.
Implementazione: in _run una variabile
solo_protezione: str | None(motivo) calcolata dopo i gate esistenti (offline, pos_error, feed stantio restano come sono: return). Nel ciclo per asset: se solo_protezione, act = "HOLD (solo protezione: )" e niente rebalance; il blocco ensure_disaster_sl resta identico. Il riepilogo finale e l'exit code: exit 2 anche quando solo_protezione (giro degradato).a) execution.DeribitTrader.rebalance_signed: se dopo almeno un fill eseguito (es. flip: close fatto) un passo successivo solleva, sollevare
RebalanceParziale(fills, causa)(nuova eccezione in execution.py, sottoclasse RuntimeError, attributi .fills e .causa). Nessun'altra modifica a execution.py (U1 lavora su _submit/open_orders/position_usd nello stesso file: non toccarli).b) book_execute: estrarre la registrazione di un fill (print " -> SIDE ...", log_event, notify) in una funzione
_registra_fill(...); chiamarla per ogni fill SUBITO dopo rebalance_signed e PRIMA di leggere newpos; newpos letto in try separato (None se illeggibile: pos_after=None nel jsonl, e la riga "reconcile: pos" diventa "reconcile: pos illeggibile ()"). Su RebalanceParziale: registra i fill di e.fills, poi rilancia la causa nell'handler di isolamento esistente.⚠️ Il formato ESATTO delle righe stampate " -> BUY 0.0100 @ $84,000.0 fee 0.00000 (OK)" e "reconcile" e' letto da src/live/tradesdb.py (parse_cron_log, regex _RE_FILL ecc.): leggi quelle regex e NON cambiare il testo delle righe che parse legge. L'ordine delle righe per un giro normale deve restare: fill..., poi reconcile. Test che parse_cron_log legge un log prodotto dal nuovo codice (giro normale e giro con RebalanceParziale).
if hasattr(trader, "set_open_cap"): trader.set_open_cap(inst, r["cap_per_asset"] * r.get("scala", 1.0), mark). hasattr perche' U1 e U2 si uniscono dopo; un commento dice che l'hasattr si toglie al merge.TEST (tests/test_book_u2.py, pattern dei test esistenti in tests/test_book_live.py / test_book_resilienza_venue.py, tutto mockato):
Suite completa:
cd <worktree> && /opt/docker/PythagorasGoal/.venv/bin/python -m pytest -q -p no:cacheprovider(baseline 1098 passed, 3 skipped).NON TOCCARE: src/live/deribit.py; in execution.py tutto tranne rebalance_signed e la nuova eccezione; config/live.json; la sequenza e i testi dei gate offline/pos_error/feed stantio; /opt/docker/PythagorasGoal. Nessuna rete, nessun ordine.
ESITO: fatto sul ramo, non in produzione
RIF: gitea:Adriano/PythagorasGoal#21
COSA: correzione su lavoro/goldrake (pushato), analisi Opus, codice Sonnet, controllo finale Opus
FILE: commit
65a7f0d841d4c7PROVA: /home/adriano/lavoro/PythagorasGoal pytest -q → 1166 passed, 3 skipped
MANCA: merge su main — richiede ok esplicito di Adriano (libro vivo). Chiusura con --soluzione dopo il merge.
PROSSIMO: ok di Adriano → merge lavoro/goldrake su main → git pull in /opt/docker/PythagorasGoal
Soluzione
scripts/live/book_execute.py: eq_fallback -> modo SOLO PROTEZIONE: nessun ribilancio, ensure_disaster_sl eseguito, un solo notify, riepilogo SOLO PROTEZIONE, exit 2.
COMMIT:
65a7f0d841d4c7, su main dal 27/09/2026 (merge con ok di Adriano). Produzione aggiornata.