fn_registry/dev/issues/0088-trading-skill-management-roadmap.md

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.