# Decisione Strategica PoC Multi-Swarm Coevolutivo — Design

**Autore**: Adriano Dal Pastro
**Data**: 9 maggio 2026
**Status**: Design strategico approvato per implementazione
**Versione**: 1.0
**Documenti correlati**:
- `00_documento_zero.md` (framework concettuale)
- `coevolutive_swarm_system.md` (Filone A, sistema completo)
- `poc_trading_swarm.md` (Filone B, design PoC trading)

---

## 1. Executive Summary

Questo documento formalizza la decisione strategica su come avviare il progetto Multi-Swarm Coevolutivo. La scelta cade sulla variante **B3 — PoC trading incrementale a tre fasi con gate go/no-go**, una declinazione disciplinata dell'opzione Smart Spike (Filone B) descritta nel documento zero.

La forma incrementale tripartita non sostituisce il design del PoC contenuto in `poc_trading_swarm.md`, ne organizza l'esecuzione in fasi successive con kill-switch numerici espliciti. Il principio guida è **applicare al progetto stesso la disciplina che il sistema dovrà applicare alle proprie ipotesi**: spegnere ciò che non funziona quando i dati lo dicono, senza sconti emotivi e senza giudizi soggettivi sui hard gate.

**Vincoli operativi adottati**:

| Dimensione | Valore |
|---|---|
| Obiettivo primario | Sistema produttivo che generi valore (trading reale, fase posteriore al PoC) |
| Dominio iniziale | Derivati crypto BTC/ETH |
| Tempo committed | Full-time, oltre 30h settimanali |
| Budget LLM cap | $2.200 hard, segmentato per fase |
| Capitale a rischio | $500-2.000 (solo nella Phase 3 forward-test mainnet) |
| Tempo calendario | 14-18 settimane atteso, 20 settimane hard cap |
| Setup tecnico di partenza | Cerbero_mcp operativo (multi-exchange, indicatori, audit, dual env) |

**Esito atteso**: alla fine delle tre fasi, una decisione binaria documentata con razionale numerico fra (a) avviare il sistema completo Filone A con confidence empirica forte, (b) iterare la Phase 2 su debolezze identificate, (c) pivotare su un dominio diverso (offerte commerciali Tielogic, code review), oppure (d) chiudere il progetto con learnings registrati.

---

## 2. Razionale della scelta strategica

### 2.1 Le tre opzioni del documento zero, oggi

Il documento zero presenta tre opzioni: A (Big Bet, sistema completo, 12-18 mesi), B (Smart Spike, PoC trading, 3-4 mesi), C (Research Dive, paper review più PoC minimo, 1-2 mesi). Alla luce dei vincoli operativi sopra elencati, la valutazione cambia rispetto al momento in cui il documento zero è stato scritto.

L'opzione A è esclusa dal vincolo budget. Le stime conservative del Filone A indicano costi LLM nell'ordine di $10.000-30.000 anche solo per la fase iniziale, contro un cap committed di $2.200. Non è una questione di tempo: il tempo full-time c'è. È che il rapporto fra costo del run e disponibilità non lo rende sostenibile senza una validazione empirica preliminare.

L'opzione C sotto-utilizza due asset materiali. Il primo è la disponibilità full-time, che rende il vincolo "non posso permettermi di costruire infrastruttura" non applicabile. Il secondo è Cerbero_mcp, già operativo: leggere paper per due settimane senza scrivere codice produttivo significherebbe lasciare ferma un'infrastruttura già pronta a essere wrappata come tool layer per agenti LLM.

Resta l'opzione B. Il documento zero la indicava come scelta preferita; questo documento la conferma e la struttura.

### 2.2 Perché B3 e non B1 o B2

Tre varianti di B sono state considerate.

La variante **B1 (Lean / single-shot)** comprime il PoC in un'unica run con popolazione ridotta a 20-30 agenti e tier C unico. Coerente con il budget tight, ma rischiosa: la dimensione della popolazione è il principale moltiplicatore di diversità nel sistema, e una popolazione undersized rischia di produrre un falso negativo. Si decreterebbe il sistema "non funzionante" quando in realtà non gli abbiamo dato il numero di tentativi necessari.

