Files

T

Adriano Dal Pastro 103dd7bce5 research(wave-0822): BOCPD — il falsificatore eseguito con potenza, 0/68 celle adattive; l'adattivita' spiega il -7% del vantaggio

2026-08-22 20:50:03 +00:00

47 KiB

Raw Permalink Blame History

CRITICO DI COMPLETEZZA — ondata 2026-08-22 (`r0822b_critic`)

Mandato: non testare una strategia. Rispondere a cosa non e' stato guardato, quale affermazione e' rimasta non verificata, e qual e' la misura di maggior valore che nessuno ha fatto.

Materiale letto per intero: docs/research/BRIEF-0822.md, docs/research/RESULTS-0822.md (684 righe, 19 sezioni), docs/diary/2026-08-22-wave-multiagente.md, piu' i punti dei singoli scripts/research/r0822_*.py dove il ledger andava verificato.

Regola di lettura di questo file. Distinguo tre stati e li marco: [VERIFICATO] = ho aperto la fonte e il fatto e' controllato in questa sessione (comando riportato o citazione esatta) · [DEDOTTO] = ragionamento su numeri altrui, non ri-misurato · [DA MISURARE] = ipotesi mia, con costo stimato. Non fabbrico numeri nuovi salvo controlli rapidi, e quando ne faccio uno dico che e' un controllo di cinque minuti e non uno studio.

Esito in una riga: l'ondata e' onesta nei singoli filoni e debole nella CUCITURA. I difetti gravi non stanno dentro i filoni (che hanno catturato 7 errori propri) ma in tre punti dove nessuno era responsabile: (a) due "difetti di dato" sono convenzioni dichiarate nel sorgente di un fornitore che gira su questa stessa VPS e che nessuno ha aperto; (b) il gate principale del progetto — il deflated-Sharpe — e' stato misurato lo stesso giorno ai suoi due estremi degeneri da due agenti diversi, e nessuno ha unito le due misure; (c) un filone su venti (ALT-OPTIONS) non e' nel ledger, e il suo risultato falsifica una quarta soglia pubblicata — quella che tiene VRP01 fuori dal libro per taglia.

1. CLAIM NON VERIFICATI

Ordinati per (impatto x P(falso)) / costo. Non elenco tutto: le otto che contano.

1.1 — 🥇 «una firm crypto lista i 19 alt Hyperliquid con short abilitato» (PROP-ALLOC)

P(falso) media-alta · impatto massimo · costo un pomeriggio, zero CPU

E' l'unica assunzione su cui poggia l'intero risultato di testa dell'ondata: +0,400 di J (argmaxJ 25/25/50 contro il libro live 75/25) e' quasi tutto mettere XS01 su un conto funded, e +0,016 — il 4% — e' il riallocare per la barriera. Se XS01 non e' eseguibile presso la firm, la riga argmaxJ collassa verso 75/25/0, che nello stesso script misura J 0,335 / P(pass) 38,6% invece di 0,738 / 82,2%. Con essa cade anche il risultato strategico del 25/07 §4 («sul canale funded diversificare paga perche' il vincolo binding e' il DD»), che e' il perno di tutta la valutazione del canale prop.

⚠️ E il progetto ha gia' una regola scritta per questo caso, e non l'ha applicata. Il 26/07: «la negoziabilita' sul conto REALE va verificata quando lo sleeve entra in RICERCA, non quando entra nel book» — regola nata dal blocco PRIIPs su GTAA01, dove cinque settimane di misure poggiavano su un'assunzione di conto mai controllata, e il controllo costo' un ordine di prova. r0822_prop_alloc.py la ripete: alla riga 100 CRYPTO_PROP = ("TP01","SKH01","XS01") # cio' che una firm CRYPTO puo' davvero far eseguire — un commento, non una misura. [VERIFICATO: letto il sorgente; l'agente esclude esplicitamente VRP01/GTAA01 "una firm CRYPTO non lista opzioni Deribit ne' ETF azionari USA", quindi ha pensato al problema e si e' fermato un passo prima di XS01.]

Cosa verificare, in ordine: (a) la lista strumenti di HYROTRADER e FTMO-crypto contiene i 19 major HL (SOL/BNB/XRP/DOGE/AVAX/LINK/LTC/ADA/ARB/OP/SUI/APT/INJ/TIA/SEI/NEAR/AAVE oltre BTC/ETH)? (b) short abilitato su ciascuno? (c) quale costo effettivo per gamba (spread + commissione)? La (c) ha una soglia gia' misurata in questa stessa ondata: XS-LITE riporta che la famiglia XS regge oltre 50 bps/gamba — quindi il costo di una firm quasi certamente non morde, ed e' la (a)/(b) binaria che decide tutto. Se (a) e' falsa, il verdetto LEAD del filone 1 va riscritto oggi, non a un gate futuro.

1.2 — 🥈 «`dealer_net_gamma` e' il GEX col SEGNO INVERTITO» (DEALER-GAMMA)

P(falso) alta — anzi: FALSO come formulato · impatto medio · costo due minuti

Il ledger lo chiama «il risultato piu' riusabile del filone» e scrive: «Chi lo usasse col nome che porta leggerebbe ogni regime al contrario». L'agente ha deciso la questione per ricostruzione (corr −0,95 BTC / −0,89 ETH contro un GEX da manuale) e lo dichiara esplicitamente nel proprio codice: "Quale, lo decide la sezione 2 (ricostruzione dalla catena), non io" (r0822_dealer_gamma.py:187).

🚨 La fonte autorevole e' su questa VPS e dice il contrario. [VERIFICATO] La colonna non e' calcolata da cerbero-bite: bite inoltra e basta il campo total_net_dealer_gamma che riceve dal tool MCP get_dealer_gamma_profile (src/cerbero_bite/runtime/market_snapshot_cycle.py:85 e clients/deribit.py:342-384, letti dal repo Gitea Adriano/Cerbero-Bite). E il produttore e' /opt/docker/cerbero-mcp/src/cerbero_mcp/common/options.py, acceso adesso, che in testa al file dichiara la convenzione:

# Convention dealer gamma: i dealer sono SHORT calls (le vendono al retail) e
# LONG puts. ... Net dealer gamma negativo -> mercato instabile (squeeze ...)
...
entry["call_dealer_gamma"] -= contrib   # dealer short calls
entry["put_dealer_gamma"]  += contrib   # dealer long puts

Cioe': call negative, put positive — l'esatta negazione, su entrambe le gambe, della convenzione da manuale che l'agente ha usato (call +, put −, r0822_dealer_gamma.py:237). Non e' un difetto della colonna: e' una convenzione opposta, deliberata e documentata — e nel suo frame dng < 0 significa dealer short gamma / mercato instabile, che e' proprio la semantica che il docstring di bite dichiara e che l'entry filter §2.8 usava.

