Merge branch 'restructure/strategy-crypto-monorepo'
This commit is contained in:
Adriano Dal Pastro
+9
-2
@@ -21,13 +21,20 @@ LLM_MODEL_TIER_D=openai/gpt-oss-20b
|
||||
RUN_NAME=phase1-spike-001
|
||||
DATA_DIR=./data
|
||||
SERIES_DIR=./series
|
||||
DB_PATH=./runs.db
|
||||
|
||||
# Database paths (split per dominio):
|
||||
# - GA_DB_PATH: tabelle GA universali (runs, generations, genomes, evaluations)
|
||||
# - STRATEGY_CRYPTO_DB_PATH: tabelle paper_trading_* per la strategia crypto
|
||||
GA_DB_PATH=./state/runs.db
|
||||
STRATEGY_CRYPTO_DB_PATH=./state/strategy_crypto.db
|
||||
|
||||
# Docker / Traefik (usati SOLO da docker-compose.yml)
|
||||
# Dominio base: traefik espone la dashboard su swarm.${DOMAIN_NAME}
|
||||
# Dominio base: traefik espone la dashboard su swarm.${DOMAIN_NAME}/strategy_crypto_gui
|
||||
DOMAIN_NAME=tielogic.xyz
|
||||
# Porta interna della NiceGUI dashboard (Traefik fa il TLS davanti)
|
||||
SWARM_DASHBOARD_PORT=8080
|
||||
# Subpath URL del dashboard NiceGUI (usato come root_path in produzione)
|
||||
DASHBOARD_ROOT_PATH=/strategy_crypto_gui
|
||||
|
||||
# Paper-trading runner — override del command nel compose (opzionali)
|
||||
PAPER_RUN_NAME=phase3-papertrade-prod
|
||||
|
||||
@@ -24,6 +24,10 @@ venv/
|
||||
*.key
|
||||
|
||||
# Project artefacts (non versionati: troppo grandi o rigenerabili)
|
||||
state/*.db
|
||||
state/*.db-journal
|
||||
state/*.db-wal
|
||||
state/*.db-shm
|
||||
runs.db
|
||||
runs.db-journal
|
||||
runs.db-wal
|
||||
@@ -36,6 +40,9 @@ checkpoints/
|
||||
logs/
|
||||
*.log
|
||||
|
||||
# OMC state (auto-orchestration)
|
||||
.omc/
|
||||
|
||||
# Build / dist
|
||||
build/
|
||||
dist/
|
||||
|
||||
+13
-11
@@ -1,13 +1,15 @@
|
||||
# syntax=docker/dockerfile:1.7
|
||||
#
|
||||
# Multi-Swarm Coevolutive — immagine unica usata da due servizi:
|
||||
# * paper-trading runner (scripts/run_paper_trading.py)
|
||||
# * Streamlit dashboard (src/multi_swarm/dashboard/streamlit_app.py)
|
||||
# Multi-Swarm Coevolutive — immagine unica usata da due servizi del compose:
|
||||
# * paper-trading runner (scripts/run_paper_trading.py)
|
||||
# * NiceGUI dashboard (strategy_crypto.frontend.nicegui_app)
|
||||
#
|
||||
# Builder stage: risolve uv.lock con `uv sync --frozen --no-dev` e produce
|
||||
# un venv in /app/.venv. Runtime stage: copia solo /app + scripts/ e gira
|
||||
# come utente non-root. data/, series/, strategies/, state/ sono bind
|
||||
# mount dal compose, quindi non finiscono nell'immagine.
|
||||
# uv workspace: pyproject root coordina due member packages
|
||||
# (multi-swarm-core + strategy-crypto). Il `uv sync --frozen` installa
|
||||
# entrambi come editable nella venv del builder.
|
||||
# Runtime stage: copia solo /app + scripts/ e gira come utente non-root.
|
||||
# data/, series/, state/ sono bind mount dal compose; strategies/ è
|
||||
# bind-mounted dal path src/strategy_crypto/strategy_crypto/strategies.
|
||||
|
||||
FROM python:3.13-slim AS builder
|
||||
RUN apt-get update && apt-get install -y --no-install-recommends \
|
||||
@@ -21,7 +23,7 @@ RUN uv sync --frozen --no-dev
|
||||
|
||||
|
||||
FROM python:3.13-slim AS runtime
|
||||
LABEL org.opencontainers.image.title="multi-swarm" \
|
||||
LABEL org.opencontainers.image.title="multi-swarm-coevolutive" \
|
||||
org.opencontainers.image.version="0.1.0" \
|
||||
org.opencontainers.image.source="https://git.tielogic.xyz/Adriano/Multi_Swarm_Coevolutive"
|
||||
|
||||
@@ -43,10 +45,10 @@ RUN useradd -m -u 1000 app \
|
||||
&& chown -R app:app /app
|
||||
USER app
|
||||
|
||||
# Healthcheck di default: import del package — i servizi reali lo
|
||||
# sovrascrivono nel compose (streamlit /_stcore/health).
|
||||
# Healthcheck di default: import dei due package del workspace.
|
||||
# I servizi reali lo sovrascrivono nel compose (es. NiceGUI HTTP).
|
||||
HEALTHCHECK --interval=60s --timeout=5s --retries=3 --start-period=10s \
|
||||
CMD python -c "import multi_swarm" || exit 1
|
||||
CMD python -c "import multi_swarm_core, strategy_crypto" || exit 1
|
||||
|
||||
# Nessun CMD di default: il compose specifica entrypoint/command
|
||||
# per ognuno dei due servizi.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Multi_Swarm_Coevolutive
|
||||
|
||||
Proof-of-concept di sistema co-evolutivo multi-agente per trading quantitativo. Un genetic algorithm fa evolvere una popolazione di agenti LLM (Hypothesis swarm) che generano strategie di trading espresse in JSON strutturato; un layer Falsification deterministico le backtesta su dati storici (default BTC-PERPETUAL Deribit) via Cerbero MCP; un layer Adversarial euristico le sottopone a red-team checks; la fitness combina Deflated Sharpe Ratio (Bailey & López 2014), Sharpe normalizzato e penalizzazione di drawdown, con opzioni v2 soft-kill e combined IS/OOS per Walk-Forward Validation. Il tutto è ispirato alla filosofia di Renaissance Technologies adattata a un contesto retail single-author con LLM agents.
|
||||
Proof-of-concept di sistema co-evolutivo multi-agente per trading quantitativo. Un genetic algorithm fa evolvere una popolazione di agenti LLM (Hypothesis swarm) che generano strategie di trading espresse in JSON strutturato; un layer Falsification deterministico le backtesta su dati storici (default BTC-PERPETUAL Deribit) via Cerbero MCP; un layer Adversarial euristico le sottopone a red-team checks; la fitness combina Deflated Sharpe Ratio (Bailey & López 2014), Sharpe normalizzato e penalizzazione di drawdown, con opzioni v2 soft-kill e combined IS/OOS per Walk-Forward Validation.
|
||||
|
||||
## Repository
|
||||
|
||||
@@ -10,99 +10,62 @@ Gitea Tielogic (privato, accesso SSH):
|
||||
git clone ssh://git@git.tielogic.xyz:222/Adriano/Multi_Swarm_Coevolutive.git
|
||||
```
|
||||
|
||||
## Layout monorepo (uv workspace)
|
||||
|
||||
Il repo è un **workspace uv** con due member packages indipendenti:
|
||||
|
||||
```
|
||||
multi_swarm_coevolutive/ repo root (workspace coordinator)
|
||||
├── pyproject.toml workspace + dev deps + ruff/mypy/pytest
|
||||
├── docker-compose.yml strategy-crypto-paper + strategy-crypto-gui
|
||||
├── Dockerfile immagine multi-swarm-coevolutive:dev
|
||||
├── uv.lock lock unico del workspace
|
||||
├── data/, series/, state/ cache OHLCV + DB (runtime, gitignored)
|
||||
├── scripts/ CLI entrypoints (run_phase1, run_paper_trading, ...)
|
||||
└── src/
|
||||
├── multi_swarm_core/ WORKSPACE MEMBER (wheel: multi-swarm-core)
|
||||
│ ├── pyproject.toml deps: pandas, numpy, openai, pydantic, ...
|
||||
│ ├── multi_swarm_core/ GA + genome + protocol + backtest + cerbero +
|
||||
│ │ data + llm + agents + ga + orchestrator +
|
||||
│ │ metrics + persistence + config
|
||||
│ ├── tests/ unit + integration (182 test)
|
||||
│ └── docs/ design/ + decisions/ + reports/
|
||||
│
|
||||
└── strategy_crypto/ WORKSPACE MEMBER (wheel: strategy-crypto)
|
||||
├── pyproject.toml deps: multi-swarm-core (workspace) + nicegui + plotly
|
||||
├── README.md overview strategia + pattern per nuove strategie
|
||||
├── strategy_crypto/
|
||||
│ ├── backend/ paper-trading (executor, portfolio, persistence, schema)
|
||||
│ ├── frontend/ NiceGUI dashboard dual-DB
|
||||
│ └── strategies/ JSON freezate (btc_*.json, eth_*.json)
|
||||
└── tests/ smoke regression (import + json + schema)
|
||||
```
|
||||
|
||||
**DB separati per dominio:** `state/runs.db` (GA core universale) + `state/strategy_crypto.db` (paper della strategia crypto). Pattern scala a N strategie senza naming collision.
|
||||
|
||||
**Pattern N strategie future:** aggiungere `src/strategy_<asset>/` con lo stesso scheletro (`backend/`, `frontend/`, `strategies/`, `tests/`), DB dedicato `state/strategy_<asset>.db`, servizi Docker `strategy-<asset>-paper` + `strategy-<asset>-gui`, GUI su `/strategy_<asset>_gui`.
|
||||
|
||||
## Stato del progetto
|
||||
|
||||
**Phase 3 (paper-trading forward-test) in corso** dal 13 maggio 2026 su VPS. Runner `scripts/run_paper_trading.py` live 24/7 in Docker (`https://swarm.tielogic.xyz` per la dashboard) con due strategie freezate:
|
||||
**Phase 3 (paper-trading forward-test) in corso** dal 13 maggio 2026 su VPS. Runner `scripts/run_paper_trading.py` long-running in Docker, dashboard NiceGUI su `https://swarm.tielogic.xyz/strategy_crypto_gui/`. Due strategie freezate:
|
||||
|
||||
- `strategies/btc_fb63e851.json` — BTC-PERPETUAL, true alpha hour-gated (RSI estremi + ATR vs SMA + filtro orario 9-17), Sharpe OOS +0,26 su 7,33 anni di storia.
|
||||
- `strategies/eth_facd6af85d5d.json` — ETH-PERPETUAL, trend-following long-bias + vol regime, Sharpe OOS +0,19 su 6,75 anni.
|
||||
- `strategy_crypto/strategies/btc_fb63e851.json` — BTC-PERPETUAL, RSI estremi + ATR vs SMA + filtro orario 9-17 (Sharpe OOS +0,26 su 7,33 anni).
|
||||
- `strategy_crypto/strategies/eth_facd6af85d5d.json` — ETH-PERPETUAL, regime-based (Sharpe OOS +0,19 su 6,75 anni).
|
||||
|
||||
Phase 1 → 2.7 tutte chiuse (30 run GA, $3.74 cumulato LLM, cap originale $700 → margine 99%+). Vedi il documento di sintesi consolidato per il dettaglio:
|
||||
Phase 1 → 2.7 chiuse (30 run GA, $3.74 cumulato LLM).
|
||||
|
||||
- [**Stato progetto e roadmap (14 maggio 2026)**](docs/reports/2026-05-14-stato-progetto-e-roadmap.md) — riepilogo di tutte le fasi, decisioni, caveat aperti, roadmap.
|
||||
- [**Stato progetto e roadmap (14 maggio 2026)**](src/multi_swarm_core/docs/reports/2026-05-14-stato-progetto-e-roadmap.md) — riepilogo fasi, decisioni, caveat, roadmap.
|
||||
- Decision log: [`src/multi_swarm_core/docs/decisions/`](src/multi_swarm_core/docs/decisions/) (gate Phase 1, scelta nemotron).
|
||||
- Design docs concettuali: [`src/multi_swarm_core/docs/design/`](src/multi_swarm_core/docs/design/).
|
||||
|
||||
Documenti chiave per fase:
|
||||
|
||||
- [Decisione strategica](docs/superpowers/specs/2026-05-09-decisione-strategica-design.md) — perché Phase 1 prima, Phase 2 poi, Phase 3 forward-test.
|
||||
- [Decision memo gate Phase 1](docs/decisions/2026-05-10-gate-phase1.md), [Technical report Phase 1](docs/reports/2026-05-10-phase1-technical-report.md), [Decision memo Phase 1.5 nemotron](docs/decisions/2026-05-11-phase1-5-nemotron-run.md).
|
||||
- [Piano Phase 2.5 prompt-mutator](docs/superpowers/plans/2026-05-11-mutate-prompt-llm-phase-2-5.md), [Piano feature temporali](docs/superpowers/plans/2026-05-11-temporal-features.md).
|
||||
|
||||
Documenti di contesto pre-implementazione: `00_documento_zero.md` (framework concettuale Renaissance → swarm), `coevolutive_swarm_system.md` (Filone A, sistema completo), `poc_trading_swarm.md` (Filone B, PoC trading).
|
||||
|
||||
## Architettura
|
||||
|
||||
```
|
||||
src/multi_swarm/
|
||||
├── config.py Settings Pydantic (.env)
|
||||
├── data/
|
||||
│ ├── cerbero_ohlcv.py OHLCV loader via Cerbero MCP + cache parquet
|
||||
│ └── splits.py Walk-forward expanding splits (Phase 2.6)
|
||||
├── backtest/
|
||||
│ ├── orders.py Side/Order/Position/Trade
|
||||
│ └── engine.py Event-driven backtest, 1-bar exec delay
|
||||
├── metrics/
|
||||
│ ├── basic.py Sharpe, max drawdown, total return
|
||||
│ ├── dsr.py Deflated Sharpe Ratio (Bailey & López 2014)
|
||||
│ └── diversity.py Entropy/diversity metrics popolazione (Phase 2.5)
|
||||
├── cerbero/
|
||||
│ ├── client.py HTTP client (bearer + bot-tag + retry tenacity)
|
||||
│ └── tools.py Wrapper tool MCP (sma/rsi/atr/macd/realized_vol/funding)
|
||||
├── protocol/
|
||||
│ ├── grammar.py Vocabolario operatori, indicatori, feature (incl. hour/dow/is_weekend)
|
||||
│ ├── parser.py json.loads → AST dataclass tipizzato
|
||||
│ ├── validator.py Arity checks, no-nesting indicators, whitelist
|
||||
│ └── compiler.py AST → Callable[[df], Series[Side]]
|
||||
├── genome/
|
||||
│ ├── hypothesis.py HypothesisAgentGenome (id deterministico)
|
||||
│ ├── mutation.py 4 operatori scalari (temp, lookback, features, style)
|
||||
│ ├── mutation_prompt_llm.py 5° operatore: riscrittura system_prompt via LLM tier B
|
||||
│ └── crossover.py Uniform crossover
|
||||
├── llm/
|
||||
│ ├── client.py Unified LLMClient via OpenRouter (tier S/A/B/C/D)
|
||||
│ └── cost_tracker.py Pricing per tier, breakdown + call_kind tracking
|
||||
├── agents/
|
||||
│ ├── hypothesis.py LLM call + JSON extract + retry-with-feedback
|
||||
│ ├── falsification.py Compile → backtest → DSR
|
||||
│ ├── adversarial.py Red-team heuristics (5 check HIGH parametrici via CLI)
|
||||
│ └── market_summary.py Stats di mercato per il prompt
|
||||
├── ga/
|
||||
│ ├── selection.py Tournament + elitism
|
||||
│ ├── fitness.py v1 continua + v2 soft-kill + combined IS/OOS opt-in
|
||||
│ ├── loop.py next_generation step
|
||||
│ ├── summary.py median/max/p90/entropy per gen
|
||||
│ └── initial.py Popolazione iniziale (6 cognitive style)
|
||||
├── persistence/
|
||||
│ ├── schema.py SQLite DDL: 6 tabelle GA + 5 tabelle paper_trading_*
|
||||
│ └── repository.py CRUD per runs/genomes/evals/cost/findings/gen_summary
|
||||
├── paper_trading/ Phase 3
|
||||
│ ├── portfolio.py Multi-asset portfolio con sleeve uguali per asset
|
||||
│ ├── executor.py PaperExecutor: carica strategia JSON, valuta ultimo bar
|
||||
│ └── persistence.py PaperRepository (paper_trading_runs/ticks/equity/trades/positions)
|
||||
├── orchestrator/
|
||||
│ └── run.py End-to-end pipeline GA + persistence
|
||||
└── dashboard/
|
||||
├── nicegui_app.py NiceGUI dashboard (overview / convergence / genomes)
|
||||
└── data.py Lettura runs.db per le pagine
|
||||
```
|
||||
|
||||
Stack: Python 3.13, uv, pytest+pytest-mock+responses, openai SDK (verso OpenRouter), requests+tenacity, pandas+numpy+scipy, sqlmodel+sqlite, nicegui+plotly, yfinance (test cross-asset non-crypto).
|
||||
|
||||
CLI knobs accumulati (Phase 2.5 → 2.7):
|
||||
|
||||
- `--prompt-mutation-weight FLOAT` (peso del 5° operatore, sweet spot 0.20-0.30)
|
||||
- `--fees-eat-alpha-threshold FLOAT` (default 0.5, suggerito 0.7)
|
||||
- `--flat-too-long-threshold FLOAT` (default 0.95)
|
||||
- `--undertrading-threshold INT` (default 20)
|
||||
- `--fitness-v2` + `--fitness-soft-penalty FLOAT`
|
||||
- `--fitness-combined-alpha FLOAT` (multi-obiettivo IS/OOS)
|
||||
- `--min-trades-threshold INT` (filtro OOS in WFA)
|
||||
Stack: Python 3.13, uv workspace, hatchling, pytest+pytest-mock+responses, openai SDK (verso OpenRouter), requests+tenacity, pandas+numpy+scipy, sqlmodel+sqlite, nicegui+plotly, yfinance.
|
||||
|
||||
## Setup
|
||||
|
||||
```bash
|
||||
uv sync
|
||||
cp .env.example .env # compilare CERBERO_*_TOKEN e OPENROUTER_API_KEY
|
||||
uv run pytest # ~180 test attesi (unit + integration)
|
||||
uv sync # installa entrambi i workspace member come editable
|
||||
cp .env.example .env # compila CERBERO_*_TOKEN e OPENROUTER_API_KEY
|
||||
uv run pytest # 186 test attesi (182 core + 4 smoke strategy_crypto)
|
||||
```
|
||||
|
||||
### Variabili .env richieste
|
||||
@@ -116,36 +79,27 @@ CERBERO_BOT_TAG=swarm-poc-phase1
|
||||
|
||||
# LLM provider (unico endpoint via OpenRouter)
|
||||
OPENROUTER_API_KEY=<sk-or-v1-...>
|
||||
OPENROUTER_BASE_URL=https://openrouter.ai/api/v1
|
||||
|
||||
# Modelli per tier (default Phase 2.5+: qwen-2.5-72b per tier C, vedi .env.example per gli altri)
|
||||
LLM_MODEL_TIER_C=qwen/qwen-2.5-72b-instruct
|
||||
# DB paths (split per dominio: core GA vs paper della strategia)
|
||||
GA_DB_PATH=./state/runs.db
|
||||
STRATEGY_CRYPTO_DB_PATH=./state/strategy_crypto.db
|
||||
|
||||
# Deploy Docker (vedi sezione Deploy)
|
||||
# Deploy Docker
|
||||
DOMAIN_NAME=tielogic.xyz
|
||||
SWARM_DASHBOARD_PORT=8080
|
||||
DASHBOARD_ROOT_PATH=/strategy_crypto_gui # subpath traefik per la dashboard
|
||||
```
|
||||
|
||||
### Cerbero MCP
|
||||
|
||||
Tutti i fetch OHLCV passano da Cerbero MCP (sostituisce ccxt). In sviluppo locale:
|
||||
|
||||
```bash
|
||||
cd /home/adriano/Documenti/Git_XYZ/CerberoSuite/Cerbero_mcp
|
||||
uv sync
|
||||
uv run cerbero-mcp # ascolta su porta da .env (default 9001 se 9000 è occupato)
|
||||
```
|
||||
|
||||
In produzione/integrazione: VPS `https://cerbero-mcp.tielogic.xyz` (richiede bearer) — o internal docker `http://cerbero-mcp:9000` se si gira nella stessa rete Traefik.
|
||||
Backcompat: `DB_PATH` legacy continua a funzionare come alias di `GA_DB_PATH`.
|
||||
|
||||
## Comandi principali
|
||||
|
||||
```bash
|
||||
# Quality gates
|
||||
uv run pytest # tutti i test
|
||||
uv run pytest tests/unit -v # solo unit
|
||||
uv run pytest tests/integration -v # solo integration (richiedono Cerbero + OpenRouter)
|
||||
uv run ruff check src/ tests/ scripts/
|
||||
uv run pytest # tutti i test
|
||||
uv run pytest src/multi_swarm_core/tests/unit -v # solo unit core
|
||||
uv run pytest src/strategy_crypto/tests/ -v # smoke strategy_crypto
|
||||
uv run ruff check src/ scripts/
|
||||
uv run mypy src/ scripts/
|
||||
|
||||
# Smoke run (MockLLM + OHLCV sintetico, no API calls)
|
||||
@@ -160,67 +114,56 @@ uv run python scripts/run_phase1.py \
|
||||
--population-size 20 --n-generations 10 \
|
||||
--prompt-mutation-weight 0.30 --fitness-v2
|
||||
|
||||
# Backtest standalone di una strategia JSON su range esteso
|
||||
# Backtest standalone di una strategia JSON
|
||||
uv run python scripts/backtest_strategy.py \
|
||||
--strategy strategies/btc_fb63e851.json \
|
||||
--strategy src/strategy_crypto/strategy_crypto/strategies/btc_fb63e851.json \
|
||||
--start 2018-09-01 --end 2026-01-01
|
||||
|
||||
# Paper-trading forward-test (Phase 3)
|
||||
uv run python scripts/run_paper_trading.py \
|
||||
--name phase3-papertrade-XXX \
|
||||
--initial-capital 1000 --poll-seconds 300
|
||||
# Default --strategies-dir: importlib.resources del package strategy_crypto
|
||||
|
||||
# Dashboard NiceGUI locale
|
||||
DB_PATH=./runs.db uv run python -m multi_swarm.dashboard.nicegui_app
|
||||
uv run python -m strategy_crypto.frontend.nicegui_app
|
||||
# → http://localhost:8080 (env SWARM_DASHBOARD_PORT)
|
||||
```
|
||||
|
||||
## Dashboard
|
||||
|
||||
NiceGUI dashboard (dark/neon palette) su `http://localhost:8080` (override con env `SWARM_DASHBOARD_PORT`):
|
||||
NiceGUI dashboard (dark palette) — **dual-DB reader** (GA + paper):
|
||||
|
||||
- **Overview** (`/`): lista runs, status, costo, metriche aggregate evaluations (parse success %, top fitness, median).
|
||||
- **GA Convergence** (`/convergence`): fitness median/max/p90 per generazione, entropy con hline a soglia gate (0.5).
|
||||
- **Genomes** (`/genomes`): top-K ordinati per fitness, click su riga per ispezione system_prompt + raw_text JSON strategy.
|
||||
- **Overview** (`/`): lista runs GA, costo cumulato, metriche aggregate evaluations.
|
||||
- **GA Convergence** (`/convergence`): fitness median/max/p90 per generazione + entropy.
|
||||
- **Genomes** (`/genomes`): top-K ordinati per fitness, ispezione system_prompt + JSON strategy.
|
||||
- **Paper** (`/paper`): forward-test live con equity curve, posizioni aperte, trade list, tick log.
|
||||
|
||||
In produzione gira dentro Docker dietro Traefik su `https://swarm.${DOMAIN_NAME}` — vedi sezione Deploy.
|
||||
In produzione su `https://swarm.tielogic.xyz/strategy_crypto_gui/` (subpath gestito via `DASHBOARD_ROOT_PATH` + Traefik PathPrefix). La root del dominio resta libera per future GUI di altre strategie.
|
||||
|
||||
## Deploy
|
||||
|
||||
`docker-compose.yml` definisce due servizi che condividono la stessa immagine `multi-swarm:dev`:
|
||||
`docker-compose.yml` definisce due servizi su immagine `multi-swarm-coevolutive:dev`:
|
||||
|
||||
- **`multi-swarm-paper`** — runner `scripts/run_paper_trading.py` long-running (`restart: unless-stopped`).
|
||||
- **`multi-swarm-dashboard`** — NiceGUI esposta via Traefik su `https://swarm.${DOMAIN_NAME}`.
|
||||
- **`strategy-crypto-paper`** — runner `scripts/run_paper_trading.py` long-running.
|
||||
- **`strategy-crypto-gui`** — NiceGUI dashboard dietro Traefik su `https://swarm.${DOMAIN_NAME}/strategy_crypto_gui/`.
|
||||
|
||||
Entrambi joinano la rete external `traefik` per parlare direttamente con `cerbero-mcp:9000` senza giro pubblico+TLS. Persistenza via bind mount:
|
||||
|
||||
- `./data/`, `./series/` — cache OHLCV (parquet)
|
||||
- `./state/` — `runs.db` (+ WAL/SHM)
|
||||
- `./strategies/` — `btc_*.json` / `eth_*.json` (read-only nel container)
|
||||
|
||||
Bring-up:
|
||||
Persistenza via bind mount: `./data/`, `./series/`, `./state/`. Le strategie JSON sono bind-mounted in read-only dal package: `./src/strategy_crypto/strategy_crypto/strategies/`.
|
||||
|
||||
```bash
|
||||
docker compose up -d --build
|
||||
docker compose logs -f multi-swarm-paper # segui i tick
|
||||
docker compose ps # stato
|
||||
docker compose logs -f strategy-crypto-paper
|
||||
docker compose ps
|
||||
```
|
||||
|
||||
Note operative:
|
||||
|
||||
- Le bind-mount dir devono essere `chown 1000:1000` (uid utente `app` nel container).
|
||||
- Override del command paper-trading via env (`PAPER_RUN_NAME`, `PAPER_INITIAL_CAPITAL`, `PAPER_POLL_SECONDS`, ecc.) — vedi `.env.example`.
|
||||
- `SWARM_DASHBOARD_PORT` controlla la porta interna del container (Traefik fa il TLS davanti).
|
||||
|
||||
## Costi
|
||||
|
||||
Costo cumulato LLM progetto a oggi: **≈ $3.74** su 30 run GA (Phase 1 → 2.7). Cap originale Phase 1: $700 → margine residuo abbondante.
|
||||
|
||||
- Tier C (qwen-2.5-72b via OpenRouter): ~$0.40/1M token.
|
||||
- Run base K=20 × 10gen ≈ $0.07. Con `--prompt-mutation-weight 0.30` overhead mutator 3-9%.
|
||||
- **Phase 3 paper-trading**: $0 incrementali LLM (strategie fisse), solo costi Cerbero (servizio esistente).
|
||||
- Override del command paper via env (`PAPER_RUN_NAME`, `PAPER_INITIAL_CAPITAL`, ecc.).
|
||||
- `SWARM_DASHBOARD_PORT` controlla la porta interna del container (Traefik fa il TLS).
|
||||
|
||||
## Sviluppo
|
||||
|
||||
Conventional commits con prefix `feat:` `fix:` `chore:` `docs:` `refactor:` `test:`. Body italiano. Footer `Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>` su ogni commit collaborativo.
|
||||
|
||||
Branch attuale: `main`. Single-author retail R&D, nessun feature branch attivo. Ablation paralleli si gestiscono via CLI knobs sullo stesso branch.
|
||||
Branch attuale: `main`. Workspace single-repo, monorepo unificato dal 15 maggio 2026 (split temporaneo monorepo→figlio invertito, vedi tag `v0.1.0-pre-split` come bookmark).
|
||||
|
||||
+32
-26
@@ -1,25 +1,27 @@
|
||||
# docker-compose.yml — Multi-Swarm Coevolutive
|
||||
#
|
||||
# Due servizi che condividono la stessa immagine `multi-swarm:dev`:
|
||||
# Due servizi della strategia crypto, condividono la stessa immagine
|
||||
# `multi-swarm-coevolutive:dev` buildata dal Dockerfile root (uv workspace):
|
||||
#
|
||||
# * multi-swarm-paper — paper-trading runner long-running
|
||||
# (scripts/run_paper_trading.py)
|
||||
# * multi-swarm-dashboard — Streamlit dashboard esposta da Traefik
|
||||
# su https://swarm.${DOMAIN_NAME:-tielogic.xyz}
|
||||
# * strategy-crypto-paper — paper-trading runner long-running
|
||||
# (scripts/run_paper_trading.py)
|
||||
# * strategy-crypto-gui — NiceGUI dashboard esposta da Traefik su
|
||||
# https://swarm.${DOMAIN_NAME:-tielogic.xyz}/strategy_crypto_gui
|
||||
#
|
||||
# Entrambi joinano la rete external `traefik` cosi' il client Cerbero
|
||||
# risolve direttamente l'host `cerbero-mcp` (porta 9000) senza passare
|
||||
# dal gateway pubblico ne' dal TLS.
|
||||
#
|
||||
# Pattern N strategie future: aggiungere strategy-<asset>-paper + strategy-<asset>-gui
|
||||
# con PathPrefix(/strategy_<asset>_gui) e DASHBOARD_ROOT_PATH dedicato.
|
||||
#
|
||||
# Dati persistenti via bind mount dalla cartella del repo:
|
||||
# ./data cache OHLCV intermedia
|
||||
# ./series cache parquet per timeframe/symbol
|
||||
# ./state contiene runs.db (+ WAL/SHM)
|
||||
# ./strategies btc_*.json / eth_*.json letti dal paper runner
|
||||
# ./data cache OHLCV intermedia
|
||||
# ./series cache parquet per timeframe/symbol
|
||||
# ./state contiene runs.db (GA) + strategy_crypto.db (paper) + WAL/SHM
|
||||
# ./src/strategy_crypto/strategy_crypto/strategies JSON freezate (ro)
|
||||
#
|
||||
# Secrets (token Cerbero + OpenRouter): caricati da .env via env_file.
|
||||
# Le variabili sotto `environment:` sovrascrivono solo i valori che
|
||||
# devono cambiare dentro il container (URL interno, path container).
|
||||
|
||||
networks:
|
||||
traefik:
|
||||
@@ -31,15 +33,19 @@ x-swarm-env: &swarm-env
|
||||
# Override: path container per persistenza
|
||||
DATA_DIR: /app/data
|
||||
SERIES_DIR: /app/series
|
||||
DB_PATH: /app/state/runs.db
|
||||
# DB separati per dominio:
|
||||
GA_DB_PATH: /app/state/runs.db
|
||||
STRATEGY_CRYPTO_DB_PATH: /app/state/strategy_crypto.db
|
||||
# Subpath sotto cui la dashboard NiceGUI e' esposta da Traefik
|
||||
DASHBOARD_ROOT_PATH: /strategy_crypto_gui
|
||||
|
||||
services:
|
||||
multi-swarm-paper:
|
||||
strategy-crypto-paper:
|
||||
build:
|
||||
context: .
|
||||
dockerfile: Dockerfile
|
||||
image: multi-swarm:dev
|
||||
container_name: multi-swarm-paper
|
||||
image: multi-swarm-coevolutive:dev
|
||||
container_name: strategy-crypto-paper
|
||||
restart: unless-stopped
|
||||
networks: [traefik]
|
||||
env_file: .env
|
||||
@@ -49,7 +55,7 @@ services:
|
||||
- ./data:/app/data
|
||||
- ./series:/app/series
|
||||
- ./state:/app/state
|
||||
- ./strategies:/app/strategies:ro
|
||||
- ./src/strategy_crypto/strategy_crypto/strategies:/app/strategies:ro
|
||||
# Niente HTTP da controllare: ci affidiamo a `restart: unless-stopped`
|
||||
# e ai log per la liveness del runner.
|
||||
command:
|
||||
@@ -64,26 +70,26 @@ services:
|
||||
labels:
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
|
||||
multi-swarm-dashboard:
|
||||
image: multi-swarm:dev
|
||||
strategy-crypto-gui:
|
||||
image: multi-swarm-coevolutive:dev
|
||||
build:
|
||||
context: .
|
||||
dockerfile: Dockerfile
|
||||
container_name: multi-swarm-dashboard
|
||||
container_name: strategy-crypto-gui
|
||||
restart: unless-stopped
|
||||
networks: [traefik]
|
||||
env_file: .env
|
||||
environment:
|
||||
<<: *swarm-env
|
||||
volumes:
|
||||
# Dashboard legge solo runs.db: mount in read-only
|
||||
# Dashboard legge entrambi i DB: state/ in read-only (WAL: vedi nota)
|
||||
- ./state:/app/state:ro
|
||||
- ./data:/app/data:ro
|
||||
- ./series:/app/series:ro
|
||||
entrypoint:
|
||||
- python
|
||||
- -m
|
||||
- multi_swarm.dashboard.nicegui_app
|
||||
- strategy_crypto.frontend.nicegui_app
|
||||
command: []
|
||||
healthcheck:
|
||||
test:
|
||||
@@ -98,9 +104,9 @@ services:
|
||||
labels:
|
||||
- traefik.enable=true
|
||||
- traefik.docker.network=traefik
|
||||
- "traefik.http.routers.multi-swarm-dashboard.rule=Host(`swarm.${DOMAIN_NAME:-tielogic.xyz}`)"
|
||||
- traefik.http.routers.multi-swarm-dashboard.tls=true
|
||||
- traefik.http.routers.multi-swarm-dashboard.entrypoints=websecure
|
||||
- traefik.http.routers.multi-swarm-dashboard.tls.certresolver=mytlschallenge
|
||||
- "traefik.http.services.multi-swarm-dashboard.loadbalancer.server.port=${SWARM_DASHBOARD_PORT:-8080}"
|
||||
- "traefik.http.routers.strategy-crypto-gui.rule=Host(`swarm.${DOMAIN_NAME:-tielogic.xyz}`) && PathPrefix(`/strategy_crypto_gui`)"
|
||||
- traefik.http.routers.strategy-crypto-gui.tls=true
|
||||
- traefik.http.routers.strategy-crypto-gui.entrypoints=websecure
|
||||
- traefik.http.routers.strategy-crypto-gui.tls.certresolver=mytlschallenge
|
||||
- "traefik.http.services.strategy-crypto-gui.loadbalancer.server.port=${SWARM_DASHBOARD_PORT:-8080}"
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
|
||||
@@ -1,282 +0,0 @@
|
||||
# Phase 1 Lean Spike — Rapporto Tecnico
|
||||
|
||||
**Autore**: Adriano Dal Pastro
|
||||
**Data**: 10 maggio 2026
|
||||
**Versione**: 1.0 (finalizzato)
|
||||
**Status**: ✅ Phase 1 chiusa, tutti 5 hard gate passati
|
||||
|
||||
**Documenti correlati**:
|
||||
- `docs/superpowers/specs/2026-05-09-decisione-strategica-design.md` (decisione strategica B3)
|
||||
- `docs/superpowers/plans/2026-05-09-phase1-lean-spike.md` (piano implementativo)
|
||||
- `docs/decisions/2026-05-10-gate-phase1.md` (decision memo finale)
|
||||
|
||||
---
|
||||
|
||||
## 1. Setup sperimentale
|
||||
|
||||
L'obiettivo della Phase 1 lean spike è dimostrare che il loop tecnico (LLM hypothesis → backtest falsification → adversarial check → GA selection) funziona end-to-end e produce output formalizzabile. I cinque hard gate definiti nello spec sez. 4.4 misurano feasibility, non alpha edge — quella è valutazione di Phase 2.
|
||||
|
||||
### 1.1 Configurazione del run di riferimento
|
||||
|
||||
Il run `phase1-real-005` (id `1c526996160446b18c0fb57d94874975`) è il primo a superare tutti i gate dopo 4 iterazioni di bug-fix (vedi sez. 3 del decision memo).
|
||||
|
||||
| Parametro | Valore |
|
||||
|---|---|
|
||||
| Population size (K) | 20 |
|
||||
| Generazioni | 10 |
|
||||
| Elite k | 2 |
|
||||
| Tournament k | 3 |
|
||||
| Crossover probability | 0.5 |
|
||||
| Random seed | 42 |
|
||||
| Symbol | BTC-PERPETUAL (Deribit) |
|
||||
| Timeframe | 1h |
|
||||
| Range storico | 2024-01-01 → 2026-01-01 (2 anni, 17545 candele) |
|
||||
| Fees backtest | 5 basis points |
|
||||
| n_trials_dsr | 50 |
|
||||
| Tier LLM dominante | C (qwen3-235b-a22b-2507 via OpenRouter) |
|
||||
| Cerbero MCP endpoint | http://localhost:9001 (locale) |
|
||||
| Durata wall-clock | 29 minuti |
|
||||
| Costo LLM | $0.069 |
|
||||
|
||||
### 1.2 Stack tecnologico
|
||||
|
||||
Python 3.13, uv 0.10.9. Test framework: pytest + pytest-mock + responses. Persistence: sqlite3 + sqlmodel. Parsing strategia: `json.loads` con dataclass-based AST. Analytics: pandas + numpy + scipy. LLM: openai SDK con base URL OpenRouter (route unica per tutti i tier S/A/B/C/D). HTTP: requests + tenacity. Dashboard: streamlit + plotly + canvas HTML5 custom.
|
||||
|
||||
### 1.3 Architettura del run
|
||||
|
||||
L'orchestrator (`src/multi_swarm/orchestrator/run.py`, 184 righe) coordina la pipeline end-to-end:
|
||||
|
||||
1. **OHLCV loading**: `CerberoOHLCVLoader` chiama `mcp-deribit/tools/get_historical` paginando in chunk da 4500 barre (cap soft Deribit ~5000). Cache parquet su sha1 della query — il run v5 ha riusato cache popolata dai run precedenti, fetch istantaneo.
|
||||
2. **Market summary**: statistiche return (mean, std, skew, kurt) + classificazione regime volatilità.
|
||||
3. **Initial population**: 20 genomi distribuiti uniformemente sui 6 cognitive style (physicist, biologist, historian, meteorologist, ecologist, engineer), temperature random in [0.7, 1.2], lookback random in {100, 150, 200, 300}.
|
||||
4. **Per ogni generazione (10 totali)**:
|
||||
- **Hypothesis**: chiamata LLM con prompt SYSTEM (regole grammar) + USER (market summary). Output JSON estratto via regex fence ```json. Se parse/validation fallisce: retry 1x con error message nel prompt utente.
|
||||
- **Falsification**: AST compilato in `Callable[[df], Series[Side]]`, backtest event-driven con 1-bar exec delay, calcolo Sharpe + Deflated Sharpe (Bailey & López 2014, n_trials=50).
|
||||
- **Adversarial**: 4 check euristici (no_trades, degenerate, overtrading, undertrading).
|
||||
- **Fitness**: `0.5*dsr + 0.25*(tanh(sharpe)+1)` × `1/(1+max_dd)`, range [0, ~1]. Kill (=0) su zero trade o HIGH adversarial finding.
|
||||
- **Next generation**: elitism 2 + tournament 3 + 50% crossover / 50% mutation.
|
||||
5. **Persistence SQLite**: ogni genome, evaluation, cost_record, adversarial_finding, generation summary persistito con indici per query rapide della dashboard.
|
||||
|
||||
### 1.4 Caveat metodologici noti
|
||||
|
||||
- **In-sample**: il backtest in Phase 1 lean spike non usa walk-forward; tutto il range 2024-2026 viene usato sia per la generazione delle ipotesi sia per la loro valutazione. La sopravvivenza out-of-sample è esplicitamente fuori scope di Phase 1 (gate Phase 2 #2).
|
||||
- **Compiler con indicatori built-in**: il compiler JSON-based (`src/multi_swarm/protocol/compiler.py`) calcola RSI, SMA, ATR, MACD, realized_vol localmente con pandas. `CerberoTools` è plumbed ma non chiamato durante l'esecuzione delle strategie — è disponibile per agenti future-tense ma il fitness Phase 1 dipende solo dagli indicatori locali.
|
||||
- **RSI epsilon-floor**: il compiler ha un epsilon sul `roll_down` per evitare RSI=100 esatto su serie monotonicamente crescenti (artefatto matematico irrilevante su dati reali ma documentato).
|
||||
- **Top-1 strategia con DSR marginale**: vedi sez. 3.
|
||||
|
||||
---
|
||||
|
||||
## 2. Loop convergence
|
||||
|
||||
### 2.1 Fitness per generazione
|
||||
|
||||
| Gen | Median | Max | P90 | Entropy |
|
||||
|---|---|---|---|---|
|
||||
| 0 | 0.0001 | 0.0601 | 0.0165 | 0.588 |
|
||||
| 1 | 0.0042 | 0.1893 | 0.0731 | 1.261 |
|
||||
| 2 | 0.0188 | 0.3347 | 0.2039 | 1.333 |
|
||||
| 3 | 0.0069 | 0.3347 | 0.3347 | 1.347 |
|
||||
| 4 | 0.0910 | 0.3347 | 0.3347 | 1.415 |
|
||||
| 5 | 0.0016 | 0.3347 | 0.3347 | 0.611 |
|
||||
| 6 | 0.0040 | 0.3347 | 0.3347 | 0.886 |
|
||||
| 7 | 0.0151 | 0.3347 | 0.3347 | 0.982 |
|
||||
| 8 | 0.0066 | 0.3347 | 0.3347 | 0.746 |
|
||||
| 9 | 0.0061 | 0.3347 | 0.3347 | 0.914 |
|
||||
|
||||
### 2.2 Lettura
|
||||
|
||||
**Convergenza tre-step iniziale**: gen 0→1→2 mostra crescita mediana 4x-50x (0.0001 → 0.0042 → 0.0188) e crescita max 3x-6x (0.06 → 0.19 → 0.33). Gate 1 PASS su questa finestra.
|
||||
|
||||
**Plateau dell'elite da gen 2**: max stabile a 0.3347 per le restanti 7 generazioni — comportamento atteso con `elite_k=2` che preserva il top performer attraverso le generazioni. P90 si allinea al max da gen 3, segno che almeno 2 elite mantengono la top fitness.
|
||||
|
||||
**Median oscillante**: dopo il picco a gen 4 (0.091), la median fluttua fra 0.0016 e 0.0151 nelle generazioni successive. Causa: turnover stocastico della popolazione (mutation + crossover) introduce genomi nuovi, alcuni dei quali parse correctly ma falliscono Adversarial (no_trades) e si attestano a fitness 0, abbassando la median. Non è regressione strutturale del GA.
|
||||
|
||||
**Entropy**: oscilla 0.6-1.4 dopo gen 0, sempre sopra soglia 0.5 → diversità di fitness preservata anche durante plateau dell'elite.
|
||||
|
||||
---
|
||||
|
||||
## 3. Top-5 genomi: ispezione qualitativa
|
||||
|
||||
| Rank | Genome ID | Gen | Style | Fitness | DSR | Sharpe | Max DD | Trades | Temp |
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
| 1 | `696052b8...` | 2 | physicist | 0.3347 | 0.0021 | 0.381 | 0.0215 | 33 | 0.68 |
|
||||
| 2 | `169376a2...` | 1 | engineer | 0.3347 | 0.0021 | 0.381 | 0.0215 | 33 | 0.78 |
|
||||
| 3 | `eb0265ad...` | 3 | ecologist | 0.2453 | 0.0006 | −0.019 | 0.0011 | 1 | 1.14 |
|
||||
| 4 | `38d4c1d9...` | 1 | engineer | 0.1893 | 0.0001 | −0.245 | 0.0028 | 1 | 0.82 |
|
||||
| 5 | `3e355975...` | 1 | physicist | 0.1893 | 0.0001 | −0.245 | 0.0028 | 1 | 0.78 |
|
||||
|
||||
### 3.1 Top-1 strategia (ispezione approfondita)
|
||||
|
||||
**System prompt** (engineer): *"Cerca segnali con rapporto S/N favorevole, filtri causali, robustezza a perturbazioni di calibrazione."*
|
||||
|
||||
**Strategia JSON** (3 regole, evaluation in ordine):
|
||||
|
||||
- **LONG**: `SMA(10) crossover SMA(30)` AND `realized_vol(20) > 0.3%` AND `RSI(14) < 45`.
|
||||
- **SHORT**: `SMA(10) crossunder SMA(30)` AND `realized_vol(20) > 0.3%` AND `RSI(14) > 55`.
|
||||
- **EXIT**: (`RSI(14) > 70` AND `close crossover SMA(50)`) OR `realized_vol(20) < 0.1%`.
|
||||
|
||||
**Lettura economica**: trend-following SMA-cross fast/slow modulato da filtro volatilità (entra solo quando il regime è abbastanza mosso, esce quando è troppo calmo) e filtro RSI come momentum confirmation (long solo se non già ipercomprato; short solo se non già ipervenduto). L'EXIT è sofisticato: esce su overbought confermato da break sopra MA50, OPPURE su collasso di volatilità.
|
||||
|
||||
**Performance**: 33 trade su 17545 candele (1 trade ogni 532 candele = 1 ogni 22 giorni). Sharpe positivo modesto, max drawdown 2.15% (basso). DSR praticamente zero (0.0021) — il segnale non è statisticamente significativo dopo correzione multiple testing, perché 33 trade su 2 anni è sample piccolo.
|
||||
|
||||
**Plausibilità**: pattern economicamente sensato, non casuale. Reminiscente di strategie trend-following classiche (Donchian, turtle-style) con filtri di regime. Lo stile cognitivo "engineer" (S/N favorable, filtri causali) si riflette nella struttura.
|
||||
|
||||
### 3.2 Top-2/3/4/5 brevemente
|
||||
|
||||
- Top-2 è una replica funzionale di Top-1 con metriche identiche. Plausibile elite duplicato o convergenza indipendente sulla stessa strategia (verifica per Phase 2: signal correlation fra duplicati).
|
||||
- Top-3, 4, 5 hanno **1 trade ciascuno** su 2 anni. Sono "lucky shot": una posizione tenuta a lungo che casualmente termina con leggera vincita. Adversarial flagga MEDIUM `undertrading` ma non HIGH, quindi sopravvivono. La fitness function continua dà loro valore non-zero perché `tanh(sharpe)` è leggermente sopra 0.5 e penalty drawdown è quasi 1.0 (max_dd <0.5%).
|
||||
|
||||
### 3.3 Ratio top-1 / median
|
||||
|
||||
Median fitness su 98 evals: 0.0003.
|
||||
Top-1 fitness: 0.3347.
|
||||
**Ratio**: 1116x — Gate 3 soddisfatto con margine drammatico (soglia 1.5x).
|
||||
|
||||
---
|
||||
|
||||
## 4. Parser failure modes
|
||||
|
||||
### 4.1 Statistiche aggregate v5
|
||||
|
||||
- Evaluations totali: 98
|
||||
- Parse success: **98 (100.0%)**
|
||||
- Parse failure: **0 (0.0%)**
|
||||
|
||||
### 4.2 Confronto con iterazioni precedenti
|
||||
|
||||
| Run | Grammar | Parse success | Note |
|
||||
|---|---|---|---|
|
||||
| v1 | S-expression | 33% | LLM nesta indicators non supportati |
|
||||
| v4 | S-expression (con arity check post-fix) | 36% | 89 di 98 errori = `indicator nested` |
|
||||
| v5 | **JSON Schema** | **100%** | Refactor commit `44eb643` |
|
||||
|
||||
Il salto da 36% a 100% deriva interamente dal cambio di grammar. JSON è natively supported dal training dei modelli LLM moderni; S-expression è esotica e induce hallucination di sintassi creative.
|
||||
|
||||
### 4.3 Retry-with-feedback (commit `d4fcb42`)
|
||||
|
||||
Il sistema accetta 1 retry con error feedback. Nel run v5 il retry **non è mai stato usato** (zero retry per parse, dato il 100% di success). Il retry rimane comunque architetturalmente presente per Phase 2 / casi edge.
|
||||
|
||||
---
|
||||
|
||||
## 5. Costi reali vs preventivo
|
||||
|
||||
### 5.1 Breakdown costi LLM v5
|
||||
|
||||
| Tier | Calls | Input tokens | Output tokens | Cost USD |
|
||||
|---|---|---|---|---|
|
||||
| C (qwen3-235b) | 113 | 112369 | 60060 | $0.069 |
|
||||
|
||||
### 5.2 Costo cumulativo Phase 1 (5 run, inclusi bug-fix iterations)
|
||||
|
||||
| Run | Cost | Note |
|
||||
|---|---|---|
|
||||
| v1 (aborted) | $0.034 | 67% parse_error, max_dd bug |
|
||||
| v2 (aborted) | $0.018 | macd 3 args, OHLCV cap discovery |
|
||||
| v3 (aborted) | $0.015 | crash su indicator arity |
|
||||
| v4 (completed FAIL) | $0.057 | 36% parse, fitness tutti 0 |
|
||||
| v5 (completed PASS) | $0.069 | tutti gate passati |
|
||||
| **Totale Phase 1** | **$0.193** | — |
|
||||
|
||||
### 5.3 Confronto con preventivo
|
||||
|
||||
- Preventivo originale (basato su pricing Anthropic Sonnet): $500-700.
|
||||
- Spesa reale Phase 1 totale: **$0.19**.
|
||||
- Deviazione: −99.97%.
|
||||
|
||||
La differenza non è dovuta a underuse — il run v5 ha fatto 113 chiamate LLM = full saturazione del budget previsto di calls. È un cambio di ordine di grandezza nei prezzi dovuto al pricing aggressivo di OpenRouter per modelli open-weights (qwen3-235b è 7.5x più economico di Sonnet su input, 37x su output). Il preventivo originale era calibrato su Sonnet 4.6.
|
||||
|
||||
### 5.4 Implicazioni per Phase 2
|
||||
|
||||
Il margine economico permette di pianificare Phase 2 con maggiore aggressività senza superare il cap ($700-1100):
|
||||
- K=40 (×2), gen=15 (×1.5), tier mix 30% B / 70% C, ablation runs multiple.
|
||||
- Estrapolazione lineare conservativa: $0.07 × 2 × 1.5 × ~3 (tier B factor) × 5 (ablation) = ~$3 totali. Possibile spingere a $30-50 senza preoccupazioni se serve per ablation più ricche.
|
||||
|
||||
**Rischio cost-trap inverso**: tentazione di sovra-dimensionare Phase 2 perché "tanto costa nulla". Mantenere disciplina budget invariata — investire i $700 cap in PIÙ ablation, non in run più grandi.
|
||||
|
||||
---
|
||||
|
||||
## 6. Diversity metrics
|
||||
|
||||
### 6.1 Entropy fitness per generazione
|
||||
|
||||
Vedi tabella sez. 2.1 colonna entropy. Mai sotto 0.5, picco a gen 4 (1.415).
|
||||
|
||||
### 6.2 Cognitive style sopravvissuti gen 9
|
||||
|
||||
| Stile | Count gen 9 | Avg fitness | Note |
|
||||
|---|---|---|---|
|
||||
| engineer | 3 | 0.0 | Dominante numericamente ma fitness 0 (genomi recent, non valutati su elite) |
|
||||
| physicist | 1 | 0.0598 | Solo presente nel top-K |
|
||||
| historian | 1 | 0.0002 | — |
|
||||
| biologist | 0 | — | Estinto |
|
||||
| meteorologist | 0 | — | Estinto |
|
||||
| ecologist | 0 | — | Estinto |
|
||||
|
||||
**Lettura**: pressione selettiva ha eliminato 3 di 6 stili cognitivi alla generazione finale. Engineer è dominante numericamente, physicist domina nel valore (l'unico con fitness >0 della popolazione "live" gen 9). Phase 2 deve introdurre speciation esplicita per evitare questo collasso (minimum 2-3 specie protette).
|
||||
|
||||
### 6.3 Trade distribution sui 98 evals
|
||||
|
||||
| Categoria | n | % |
|
||||
|---|---|---|
|
||||
| Zero trade (HIGH no_trades, kill) | 42 | 42.9% |
|
||||
| Undertrading (1-4 trade, MEDIUM) | 5 | 5.1% |
|
||||
| Normal (5-100 trade) | 9 | 9.2% |
|
||||
| Overtrading (>100 trade, NON flaggato) | 42 | 42.9% |
|
||||
|
||||
**Issue identificato**: il 42.9% di overtrading non viene catturato dall'Adversarial perché la soglia attuale è `n_trades > n_bars/5 = 3509` — troppo alta per essere triggerata su 1000-2000 trade. Phase 2 dovrebbe abbassare a `n_bars/20 = 877` o usare metrica relativa al regime.
|
||||
|
||||
### 6.4 Adversarial findings totali
|
||||
|
||||
| Finding | Severity | Count |
|
||||
|---|---|---|
|
||||
| no_trades | HIGH | 42 |
|
||||
| undertrading | MEDIUM | 5 |
|
||||
|
||||
Niente `degenerate` né `overtrading` flaggato. Il primo è raro (richiede strategia sempre-LONG o sempre-SHORT puro), il secondo soffre della soglia troppo alta.
|
||||
|
||||
---
|
||||
|
||||
## 7. Threats to validity
|
||||
|
||||
Lista esplicita dei limiti metodologici da non sovra-interpretare:
|
||||
|
||||
1. **In-sample fitting**: tutto il backtest è in-sample. Il top-1 ha Sharpe 0.38 ottenuto guardando i dati su cui è stato selezionato. Phase 2 (walk-forward + hold-out Q1-Q2 2026 intoccabile) misura overfitting reale.
|
||||
2. **Tier C unico**: nessun confronto contro tier B/S. Possibile underperformance del LLM economico vs Sonnet/Opus. Phase 2 introduce ablation multi-tier.
|
||||
3. **Adversarial hand-crafted**: 4 check euristici (no_trades, degenerate, overtrading, undertrading). Phase 2 introduce 5 prompt LLM-driven dedicati (data snooping, lookahead, regime fragility, crowding, transaction cost erosion).
|
||||
4. **Fitness function v1**: lineare in DSR + tanh(Sharpe) normalizzato + drawdown moltiplicativa. Non multi-livello (per-team, anti-collusion). Phase 2 introduce.
|
||||
5. **No speciation, no novelty bonus**: cognitive style scendono da 6 a 3 a gen 9. Phase 2 deve mitigare.
|
||||
6. **DSR del top-1 = 0.0021**: il "successo" del Gate 3 è guidato da Sharpe (positivo modesto), non da significatività statistica vera. Senza walk-forward + multiple testing rigoroso, non si può affermare alpha edge.
|
||||
7. **Top-3/4/5 sono "lucky shot" 1-trade**: la fitness function continua li promuove perché drawdown bassissimo + sharpe leggermente negativo, ma sono artefatti. Phase 2 promuove undertrading a HIGH se `n_trades < 10`.
|
||||
8. **Cerbero/Deribit data quality**: nessuna detection di gap, outlier, exchange downtime. Da affrontare prima di forward-test (Phase 3).
|
||||
9. **Cost predictability inverso**: Phase 2 deve resistere alla tentazione di sovra-dimensionare perché Phase 1 è costata $0.19.
|
||||
|
||||
---
|
||||
|
||||
## 8. Conclusioni e implicazioni per Phase 2
|
||||
|
||||
**Hard gate sintesi**: ✅ 5 su 5 passati.
|
||||
|
||||
**Decisione finale**: **GO Phase 2** (formalizzata nel decision memo).
|
||||
|
||||
**Apprendimenti chiave per Phase 2**:
|
||||
|
||||
1. **JSON >> S-expression** per grammar LLM-generated. Phase 2 non rivisita.
|
||||
2. **Fitness continua è essenziale** per dare gradient al GA, ma può promuovere strategie degeneri (1-trade) che vanno killate diversamente.
|
||||
3. **OpenRouter qwen3-235b** è sorprendentemente capace per generare strategie strutturate, dato un prompt schema-rigoroso. Tier B (Sonnet) potrebbe non essere necessario al 30% come pianificato; ablation Phase 2 misurerà il vero contributo.
|
||||
4. **Cerbero MCP come single source of truth** funziona: paginazione, cache parquet, audit log integrati senza fragility.
|
||||
5. **Bug-fix discovery via run reale** è efficiente: 4 cicli, ognuno ha esposto un problema specifico (max_dd math, macd arity, validator arity, fitness clamp, grammar choice). Phase 2 può aspettarsi pattern simile per nuove componenti (speciation edge cases, OOS overfitting, multi-tier dispatch).
|
||||
|
||||
**Riusabilità del codebase Phase 1**: il design modulare (data, backtest, metrics, cerbero, protocol, genome, llm, agents, ga, persistence, orchestrator, dashboard) è riusabile direttamente. Estensioni Phase 2:
|
||||
- `ga/speciation.py` (nuovo) — clustering cosine similarity prompt, quota tournament per specie.
|
||||
- `ga/fitness.py` — versione v2 con novelty bonus + per-team aggregation.
|
||||
- `orchestrator/run.py` — integrazione walk-forward.
|
||||
- `agents/adversarial_llm.py` (nuovo) — 5 prompt LLM-driven.
|
||||
- `baseline/random_forest.py` (nuovo) — RF baseline per benchmark.
|
||||
|
||||
**Costo stimato Phase 2**: $3-15 (estrapolazione molto conservativa). Cap rimane $700-1100 invariato per disciplina.
|
||||
|
||||
**Tempo stimato Phase 2**: 4-6 settimane di lavoro calendar, includendo i 3 aggiustamenti del decision memo (Adversarial soglie, speciation, walk-forward).
|
||||
|
||||
---
|
||||
|
||||
*Documento finalizzato 10 maggio 2026. Versione 1.0.*
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,318 +0,0 @@
|
||||
# `mutate_prompt_llm` — Phase 2.5 Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [x]`) syntax for tracking.
|
||||
|
||||
**Status:** **TUTTI I 6 TASK COMPLETATI** (task 1-5 il 2026-05-11, task 6 il 2026-05-12). Mergiati su main. Validato empiricamente: run `phase2-5-qwen25-prompt-mut-004` ha raggiunto max fitness **0.1012** (+225% vs baseline `phase2-qwen25-control-001` 0.0311). Sweet spot weight=0.30 (curva U: weight=0.50 → regressione plateau 0.0311; weight=0.00 → baseline piatto).
|
||||
|
||||
**Trigger Phase 2.5 verificati con esito Phase 2 + run controllo:**
|
||||
- ✅ Plateau max fitness ≥ 4 gen consecutive (Phase 2 qwen3-235b stuck 8 gen a 0.0238; run controllo qwen-2.5-72b stuck 9 gen a 0.0311).
|
||||
- ✅ Diversità prompt collapsed: top genomi del run controllo hanno fitness/Sharpe/DD identici (mutazioni scalari non producono varianti significative).
|
||||
- ✗ Top quasi-fit ≥ 0.10 non raggiunto, ma 2/3 trigger sufficienti.
|
||||
|
||||
**Decisione collaterale:** rollback tier C a `qwen/qwen-2.5-72b-instruct` (run controllo l'ha dimostrato superiore a qwen3-235b: +30% fitness, 4× entropy, metà costo e tempo).
|
||||
|
||||
**Goal:** Introdurre un quinto operatore di mutazione che usa un LLM tier B come "mutator" per riscrivere il `system_prompt` di un genoma, generando diversità reale dove oggi `random_mutate` tocca solo quattro scalari. La pipeline GA esistente resta intatta: `mutate_prompt_llm` è solo un nuovo membro di `MUTATION_OPS` con peso configurabile.
|
||||
|
||||
**Architecture:** Operatore puro come gli altri quattro (`mutate_temperature`, `mutate_lookback`, `mutate_feature_access`, `mutate_cognitive_style`). Riceve `parent_genome`, `llm_client`, `rng` e restituisce un child genome con `system_prompt` modificato. Il mutator LLM (tier B = `deepseek/deepseek-v4-flash`) riceve una mutation-instruction casuale tra sei tipi predefiniti (`tighten_threshold`, `swap_comparator`, `add_condition`, `remove_condition`, `change_timeframe`, `add_temporal_gate`) e produce un nuovo prompt vincolato a una mutazione "atomica". Il child viene validato (parser + adversarial dry-run); su fallimento si effettua fallback a `random_mutate`. Selezione probabilistica nel `random_mutate` dispatcher con peso configurabile (default 0.30) — i quattro operator scalari mantengono il 70% complessivo.
|
||||
|
||||
**Tech Stack:** Python 3.13, `LLMClient` esistente (OpenAI SDK via OpenRouter), pytest + `pytest-mock`. Niente nuove dipendenze.
|
||||
|
||||
**Spec di riferimento:** sezione "Meccanismo di mutazione" della conversazione `2026-05-11`, valutazione `mutate_prompt_llm` (questa pagina contiene la sintesi).
|
||||
|
||||
---
|
||||
|
||||
## Trigger condition (quando attivare)
|
||||
|
||||
Implementare e mergiare **solo se** uno dei seguenti è vero al termine di Phase 2:
|
||||
|
||||
1. **Plateau evolutivo**: max fitness stagnante (Δ < 0.01) per ≥ 4 generazioni consecutive su `phase2-qwen3-001` o successori.
|
||||
2. **Diversità prompt collassa**: media Levenshtein normalizzata fra i prompt della popolazione finale ≤ 0.15 (= popolazione clonata).
|
||||
3. **Top genome problematico ma quasi-fit**: max fitness ≥ 0.10 ma adversarial finding HIGH ≥ 2 per il top, suggerendo che una mutazione mirata del prompt potrebbe "ripararlo".
|
||||
|
||||
Se Phase 2 raggiunge max fitness ≥ 0.30 senza plateau, **non attivare** (la diversità random basta).
|
||||
|
||||
---
|
||||
|
||||
## File map
|
||||
|
||||
| File | Tipo | Responsabilità |
|
||||
|------|------|----------------|
|
||||
| `src/multi_swarm/genome/mutation_prompt_llm.py` | New | Operatore `mutate_prompt_llm` + helper `MUTATION_INSTRUCTIONS` + retry/fallback wrapper |
|
||||
| `src/multi_swarm/genome/mutation.py` | Modify | Estendere `MUTATION_OPS` + introdurre dispatcher pesato `weighted_random_mutate` |
|
||||
| `src/multi_swarm/ga/loop.py` | Modify | Sostituire `random_mutate(parent, rng)` con `weighted_random_mutate(parent, rng, llm_client, weights)` |
|
||||
| `src/multi_swarm/orchestrator/run.py` | Modify | Aggiungere `mutator_tier: ModelTier = ModelTier.B` e `prompt_mutation_weight: float = 0.30` a `RunConfig`, passare `LLMClient` al loop GA |
|
||||
| `src/multi_swarm/llm/cost_tracker.py` | Modify (minimo) | Loggare `mutation_call` separatamente da `hypothesis_call` per attribuzione costo |
|
||||
| `src/multi_swarm/metrics/diversity.py` | New | Funzione `population_prompt_diversity` (Levenshtein normalizzata) — usata in trigger check + telemetry |
|
||||
| `tests/unit/test_mutation_prompt_llm.py` | New | Test operator con mock `LLMClient` (success + validation fail + retry/fallback) |
|
||||
| `tests/unit/test_mutation_dispatcher.py` | New | Test `weighted_random_mutate` rispetta i pesi |
|
||||
| `tests/unit/test_diversity.py` | New | Test `population_prompt_diversity` su prompt identici/diversi |
|
||||
| `tests/integration/test_ga_loop_with_prompt_mutator.py` | New | Loop end-to-end di 2 gen × 5 genomi con mock LLM, verifica diversità prompt cresce |
|
||||
|
||||
---
|
||||
|
||||
## Task 1: Mutator instructions + operator stub
|
||||
|
||||
**Files:**
|
||||
- New: `src/multi_swarm/genome/mutation_prompt_llm.py`
|
||||
- New: `tests/unit/test_mutation_prompt_llm.py`
|
||||
|
||||
- [x] **Step 1.1: Write failing test — operator returns child con system_prompt diverso**
|
||||
|
||||
Append a `tests/unit/test_mutation_prompt_llm.py`:
|
||||
|
||||
```python
|
||||
def test_mutate_prompt_llm_produces_different_prompt(mock_llm: LLMClient) -> None:
|
||||
parent = make_genome(system_prompt="Strategia: compra quando RSI < 30")
|
||||
mock_llm.respond_with("Strategia: compra quando RSI < 25 e ora >= 14")
|
||||
child = mutate_prompt_llm(parent, mock_llm, rng=random.Random(0))
|
||||
assert child.system_prompt != parent.system_prompt
|
||||
assert child.parent_ids == [*parent.parent_ids, parent.id]
|
||||
assert child.generation == parent.generation + 1
|
||||
```
|
||||
|
||||
- [x] **Step 1.2: Implement `MUTATION_INSTRUCTIONS` constant**
|
||||
|
||||
`mutation_prompt_llm.py`:
|
||||
|
||||
```python
|
||||
MUTATION_INSTRUCTIONS: dict[str, str] = {
|
||||
"tighten_threshold": "Rendi una soglia numerica più restrittiva del 10–20%...",
|
||||
"swap_comparator": "Inverti un comparator (gt ↔ lt, gte ↔ lte) mantenendo intent...",
|
||||
"add_condition": "Aggiungi una condizione AND/OR alla rule più specifica...",
|
||||
"remove_condition": "Rimuovi una condizione ridondante o debole...",
|
||||
"change_timeframe": "Modifica una finestra rolling (lookback) di ±30%...",
|
||||
"add_temporal_gate": "Aggiungi un gate temporale (hour, dow, is_weekend)...",
|
||||
}
|
||||
```
|
||||
|
||||
- [x] **Step 1.3: Implement `mutate_prompt_llm`**
|
||||
|
||||
Firma:
|
||||
```python
|
||||
def mutate_prompt_llm(
|
||||
g: HypothesisAgentGenome,
|
||||
llm: LLMClient,
|
||||
rng: random.Random,
|
||||
mutator_tier: ModelTier = ModelTier.B,
|
||||
) -> HypothesisAgentGenome:
|
||||
```
|
||||
|
||||
Logica:
|
||||
1. Scegli `instruction_key = rng.choice(list(MUTATION_INSTRUCTIONS))`.
|
||||
2. Costruisci messaggio system + user con `MUTATION_INSTRUCTIONS[instruction_key]` + `g.system_prompt`.
|
||||
3. Crea genoma temporaneo `mutator_genome` con `model_tier=mutator_tier`.
|
||||
4. Chiama `llm.complete(mutator_genome, system, user, max_tokens=2000)`.
|
||||
5. Estrai nuovo prompt da risposta (cerca blocco `<prompt>...</prompt>` o intero output).
|
||||
6. Ritorna `_clone_with(g, system_prompt=new_prompt)` (riusa helper di `mutation.py`).
|
||||
|
||||
- [x] **Step 1.4: Run test → green**
|
||||
|
||||
```bash
|
||||
uv run pytest tests/unit/test_mutation_prompt_llm.py::test_mutate_prompt_llm_produces_different_prompt -xvs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 2: Validation + fallback
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/multi_swarm/genome/mutation_prompt_llm.py`
|
||||
- Append: `tests/unit/test_mutation_prompt_llm.py`
|
||||
|
||||
- [x] **Step 2.1: Write failing test — fallback a random_mutate su prompt invalid**
|
||||
|
||||
```python
|
||||
def test_mutate_prompt_llm_falls_back_on_invalid_prompt(mock_llm: LLMClient) -> None:
|
||||
parent = make_genome()
|
||||
mock_llm.respond_with("garbage that does not parse")
|
||||
child = mutate_prompt_llm(parent, mock_llm, rng=random.Random(0))
|
||||
# Garbage prompt deve fallback: child è prodotto da random_mutate, quindi
|
||||
# system_prompt == parent.system_prompt (random_mutate tocca solo scalari)
|
||||
assert child.system_prompt == parent.system_prompt
|
||||
assert child.parent_ids == [*parent.parent_ids, parent.id]
|
||||
```
|
||||
|
||||
- [x] **Step 2.2: Implement validation step**
|
||||
|
||||
Dopo aver estratto `new_prompt`, esegui `validate_prompt(new_prompt)`:
|
||||
- Lunghezza minima 50 caratteri.
|
||||
- Contiene almeno una keyword fra `{rsi, sma, ema, atr, momentum, breakout, mean reversion, gt, lt, ...}`.
|
||||
- Non identico a `parent.system_prompt` (Levenshtein > 0.05 normalizzata).
|
||||
|
||||
Su fail → log warning + ritorna `random_mutate(g, rng)`.
|
||||
|
||||
- [x] **Step 2.3: Write failing test — diversity guard**
|
||||
|
||||
Mock LLM ritorna prompt identico al parent → `validate_prompt` rifiuta → fallback.
|
||||
|
||||
- [x] **Step 2.4: Run test suite parziale**
|
||||
|
||||
```bash
|
||||
uv run pytest tests/unit/test_mutation_prompt_llm.py -xvs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 3: Weighted dispatcher
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/multi_swarm/genome/mutation.py`
|
||||
- New: `tests/unit/test_mutation_dispatcher.py`
|
||||
|
||||
- [x] **Step 3.1: Write failing test — weighted_random_mutate rispetta pesi**
|
||||
|
||||
```python
|
||||
def test_weighted_random_mutate_picks_prompt_op_at_configured_rate() -> None:
|
||||
rng = random.Random(0)
|
||||
weights = {"prompt": 1.0, "scalar": 0.0} # 100% prompt
|
||||
counter = Counter()
|
||||
for _ in range(100):
|
||||
op_name = _pick_op_name(weights, rng)
|
||||
counter[op_name] += 1
|
||||
assert counter["prompt"] == 100
|
||||
```
|
||||
|
||||
- [x] **Step 3.2: Implement `weighted_random_mutate`**
|
||||
|
||||
```python
|
||||
def weighted_random_mutate(
|
||||
g: HypothesisAgentGenome,
|
||||
rng: random.Random,
|
||||
llm: LLMClient | None = None,
|
||||
prompt_mutation_weight: float = 0.30,
|
||||
) -> HypothesisAgentGenome:
|
||||
if llm is not None and rng.random() < prompt_mutation_weight:
|
||||
return mutate_prompt_llm(g, llm, rng)
|
||||
return random_mutate(g, rng)
|
||||
```
|
||||
|
||||
- [x] **Step 3.3: Test edge cases**
|
||||
|
||||
- `llm=None` → sempre scalar mutation (backward compat).
|
||||
- `prompt_mutation_weight=0.0` → sempre scalar.
|
||||
- `prompt_mutation_weight=1.0` → sempre prompt (se llm presente).
|
||||
|
||||
---
|
||||
|
||||
## Task 4: Integrazione GA loop
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/multi_swarm/ga/loop.py`
|
||||
- Modify: `src/multi_swarm/orchestrator/run.py`
|
||||
- New: `tests/integration/test_ga_loop_with_prompt_mutator.py`
|
||||
|
||||
- [x] **Step 4.1: Estendere `GAConfig`**
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class GAConfig:
|
||||
population_size: int
|
||||
elite_k: int
|
||||
tournament_k: int
|
||||
p_crossover: float
|
||||
prompt_mutation_weight: float = 0.0 # default off → opt-in
|
||||
```
|
||||
|
||||
- [x] **Step 4.2: Pass `LLMClient` in `next_generation`**
|
||||
|
||||
```python
|
||||
def next_generation(
|
||||
population: list[HypothesisAgentGenome],
|
||||
fitnesses: dict[str, float],
|
||||
cfg: GAConfig,
|
||||
rng: random.Random,
|
||||
llm: LLMClient | None = None,
|
||||
) -> list[HypothesisAgentGenome]:
|
||||
...
|
||||
child = weighted_random_mutate(parent, rng, llm, cfg.prompt_mutation_weight)
|
||||
```
|
||||
|
||||
- [x] **Step 4.3: Wire in orchestrator**
|
||||
|
||||
`RunConfig.prompt_mutation_weight: float = 0.0` (default off). Quando attivo via CLI `--prompt-mutation-weight 0.30`, passare a `next_generation`.
|
||||
|
||||
- [x] **Step 4.4: Integration test**
|
||||
|
||||
Loop 2 gen × 5 genomi, mock LLM che ritorna prompt sempre diversi. Verifica che la popolazione finale abbia più diversità prompt della iniziale.
|
||||
|
||||
---
|
||||
|
||||
## Task 5: Diversity metric
|
||||
|
||||
**Files:**
|
||||
- New: `src/multi_swarm/metrics/diversity.py`
|
||||
- New: `tests/unit/test_diversity.py`
|
||||
|
||||
- [x] **Step 5.1: Implement `population_prompt_diversity`**
|
||||
|
||||
```python
|
||||
def population_prompt_diversity(prompts: list[str]) -> float:
|
||||
"""Levenshtein normalizzata media su tutte le coppie. 0.0 = identici, 1.0 = totalmente diversi."""
|
||||
```
|
||||
|
||||
- [x] **Step 5.2: Test**
|
||||
|
||||
Tre prompt identici → 0.0. Tre prompt totalmente diversi → ~1.0.
|
||||
|
||||
- [x] **Step 5.3: Logging**
|
||||
|
||||
Aggiungere `diversity_prompt` come campo per-generazione in `repository.save_generation` (richiede migration leggera).
|
||||
|
||||
---
|
||||
|
||||
## Task 6: Cost attribution
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/multi_swarm/llm/cost_tracker.py`
|
||||
- Modify: tests esistenti
|
||||
|
||||
- [x] **Step 6.1: Aggiungere `call_kind` a `CostRecord`**
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class CostRecord:
|
||||
...
|
||||
call_kind: str = "hypothesis" # "hypothesis" | "mutation"
|
||||
```
|
||||
|
||||
- [x] **Step 6.2: Loggare separatamente in summary**
|
||||
|
||||
`summary()["by_call_kind"]` con breakdown.
|
||||
|
||||
- [x] **Step 6.3: Test compatibilità con record esistenti**
|
||||
|
||||
Backward compat: record senza `call_kind` interpretati come `"hypothesis"`.
|
||||
|
||||
---
|
||||
|
||||
## Verification end-to-end
|
||||
|
||||
- [x] `uv run pytest -q` → 100% passa (157 + nuovi test).
|
||||
- [x] `uv run python scripts/smoke_run.py` → completa con mock LLM.
|
||||
- [x] **Run baseline B**: ripetere `phase2-qwen3-001` con `--prompt-mutation-weight 0.0` per controllo.
|
||||
- [x] **Run trattamento T**: `phase2-qwen3-prompt-mut-001` con `--prompt-mutation-weight 0.30`.
|
||||
- [x] Confronto: max fitness T > B + 20%, diversity_prompt(T) > diversity_prompt(B) + 30%.
|
||||
- [x] Costo aggiuntivo run T ≤ $0.10 (sanity check).
|
||||
|
||||
---
|
||||
|
||||
## Risks & mitigations
|
||||
|
||||
| Rischio | Mitigazione |
|
||||
|---------|-------------|
|
||||
| Mode collapse mutator LLM | `mutation_instruction` scelta random + diversity guard Levenshtein |
|
||||
| Prompt LLM-output non parsabile dal compiler | Validation step + fallback `random_mutate` |
|
||||
| Costo runaway (loop infinito retry) | `max_tokens=2000`, no retry su validation fail |
|
||||
| Bias condiviso con generator tier C | Mutator tier B = `deepseek-v4-flash`, famiglia diversa da Qwen3 |
|
||||
| Variabili confuse con Phase 2 | Attivare **solo** dopo Phase 2 baseline; A/B isolato |
|
||||
|
||||
---
|
||||
|
||||
## Cost estimate
|
||||
|
||||
Pop = 20, gen = 10, mutation rate ~75% (5 elite + 15 children), prompt_mutation_weight = 0.30:
|
||||
- ~45 chiamate LLM tier B aggiuntive per run.
|
||||
- ~500 tok input + 200 tok output per call → 22.5k in + 9k out totali.
|
||||
- 22.5k × $0.14/1M + 9k × $0.28/1M ≈ **$0.0057/run**.
|
||||
|
||||
Trascurabile rispetto al budget run base (~$0.10).
|
||||
@@ -1,482 +0,0 @@
|
||||
# Feature temporali nella grammatica Hypothesis — Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** Aggiungere quattro feature temporali (`hour`, `dow`, `is_weekend`, `minute_of_hour`) alla grammatica delle strategie Hypothesis come `FeatureNode`, universalmente accessibili a ogni genoma e usabili con i comparator esistenti.
|
||||
|
||||
**Architecture:** Estensione puramente additiva. La whitelist `KNOWN_FEATURES` in `protocol/grammar.py` cresce da 5 a 9 nomi. Il dispatcher di `FeatureNode` in `protocol/compiler.py` acquisisce un branch prioritario che mappa i nomi temporali a serie derivate da `df.index` (DatetimeIndex UTC). Il prompt template di `agents/hypothesis.py` riceve due esempi few-shot. Nessuna modifica a parser, mutation/crossover, genome dataclass.
|
||||
|
||||
**Tech Stack:** Python 3.13, pandas (DatetimeIndex), pytest. Esecuzione via `uv run`. Repository: `/home/adriano/Documenti/Git_XYZ/Multi_Swarm_Coevolutive`.
|
||||
|
||||
**Spec di riferimento:** `docs/superpowers/specs/2026-05-11-temporal-features-design.md`
|
||||
|
||||
---
|
||||
|
||||
## File map
|
||||
|
||||
| File | Tipo | Responsabilità |
|
||||
|------|------|----------------|
|
||||
| `src/multi_swarm/protocol/grammar.py` | Modify | Estendere `KNOWN_FEATURES` |
|
||||
| `src/multi_swarm/protocol/compiler.py` | Modify | Aggiungere `_TIME_FEATURE_FNS` + branch in `_eval_node` |
|
||||
| `src/multi_swarm/agents/hypothesis.py` | Modify | Estendere prompt template con sezione feature temporali + 2 esempi |
|
||||
| `tests/unit/test_protocol_validator.py` | Modify | +2 test (accept/reject) |
|
||||
| `tests/unit/test_protocol_compiler.py` | Modify | +5 test (4 feature + 1 integrazione) |
|
||||
|
||||
---
|
||||
|
||||
## Task 1: Grammar extension + validator tests
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/multi_swarm/protocol/grammar.py:21-23`
|
||||
- Modify: `tests/unit/test_protocol_validator.py` (append)
|
||||
|
||||
- [ ] **Step 1.1: Write failing test — validator accepts temporal features**
|
||||
|
||||
Append to `tests/unit/test_protocol_validator.py`:
|
||||
|
||||
```python
|
||||
def test_validator_accepts_temporal_features() -> None:
|
||||
for name in ("hour", "dow", "is_weekend", "minute_of_hour"):
|
||||
src = _wrap(
|
||||
{
|
||||
"op": "gt",
|
||||
"args": [
|
||||
{"kind": "feature", "name": name},
|
||||
{"kind": "literal", "value": 0},
|
||||
],
|
||||
}
|
||||
)
|
||||
ast = parse_strategy(src)
|
||||
validate_strategy(ast) # no exception
|
||||
|
||||
|
||||
def test_validator_rejects_temporal_typo() -> None:
|
||||
src = _wrap(
|
||||
{
|
||||
"op": "gt",
|
||||
"args": [
|
||||
{"kind": "feature", "name": "weekday"},
|
||||
{"kind": "literal", "value": 0},
|
||||
],
|
||||
}
|
||||
)
|
||||
ast = parse_strategy(src)
|
||||
with pytest.raises(ValidationError, match="unknown feature"):
|
||||
validate_strategy(ast)
|
||||
```
|
||||
|
||||
- [ ] **Step 1.2: Run tests to verify they fail**
|
||||
|
||||
Run: `uv run pytest tests/unit/test_protocol_validator.py::test_validator_accepts_temporal_features tests/unit/test_protocol_validator.py::test_validator_rejects_temporal_typo -v`
|
||||
Expected: First test FAILs with `ValidationError: unknown feature: hour`. Second test PASSes already (weekday is unknown today too).
|
||||
|
||||
- [ ] **Step 1.3: Extend `KNOWN_FEATURES` whitelist**
|
||||
|
||||
Edit `src/multi_swarm/protocol/grammar.py`, lines 21-23:
|
||||
|
||||
```python
|
||||
KNOWN_FEATURES: frozenset[str] = frozenset(
|
||||
{"open", "high", "low", "close", "volume",
|
||||
"hour", "dow", "is_weekend", "minute_of_hour"}
|
||||
)
|
||||
```
|
||||
|
||||
- [ ] **Step 1.4: Run tests to verify both pass**
|
||||
|
||||
Run: `uv run pytest tests/unit/test_protocol_validator.py -v`
|
||||
Expected: All tests PASS (both new tests + all pre-existing ones).
|
||||
|
||||
- [ ] **Step 1.5: Commit**
|
||||
|
||||
```bash
|
||||
git add src/multi_swarm/protocol/grammar.py tests/unit/test_protocol_validator.py
|
||||
git commit -m "feat(protocol): extend KNOWN_FEATURES with temporal feature names"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 2: Compiler — `hour` feature
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/multi_swarm/protocol/compiler.py:135-137`
|
||||
- Modify: `tests/unit/test_protocol_compiler.py` (append)
|
||||
|
||||
- [ ] **Step 2.1: Write failing test for `hour`**
|
||||
|
||||
Append to `tests/unit/test_protocol_compiler.py`:
|
||||
|
||||
```python
|
||||
def test_compile_hour_feature_returns_index_hour(ohlcv: pd.DataFrame) -> None:
|
||||
src = json.dumps(
|
||||
{
|
||||
"rules": [
|
||||
{
|
||||
"condition": {
|
||||
"op": "gt",
|
||||
"args": [
|
||||
{"kind": "feature", "name": "hour"},
|
||||
{"kind": "literal", "value": -1},
|
||||
],
|
||||
},
|
||||
"action": "entry-long",
|
||||
}
|
||||
]
|
||||
}
|
||||
)
|
||||
ast = parse_strategy(src)
|
||||
fn = compile_strategy(ast)
|
||||
signal = fn(ohlcv)
|
||||
# Tutte le righe hanno hour >= 0 > -1, quindi tutte entry-long
|
||||
assert (signal == Side.LONG).all()
|
||||
```
|
||||
|
||||
- [ ] **Step 2.2: Run test to verify it fails**
|
||||
|
||||
Run: `uv run pytest tests/unit/test_protocol_compiler.py::test_compile_hour_feature_returns_index_hour -v`
|
||||
Expected: FAIL with `KeyError: 'hour'` (df has no `hour` column, dispatcher falls into `df[name]`).
|
||||
|
||||
- [ ] **Step 2.3: Add `_TIME_FEATURE_FNS` and dispatcher branch**
|
||||
|
||||
Edit `src/multi_swarm/protocol/compiler.py`. Insert after line 108 (end of `INDICATOR_FNS`):
|
||||
|
||||
```python
|
||||
_TIME_FEATURE_FNS: dict[str, Callable[[pd.DatetimeIndex], pd.Series]] = {
|
||||
"hour": lambda idx: pd.Series(idx.hour, index=idx, dtype="int64"),
|
||||
"dow": lambda idx: pd.Series(idx.dayofweek, index=idx, dtype="int64"),
|
||||
"is_weekend": lambda idx: pd.Series((idx.dayofweek >= 5).astype("int64"), index=idx),
|
||||
"minute_of_hour": lambda idx: pd.Series(idx.minute, index=idx, dtype="int64"),
|
||||
}
|
||||
```
|
||||
|
||||
Then modify `_eval_node` at line 135-137. Replace:
|
||||
|
||||
```python
|
||||
def _eval_node(node: Node, df: pd.DataFrame) -> pd.Series:
|
||||
if isinstance(node, FeatureNode):
|
||||
return df[node.name]
|
||||
```
|
||||
|
||||
With:
|
||||
|
||||
```python
|
||||
def _eval_node(node: Node, df: pd.DataFrame) -> pd.Series:
|
||||
if isinstance(node, FeatureNode):
|
||||
if node.name in _TIME_FEATURE_FNS:
|
||||
return _TIME_FEATURE_FNS[node.name](df.index)
|
||||
return df[node.name]
|
||||
```
|
||||
|
||||
- [ ] **Step 2.4: Run test to verify it passes**
|
||||
|
||||
Run: `uv run pytest tests/unit/test_protocol_compiler.py::test_compile_hour_feature_returns_index_hour -v`
|
||||
Expected: PASS.
|
||||
|
||||
- [ ] **Step 2.5: Commit**
|
||||
|
||||
```bash
|
||||
git add src/multi_swarm/protocol/compiler.py tests/unit/test_protocol_compiler.py
|
||||
git commit -m "feat(protocol): dispatcher temporal features (hour) in compiler"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 3: Compiler — `dow` and `is_weekend` tests
|
||||
|
||||
**Files:**
|
||||
- Modify: `tests/unit/test_protocol_compiler.py` (append)
|
||||
|
||||
Nessuna modifica al sorgente: `_TIME_FEATURE_FNS` definito in Task 2 contiene già le quattro funzioni. Questi test verificano semantica e copertura.
|
||||
|
||||
- [ ] **Step 3.1: Add `dow` test**
|
||||
|
||||
Append to `tests/unit/test_protocol_compiler.py`:
|
||||
|
||||
```python
|
||||
def test_compile_dow_feature_monday_is_zero(ohlcv: pd.DataFrame) -> None:
|
||||
# 2024-01-01 e' un lunedi -> dow=0; gating eq dow 0 deve dare LONG su monday only.
|
||||
src = json.dumps(
|
||||
{
|
||||
"rules": [
|
||||
{
|
||||
"condition": {
|
||||
"op": "eq",
|
||||
"args": [
|
||||
{"kind": "feature", "name": "dow"},
|
||||
{"kind": "literal", "value": 0},
|
||||
],
|
||||
},
|
||||
"action": "entry-long",
|
||||
}
|
||||
]
|
||||
}
|
||||
)
|
||||
ast = parse_strategy(src)
|
||||
fn = compile_strategy(ast)
|
||||
signal = fn(ohlcv)
|
||||
# ohlcv fixture: 200h da 2024-01-01 00:00 UTC -> primo lunedi e' bar 0..23
|
||||
monday_hours = signal[(signal.index.dayofweek == 0)]
|
||||
other_hours = signal[(signal.index.dayofweek != 0)]
|
||||
assert (monday_hours == Side.LONG).all()
|
||||
assert (other_hours == Side.FLAT).all()
|
||||
```
|
||||
|
||||
- [ ] **Step 3.2: Add `is_weekend` test**
|
||||
|
||||
Append:
|
||||
|
||||
```python
|
||||
def test_compile_is_weekend_returns_zero_one(ohlcv: pd.DataFrame) -> None:
|
||||
src = json.dumps(
|
||||
{
|
||||
"rules": [
|
||||
{
|
||||
"condition": {
|
||||
"op": "eq",
|
||||
"args": [
|
||||
{"kind": "feature", "name": "is_weekend"},
|
||||
{"kind": "literal", "value": 1},
|
||||
],
|
||||
},
|
||||
"action": "entry-long",
|
||||
}
|
||||
]
|
||||
}
|
||||
)
|
||||
ast = parse_strategy(src)
|
||||
fn = compile_strategy(ast)
|
||||
signal = fn(ohlcv)
|
||||
weekend = signal[signal.index.dayofweek >= 5]
|
||||
weekdays = signal[signal.index.dayofweek < 5]
|
||||
assert (weekend == Side.LONG).all()
|
||||
assert (weekdays == Side.FLAT).all()
|
||||
```
|
||||
|
||||
- [ ] **Step 3.3: Run both tests**
|
||||
|
||||
Run: `uv run pytest tests/unit/test_protocol_compiler.py::test_compile_dow_feature_monday_is_zero tests/unit/test_protocol_compiler.py::test_compile_is_weekend_returns_zero_one -v`
|
||||
Expected: Both PASS.
|
||||
|
||||
- [ ] **Step 3.4: Commit**
|
||||
|
||||
```bash
|
||||
git add tests/unit/test_protocol_compiler.py
|
||||
git commit -m "test(protocol): compiler semantica dow + is_weekend"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 4: Compiler — `minute_of_hour` test
|
||||
|
||||
**Files:**
|
||||
- Modify: `tests/unit/test_protocol_compiler.py` (append)
|
||||
|
||||
- [ ] **Step 4.1: Add `minute_of_hour` test**
|
||||
|
||||
Append:
|
||||
|
||||
```python
|
||||
def test_compile_minute_of_hour_zero_on_1h_timeframe(ohlcv: pd.DataFrame) -> None:
|
||||
# Fixture ohlcv ha freq=1h, quindi tutti i minute_of_hour sono 0.
|
||||
# gating eq minute_of_hour 0 -> LONG su TUTTE le righe.
|
||||
src = json.dumps(
|
||||
{
|
||||
"rules": [
|
||||
{
|
||||
"condition": {
|
||||
"op": "eq",
|
||||
"args": [
|
||||
{"kind": "feature", "name": "minute_of_hour"},
|
||||
{"kind": "literal", "value": 0},
|
||||
],
|
||||
},
|
||||
"action": "entry-long",
|
||||
}
|
||||
]
|
||||
}
|
||||
)
|
||||
ast = parse_strategy(src)
|
||||
fn = compile_strategy(ast)
|
||||
signal = fn(ohlcv)
|
||||
assert (signal == Side.LONG).all()
|
||||
```
|
||||
|
||||
- [ ] **Step 4.2: Run test**
|
||||
|
||||
Run: `uv run pytest tests/unit/test_protocol_compiler.py::test_compile_minute_of_hour_zero_on_1h_timeframe -v`
|
||||
Expected: PASS.
|
||||
|
||||
- [ ] **Step 4.3: Commit**
|
||||
|
||||
```bash
|
||||
git add tests/unit/test_protocol_compiler.py
|
||||
git commit -m "test(protocol): compiler semantica minute_of_hour su 1h"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 5: Compiler — integrazione con regola completa
|
||||
|
||||
**Files:**
|
||||
- Modify: `tests/unit/test_protocol_compiler.py` (append)
|
||||
|
||||
- [ ] **Step 5.1: Add integration test**
|
||||
|
||||
Append:
|
||||
|
||||
```python
|
||||
def test_rule_with_temporal_gating_compiles_and_executes(ohlcv: pd.DataFrame) -> None:
|
||||
# Regola: entry-long se hour > 14 AND close > sma(20).
|
||||
# close in fixture e' lineare crescente, quindi close > sma(20) e' True dopo warmup.
|
||||
# entry-long deve apparire solo nelle bar con hour > 14.
|
||||
src = json.dumps(
|
||||
{
|
||||
"rules": [
|
||||
{
|
||||
"condition": {
|
||||
"op": "and",
|
||||
"args": [
|
||||
{
|
||||
"op": "gt",
|
||||
"args": [
|
||||
{"kind": "feature", "name": "hour"},
|
||||
{"kind": "literal", "value": 14},
|
||||
],
|
||||
},
|
||||
{
|
||||
"op": "gt",
|
||||
"args": [
|
||||
{"kind": "feature", "name": "close"},
|
||||
{"kind": "indicator", "name": "sma", "params": [20]},
|
||||
],
|
||||
},
|
||||
],
|
||||
},
|
||||
"action": "entry-long",
|
||||
}
|
||||
]
|
||||
}
|
||||
)
|
||||
ast = parse_strategy(src)
|
||||
fn = compile_strategy(ast)
|
||||
signal = fn(ohlcv)
|
||||
|
||||
# Bar con hour <= 14: mai LONG (gating temporale blocca).
|
||||
morning = signal[signal.index.hour <= 14]
|
||||
assert (morning == Side.FLAT).all()
|
||||
|
||||
# Bar con hour > 14 e dopo warmup sma (>=20 bar dall'inizio): LONG.
|
||||
afternoon_warm = signal[(signal.index.hour > 14) & (np.arange(len(signal)) >= 20)]
|
||||
assert (afternoon_warm == Side.LONG).all()
|
||||
```
|
||||
|
||||
- [ ] **Step 5.2: Run test**
|
||||
|
||||
Run: `uv run pytest tests/unit/test_protocol_compiler.py::test_rule_with_temporal_gating_compiles_and_executes -v`
|
||||
Expected: PASS.
|
||||
|
||||
- [ ] **Step 5.3: Run full compiler + validator test suite to check regressions**
|
||||
|
||||
Run: `uv run pytest tests/unit/test_protocol_compiler.py tests/unit/test_protocol_validator.py -v`
|
||||
Expected: All tests PASS (pre-existing + new). Nessun test rotto.
|
||||
|
||||
- [ ] **Step 5.4: Commit**
|
||||
|
||||
```bash
|
||||
git add tests/unit/test_protocol_compiler.py
|
||||
git commit -m "test(protocol): integration test gating temporale + sma"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 6: Update Hypothesis prompt
|
||||
|
||||
**Files:**
|
||||
- Modify: `src/multi_swarm/agents/hypothesis.py:84-85`
|
||||
|
||||
- [ ] **Step 6.1: Edit prompt template**
|
||||
|
||||
In `src/multi_swarm/agents/hypothesis.py`, alla riga 84-85 sostituire:
|
||||
|
||||
```python
|
||||
Leaf - feature OHLCV:
|
||||
{{"kind": "feature", "name": "open|high|low|close|volume"}}
|
||||
```
|
||||
|
||||
con:
|
||||
|
||||
```python
|
||||
Leaf - feature OHLCV:
|
||||
{{"kind": "feature", "name": "open|high|low|close|volume"}}
|
||||
|
||||
Leaf - feature TEMPORALI (sempre accessibili, UTC):
|
||||
{{"kind": "feature", "name": "hour"}} // range 0-23
|
||||
{{"kind": "feature", "name": "dow"}} // range 0-6 (lun=0, dom=6)
|
||||
{{"kind": "feature", "name": "is_weekend"}} // 0 o 1
|
||||
{{"kind": "feature", "name": "minute_of_hour"}} // range 0-59
|
||||
|
||||
Esempi di gating temporale:
|
||||
// Solo durante la sessione US (14:00-22:00 UTC)
|
||||
{{"op": "and", "args": [
|
||||
{{"op": "gt", "args": [{{"kind": "feature", "name": "hour"}}, {{"kind": "literal", "value": 14}}]}},
|
||||
{{"op": "lt", "args": [{{"kind": "feature", "name": "hour"}}, {{"kind": "literal", "value": 22}}]}}
|
||||
]}}
|
||||
|
||||
// Solo nel weekend (sab+dom)
|
||||
{{"op": "eq", "args": [{{"kind": "feature", "name": "is_weekend"}}, {{"kind": "literal", "value": 1}}]}}
|
||||
```
|
||||
|
||||
- [ ] **Step 6.2: Run existing hypothesis tests to verify prompt format still valid**
|
||||
|
||||
Run: `uv run pytest tests/unit/test_hypothesis_agent.py -v`
|
||||
Expected: All tests PASS. Il template `{feature_access}` continua a funzionare perché non lo abbiamo toccato.
|
||||
|
||||
- [ ] **Step 6.3: Commit**
|
||||
|
||||
```bash
|
||||
git add src/multi_swarm/agents/hypothesis.py
|
||||
git commit -m "feat(hypothesis): aggiungi feature temporali al prompt con 2 esempi few-shot"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 7: Smoke run end-to-end
|
||||
|
||||
**Files:**
|
||||
- Nessuna modifica al codice.
|
||||
|
||||
Validazione che il loop intero giri con la grammatica estesa: carica OHLCV, genera 4 genomi, compila, backtesta, valuta DSR, applica Adversarial, persiste.
|
||||
|
||||
- [ ] **Step 7.1: Run smoke script**
|
||||
|
||||
Run: `uv run python -m scripts.smoke_run`
|
||||
Expected: completamento senza eccezioni, output finale contenente `Smoke run completed`.
|
||||
|
||||
- [ ] **Step 7.2: Inspect at least one generated genome for temporal feature usage**
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
LATEST=$(sqlite3 runs.db "SELECT id FROM runs WHERE name LIKE 'smoke%' ORDER BY started_at DESC LIMIT 1;")
|
||||
sqlite3 runs.db "SELECT genome_id, substr(raw_text, 1, 600) FROM evaluations WHERE run_id='$LATEST' LIMIT 4;"
|
||||
```
|
||||
|
||||
Expected output: 4 righe raw_text JSON. Almeno 1 dovrebbe contenere `"name": "hour"`, `"name": "dow"`, `"name": "is_weekend"`, o `"name": "minute_of_hour"`. Se 0/4 usano feature temporali, il prompt non è abbastanza eloquente — apri un follow-up per iterare il prompt (non bloccante per questa PR).
|
||||
|
||||
- [ ] **Step 7.3: Push branch + open PR**
|
||||
|
||||
```bash
|
||||
git log --oneline -8 # verifica 6 commit dei Task 1-6
|
||||
git push origin HEAD
|
||||
```
|
||||
|
||||
Aprire PR con titolo `feat: feature temporali nella grammatica Hypothesis` referenziando lo spec.
|
||||
|
||||
---
|
||||
|
||||
## Self-review notes (autore del piano)
|
||||
|
||||
- Tutti i 7 hard requirement dello spec (`grammar`, `compiler`, `prompt`, 4 feature, integration test, smoke, backward compat) sono coperti dai Task 1-7.
|
||||
- Nessun placeholder `TBD`/`TODO`.
|
||||
- Tipi consistenti: `_TIME_FEATURE_FNS` definito una volta in Task 2 e referenziato implicitamente dai tester nei Task 3-5 senza bisogno di re-definizione.
|
||||
- Test pre-esistenti non vengono toccati; il Task 5 include `pytest` sull'intera suite del protocollo come regression check.
|
||||
- Backward compat: `KNOWN_FEATURES` cresce, il branch OHLCV resta invariato → genomi vecchi restano validi senza migrazione DB.
|
||||
@@ -1,427 +0,0 @@
|
||||
# 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.*
|
||||
@@ -1,183 +0,0 @@
|
||||
# Feature temporali nella grammatica Hypothesis — Design
|
||||
|
||||
**Data**: 11 maggio 2026
|
||||
**Status**: design approvato dall'operatore, pronto per writing-plans
|
||||
**Scope target**: Phase 2
|
||||
**Riferimenti**: `docs/decisions/2026-05-11-phase1-5-nemotron-run.md` (memo che ha originato la discussione)
|
||||
|
||||
---
|
||||
|
||||
## 1. Motivazione
|
||||
|
||||
Le strategie LLM-generate da Phase 1 operano in modo time-blind: la grammatica espone solo OHLCV (`open`, `high`, `low`, `close`, `volume`) e indicatori tecnici (`sma`, `rsi`, `atr`, `macd`, `realized_vol`) calcolati sopra. Non esiste alcuna feature che permetta al genoma di condizionare il comportamento sull'orario o sul giorno della settimana.
|
||||
|
||||
Questo è un limite strutturale rispetto a BTC-PERPETUAL su Cerbero, dove esistono effetti temporali sistematici:
|
||||
|
||||
- apertura USA (14:30 UTC) e Europa (08:00 UTC) generano volatilità sistematica;
|
||||
- apertura/chiusura settimanale crypto (Sabato/Domenica vs. resto della settimana) ha liquidità diversa e basis funding diverso;
|
||||
- la sessione asiatica overnight presenta pattern di trend reversal noti.
|
||||
|
||||
Il design seguente aggiunge alla grammatica quattro feature temporali — `hour`, `dow`, `is_weekend`, `minute_of_hour` — universalmente accessibili a ogni genoma, lasciando inalterati i meccanismi di mutation/crossover esistenti.
|
||||
|
||||
---
|
||||
|
||||
## 2. Decisioni di design
|
||||
|
||||
Le seguenti scelte sono state ratificate in fase di brainstorming.
|
||||
|
||||
**Quattro feature, non una.** `hour` da sola coprirebbe l'80% dei casi, ma `dow` cattura un asse ortogonale (weekend effect) e `is_weekend` è una scorciatoia espressiva utile al LLM. `minute_of_hour` è incluso per disponibilità futura (timeframe 5m/15m in Phase 2+), inerte sui dati 1h attuali.
|
||||
|
||||
**Accesso universale, non soggetto a `feature_access`.** Le feature temporali sono sempre disponibili a ogni genoma, indipendentemente dal subset OHLCV randomizzato in `ga/initial.py` e mutato da `mutate_feature_access`. Motivo: vogliamo che ogni genoma possa testarle; passarle attraverso `FEATURE_POOL` rischia di lasciarle inutilizzate in metà della popolazione e vanificare l'esperimento. Il prompt indica esplicitamente che sono "sempre accessibili", separate dalla sezione `{feature_access}` del template.
|
||||
|
||||
**Riuso di `FeatureNode`, niente nuovo tipo AST.** Le feature temporali entrano nella stessa whitelist `KNOWN_FEATURES` di OHLCV e usano la stessa shape JSON `{"kind": "feature", "name": "..."}`. Il dispatcher in `compiler.py` discrimina per nome. Alternativa scartata: introdurre `TimeFeatureNode` separato. Avrebbe dato type-safety formale ma richiesto modifiche a parser, validator, JSON shape, prompt — costo eccessivo per beneficio puramente strutturale, dato che semanticamente "ora del giorno" e "prezzo close" sono entrambi attributi della riga.
|
||||
|
||||
**Few-shot examples nel prompt.** L'istruzione minimale (solo nomi) lascia troppo spazio a interpretazioni errate (es. `dow=7` per domenica all'italiana, `hour` in fuso locale invece che UTC). Due esempi concreti — un gating intraday `gt hour 14 AND lt hour 22`, un gating settimanale `eq is_weekend 1` — fissano la semantica al costo di ~200 token addizionali per call.
|
||||
|
||||
**Out-of-range non è errore di validazione.** Il LLM potrebbe emettere `gt hour 25` o `eq dow 7`. Il validator non li intercetta: tecnicamente sono `LiteralNode(value=...)` numerici legali. La condizione sarà semplicemente sempre falsa e l'Adversarial layer (`flat_too_long`, `no_trades`) sanzionerà i genomi che ne sono dipendenti. Aggiungere un check range esplicito sarebbe over-engineering per un caso che il sistema già gestisce.
|
||||
|
||||
---
|
||||
|
||||
## 3. Architettura — modifiche file-by-file
|
||||
|
||||
Cinque file toccati. Nessun nuovo modulo.
|
||||
|
||||
### `src/multi_swarm/protocol/grammar.py`
|
||||
|
||||
Estendere `KNOWN_FEATURES` da 5 a 9 nomi:
|
||||
|
||||
```python
|
||||
KNOWN_FEATURES: frozenset[str] = frozenset(
|
||||
{"open", "high", "low", "close", "volume",
|
||||
"hour", "dow", "is_weekend", "minute_of_hour"}
|
||||
)
|
||||
```
|
||||
|
||||
Nessun'altra modifica al file. Il validator legge da qui automaticamente.
|
||||
|
||||
### `src/multi_swarm/protocol/compiler.py`
|
||||
|
||||
Aggiungere un dizionario di derivazioni temporali ed estendere il dispatcher di `FeatureNode` con un branch prioritario:
|
||||
|
||||
```python
|
||||
_TIME_FEATURE_FNS: dict[str, Callable[[pd.DatetimeIndex], pd.Series]] = {
|
||||
"hour": lambda idx: pd.Series(idx.hour, index=idx, dtype="int64"),
|
||||
"dow": lambda idx: pd.Series(idx.dayofweek, index=idx, dtype="int64"),
|
||||
"is_weekend": lambda idx: pd.Series((idx.dayofweek >= 5).astype("int64"), index=idx),
|
||||
"minute_of_hour": lambda idx: pd.Series(idx.minute, index=idx, dtype="int64"),
|
||||
}
|
||||
|
||||
# nel branch FeatureNode di _eval_node:
|
||||
if isinstance(node, FeatureNode):
|
||||
if node.name in _TIME_FEATURE_FNS:
|
||||
return _TIME_FEATURE_FNS[node.name](df.index)
|
||||
return df[node.name]
|
||||
```
|
||||
|
||||
Il branch OHLCV preesistente (`return df[node.name]`) resta invariato come fallback per i nomi non temporali. Si assume `df.index` di tipo `DatetimeIndex` UTC, già garantito da `CerberoOHLCVLoader`.
|
||||
|
||||
### `src/multi_swarm/agents/hypothesis.py`
|
||||
|
||||
Aggiungere nel prompt template, dopo la sezione "Leaf - feature OHLCV" (intorno a riga 84), una sezione "Leaf - feature TEMPORALI" con i quattro nomi, i loro range, e due esempi few-shot completi (gating sessione US, gating weekend). Mantenere la sezione separata da `{feature_access}` e dichiarare esplicitamente che le feature temporali sono "sempre accessibili". Contenuto preciso definito nella sezione 5 di questo spec.
|
||||
|
||||
### `tests/protocol/test_compiler.py`
|
||||
|
||||
Cinque test nuovi:
|
||||
|
||||
1. `test_compile_hour_feature_returns_index_hour` — DataFrame 24-bar con index orario, `FeatureNode("hour")` restituisce serie `[0,1,...,23]`.
|
||||
2. `test_compile_dow_feature_lunedi_is_zero` — verifica convenzione pandas (lunedì → 0, domenica → 6).
|
||||
3. `test_compile_is_weekend_returns_zero_one` — sabato e domenica → 1, altri → 0.
|
||||
4. `test_compile_minute_of_hour_zero_on_1h_timeframe` — su index 1h tutti gli output sono 0 (test di regressione del comportamento atteso).
|
||||
5. `test_rule_with_temporal_gating_compiles_and_executes` — integrazione: regola `entry-long if hour > 14 AND close > sma(20)`, verifica che `Side.LONG` appaia solo nelle bar con `hour > 14`.
|
||||
|
||||
### `tests/protocol/test_validator.py`
|
||||
|
||||
Due test nuovi:
|
||||
|
||||
1. `test_validator_accepts_temporal_features` — i quattro nuovi nomi non sollevano `ValidationError`.
|
||||
2. `test_validator_rejects_temporal_typo` — `FeatureNode("weekday")` solleva `ValidationError`.
|
||||
|
||||
Test esistenti non devono cambiare. L'aggiunta è puramente additiva.
|
||||
|
||||
---
|
||||
|
||||
## 4. Contratto delle feature
|
||||
|
||||
| Feature | Tipo | Range | Derivazione pandas |
|
||||
|---------|------|-------|---------------------|
|
||||
| `hour` | int64 | 0–23 | `df.index.hour` |
|
||||
| `dow` | int64 | 0–6 (lun=0) | `df.index.dayofweek` |
|
||||
| `is_weekend` | int64 | 0 o 1 | `(df.index.dayofweek >= 5).astype(int)` |
|
||||
| `minute_of_hour` | int64 | 0–59 | `df.index.minute` |
|
||||
|
||||
L'indice del DataFrame è UTC tz-aware per costruzione (`CerberoOHLCVLoader`). I valori temporali sono quindi in UTC, non in fuso locale italiano. Questa scelta è coerente con la convenzione di prezzi e timestamp del progetto e con la natura globale del mercato crypto.
|
||||
|
||||
I confronti tipici emessi dal LLM saranno della forma `{"op": "gt", "args": [{"kind": "feature", "name": "hour"}, {"kind": "literal", "value": 14}]}`. Funzionano via broadcasting numpy senza modifiche a comparator o operator nodes.
|
||||
|
||||
---
|
||||
|
||||
## 5. Frammento di prompt aggiunto
|
||||
|
||||
Da inserire in `hypothesis.py` dopo l'attuale sezione "Leaf - feature OHLCV":
|
||||
|
||||
```text
|
||||
Leaf - feature TEMPORALI (sempre accessibili, UTC):
|
||||
{{"kind": "feature", "name": "hour"}} range 0-23
|
||||
{{"kind": "feature", "name": "dow"}} range 0-6 (lun=0, dom=6)
|
||||
{{"kind": "feature", "name": "is_weekend"}} 0 o 1
|
||||
{{"kind": "feature", "name": "minute_of_hour"}} range 0-59
|
||||
|
||||
Esempi di gating temporale:
|
||||
// Solo durante la sessione US (14:00-22:00 UTC)
|
||||
{{"op": "and", "args": [
|
||||
{{"op": "gt", "args": [{{"kind": "feature", "name": "hour"}}, {{"kind": "literal", "value": 14}}]}},
|
||||
{{"op": "lt", "args": [{{"kind": "feature", "name": "hour"}}, {{"kind": "literal", "value": 22}}]}}
|
||||
]}}
|
||||
|
||||
// Solo nel weekend (sab+dom)
|
||||
{{"op": "eq", "args": [{{"kind": "feature", "name": "is_weekend"}}, {{"kind": "literal", "value": 1}}]}}
|
||||
```
|
||||
|
||||
Il blocco va inserito **prima** della frase corrente "Feature accessibili dal tuo genoma: {feature_access}", per chiarire che `{feature_access}` riguarda solo OHLCV mentre le temporali sono universali.
|
||||
|
||||
---
|
||||
|
||||
## 6. Backward compatibility e impatto sui run esistenti
|
||||
|
||||
Tutti i genomi esistenti nei `runs.db` storici (Phase 1, Phase 1.5 nemotron, Phase 1.5 grok in corso) usano solo feature OHLCV. Con la grammatica estesa restano validi: il validator continua ad accettarli, il compiler li gestisce nel branch OHLCV invariato.
|
||||
|
||||
Non c'è quindi alcuna migrazione di dati. I run vecchi possono essere ri-letti dalla dashboard senza modifiche. La distinzione "run pre/post feature temporali" sarà tracciata implicitamente dalla data del commit di merge.
|
||||
|
||||
---
|
||||
|
||||
## 7. Validazione end-to-end
|
||||
|
||||
Dopo il merge dei cinque file, la procedura di validazione è:
|
||||
|
||||
1. Esecuzione test suite completa (`uv run pytest`) — i 7 nuovi test devono passare, nessun test esistente deve rompersi.
|
||||
2. `scripts/smoke_run.py` con `population_size=4, n_generations=1` per verificare che il loop end-to-end completi (caricamento OHLCV → generazione genome → compile → backtest → DSR → adversarial → persistenza). Tempo atteso ~2 minuti.
|
||||
3. Ispezione manuale di almeno 1 genoma generato post-merge: verificare che il LLM abbia effettivamente usato almeno una feature temporale tra le sue regole. Se in 4 genomi nessuno usa feature temporali, ri-esaminare il prompt.
|
||||
|
||||
Non è previsto un confronto ablation formale (con/senza feature temporali) in questo spec — è un'attività di Phase 2 separata che andrà pianificata in un proprio spec quando si avvierà il run di valutazione.
|
||||
|
||||
---
|
||||
|
||||
## 8. Out of scope
|
||||
|
||||
I seguenti elementi sono esplicitamente fuori dallo scope di questo spec e dovranno essere oggetto di design dedicato se desiderati:
|
||||
|
||||
- **Feature temporali con segno periodico** (es. `sin_hour`, `cos_dow`): utili per regressioni continue, non per regole booleane GA-based. Skip.
|
||||
- **Feature di sessione discreta** (es. `session=us|europe|asia`): derivabili componendo `hour` con comparator, non necessario aggiungere come feature primitiva.
|
||||
- **Time-zone configurabile**: rimane fissa UTC. Cambiare implica refactor del loader OHLCV.
|
||||
- **Validator range-check** (es. rifiutare `gt(dow, 6)`): sanzionato già dal loop GA via fitness e Adversarial.
|
||||
- **Modifica del meccanismo `mutate_feature_access`**: invariato. Le feature temporali non entrano nel pool mutabile.
|
||||
- **Indicatori temporali** (es. `time_since_last_high`): richiede stato persistente, fuori dal modello stateless attuale.
|
||||
|
||||
---
|
||||
|
||||
## 9. Stima di sforzo
|
||||
|
||||
Implementazione: ~120 LOC (60 di codice + 60 di test) in 5 file. Complessità bassa.
|
||||
|
||||
TDD-driven: scrivere prima i 7 test, verificare che falliscano, poi aggiungere whitelist + dispatcher + prompt. Tempo stimato: 2-3 ore di lavoro continuo, validation smoke run inclusa.
|
||||
|
||||
Costo prompt addizionale per call: ~200 token. Su un run da 200 call, ~40k token aggiuntivi → impatto economico trascurabile (<$0.05 con qualsiasi tier).
|
||||
@@ -1,831 +0,0 @@
|
||||
# PoC Trading Swarm — Validazione Strategica
|
||||
|
||||
**Autore**: Adriano Dal Pastro
|
||||
**Data**: Maggio 2026
|
||||
**Status**: Design document — pre-implementazione
|
||||
**Versione**: 0.1
|
||||
**Documento correlato**: `coevolutive_swarm_system.md` (sistema completo)
|
||||
|
||||
---
|
||||
|
||||
## 1. Razionale della deviazione
|
||||
|
||||
Invece di committere 12-18 mesi al sistema co-evolutivo completo descritto nel documento principale, partiamo con un **proof-of-concept strategico** focalizzato su trading, con architettura semplificata, per validare empiricamente se l'idea di base funziona prima di investire nel sistema full.
|
||||
|
||||
**Cosa il PoC valida**:
|
||||
1. Lo swarm produce strategie che superano il null hypothesis statistico (Deflated Sharpe Ratio significativo)?
|
||||
2. Le strategie sono qualitativamente diverse o cloni leggeri?
|
||||
3. Le strategie sopravvivono al regime change out-of-sample?
|
||||
4. Quanto del successo viene da modelli costosi vs economici (ablation multi-tier)?
|
||||
5. Lo swarm batte una baseline statistica tradizionale (random forest + feature engineering)?
|
||||
|
||||
**Tempo target**: 3-4 mesi a impegno significativo.
|
||||
**Budget LLM target**: $2-4K.
|
||||
|
||||
**Decisione post-PoC**:
|
||||
- Se passa tutti i 5 test → procedere con sistema completo (documento principale)
|
||||
- Se passa parzialmente → iterare sul PoC, identificare bottleneck
|
||||
- Se non passa → riformulare. Forse l'edge degli LLM agents è in altri domini, non in pattern discovery numerico
|
||||
|
||||
---
|
||||
|
||||
## 2. Architettura semplificata
|
||||
|
||||
### 2.1 Cosa cambia rispetto al sistema completo
|
||||
|
||||
| Aspetto | Sistema completo | PoC |
|
||||
|------------------------|-----------------------------|------------------------------------|
|
||||
| Popolazioni evolventi | 4 (3 layer + protocollo) | 1 (solo Hypothesis) |
|
||||
| Hypothesis layer | Evolve via GA | Evolve via GA (K=50) |
|
||||
| Falsification layer | Evolve via GA | Hand-crafted, 1 agente fisso |
|
||||
| Adversarial layer | Evolve via GA | Hand-crafted, 1 agente fisso |
|
||||
| Protocollo | Co-evolve | Fisso, designed manualmente |
|
||||
| Domini di applicazione | Multipli | Solo trading BTC/ETH |
|
||||
| Idiom emergence | Sì | No |
|
||||
| Speciation | Sì | Versione semplificata (clustering base) |
|
||||
| Tier multi-model | Sì (S/A/B/C/D) | Sì (semplificato a B/C principalmente) |
|
||||
| Human-in-the-loop | Strutturato ogni 20 gen | Review settimanale informale |
|
||||
|
||||
**Filosofia**: massimizzare apprendimento, minimizzare complessità implementativa.
|
||||
|
||||
### 2.2 Schema architetturale
|
||||
|
||||
```
|
||||
┌───────────────────────────────────┐
|
||||
│ PROTOCOLLO FISSO (S-expression) │
|
||||
│ ~15 verbi designed manualmente │
|
||||
└─────────────┬─────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ HYPOTHESIS SWARM │ ← UNICO layer che evolve
|
||||
│ K=50 agenti │
|
||||
│ Tier mix: B/C │
|
||||
│ GA: tournament, │
|
||||
│ speciation base, │
|
||||
│ novelty bonus │
|
||||
└──────────┬───────────┘
|
||||
│ ipotesi formalizzate
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ FALSIFICATION (hand) │ ← FISSO
|
||||
│ 1 agente Tier-B │
|
||||
│ Funzione: traduce │
|
||||
│ ipotesi in regole + │
|
||||
│ chiama backtest + │
|
||||
│ valuta con DSR │
|
||||
└──────────┬───────────┘
|
||||
│ strategie validate
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ ADVERSARIAL (hand) │ ← FISSO
|
||||
│ 1 agente Tier-A │
|
||||
│ Funzione: red team │
|
||||
│ con checklist statica│
|
||||
│ (lookahead, regime, │
|
||||
│ crowding) │
|
||||
└──────────┬───────────┘
|
||||
│ strategie sopravvissute
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ FITNESS LOOP │
|
||||
│ Update agent_fitness│
|
||||
│ Selezione + GA │
|
||||
└──────────────────────┘
|
||||
│
|
||||
▼
|
||||
Generazione N+1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Le quattro trappole del backtesting su crypto
|
||||
|
||||
Queste sono le killer specifiche del dominio. Vanno mitigate by design, non come afterthought.
|
||||
|
||||
### 3.1 Look-ahead bias subdolo
|
||||
|
||||
**Problema**: molti dati "storici" su crypto sono in realtà revisionati ex-post.
|
||||
- Funding rates: spesso medie giornaliere ricalcolate, non valori real-time storici
|
||||
- On-chain metrics (MVRV, NUPL, SOPR): formule che cambiano nel tempo, applicate retroattivamente
|
||||
- Liste top-N token: survivorship bias massiccio
|
||||
- Sentiment storico: ricostruzioni post-hoc, non disponibili in tempo reale a quei momenti
|
||||
|
||||
**Mitigazione**:
|
||||
- Ogni feature deve avere un campo `availability_lag`: quante ore dopo il timestamp T la feature era effettivamente disponibile
|
||||
- Backtest engine rifiuta di usare feature prima del lag
|
||||
- Documentazione esplicita di come/quando ogni feature è stata raccolta
|
||||
- Preferire fonti che pubblicano archivi real-time (Kaiko, Tardis.dev, Amberdata) a quelle ricostruite
|
||||
|
||||
### 3.2 Multiple testing su scala industriale
|
||||
|
||||
**Problema**: con 10000 strategie testate, ~100 superano p<0.01 per puro caso. Senza correzione, il sistema produce sempre "vincitori" illusori.
|
||||
|
||||
**Mitigazione**:
|
||||
- **Deflated Sharpe Ratio (DSR)** come fitness primaria, non Sharpe naive
|
||||
- Tracking del numero totale di strategie testate fino a generazione N (impatta DSR)
|
||||
- Bonferroni-style correction quando si seleziona "top strategies" da reporting
|
||||
- Hold-out set finale **mai toccato durante evoluzione** per validation finale
|
||||
|
||||
### 3.3 Regime dependency
|
||||
|
||||
**Problema**: BTC/ETH hanno regimi macro molto diversi. Una strategia che funziona 2018-2024 può essere semplicemente "long-only momentum con leva". OOS 2026 fallisce.
|
||||
|
||||
**Periodi di regime distintivi**:
|
||||
- 2017: bull mania retail (escluso dal dataset, troppo anomalo)
|
||||
- 2018-2019: bear lungo
|
||||
- 2020-2021: DeFi summer + bull istituzionale + COVID
|
||||
- 2022: collapse cycle (LUNA, FTX, Celsius)
|
||||
- 2023-2024: ripresa + ETF spot
|
||||
- 2025-2026: post-ETF, regime nuovo
|
||||
|
||||
**Mitigazione**:
|
||||
- Walk-forward con **purged cross-validation** (López de Prado 2018)
|
||||
- Train su finestra mobile, test su successiva, **gap di purging** in mezzo per evitare leakage
|
||||
- Fitness penalizza strategie che funzionano solo su 1-2 regimi
|
||||
- OOS finale obbligatoriamente su periodo diverso dal training
|
||||
|
||||
### 3.4 Backtest ≠ live execution
|
||||
|
||||
**Problema**: anche backtest perfetto ha gap col live.
|
||||
- Slippage non lineare con size (su crypto particolarmente)
|
||||
- Fees variabili (maker/taker, volume rebates)
|
||||
- Funding rate sui perp può mangiarsi l'edge
|
||||
- Liquidità evapora nei momenti che contano
|
||||
- API outages, exchange downtime
|
||||
|
||||
**Mitigazione**:
|
||||
- Modello di slippage realistico (Almgren-Chriss o simile, non costante)
|
||||
- Fees accurate (struttura tier per exchange)
|
||||
- Funding payments simulati per posizioni perp
|
||||
- Cap su size per evitare strategie che funzionano solo a $100, non a $100K
|
||||
|
||||
---
|
||||
|
||||
## 4. Dataset Specification
|
||||
|
||||
### 4.1 Coverage
|
||||
|
||||
- **Asset**: BTC, ETH (focus iniziale)
|
||||
- **Periodo**: 2018-01-01 → 2025-12-31
|
||||
- **Train/OOS split**: train 2018-2023, OOS validation 2024, OOS final hold-out 2025
|
||||
- **Frequenza base**: 1-hour bars (compromesso tra granularità e gestibilità)
|
||||
- **Frequenze derivate**: 4h, 1d aggregate per features di lungo periodo
|
||||
|
||||
### 4.2 Feature catalog
|
||||
|
||||
**Price/Volume (sempre disponibili real-time, lag=0)**:
|
||||
- OHLCV su 1h, 4h, 1d
|
||||
- Returns log su orizzonti multipli
|
||||
- Volatility realized (Garman-Klass, Parkinson, RV)
|
||||
- Volume profile, VWAP
|
||||
|
||||
**Derivatives (lag tipicamente 5-15min)**:
|
||||
- Funding rates (Bybit, Binance, Hyperliquid, Deribit)
|
||||
- Open Interest (per exchange e aggregato)
|
||||
- Put/Call ratio (Deribit options)
|
||||
- Implied volatility surface (Deribit)
|
||||
- Skew, term structure
|
||||
- Liquidations (volume e direzione)
|
||||
|
||||
**On-chain (lag tipicamente 1-6 ore per finalization)**:
|
||||
- Active addresses
|
||||
- Transaction count + volume
|
||||
- Exchange inflows/outflows (Glassnode-style)
|
||||
- Miner flows
|
||||
- Whale transactions (>$1M)
|
||||
- MVRV, NUPL, SOPR (con cautela su revisionalità)
|
||||
|
||||
**Macro context (lag variabile)**:
|
||||
- DXY, gold, S&P 500, yield 10Y (per correlazioni)
|
||||
- Crypto-specific: BTC dominance, ETH/BTC ratio, total market cap
|
||||
- Stablecoin supply (USDT, USDC, DAI)
|
||||
|
||||
**Sentiment (lag variabile, qualità incerta)**:
|
||||
- Funding rate come proxy sentiment
|
||||
- Open Interest variations come proxy speculation
|
||||
- (Skip Twitter/social per ora — qualità storica troppo bassa)
|
||||
|
||||
### 4.3 Data sources
|
||||
|
||||
**Preferiti** (real-time archivi):
|
||||
- Tardis.dev (derivatives, order book, trades — premium)
|
||||
- Kaiko (institutional grade — premium)
|
||||
- Amberdata (multi-source)
|
||||
|
||||
**Backup gratuiti/cheap**:
|
||||
- CCXT historical (OHLCV affidabile)
|
||||
- Binance/Bybit/Deribit API direct (con cautela su gap)
|
||||
- CoinGlass (derivatives aggregati, qualità media)
|
||||
- Glassnode free tier (on-chain, limitato)
|
||||
|
||||
**Da evitare**:
|
||||
- Aggregatori che non documentano metodologia
|
||||
- Source che hanno cambiato formula nel tempo senza versioning
|
||||
|
||||
### 4.4 Storage
|
||||
|
||||
```sql
|
||||
CREATE TABLE features (
|
||||
timestamp TIMESTAMPTZ NOT NULL,
|
||||
asset TEXT NOT NULL,
|
||||
feature_name TEXT NOT NULL,
|
||||
value DOUBLE PRECISION,
|
||||
availability_lag_seconds INT NOT NULL, -- CRITICO
|
||||
source TEXT,
|
||||
version TEXT, -- per gestire cambi di metodologia
|
||||
PRIMARY KEY (timestamp, asset, feature_name)
|
||||
);
|
||||
|
||||
CREATE INDEX idx_feat_time ON features (timestamp);
|
||||
CREATE INDEX idx_feat_asset_name ON features (asset, feature_name);
|
||||
```
|
||||
|
||||
Considerare TimescaleDB se le query temporali diventano colli di bottiglia.
|
||||
|
||||
---
|
||||
|
||||
## 5. Backtest Engine
|
||||
|
||||
### 5.1 Requisiti
|
||||
|
||||
- **Determinismo**: stesso input, stesso output, sempre
|
||||
- **Velocità**: target ≥100 backtest/sec su CPU normale (per gestire 50 agenti × 10 ipotesi/gen)
|
||||
- **Anti-leakage by design**: rifiuta feature prima di availability_lag
|
||||
- **Walk-forward integrato**: non opzionale, parte del flow base
|
||||
- **Realistic execution**: slippage, fees, funding
|
||||
|
||||
### 5.2 Architettura
|
||||
|
||||
**Linguaggio**: Python+NumPy per il PoC. Rust+PyO3 solo se diventa bottleneck (probabile in fase scaling, non necessario per PoC).
|
||||
|
||||
**API base**:
|
||||
```python
|
||||
class BacktestEngine:
|
||||
def run(self,
|
||||
strategy: StrategySpec,
|
||||
features: FeatureSet,
|
||||
time_range: tuple[datetime, datetime],
|
||||
walk_forward_config: WFConfig) -> BacktestResult:
|
||||
...
|
||||
|
||||
def run_with_dsr(self,
|
||||
strategy: StrategySpec,
|
||||
...) -> tuple[BacktestResult, DSRStats]:
|
||||
...
|
||||
|
||||
@dataclass
|
||||
class StrategySpec:
|
||||
entry_rules: list[Rule] # condizioni di ingresso
|
||||
exit_rules: list[Rule] # condizioni di uscita
|
||||
sizing: SizingRule # position sizing
|
||||
instruments: list[str] # BTC, ETH, BTC-PERP, etc.
|
||||
constraints: list[Constraint] # max leverage, max DD, etc.
|
||||
|
||||
@dataclass
|
||||
class BacktestResult:
|
||||
pnl_curve: pd.Series
|
||||
sharpe: float
|
||||
sortino: float
|
||||
max_drawdown: float
|
||||
n_trades: int
|
||||
win_rate: float
|
||||
avg_holding_time: timedelta
|
||||
fees_paid: float
|
||||
funding_paid: float
|
||||
slippage_cost: float
|
||||
regime_breakdown: dict[str, float] # PnL per regime
|
||||
```
|
||||
|
||||
### 5.3 Execution model
|
||||
|
||||
**Slippage**:
|
||||
```
|
||||
slippage = base_spread + impact_factor * (size / avg_volume_5min) ^ 0.5
|
||||
```
|
||||
Calibrato su book reale per BTC/ETH. Più alto in regimi di alta volatilità.
|
||||
|
||||
**Fees**:
|
||||
- Maker: 0.02% (tipico)
|
||||
- Taker: 0.05% (tipico)
|
||||
- Tier per volume non simulato nel PoC (assume tier base)
|
||||
|
||||
**Funding** (per perp):
|
||||
- Pagato/ricevuto ogni 8 ore
|
||||
- Calcolato su mark price × position size × funding rate
|
||||
|
||||
**Constraints automatiche**:
|
||||
- Max leverage (configurabile, default 5x per il PoC)
|
||||
- Margin call simulati realisticamente
|
||||
- Liquidations forzate se margin scende sotto threshold
|
||||
|
||||
### 5.4 Walk-forward purged CV
|
||||
|
||||
```
|
||||
Time: |---------train-----------|gap|----test----|---next gap---|--next test--|
|
||||
Window 1: [2018-01 ──────── 2020-06] [2020-07 ──── 2020-12]
|
||||
Window 2: [2018-07 ──── 2021-06] [2021-07 ──── 2021-12]
|
||||
Window 3: [2019-01 ── 2022-06] [2022-07 ── 2022-12]
|
||||
...
|
||||
```
|
||||
|
||||
- Training window: 30 mesi
|
||||
- Gap (purging): 1 mese (evita leakage da event horizon)
|
||||
- Test window: 6 mesi
|
||||
- Step: 6 mesi
|
||||
- Embargo: ulteriori 2 settimane post-test prima del prossimo training (López de Prado embargo)
|
||||
|
||||
---
|
||||
|
||||
## 6. Hypothesis Swarm (l'unico layer che evolve)
|
||||
|
||||
### 6.1 Genome design
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class HypothesisAgentGenome:
|
||||
# Cognizione
|
||||
system_prompt: str
|
||||
cognitive_style: str # "physicist", "biologist", "engineer", "trader_oldschool"...
|
||||
|
||||
# Accesso a dati
|
||||
feature_access: list[str] # subset delle feature disponibili
|
||||
lookback_window_days: int # quanto storico vede
|
||||
timeframes: list[str] # ["1h", "4h", "1d"]
|
||||
|
||||
# Modello
|
||||
model_tier: ModelTier # B o C principalmente nel PoC
|
||||
temperature: float # 0.6 - 1.2
|
||||
|
||||
# Bias di output
|
||||
strategy_type_preference: list[str] # ["mean_reversion", "momentum", "vol_arb", "cross_asset"]
|
||||
timeframe_preference: str # "intraday", "swing", "position"
|
||||
|
||||
# Tracking
|
||||
parent_ids: list[UUID]
|
||||
generation: int
|
||||
species_id: UUID
|
||||
```
|
||||
|
||||
### 6.2 Output format (nel protocollo fisso)
|
||||
|
||||
```
|
||||
PROPOSE_STRATEGY(
|
||||
id=#strat_47,
|
||||
name="vol_skew_momentum",
|
||||
|
||||
entry_conditions=[
|
||||
AND(
|
||||
(deribit_skew_25d > rolling_mean(deribit_skew_25d, 30d) + 1.5*std),
|
||||
(btc_funding_8h > 0.01),
|
||||
(eth_funding_8h > btc_funding_8h)
|
||||
)
|
||||
],
|
||||
|
||||
exit_conditions=[
|
||||
OR(
|
||||
(skew normalized below mean),
|
||||
(max_holding > 7d),
|
||||
(drawdown > 0.03)
|
||||
)
|
||||
],
|
||||
|
||||
sizing=KELLY_FRACTIONAL(fraction=0.25),
|
||||
instruments=["ETH-PERP-HL"],
|
||||
side="long",
|
||||
|
||||
rationale="Skew elevato indica fear di puts, funding alto indica long crowding. Cross-section ETH/BTC funding suggerisce ETH outperformance attesa.",
|
||||
|
||||
expected_regime="normal volatility, trending",
|
||||
expected_failure_modes=["crash con depinning", "regime shift improvviso"]
|
||||
)
|
||||
```
|
||||
|
||||
### 6.3 Operatori genetici
|
||||
|
||||
**Mutazione del system prompt**:
|
||||
- LLM-as-mutator (Tier-B): "Modifica questo prompt cambiando un aspetto cognitivo, mantenendo intent"
|
||||
- Probabilità: 60% per agente selezionato
|
||||
|
||||
**Mutazione di feature_access**:
|
||||
- Add/remove 1-3 feature random
|
||||
- Probabilità: 30%
|
||||
|
||||
**Mutazione di temperature**:
|
||||
- Gaussiana, σ=0.1, clip [0.3, 1.4]
|
||||
- Probabilità: 20%
|
||||
|
||||
**Crossover**:
|
||||
- 50/50 di feature_access da due parent
|
||||
- Cognitive_style preso da parent migliore
|
||||
- System prompt: crossover sezione-by-sezione (role/context/instructions/output_format)
|
||||
- Probabilità: 50% per nuova generazione (resto è mutazione)
|
||||
|
||||
**Mutazione di model_tier**:
|
||||
- Rara (5%), perché impatta costo
|
||||
- Solo C↔B, non promozioni a A senza fitness eccezionale
|
||||
|
||||
### 6.4 Selection
|
||||
|
||||
**Tournament selection**, k=5.
|
||||
|
||||
**Speciation semplificata**:
|
||||
- Embedding del system prompt via Voyage o OpenAI ada
|
||||
- K-means con K=5-7 cluster
|
||||
- Fitness sharing dentro cluster
|
||||
|
||||
**Elitismo**: top 3 agenti per cluster sopravvivono non modificati.
|
||||
|
||||
**Immigrazione**: ogni 10 generazioni, 5 nuovi agenti random vengono inseriti (anti-stagnazione).
|
||||
|
||||
---
|
||||
|
||||
## 7. Falsification Agent (hand-crafted, fisso)
|
||||
|
||||
### 7.1 Ruolo
|
||||
|
||||
Prende ipotesi dal swarm, le esegue su backtest engine, riporta risultati con DSR e diagnostica.
|
||||
|
||||
**NON** valuta soggettivamente. Esegue test deterministici e li interpreta.
|
||||
|
||||
### 7.2 Modello
|
||||
|
||||
Tier-B (Qwen Max o equivalente). Sufficiente per:
|
||||
- Tradurre ipotesi in linguaggio naturale → StrategySpec strutturato
|
||||
- Chiamare backtest engine
|
||||
- Interpretare output numerico
|
||||
- Riportare in protocollo
|
||||
|
||||
### 7.3 System prompt template
|
||||
|
||||
```
|
||||
Sei un agente di falsification rigoroso. Il tuo ruolo è testare ipotesi
|
||||
trading senza pregiudizi e riportare risultati onesti.
|
||||
|
||||
Per ogni ipotesi ricevuta:
|
||||
1. Verifica che le entry/exit conditions siano formalizzabili in regole testabili
|
||||
2. Verifica che le feature richieste rispettino availability_lag
|
||||
3. Chiama il backtest engine con configurazione walk-forward standard
|
||||
4. Calcola Deflated Sharpe Ratio considerando il numero di test fatti finora ({total_trials})
|
||||
5. Riporta breakdown per regime (bear/bull/sideways)
|
||||
6. Identifica failure modes osservati nel backtest
|
||||
|
||||
Output strict in protocollo S-expression. Nessuna interpretazione narrativa.
|
||||
Se l'ipotesi non è formalizzabile, ritorna REJECT con motivo specifico.
|
||||
```
|
||||
|
||||
### 7.4 Output format
|
||||
|
||||
```
|
||||
REPORT_BACKTEST(
|
||||
target=#strat_47,
|
||||
|
||||
metrics=(
|
||||
sharpe=1.34,
|
||||
deflated_sharpe=0.87,
|
||||
p_value=0.04,
|
||||
max_drawdown=0.18,
|
||||
n_trades=143,
|
||||
avg_holding_h=42
|
||||
),
|
||||
|
||||
regime_performance=(
|
||||
bear_2018=0.42,
|
||||
bull_2020=2.1,
|
||||
crash_2022=-0.85,
|
||||
recovery_2023=1.1
|
||||
),
|
||||
|
||||
warnings=[
|
||||
"Performance dominated by 2020-2021 regime",
|
||||
"DSR significant but multiple testing burden high (8400 strategies tested)"
|
||||
],
|
||||
|
||||
verdict=PASS_WITH_WARNINGS // PASS / FAIL / PASS_WITH_WARNINGS
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. Adversarial Agent (hand-crafted, fisso)
|
||||
|
||||
### 8.1 Ruolo
|
||||
|
||||
Per ogni strategia che passa Falsification, applica una **checklist statica** di attacchi epistemici.
|
||||
|
||||
Nel PoC NON evolve. Ha vocabolario fisso di attacchi noti dalla letteratura (López de Prado, Bailey, etc.).
|
||||
|
||||
### 8.2 Modello
|
||||
|
||||
Tier-A (Sonnet). Qui il reasoning conta — riconoscere lookahead bias subtle richiede capacità.
|
||||
|
||||
### 8.3 Checklist di attacchi
|
||||
|
||||
```
|
||||
1. Lookahead bias check
|
||||
- Tutte le feature usate rispettano availability_lag?
|
||||
- Qualche feature è "future-derived" subdolamente?
|
||||
|
||||
2. Survivorship bias check
|
||||
- La strategia usa universo di asset dinamico?
|
||||
- Filtra solo asset sopravvissuti?
|
||||
|
||||
3. Regime dependency check
|
||||
- Performance concentrata in 1-2 regimi specifici?
|
||||
- Cosa succede se rimuovi il regime migliore?
|
||||
|
||||
4. Multiple testing severity
|
||||
- DSR resta significativo dopo Bonferroni stretto?
|
||||
- Confronto con random strategy baseline
|
||||
|
||||
5. Crowding plausibility
|
||||
- La logica è "ovvia"? Probabilmente già crowded
|
||||
- Edge size ragionevole o sospettosamente alto?
|
||||
|
||||
6. Implementation friction
|
||||
- Slippage assumption realistica per la size?
|
||||
- Funding payments inclusi correttamente?
|
||||
- Trade frequency compatibile con execution reale?
|
||||
|
||||
7. Feature stability
|
||||
- Le feature critiche hanno stessa metodologia in tutto il periodo?
|
||||
- Source provider ha cambiato formula?
|
||||
|
||||
8. Statistical robustness
|
||||
- Sharpe sensibile a rimozione top 5% trade?
|
||||
- Performance robusta a perturbazioni piccole nei parametri?
|
||||
```
|
||||
|
||||
### 8.4 Output
|
||||
|
||||
```
|
||||
ADVERSARIAL_REVIEW(
|
||||
target=#strat_47,
|
||||
attacks_passed=[1, 2, 5, 6, 7],
|
||||
attacks_failed=[3, 4, 8],
|
||||
|
||||
critical_concerns=[
|
||||
CONCERN(
|
||||
type=regime_dependency,
|
||||
severity=high,
|
||||
detail="60% of PnL from 2020-2021 bull regime. Removing it gives Sharpe 0.4."
|
||||
),
|
||||
CONCERN(
|
||||
type=multiple_testing,
|
||||
severity=medium,
|
||||
detail="DSR significant but only marginally (p=0.04). With 8400 trials, expect ~336 false positives at this level."
|
||||
)
|
||||
],
|
||||
|
||||
verdict=REJECT // ACCEPT / ACCEPT_CONDITIONAL / REJECT
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Fitness Function
|
||||
|
||||
### 9.1 Agent fitness (per Hypothesis swarm)
|
||||
|
||||
```python
|
||||
def agent_fitness(agent: HypothesisAgentGenome,
|
||||
episodes: list[Episode]) -> float:
|
||||
|
||||
# Quality of contributions
|
||||
accepted_strats = [e for e in episodes
|
||||
if e.adversarial_verdict == "ACCEPT"]
|
||||
conditional_strats = [e for e in episodes
|
||||
if e.adversarial_verdict == "ACCEPT_CONDITIONAL"]
|
||||
|
||||
quality_score = (
|
||||
len(accepted_strats) * 1.0
|
||||
+ len(conditional_strats) * 0.3
|
||||
)
|
||||
|
||||
# Average DSR of accepted strategies
|
||||
avg_dsr = np.mean([e.dsr for e in accepted_strats]) if accepted_strats else 0
|
||||
|
||||
# Cost penalty (proporzionale al tier usato)
|
||||
cost_per_episode = TIER_COST[agent.model_tier] * agent.avg_tokens_per_episode
|
||||
cost_penalty = cost_per_episode * COST_PENALTY_LAMBDA
|
||||
|
||||
# Novelty bonus (semantica delle strategie prodotte)
|
||||
novelty_score = compute_novelty(agent, all_agents_in_generation)
|
||||
|
||||
# Diversity bonus (strategie diverse, non cloni)
|
||||
diversity_score = compute_internal_diversity(agent.strategies)
|
||||
|
||||
return (
|
||||
quality_score
|
||||
+ avg_dsr * DSR_WEIGHT
|
||||
+ novelty_score * NOVELTY_WEIGHT
|
||||
+ diversity_score * DIVERSITY_WEIGHT
|
||||
- cost_penalty
|
||||
)
|
||||
```
|
||||
|
||||
### 9.2 Pesi iniziali (da calibrare empiricamente)
|
||||
|
||||
```python
|
||||
DSR_WEIGHT = 2.0 # peso forte: vogliamo edge reale
|
||||
NOVELTY_WEIGHT = 0.5 # bonus moderato per esplorazione
|
||||
DIVERSITY_WEIGHT = 0.3 # leggero, evita cloni
|
||||
COST_PENALTY_LAMBDA = 0.1 # da calibrare in base a budget
|
||||
```
|
||||
|
||||
### 9.3 Anti-gaming
|
||||
|
||||
- Tracking globale del numero di test fatti per DSR correction
|
||||
- Cap su `quality_score` per evitare gaming via spam di ipotesi banali
|
||||
- Adversarial feedback va in fitness (strategie REJECTED penalizzano, non solo non bonificano)
|
||||
- Periodic audit umano: ogni 10 generazioni rivedere top 5 strategies, marcare "spurious" se gaming
|
||||
|
||||
---
|
||||
|
||||
## 10. Baseline non-LLM (anti-illusion check)
|
||||
|
||||
**Critico**: il PoC deve includere una baseline statistica tradizionale.
|
||||
|
||||
### 10.1 Specifica baseline
|
||||
|
||||
- **Metodo**: Random Forest + feature engineering manuale
|
||||
- **Features**: stesso pool del swarm
|
||||
- **Target**: returns N-bar future (predizione regression o classification)
|
||||
- **Validation**: stesso walk-forward purged CV
|
||||
- **Output**: trade signals → backtest engine identico
|
||||
|
||||
### 10.2 Confronto
|
||||
|
||||
| Metrica | Baseline RF | Swarm LLM |
|
||||
|----------------------------|-------------|-----------|
|
||||
| Best DSR found | ? | ? |
|
||||
| Avg DSR top-10 strategies | ? | ? |
|
||||
| N strategies passing adv. | ? | ? |
|
||||
| Diversity (semantic) | ? | ? |
|
||||
| Total cost | ~$50 | ~$3K |
|
||||
|
||||
**Interpretazione**:
|
||||
- Se Swarm batte significativamente Baseline → architettura LLM sta aggiungendo valore
|
||||
- Se Swarm pareggia → costo non giustificato per discovery numerica pura
|
||||
- Se Swarm perde → l'edge degli LLM agents è altrove (creatività su task non numerici, integrazione semi-strutturata)
|
||||
|
||||
**Punto importante**: anche se Swarm perde su pattern discovery numerico, NON significa che il sistema co-evolutivo completo è inutile. Significa che la value-add è in altri domini (ipotesi macro, integrazione narrative, generalizzazione cross-domain). È informazione preziosa.
|
||||
|
||||
---
|
||||
|
||||
## 11. Roadmap Implementativa (3-4 mesi)
|
||||
|
||||
### Settimane 1-3: Setup & Dataset
|
||||
|
||||
- Setup repo, environment, dependencies
|
||||
- Data sourcing: identificare provider, sottoscrivere se necessario
|
||||
- Data ingestion: pipeline dati storici BTC/ETH 2018-2025
|
||||
- Storage schema (PostgreSQL/TimescaleDB)
|
||||
- Audit di availability_lag per ogni feature
|
||||
- Sanity checks: confronto cross-source per validare integrity
|
||||
|
||||
**Deliverable**: dataset completo annotato, query-able, con feature catalog.
|
||||
|
||||
### Settimane 4-7: Backtest Engine
|
||||
|
||||
- Implementazione walk-forward purged CV
|
||||
- Slippage model (Almgren-Chriss)
|
||||
- Fees + funding
|
||||
- DSR computation
|
||||
- Test di non-leakage (deliberately inject lookahead → engine deve catcharlo)
|
||||
- Performance optimization (target ≥100 backtest/sec)
|
||||
|
||||
**Deliverable**: backtest engine standalone testato. Strategie semplici (buy & hold, 50/200 SMA crossover) producono risultati noti.
|
||||
|
||||
### Settimane 8-9: Agenti hand-crafted
|
||||
|
||||
- Falsification agent (Tier-B)
|
||||
- Adversarial agent (Tier-A)
|
||||
- Protocol fisso (S-expression parser + 15 verbi)
|
||||
- Message bus auditato semplificato
|
||||
- Test end-to-end con ipotesi hand-crafted
|
||||
|
||||
**Deliverable**: pipeline agente → falsification → adversarial → verdict, funzionante end-to-end con strategie inserite manualmente.
|
||||
|
||||
### Settimane 10-12: Hypothesis Swarm + GA
|
||||
|
||||
- Population manager (50 agenti)
|
||||
- Operatori genetici (mutazione + crossover)
|
||||
- Speciation con clustering embedding
|
||||
- Fitness computation
|
||||
- Tournament selection
|
||||
- Evoluzione per 50 generazioni baseline
|
||||
|
||||
**Deliverable**: swarm che evolve, fitness che migliora over generations, output di top strategies.
|
||||
|
||||
### Settimane 13-14: Baseline + Comparison
|
||||
|
||||
- Implementazione baseline Random Forest
|
||||
- Run baseline su stesso dataset/timeframe
|
||||
- Tabella comparison
|
||||
- Analisi qualitative delle strategie prodotte da entrambi
|
||||
|
||||
**Deliverable**: documento di confronto onesto.
|
||||
|
||||
### Settimane 15-16: Analisi & Report
|
||||
|
||||
- Run finale su hold-out set 2025
|
||||
- Analysis: ablation multi-tier, regime breakdown, diversity analysis
|
||||
- Documentazione lessons learned
|
||||
- Decision document: procedere con sistema completo, iterare PoC, o pivot
|
||||
|
||||
**Deliverable**: report finale con risposte alle 5 domande di validazione iniziali.
|
||||
|
||||
---
|
||||
|
||||
## 12. Costi PoC
|
||||
|
||||
### 12.1 LLM costs
|
||||
|
||||
| Fase | Calls stimate | Tokens stimati | Tier mix | Costo |
|
||||
|-------------------------|---------------|-----------------|--------------|--------|
|
||||
| Setup + agenti hand | ~500 | 2M | A/B | ~$50 |
|
||||
| Test pipeline | ~2000 | 8M | B/C | ~$30 |
|
||||
| GA run principale | 50 gen × 50 agent × 10 calls × 5K tok = 125M tok | mostly C, some B | ~$300-500 |
|
||||
| Repeat runs (3x) | (per ablation, tuning) | | | ~$1000-1500 |
|
||||
| Hold-out validation | ~1000 | 5M | A (judge) | ~$80 |
|
||||
| **Totale** | | | | **$1500-2500** |
|
||||
|
||||
Più conservativo se aggiungiamo iteration overhead: **budget $2-4K**.
|
||||
|
||||
### 12.2 Infrastruttura
|
||||
|
||||
- Compute (locale o cloud modesto): ~$200-400 totali
|
||||
- Storage (data + logs): ~$50/mese
|
||||
- Data subscription (Tardis o Kaiko per derivatives): variabile, $0-500/mese a seconda della qualità richiesta
|
||||
|
||||
### 12.3 Tempo
|
||||
|
||||
- Realistic estimate: **3-4 mesi** a 3-4 giorni/settimana effettivi
|
||||
- Pessimistic estimate: 5-6 mesi se data sourcing risulta più complesso del previsto
|
||||
|
||||
---
|
||||
|
||||
## 13. Rischi e Mitigazioni
|
||||
|
||||
| Rischio | Probabilità | Impatto | Mitigazione |
|
||||
|------------------------------------|-------------|---------|-----------------------------------------|
|
||||
| Data sourcing più complesso | Alta | Medio | Start con CCXT + Binance free, upgrade dopo |
|
||||
| Backtest engine ha bug subtle | Alta | Critico | Test deliberato di lookahead injection |
|
||||
| Swarm non batte baseline RF | Media | Alto | È un risultato comunque, non fallimento |
|
||||
| Costi over-budget | Media | Medio | Cap hard, monitor settimanale |
|
||||
| Time over-budget (5+ mesi) | Alta | Medio | Milestone bi-settimanali, taglio scope se necessario |
|
||||
| Convergenza prematura del swarm | Media | Alto | Speciation, novelty bonus, immigrazione |
|
||||
| OpenRouter qualità inconsistente | Media | Basso | Fallback policy, monitor success rate |
|
||||
|
||||
---
|
||||
|
||||
## 14. Decisioni Aperte
|
||||
|
||||
Da risolvere prima di Fase 1:
|
||||
|
||||
1. **Asset focus**: solo BTC, solo ETH, o entrambi? (suggerito: entrambi, per cross-asset features)
|
||||
2. **Data provider primario**: pagare Tardis/Kaiko o partire con free sources? (suggerito: free per Fase 1, upgrade se necessario)
|
||||
3. **Hardware**: locale o cloud? (suggerito: locale, dataset ~50-100GB gestibile)
|
||||
4. **Tier-A budget**: quanto reservare a Sonnet per Adversarial? (suggerito: $300-500 cap)
|
||||
5. **Frequency primaria**: 1h confermato o scendere a 15min? (suggerito: 1h, evita overfitting su microstructure)
|
||||
|
||||
---
|
||||
|
||||
## 15. Cosa il PoC NON fa (e va bene)
|
||||
|
||||
- NON evolve il protocollo (sistema completo)
|
||||
- NON co-evolve Falsification e Adversarial (sistema completo)
|
||||
- NON esplora idiom emergence (sistema completo)
|
||||
- NON applica a domini non-trading (sistema completo)
|
||||
- NON cerca breakthrough singoli, cerca **validazione architetturale**
|
||||
- NON è un trading bot pronto per capitale reale (mai dopo PoC, paper trading prima)
|
||||
|
||||
Il PoC è un **esperimento controllato**. Il sistema completo è il prodotto. Sono cose diverse, e va bene così.
|
||||
|
||||
---
|
||||
|
||||
## 16. Decision Triggers
|
||||
|
||||
Dopo PoC, queste sono le decisioni discrete:
|
||||
|
||||
**GO al sistema completo se**:
|
||||
- Swarm produce ≥5 strategie con DSR significativo dopo Adversarial
|
||||
- Swarm batte baseline RF di ≥30% in best-DSR e diversity
|
||||
- Strategie sopravvivono a OOS 2025 (regime change)
|
||||
- Multi-tier ablation conferma valore (no significant loss usando 70% Tier-C)
|
||||
|
||||
**ITERATE PoC se**:
|
||||
- Risultati borderline (alcuni indicatori sì, altri no)
|
||||
- Bug specifici identificabili (es. GA non diversifica → fix speciation)
|
||||
- Architettura sembra giusta ma implementazione perfettibile
|
||||
|
||||
**PIVOT se**:
|
||||
- Swarm decisamente perde vs baseline su discovery numerica
|
||||
- Ma: considerare pivot verso domini non-numerici (offerte commerciali, code review)
|
||||
- O: considerare uso del swarm come *generator* di ipotesi macro/strutturali, non pattern numerici
|
||||
|
||||
---
|
||||
|
||||
*Documento da aggiornare durante PoC. Questa è v0.1, scritta prima di qualunque implementazione.*
|
||||
*Documento principale (sistema completo): `coevolutive_swarm_system.md`*
|
||||
+13
-28
@@ -1,26 +1,16 @@
|
||||
[project]
|
||||
name = "multi-swarm"
|
||||
name = "multi-swarm-coevolutive"
|
||||
version = "0.1.0"
|
||||
description = "Multi-Swarm Coevolutive PoC trading swarm — Phase 1 lean spike"
|
||||
description = "Multi-Swarm Coevolutive: monorepo workspace (core + strategie)"
|
||||
authors = [{ name = "Adriano Dal Pastro", email = "adrianodalpastro@tielogic.com" }]
|
||||
requires-python = ">=3.13"
|
||||
dependencies = [
|
||||
"pandas>=2.2",
|
||||
"numpy>=2.1",
|
||||
"scipy>=1.14",
|
||||
"pydantic>=2.9",
|
||||
"pydantic-settings>=2.6",
|
||||
"sqlmodel>=0.0.22",
|
||||
"openai>=1.55",
|
||||
"httpx>=0.28",
|
||||
"requests>=2.32",
|
||||
"tenacity>=9.0",
|
||||
"pyyaml>=6.0",
|
||||
"plotly>=5.24",
|
||||
"pyarrow>=18.0",
|
||||
"nicegui>=3.11.1",
|
||||
"yfinance>=1.3.0",
|
||||
]
|
||||
|
||||
[tool.uv.workspace]
|
||||
members = ["src/multi_swarm_core", "src/strategy_crypto"]
|
||||
|
||||
[tool.uv.sources]
|
||||
multi-swarm-core = { workspace = true }
|
||||
strategy-crypto = { workspace = true }
|
||||
|
||||
[dependency-groups]
|
||||
dev = [
|
||||
@@ -31,15 +21,10 @@ dev = [
|
||||
"ruff>=0.7",
|
||||
"mypy>=1.13",
|
||||
"types-requests>=2.32",
|
||||
"multi-swarm-core",
|
||||
"strategy-crypto",
|
||||
]
|
||||
|
||||
[build-system]
|
||||
requires = ["hatchling"]
|
||||
build-backend = "hatchling.build"
|
||||
|
||||
[tool.hatch.build.targets.wheel]
|
||||
packages = ["src/multi_swarm"]
|
||||
|
||||
[tool.ruff]
|
||||
line-length = 100
|
||||
target-version = "py313"
|
||||
@@ -52,8 +37,8 @@ python_version = "3.13"
|
||||
strict = true
|
||||
|
||||
[tool.pytest.ini_options]
|
||||
testpaths = ["tests"]
|
||||
addopts = "-v --tb=short"
|
||||
testpaths = ["src/multi_swarm_core/tests", "src/strategy_crypto/tests"]
|
||||
addopts = "-v --tb=short --import-mode=importlib"
|
||||
markers = [
|
||||
"integration: tests that require external services (Cerbero, LLM API)",
|
||||
"slow: tests that take more than 5 seconds",
|
||||
|
||||
@@ -17,13 +17,13 @@ import math
|
||||
from datetime import datetime
|
||||
from pathlib import Path
|
||||
|
||||
from multi_swarm.agents.adversarial import AdversarialAgent
|
||||
from multi_swarm.agents.falsification import FalsificationAgent
|
||||
from multi_swarm.cerbero.client import CerberoClient
|
||||
from multi_swarm.config import load_settings
|
||||
from multi_swarm.data.cerbero_ohlcv import CerberoOHLCVLoader, OHLCVRequest
|
||||
from multi_swarm.protocol.parser import parse_strategy
|
||||
from multi_swarm.protocol.validator import validate_strategy
|
||||
from multi_swarm_core.agents.adversarial import AdversarialAgent
|
||||
from multi_swarm_core.agents.falsification import FalsificationAgent
|
||||
from multi_swarm_core.cerbero.client import CerberoClient
|
||||
from multi_swarm_core.config import load_settings
|
||||
from multi_swarm_core.data.cerbero_ohlcv import CerberoOHLCVLoader, OHLCVRequest
|
||||
from multi_swarm_core.protocol.parser import parse_strategy
|
||||
from multi_swarm_core.protocol.validator import validate_strategy
|
||||
|
||||
|
||||
def main() -> None:
|
||||
|
||||
@@ -0,0 +1,127 @@
|
||||
"""Replay diagnostico: per ciascuna strategia conta quanti bar avrebbero
|
||||
soddisfatto le condizioni di ciascuna regola sull'ultimo `--days` di storico.
|
||||
|
||||
Ouput tabellare per branch: total_bars, fires, fire_rate, primo/ultimo fire.
|
||||
Esegue anche un backtest grezzo (entry-on-signal, exit-on-flat) per stimare
|
||||
n_trades e total_return realistici nel periodo.
|
||||
|
||||
Esempio:
|
||||
docker compose exec multi-swarm-paper \
|
||||
python /app/scripts/replay_strategies_window.py --days 30
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import json
|
||||
from datetime import UTC, datetime, timedelta
|
||||
from pathlib import Path
|
||||
|
||||
import pandas as pd
|
||||
|
||||
from multi_swarm_core.cerbero.client import CerberoClient
|
||||
from multi_swarm_core.config import load_settings
|
||||
from multi_swarm_core.data.cerbero_ohlcv import CerberoOHLCVLoader, OHLCVRequest
|
||||
from multi_swarm_core.protocol.compiler import _eval_node, compile_strategy
|
||||
from multi_swarm_core.protocol.parser import parse_strategy
|
||||
|
||||
PROJECT_ROOT = Path(__file__).resolve().parent.parent
|
||||
|
||||
|
||||
def parse_args() -> argparse.Namespace:
|
||||
p = argparse.ArgumentParser()
|
||||
p.add_argument("--days", type=int, default=30)
|
||||
p.add_argument("--strategies-dir", default=str(PROJECT_ROOT / "strategies"))
|
||||
return p.parse_args()
|
||||
|
||||
|
||||
def fetch_window(loader: CerberoOHLCVLoader, symbol: str, days: int) -> pd.DataFrame:
|
||||
end = datetime.now(UTC).replace(minute=0, second=0, microsecond=0)
|
||||
start = end - timedelta(days=days)
|
||||
req = OHLCVRequest(
|
||||
symbol=symbol, timeframe="1h", start=start, end=end, exchange="deribit"
|
||||
)
|
||||
return loader._fetch(req) # noqa: SLF001 — bypass cache
|
||||
|
||||
|
||||
def per_branch_fires(strategy_path: Path, ohlcv: pd.DataFrame) -> list[dict]:
|
||||
raw = strategy_path.read_text()
|
||||
parsed = parse_strategy(raw)
|
||||
out = []
|
||||
for idx, rule in enumerate(parsed.rules):
|
||||
cond_series = _eval_node(rule.condition, ohlcv).fillna(False).astype(bool)
|
||||
n = int(cond_series.sum())
|
||||
first = ohlcv.index[cond_series.argmax()] if n > 0 else None
|
||||
# last fire: argmax on reversed
|
||||
last = ohlcv.index[len(cond_series) - 1 - cond_series[::-1].argmax()] if n > 0 else None
|
||||
out.append({
|
||||
"branch_idx": idx,
|
||||
"action": rule.action,
|
||||
"fires": n,
|
||||
"fire_rate_pct": round(100.0 * n / len(ohlcv), 2),
|
||||
"first_fire": first,
|
||||
"last_fire": last,
|
||||
})
|
||||
return out
|
||||
|
||||
|
||||
def quick_pnl(strategy_path: Path, ohlcv: pd.DataFrame, fees_bp: float = 5.0) -> dict:
|
||||
"""Approx: at each bar evaluate compiled signal series (long/short/flat),
|
||||
apply position to next-bar return, charge fees on changes. No leverage."""
|
||||
raw = strategy_path.read_text()
|
||||
parsed = parse_strategy(raw)
|
||||
sig_fn = compile_strategy(parsed)
|
||||
signals = sig_fn(ohlcv) # series of "long"/"short"/"flat"
|
||||
# map to position: long=+1, short=-1, flat=0
|
||||
pos = signals.map({"long": 1, "short": -1, "flat": 0}).fillna(0).astype(int)
|
||||
rets = ohlcv["close"].pct_change().fillna(0.0)
|
||||
# next-bar execution: position decided at bar t applies to return t+1 -> shift
|
||||
pnl = pos.shift(1).fillna(0) * rets
|
||||
# fees on position changes
|
||||
changes = pos.diff().abs().fillna(0).astype(int)
|
||||
fee_per_change = fees_bp / 10_000.0
|
||||
pnl_after_fees = pnl - changes * fee_per_change
|
||||
cum = (1 + pnl_after_fees).prod() - 1
|
||||
n_trades = int((changes > 0).sum())
|
||||
time_in_market = float((pos != 0).mean())
|
||||
return {
|
||||
"n_trades": n_trades,
|
||||
"total_return_pct": round(100.0 * float(cum), 3),
|
||||
"time_in_market_pct": round(100.0 * time_in_market, 2),
|
||||
}
|
||||
|
||||
|
||||
def main() -> None:
|
||||
args = parse_args()
|
||||
settings = load_settings()
|
||||
token = (
|
||||
settings.cerbero_mainnet_token.get_secret_value()
|
||||
if settings.cerbero_mainnet_token
|
||||
else settings.cerbero_testnet_token.get_secret_value()
|
||||
)
|
||||
cerbero = CerberoClient(
|
||||
base_url=settings.cerbero_base_url,
|
||||
token=token,
|
||||
bot_tag=settings.cerbero_bot_tag,
|
||||
)
|
||||
loader = CerberoOHLCVLoader(client=cerbero, cache_dir=settings.series_dir)
|
||||
|
||||
strategies_dir = Path(args.strategies_dir)
|
||||
pairs = [
|
||||
("BTC-PERPETUAL", sorted(strategies_dir.glob("btc_*.json"))[0]),
|
||||
("ETH-PERPETUAL", sorted(strategies_dir.glob("eth_*.json"))[0]),
|
||||
]
|
||||
|
||||
for symbol, strat_path in pairs:
|
||||
print(f"\n=== {symbol} strategy={strat_path.name} window={args.days}d ===")
|
||||
ohlcv = fetch_window(loader, symbol, args.days)
|
||||
print(f"bars: {len(ohlcv)} range: {ohlcv.index[0]} -> {ohlcv.index[-1]}")
|
||||
print("\n-- per branch --")
|
||||
for row in per_branch_fires(strat_path, ohlcv):
|
||||
print(json.dumps(row, default=str))
|
||||
print("\n-- quick pnl (next-bar exec, fees=5bp) --")
|
||||
print(json.dumps(quick_pnl(strat_path, ohlcv), default=str))
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -20,22 +20,25 @@ Esempio:
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import importlib.resources
|
||||
import time
|
||||
from dataclasses import dataclass
|
||||
from datetime import UTC, datetime, timedelta
|
||||
from pathlib import Path
|
||||
|
||||
from multi_swarm.cerbero.client import CerberoClient
|
||||
from multi_swarm.config import load_settings
|
||||
from multi_swarm.data.cerbero_ohlcv import CerberoOHLCVLoader, OHLCVRequest
|
||||
from multi_swarm.paper_trading.executor import PaperExecutor
|
||||
from multi_swarm.paper_trading.persistence import PaperRepository
|
||||
from multi_swarm.paper_trading.portfolio import Portfolio
|
||||
from multi_swarm.persistence.repository import Repository
|
||||
from multi_swarm_core.cerbero.client import CerberoClient
|
||||
from multi_swarm_core.config import load_settings
|
||||
from multi_swarm_core.data.cerbero_ohlcv import CerberoOHLCVLoader, OHLCVRequest
|
||||
from strategy_crypto.backend import PaperExecutor, PaperRepository, Portfolio
|
||||
|
||||
PROJECT_ROOT = Path(__file__).resolve().parent.parent
|
||||
|
||||
|
||||
def _default_strategies_dir() -> Path:
|
||||
"""Cartella JSON shippata col package strategy_crypto."""
|
||||
return Path(str(importlib.resources.files("strategy_crypto") / "strategies"))
|
||||
|
||||
|
||||
@dataclass(frozen=True)
|
||||
class AssetConfig:
|
||||
symbol: str # es. "BTC-PERPETUAL"
|
||||
@@ -54,8 +57,8 @@ def parse_args() -> argparse.Namespace:
|
||||
p.add_argument("--lookback-bars", type=int, default=500, help="Quante bar fetchare per indicatori")
|
||||
p.add_argument(
|
||||
"--strategies-dir",
|
||||
default=str(PROJECT_ROOT / "strategies"),
|
||||
help="Cartella contenente btc_*.json e eth_*.json",
|
||||
default=str(_default_strategies_dir()),
|
||||
help="Cartella contenente btc_*.json e eth_*.json (default: package strategy_crypto/strategies)",
|
||||
)
|
||||
return p.parse_args()
|
||||
|
||||
@@ -77,9 +80,6 @@ def main() -> None:
|
||||
args = parse_args()
|
||||
settings = load_settings()
|
||||
|
||||
# Inizializza schema (idempotente).
|
||||
Repository(settings.db_path).init_schema()
|
||||
|
||||
token = (
|
||||
settings.cerbero_mainnet_token.get_secret_value()
|
||||
if settings.cerbero_mainnet_token
|
||||
@@ -105,7 +105,8 @@ def main() -> None:
|
||||
fees_bp=args.fees_bp,
|
||||
n_sleeves=len(assets),
|
||||
)
|
||||
repo = PaperRepository(settings.db_path)
|
||||
repo = PaperRepository(settings.strategy_crypto_db_path)
|
||||
repo.init_schema()
|
||||
config = {
|
||||
"assets": [
|
||||
{"symbol": a.symbol, "strategy": a.strategy_file.name, "exchange": a.exchange}
|
||||
|
||||
@@ -3,12 +3,12 @@ from __future__ import annotations
|
||||
import argparse
|
||||
from datetime import datetime
|
||||
|
||||
from multi_swarm.cerbero.client import CerberoClient
|
||||
from multi_swarm.config import load_settings
|
||||
from multi_swarm.data.cerbero_ohlcv import CerberoOHLCVLoader, OHLCVRequest
|
||||
from multi_swarm.genome.hypothesis import ModelTier
|
||||
from multi_swarm.llm.client import LLMClient
|
||||
from multi_swarm.orchestrator.run import RunConfig, run_phase1
|
||||
from multi_swarm_core.cerbero.client import CerberoClient
|
||||
from multi_swarm_core.config import load_settings
|
||||
from multi_swarm_core.data.cerbero_ohlcv import CerberoOHLCVLoader, OHLCVRequest
|
||||
from multi_swarm_core.genome.hypothesis import ModelTier
|
||||
from multi_swarm_core.llm.client import LLMClient
|
||||
from multi_swarm_core.orchestrator.run import RunConfig, run_phase1
|
||||
|
||||
|
||||
def parse_args() -> argparse.Namespace:
|
||||
|
||||
@@ -6,9 +6,9 @@ from pathlib import Path
|
||||
import numpy as np
|
||||
import pandas as pd # type: ignore[import-untyped]
|
||||
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm.llm.client import CompletionResult
|
||||
from multi_swarm.orchestrator.run import RunConfig, run_phase1
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.llm.client import CompletionResult
|
||||
from multi_swarm_core.orchestrator.run import RunConfig, run_phase1
|
||||
|
||||
_MOCK_STRATEGY = json.dumps(
|
||||
{
|
||||
|
||||
@@ -6,7 +6,7 @@ in the project root. Required secrets are validated at instantiation time.
|
||||
|
||||
from pathlib import Path
|
||||
|
||||
from pydantic import Field, SecretStr
|
||||
from pydantic import AliasChoices, Field, SecretStr
|
||||
from pydantic_settings import BaseSettings, SettingsConfigDict
|
||||
|
||||
|
||||
@@ -35,7 +35,24 @@ class Settings(BaseSettings):
|
||||
run_name: str = "phase1-spike-001"
|
||||
data_dir: Path = Field(default=Path("./data"))
|
||||
series_dir: Path = Field(default=Path("./series"))
|
||||
db_path: Path = Field(default=Path("./runs.db"))
|
||||
|
||||
# GA core DB (tabelle universali: runs, generations, genomes, evaluations, ...)
|
||||
# Alias DB_PATH legacy mantenuto per backcompat (deprecato, rimuovere nei prossimi cicli).
|
||||
ga_db_path: Path = Field(
|
||||
default=Path("./state/runs.db"),
|
||||
validation_alias=AliasChoices("GA_DB_PATH", "DB_PATH"),
|
||||
)
|
||||
|
||||
# DB per la strategia crypto (tabelle paper_trading_*, isolato dal core)
|
||||
strategy_crypto_db_path: Path = Field(
|
||||
default=Path("./state/strategy_crypto.db"),
|
||||
validation_alias="STRATEGY_CRYPTO_DB_PATH",
|
||||
)
|
||||
|
||||
@property
|
||||
def db_path(self) -> Path:
|
||||
"""Backcompat alias: legge ga_db_path. Deprecato — usare ga_db_path."""
|
||||
return self.ga_db_path
|
||||
|
||||
|
||||
def load_settings() -> Settings:
|
||||
-61
@@ -77,68 +77,7 @@ CREATE TABLE IF NOT EXISTS adversarial_findings (
|
||||
FOREIGN KEY (run_id) REFERENCES runs(id)
|
||||
);
|
||||
|
||||
CREATE TABLE IF NOT EXISTS paper_trading_runs (
|
||||
id TEXT PRIMARY KEY,
|
||||
name TEXT NOT NULL,
|
||||
started_at TEXT NOT NULL,
|
||||
stopped_at TEXT,
|
||||
status TEXT NOT NULL DEFAULT 'running',
|
||||
initial_capital REAL NOT NULL,
|
||||
config_json TEXT NOT NULL
|
||||
);
|
||||
|
||||
CREATE TABLE IF NOT EXISTS paper_trading_positions (
|
||||
paper_run_id TEXT NOT NULL,
|
||||
symbol TEXT NOT NULL,
|
||||
side TEXT NOT NULL,
|
||||
qty REAL NOT NULL,
|
||||
entry_price REAL NOT NULL,
|
||||
entry_ts TEXT NOT NULL,
|
||||
PRIMARY KEY (paper_run_id, symbol),
|
||||
FOREIGN KEY (paper_run_id) REFERENCES paper_trading_runs(id)
|
||||
);
|
||||
|
||||
CREATE TABLE IF NOT EXISTS paper_trading_trades (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
paper_run_id TEXT NOT NULL,
|
||||
symbol TEXT NOT NULL,
|
||||
side TEXT NOT NULL,
|
||||
qty REAL NOT NULL,
|
||||
entry_price REAL NOT NULL,
|
||||
exit_price REAL NOT NULL,
|
||||
entry_ts TEXT NOT NULL,
|
||||
exit_ts TEXT NOT NULL,
|
||||
pnl REAL NOT NULL,
|
||||
fees REAL NOT NULL,
|
||||
FOREIGN KEY (paper_run_id) REFERENCES paper_trading_runs(id)
|
||||
);
|
||||
|
||||
CREATE TABLE IF NOT EXISTS paper_trading_equity (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
paper_run_id TEXT NOT NULL,
|
||||
ts TEXT NOT NULL,
|
||||
equity REAL NOT NULL,
|
||||
cash REAL NOT NULL,
|
||||
positions_value REAL NOT NULL,
|
||||
FOREIGN KEY (paper_run_id) REFERENCES paper_trading_runs(id)
|
||||
);
|
||||
|
||||
CREATE TABLE IF NOT EXISTS paper_trading_ticks (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
paper_run_id TEXT NOT NULL,
|
||||
symbol TEXT NOT NULL,
|
||||
ts TEXT NOT NULL,
|
||||
bar_ts TEXT NOT NULL,
|
||||
close_price REAL NOT NULL,
|
||||
signal TEXT NOT NULL,
|
||||
action_taken TEXT NOT NULL,
|
||||
FOREIGN KEY (paper_run_id) REFERENCES paper_trading_runs(id)
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_evaluations_fitness ON evaluations(run_id, fitness DESC);
|
||||
CREATE INDEX IF NOT EXISTS idx_genomes_generation ON genomes(run_id, generation_idx);
|
||||
CREATE INDEX IF NOT EXISTS idx_cost_run ON cost_records(run_id);
|
||||
CREATE INDEX IF NOT EXISTS idx_paper_trades_run ON paper_trading_trades(paper_run_id, exit_ts);
|
||||
CREATE INDEX IF NOT EXISTS idx_paper_equity_run ON paper_trading_equity(paper_run_id, ts);
|
||||
CREATE INDEX IF NOT EXISTS idx_paper_ticks_run ON paper_trading_ticks(paper_run_id, ts);
|
||||
"""
|
||||
@@ -0,0 +1,25 @@
|
||||
[project]
|
||||
name = "multi-swarm-core"
|
||||
version = "0.1.0"
|
||||
description = "Multi-Swarm Coevolutive core: GA, genome, protocol, backtest, cerbero, data, llm, persistence"
|
||||
authors = [{ name = "Adriano Dal Pastro", email = "adrianodalpastro@tielogic.com" }]
|
||||
requires-python = ">=3.13"
|
||||
dependencies = [
|
||||
"pandas>=2.2",
|
||||
"numpy>=2.1",
|
||||
"scipy>=1.14",
|
||||
"pydantic>=2.9",
|
||||
"pydantic-settings>=2.6",
|
||||
"sqlmodel>=0.0.22",
|
||||
"openai>=1.55",
|
||||
"httpx>=0.28",
|
||||
"requests>=2.32",
|
||||
"tenacity>=9.0",
|
||||
"pyyaml>=6.0",
|
||||
"pyarrow>=18.0",
|
||||
"yfinance>=1.3.0",
|
||||
]
|
||||
|
||||
[build-system]
|
||||
requires = ["hatchling"]
|
||||
build-backend = "hatchling.build"
|
||||
+4
-4
@@ -5,10 +5,10 @@ import numpy as np
|
||||
import pandas as pd
|
||||
import pytest
|
||||
|
||||
from multi_swarm.genome.hypothesis import ModelTier
|
||||
from multi_swarm.llm.client import CompletionResult
|
||||
from multi_swarm.orchestrator.run import RunConfig, run_phase1
|
||||
from multi_swarm.persistence.repository import Repository
|
||||
from multi_swarm_core.genome.hypothesis import ModelTier
|
||||
from multi_swarm_core.llm.client import CompletionResult
|
||||
from multi_swarm_core.orchestrator.run import RunConfig, run_phase1
|
||||
from multi_swarm_core.persistence.repository import Repository
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
+2
-2
@@ -9,8 +9,8 @@ from __future__ import annotations
|
||||
import random
|
||||
from dataclasses import dataclass
|
||||
|
||||
from multi_swarm.ga.loop import GAConfig, next_generation
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.ga.loop import GAConfig, next_generation
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
|
||||
_PROMPT_TEMPLATES = (
|
||||
"Strategia mean-reversion 1h. Entry long RSI(14) < 30 e close > SMA(50). Stop 2%.",
|
||||
+18
-18
@@ -4,14 +4,14 @@ import numpy as np
|
||||
import pandas as pd
|
||||
import pytest
|
||||
|
||||
from multi_swarm.agents.adversarial import (
|
||||
from multi_swarm_core.agents.adversarial import (
|
||||
AdversarialAgent,
|
||||
AdversarialReport,
|
||||
Severity,
|
||||
)
|
||||
from multi_swarm.backtest.engine import BacktestResult
|
||||
from multi_swarm.backtest.orders import Side, Trade
|
||||
from multi_swarm.protocol.parser import parse_strategy
|
||||
from multi_swarm_core.backtest.engine import BacktestResult
|
||||
from multi_swarm_core.backtest.orders import Side, Trade
|
||||
from multi_swarm_core.protocol.parser import parse_strategy
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
@@ -178,10 +178,10 @@ def test_undertrading_under_10_is_high(monkeypatch: pytest.MonkeyPatch,
|
||||
return lambda df: fake_signals
|
||||
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.BacktestEngine.run", fake_run
|
||||
"multi_swarm_core.agents.adversarial.BacktestEngine.run", fake_run
|
||||
)
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.compile_strategy", fake_compile
|
||||
"multi_swarm_core.agents.adversarial.compile_strategy", fake_compile
|
||||
)
|
||||
|
||||
src = _MINIMAL_STRATEGY_SRC
|
||||
@@ -220,8 +220,8 @@ def test_undertrading_threshold_parametric(monkeypatch: pytest.MonkeyPatch,
|
||||
def fake_compile(strategy): # type: ignore[no-untyped-def]
|
||||
return lambda df: fake_signals
|
||||
|
||||
monkeypatch.setattr("multi_swarm.agents.adversarial.BacktestEngine.run", fake_run)
|
||||
monkeypatch.setattr("multi_swarm.agents.adversarial.compile_strategy", fake_compile)
|
||||
monkeypatch.setattr("multi_swarm_core.agents.adversarial.BacktestEngine.run", fake_run)
|
||||
monkeypatch.setattr("multi_swarm_core.agents.adversarial.compile_strategy", fake_compile)
|
||||
|
||||
ast = parse_strategy(_MINIMAL_STRATEGY_SRC)
|
||||
# Default threshold 10: 15 trade NON killato
|
||||
@@ -269,10 +269,10 @@ def test_overtrading_with_tighter_threshold(monkeypatch: pytest.MonkeyPatch,
|
||||
return lambda df: fake_signals
|
||||
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.BacktestEngine.run", fake_run
|
||||
"multi_swarm_core.agents.adversarial.BacktestEngine.run", fake_run
|
||||
)
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.compile_strategy", fake_compile
|
||||
"multi_swarm_core.agents.adversarial.compile_strategy", fake_compile
|
||||
)
|
||||
|
||||
src = _MINIMAL_STRATEGY_SRC
|
||||
@@ -315,10 +315,10 @@ def test_flat_too_long_flagged(monkeypatch: pytest.MonkeyPatch,
|
||||
return lambda df: fake_signals
|
||||
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.BacktestEngine.run", fake_run
|
||||
"multi_swarm_core.agents.adversarial.BacktestEngine.run", fake_run
|
||||
)
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.compile_strategy", fake_compile
|
||||
"multi_swarm_core.agents.adversarial.compile_strategy", fake_compile
|
||||
)
|
||||
|
||||
src = _MINIMAL_STRATEGY_SRC
|
||||
@@ -367,10 +367,10 @@ def test_fees_eat_alpha_flagged(monkeypatch: pytest.MonkeyPatch,
|
||||
return lambda df: fake_signals
|
||||
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.BacktestEngine.run", fake_run
|
||||
"multi_swarm_core.agents.adversarial.BacktestEngine.run", fake_run
|
||||
)
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.compile_strategy", fake_compile
|
||||
"multi_swarm_core.agents.adversarial.compile_strategy", fake_compile
|
||||
)
|
||||
|
||||
src = _MINIMAL_STRATEGY_SRC
|
||||
@@ -413,10 +413,10 @@ def test_time_in_market_too_high_flagged(monkeypatch: pytest.MonkeyPatch,
|
||||
return lambda df: fake_signals
|
||||
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.BacktestEngine.run", fake_run
|
||||
"multi_swarm_core.agents.adversarial.BacktestEngine.run", fake_run
|
||||
)
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.compile_strategy", fake_compile
|
||||
"multi_swarm_core.agents.adversarial.compile_strategy", fake_compile
|
||||
)
|
||||
|
||||
src = _MINIMAL_STRATEGY_SRC
|
||||
@@ -461,10 +461,10 @@ def test_reasonable_balanced_strategy_not_flagged(monkeypatch: pytest.MonkeyPatc
|
||||
return lambda df: fake_signals
|
||||
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.BacktestEngine.run", fake_run
|
||||
"multi_swarm_core.agents.adversarial.BacktestEngine.run", fake_run
|
||||
)
|
||||
monkeypatch.setattr(
|
||||
"multi_swarm.agents.adversarial.compile_strategy", fake_compile
|
||||
"multi_swarm_core.agents.adversarial.compile_strategy", fake_compile
|
||||
)
|
||||
|
||||
src = _MINIMAL_STRATEGY_SRC
|
||||
+2
-2
@@ -2,8 +2,8 @@ import numpy as np
|
||||
import pandas as pd
|
||||
import pytest
|
||||
|
||||
from multi_swarm.backtest.engine import BacktestEngine
|
||||
from multi_swarm.backtest.orders import Side
|
||||
from multi_swarm_core.backtest.engine import BacktestEngine
|
||||
from multi_swarm_core.backtest.orders import Side
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
+1
-1
@@ -2,7 +2,7 @@ from datetime import UTC, datetime
|
||||
|
||||
import pytest
|
||||
|
||||
from multi_swarm.backtest.orders import Order, Position, Side, Trade
|
||||
from multi_swarm_core.backtest.orders import Order, Position, Side, Trade
|
||||
|
||||
|
||||
def test_order_validates_side() -> None:
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
import pytest
|
||||
import responses
|
||||
|
||||
from multi_swarm.cerbero.client import CerberoClient
|
||||
from multi_swarm_core.cerbero.client import CerberoClient
|
||||
|
||||
|
||||
@responses.activate
|
||||
+1
-1
@@ -6,7 +6,7 @@ from pathlib import Path
|
||||
import pandas as pd
|
||||
import pytest
|
||||
|
||||
from multi_swarm.data.cerbero_ohlcv import CerberoOHLCVLoader, OHLCVRequest
|
||||
from multi_swarm_core.data.cerbero_ohlcv import CerberoOHLCVLoader, OHLCVRequest
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
import pytest
|
||||
|
||||
from multi_swarm.cerbero.tools import CerberoTools
|
||||
from multi_swarm_core.cerbero.tools import CerberoTools
|
||||
|
||||
|
||||
def test_tools_dispatch_sma(mocker):
|
||||
@@ -1,4 +1,4 @@
|
||||
"""Tests for multi_swarm.config.Settings.
|
||||
"""Tests for multi_swarm_core.config.Settings.
|
||||
|
||||
Note on .env isolation:
|
||||
The happy-path test relies on monkeypatch.setenv to provide values.
|
||||
@@ -10,7 +10,7 @@ absence of required env vars. This keeps the test deterministic both in CI
|
||||
|
||||
import pytest
|
||||
|
||||
from multi_swarm.config import Settings
|
||||
from multi_swarm_core.config import Settings
|
||||
|
||||
|
||||
def test_settings_loads_from_env(monkeypatch: pytest.MonkeyPatch) -> None:
|
||||
+2
-2
@@ -1,5 +1,5 @@
|
||||
from multi_swarm.genome.hypothesis import ModelTier
|
||||
from multi_swarm.llm.cost_tracker import CostTracker, estimate_cost
|
||||
from multi_swarm_core.genome.hypothesis import ModelTier
|
||||
from multi_swarm_core.llm.cost_tracker import CostTracker, estimate_cost
|
||||
|
||||
|
||||
def test_estimate_cost_tier_c():
|
||||
@@ -1,6 +1,6 @@
|
||||
from __future__ import annotations
|
||||
|
||||
from multi_swarm.metrics.diversity import population_prompt_diversity
|
||||
from multi_swarm_core.metrics.diversity import population_prompt_diversity
|
||||
|
||||
|
||||
def test_empty_or_single_prompt_zero_diversity() -> None:
|
||||
+2
-2
@@ -4,8 +4,8 @@ import numpy as np
|
||||
import pandas as pd
|
||||
import pytest
|
||||
|
||||
from multi_swarm.agents.falsification import FalsificationAgent, FalsificationReport
|
||||
from multi_swarm.protocol.parser import parse_strategy
|
||||
from multi_swarm_core.agents.falsification import FalsificationAgent, FalsificationReport
|
||||
from multi_swarm_core.protocol.parser import parse_strategy
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
@@ -1,8 +1,8 @@
|
||||
from itertools import pairwise
|
||||
|
||||
from multi_swarm.agents.adversarial import AdversarialReport, Finding, Severity
|
||||
from multi_swarm.agents.falsification import FalsificationReport
|
||||
from multi_swarm.ga.fitness import compute_fitness
|
||||
from multi_swarm_core.agents.adversarial import AdversarialReport, Finding, Severity
|
||||
from multi_swarm_core.agents.falsification import FalsificationReport
|
||||
from multi_swarm_core.ga.fitness import compute_fitness
|
||||
|
||||
|
||||
def make_falsification(
|
||||
@@ -1,7 +1,7 @@
|
||||
import random
|
||||
|
||||
from multi_swarm.ga.initial import build_initial_population
|
||||
from multi_swarm.genome.hypothesis import ModelTier
|
||||
from multi_swarm_core.ga.initial import build_initial_population
|
||||
from multi_swarm_core.genome.hypothesis import ModelTier
|
||||
|
||||
|
||||
def test_initial_population_size():
|
||||
@@ -1,7 +1,7 @@
|
||||
import random
|
||||
|
||||
from multi_swarm.ga.loop import GAConfig, next_generation
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.ga.loop import GAConfig, next_generation
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
|
||||
|
||||
def make(idx: int) -> HypothesisAgentGenome:
|
||||
@@ -2,7 +2,7 @@ import math
|
||||
|
||||
import pytest
|
||||
|
||||
from multi_swarm.ga.summary import generation_summary
|
||||
from multi_swarm_core.ga.summary import generation_summary
|
||||
|
||||
|
||||
def test_summary_basic_stats():
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
import random
|
||||
|
||||
from multi_swarm.genome.crossover import uniform_crossover
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.genome.crossover import uniform_crossover
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
|
||||
|
||||
def make(name: str) -> HypothesisAgentGenome:
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
|
||||
|
||||
def test_genome_creation_defaults():
|
||||
+2
-2
@@ -2,8 +2,8 @@ import random
|
||||
|
||||
import pytest
|
||||
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm.genome.mutation import (
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.genome.mutation import (
|
||||
COGNITIVE_STYLES,
|
||||
FEATURE_POOL,
|
||||
mutate_cognitive_style,
|
||||
+3
-3
@@ -1,8 +1,8 @@
|
||||
import json
|
||||
|
||||
from multi_swarm.agents.hypothesis import HypothesisAgent, MarketSummary
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm.llm.client import CompletionResult, EmptyCompletionError
|
||||
from multi_swarm_core.agents.hypothesis import HypothesisAgent, MarketSummary
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.llm.client import CompletionResult, EmptyCompletionError
|
||||
|
||||
|
||||
def make_summary() -> MarketSummary:
|
||||
+12
-12
@@ -1,7 +1,7 @@
|
||||
import pytest
|
||||
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm.llm.client import CompletionResult, LLMClient
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.llm.client import CompletionResult, LLMClient
|
||||
|
||||
|
||||
def make_genome(tier: ModelTier) -> HypothesisAgentGenome:
|
||||
@@ -23,7 +23,7 @@ def test_completion_tier_c_uses_openrouter(mocker):
|
||||
fake_response.usage = mocker.MagicMock(prompt_tokens=100, completion_tokens=200)
|
||||
fake_openai.chat.completions.create.return_value = fake_response
|
||||
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(openrouter_api_key="or-x")
|
||||
g = make_genome(ModelTier.C)
|
||||
@@ -43,7 +43,7 @@ def test_completion_tier_b_uses_openrouter_with_anthropic_model(mocker):
|
||||
fake_response.choices = [mocker.MagicMock(message=mocker.MagicMock(content="(strategy ...)"))]
|
||||
fake_response.usage = mocker.MagicMock(prompt_tokens=80, completion_tokens=150)
|
||||
fake_openai.chat.completions.create.return_value = fake_response
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(openrouter_api_key="or-x")
|
||||
g = make_genome(ModelTier.B)
|
||||
@@ -67,7 +67,7 @@ def test_completion_retries_on_connection_error(mocker):
|
||||
fake_openai.chat.completions.create.side_effect = openai.APIConnectionError(
|
||||
request=mocker.MagicMock()
|
||||
)
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(openrouter_api_key="or-x")
|
||||
g = make_genome(ModelTier.C)
|
||||
@@ -86,7 +86,7 @@ def test_completion_uses_custom_model_tier_c(mocker):
|
||||
]
|
||||
fake_response.usage = mocker.MagicMock(prompt_tokens=10, completion_tokens=20)
|
||||
fake_openai.chat.completions.create.return_value = fake_response
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(
|
||||
openrouter_api_key="or-x",
|
||||
@@ -109,7 +109,7 @@ def test_completion_uses_custom_model_tier_b(mocker):
|
||||
]
|
||||
fake_response.usage = mocker.MagicMock(prompt_tokens=10, completion_tokens=20)
|
||||
fake_openai.chat.completions.create.return_value = fake_response
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(
|
||||
openrouter_api_key="or-x",
|
||||
@@ -130,7 +130,7 @@ def test_completion_tier_s_uses_openrouter_with_anthropic_model(mocker):
|
||||
fake_response.choices = [mocker.MagicMock(message=mocker.MagicMock(content="(strategy s)"))]
|
||||
fake_response.usage = mocker.MagicMock(prompt_tokens=50, completion_tokens=100)
|
||||
fake_openai.chat.completions.create.return_value = fake_response
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(openrouter_api_key="or-x")
|
||||
g = make_genome(ModelTier.S)
|
||||
@@ -149,7 +149,7 @@ def test_completion_tier_a_uses_openrouter_with_anthropic_model(mocker):
|
||||
fake_response.choices = [mocker.MagicMock(message=mocker.MagicMock(content="(strategy a)"))]
|
||||
fake_response.usage = mocker.MagicMock(prompt_tokens=40, completion_tokens=80)
|
||||
fake_openai.chat.completions.create.return_value = fake_response
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(openrouter_api_key="or-x")
|
||||
g = make_genome(ModelTier.A)
|
||||
@@ -170,7 +170,7 @@ def test_completion_tier_d_uses_openrouter_with_llama(mocker):
|
||||
]
|
||||
fake_response.usage = mocker.MagicMock(prompt_tokens=30, completion_tokens=70)
|
||||
fake_openai.chat.completions.create.return_value = fake_response
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(openrouter_api_key="or-x")
|
||||
g = make_genome(ModelTier.D)
|
||||
@@ -191,7 +191,7 @@ def test_completion_uses_custom_model_tier_s(mocker):
|
||||
]
|
||||
fake_response.usage = mocker.MagicMock(prompt_tokens=10, completion_tokens=20)
|
||||
fake_openai.chat.completions.create.return_value = fake_response
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(
|
||||
openrouter_api_key="or-x",
|
||||
@@ -221,7 +221,7 @@ def test_completion_succeeds_after_one_retry(mocker):
|
||||
openai.APITimeoutError(request=mocker.MagicMock()),
|
||||
fake_response,
|
||||
]
|
||||
mocker.patch("multi_swarm.llm.client.OpenAI", return_value=fake_openai)
|
||||
mocker.patch("multi_swarm_core.llm.client.OpenAI", return_value=fake_openai)
|
||||
|
||||
client = LLMClient(openrouter_api_key="or-x")
|
||||
g = make_genome(ModelTier.C)
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
import numpy as np
|
||||
import pandas as pd
|
||||
|
||||
from multi_swarm.agents.market_summary import build_market_summary
|
||||
from multi_swarm_core.agents.market_summary import build_market_summary
|
||||
|
||||
|
||||
def test_build_summary_basic() -> None:
|
||||
+1
-1
@@ -2,7 +2,7 @@ import numpy as np
|
||||
import pandas as pd
|
||||
import pytest
|
||||
|
||||
from multi_swarm.metrics.basic import max_drawdown, sharpe_ratio, total_return
|
||||
from multi_swarm_core.metrics.basic import max_drawdown, sharpe_ratio, total_return
|
||||
|
||||
|
||||
def test_sharpe_zero_returns():
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
import numpy as np
|
||||
import pandas as pd
|
||||
|
||||
from multi_swarm.metrics.dsr import deflated_sharpe_ratio, expected_max_sharpe
|
||||
from multi_swarm_core.metrics.dsr import deflated_sharpe_ratio, expected_max_sharpe
|
||||
|
||||
|
||||
def test_expected_max_sharpe_grows_with_n_trials():
|
||||
+2
-2
@@ -4,8 +4,8 @@ import random
|
||||
from collections import Counter
|
||||
from dataclasses import dataclass
|
||||
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm.genome.mutation import weighted_random_mutate
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.genome.mutation import weighted_random_mutate
|
||||
|
||||
_PROMPT = (
|
||||
"Strategia mean-reversion 1h BTC. Entry long quando RSI(14) < 30 e "
|
||||
+2
-2
@@ -3,8 +3,8 @@ from __future__ import annotations
|
||||
import random
|
||||
from dataclasses import dataclass
|
||||
|
||||
from multi_swarm.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm.genome.mutation_prompt_llm import (
|
||||
from multi_swarm_core.genome.hypothesis import HypothesisAgentGenome, ModelTier
|
||||
from multi_swarm_core.genome.mutation_prompt_llm import (
|
||||
MUTATION_INSTRUCTIONS,
|
||||
_extract_prompt,
|
||||
is_valid_prompt,
|
||||
+3
-3
@@ -6,9 +6,9 @@ import numpy as np
|
||||
import pandas as pd
|
||||
import pytest
|
||||
|
||||
from multi_swarm.backtest.orders import Side
|
||||
from multi_swarm.protocol.compiler import compile_strategy
|
||||
from multi_swarm.protocol.parser import parse_strategy
|
||||
from multi_swarm_core.backtest.orders import Side
|
||||
from multi_swarm_core.protocol.compiler import compile_strategy
|
||||
from multi_swarm_core.protocol.parser import parse_strategy
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
+2
-2
@@ -2,7 +2,7 @@ import json
|
||||
|
||||
import pytest
|
||||
|
||||
from multi_swarm.protocol.grammar import (
|
||||
from multi_swarm_core.protocol.grammar import (
|
||||
ACTION_VALUES,
|
||||
ALL_OPS,
|
||||
COMPARATOR_OPS,
|
||||
@@ -10,7 +10,7 @@ from multi_swarm.protocol.grammar import (
|
||||
KIND_VALUES,
|
||||
LOGICAL_OPS,
|
||||
)
|
||||
from multi_swarm.protocol.parser import (
|
||||
from multi_swarm_core.protocol.parser import (
|
||||
FeatureNode,
|
||||
IndicatorNode,
|
||||
LiteralNode,
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user