La variante **B2 (Canonical / come da documento)** segue fedelmente `poc_trading_swarm.md` con K=50, mix tier B/C, full set di ablation. Tecnicamente solida ma sfora il budget cap di un fattore 1.5-2x. Adottabile solo accettando di alzare il cap a $3-4K, decisione non giustificabile senza segnali empirici preliminari.

La variante **B3 (Incrementale)**, scelta, articola il PoC in tre fasi sequenziali con cap budget per fase e gate decisionali quantitativi fra una fase e la successiva. Phase 1 valida il loop tecnico con popolazione minima e tier economico. Phase 2 esegue il PoC canonico solo se Phase 1 passa. Phase 3 forward-testa con capitale reale solo se Phase 2 passa. Il budget totale resta entro $2.2K e il rischio di falso negativo viene ridotto dal fatto che la popolazione completa di Phase 2 non viene mai tagliata: viene messa al lavoro solo dopo che il loop è stato validato.

La struttura tripartita ha anche un beneficio non monetario: i deliverable di Phase 1 e Phase 2 valgono anche se le fasi successive falliscono. Il backtest engine, il GA harness, la Cerbero integration, la dashboard Streamlit, la pipeline DSR sono tutti riusabili in caso di pivot di dominio. Solo il capitale di Phase 3 è genuinamente "a rischio" come costo della validazione.

### 2.3 Coerenza con la filosofia del progetto

Il documento zero al §3.3 identifica come takeaway fondamentale di Renaissance la disciplina di spegnere strategie quando l'edge svanisce, senza decisioni emotive. Il design B3 applica questa disciplina al progetto stesso, prima ancora che al sistema. I gate sono numerici, le soglie sono fissate prima di vedere i dati, l'azione di stop è meccanica quando un hard gate fallisce. Non c'è spazio per "magari un'altra generazione" o "i risultati erano quasi ottimi": la decisione è già scritta nel design.

---

## 3. Vincoli di terminazione globali

Tre kill-switch globali sopra le singole fasi:

1. **Cap budget LLM globale**: $2.200 hard. Spesa effettiva monitorata da pagina Overview della dashboard, contatore aggiornato dopo ogni batch. Sforamento previsto entro la fase corrente → riformulazione scope, non incremento cap.
2. **Cap tempo calendario**: 14-18 settimane attese, **20 settimane hard cap** dalla settimana 1 della Phase 1 alla decisione formale post-Phase 3. Sforamento previsto del cap → decisione anticipata sulla base dei dati raccolti, non estensione del cap.
3. **Hard gate falliti**: per costruzione, un hard gate fallito chiude la fase corrente e non apre quella successiva. La decisione fra stop, pivot, o iterazione è formalizzata nel decision memo della fase chiusa, non nel passaggio automatico alla successiva.

---

## 4. Phase 1 — Lean Spike

**Obiettivo**: dimostrare che il loop tecnico funziona end-to-end. Non si misura ancora alpha: si misura se il sistema gira come progettato, se l'output LLM è formalizzabile, se la GA converge, se i costi sono prevedibili.

### 4.1 Scope IN

- Infrastruttura backtest minima: dataset 2 anni (2024-2026) di OHLCV 1h BTC/ETH, engine event-driven semplificato (no microstructure, no slippage modelling complesso, fees fissi a 5 basis points), walk-forward expanding 70/30.
- Wrapper Cerbero come tool layer per agenti: i tool MCP esistenti (`indicators`, `vol_cone`, `oi_weighted_skew`, indicatori options/microstructure/stats) tradotti in funzioni callable dagli agenti. Niente reimplementazione, solo wrapping.
- Protocollo S-expression fisso: 12-15 verbi disegnati manualmente come da `poc_trading_swarm.md` §2.2. Nessuna evoluzione del protocollo in questa fase.
- Hypothesis Swarm con K=20 agenti, tier C unico (Qwen 2.5 72B via OpenRouter). Mutazione e crossover prompt come da documento PoC. Nessuna speciation, nessun novelty bonus.
- Falsification e Adversarial layer hand-crafted, un agente fisso per ognuno, prompt manuali. Tier B (Sonnet 4.6) chiamato solo per i top-5 candidati a fine generazione, per contenere costi.
- Fitness function v0: DSR in-sample con drawdown penalty. No multi-livello, no out-of-sample ancora.
- GA loop: 8-12 generazioni, tournament selection, elitism k=2.