E c'e' una seconda spiegazione, gratis, per i due numeri residui che l'agente ha attribuito a non-portabilita': la chiamata di bite usa il default top_n_strikes = 50 [VERIFICATO: dealer_gamma_profile(asset_upper) senza argomenti], contro i ~280-316 strike della ricostruzione. Un troncamento ai 50 strike di punta spiega naturalmente sia il coefficiente −0,7 (invece di −1,0) sia l'offset «dng=0 corrisponde a GEX=+5,8e6 su BTC», che il ledger presenta come prova che la soglia non e' portabile.

Cosa cambia se e' falso (ed e' falso): il verdetto SCARTATO regge intatto (DSR 0,440, null de-levering fallito, n_eff 24-53 ore su 2.130, cella migliore sotto il massimo del rumore). Ma cade la regola pubblicata, e cade nel modo peggiore: la frase del ledger «BTC non separa, ETH separa al ROVESCIO» e' formulata in un frame di segno che va rovesciato — quindi l'unica riga del filone che le ondate future erediterebbero e' quella sbagliata. Correzione da fare oggi nel ledger, costo due righe.

1.3 — 🥉 «`liquidation_long/short_risk` e' costante 'low': meta' dell'ipotesi non esiste, ed e'

comunque morta perche' la colonna non e' ricostruibile» (FLOW-SQUEEZE) P(falso) alta sulla seconda meta' · impatto medio · costo due ore

[VERIFICATO] Il fatto e' vero (low in 17.229/17.229 righe non nulle, riprodotto). Ma le due inferenze che l'agente costruisce sopra il fatto sono entrambe smentibili leggendo la stessa sorgente di §1.2, /opt/docker/cerbero-mcp/.../sentiment/fetchers.py:480-518:

long_risk = "high"   se avg_funding > 0.0001 e delta_24h > 5
           "medium"  se avg_funding > 0.00005 e delta_24h > 2

Cioe' e' una soglia su due input, non una misura. Conseguenze:

«Nessuna fonte nostra la produce, e non c'e' niente da produrre» (r0822_flow_squeeze.py:626) e' falso: i due input sono oi_delta_pct_24h e il funding cross, e il funding cross e' nel file (funding_cross_annualized, copertura 99%), cosi' come oi_delta_pct_4h (copertura 99%, dev.std 1,23%, range −7,1%…+13,4% — [VERIFICATO] con una lettura del parquet). L'agente poteva ricostruire la variabile di affollamento con le proprie soglie, che e' anche metodologicamente meglio che ereditarne una arbitraria.
«Costante = zero informazione» e' vero come statistica e sbagliato come lettura: low al 100% con quelle soglie significa che nella finestra 2026-03 → 07 non c'e' stato un solo episodio di affollamento per quella definizione. Non e' una colonna rotta, e' un fatto di mercato — e per giunta rafforza la conclusione del filone (funding chiuso sul quarto lato) molto piu' di quanto faccia «la colonna e' inservibile».

Cosa cambia se e' falso: il verdetto SCARTATO regge (l'altra meta' e' sotto la propria MDE dichiarata: effetto 0,402% contro MDE 1,056%). Ma il filone e' chiuso con la motivazione sbagliata, e la motivazione sbagliata e' quella che impedisce di riaprirlo con i dati che ci sono.

1.4 — «la finestra forward non va persa: riparare `advance()` + RIGENERARE, nessuna data di

gate si sposta» (MONITOR-AUDIT) P(falso) bassa sul fatto, alta sull'implicazione · impatto alto (3 gate) · costo zero

Il fatto e' provato bene, due volte in modo indipendente (paper_prevday 1427/1488 barre identiche al bit dopo 62 notti; le 6 barre di paper_statarb recuperate dopo il guasto EPERM coincidono al bit). Non contesto il fatto. Contesto che sia gratis.

Una serie rigenerata non e' una serie forward. La ragione per cui un progetto pre-registra una finestra forward e' che sia prodotta da codice che non poteva essere tarato su di essa. Dopo la riparazione, la serie su cui si decide il 27/09 sara' prodotta da codice scritto oggi, dopo aver visto quella finestra — e chi scrive la riparazione ha gia' letto, nel ledger, che la metrica registrata dice +1,96 e quella ricostruita −2,02. La riparazione e' banale e meccanicamente forzata (scartare la barra non chiusa), quindi il rischio e' piccolo; ma e' un grado di liberta' nuovo su un gate pre-registrato, e nessuno lo ha nominato.

Costo di chiuderlo: zero. Si scrive la riparazione, la si congela con un test, e solo dopo si rigenera — dichiarando in anticipo che nessun parametro verra' toccato in base al risultato della rigenerazione. Farlo dopo aver visto lo Sharpe rigenerato non e' piu' possibile.

1.5 — «haircut a $5.000 <= 40%» come gamba del gate XSR01 del 23/10

P(che il gate sia non-informativo) alta · impatto alto · costo zero (e' gia' misurato)

Due filoni hanno colpito le due gambe del gate del 23/10 senza che nessuno tirasse la somma:

gamba haircut — HL-EXEC: a $5.000 col pavimento vero l'haircut sta fra −7% e +2%, quindi «una condizione pre-registrata che non puo' fallire non e' una condizione». XSR-REPRO dall'altro lato: il $14,41 pubblicato non ha alcuno script committato che lo riproduca ed e' ~2,4x ottimista (ticket mediano $3,33, 63% degli ordini sotto $5).
gamba Sharpe >= 1,0 — MONITOR-AUDIT: la serie che la misura registra 41 minuti di mercato al giorno, corr col replay −0,045.

📌 La somma, che il ledger non fa: al 22/08 il gate del 23/10 e' non-informativo su ENTRAMBE le gambe — una non puo' fallire, l'altra e' letta su uno strumento scollegato dalla realta'. Il ledger scrive «GATE 23/10 COMPROMESSO: PARZIALMENTE». E' compromesso interamente, e la differenza non e' semantica: «parzialmente» autorizza a decidere il 23/10 con una riserva, «interamente» obbliga a ri-registrare il gate prima, che e' l'unica mossa che non e' selezione.

1.6 — «k* empirico ~10-14x» (GROWTH-POLICY)

