feat(mcp+runtime): allineamento a Cerbero MCP V2 e flag operativi
Adegua Cerbero Bite alla nuova versione 2.0.0 del server MCP unificato (testnet/mainnet routing per token, header X-Bot-Tag obbligatorio) e introduce due interruttori operativi indipendenti per separare la raccolta dati dall'esecuzione di strategia. Auth e collegamento MCP - Token bearer letto dalla nuova variabile CERBERO_BITE_MCP_TOKEN; il valore sceglie l'ambiente upstream (testnet vs mainnet) sul server. Rimosso il caricamento da file (`secrets/core.token`, CERBERO_BITE_CORE_TOKEN_FILE, Docker secret /run/secrets/core_token). - Aggiunto header X-Bot-Tag (default `BOT__CERBERO_BITE`, override via CERBERO_BITE_MCP_BOT_TAG) su ogni call MCP, con validazione lato client (non vuoto, ≤ 64 caratteri). - Cartella `secrets/` rimossa, `.gitignore` ripulito, Dockerfile e docker-compose.yml aggiornati con env passthrough e fail-fast quando manca il token. Modalità operativa (RuntimeFlags) - Nuovo modulo `config/runtime_flags.py` con `RuntimeFlags( data_analysis_enabled, strategy_enabled)` e loader che parserizza CERBERO_BITE_ENABLE_DATA_ANALYSIS e CERBERO_BITE_ENABLE_STRATEGY (true/false/yes/no/on/off/enabled/disabled, case-insensitive). - L'orchestratore espone i flag, audita e logga la modalità al boot (`engine started: env=… data_analysis=… strategy=…`), e in `install_scheduler` esclude i job `entry`/`monitor` quando strategy è off e il job `market_snapshot` quando data analysis è off. I job di infrastruttura (health, backup, manual_actions) restano sempre attivi. - Default profile = "solo analisi dati" (data_analysis=true, strategy=false), pensato per la finestra di soak post-deploy. GUI saldi - `gui/live_data.py::_fetch_deribit_currency` riconosce il campo soft `error` nel payload V2 (HTTP 200 con `error` valorizzato dal server quando l'auth Deribit fallisce) e lo propaga come `BalanceRow.error`, evitando di mostrare un fuorviante equity = 0,00. CLI - Sostituita l'opzione `--token-file` con `--token` (stringa) sui comandi start/dry-run/ping; il default proviene dall'env. Le chiamate al builder dell'orchestrator passano anche `bot_tag` e `flags`. Documentazione - `docs/04-mcp-integration.md`: descrizione del nuovo flusso di auth V2 (token = ambiente, X-Bot-Tag nell'audit) e router unificati. - `docs/06-operational-flow.md`: nuova sezione "Modalità operativa" con i tre profili canonici e tabella di gating per ogni job; aggiunto `market_snapshot` al cron summary. - `docs/10-config-spec.md`: nuova sezione "Variabili d'ambiente" tabellare con tutti gli env, comprese le bool dei flag operativi. - `docs/02-architecture.md`: layout del repo aggiornato (`secrets/` rimosso, `runtime_flags.py` aggiunto), descrizione di `config/` estesa. Test - 5 nuovi test su `_fetch_deribit_currency` (soft-error, payload pulito, eccezione, error blank, signature parity). - 7 nuovi test su `load_runtime_flags` (default, override, parsing truthy/falsy, blank fallback, valore invalido). - 4 nuovi test su `HttpToolClient` (X-Bot-Tag default e custom, blank e troppo lungo rifiutati). - 3 nuovi test integration sull'orchestratore (gating dei job in base ai flag). - Test esistenti su token/CLI ping/orchestrator aggiornati al nuovo schema. Suite intera: 404 passed, 1 skipped (sqlite3 CLI assente sull'host di sviluppo). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -88,9 +88,9 @@ Cerbero_Bite/
|
||||
├── strategy.yaml # config golden + execution.environment
|
||||
├── strategy.local.yaml.example # override locale (gitignored)
|
||||
├── Dockerfile # image runtime + HEALTHCHECK
|
||||
├── docker-compose.yml # rete external cerbero-suite + secrets
|
||||
├── docker-compose.yml # rete external cerbero-suite, env passthrough
|
||||
├── .env.example # template variabili (token MCP, bot tag, modalità)
|
||||
├── docs/ # questa documentazione
|
||||
├── secrets/ # gitignored (solo .gitkeep + README)
|
||||
├── src/cerbero_bite/
|
||||
│ ├── __init__.py
|
||||
│ ├── __main__.py # entry point CLI
|
||||
@@ -135,7 +135,8 @@ Cerbero_Bite/
|
||||
│ ├── config/ # caricamento e validazione yaml
|
||||
│ │ ├── schema.py
|
||||
│ │ ├── loader.py
|
||||
│ │ └── mcp_endpoints.py # URL + token loader
|
||||
│ │ ├── mcp_endpoints.py # URL + token + bot tag (da .env)
|
||||
│ │ └── runtime_flags.py # ENABLE_DATA_ANALYSIS / ENABLE_STRATEGY
|
||||
│ ├── reporting/ # report umani (Fase 5)
|
||||
│ ├── gui/ # Streamlit dashboard (Fase 4.5)
|
||||
│ └── safety/ # kill switch, dead man, audit
|
||||
@@ -170,8 +171,9 @@ Cerbero_Bite/
|
||||
effetti collaterali. Espone `Orchestrator` come façade per il CLI.
|
||||
- **`state/`** persistenza. Mai logica di business. Solo CRUD.
|
||||
- **`config/`** caricamento di `strategy.yaml`, validazione,
|
||||
esposizione immutabile dei parametri. Risolve gli URL MCP e legge
|
||||
il bearer token al boot.
|
||||
esposizione immutabile dei parametri. Risolve gli URL MCP, legge
|
||||
il bearer token + il bot tag al boot ed espone i due interruttori
|
||||
operativi `RuntimeFlags(data_analysis_enabled, strategy_enabled)`.
|
||||
- **`safety/`** controlli trasversali (vedere `07-risk-controls.md`).
|
||||
- **`reporting/`** generazione di stringhe per Telegram. Niente
|
||||
logica di trading, solo formatting.
|
||||
|
||||
+32
-13
@@ -1,11 +1,15 @@
|
||||
# 04 — MCP Integration
|
||||
|
||||
Cerbero Bite consuma quattro servizi MCP HTTP della suite (`Cerbero_mcp`):
|
||||
`cerbero-deribit`, `cerbero-hyperliquid`, `cerbero-macro`,
|
||||
`cerbero-sentiment`. Non utilizza l'SDK Python `mcp`: ogni server
|
||||
espone gli endpoint REST `POST <base_url>/tools/<tool_name>` con
|
||||
autenticazione Bearer, e Cerbero Bite vi si collega tramite
|
||||
`httpx.AsyncClient` long-lived (`clients/_base.py`).
|
||||
Cerbero Bite consuma quattro router MCP HTTP della suite Cerbero MCP V2
|
||||
(`Cerbero_mcp`): `mcp-deribit`, `mcp-hyperliquid`, `mcp-macro`,
|
||||
`mcp-sentiment`. Dalla V2 i quattro router vivono nello stesso processo
|
||||
FastAPI dietro lo stesso host (default in-cluster
|
||||
`http://cerbero-mcp:9000/mcp-{exchange}`, gateway pubblico
|
||||
`https://cerbero-mcp.tielogic.xyz/mcp-{exchange}`). Cerbero Bite non
|
||||
utilizza l'SDK Python `mcp`: ogni router espone gli endpoint REST
|
||||
`POST <base_url>/tools/<tool_name>` con autenticazione Bearer e header
|
||||
`X-Bot-Tag`, e Cerbero Bite vi si collega tramite `httpx.AsyncClient`
|
||||
long-lived (`clients/_base.py`).
|
||||
|
||||
Telegram e Portfolio, in passato esposti come servizi MCP condivisi,
|
||||
sono stati rimossi dal layer MCP e gestiti **in-process** da ogni bot
|
||||
@@ -22,13 +26,19 @@ con default che corrispondono al DNS della rete Docker
|
||||
ecc.). Ogni servizio può essere sovrascritto da una variabile
|
||||
d'ambiente dedicata, utile in sviluppo:
|
||||
|
||||
| Servizio | Variabile d'ambiente | Default Docker DNS |
|
||||
| Servizio | Variabile d'ambiente | Default Docker DNS legacy |
|
||||
|---|---|---|
|
||||
| Deribit | `CERBERO_BITE_MCP_DERIBIT_URL` | `http://mcp-deribit:9011` |
|
||||
| Hyperliquid | `CERBERO_BITE_MCP_HYPERLIQUID_URL` | `http://mcp-hyperliquid:9012` |
|
||||
| Macro | `CERBERO_BITE_MCP_MACRO_URL` | `http://mcp-macro:9013` |
|
||||
| Sentiment | `CERBERO_BITE_MCP_SENTIMENT_URL` | `http://mcp-sentiment:9014` |
|
||||
|
||||
I default mostrati sopra sono il legacy della topologia V1 (un container
|
||||
per servizio). Sulla V2 unificata ogni URL deve includere il prefisso di
|
||||
router, ad esempio `http://cerbero-mcp:9000/mcp-deribit` o
|
||||
`https://cerbero-mcp.tielogic.xyz/mcp-deribit`. Le URL effettive sono
|
||||
configurate in `.env`.
|
||||
|
||||
Telegram (notify-only) viene configurato direttamente via due
|
||||
variabili d'ambiente, lette al boot dal client in-process:
|
||||
|
||||
@@ -40,17 +50,26 @@ variabili d'ambiente, lette al boot dal client in-process:
|
||||
Quando una delle due manca, il client Telegram entra in modalità
|
||||
**disabled** e ogni `notify_*` diventa un no-op a livello di DEBUG.
|
||||
|
||||
Il bearer token per le chiamate è il token con capability `core` letto
|
||||
da `secrets/core.token` (path configurabile via
|
||||
`CERBERO_BITE_CORE_TOKEN_FILE`, default `/run/secrets/core_token` nel
|
||||
container). Non è loggato.
|
||||
Il bearer token per le chiamate è letto dalla variabile d'ambiente
|
||||
`CERBERO_BITE_MCP_TOKEN` (vedi `.env`). Sulla V2 il valore del token
|
||||
decide quale ambiente upstream serve la richiesta: lo stesso server MCP
|
||||
fronteggia testnet e mainnet contemporaneamente, e si passa da uno
|
||||
all'altro semplicemente sostituendo il valore della variabile e
|
||||
riavviando il bot. Il token non viene mai loggato.
|
||||
|
||||
A ogni chiamata Cerbero Bite aggiunge anche l'header `X-Bot-Tag`, con
|
||||
valore di default `BOT__CERBERO_BITE` (override via
|
||||
`CERBERO_BITE_MCP_BOT_TAG`). Il server MCP scrive il valore nell'audit
|
||||
record di ogni operazione di scrittura, così ogni write resta
|
||||
attribuibile al bot d'origine.
|
||||
|
||||
```python
|
||||
# clients/_base.py — sintesi
|
||||
class HttpToolClient:
|
||||
service: str # "deribit", "macro", ...
|
||||
base_url: str # "http://mcp-deribit:9011"
|
||||
token: str # bearer
|
||||
base_url: str # "https://cerbero-mcp.tielogic.xyz/mcp-deribit"
|
||||
token: str # bearer (testnet o mainnet, scelto da env)
|
||||
bot_tag: str = "BOT__CERBERO_BITE" # X-Bot-Tag header
|
||||
timeout_s: float = 8.0
|
||||
retry_max: int = 3 # esponenziale 1s/5s/30s
|
||||
client: httpx.AsyncClient | None # condiviso dal RuntimeContext
|
||||
|
||||
@@ -223,7 +223,61 @@ proposed
|
||||
| `0 2,14 * * *` | Position monitoring | 2× giorno |
|
||||
| `0 12 1 * *` | Kelly recalibration | Mensile |
|
||||
| `*/5 * * * *` | Health check | 5 min |
|
||||
| `*/15 * * * *` | Market snapshot (calibrazione soglie) | 15 min |
|
||||
| `0 0 * * *` | Backup SQLite + rotation log | Giornaliero |
|
||||
| `0 8 * * *` | Daily digest Telegram | Giornaliero |
|
||||
|
||||
Tutti gli orari in UTC.
|
||||
|
||||
## Modalità operativa (interruttori `RuntimeFlags`)
|
||||
|
||||
Il bot riconosce due interruttori indipendenti, letti da
|
||||
`.env` al boot tramite `cerbero_bite.config.runtime_flags.load_runtime_flags()`:
|
||||
|
||||
| Variabile d'ambiente | Default | Cosa abilita |
|
||||
|---|---|---|
|
||||
| `CERBERO_BITE_ENABLE_DATA_ANALYSIS` | `true` | Job `market_snapshot` ogni 15 min: raccolta dati MCP, scrittura tabella `market_snapshots`, calibrazione soglie. |
|
||||
| `CERBERO_BITE_ENABLE_STRATEGY` | `false` | Job `entry` (lunedì 14:00 UTC) e `monitor` (2× giorno): valutazione regole §2-§9 di `01-strategy-rules.md` e proposta/esecuzione ordini. |
|
||||
|
||||
I job di infrastruttura (`health`, `backup`, `manual_actions`) sono
|
||||
**sempre attivi**, indipendentemente dai flag, perché tengono in vita il
|
||||
kill switch e la persistenza.
|
||||
|
||||
### Profilo "solo analisi dati" (default)
|
||||
|
||||
Configurazione standard del periodo di soak post-deploy:
|
||||
|
||||
```env
|
||||
CERBERO_BITE_ENABLE_DATA_ANALYSIS=true
|
||||
CERBERO_BITE_ENABLE_STRATEGY=false
|
||||
```
|
||||
|
||||
Effetto: il bot raccoglie snapshot di mercato, alimenta `market_snapshots`,
|
||||
ma **non** invia entry né chiude posizioni autonomamente. I metodi
|
||||
`run_entry`/`run_monitor` restano richiamabili manualmente da CLI
|
||||
(`cerbero-bite dry-run --cycle entry|monitor`) e tramite `manual_actions`
|
||||
per testing e validazione.
|
||||
|
||||
### Profilo "trading attivo"
|
||||
|
||||
```env
|
||||
CERBERO_BITE_ENABLE_DATA_ANALYSIS=true
|
||||
CERBERO_BITE_ENABLE_STRATEGY=true
|
||||
```
|
||||
|
||||
Effetto: tutti i job canonici vengono installati nello scheduler. Lo
|
||||
switch va fatto solo dopo che la qualità dei dati raccolti è stata
|
||||
validata e Adriano dà esplicito consenso al passaggio.
|
||||
|
||||
### Disattivazione completa dell'analisi dati
|
||||
|
||||
Caso eccezionale (manutenzione, problema MCP):
|
||||
|
||||
```env
|
||||
CERBERO_BITE_ENABLE_DATA_ANALYSIS=false
|
||||
CERBERO_BITE_ENABLE_STRATEGY=false
|
||||
```
|
||||
|
||||
Il bot resta vivo per health check e ricezione di manual actions, ma
|
||||
non interroga MCP per dati di mercato e non opera. Il kill switch resta
|
||||
operativo.
|
||||
|
||||
@@ -307,3 +307,31 @@ Non è permesso parametrizzare:
|
||||
superiori, non ulteriormente liberalizzabili).
|
||||
- Lo **scheduler** per intervalli più stretti (un'ottimizzazione che
|
||||
non si fa via config).
|
||||
|
||||
## Variabili d'ambiente
|
||||
|
||||
`strategy.yaml` definisce **cosa** fa il bot quando è acceso. Le
|
||||
variabili d'ambiente in `.env` definiscono **come** si collega al
|
||||
mondo esterno e **quali interruttori operativi** sono attivi.
|
||||
Queste vivono fuori da `strategy.yaml` perché cambiano per ambiente
|
||||
(testnet vs mainnet, soak vs trading) ma non per regola di strategia.
|
||||
|
||||
| Variabile | Tipo | Default | Uso |
|
||||
|---|---|---|---|
|
||||
| `CERBERO_BITE_MCP_TOKEN` | string (obbligatoria) | — | Bearer token presentato a Cerbero MCP V2. Il valore decide l'ambiente upstream (testnet o mainnet). Cambia il valore = cambia l'ambiente. |
|
||||
| `CERBERO_BITE_MCP_BOT_TAG` | string ≤ 64 char | `BOT__CERBERO_BITE` | Header `X-Bot-Tag` registrato nell'audit log del server MCP per ogni write. |
|
||||
| `CERBERO_BITE_MCP_DERIBIT_URL` | URL | gateway pubblico | Override URL router Deribit. |
|
||||
| `CERBERO_BITE_MCP_HYPERLIQUID_URL` | URL | gateway pubblico | Override URL router Hyperliquid. |
|
||||
| `CERBERO_BITE_MCP_MACRO_URL` | URL | gateway pubblico | Override URL router Macro. |
|
||||
| `CERBERO_BITE_MCP_SENTIMENT_URL` | URL | gateway pubblico | Override URL router Sentiment. |
|
||||
| `CERBERO_BITE_ENABLE_DATA_ANALYSIS` | bool (`true`/`false`) | `true` | Abilita il job `market_snapshot` (raccolta dati MCP ogni 15 min). |
|
||||
| `CERBERO_BITE_ENABLE_STRATEGY` | bool (`true`/`false`) | `false` | Abilita i job `entry` e `monitor` (esecuzione regole §2-§9). |
|
||||
| `CERBERO_BITE_TELEGRAM_BOT_TOKEN` | string | — | Token bot Telegram (notify-only). Senza, il client è in modalità disabled. |
|
||||
| `CERBERO_BITE_TELEGRAM_CHAT_ID` | string | — | Chat ID destinatario notifiche Telegram. |
|
||||
|
||||
I valori bool accettano in input `1`/`0`, `true`/`false`, `yes`/`no`,
|
||||
`on`/`off`, `enabled`/`disabled` (case-insensitive). Qualunque altro
|
||||
valore fa fallire il boot con `ValueError`.
|
||||
|
||||
Vedi `06-operational-flow.md` §"Modalità operativa" per i profili
|
||||
canonici di `ENABLE_DATA_ANALYSIS` e `ENABLE_STRATEGY`.
|
||||
|
||||
Reference in New Issue
Block a user