### 4.2 Scope OUT (esplicito)

- Multi-tier ablation comparativa.
- Out-of-sample DSR e hold-out finale.
- Random Forest baseline.
- Speciation, novelty, diversity metrics.
- Forward-test con capitale reale.
- Domini diversi da BTC/ETH.

### 4.3 Budget e tempo

- LLM: $500-700. Stima base: 20 agenti × ~8.000 token output medi × 10 generazioni × pricing Qwen ≈ $300, più 50% di overhead per Adversarial, Falsification e iterazioni di sviluppo, totale stimato $500-700.
- Tempo: 4-6 settimane full-time. Settimane 1-2 backtest engine e Cerbero wrapper, settimana 3 GA infrastructure e parser S-expression, settimane 4-5 tuning e run completo, settimana 6 analisi e decisione gate.
- Capitale a rischio: zero.

### 4.4 Gate go/no-go (tutti AND)

Cinque hard gate:

1. **Loop converge**: la fitness mediana della popolazione cresce per almeno tre generazioni consecutive prima di plateau.
2. **Output formalizzabile**: almeno l'80% delle proposte LLM passano il parser S-expression senza intervento manuale.
3. **Tail superiore esiste**: i top-5 genomi hanno DSR in-sample pari ad almeno 1.5x la mediana di popolazione, segnale che esiste struttura e non solo rumore.
4. **Diversità non collassa**: entropia della distribuzione di fitness in popolazione superiore a 0.5 a fine run, evita la convergenza monocoltura.
5. **Cost predictability**: spesa effettiva entro ±30% della stima preventivata.

Anche un solo hard gate fallito chiude la Phase 1. Decisione successiva (pivot, ridiscussione design, stop) presa nel decision memo, non automaticamente in Phase 2.

### 4.5 Deliverable Phase 1

- Codice testato (pytest): backtest engine, Cerbero wrapper, GA loop, protocol parser.
- Report tecnico (~5 pagine): loop convergence con grafici, ispezione qualitativa dei top-5 genomi, parser failure modes osservati, costi reali vs preventivo, diversity metrics.
- Decision memo: vai/non-vai a Phase 2 con eventuali aggiustamenti di scope.

---

## 5. Phase 2 — Canonical PoC

**Obiettivo**: rispondere ai cinque test del PoC originale (`poc_trading_swarm.md` §1) con popolazione e infrastruttura adeguate. Solo questa fase produce una vera misura dell'edge potenziale del sistema.

### 5.1 Scope IN (in aggiunta a Phase 1)

- Hypothesis Swarm K=40, scaling della popolazione a un livello canonico ridotto (K=50 documento → K=40 per disciplina budget).
- Tier mix B/C: circa 70% Qwen/DeepSeek (tier C), 30% Sonnet 4.6 (tier B). L'ablation comparativa misura il valore aggiunto del tier B.
- Speciation di base: clustering dei genomi per cosine similarity dei prompt più cognitive_style. Si mantengono almeno 3 specie attive, ognuna con quote di tournament protette.
- Novelty bonus: fitness composta α·DSR_OOS + β·novelty_score, dove la novelty è calcolata come distanza behavioural dei segnali rispetto a un archivio di elite.
- Walk-forward expanding più hold-out finale: training Q1-2024 a Q4-2025 in walk-forward, hold-out intoccabile Q1-Q2 2026.
- Random Forest baseline: feature engineering classico (returns multi-orizzonte, RSI/MACD/ATR, vol cone, funding rate, OI changes), classificazione long/flat/short su orizzonti 1d e 4h, valutato sulla stessa hold-out.
- Adversarial layer hand-crafted potenziato: cinque prompt distinti (data snooping, lookahead, regime fragility, crowding, transaction cost erosion) eseguiti sui top-10 candidati prima della valutazione OOS.
- Falsification con Deflated Sharpe Ratio (Bailey & López de Prado), correzione Bonferroni sul numero totale di ipotesi testate.
- Fitness multi-livello: per-agent (contributo DSR), per-team (DSR portfolio), diversity penalty per ridurre collusione.

