82 lines
4.9 KiB
Markdown
82 lines
4.9 KiB
Markdown
---
|
||
id: "0088"
|
||
title: "Trading & Skill Management Roadmap"
|
||
status: pendiente
|
||
type: epic
|
||
domain:
|
||
- trading
|
||
scope: cross-stack
|
||
priority: alta
|
||
depends: []
|
||
blocks: []
|
||
related: []
|
||
created: 2026-05-17
|
||
updated: 2026-05-17
|
||
tags: []
|
||
---
|
||
# 0088 — Trading & Skill Management Roadmap
|
||
|
||
**Status:** pendiente
|
||
**Created:** 2026-05-14
|
||
**Type:** planning
|
||
**Related:** 0085 (telemetry), 0086 (delegation), 0087 (capability discovery), 0068 (e2e validation), 0069 (autonomous loop)
|
||
**Sub-issues:** 0088a–0088j
|
||
|
||
## Problema
|
||
|
||
Trading manual (multi-fuente, multi-cuenta) es una habilidad medible que se beneficia del mismo bucle reactivo que el registry: CONSTRUIR → EJECUTAR → RECOPILAR → ANALIZAR → MEJORAR. Falta la instanciacion concreta: ledger inmutable, broker connectors, strategy contract, risk gates, reflection log y un live runner gobernado por assertions. El registro ya tiene primitivas puras de finance (SMA/EMA/RSI/Bollinger/VWAP/Sharpe/Drawdown/GBM/Avellaneda-Stoikov/Hawkes) e impuras minimas (`fetch_ohlcv`, `stream_ticks`, `tick_to_ohlcv`, `write_ohlcv_to_parquet`, `load_ohlcv_from_duckdb`), pero no hay broker integration, ledger ni runner.
|
||
|
||
Objetivo: tratar **trading como skill autoiterado** sobre el bucle reactivo, con metricas explicitas (PnL realizado, drawdown, sharpe live vs backtest, slippage, win-rate, adherencia a reflection log) que se evaluan por assertions y generan proposals automaticas.
|
||
|
||
## Filosofia
|
||
|
||
1. **Skill = control loop con ledger inmutable**. Sin INSERT-only ledger no hay verdad; sin verdad no hay mejora.
|
||
2. **Paper-first**. Adapter `broker_paper` cumple la misma interfaz que cualquier broker real. Switch por config.
|
||
3. **Reflection obligatoria**. La UI del journal fuerza post-mortem antes de cerrar un trade. Sin reflexion, el bucle no progresa.
|
||
4. **Kill-switch como funcion del registry**, invocable desde CLI/UI/cron. Definida ANTES del primer broker live.
|
||
5. **Bucle reactivo del registry == bucle reactivo del skill**. Las assertions que vigilan al runner son del mismo tipo que las que vigilan a las apps.
|
||
|
||
## Pilares + sub-issues
|
||
|
||
| # | Sub-issue | Pieza | Tipo |
|
||
|---|---|---|---|
|
||
| 0088a | Project scaffolding `projects/trading/` + vault `market_data` | infra |
|
||
| 0088b | Capability group `market_data` + adapters (binance, yfinance, alphavantage; cpp/py) | feature |
|
||
| 0088c | Capability group `broker` + interface comun + adapter `broker_paper` | feature |
|
||
| 0088d | App `portfolio_tracker` (ledger INSERT-only + sqlite_api + Mantine UI) | feature |
|
||
| 0088e | Capability group `strategy` + contrato Strategy + 2 pure strategies de referencia | feature |
|
||
| 0088f | Capability group `risk` (kelly, max_loss, exposure_cap, correlation_filter) + kill_switch | feature |
|
||
| 0088g | App `backtester` (corre Strategy contra historico, produce reporte deterministico) | feature |
|
||
| 0088h | App `live_runner` (service, paper-only on master; broker real detras de feature flag OFF) | feature |
|
||
| 0088i | App `trading_journal` (reflection log + UI con tags + screenshots) | feature |
|
||
| 0088j | Wiring del bucle reactivo: `e2e_checks` + assertions especificas de trading + proposals automaticas | infra |
|
||
|
||
## Decisiones criticas (resolver antes de 0088c)
|
||
|
||
- **Multi-account, multi-currency, multi-asset desde dia 1** en el schema del ledger. Migracion posterior es dolorosa.
|
||
- **`client_order_id` deterministico** para idempotencia. Hash de `(strategy_id, intent_ts, intent_hash)`.
|
||
- **Reconciliacion** broker ↔ ledger en cada ciclo del live runner. Discrepancia > epsilon → halt + proposal.
|
||
- **Backtest != live**. Assertion sobre `|sharpe_backtest - sharpe_live|` y sobre `slippage_realized - slippage_modeled`.
|
||
- **Datos sensibles**. Credenciales de broker en `~/.fn_secrets` o gestor externo, nunca en `operations.db`.
|
||
|
||
## Plan de ejecucion
|
||
|
||
Tres tandas, cada una mergeable a master con master desplegable:
|
||
|
||
- **Tanda A (foundations)**: 0088a + 0088d (ledger sin broker) + 0088f (risk + kill_switch como funciones puras).
|
||
- **Tanda B (paper loop cerrado)**: 0088b + 0088c (solo paper) + 0088e + 0088g.
|
||
- **Tanda C (live + bucle reactivo)**: 0088h (behind flag OFF) + 0088i + 0088j. Activacion live = commit explicito que flip-flop el flag tras N sesiones paper estables.
|
||
|
||
## Aceptacion del roadmap
|
||
|
||
- Cada sub-issue cerrado con su `e2e_checks` declarado en `app.md` cuando aplique.
|
||
- `docs/capabilities/trading.md` (o split: market_data / broker / strategy / risk / journal) listando primitivas reutilizables.
|
||
- Kill-switch invocable: `./fn run halt_all_strategies_py_finance` (o equivalente). Verificable en frio.
|
||
- Primer ciclo paper de 7 dias con ledger reconciliado, reflection log >= 1 entry por trade, assertions pasadas o explicadas via proposals.
|
||
|
||
## No-objetivos
|
||
|
||
- Optimizacion HFT, latencia sub-ms, market making real en exchange.
|
||
- Multi-tenant (esto es para uso personal).
|
||
- Estrategias proprietarias secretas — el registry es publico-local, cualquier estrategia debe encajar como funcion pura testeable. Edge se protege via parametros en `~/.fn_secrets/strategies.yaml`, no via codigo oculto.
|