Il giro d'ombra di TradingBook non è documentato qui, e gira sulla stessa crontab e sulla stessa chiave Deribit #11
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 settimanale 2026-09-16, punto URGENTE: la crontab installata ha dal 13/09 la riga di cron_ombra.sh (TradingBook), ma nel CLAUDE.md (§1, §12) non compare. Verificato il 16/09: l'ombra legge il conto con TradingBook/secrets/deribit.json, il cui client_id coincide (per hash) con DERIBIT_CLIENT_ID_LIVE di cerbero-mcp, cioè la chiave del libro vivo; legge il feed tramite il collegamento data/raw; scrive solo nel proprio albero (misurato su 3 giri: nessun file di data/ o logs/ di PG modificato). Criterio di fatto: §1 descrive l'ombra (cosa legge, dove scrive, perché non invia, chiave in comune, orario :44 e tetto), §12 la cita. Deciso da Adriano il 16/09.
Soluzione
Commit
31f5915. CLAUDE.md §1 ha il paragrafo OMBRA: la riga 44 * * * * di cron_ombra.sh (TradingBook) nella stessa crontab e la finestra fino al 30/09. Cosa legge: il conto con TradingBook/secrets/deribit.json, stesso client_id di DERIBIT_CLIENT_ID_LIVE di cerbero-mcp (confronto per hash il 16/09), e il feed tramite il collegamento data/raw. Dove scrive: solo nel suo albero, logs/cron_ombra.log, data/live/ombra.jsonl, data/live/equity_seen.json; sui giri delle 18:17, 19:17 e 20:44 del 16/09 nessun file di data/ o logs/ di PG e' cambiato. Perche' non invia: nel codice manca il percorso d'invio, come verifica test_ombra_non_invia; la chiave invece puo' fare trading, e una chiave di sola lettura la crea l'operatore. Orario :44 con timeout, fine entro :46:40 (TradingBook#16). §12 rimanda al §1.