# 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:**
1. **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**.
2. **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.**
3. **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).