426735448e
Nato da "stato trades" durante una manutenzione Deribit (system_maintenance 11051,
08:57-09:20 UTC). Contati i log invece che ricordarli: 1.499 giri dal 23/06, 3 con
manutenzione, 5 traceback duri — e 4 dei 5 sono il NOSTRO gateway, non il venue.
Le release Deribit escono il martedi' alle 09:00 UTC: il cron al :07 ci cadeva dentro
per costruzione (21/07, 11/08, 18/08, 25/08).
DIAGNOSI (src/live/venue_probe.py, nuovo)
Sonda l'API PUBBLICA Deribit senza gateway e senza credenziali, e classifica il guasto:
VENUE_MANUTENZIONE / VENUE_GIU / GATEWAY / IGNOTO. Prima ogni causa stampava la stessa
riga ("conto non leggibile (offline)") con nota di diagnosi CABLATA — P4 violata, e il
18/08 il codice 11051 era gia' dentro il processo senza arrivare a chi decideva la
gravita'. Parte solo dopo un guasto: sul percorso sano costa zero. P1 rispettata: la
firma 11051 si importa da venue_watch.is_maintenance, non si ridichiara.
P9: la manutenzione dentro lo slot declassa il titolo a info, ma solo su EVIDENZA della
sonda (mai sull'orologio) e solo dentro la durata annunciata — oltre, RIALZA. Un gateway
rotto di martedi' mattina resta al massimo.
DISASTER-SL SCOPERTO (src/live/execution.py)
ensure_disaster_sl cancella i bracket incoerenti PRIMA di ripiazzarne uno: fra le due
chiamate la posizione e' senza stop. Se il ripiazzamento sollevava, l'eccezione risaliva
a main() e il guasto peggiore aveva la faccia di un errore qualunque. Ora: due tentativi,
poi stato `naked`, distinto da `place-failed` (P5). Non e' "non sono riuscito a
proteggere": e' "ho tolto la protezione e non sono riuscito a rimetterla" -> allarme
massimo, mai declassato. La SEQUENZA non e' stata invertita: piazza-poi-cancella sembra
piu' sicuro ma "sembra" non basta con soldi veri senza misurarlo.
ISOLAMENTO PER ASSET (scripts/live/book_execute.py)
Il 21/07 un 502 dentro ensure_disaster_sl su BTC ha ucciso il giro intero: nel log ETH
non compare — ne' ribilanciato ne' verificato nella protezione. Ora un asset che esplode
non ferma il ciclo, e il giro degradato esce con codice 2.
CRON :07 -> :47
Il vincolo vero non era ":07" ma "fuori dai ~26s del minuto tondo" (rate-limit per-IP
auto-saturato dal collettore catena, misura del 30/07). Il :47 lo soddisfa e in piu' sta
fuori dallo slot di release. PREVISIONE DICHIARATA (M12): 3 delle 4 finestre osservate
sono rientrate entro l'ora -> il :47 ne avrebbe scavalcate 3 su 4; se martedi' prossimo
becca comunque la manutenzione, la previsione e' sbagliata.
WATERMARK AVVELENATO DAI TEST (tests/conftest.py, nuovo)
Trovato addosso: lanciando la suite, data/live/equity_seen.json passava a $5.000 e il giro
successivo mandava un allarme Telegram FALSO ("USCITA DI FONDI -86,6%"). Non cosmetico:
cap_fallback = min(cap_config, watermark x frac) sarebbe passato da $334 a $2.500/asset,
~7,5x di leva su un conto da $668, sul ramo eq_fallback che allerta e NON blocca — cioe'
i test potevano armare il pericolo che il watermark esiste per impedire. Riparato con una
fixture AUTOUSE, non per-test: chiedere a ogni autore di ricordarsene ha gia' perso il
26/07 e il 21/08. Resta esposto lo stesso errore su trades.db e book_executions.jsonl.
BLOCCATO, NON RINVIATO
Il fallback diretto ai privati Deribit richiede chiavi API create dall'operatore: in
locale esiste solo CERBERO_TOKEN. Il gateway resta un punto singolo di guasto non
aggirabile (CLAUDE.md 5.11). La sonda dice di chi e' il guasto, non lo aggira.
Test: 20 nuovi, nessuno tocca la rete; controllo positivo fatto (5 su 7 falliscono contro
il codice vecchio). Suite 730 passati, 1 fallito — quello gia' noto di 5.9 (deriva dati).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1
53 lines
2.6 KiB
Python
53 lines
2.6 KiB
Python
"""Isolamento della suite dai FILE OPERATIVI VIVI.
|
|
|
|
⚠️ PERCHE' ESISTE (2026-08-25, difetto trovato addosso). Lanciando `uv run pytest` la suite ha
|
|
scritto **$5.000 dentro `data/live/equity_seen.json`**, il watermark dell'equity reale del conto.
|
|
Al primo giro successivo del book (09:47 UTC) l'esecutore ha confrontato l'equity vera contro quel
|
|
valore e ha mandato un allarme Telegram:
|
|
|
|
💰 USCITA DI FONDI: $5,000.00 -> $667.68 (-86.6%)
|
|
|
|
**Falso, e generato da un test.** Il colpevole e'
|
|
`test_book_live.py::test_la_formula_del_report_ha_potenza_anche_a_libro_flat`: prende solo
|
|
`monkeypatch` (niente `tmp_path`), sostituisce `shadow_report` con uno che dichiara
|
|
`real_equity=5000.0` e poi chiama `book.book_report()` — che come effetto collaterale scrive il
|
|
watermark. L'helper `_write_cfg` esisteva gia' proprio per questo (difetto gemello del 2026-07-26),
|
|
ma quel test, aggiunto il 21/08, non lo usa.
|
|
|
|
**NON e' un fastidio cosmetico.** Il watermark alimenta il cap di fallback:
|
|
|
|
cap_fallback = min(cap_fisso_di_config, watermark * frac)
|
|
|
|
Con `watermark = $5.000` il cap diventa `min($3.000, $2.500) = $2.500` per asset invece di `$334`:
|
|
su un conto da $668 sono fino a **$5.000 di nozionale lordo, ~7,5x di leva**. Ed e' raggiungibile:
|
|
il ramo `eq_fallback` di `book_execute` **allerta e NON blocca** per scelta dichiarata. Cioe'
|
|
lanciare la suite di test poteva **armare esattamente il pericolo che il watermark esiste per
|
|
impedire** (vedi `src/live/book.py`, nota del 2026-07-26 sul cap fisso e la leva 3,35x).
|
|
|
|
**LA RIPARAZIONE E' STRUTTURALE, NON PER-TEST.** Chiedere a ogni autore di ricordarsi il
|
|
monkeypatch e' la stessa scommessa che ha gia' perso due volte (26/07 e 21/08). Qui il
|
|
reindirizzamento e' **autouse**: vale per ogni test, anche per quelli che verranno scritti domani
|
|
da chi non ha letto questo file. Un test che vuole davvero pilotare il watermark continua a
|
|
funzionare — il suo monkeypatch esplicito vince su questo, che gira prima.
|
|
"""
|
|
import sys
|
|
from pathlib import Path
|
|
|
|
import pytest
|
|
|
|
PROJECT_ROOT = Path(__file__).resolve().parents[1]
|
|
sys.path.insert(0, str(PROJECT_ROOT))
|
|
|
|
|
|
@pytest.fixture(autouse=True)
|
|
def _isola_file_operativi_vivi(tmp_path, monkeypatch):
|
|
"""Ogni test scrive il watermark in una cartella temporanea, mai in `data/live/`.
|
|
|
|
Il valore iniziale NON viene precaricato: un test che si aspetta un watermark deve
|
|
dichiararlo, e la prima lettura in assoluto non produce allarmi per costruzione
|
|
(`write_equity_watermark` ritorna None quando non c'e' un "prima").
|
|
"""
|
|
import src.live.book as book
|
|
monkeypatch.setattr(book, "EQUITY_WATERMARK", tmp_path / "equity_seen.json")
|
|
yield
|