PythagorasGoal/docs/diary/2026-09-10-cinque-punti-revisione.md

I cinque punti della revisione del 09/09 — decisi e fatti

Data: 2026-09-10 (sessione 12:08Z → 13:10Z; i timestamp qui dentro sono letti, non ricordati) Origine: la prima revisione settimanale (docs/revisioni/2026-09-09.md, revisore fable) e il giornale del 09/09. Ogni punto e' stato spiegato all'operatore con pro e contro e deciso da lui (§3-style: decisioni con l'informazione completa). Issue sul Gitea di casa #2-#6, chiuse con la soluzione scritta (regola globale del 10/09).

Le decisioni, in una tabella

#	punto	decisione dell'operatore	issue
1	usde_watch contava 400 USDE come reward (07/09)	ripara ora + issue	#2 bug
2	cuscino USDC senza sorvegliante (§5.17)	equity USDC, riconverte da solo	#3 sviluppo
3	versamento 04/09 solo rilevato; piano €5.000 «in attesa»	e' l'INTERO versamento previsto: dichiarato, piano chiuso	#6 sviluppo
4	SCALA-01 A2: da quando contano i 180 giorni	dal 01/09 (sorvegliante attivo) → gate non prima del 2027-02-28	#5 bug
5	PREVDAY-01 «senza data»	tieni 21/06/2027, cabla kill e veto, correggi §4	#4 bug

Sul punto 5 la domanda giusta e' stata «ricorda dove dobbiamo arrivare (50 €/g)»: PREVDAY de-luckato al 15% vale +0,10 di Sharpe sul libro e la somma di tutti i lead dell'ondata di agosto vale +0,036 €/giorno. Verso i 50 €/g il candidato vale centesimi in qualunque esito del gate: non si spende una sessione di ricerca per anticipare (a)+(b), e non si butta l'unica gamba short scorrelata oltre a SKH01 per risparmiare un cron. Costo scelto: mezza giornata, una volta.

Punto 1 — il lettore dei trade spot aveva DUE limiti, non uno

Il primo era noto dalla revisione: trade_history(limit=50) con 54 ordini. Il secondo l'ho trovato sondando il gateway per ripararlo: get_user_trades_by_instrument chiamato senza historical restituisce solo le ultime ~24 ore — il fill BTC dell'08/09 06:47Z e' invisibile alle 12:55Z del 10/09, quello del 09/09 21:47Z si vede. Il cron gira ogni 24h alle 12:35: sta dentro la finestra per pochi secondi. Un giro saltato avrebbe reso invisibili i trade fra 48h e 24h fa, e il delta sarebbe stato attribuito al reward esattamente come il 07/09, con un meccanismo diverso.

Ora trade_copertura() dichiara non leggibile (somma None, e analizza non attribuisce: P12) in entrambi i casi — lista lunga quanto il limite (troncata) o ultima lettura oltre 24h+5min — e il record porta trades_motivo (P4: il perche'). TRADE_LIMIT = 1000 e' il count massimo di Deribit. Controllo positivo nei test: 54 ordini si sommano tutti.

La riga del 07/09 in data/live/usde_watch.jsonl e' corretta in loco con campo correzione (originale conservato dentro, copia del file in usde_watch.jsonl.pre_fix_20260910): 54 ordini = 8 + 30 + 16 dal registro usde_convert.jsonl, 2.434 USDE, reward 0,080934. Il tasso non cambia — la riga era gia' esclusa per con_trade — e rendimento() oggi da' 3,94% su 14 finestre, 12 pagate.

Punto 2 — cuscino_watch: la grandezza che nessuno guardava

Il cuscino richiesto e' 2 × 0,5 × 0,30 × equity_tot = 30% dell'equity, derivato da config e book.WEIGHT. La formula e' passata da usde_convert.py a src/live/usde.py, e usde_convert la importa da li': due lettori, una formula (P1 — cinque occorrenze nel progetto di sorveglianti puntati su un bersaglio ridichiarato).

stato	criterio	azione
OK	slack ≥ 10% del cuscino	niente
PREAVVISO	0 ≤ slack < 10%	⚠️ alla transizione
SCOPERTO	slack < 0	🚨 + usde_convert --quota 0,64 --esegui (cuscino + 20% di margine, alzato dal 10% in revisione)
BLIND	conto non leggibile	⚠️ alla transizione

Guardie della riconversione: execution_enabled del libro (un solo interruttore), niente vendita sotto depeg_warn (li' decide l'operatore, e l'allarme lo dice), un tentativo ogni 6h, le guardie proprie di usde_convert (banda di prezzo, book leggibile, tetto HARD) ereditate lanciando lo script vero (P15). Il marcatore «gia' detto» e' l'esito di notify: un invio fallito non consuma la transizione (lezione del debito §5.2). Cron :53 = dopo il giro del book (:47), fuori dal minuto tondo. monitor_health lo sorveglia (max 3h).

📌 Primo giro a secco (13:00Z): gia' PREAVVISO. USDC equity $1.361,23 contro $1.335,26 richiesti: slack +$25,97. Il 09/09 il revisore aveva stimato +$41/+$59; la marcatura del libro dal picco del 06/09 ne aveva consumati altri 15-30 senza che nessuno lo vedesse. E' il caso d'uso del sorvegliante, arrivato prima del sorvegliante.

Punto 3 — il versamento del 04/09, dal balance e non dall'equity

Il salto di equity 13:47→14:47Z diceva +$2.410,14 col mercato dell'ora dentro. Il balance USDC di balance_watch (cambia solo per P&L realizzato, fee, funding e movimenti) dice 1.417,73455581 → 3.832,41432481 = +$2.414,68, nessun fill nella finestra, funding su $541 di nozionale ~$0,01. Dichiarato con banda $0,05. Il report ora lo mostra come dichiarato e il TWR passa a +6,66% (era +7,22% stamattina, +7,83% il 06/09): la coda −0,63% dal 04/09 e' marcatura delle due long, trading da arming +$13,82.

L'operatore ha detto che era l'intero versamento previsto: la voce «in attesa di importo e data» di §1 e' chiusa. Resta la lezione di §2: per sei giorni il movimento e' stato solo rilevato, la regola diceva il giorno stesso.

Punto 4 — SCALA-01: la data era il punto 5 della SPEC scambiato per il gate

«Non prima del 2026-10-01» erano i 30 giorni di sorvegliante del punto 5 (§7 della SPEC); A2 chiede ≥180 giorni col criterio passato ogni giorno, e il criterio lo misura solo scale_watch, attivo dal 01/09. Le tre letture possibili, con pro e contro, sono nel diario di sessione; l'operatore ha scelto dal 01/09 → 2027-02-28. Contare dall'arming avrebbe dato un criterio ricostruito a posteriori, che non prova nulla sul sorvegliante; ridurre A2 a 30 giorni avrebbe allentato un gate senza un costo d'attesa che lo giustifichi (il gradino 1,25x vale meno di €100/mese di versamento).

Riconciliata anche la data d'arming: 20/06 = TP01 da solo (commit 4650aa7), 23/06 = il BOOK (commit db738bc, prima lettura di equity 23/06 22:00Z). CLAUDE.md §0 diceva solo la prima, config/live.json e il TWR usano la seconda: erano due eventi, non un errore.

Punto 5 — PREVDAY-01 aveva la data; non l'aveva la tabella

RESULTS-0822 §54: decisione 2027-06-21, kill, veto. La tabella §4 diceva «scritto 23/08 · 10 condizioni», e il revisore ha letto quella. Ora la riga ha data, kill, veto e stato (5/7: (a) e (b) sono strutturali, nessun forward le cambia).

Cablato in paper_prevday.py (prima esisteva solo nel testo, a differenza di paper_dvolspread):

misura	valore al 10/09
Sharpe forward giornaliero (lente del kill; l'oraria +1,19 non si cita, §54)	+0,95 su 81 giorni, 81 attivi
kill (< −0,50 su ≥180 g attivi)	NON MATURO, leggibile dal ~18/12/2026
barre ricostruibili dal feed di oggi	1.942/1.943 (99,9%); l'unica divergente e' il 26/08 00:00, il giorno del fix di advance()
veto	ok

⚠️ Errore mio, catturato prima di committare: la prima stesura del veto leggeva «divergenze non crescenti» come tasso_recente > tasso_totale, e con UNA barra divergente negli ultimi 30 giorni (0,03/g contro 0,01/g) dichiarava VETO. Una guardia piu' stretta del contratto produce allarmi che si impara a ignorare (P14): ora la crescita richiede ≥5 barre recenti E tasso doppio, dichiarato nel codice e provato nel test con i numeri della serie vera.

La ricostruzione al 99,9% contro il 95,6% di §54: la misura del 23/08 era stata fatta prima del fix di advance() del 26/08 (le 67 barre divergenti erano «all'ora del cron», cioe' barre parziali); oggi il feed rivisto e la serie coincidono tranne quella barra.

Cose trovate per strada

• Due timestamp «di comodo» scritti a mano (13:05Z e 13:07Z) invece dell'ora letta (12:57:43Z e 13:04:09Z): corretti subito. E' esattamente la regola globale «la data si LEGGE» — vale anche per chi la scrive nel campo correzione.
• issue --json va prima del sottocomando; il percorso nella regola globale era /opt/docker/AI-OS invece di /opt/AI-OS (corretto la mattina, nel test dello strumento).

Verifica

uv run pytest: 1060 passati (erano 1031). Nuovi: test_cuscino_watch.py (14), test_paper_prevday_gate.py (8), +5 in test_usde_watch.py. Revisione del diff affidata a fable (agente fresco): esito e correzioni applicate in coda a questo diario.

Revisione fable (13:10-13:18Z): 15 segnalazioni, 4 medie — tutte verificate, 12 applicate

#	segnalazione	verifica	esito
1	puo_riconvertire contava anche i NON tentativi (tentata=False): un giro --secco o un prezzo illeggibile bloccava la riconversione vera per 6h	riprodotta	filtro su tentata + test
2	il tetto del venue in usde_convert.piano bloccava anche la vendita: con venue_cap_frac rimesso in config la riconversione automatica sarebbe stata morta	riprodotta (side=sell, ok=False)	vale solo in acquisto
3	MARGINE_RIPRISTINO 10% == PREAVVISO_FRAC 10%: dopo ogni 🚨 un ⚠️ per costruzione (P14)	riprodotta col floor di 1 USDE	margine 20% → quota 0,64, test
4	--secco scriveva nel registro vivo (veicolo del punto 1, e maschera un cron fermo)	riprodotta (riga 13:00:15Z)	non scrive; riga tolta
5	due bersagli di quota: quota_target 0,70 in config contro 0,64 del ripristino; il ripristino e' un ratchet verso il basso	letto	dichiarato in CLAUDE.md §5.17 e nel docstring: decisione dell'operatore (N9)
7	buco di ≤5 min dentro la tolleranza della finestra 24h	letto	dichiarato (D5) + fonte Deribit documentata
8	giorni_attivi legge posizioni REAL, il kill e' MODELED	letto	dichiarato nel docstring (81/81 oggi)
10	il test del cron leggeva un commento nello .sh, non la crontab	letto	legge crontab -l come test_book_cadenza
11	prevday_target patchato senza monkeypatch	letto	monkeypatch
13	«QUATTRO movimenti» in §2: sono TRE, in quattro tratti	letto	corretto
14	«5/7» contro «8/10» di §54: base diversa non dichiarata	letto	dichiarata
6, 9, 12, 15	verifiche che reggono (sys.executable, cwd, piano() in SCOPERTO, ricostruzione ≡ advance)	—	—

Non applicato: il lock fra cron e conversione a mano (DUBBIO 2) — dichiarato come limite nel docstring. Il DUBBIO 1 (ratchet) e' la domanda aperta per l'operatore.