La ejecución se detuvo y por qué

Cómo leer por qué una ejecución no avanza. Los estados que usa AutoDev, el motivo que registra cada vez que se pausa o se detiene, y qué continúa cada uno.

Lee el motivo #

Una ejecución que se detuvo registra su propio motivo. autodev status imprime el estado, autodev report imprime el motivo junto a él, y el panel dice lo mismo en Needs you y en la barra de estado. autodev status imprime estas líneas:

autodev status

Project: <name>
Status: <status>
Daemon: pid <n> (alive)
Current task: <task>
Iteration: <n>
Est. cost: $<n>
Heartbeat: <n>s ago
Next resume: <time>
Web: not serving
Waiting: <reason> (<n>m elapsed)

Status es uno de idle, running, rate_limited, waiting, paused, gated, awaiting_user, completed o error. Daemon es pid <n> (alive) o stopped. Next resume es la hora en que termina un límite de uso, o None. Waiting aparece solo mientras el estado es waiting. El heartbeat recibe (stalled?) al final solo cuando el daemon está vivo, la ejecución está activa y el último heartbeat tiene 40 minutos o más.

running, rate_limited y waiting afirman que el bucle se está ejecutando. Vistos sin ningún daemon vivo, son lo que queda de una ejecución terminada a la fuerza: la barra de estado muestra (stopped) junto a ellos, y autodev report muestra (stale).

autodev report abre con una línea para el motivo. Una ejecución que pausaste tú se lee paused by you · daemon stopped. Cualquier otra ejecución detenida se lee <status> · daemon stopped · <el último motivo>, donde el motivo es el último evento que terminó algo, y una ejecución viva se lee <status> · alive. En el panel, una ejecución pausada o en error sin daemon añade un elemento en Needs you que dice que no se reanudará sola. Una ejecución que pausaste tú no lo recibe, porque terminar esa pausa te toca a ti. El feed termina con stopped o completed a la hora en que acabó.

La detuviste o pausaste tú #

autodev stop y el control Stop terminan la ejecución en la iteración actual, con el estado idle y el evento Stop requested. autodev pause y el control Pause dejan el estado paused con Pause requested, y AutoDev recuerda que la pausa fue tuya. Ninguna de las dos es un fallo, y ninguna se reanuda sola.

AutoDev mantiene separados los dos tipos de pausa: una pausa tuya no se señala como algo que te necesita, y una causada por un límite de seguridad sí, como muestra la sección siguiente.

Terminó #

El estado es completed, y el log tiene All tasks resolved. El daemon ya salió. Para dar más trabajo a un proyecto terminado, envía un mensaje: el compositor del panel, o autodev send "<message>", que imprime Message sent; run started. Para empezar de nuevo con un hilo vacío, autodev new-run archiva este antes.

Alcanzó un tope #

Un límite de seguridad pausa la ejecución, y el estado es paused. El motivo es un evento en el log, con uno de estos mensajes:

Mensaje	Causa	Qué lo activa
`Budget reached: spend cap reached (...); pausing`	El gasto estimado alcanzó el tope.	`maxSpendUsd`
`Budget reached: runtime budget reached (...); pausing`	Se agotó el presupuesto de tiempo real. El tiempo esperando un límite de uso o una condición no cuenta.	`maxRuntimeMin`
`Reached max iterations (N); pausing`	El bucle alcanzó su tope de iteraciones.	`maxIterations`
`No progress for N iterations; pausing`	Ninguna publicación se verificó como trabajo durante 10 iteraciones.	ninguna clave de configuración: el valor predeterminado es 10
`Waited ... and gave up`	Una espera superó su tope.	`maxWaitMin`
`Completion audit still finds gaps; run paused for review — send a message to resume`	La auditoría reabrió la ejecución demasiadas veces.	`maxAcceptChecks`
`The thread is producing no work; run paused for review — send a message to resume`	Demasiadas publicaciones consecutivas que no eran trabajo.	`maxTalkTurns`
`No participants; run paused until a team is set up`	No hay equipo.	configurar el equipo

Una ejecución que vuelve a empezar se pausa de nuevo mientras el límite siga alcanzado, así que sube primero el límite, con autodev config set o el destino Config, y luego continúa. Todas las claves de configuración enumera los ajustes.

Se rindió con una llamada que falla #