P(falso) alta come numero · impatto medio-alto · costo zero (giunzione di due misure gia' fatte)

L'agente ha gia' fatto due autocritiche corrette (capitale mediano $4,4e12 a k=14x → «a k>2 i numeri sono aritmetica, non previsioni»; k* lineare nell'errore del drift). Ne manca una terza, e sta dentro la stessa ondata: SLIP-AUDIT misura che la partecipazione al nastro scala lineare col nozionale e che il caso peggiore osservato e' gia' 21,9% di una barra 5m a nozionale ~$636. La leva moltiplica il nozionale esattamente come il capitale. Quindi [DEDOTTO, aritmetica diretta sulla tabella di SLIP-AUDIT]:

leva su $635	nozionale	peggior partecipazione osservata, riscalata
1,00x	$636	22% di una barra 5m
1,50x (il gradino proposto)	$954	33%
5x	$3.180	110%
10-14x (k*)	$6.400-8.900	220-310%

📌 Il gradino 1,00 → 1,50x NON e' toccato da questo (33% resta dentro il regime misurato): la raccomandazione operativa sopravvive. E' il numero k* che non e' misurabile, per una terza ragione indipendente dalle due dichiarate: sopra ~k=5 la serie di ritorni su cui k* e' calcolato smette di essere indipendente dalla size, che e' esattamente l'ipotesi che l'agente aveva segnalato come implausibile senza poterla quantificare. Ora e' quantificata, gratis, e va scritta accanto al 10-14x.

1.7 — «BTC opzioni min 0.1 = $6.210/lotto → VRP01 fuori a $3.000, servirebbe il 61% del conto»

P(falso) verificata FALSA · impatto alto · costo gia' pagato — il numero esiste e non e' nel ledger

Questo e' congelato in tests/test_vrp_profit_take.py e in CLAUDE.md. VRP-QUOTE-VERE l'ha falsificato a meta' (famiglia sbagliata) e ALT-OPTIONS l'ha falsificato del tutto — ma ALT-OPTIONS non ha una sezione nel ledger (vedi §5.1), quindi il numero non e' mai stato scritto. [VERIFICATO: letto l'output del filone]:

famiglia	f_venue	credito eseg.	max-loss / lotto	IM se il venue NON netta
ETH_USDC	0,980	$3,38	$16,62	$33,50
BTC_USDC	0,921	$6,25	$33,75	$101,79
ETH inverse (la famiglia del muro)	0,930	$29,36	$145,88	$324,42
BTC inverse (la famiglia del muro)	0,927	$81,97	$418,03	$1.017,06

Il muro pubblicato e' calcolato sul nozionale del lotto minimo della famiglia inverse. La grandezza giusta per una struttura a rischio definito e' il max-loss, e sulla famiglia che il conto puo' marginare vale $16,62. Al peso di libro del 12%, VRP01 entra con un lotto da un conto di ~$140 (o ~$280 se Deribit non netta le gambe), non da $3.000 al 61% del conto — due ordini di grandezza. Sul conto vero ($635) ci stanno 7 strutture dentro un budget di rischio del 20%, con 3.000 lotti al miglior bid e spread della gamba corta al 2,6%.

⚠️ Cosa NON cambia, e va detto forte: VRP01 resta fuori dal libro, ma per la regola «niente short-vol da modello in deploy» e per il gate IV-rank (0/19 settimane aperte), non per la taglia. Cade una delle tre ragioni, ed e' quella che il progetto ripete piu' spesso.

1.8 — «lo screen largo non puo' passare il proprio gate: e' aritmetica» (ORTHO-SCREEN)

P(falso) alta come generalizzazione · impatto alto (tocca 3 gate futuri) · costo 5 minuti

Vedi §2.1: l'ho ri-derivato e il numero e' giusto ma non dice cio' che il ledger gli fa dire.

2. CONTRADDIZIONI FRA AGENTI

2.1 — 🚨 IL DEFLATED-SHARPE MISURATO AI SUOI DUE ESTREMI DEGENERI, LO STESSO GIORNO, DA DUE AGENTI CHE NON SI CITANO

ORTHO-SCREEN: «su 168 trial il massimo atteso dal puro rumore e' Sharpe 1,572, sopra il soffitto direzionale (~1,3) → una ricerca a rete larga NON PUO' passare il proprio gate. Non e' sfortuna, e' aritmetica.» DSR di screen 0,034.
SCETTICO su VOL-SIZE: «DSR = 1,000 dichiarato VACUO, non PASS: lo passa anche il baseline — su una famiglia di perturbazioni della stessa strategia il deflated-Sharpe non ha potenza.»

Sono la stessa osservazione dai due lati, e insieme delimitano il gate principale del progetto. [VERIFICATO] Ho aperto altlib.deflated_sharpe: il massimo atteso non e' SE(Sharpe) x sqrt(2 ln N) ma la formula Bailey–Lopez de Prado

sr0 = sd(Sharpe dei trial OSSERVATI) x [ (1-gamma)*z(1-1/N) + gamma*z(1-1/(N e)) ]

cioe' la dispersione trasversale delle celle che hai deciso di dichiarare, moltiplicata per un fattore che dipende solo da N. Ricalcolando il moltiplicatore [controllo di cinque minuti]:

N dichiarato	moltiplicatore	`sr0` con la STESSA dispersione (sd = 0,58)
12	1,665	0,97
24	1,980	1,15
48	2,261	1,31
72	2,413	1,40
168 (lo screen)	2,708	1,57
729	3,164	1,84

E al variare della dispersione, a parita' di dati:

dispersione delle celle	`sr0(24)`	`sr0(168)`
0,15 (famiglia di perturbazioni, tipo VOL-SIZE)	0,30	0,41
0,58 (lo screen ortogonale)	1,15	1,57

📌 Tre letture che il ledger non ha:

La soglia «1,572» non e' una proprieta' di BTC/ETH: e' una proprieta' della GRIGLIA. Le stesse 168 celle, dichiarate come 7 famiglie da 24, danno sr0 = 1,15 — sotto il soffitto direzionale. Il verdetto «impossibile per aritmetica» si ribalta senza toccare un dato.
Percio' la lezione pubblicata invita alla mossa che il progetto ha gia' proibito. Il ledger conclude «le ondate future o dichiarano famiglie molto piu' piccole in anticipo, o cambiano meccanismo». La prima meta' e' esattamente il barare che il 30/07 aveva codificato: «il deflated-Sharpe e' l'unico posto dove barare e' indolore e invisibile», e «il verdetto si ribalta col conteggio» (congelato in un test su VRP01: DSR 0,983 a N=8 / 0,948 a N=72 / 0,909 a N=360). Il 22/08 la stessa leva viene raccomandata come buona pratica.
Cio' che il progetto non sapeva e' la META' PIU' GRANDE: la dispersione. Il fattore N va da 1,67 a 3,16 su due ordini di grandezza di trial (1,9x). La dispersione va da 0,15 a 0,58 fra una famiglia omogenea e uno screen (3,9x). Il gate e' dominato dalla variabile mai dichiarata.

Conseguenza operativa immediata, perche' tocca tre gate pre-registrati: DVOLSPREAD 24/10 ha come criterio (c) «deflated-Sharpe ricalcolato >= 0,95» — su una famiglia di 729 celle omogenee; XSR01 23/10 poggia su DSR 0,983; VOL-SIZE ha gia' dichiarato il proprio DSR vacuo. Nessuno dei tre e' interpretabile senza dichiarare, accanto a N, la dispersione delle celle. Riformulazione onesta della lezione di ORTHO-SCREEN: con celle disperse di ~0,58 di Sharpe e un soffitto di ~1,3, il gate non separa; la cura non e' dichiarare meno trial, e' progettare famiglie i cui membri siano varianti di UN meccanismo — e li' il DSR e' vacuo, quindi serve un altro gate. Il deflated-Sharpe non ha una regione utile in mezzo, e nessuno l'ha detto.

2.2 — Lo Sharpe di XSR01: non tre lenti ma quattro, e la quarta non e' nel quadro conciliato

Il ledger conclude con un «quadro conciliato»: titolo demean_skeptic 1,82 · gate basket_gate 1,75-1,79 · monitor paper_xsr 2,21, e prescrive «NUMERO ONESTO DA CITARE: 1,79 (finestra di scoperta) / 1,63 (a oggi)».

[VERIFICATO nell'output di XS-LITE] Lo stesso giorno XS-LITE, che dichiara replica bit-exact contro basket_from_positions(demean=True) (max|diff| = 0,000e+00 su 965 barre), pubblica: «XSR01 pieno, lente pubblicata: Sharpe 1,64 (pubblicati 1,82)», «normalizzazione COSTANTE 1/50: 1,65», «sulla FINESTRA DI SCOPERTA (<= 2026-07-25, 937 barre): 1,75».

Quindi due agenti che rivendicano entrambi la replica bit-exact della stessa funzione danno 1,75 e 1,79 sulla stessa finestra. La spiegazione piu' probabile e' la loro stessa scoperta (l'ultima barra della finestra di scoperta era parziale il 25/07 e oggi e' chiusa), e i due concordano sull'oggi (1,64 vs 1,63). Ma il ledger prescrive una coppia canonica senza nominare l'altra, e la regola che pubblica — «va sempre citata la coppia (lente, ultima barra chiusa)» — e' proprio quella che avrebbe risolto la discrepanza se applicata a se stessa. Costo di chiudere: una riga nel ledger. Impatto: e' il numero su cui si decide il 23/10.

2.3 — Il muro di XS01: tre numeri diversi nello stesso corpus di documenti

XS-LITE: capitale minimo perche' il ribilancio passi = $109 di sleeve (~$730 di libro).
HL-EXEC: haircut ~0 gia' a $200-600 allocati (→ a peso 15%, $1.300-4.000 di conto).
Diario §6.5: «XS01 e' eseguibile a ~$1.300 di conto» — cioe' l'estremo basso di HL-EXEC.

I tre sono compatibili (criteri diversi: soglia del ribilancio vs soglia dell'haircut), ma il diario ne pubblica uno come se fosse il numero, dopo che l'ondata ha appena passato una giornata a dimostrare che i numeri pubblicati a un criterio solo sono il difetto ricorrente del progetto. Da citare come banda $730-$1.300 col criterio accanto.

2.4 — La leva: due filoni della stessa ondata danno guida opposta

GROWTH-POLICY: k* ~10-14x, il libro gira al 7% di Kelly, alzare la leva vale 14,7a → 11,6a.
PROP-ALLOC: J massimo a 0,75x, e «P(pass) senza limite di tempo e' monotona DECRESCENTE» (98,9% a 0,50x → 65,9% a 1,50x).

Non e' un errore: sono obiettivi diversi (crescita in log senza barriera vs sopravvivenza sotto una barriera per-conto). Ma nessuno lo scrive, e l'operatore leggera' due raccomandazioni opposte nello stesso documento. La sintesi che manca, e che riconcilia: 📌 anche il conto proprio ha una barriera assorbente — e' la decisione di venue del 26/07 («zero e' assorbente: andare a zero all'anno 10 di un piano da 16 anni significa non arrivarci piu'»). Quindi il criterio di GROWTH-POLICY (Kelly puro) e' il caso limite senza barriera, e PROP-ALLOC misura cosa succede quando la barriera c'e': la leva ottima cade da 10x a 0,75x appena si mette una barriera, e la distanza fra i due numeri E' la misura di quanto la barriera costa. Detta cosi', le due misure smettono di contraddirsi e diventano la stessa curva.

2.5 — Il peso di SKH01: respinto da un filone, raccomandato al doppio dall'altro

VOL-SIZE / scettico: «quasi ogni variante alzava il peso effettivo di SKH fino a 0,375, e "alzare SKH01" e' gia' stato misurato e respinto il 26/07» — motivo per cui il null giusto e' iso-peso.
PROP-ALLOC: sul campione 2019+ che contiene il 2022, l'ottimo della coppia crypto sotto barriera e' 38/62 (J 0,521 contro 0,443), cioe' SKH01 al 62%.

Di nuovo obiettivi diversi, di nuovo non detto. Ma qui c'e' un aggravante che l'agente dichiara da solo: PROP-ALLOC non ha girato la banda d'ancora, quindi il suo ottimo poggia sull'ancora canonica di SKH01, lo sleeve che il LOO del 26/07 misura come quello con la fortuna d'ancora piu' grande da restituire (l'ancora regala 2/3 del FULL, 70% dell'hold-out, 80% della protezione DD). La distorsione e' a favore della raccomandazione, e la raccomandazione riguarda l'unico canale che l'operatore potrebbe aprire quest'anno. Costo di chiuderla: rigirare l'ottimo su una banda di 8 ancore — l'ordine di grandezza del budget di un agente di questa ondata.

2.6 — Il conteggio degli ingressi VRP nella stessa finestra di catena: 19 contro 22

VRP-QUOTE-VERE: «f = 0,714 pooled, 0/19 osservazioni >= 1,0»; SKEW: «0,714 su 22 ingressi». Stesso f a tre decimali, popolazione diversa. [VERIFICATO che SKEW usa «stessa macchina di cblib», quindi non e' una replica indipendente e l'accordo a tre decimali non e' evidenza.] Spiegazione benigna probabile (VRP richiede entrambe le gambe quotate ai due delta obiettivo, SKEW ricostruisce lo smile e ne richiede meno). Ma il ledger presenta il 0,714 come «replica indipendente» del f del 30/07 senza dire che il secondo 0,714 viene dallo stesso harness. Impatto basso, costo di chiarirlo nullo.

2.7 — «il collettore raccoglie la famiglia sbagliata» e' una classificazione, non un fatto

Il ledger apre VRP-QUOTE-VERE con 🚨 IL RISULTATO DI PRODUZIONE. [VERIFICATO in scripts/live/collect_chain.py:114: {"currency": asset, "kind": "option"} e OI_MIN = 100.0 alla riga 57 — i due fatti sono esatti.] Ma il collettore serve la ricerca sui prezzi, non l'esecuzione: sulle inverse ci sono 415/548 strumenti con OI>=100 e 97% di quote a due lati, contro il 94% e 119 strumenti di ETH_USDC. Per misurare f, IV-rank e struttura a termine, la famiglia raccolta e' la migliore delle due. Il difetto esiste solo rispetto a un uso — l'esecuzione — che oggi e' vietato da un'altra regola («niente short-vol da modello in deploy»). Il diario lo corregge a meta' (punto aperto 3 lo presenta come decisione sul rate limit); il ledger no. Un difetto di produzione e una scelta di raccolta non si segnano con lo stesso simbolo, o il prossimo che legge ripara qualcosa che non e' rotto — al costo di +90% sul giro e del rate-limit per-IP che il 29/07 e' gia' costato un guasto.

3. MODALITA' NON ESPLORATE

Filtro applicato: (a) compatibile con dati che il progetto possiede o puo' ottenere, (b) non nella lista dei filoni morti del brief, (c) meccanismo plausibile e nominabile. Niente idee generiche.

3.1 — 🥇 Il costo del CHOP, cioe' il rischio che il libro non ha mai vissuto

Dati: esistono (7,4 anni di libro; 2018-19 e 2022-23 come stiramenti laterali; 30 anni di equity come stampo). Meccanismo: il progetto ha misurato la difesa nel sinistro — il criterio B di edge_watch e' 8/8 anni di crash superati — e non ha mai misurato la modalita' di fallimento propria di un trend-follower, che non e' il crash ma il mercato laterale. E la misura di controllo che ho fatto in cinque minuti la rende urgente e non teorica:

giorno	BTC	ETH	libro 75/25 (close-only)
2020-03-12	−41,5%	−45,7%	+0,97%
2022-06-13	−15,5%	—	+0,72%
2021-05-19	−14,3%	−27,9%	−1,98%
2022-11-09	−14,4%	−18,0%	0,00%
2021-01-21	—	−19,5%	−2,24%

[controllo di cinque minuti, non uno studio: altlib.tp01_baseline_daily() + sleeves._skyhook_returns(), 75/25, ancora canonica. Peggior giorno del libro su 7,4 anni: −3,38% (2025-10-10), che non e' un giorno di crash.] Cioe': il libro non perde nei crolli — nei crolli guadagna. Tutte le sue peggiori giornate sono altrove. Nessuno ha mai chiesto dove. Un piano a 10-20 anni su una strategia il cui unico rischio misurato e' quello che non la tocca ha un buco esattamente della forma che questo progetto e' bravo a trovare in tutto il resto.

3.2 — 🥈 Il prezzo di essere ciechi: il costo atteso in P&L dell'attrito OPERATIVO

Dati: ci sono gia' e sono nostri — logs/cron_book.log, data/venue_watch, feed_age_minutes, skh_feed_errors, book_executions.jsonl. Meccanismo: nel 2026 il libro e' stato cieco o stantio almeno tre volte documentate (feed-freeze 14/07; fallback silenzioso di fresh_5m il 29/07, latenza d'uscita di SKH01 da ~1h a ~11h per 6 giri su 8; manutenzione Deribit del 18/08 sforata fino alle 14:07, con astensione del libro). Il progetto ha prezzato fee, slippage, min-order, pavimento IB, fortuna d'ancora, degrado d'esecuzione, e persino il fallimento dell'exchange — e non ha mai prezzato quanto costa all'anno che il libro non veda. E' una misura, non una previsione: si prendono le finestre di cecita' realmente occorse, si guarda cosa ha fatto il prezzo dentro, e si confronta il P&L realizzato col P&L del percorso non-cieco. Perche' conta adesso: e' un costo che scala col nozionale esattamente come la leva, quindi entra direttamente nel conto di §4; e le uscite di SKH01 sono la gamba latency-sensitive. Perche' non e' morto: non e' calendario, non e' un overlay, non e' una strategia — e' il prezzo di un rischio operativo gia' materializzato tre volte.

3.3 — 🥉 Lo spread di volatilita' BTC-vs-ETH come sleeve, non come timer

Dati: dvol_btc / dvol_eth dal 2021-03 = 1978 giorni, 5,4 anni — l'unico dataset non direzionale del progetto abbastanza lungo da avere un hold-out vero (a differenza di tutta la catena, ferma a 74-90 giorni). Meccanismo: i due asset condividono un fattore di vol comune, e la ricchezza relativa delle due vol e' una grandezza stazionaria per costruzione, mentre il livello non lo e'. Non e' DVOLSPREAD: quello e' il lead in forward-monitor che usa lo spread come timer direzionale (de-risk); qui lo spread si traderebbe come tale (straddle lungo su uno, corto sull'altro), market-neutral rispetto alla direzione e — a differenza di VRP01 — con esposizione al premio di vol quasi cancellata fra le due gambe. Non e' nella lista dei morti (gamma scalping = long-vol nudo; VRP01 = short-vol nudo gated; questo e' relative-value). ⚠️ Due muri dichiarati in anticipo: (i) sarebbe prezzato su DVOL, cioe' BS-flat, e la SKEW di questa ondata ha appena misurato che il flat costa x0,869 di struttura a termine e x0,920 di skew — quindi il verdetto massimo e' LEAD finche' non e' riprezzato sulla catena vera; (ii) richiede opzioni su entrambi gli asset: fuori a $635 (BTC_USDC ~$780/lotto), dentro a ~$3-5k.

3.4 — Il basis dei futures datati come campione della coda, non come carry

BASIS-CALENDAR ha costruito un dataset che il progetto non aveva — BTC 34 contratti / 240.150 barre orarie dal 2018-09, ETH 34 / 233.334, piu' 64.110 ore di funding e indice — e lo ha usato per una sola domanda (il premio incassabile, IC95 che contiene lo zero → SCARTATO). Il dataset contiene la coda che manca a tutto il resto del progetto, e il ledger lo dice esplicitamente («include il deleveraging 2022 — esattamente la coda che a CC01 mancava per costruzione»). Uso non esplorato: il blow-out del basis e' l'unico marcatore osservabile e datato dei giorni di deleveraging forzato. Condizionare a quei giorni le domande di §3.1 e §4 da' un campione di stress reale al posto di uno scenario assunto a mano. ⚠️ E c'e' un'azione a costo quasi nullo che nessuno ha messo negli aperti: quel dataset vive in .../scratchpad/basis_cache/ (20 MB, [VERIFICATO]), cioe' in una cartella di sessione che sparisce. E' ricostruibile (30/30 trimestrali rispondono e il metodo — costruire a mano i nomi dei contratti scaduti e chiamare get_tradingview_chart_data — e' documentato nello script), ma ricostruirlo costa rete e tempo che ora sono gia' stati spesi. Persisterlo in data/raw/fut_* e' l'unica cosa dell'intera ondata che si perde per non averla scritta.

3.5 — La copertura di coda come abilitante della leva, non come miglioramento dello Sharpe

Stato dell'arte nel progetto, dichiarato: tail hedge e' gia' stato provato — OPT06 (ratio put spread con tail hedge) e OPT07 (collar) nello sweep del 20/06, entrambi modellati su DVOL BS-flat e giudicati sullo Sharpe, entrambi bocciati. Cosa non e' stato fatto: giudicarlo sull'obiettivo crescita a leva. Sono domande diverse perche' il valore di un pavimento e' convesso nella leva: a k=1 una put lontana e' un costo secco, a k=k* e' cio' che rende k* stimabile. La domanda esatta: esiste una put a delta basso il cui costo annuo, misurato sulle quote VERE (non su DVOL), sia minore del guadagno di crescita che il pavimento autorizza? ⚠️ Prior onesto: sfavorevole. Il 30/07 ha misurato che l'ala comprata costa ~2,3x il modello (f_long 2,23, fino a 5,85 sui delta piu' bassi) — quindi la protezione reale e' piu' cara di quella che aveva gia' bocciato OPT06/OPT07. Ma il confronto non e' mai stato fatto contro la leva, ed e' l'unico confronto in cui una protezione cara puo' comunque pagare. ⚠️ Eseguibile solo da ~$3-5k (ETH_USDC ~$250/lotto di nozionale): e' una domanda per il deposito, non per oggi.

3.6 — Il flusso di opzioni (volume per strike), che e' nel dato e nessuno ha guardato

La catena registra volume_24h per strumento, oraria. Sei filoni hanno usato l'OI (posizioni accumulate) e zero hanno usato il volume (transazioni). ALT-OPTIONS ha appena dimostrato che sulle famiglie lineari OI e negoziabilita' sono anti-correlati (rho di rango −0,77) — che e' un'ottima ragione per sospettare che le due grandezze dicano cose diverse anche sulle inverse. Meccanismo: un'ondata di acquisti concentrata su uno strike e' un fatto di flusso; l'OI e' il suo integrale, e integrare distrugge il segnale di timing. ⚠️ Muro invalicabile e dichiarato: 74-90 giorni di calendario. Il verdetto massimo qui e' LEAD con gate pre-registrato, e l'onesta' vuole che si dica prima di iniziare, non dopo. La ragione per farlo comunque e' che il calendario cresce da solo, gratis, ogni ora.

4. LA MISURA DI MAGGIOR VALORE MAI FATTA

La misura

Il peggior giorno che il libro puo' avere, misurato invece che assunto: la distribuzione della perdita giornaliera CONDIZIONATA all'esposizione piena, sotto la lente wick accoppiata, con lo scenario di gap attraverso il disaster-SL.

Perche' questa

Perche' e' l'unico parametro che blocca la sola leva gratuita che l'ondata abbia trovato, e perche' oggi quel parametro e' un numero scelto a mano.

GROWTH-POLICY ha stabilito che il gradino eseguibile 1,00x → 1,25-1,50x vale 14,7 anni → 12,9-11,6 anni al capitale-rendita (a €500/mese, netto fisco). Lo scettico ha tolto una delle tre riserve (il wick non amplifica il maxDD: ricarico costante ~3,5%). Delle due rimaste, una non e' risolvibile (il drift stimato su 7,4 anni — e comunque k* resta 7x a −2 SE, quindi 1,5x sta al 21% di k*) e una lo e': la coda. E' la riserva che decide, perche' e' l'unica che porta k* sotto il gradino proposto: «un solo giorno −10% all'anno porta k* da ~10x a 2x, −15%/anno a 1x».

📌 Quel −10% non e' stato misurato: e' stato scelto. E il controllo di cinque minuti in §3.1 dice che potrebbe essere una coda da buy&hold importata dentro un libro difensivo: sui cinque peggiori giorni di BTC e i cinque di ETH in 7,4 anni — compreso il −41,5% / −45,7% del 12 marzo 2020 — il libro ha fatto +0,97 · +0,72 · 0,00 · −1,98 · −2,24 · +0,23%, e il suo peggior giorno assoluto e' −3,38% in una data che non e' un crash. Se il vero peggior giorno plausibile e' −5% e non −10%, k* non e' 2x e il gradino e' autorizzato.

⚠️ Ma il mio controllo e' close-only, cioe' proprio la lente che questa ondata ha appena dichiarato "esattamente cieca" sulle regole a UN giorno (rapporto acc./close = INF a soglia 5%). Quindi la misura vera non e' quella che ho fatto: e' la stessa domanda sotto r0725_prop_coupled (tuple accoppiate, minimo intra-giorno) piu' lo scenario che il dataset non contiene — un gap notturno che attraversa il disaster-SL −30% con posizione piena su entrambe le gambe. Tutta la macchineria esiste gia' (r0725_prop_coupled, r0822_leverage_skeptic), il campione di stress si puo' prendere dal dataset dei futures datati di §3.4, e il costo e' un agente di questa ondata.

Confronto esplicito con le leve gia' quantificate

leva	valore	costo	stato
versare €250/mese invece di €0	da mai a 19,8a (P 52% netto fisco)	€250/mese	decisa dall'operatore
versare €500 invece di €250	19,8a → 14,7a	€250/mese in piu'	decisa dall'operatore
leva 1,00x → 1,50x	14,7a → 11,6a	zero	bloccata da UN parametro assunto
riallocare per la barriera (prop)	+0,016 di J = il 4%	analisi	misurata, marginale
XS01 su conto funded	+0,400 di J	assunzione non verificata (§1.1)	LEAD
ottimizzare il peso di SKH01	+0,030 di Sharpe	analisi	gate fallito, plateau
rischio venue a p=5%	capitale mediano → zero	split di conto	decisa: 100% Deribit fino a $20k

📌 Il gradino di leva vale ~3,1 anni, cioe' l'equivalente di ~€300/mese di versamenti, a costo zero. E' la prima volta in due mesi che una misura di ricerca entra nell'ordine di grandezza della leva dei versamenti, e ci entra perche' non e' ricerca di alpha: e' un cambio di scala di cio' che gia' funziona. Vale 100x l'ottimizzazione del peso di SKH01 e 25x il riallocare per la barriera.

E adesso la parte che il mandato chiede di dire se e' vera

Sì: nessuna misura di ricerca di questa ondata batte "versare". Venti filoni, ~15.300 righe, zero candidati promossi; il soffitto direzionale e' stato riconfermato per via aritmetica; e per tre volte l'eseguibilita' a $600 non e' stata il vincolo binding — tutto e' morto sull'edge. La misura che propongo non e' un'eccezione a questo, ne e' la conferma: non cerca un rendimento nuovo, prezza un parametro di rischio per poter usare meglio quello che c'e'. E anche cosi', 3,1 anni sono meno di cio' che valgono €250/mese di differenza nei versamenti.

La seconda misura, e va detta insieme alla prima perche' costa ancora meno: la verifica di §1.1 (i 19 alt HL sono listati e shortabili presso la firm?). Non e' ricerca, e' un pomeriggio di lettura sul sito di due firm — e decide se il canale prop, l'unico che moltiplica il nozionale senza possedere capitale, vale J 0,738 o J 0,335. Il progetto ha gia' pagato una volta il prezzo di non fare questa verifica (GTAA01/PRIIPs, cinque settimane di misure su un ETF che il broker rifiuta di vendere) e ha scritto la regola per non ripeterlo. Farla prima di aprire un altro filone prop e' la cosa piu' economica che ci sia in questo elenco.

In una riga: misurare la coda invece di assumerla e' la ricerca che vale di piu' (3,1 anni, gratis); leggere il listino di una prop firm e' la verifica che vale di piu' (un canale intero, un pomeriggio); e nessuna delle due batte i versamenti, che restano il vincolo binding come il 26/07 aveva gia' stabilito.

5. AUTOCRITICA DELL'ONDATA

5.1 — 🚨 Un filone su venti non e' nel ledger, ed e' quello con il risultato eseguibile oggi

ALT-OPTIONS (filone 14, r0822_alt_options.py, 709 righe) non ha ne' una riga di tabella ne' una sezione in RESULTS-0822.md. [VERIFICATO: 19 sezioni ###, 18 righe di tabella, nessuna per il 14 — e la tabella ha anche un difetto di markdown che fonde le righe 9 e 4 su una sola linea (... = TP01 travestito || 4 | DEALER-GAMMA | ...).] Il filone e' citato due volte da un altro filone («vedi filone 14», «ETH_USDC resta la gamba giusta ... (filone 14)») e serve al coordinatore per ritirare una propria inferenza sbagliata sull'OI — ma il lettore non trova la fonte da nessuna parte.

Nel diario compare come due parole dentro l'elenco dei morti: «alt-options (alt)». La sintesi e' sbagliata due volte: il filone non muore «perche' alt» (la sua conclusione e' che SOL/XRP/HYPE/AVAX sono i peggiori: SOL_USDC ha il 9% dei put quotati a due lati e f_venue negativo), e cio' che trova e' che ETH_USDC — non un alt — e' la gamba con f_venue = 0,980, spread della corta al 2,6%, max-loss $16,62/lotto e 3.000 lotti al best bid. Cioe' §1.7: la quarta soglia pubblicata falsificata dall'ondata, quella che tiene VRP01 fuori per taglia — e il diario ne annuncia tre.

Lezione: il ledger e' stato scritto man mano (lo dice la sua prima riga) e un filone che finisce mentre si scrive la sintesi puo' sparire senza che nulla lo segnali. Serve una guardia banale: contare i file r0822_*.py e le sezioni del ledger, e non chiudere l'ondata se non combaciano. E' lo stesso principio che l'ondata ha appena raccomandato per i monitor.

5.2 — Il gate `implausible_sharpe` non e' stato girato dove serviva, per la seconda volta

MONITOR-AUDIT lo osserva bene: «implausible_sharpe esiste dal 26/07 e non e' mai stato puntato sulle serie forward» (avrebbe segnalato Sharpe −15,8 su 28 barre). Ma la stessa mancanza si ripete dentro l'ondata: il gate non compare in PROP-ALLOC (dove J e P(pass) sono costruiti su percorsi bootstrap, non su una serie reale — legittimo, ma va dichiarato) ne' in GROWTH-POLICY, il cui output include un capitale mediano di $4,4e12 — che e' letteralmente la firma per cui il gate e' stato scritto. L'agente ha fatto il controllo di plausibilita' a mano e l'ha riportato con onesta'; il gate del progetto non e' stato invocato. Un gate che si applica a mano e' un gate che un giorno non si applichera'.

5.3 — Due «difetti di dato» diagnosticati per ricostruzione con la sorgente a due minuti di distanza

E' il tema di §1.2 e §1.3, e vale come critica di metodo dell'ondata, non dei due agenti. Il progetto ha codificato il 07/08: «una fonte normativa citata in un commento di codice si verifica come un numero» — nata da una legge citata male in 5 file per settimane. Il 22/08 due filoni dichiarano un difetto in un dato prodotto da /opt/docker/cerbero-mcp (acceso, sulla stessa macchina, e per giunta gia' usato da PythagorasGoal per Hyperliquid) e da Adriano/Cerbero-Bite (su Gitea, ultimo commit di dismissione), senza aprire ne' l'uno ne' l'altro. Io li ho aperti entrambi in meno di dieci minuti. Il brief e' complice: elenca le dieci trappole statistiche e non dice «prima di dichiarare un difetto di dato, leggi il codice che quel dato lo produce». E' la regola nuova piu' economica che questa ondata possa lasciare.

5.4 — Il coordinatore ha lasciato passare una conclusione debole, e ne ha corretta una propria

Corretta (a merito): l'inferenza «BTC_USDC e' praticamente morto», ritirata dopo la misura di ALT-OPTIONS, con la ragione scritta accanto. E' il comportamento giusto. Lasciata passare: la lezione di ORTHO-SCREEN (§2.1). E' etichettata «il risultato piu' riusabile dell'ondata» e «non e' sfortuna, e' aritmetica» — due formule che chiudono la discussione — mentre la sua meta' operativa («dichiarare famiglie molto piu' piccole in anticipo») e' la manovra che il progetto ha proibito il 30/07 e la sua meta' quantitativa dipende da una variabile (la dispersione delle celle) mai nominata. Il segnale che avrebbe dovuto fermarla c'era ed era nello stesso ledger, sette sezioni piu' avanti: il DSR vacuo di VOL-SIZE. Due misure dello stesso gate, versi opposti, stesso giorno, nessun rimando. La sintesi di venti filoni ha un compito che nessun filone ha: incrociare. Qui non l'ha fatto, e non l'ha fatto neanche su §2.4 (leva), §2.5 (peso SKH01), §1.5 (le due gambe del gate 23/10) e §1.6 (k* contro la partecipazione al nastro) — cinque incroci disponibili a costo zero, tutti fra coppie di filoni gia' consegnati.

5.5 — Agenti che hanno dichiarato «non girabile» cio' che era girabile

FLOW-SQUEEZE: «liquidation_long/short: NO ... Nessuna fonte nostra la produce, e non c'e' niente da produrre». I due input della regola sono nel file (§1.3). Costo del mancato lavoro: ~due ore. Il verdetto non sarebbe cambiato; la motivazione si'.
DEALER-GAMMA: «Quale [convenzione], lo decide la sezione 2 (ricostruzione dalla catena), non io» — decidibile leggendo, in due minuti (§1.2).
PROP-ALLOC: la banda d'ancora dichiarata «non girata, fuori budget». Onesto, e la distorsione e' dichiarata a proprio sfavore. Ma e' l'unica distorsione dichiarata che punta nella direzione della raccomandazione, sull'unico filone che raccomanda qualcosa: dovrebbe essere il primo pezzo di budget di un seguito, non l'ultimo.
TERM-STRUCTURE: «deflated_sharpe NON girato, e la motivazione e' il risultato» — questo invece e' corretto e da imitare: con 74 osservazioni l'incertezza di campione domina di un ordine di grandezza quella da selezione, e deflazionare 312 trial avrebbe dato «un numero preciso e privo di senso». E' anche la migliore descrizione, scritta senza saperlo, del problema di §2.1.

5.6 — Cosa l'ondata ha fatto meglio della media del progetto (perche' un'autocritica che elenca

solo difetti non e' calibrata) Sette agenti hanno catturato un errore proprio prima di pubblicare; tre hanno refutato una propria ipotesi in corsa; uno scettico ha ritirato una regola pubblicata poche ore prima provando che il difetto non esisteva — e la regola ritirata era sua di famiglia. Quattro filoni hanno dichiarato la potenza prima di guardare (OI-PIN, FLOW-SQUEEZE, SLIP-AUDIT, VOL-SIZE) e in tre casi il candidato e' morto contro la propria soglia dichiarata, che e' il modo piu' pulito di morire. Le repliche bit-exact prima di ogni delta sono ormai sistematiche (5/5 in XS-LITE e HL-EXEC, max|diff| = 0,0). Il metodo dei singoli filoni non e' il problema di questa ondata: la cucitura lo e'.

Appendice — cosa ho verificato in questa sessione, e come

#	fatto	come
A	`dealer_net_gamma` = convenzione dichiarata (dealer short calls / long puts) nel sorgente di `cerbero-mcp`, non un difetto	letto `/opt/docker/cerbero-mcp/src/cerbero_mcp/common/options.py:11-14, 138-140`
B	bite inoltra il campo e non lo calcola; chiama con `top_n_strikes=50` di default	clone `Adriano/Cerbero-Bite`, `runtime/market_snapshot_cycle.py:85`, `clients/deribit.py:342-384`
C	`liquidation__risk` = soglia su `oi_delta_24h` + funding, e i due input sono nel parquet* (copertura 99%, `oi_delta_pct_4h` std 1,23%)	`sentiment/fetchers.py:480-518` + lettura di `cb_market_snapshots.parquet`
D	`sr0` del DSR = `sd(Sharpe dei trial) x mult(N)`; con sd=0,58, `sr0` passa da 1,57 (N=168) a 1,15 (N=24)	letto `altlib.deflated_sharpe:689-712`, moltiplicatori ricalcolati
E	il libro 75/25 fa +0,97% il 12/03/2020 (BTC −41,5%, ETH −45,7%); peggior giorno −3,38%, non un crash	`altlib.tp01_baseline_daily()` + `sleeves._skyhook_returns()`, close-only
F	`collect_chain.py` interroga `{"currency": asset}` e filtra `OI_MIN = 100.0`	`scripts/live/collect_chain.py:57, 114, 181`
G	il feed certificato e' `BTC/USD:BTC` (inverse), il libro esegue `BTC_USDC-PERPETUAL` (lineare)	`rebuild_history.DERIBIT_INSTR:48` vs `src/live/deribit.INSTRUMENT:110`
H	ALT-OPTIONS: ETH_USDC `f_venue` 0,980 / max-loss $16,62 / 7 strutture al 20% di $635	output del filone in scratchpad
I	il dataset dei futures datati (20 MB) vive solo in `scratchpad/basis_cache/`	`du -sh`
J	`RESULTS-0822.md`: 19 sezioni, 18 righe di tabella, filone 14 assente, righe 9 e 4 fuse	conteggio diretto

⚠️ Su (G): e' un fatto, non un'accusa. rebuild_history lo dichiara in un commento («inverse, storia lunga ~ lineare entro 3 bps») e SLIP-AUDIT ha misurato la base ai 18 fill (BTC −0,03 bps, ETH −0,27) — trascurabile sui ritorni, che dipendono dalle variazioni della base. Lo segno solo perche' e' la 5ª occorrenza nell'ondata dello schema «un controllo puntato su uno strumento diverso da quello che si trada» (dopo fee_watch 21/08, il collettore della catena, il feed dello slippage e la taratura di venue_watch), e perche' la parte non verificata di quel commento — «~ lineare entro 3 bps» su tutta la storia — non e' mai stata misurata: esiste una misura su 18 istanti, non sulle 60.000 ore in cui entrambi gli strumenti esistono. Costo di chiuderla: un'ora.

Book, pesi, cron, config: questo filone non tocca niente. Consegna un'analisi. Le uniche azioni che raccomanda sono a costo quasi nullo e tutte su documenti o verifiche: correggere §1.2 nel ledger, aggiungere la sezione mancante di §5.1, dichiarare la dispersione accanto a ogni DSR (§2.1), ri-registrare il gate del 23/10 prima di rigenerare le serie (§1.4-1.5), persistere il dataset dei futures (§3.4), e leggere il listino di una prop firm prima di misurare un'altra volta il canale che ne dipende (§1.1).

47 KiB Raw Permalink Blame History Unescape Escape

CRITICO DI COMPLETEZZA — ondata 2026-08-22 (r0822b_critic)