### 5.2 Scope OUT

- Co-evolution del protocollo (Filone A).
- Forward-test con capitale reale (Phase 3).
- Speciation NEAT-style completa.
- Idiom emergence.
- Domini diversi da trading.

### 5.3 Budget e tempo

- LLM: $700-1.100. Dettaglio stimato: tier C ~$500, tier B ~$400, overhead per ablation iterativa ~$200. Range ampio per consentire più cicli di ablation se i primi risultati lo richiedono.
- Tempo: 4-6 settimane full-time. Settimana 1 porting K=40, speciation, novelty. Settimane 2-3 ablation runs (tier C only, tier B only, mix; con e senza speciation). Settimana 4 hold-out evaluation, RF baseline, Adversarial sweep. Settimane 5-6 analisi statistica, report, decisione gate.
- Capitale a rischio: zero.

### 5.4 Gate go/no-go

**Hard gate (tutti AND, altrimenti stop)**:

1. **Significatività statistica**: top genoma su hold-out con DSR > 1.0 e p-value < 0.05 dopo correzione Bonferroni.
2. **Sopravvivenza regime change**: DSR hold-out almeno 0.5x del DSR walk-forward — limite contro overfitting catastrofico.
3. **Batte baseline**: top-3 genomi con Sharpe OOS superiore al Sharpe RF baseline OOS, effect size non trascurabile (Cohen's d > 0.3 sul rolling Sharpe).

**Soft gate (informano, non killano)**:

4. **Diversità**: almeno 3 specie distinte sopravvivono a fine run, top-3 genomi non identici per signal correlation (ρ < 0.7).
5. **Tier B aggiunge valore**: l'ablation mostra Δ Sharpe OOS misurabile per tier mix vs tier C only. In caso negativo, Phase 3 può girare tier C only e il decision memo ne prende nota.

Hard gate passati → Phase 3. Hard gate falliti → stop o pivot. Soft gate falliti → Phase 3 con scope ridotto e annotazioni nel report.

### 5.5 Deliverable Phase 2

- Codice testato: speciation, novelty, ablation harness, RF baseline, DSR pipeline, Adversarial battery.
- Report scientifico (~15-20 pagine): metodologia, risultati per ogni gate, ablation table, top-5 strategie ispezionate qualitativamente, threats to validity.
- Decision memo: vai/non-vai a Phase 3, scope di Phase 3 (capitale, exchange, leva, durata) calibrato sui risultati.

---

## 6. Phase 3 — Forward-test mainnet

**Obiettivo**: vedere se l'edge sopravvive in produzione. Anche il backtest più rigoroso ha bias inevitabili (look-ahead microscopico, slippage idealizzato, assenza di information leakage da fonti che non esistevano in periodo storico). Solo il forward-test live risponde alla domanda finale.

### 6.1 Scope IN

- Selezione strategie: top-3 genomi out-of-sample dalla Phase 2, dopo passaggio completo dell'Adversarial battery. Niente cherry-picking ex-post post-Phase 2.
- Capitale: $500-2.000 totali, distribuiti sui tre genomi con allocazione equal weight oppure risk-parity sulla volatilità OOS attesa, scelta motivata nel decision memo Phase 2.
- Exchange: scelta condizionata alle strategie selezionate. Default raccomandati Bybit (perp, fees competitive, liquidità BTC/ETH adeguata) oppure Hyperliquid (no KYC, transparent funding). Cerbero supporta entrambi nativamente.
- Leva: massimo 2x in forward-test. Anche se lo Sharpe OOS suggerisse di più, in fase di validazione la leva resta bassa per non confondere edge della strategia con leva.
- Durata: 6-8 settimane continue. Razionale: in crypto questa finestra copre tipicamente uno o due micro-regime change, sufficienti a stressare il modello senza catastrofi statistiche da campione troppo piccolo.
- Monitoring: dashboard giornaliera (sezione Live Monitor) con Sharpe live realized vs Sharpe OOS atteso, drawdown realtime, violation count (segnali generati ma non eseguiti per qualunque ragione), audit log Cerbero per ogni order.
- Decision triggers automatici: kill-switch se il drawdown live supera 1.5x il peggiore osservato in walk-forward; pause se Sharpe rolling 14d resta negativo per 14 giorni consecutivi.
- Adversarial post-mortem settimanale: l'agente Adversarial gira nuovamente sul signal log della settimana per identificare degradazione dell'edge (regime drift detection).

### 6.2 Scope OUT

- Capital scaling oltre $2.000 in Phase 3. Se i risultati promettono, la decisione di scaling è esplicitamente fuori dal PoC e viene presa dopo il decision memo finale.
- Multi-strategy portfolio rebalancing dinamico. Allocazione statica sui tre genomi.
- Hedging cross-exchange. Confonderebbe la lettura dell'edge della strategia.
- Aggiunta di nuovi genomi in corsa. I tre genomi sono fissati a inizio fase.

### 6.3 Budget e tempo

- LLM: $200-400. La popolazione GA non gira più, gli agenti sono richiamati solo per Adversarial post-mortem settimanale e per occasionali refresh quando i decision triggers scattano.
- Capitale a rischio: $500-2.000. Trattato come **costo della validazione**, non come investimento. Se il capitale va a zero, il dato che ne ricaviamo vale comunque.
- Tempo: 6-8 settimane di calendario, monitoring operativo circa 5h/settimana — non full-time. Le settimane libere sono allocate a documentazione finale, lavoro su Tielogic e altri progetti, prima esplorazione Filone A in caso di decisione GO.
- Costo infra extra: circa $10-30/mese VPS per dashboard più monitoring, in larga parte già coperto dal setup Hostinger esistente.

### 6.4 Gate decisionale finale del PoC

**Hard gate per "GO sistema completo / Filone A"**:

1. **Edge sopravvive live**: Sharpe live realized almeno 0.5x dello Sharpe OOS atteso, su finestra di almeno 4 settimane.
2. **No catastrophic failure**: max drawdown live al massimo 1.5x del peggior drawdown walk-forward.
3. **Reproducibility**: almeno 2 dei 3 genomi performano in linea con previsione — la fortuna non si concentra su uno solo.

**Soft gate (qualitativi, informano la decisione)**:

4. **Audit Adversarial settimanali**: nessuna scoperta critica come lookahead nascosto emerso solo live, oppure data leakage da provider.
5. **Cost economy**: edge dopo costi reali (slippage effettivo, fees, funding) resta positivo.

**Esiti possibili**:

- Hard gate e soft gate tutti passati → GO Filone A con confidence empirica forte. Si apre la ridiscussione del budget e della roadmap del sistema completo, fuori dal perimetro di questo documento.
- Hard gate passati, soft gate falliti → iterazione Phase 2 mirata sulle debolezze identificate, no Filone A immediato.
- Hard gate falliti, ma senza catastrofi → l'idea regge concettualmente ma non scala live retail. Decision memo con due opzioni: pivot dominio (offerte Tielogic, code review) oppure chiusura del progetto.
- Hard gate falliti più drawdown catastrofico → l'idea non regge live. Stop del progetto. Documento di chiusura con learnings registrati per progetti futuri.

### 6.5 Deliverable Phase 3 e finali

- Report finale del PoC (~20-30 pagine): metodologia completa, risultati Phase 1+2+3, comparison Sharpe in-sample / OOS / live, ispezione qualitativa delle strategie, learnings, threats to validity confermati o respinti.
- Decision memo strategico: GO Filone A / iterate Phase 2 / pivot dominio / stop, con razionale quantitativo ancorato ai gate.
- Codebase pubblicabile (anche se repo privato): backtest, GA, Cerbero integration, speciation, DSR pipeline, RF baseline, monitoring dashboard, tutto documentato.

---

## 7. GUI Streamlit incrementale

Una dashboard è essenziale per ispezionare cosa fa il sistema, decidere i gate in modo informato, e produrre i grafici che entreranno nei report.

### 7.1 Architettura

- Tech stack: Streamlit single-app multi-page, dati letti da SQLite locale (`runs.db`) e Parquet per series numerici pesanti.
- SQLite per stato: genomi, generazioni, fitness, ablation results, adversarial findings, trade log. Schema relazionale stabile, query veloci, nessun DB server da gestire.
- Parquet per series: equity curves, signal time series, OHLCV. File-based, columnar, leggero.
- Auto-refresh ogni 10 secondi nella sola pagina Live Monitor (Phase 3). Sufficiente per uno scope a decisioni minute-level, non HFT.
- Single app, multipage: tutto sotto `dashboard/streamlit_app.py` più `pages/`. Deploy locale con `streamlit run`, niente VPS frontend.

### 7.2 Pagine costruite incrementalmente

**Phase 1 (3-4 giorni di lavoro)**:

- *Overview*: ultima run, generazione corrente, stato (running/completed/failed), spesa LLM cumulata vs cap.
- *GA Convergence*: line plot fitness mediana / max / 90° percentile per generazione, distribuzione fitness ultima generazione (histogram), counter chiamate LLM e costo.
- *Genomes (basic)*: tabella top-10 genomi correnti con DSR, cognitive_style, temperature, lookback. Click su riga apre side panel con system_prompt completo, feature_access, lineage parent_id.

**Phase 2 (9-12 giorni distribuiti)**:

- *Genomes (avanzato)*: lineage tree interattivo (parent → children su 15 generazioni), speciation cluster view (UMAP/t-SNE su prompt embedding più parametri, colori per specie), filtri per specie / tier / cognitive_style.
- *Performance*: equity curve in-sample, walk-forward, OOS, hold-out per ogni genoma. Sharpe, DSR, drawdown. Trade distribution per regime di volatilità, asset, orario. Per-strategy e portfolio view.
- *Ablation*: confronto runs (tier C only, tier B only, mix) side-by-side. Δ Sharpe OOS, costo per percentile fitness, breakeven analysis.
- *Adversarial*: per ogni top-10 genoma, le cinque critiche (data snooping, lookahead, regime fragility, crowding, transaction cost). Click espande prompt completo, risposta LLM, decisione pass/fail con rationale.
- *RF Baseline*: Sharpe RF baseline OOS, feature importance, comparison vs top-3 swarm, Cohen's d effect size.

**Phase 3 (4-5 giorni)**:

- *Live Monitor*: P&L realtime per strategia e portfolio, equity curve da inizio Phase 3, drawdown rolling. Auto-refresh 10s.
- *Live vs OOS*: Sharpe live realized vs Sharpe OOS atteso (con confidence interval), gauge "edge sopravvive?", cumulative deviation tracker.
- *Triggers state*: stato kill-switch per strategia, distance from threshold, history pause/resume, audit log decisioni recenti.
- *Adversarial weekly*: report settimanale di regime drift detection, diff vs settimana precedente.

### 7.3 Costi GUI

- Effort totale: 16-21 giorni netti, distribuiti come da fasi sopra.
- LLM: zero (codice e visualizzazione Python locale).
- Infra: zero (esecuzione locale, SQLite locale, Parquet locale).

### 7.4 Trade-off accettati

- Refresh non realtime sub-secondo: accettabile per scope decisionale minute/hour.
- Niente login né multi-utente: dashboard personale solo locale.
- Niente alert push esterni in default: alert appaiono in dashboard. Per Phase 3 si può aggiungere webhook Telegram/email se necessario, mezza giornata extra di lavoro.
- Streamlit re-runs full-page on interaction: gestibile con `@st.cache_data` su query SQLite e dataset PoC di dimensioni contenute.

### 7.5 Deliverable GUI

- Codice `dashboard/` testato (smoke test e data layer test).
- Schema SQLite versionato con migrazioni semplici (Alembic light o script SQL).
- README con istruzioni `streamlit run` e descrizione di ogni pagina.

---

## 8. Hardware e infrastruttura

Principio: tutto locale più Cerbero come unico servizio remoto. Nessuna GPU, nessun cloud compute, nessun costo infra ricorrente significativo.

### 8.1 Compute

- Backtest e GA loop: PC locale Linux. Tutto CPU-bound, parallelizzabile su core (joblib o multiprocessing). Dataset 2 anni OHLCV 1h BTC+ETH circa 30-50 MB. Anche granularità 1m sarebbe sotto i 2 GB, gestibile.
- LLM: tutte chiamate via API esterne (OpenRouter per tier C, Anthropic per tier B). Nessun model locale, nessuna GPU.
- Streamlit dashboard: locale (`streamlit run` su `localhost:8501`).

### 8.2 Cerbero_mcp

Già configurato e operativo. Modalità d'uso durante PoC:

- Locale via Docker compose durante development e Phase 1-2 (testnet only). Riduce latenza, niente costi VPS, debug più rapido.
- VPS Hostinger durante Phase 3 forward-test (mainnet). Già setup `/opt/cerbero-mcp` con `deploy-vps.sh` e branch V2.0.0.
- Token bearer: `TESTNET_TOKEN` per Phase 1-2 backtest replay, `MAINNET_TOKEN` solo per Phase 3.
- Bot tag dedicato per il PoC (`X-Bot-Tag: swarm-poc-<phase>`). L'audit log Cerbero traccia ogni call separatamente per fase, utile per ricostruzioni post-mortem.

### 8.3 Storage

- `runs.db` SQLite per stato GA, genomi, generazioni, fitness, adversarial, trade log. Backup giornaliero su disco esterno o cloud personale.
- `series/` Parquet per equity curves, signal time series, OHLCV cache. Versionato fuori da git (Git LFS o cartella esterna trackata in `.gitignore`).
- Audit log Cerbero: già JSONL con rotazione 30 giorni (`AUDIT_LOG_BACKUP_DAYS=30`). Per Phase 3 aumentare a 90 giorni per coprire intera fase più post-mortem.

### 8.4 Networking

- LLM API via OpenRouter (tier C) e Anthropic (tier B). Nessun setup speciale.
- Cerbero locale: porta 9000 default, nessuna esposizione pubblica.
- Cerbero VPS: già protetto da Traefik più bearer più allowlist IP. Nessun lavoro extra.

### 8.5 Costi infra ricorrenti

- VPS Hostinger: già pagato per altri progetti, costo marginale zero.
- Storage backup: trascurabile.
- Domini e TLS: già coperti (cerbero-mcp.tielogic.xyz).

### 8.6 Decisioni hardware non bloccanti

- Se la Phase 2 ablation richiedesse parallelizzazione massiva (ad esempio cento backtest concorrenti), valutare spot instance AWS o Hetzner. Probabilmente non necessario, le strategie a granularità 1h sono veloci da backtestare anche su CPU desktop.
- Backup off-site di `runs.db`: decisione di lifecycle, non bloccante per Phase 1.

---

## 9. Cadenza review e disciplina autoriale

Regola personale dell'autore: mai self-approve, separare author pass da review pass. Applicata sistematicamente ai gate del PoC.

### 9.1 Cadenza working

- Daily: lavoro full-time. Self-review informale a fine giornata, una riga nel commit message su cosa è andato e cosa no.
- Settimanale (venerdì): review formale con dump strutturato che include fitness convergence plot, top-5 genomi della settimana, spesa LLM accumulata vs cap di fase, eventuali findings Adversarial significativi, aggiornamento di `progress.md`.
- Bi-settimanale: snapshot completo più decision check sul fatto se siamo ancora on-track per il gate. Se due bi-weekly consecutivi mostrano off-track materiale, decisione anticipata di pivot o iterate, non attesa fino a fine fase.

### 9.2 Gate review (decisione formale fine fase)

Per ognuno dei tre gate (fine Phase 1, fine Phase 2, fine Phase 3): author pass e review pass separati.

- **Author pass**: l'autore scrive il decision memo con tutti i numeri, gate per gate, conclusione raccomandata.
- **Review pass**: secondo passaggio con approccio adversarial. Tre opzioni equivalenti:
  - Subagent Claude con prompt esplicitamente "red team" che riceve memo più dati grezzi e produce critica strutturata (cherry-picking, debolezze statistiche, omissioni).
  - Collega umano disponibile, se esiste un contesto Tielogic adatto.
  - Rilettura dopo 48 ore con timer, fresh eyes pass.
- **Sintesi**: solo dopo il review pass la decisione viene formalizzata e committata.

### 9.3 Decision triggers oggettivi

I gate hard di ogni fase sono numerici (DSR, p-value, drawdown ratio). La decisione GO/STOP è meccanica sui hard gate:

- Hard gate fallito → STOP automatico, non in discussione.
- Hard gate passato → si valuta se i soft gate danno motivo di iterazione invece di procedere.

Questa è la disciplina Renaissance applicata al progetto: niente "magari un'altra generazione" se il numero non lo dice.

### 9.4 Documentazione del processo

- `docs/runs/YYYY-MM-DD-phase{1,2,3}-run-N.md` per ogni run completato: configurazione, risultati, anomalie, learning.
- `docs/decisions/YYYY-MM-DD-gate-phase{1,2,3}.md` per ogni decisione gate: author pass, review pass, decisione finale, razionale.
- Questo documento (`docs/superpowers/specs/2026-05-09-decisione-strategica-design.md`) come north star strategico, aggiornato se cambiano vincoli o decisioni macro.

---

## 10. Catena di ragionamento (tracciabilità)

Per riferimento futuro, la sequenza logica che ha portato al design B3:

1. Obiettivo dichiarato sistema produttivo che generi valore → esclude C (research dive senza output produttivo).
2. Dominio iniziale trading crypto → allinea il PoC al design già scritto in `poc_trading_swarm.md`.
3. Tempo full-time disponibile → scioglie il vincolo "non posso costruire infrastruttura", apre spazio per fasi sequenziali.
4. Budget LLM tight ($1-2K) → esclude A (Filone completo) e impone disciplina su B.
5. Setup Cerbero_mcp esistente → riduce settimane di plumbing, gli agenti chiamano tool MCP nativi.
6. Forward-test mainnet con capitale piccolo come parte del successo → richiede una Phase 3 dedicata, distinta dalla validazione statistica.
7. Disciplina "spegnere ciò che non funziona" → struttura tripartita con kill-switch numerici.
8. Mai self-approve → separazione author pass / review pass nei gate.
9. Necessità di ispezionare cosa fa il sistema → GUI Streamlit come componente orizzontale, non opzionale.

---

## 11. Decisioni risolte e decisioni ancora aperte

### 11.1 Risolte da questo documento

- Opzione strategica: B3.
- Dominio iniziale: trading derivati crypto BTC/ETH.
- Numero di fasi: tre, con gate go/no-go fra una e l'altra.
- Budget cap globale: $2.200 LLM più $500-2.000 capitale a rischio Phase 3.
- Cap calendario: 18 settimane.
- Tier mix: solo C in Phase 1, mix B/C in Phase 2-3.
- Tech stack GUI: Streamlit più SQLite più Parquet.
- Infrastruttura: locale più Cerbero_mcp esistente.
- Cadenza review: settimanale, bi-settimanale per check, gate con author/review pass separati.

### 11.2 Aperte (non bloccanti per Phase 1)

- Allocazione capitale Phase 3 (equal weight vs risk-parity): decisione formalizzata nel decision memo Phase 2 sulla base dei risultati OOS.
- Exchange Phase 3 (Bybit vs Hyperliquid): scelta dipendente dalle strategie selezionate, decisa nel decision memo Phase 2.
- Approccio review pass (subagent vs umano vs fresh eyes): decisione tattica per gate, nessun lock-in.
- Webhook alert Telegram/email per Phase 3: opzionale, decidibile a inizio Phase 3.

### 11.3 Esplicitamente fuori scope

- Filone A (sistema completo) come fase corrente. Decisione su A presa solo dopo decision memo finale Phase 3.
- Filone C (applicazioni non-trading: offerte Tielogic, code review, doc Swagger). Possibile pivot in caso di hard gate falliti, non azione preventiva.
- Co-evolution del protocollo. Nessuna delle tre fasi PoC la include.
- Capital scaling oltre $2.000 in Phase 3. Decisione di scaling appartiene a una fase successiva al PoC.

---

## 12. Prossimi passi

Esecuzione di Phase 1.

Il piano implementativo dettagliato di Phase 1 (settimana per settimana, task atomici, dipendenze, verifiche) sarà oggetto del documento successivo, da costruire con l'invocazione dello skill `writing-plans` su questo design.

---

*Documento approvato il 9 maggio 2026. Versione 1.0. Aggiornare in caso di modifica dei vincoli operativi o di esiti di gate che richiedano revisione strategica complessiva.*