Un turno que falla sin ser un límite de uso es un fallo de infraestructura: la CLI no arrancó, no se pudo alcanzar o murió. AutoDev lo reintenta en una escala creciente, empezando en un segundo y esperando luego 1, 2, 4, 8, 15 y 30 minutos, y después una hora. Cada turno que falla registra Turn failed (infra); will retry: seguido de lo que dijo la CLI, y cada reintento registra Attempt N of 12 failed (...); trying again at <time>. Tras 12 fallos seguidos, unas cinco horas, la ejecución se pausa con Gave up after 12 failed attempts in a row, over five hours (...); run paused — resume to try again. Un turno que funciona reinicia la cuenta.

Dos casos difieren. Cuando la API del proveedor no se puede alcanzar en absoluto, AutoDev trata al proveedor como fuera para todos los que están en él, como un límite. El evento es <provider> could not be reached; trying it again at <time>, la espera es de 1, 2, 4 y 8 minutos y luego cada 15 minutos, no hay plazo, y un participante en otro proveedor sigue trabajando mientras tanto. Proveedores y failover los distingue de un límite de uso.

El otro caso es un participante que sigue terminando su turno sin publicar. Cada turno así registra Turn ended without a post, y nombra la causa probable cuando puede: la CLI rechazó el permiso para las herramientas de AutoDev, la línea de comandos llegó rota en Windows, o la CLI no tiene herramientas de hilo. En el tercer turno seguido la ejecución se pausa con @<participant> ended 3 turns without posting; pausing instead of spending more quota — send a message to resume. Arregla primero la CLI del participante, ya que terminará todo turno de la misma manera. No se encontró ninguna CLI de agente y CLI sin autenticar cubren las dos causas habituales.

Espera, no se detuvo #

Dos estados parecen una parada y no lo son. El daemon está vivo, el heartbeat sigue avanzando, y la ejecución continúa sola.

rate_limited: todos los participantes están en un límite de uso. Next resume es la hora en que vuelve el primero, y la ejecución continúa entonces. Proveedores y failover dice cómo se mueve el turno mientras tanto.
waiting: un participante se negó a empezar, por un motivo que Waiting imprime, como una persona trabajando en la misma carpeta. AutoDev vuelve a comprobar, a intervalos que crecen hasta 30 minutos, y pausa la ejecución con Waited ... and gave up cuando la espera supera maxWaitMin, que son 240 minutos por defecto.

Te espera a ti #

Dos estados son paradas deliberadas. AutoDev no los reinicia, y nada los reanuda solo.

gated: una acción irreversible espera. Apruébala o deniégala en el panel con Approve o Deny, o ejecuta autodev approve o autodev deny. Con el gateMode predeterminado, auto, AutoDev aprueba los gates que se le muestran, así que esto ocurre cuando defines gateMode como gated. Una acción que se aprobó y luego falló no se vuelve a intentar: la ejecución se detiene con Approved action failed; run halted: <action> y el estado error.
awaiting_user: el hilo te pasó el turno, con @<participant> is waiting for you. El daemon sale, y tu próximo mensaje lo inicia de nuevo. autodev answer es para avisos, no para esto.

Murió #

error significa que la ejecución se pausó tras 5 errores de paso consecutivos, con el mensaje Pausing after 5 consecutive step errors, o que el proceso siguió muriendo: Supervised process died N times within 300s; giving up, tras 5 reinicios en 5 minutos. Los errores de paso están en el log con sus mensajes.

Un estado activo con Daemon: stopped significa que el proceso desapareció, terminado a la fuerza o con la máquina apagada. autodev sin comando reinicia una ejecución que quedó en running, waiting o rate_limited, y autodev start reinicia el daemon sea cual sea el estado. Qué sobrevive a un reinicio dice desde dónde arranca el nuevo daemon.

Continúala #

Toda parada de arriba termina igual, en una de estas:

Envía un mensaje. En el panel, el compositor inicia la ejecución de nuevo cuando hay un equipo montado y de confianza. Desde una terminal, autodev send "<message>".
Ejecuta autodev start. Reinicia el daemon y limpia una pausa. autodev resume por sí solo solo escribe la petición, así que no reinicia un daemon que salió.
Aprueba o deniega un gate.
Ejecuta autodev restore para rebobinar el código hasta un checkpoint, después de autodev stop, cuando la ejecución salió mal en lugar de detenerse. Checkpoints y restauración lo trata.
Ejecuta autodev new-run para archivar el hilo y empezar de nuevo.

El panel no tiene botón Resume ni Retry. Leer los logs muestra dónde se escriben los motivos.

Esta página no sabe por qué falló una llamada de CLI. El error de paso, o la propia salida de la CLI en el log, lleva ese mensaje.