Ejecuciones de corrección
Una ejecución de corrección es el agente trabajando un issue. Cada issue recibe como máximo una: un hilo de tipo fix_run que llega al veredicto y, en un problema confirmado, sigue trabajándolo hasta una corrección en la misma conversación.
Qué hace
El hilo es donde lees toda la historia: el trabajo a medida que ocurre, la evidencia a un clic en su linaje y el resultado al final. La ejecución lee la alerta o el hallazgo, la consulta que hay detrás, las métricas y logs recientes en torno al disparo, los cambios recientes y tu código. Antes de actuar, escribe la cadena causal en el hilo: la señal, el mecanismo, el componente y la ruta de código que la producen, el desencadenante y el radio de impacto, cada eslabón respaldado por evidencia con nombre o marcado como desconocido.
Cómo funciona
- Una ejecución empieza cuando una comprobación o una alerta conectada produce un hallazgo, cuando un agente en un hilo de chat abre un issue a partir del problema que estás tratando, o cuando eliges Investigate en un issue.
- El agente lee la evidencia y llega a uno de dos veredictos,
confirmedodismissed. Un hallazgo que coincide con un issue existente se une a él en lugar de iniciar una segunda ejecución. - En un problema confirmado, el mismo agente rastrea la causa y escribe la cadena causal.
- Cuando un cambio de código corrige la causa en un repositorio conectado, la ejecución abre el pull request a través de autofix. Cuando ningún pull request puede corregirlo, la ejecución plantea un escalado que nombra lo que una persona tiene que hacer.
- Cada paso aterriza en la línea de tiempo de actividad del issue, junto a las detecciones, las nuevas detecciones y tus propias notas.
Resultados
Tras cada turno del agente, Polylane clasifica la ejecución.
| Resultado | Descripción |
|---|---|
resolved | Causa raíz encontrada y el problema está corregido o se ha recuperado. |
diagnosed | Causa raíz encontrada, pero la corrección aún no ha llegado. |
inconclusive | El agente no pudo decidirse por una causa. |
false_positive | El hallazgo no apuntaba a un problema real. |
failed | La ejecución terminó con un error. |
Una ejecución también puede aparcarse, lo que impide que la monitorización la empuje a volver a investigar hasta que el issue se resuelva.
| Estado aparcado | Descripción |
|---|---|
needs_human_action | La corrección requiere algo que solo tú puedes hacer. |
needs_decision | El agente necesita una decisión tuya antes de continuar. |
awaiting_change | El agente espera a que llegue una corrección, por ejemplo un pull request pendiente de revisión. Este estado se aparca en silencio. |
failed | La ejecución encontró un error que no pudo sortear. |
Los tres estados que necesitan a una persona se registran como escalados, se muestran en la tarjeta de resultado del hilo y se listan en el preajuste Needs you, así que la misma petición nunca te notifica dos veces.
Dónde encontrarlo
Las ejecuciones de corrección aparecen en Threads junto a los hilos de chat, y el preajuste Needs you lista las que esperan a una persona. El Lineage en la barra lateral del hilo contiene el registro detrás de la ejecución: Issue abre la evidencia y la línea de tiempo del issue, Escalation abre lo que el agente te pidió con Mark as handled, y Check abre la evaluación que detectó el problema. El menú del issue lleva Investigate, Investigate again, View investigation y View triggering check.
Configurar
En Settings > Workspace, la tarjeta Investigations fija Investigate automatically from: la severidad más baja que inicia una ejecución de corrección por sí sola. Los issues por debajo conservan su veredicto y quedan retenidos, y su hilo ofrece Start investigation para que alguien de tu equipo pueda retomarlos. Los veredictos nunca se retienen: cada issue confirmado se ve confirmado, y el umbral solo aplaza el trabajo que sigue.
Relacionado
- Issues para el registro que trabaja cada ejecución de corrección.
- Threads para leer, detener y compartir la ejecución.
- Escalations para las peticiones que plantea una ejecución aparcada.
- Autofix para el pull request que abre una ejecución.