osservabilita': fee realizzate mai confrontate, trades.db senza ora del fill, CLAUDE.md al tetto del revisore #37

Closed
opened 2026-09-27 13:12:15 +00:00 by Adriano · 3 comments
Owner

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-246 realized_fee_bps() vive solo nel blocco if 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 reconcile dicono che book_executions.jsonl non 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 e pos_after. trades.db invece prende ts di INIZIO giro, prezzo arrotondato a 1 decimale e lascia pos_after/order_id NULL. Inoltre il parser scarta in silenzio un fill senza riga di segnale precedente (riga 214) e sync non 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,18 docstring «senza ora»; misurato data/live/book_executions.jsonl: 166 righe, 147 con ts_utc a 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 sync non chiama reconcile ne' confronta conteggi (reconcile e' solo il comando manuale, riga 40-50). Parser: tradesdb.py:214 scarta 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_VOCE 90.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:42 MAX_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).

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-246` `realized_fee_bps()` vive solo nel blocco `if 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 `reconcile` dicono che `book_executions.jsonl` non 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 e `pos_after`. trades.db invece prende ts di INIZIO giro, prezzo arrotondato a 1 decimale e lascia `pos_after`/`order_id` NULL. Inoltre il parser scarta in silenzio un fill senza riga di segnale precedente (riga 214) e `sync` non 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,18` docstring «senza ora»; misurato `data/live/book_executions.jsonl`: 166 righe, 147 con `ts_utc` a 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 sync` non chiama `reconcile` ne' confronta conteggi (reconcile e' solo il comando manuale, riga 40-50). Parser: `tradesdb.py:214` scarta 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_VOCE` 90.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:42` `MAX_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).
Adriano added the sviluppo label 2026-09-27 13:12:15 +00:00
Author
Owner

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.

  1. Calcolarlo sempre, fuori dal blocco di stampa, e registrarlo nel record del giro. Dove oggi fee_watch registra i giri: runs.jsonl o lo state, guarda il codice.
  2. Avviso: se |realized - tier pubblico atteso| > 1 bps, notify UNA volta per episodio.
    • Marcatore nello state di fee_watch, es. "divergenza_detta": true, azzerato quando torna sotto soglia.
    • Si scrive solo se notify ha restituito True: stessa regola di #29 B8, gia' nel file, seguila.
  3. "NON MISURATO" (nessun trade) -> nessun avviso, registrato come None.

C11 — src/live/tradesdb.py e scripts/live/trades_db.py

  1. Docstring tradesdb.py:5-20. E' anche il punto A9 di #35, qui. Da correggere: book_executions.jsonl HA l'ora del fill dal 2026-08-24 01:07Z (campo ts_utc), con prezzo a piena precisione e pos_after. Il cron_book.log invece da' l'ora di inizio giro. Verifica i campi leggendo UNA riga recente di data/live/book_executions.jsonl nella cartella (copia locale dei dati).
  2. 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.
    • Se diversi: riga "⚠️ trades.db: N fill nel jsonl, M nel DB dal 24/08" e notify una volta per episodio (marcatore come B9, scritto solo su invio riuscito).
    • Guarda come trades_db decide dove sta il DB e se sync ha gia' uno state.
  3. L'ARRICCHIMENTO di ts/prezzo/pos_after dal jsonl nel DB NON si fa in questa unita' (sviluppo, TradingBook#11 lo tocca). Scrivilo nel rapporto come non fatto.

C12 — src/live/revisione.py:42 MAX_CHARS_VOCE = 90_000

  • Tetto per-voce distinto per CLAUDE.md: 150_000. Il totale resta 400k: verifica che la somma dei tetti non lo superi o che il totale sia applicato a parte.
  • Avviso nel rapporto (riga di testo nel prompt/rapporto, come oggi e' marcato [TRONCATO]) quando una voce supera il 95% del suo tetto.
  • NON toccare il taglio per Telegram a righe ~261 (lo fa un'altra unita').

TEST

  • B9: record con realized; divergenza > 1 bps -> una notify; secondo giro stesso episodio -> nessuna; notify False -> marcatore non scritto; ritorno sotto soglia -> marcatore azzerato. Monkeypatch dei trade e di notify, nessuna rete.
  • C11: DB e jsonl finti in tmp_path, conteggi uguali -> niente; diversi -> una notify.
  • C12: una voce CLAUDE.md da 120k non troncata; una voce da 86k su tetto 90k -> avviso 95%.
    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)".
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. 1. Calcolarlo sempre, fuori dal blocco di stampa, e registrarlo nel record del giro. Dove oggi fee_watch registra i giri: runs.jsonl o lo state, guarda il codice. 2. Avviso: se |realized - tier pubblico atteso| > 1 bps, notify UNA volta per episodio. - Marcatore nello state di fee_watch, es. "divergenza_detta": true, azzerato quando torna sotto soglia. - Si scrive solo se notify ha restituito True: stessa regola di #29 B8, gia' nel file, seguila. 3. "NON MISURATO" (nessun trade) -> nessun avviso, registrato come None. C11 — src/live/tradesdb.py e scripts/live/trades_db.py 1. Docstring tradesdb.py:5-20. E' anche il punto A9 di #35, qui. Da correggere: book_executions.jsonl HA l'ora del fill dal 2026-08-24 01:07Z (campo ts_utc), con prezzo a piena precisione e pos_after. Il cron_book.log invece da' l'ora di inizio giro. Verifica i campi leggendo UNA riga recente di data/live/book_executions.jsonl nella cartella (copia locale dei dati). 2. 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. - Se diversi: riga "⚠️ trades.db: N fill nel jsonl, M nel DB dal 24/08" e notify una volta per episodio (marcatore come B9, scritto solo su invio riuscito). - Guarda come trades_db decide dove sta il DB e se sync ha gia' uno state. 3. L'ARRICCHIMENTO di ts/prezzo/pos_after dal jsonl nel DB NON si fa in questa unita' (sviluppo, TradingBook#11 lo tocca). Scrivilo nel rapporto come non fatto. C12 — src/live/revisione.py:42 MAX_CHARS_VOCE = 90_000 - Tetto per-voce distinto per CLAUDE.md: 150_000. Il totale resta 400k: verifica che la somma dei tetti non lo superi o che il totale sia applicato a parte. - Avviso nel rapporto (riga di testo nel prompt/rapporto, come oggi e' marcato [TRONCATO]) quando una voce supera il 95% del suo tetto. - NON toccare il taglio per Telegram a righe ~261 (lo fa un'altra unita'). TEST - B9: record con realized; divergenza > 1 bps -> una notify; secondo giro stesso episodio -> nessuna; notify False -> marcatore non scritto; ritorno sotto soglia -> marcatore azzerato. Monkeypatch dei trade e di notify, nessuna rete. - C11: DB e jsonl finti in tmp_path, conteggi uguali -> niente; diversi -> una notify. - C12: una voce CLAUDE.md da 120k non troncata; una voce da 86k su tetto 90k -> avviso 95%. 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)".
Author
Owner

ESITO: fatto sul ramo, non in produzione
RIF: gitea:Adriano/PythagorasGoal#37
FILE: commit 95cfb39 13c136c ac6ad7f 28a6d79 su lavoro/goldrake (pushato, HEAD d34b0a8)
PROVA: /home/adriano/lavoro/PythagorasGoal pytest -q → 1220 passed, 3 skipped
MANCA: merge su main con ok di Adriano; poi issue chiudi --soluzione

ESITO: fatto sul ramo, non in produzione RIF: gitea:Adriano/PythagorasGoal#37 FILE: commit 95cfb39 13c136c ac6ad7f 28a6d79 su lavoro/goldrake (pushato, HEAD d34b0a8) PROVA: /home/adriano/lavoro/PythagorasGoal pytest -q → 1220 passed, 3 skipped MANCA: merge su main con ok di Adriano; poi issue chiudi --soluzione
Author
Owner

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 95cfb39 13c136c ac6ad7f.
Su main d34b0a8 dal 27/09/2026 17:31Z, produzione aggiornata. Test 1220 passed.

**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 95cfb39 13c136c ac6ad7f. Su main d34b0a8 dal 27/09/2026 17:31Z, produzione aggiornata. Test 1220 passed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Adriano/PythagorasGoal#37