fn_registry/dev/issues/0088j-trading-reactive-loop-wiring.md

id, title, status, type, domain, scope, priority, depends, blocks, related, created, updated, tags

id	title	status	type	domain	scope	priority	depends	blocks	related	created	updated	tags
0088j	Trading: wiring del bucle reactivo (assertions + proposals)	pendiente	feature	trading frontend	multi-app	alta				2026-05-17	2026-05-17

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.