Pipes de insights

Los pipes de insights convierten una idea de trading en una secuencia controlada de decisiones. Úsalos para dimensionar posiciones, definir ventanas de negociación, comprobar la relación beneficio-riesgo, enviar entradas y gestionar posiciones. Mantén la generación de señales en el modelo alfa.

Crear una cadena específica para cada estado

Los estados actuales del motor son New, Executed, Filled, Closed, Cancelled y Rejected. La caducidad es un motivo de un resultado, no un estado Expired independiente.

Para un insight nuevo, una cadena habitual establece la intención de entrada, fija los niveles de protección, dimensiona la posición, comprueba las restricciones y lo envía. Para un insight con orden ejecutada, usa pipes de gestión para stops, toma de beneficios, salidas graduales o salidas basadas en tiempo.

El orden importa: los cálculos de cantidad en función del riesgo necesitan los datos correspondientes de precio y protección. En AQS, inspecciona la jerarquía del pipeline y las propiedades de cada nodo antes de ejecutar un backtest.

Interfaz de pipe personalizado

pub trait InsightPipe {
    fn version(&self) -> &str;
    fn run(
        &mut self,
        ctx: &mut dyn StrategyContext,
        insight: &mut Insight,
    ) -> InsightPipeResult;
}

Esta es la interfaz principal; el trait también proporciona hooks opcionales. InsightPipeResult describe si la etapa pasó la comprobación, si se completó correctamente, un mensaje opcional y cualquier dependencia que deba completarse primero.

Pendiente no es lo mismo que fallido

Los comandos del bróker y las instantáneas requeridas pueden no estar disponibles de inmediato. El entorno de ejecución conserva una continuación diferida y la reanuda cuando su dependencia está lista.

Cuando una etapa personalizada envíe un insight, convierte el resultado de la mutación con la función auxiliar proporcionada:

InsightPipeResult::from_mutation(insight.submit(ctx), self.name())

Para una etapa de salida, usa:

InsightPipeResult::from_exit_mutation(insight.close(ctx), self.name())

Estas son expresiones de retorno dentro del método run de un pipe. La función auxiliar de salida evita que etapas posteriores emitan otra salida en el mismo turno. La lógica que depende de instantáneas puede usar InsightPipeResult::from_read_error para mantener pendiente una dependencia de datos de cuenta, posición o cotización que aún no estén disponibles.

No descartes el resultado de una mutación para informar inmediatamente de un resultado satisfactorio. Una solicitud puede seguir en cola o esperando al bróker; su recibo no confirma que la orden se haya ejecutado.

Componentes integrados

Componente	Finalidad
`MarketOrderEntryPipe`	Derivar la intención de entrada a mercado del historial de velas disponible.
`InsightTtlConfigPipe`	Configurar cuánto tiempo puede permanecer activo un insight con o sin orden ejecutada.
`MinimumRiskToRewardPipe`	Validar el riesgo y el beneficio propuestos.
`InsightSubmitPipe`	Comprobar la capacidad del árbol pendiente y solicitar el envío.
`BasicStopLossPipe`	Solicitar una salida cuando se active la protección.
`BasicTakeProfitPipe`	Gestionar salidas totales o parciales de toma de beneficios.

La lógica integrada de salida gestiona la ruta de ejecución aplicable. Es preferible usar estos componentes a copiar una implementación antigua de stop o take-profit basada solo en velas dentro de una nueva estrategia en vivo.

Cantidad y capacidad del bróker

Las herramientas actuales de dimensionamiento distinguen el tamaño máximo de cada orden, la exposición agregada por símbolo y el límite de órdenes pendientes de la cuenta. Las órdenes demasiado grandes pueden dividirse en fragmentos de ejecución; esos fragmentos no son niveles DCA lógicos adicionales.

Los cálculos de capacidad incluyen las cantidades activas y reservadas de la estrategia. Otras estrategias y órdenes manuales también pueden consumir capacidad del bróker, por lo que la información de este sigue siendo la referencia definitiva. Consulta Brókeres y fuentes de datos.

Validar tus cambios

Ejecuta un backtest, inspecciona los insights rechazados y cancelados además de los que tienen órdenes ejecutadas y lee el historial de estados para conocer por qué se detuvo cada etapa. Después, verifica la misma configuración con una ejecución simulada controlada antes de usar una cuenta de ejecución en vivo.