---
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.