Files
PythagorasGoal/docs/diary/2026-09-09c-revisione-settimanale.md
T
Adriano Dal Pastro 8f2e6c5c2c revisione settimanale in sola lettura: revisore fable, rapporto firmato + Telegram, lunedi' 06:15 UTC
- src/live/revisione.py: materiale (CLAUDE.md, config, crontab, git, monitor_health, stati dei
  sorveglianti, 7 g di giornale e diari, ~195k caratteri), prompt con dieci regole (sola lettura, fonte
  per ogni segnalazione, solo numeri del materiale, §3 non si ripropone, idee nuove solo citando la
  memoria, gate con data e criterio), guardia sui numeri, rapporto firmato (P13), Telegram = Sintesi
  con taglio dichiarato; modello muto o risposta senza titoli -> rapporto «NON eseguita» + 🚨 (P5).
- scripts/live/revisione.py (guardia cli.valida, --secco/--no-telegram/--quiet/--giorno/--modello),
  scripts/cron_review.sh, crontab `15 6 * * 1`.
- primo giro reale: il prompt su argv moriva con `Argument list too long` senza rapporto ne' allerta ->
  prompt su stdin, ogni eccezione diventa errore dichiarato; `analista.pulisci` toglieva i titoli.
  Secondo giro: docs/revisioni/2026-09-09.md, stato sospetta (cifre in formato italiano), nessun URGENTE.
- scartati con la memoria: autoregolazione dei parametri, generazione automatica di strategie, macro
  da internet (diario 2026-09-09c, memoria 40).
- test: tests/test_revisione.py (18) + 2 in test_cli_flag; suite 1031/1031.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjj5vPEBoAJrB23P6RjKzs
2026-09-09 22:07:50 +00:00

8.0 KiB

2026-09-09c — Revisione settimanale in sola lettura: cosa si costruisce e cosa no

Richiesta dell'operatore: «schedulare ogni x tempo un processo di auto revisione dei dati e della configurazione del sistema in modo che migliori con il tempo … autoregolazione e autoaggiornamento dei sistemi o anche creare nuovi sistemi … valutando dati macroeconomici … e poi informa me tramite Telegram». Dopo la discussione: «fai».

Esito in una riga: costruita la rilettura settimanale in sola lettura con revisore diverso dall'autore (claude-fable-5-1), rapporto firmato in docs/revisioni/ e Sintesi su Telegram, lunedi' 06:15 UTC; scartati — con la memoria del progetto, non per prudenza generica — autoregolazione dei parametri, generazione automatica di strategie e macro da internet. Libro, config, pesi: invariati.

1. Perche' tre pezzi su quattro sono no

pezzo cosa dice la memoria esito
auto-revisione periodica nove sorveglianti, ognuno sulla sua grandezza; nessuno rilegge l'insieme; la revisione col secondo modello ha trovato oggi due conclusioni false e un look-ahead si'
autoregolazione dei parametri TP01/SKH01 congelati (M20), 75/25 confermato 3 volte, weights_tilt_null fallisce; scale_watch esiste per rendere visibile ogni cambio di config; A8: una riga di config + una di giornale, decisione dell'operatore no
generazione e test di strategie nuove 69 filoni in 6 ondate; ogni candidato e' un trial (M3) e deflaziona tutto; la ricerca non e' il vincolo binding dal 26/07 (+0,046 €/g il miglior lead contro +4,07%/anno per €100/mese) no, salvo freno: prima si apre la memoria e si batte il motivo della morte; i candidati vanno in forward-monitor con gate e data, mai nel book
dati macro da internet gate macro / DVOL direzionale / skew de-risk: HEDGE o ridondanti (TP01 gia' flat nei crolli); un dato dal web non e' certificato (D1-D4; la APR USDC 3,40% pubblicata e mai incassata) no

Il centro dell'argomento: il progetto ha gia' misurato che piu' ricerca non sposta il traguardo, i bonifici si'. Un ciclo automatico che cerca strategie ottimizza la leva sbagliata e paga in trial bruciati.

2. Cosa gira

scripts/cron_review.sh (lunedi' 06:15 UTC: fuori dal :00, fuori dal martedi' 09:00, dopo il cron_daily delle 00:30 cosi' il giornale di domenica e' chiuso) → scripts/live/revisione.py --quietsrc/live/revisione.scrivi. Riga installata in crontab (15 6 * * 1), letta dal test.

Materiale (sola lettura, ~195k caratteri, 27 voci): CLAUDE.md intero · config/live.json · crontab -l · git log 14 g + git status · monitor_health · stato dei sorveglianti (scale, vrp_f, usde, balance, venue_news, movimenti dichiarati, watermark) · 7 pagine di giornale · diari della settimana. Gli stati stanno prima delle voci grandi: alla prima stesura il tetto totale (320k) aveva tagliato usde_convert.jsonl a 2 caratteri — un sorvegliante invisibile per un limite di lunghezza.

Prompt: dieci regole vincolanti (sola lettura · ogni segnalazione cita la fonte · solo numeri del materiale · le decisioni di §3 non si ripropongono se la colonna «cosa la riapre» non e' soddisfatta · un'idea nuova solo citando la memoria che ha ucciso la simile · i gate con data e criterio, senza anticipare · misurato ≠ dedotto · niente previsioni · URGENTE per cio' che serve all'operatore subito · cinque titoli fissi, ~1.000 parole). L'ultimo titolo, «Cosa ho letto e cosa mi mancava», e' l'elenco da cui il materiale della settimana dopo migliora: e' l'unico «miglioramento col tempo» che questo sistema si concede, e passa da una modifica al codice, cioe' da una revisione.

Uscita: docs/revisioni/<data>.md firmato (modello, ora, «SOLA LETTURA», «lettore fallibile P13», guardia sui numeri come analista con soglia 12, tabella del materiale letto). Telegram: la sola Sintesi, taglio dichiarato sotto i 4.096. Modello muto o risposta senza i titoli → rapporto «NON eseguita» col motivo e 🚨: il silenzio non e' una revisione (P5).

Cosa non puo' fare, per costruzione: scrivere altro che il rapporto (test sull'albero dei file: --secco non scrive niente, un giro scrive UN file), eseguire proposte, cambiare config. Il modello e' claude-fable-5-1 per costante, e un test verifica che sia diverso da analista.MODELLO_DEFAULT.

