osservabilita': fee realizzate mai confrontate, trades.db senza ora del fill, CLAUDE.md al tetto del revisore #37
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 B9 [miglioria]
FILE: pg:scripts/live/fee_watch.py:221,235-246
COSA: il cross-check sulle fee REALMENTE pagate (la fonte "autorevole") si calcola solo dentro il blocco di stampa, che in cron (--quiet) gira solo se il tier pubblico cambia: la divergenza tier/conto non e' mai sorvegliata, e anche quando si stampa "⚠️ DIVERGE" non allerta.
SCENARIO: il conto paga 7 bps effettivi con tier pubblico 5 -> fee_watch tace per sempre.
PROVA: VERIFICATO:
grep -c "cross-check sui trade" logs/cron_daily.log-> 4 in tutta la storia del log (ultima: NON MISURATO).PROPOSTA: calcolare realized_fee_bps() sempre, registrarlo in runs.jsonl, e allertare su |diff| > 1 bps una volta per episodio.
Verifica fable B9 VERDETTO: CONFERMATO
GRAVITA': basso (miglioria)
PERCHE':
fee_watch.py:221-246realized_fee_bps()vive solo nel bloccoif not quiet or interessante; in cron (--quiet) gira solo se cambia il tier; il «⚠️ DIVERGE» e' solo stampa, nessun notify/registro.CORREZIONE: ok.
Rilievo C11 [miglioria]
FILE: PG:src/live/tradesdb.py:5-20, 230-261; scripts/live/trades_db.py:22-37
COSA: il docstring e
reconciledicono chebook_executions.jsonlnon ha l'ora: dal 2026-08-24 01:07Z ce l'ha (147/166 righe con ts del fill, es. 00:47:28 contro 00:47:01 del log), con prezzo a piena precisione epos_after. trades.db invece prende ts di INIZIO giro, prezzo arrotondato a 1 decimale e lasciapos_after/order_idNULL. Inoltre il parser scarta in silenzio un fill senza riga di segnale precedente (riga 214) esyncnon confronta mai i conteggi: se il formato del log cambia, trades.db smette di crescere senza allarme (oggi: 166 = 166, 0 righe non parsate).PROPOSTA: in
sync, per le righe jsonl con ora vera, arricchire ts/prezzo/pos_after e allertare (Telegram) se il numero di fill jsonl post-24/08 != fill DB nello stesso intervallo. (Non riproporre la duplicazione dei parser: TradingBook#11.)Verifica fable C11 VERDETTO: CONFERMATO
GRAVITA': basso (miglioria)
PERCHE':
tradesdb.py:5-8,18docstring «senza ora»; misuratodata/live/book_executions.jsonl: 166 righe, 147 conts_utca ora vera (campi: ts_utc, bar_ts, asset, action, side, filled, price, fee, verified, notes, net_target, pos_after).scripts/live/trades_db.py:22-37 syncnon chiamareconcilene' confronta conteggi (reconcile e' solo il comando manuale, riga 40-50). Parser:tradesdb.py:214scarta il fill senza riga di segnale.CORREZIONE: ok, con la riserva del revisore (non duplicare i parser, TradingBook#11).
Rilievo C12 [miglioria]
FILE: PG:src/live/revisione.py:42, 139-140
COSA: CLAUDE.md e' a 89.590 caratteri contro
MAX_CHARS_VOCE90.000 (410 di margine; 87.916 al 21/09, +1.674 in una settimana). Alla prossima crescita il revisore leggera' CLAUDE.md troncato in coda (§12-15), marcato [TRONCATO] ma senza sezioni.PROVA: VERIFICATO:
len(open('CLAUDE.md').read())= 89590; tabella di docs/revisioni/2026-09-21.md = 87,916.PROPOSTA: alzare il tetto per CLAUDE.md (il totale e' 400k) o darne le sezioni rilevanti.
Verifica fable C12 VERDETTO: CONFERMATO
GRAVITA': basso
PERCHE':
python3 -c "len(open('CLAUDE.md').read())"-> 89590;src/live/revisione.py:42MAX_CHARS_VOCE = 90_000(commento «CLAUDE.md sta sotto»: per 410 caratteri). Al superamento la coda (§12-15) sparisce dal prompt del revisore settimanale.CORREZIONE: ok (tetto per-voce distinto per CLAUDE.md, o avviso nel rapporto quando la voce supera il 95% del tetto).
ANALISI (passo 1, Opus, 27/09/2026)
ANALISI U11 — gitea:Adriano/PythagorasGoal#37 (B9, C11, C12) + #35 A9 per la sola parte tradesdb.py
CARTELLA: /home/adriano/lavoro/PG-u11 RAMO: lavoro/goldrake-u11 (da main
841d4c7)Testo dei rilievi:
issue --repo Adriano/PythagorasGoal --forge gitea mostra 37.B9 — scripts/live/fee_watch.py:221-246
PERCHE': realized_fee_bps() gira solo dentro il blocco di stampa. In cron (--quiet) quindi non gira mai, e "DIVERGE" non avvisa nessuno.
C11 — src/live/tradesdb.py e scripts/live/trades_db.py
sync: dopo la sincronizzazione confrontare il numero di fill in jsonl con ts_utc >= 2026-08-24T01:07 e i fill in DB nello stesso intervallo.C12 — src/live/revisione.py:42 MAX_CHARS_VOCE = 90_000
TEST
Suite:
cd /home/adriano/lavoro/PG-u11 && /opt/docker/PythagorasGoal/.venv/bin/python -m pytest -q -p no:cacheprovider. Baseline 1166 passed, 3 skipped.NON TOCCARE: il parser di cron_book.log in tradesdb (oltre il docstring), book_execute.py, analista.py.
COMMIT: "(#37 B9)", "(#37 C11, #35 A9)", "(#37 C12)".
ESITO: fatto sul ramo, non in produzione
RIF: gitea:Adriano/PythagorasGoal#37
FILE: commit
95cfb3913c136cac6ad7f28a6d79su lavoro/goldrake (pushato, HEADd34b0a8)PROVA: /home/adriano/lavoro/PythagorasGoal pytest -q → 1220 passed, 3 skipped
MANCA: merge su main con ok di Adriano; poi issue chiudi --soluzione
Soluzione
B9 fee_watch: realized_fee_bps sempre calcolata e registrata, divergenza >1 bps avvisata una volta per episodio. C11 trades_db sync confronta conteggi jsonl/DB dal 24/08 e avvisa una volta; docstring tradesdb corretto. C12 revisione: tetto CLAUDE.md 150k e avviso al 95%. Arricchimento ts/prezzo nel DB non fatto (TradingBook#11). Commit
95cfb3913c136cac6ad7f.Su main
d34b0a8dal 27/09/2026 17:31Z, produzione aggiornata. Test 1220 passed.