eccezione nel calcolo SKH01 -> SKH flat su entrambi gli asset e ordini inviati #22
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 A10 [bug]
FILE: PG:src/live/book.py:302-306 + scripts/live/book_execute.py:131-133
COSA: un'eccezione nel calcolo SKH01 forza skh_sign=0 su ENTRAMBI gli asset e il giro PROSEGUE inviando ordini: chiude la quota SKH aperta per un guasto software/dato. Contraddice la scelta dichiarata per il feed stantio (book_execute.py:140-142: "forzare SKH flat chiuderebbe posizioni buone su un glitch" -> non si fa).
SCENARIO: SKH short BTC aperto (net = 0,54583(0,75*0,47-0,25) = $240), load_data(5m) o build_frames solleva (file certificato illeggibile/troncato durante una riscrittura, dipendenza rotta) -> net diventa $813 -> BUY $573 reale; al giro dopo, se il calcolo torna, SELL $573 per riaprire lo short a un prezzo diverso. Solo notify "SKH feed fallito", nessun blocco.
PROVA: VERIFICATO: lettura book.py:302-306 (except -> {a: "flat"}) e book_execute.py:131-133 (notify e prosegue); test_book_execute_surfaces_skh_error in tests/test_book_live.py:417 verifica solo la stampa. Mai accaduto (grep "SKH FEED ERRORE" logs/cron_book.log -> 0).
PROPOSTA: con skh_error non inviare ordini (tenere la posizione, eseguire solo ensure_disaster_sl), come per pos_error; oppure tenere la quota SKH dedotta dalla posizione corrente meno la quota TP01.
Verifica fable A10 VERDETTO: CONFERMATO
GRAVITA': alto
PERCHE': book.py:293-296
except Exception: skh = {a: "flat"}+ book_execute.py:130-133 solo print+notify e prosegue; il net target cambia di 0,5 x equity x 0,25 = $573 per asset con SKH aperto -> ordine reale (BUY se era short, SELL reduce_only se era long) per un guasto software/dato. Contraddice la scelta dichiarata a book_execute.py:140-142 per il feed stantio. tests/test_book_live.py verifica solo la stampa. Mai accaduto (grep -> 0).CORREZIONE: ok (con skh_error: nessun ordine, solo ensure_disaster_sl; allerta come oggi).
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#22
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: skh_error -> SOLO PROTEZIONE (nessun ordine su segnale ignoto), un solo notify.
COMMIT:
65a7f0d841d4c7, su main dal 27/09/2026 (merge con ok di Adriano). Produzione aggiornata.