60 lines
2.6 KiB
Markdown
60 lines
2.6 KiB
Markdown
---
|
|
id: "0088j"
|
|
title: "Trading: wiring del bucle reactivo (assertions + proposals)"
|
|
status: pendiente
|
|
type: feature
|
|
domain:
|
|
- trading
|
|
- frontend
|
|
scope: multi-app
|
|
priority: alta
|
|
depends: []
|
|
blocks: []
|
|
related: []
|
|
created: 2026-05-17
|
|
updated: 2026-05-17
|
|
tags: []
|
|
---
|
|
# 0088j — Trading: wiring del bucle reactivo (assertions + proposals)
|
|
|
|
**Status:** pendiente
|
|
**Created:** 2026-05-14
|
|
**Type:** infra
|
|
**Parent:** 0088
|
|
**Depends:** 0088d, 0088g, 0088h, 0088i
|
|
**Related:** 0068 (e2e validation fase 4-5), 0069 (autonomous loop)
|
|
|
|
## Problema
|
|
|
|
Las 4 apps de trading (portfolio_tracker, backtester, live_runner, trading_journal) tienen cada una su `operations.db`, pero no hay assertions cruzadas ni proposals automaticas que cierren el ciclo MEJORAR. Sin este wiring, el bucle reactivo se queda en EJECUTAR/RECOPILAR y no impulsa cambios.
|
|
|
|
## Piezas
|
|
|
|
1. Assertions declaradas (kind libre, ver `assertions.md`):
|
|
- `live_drawdown_under_X` (critical): si `max_drawdown_live > config.max_dd_pct` → halt + proposal.
|
|
- `sharpe_live_vs_backtest` (warning): `|sharpe_live - sharpe_backtest_reference| > 0.5` → proposal "investigar drift".
|
|
- `slippage_realized_under_modeled` (warning).
|
|
- `reflection_adherence` (critical para weekly review): `reflections_done / trades_closed < 0.8` → halt suaves (no acepta nuevos trades hasta cubrir).
|
|
- `reconciliation_clean` (critical): ledger == broker.
|
|
- `consecutive_losing_days` (warning).
|
|
2. `e2e_checks` por app declarados (cada sub-issue ya los pide; este issue verifica que cumplen el contrato 0068).
|
|
3. Proposals automaticas via `fn-mejorador`:
|
|
- Cuando una assertion critical falla, abrir proposal con evidencia (assertion_ids + execution_ids + sample trades).
|
|
- Tipos esperados: `pause_strategy`, `tune_param`, `kill_strategy`, `add_filter`.
|
|
4. Integracion con `fn-orquestador` (issue 0069): tarea autonoma `trading-skill-loop` que cada noche corre fn-analizador sobre las 4 apps, agrega resultados y abre proposals si hay rojos.
|
|
5. Dashboard tab `trading` en `registry_dashboard` (fn_monitoring) con KPIs en vivo: equity, drawdown, sharpe, adherence, n_open_proposals.
|
|
6. Cron / Dagu DAG que orquesta:
|
|
- Diario: snapshot equity + assertions + proposals.
|
|
- Semanal: weekly_review + adherence + ranking estrategias.
|
|
|
|
## Aceptacion
|
|
|
|
- 1 falla simulada de cada tipo de assertion genera 1 proposal con evidencia.
|
|
- Dashboard muestra los 5 KPIs en vivo.
|
|
- `fn-orquestador` puede correr el bucle entero sin intervencion humana (modo paper).
|
|
- Halt automatico funciona end-to-end (simulado).
|
|
|
|
## No-objetivos
|
|
|
|
- Auto-apply de proposals. El humano (o flujo aprobado del 0069) sigue siendo gate para cambios de codigo o de risk_config.
|