3. Test — tests/test_revisione.py (16)

Finestra del materiale e file assenti dichiarati · ordine stati-prima-delle-voci-grandi · troncamento dichiarato · regole nel prompt · guardia (vuoto, titoli mancanti, numeri fuori con controllo positivo) · rapporto firmato · modello muto → rapporto + 🚨 · Telegram con HTML neutralizzato e taglio dichiarato · --secco non chiama e non scrive · un giro scrive un solo file · --no-telegram · revisore ≠ autore · cadenza: il .sh dichiara «lunedi' HH:MM UTC», minuto ≠ 0, fuori dallo slot di release, e la crontab installata ha gli stessi cinque campi (skip se illeggibile). test_cli_flag ha preso lo script da solo (guardia valida, USO coi flag, flag del cron accettati).

4. Errori in sessione

  • _tronca(testo, n=MAX_CHARS_VOCE): il default e' catturato alla definizione, il test che patchava la costante non vedeva niente — la stessa trappola del debito 12 (connect). Letto a runtime.
  • Il tetto totale tagliava in coda: i sorveglianti erano gli ultimi e i primi a sparire. Riordinato, e il test lo presidia.

5. Primo giro reale (22:03Z) — e i tre difetti che solo il giro reale poteva trovare

Il primo lancio e' morto prima di chiamare il modello: OSError: Argument list too long — 195k caratteri di prompt passati come argomento alla CLI superano il limite del sistema, e analista.interroga non lo catturava: zero rapporto, zero Telegram, il silenzio che il modulo esiste per vietare. Nessun test l'avrebbe trovato (i test iniettano interroga): e' un difetto di trasporto, e il trasporto si valida sul trasporto (P2). Tre correzioni: (1) revisione.interroga proprio, prompt su stdin, ogni eccezione restituita come errore; (2) scrivi incapsula chiamata e invio: un'eccezione diventa un rapporto «NON eseguita» + 🚨; (3) _cmd (crontab, git) dichiara qualunque eccezione invece di propagarla. Test con controllo positivo su OSError(7). Terzo difetto, trovato dal test: analista.pulisci toglie le righe che iniziano con #, cioe' i cinque titoli che la guardia richiede — usarlo avrebbe reso ogni revisione «rifiutata: titoli mancanti». Sostituito con strip().

Secondo lancio: rapporto scritto, stato sospetta, 1.435 parole, docs/revisioni/2026-09-09.md. La guardia ha segnato 11 numeri «non nel materiale»: sono cifre in formato italiano («4.477,46», «1.341») contro il materiale in formato USA («$4,477.46») — la normalizzazione di analista conosce una convenzione sola. E' un limite dichiarato, non un errore del revisore: si aggiusta quando si vede quanto spesso scatta. Contenuto: nessun URGENTE; tre verifiche in cima (una possibile attribuzione a reward di 400 USDE che erano un acquisto in usde_watch del 07/09 — n_trades fermo a 50 contro 54 ordini nel registro; il cuscino USDC del debito §5.17 senza definizione balance/equity; il versamento del 04/09 non dichiarato in movimenti_dichiarati.jsonl); una contraddizione in CLAUDE.md §1 sull'haircut (M28); la data di arming che differisce fra §0, config e TWR; quattro sorveglianti senza timestamp o fuori da monitor_health; e, come richiesto dalla regola 5, zero idee di strategia. «Cosa mi mancava»: stati con ora di edge/fee/venue/scale_watch, l'output di usde_watch.rendimento(), i paper a oggi, cron_daily.sh, il registro fill della settimana — l'elenco da cui il materiale della prossima settimana migliora. Le segnalazioni sono dell'operatore e della prossima sessione: nessuna e' stata applicata qui (sarebbe l'agente che esegue le proposte del revisore nello stesso giro, cioe' il ciclo che si e' scartato). Costo: una chiamata, ~4 minuti.