Qué sobrevive a un reinicio

Qué hay en el disco cuando un proceso muere, qué queda solo en memoria y qué vuelve a iniciar la ejecución. Cerrar el editor, una caída, una máquina que duerme y un reinicio del equipo son casos distintos.

Quién sigue en marcha #

El daemon está desacoplado del terminal y del editor que lo iniciaron, así que cerrar cualquiera de los dos no lo detiene. Un proceso supervisor inicia el daemon y lo inicia de nuevo cuando sale con la ejecución aún activa, que es lo que parece una caída.

El supervisor no reinicia un daemon tras un stop, un pause, o una ejecución que terminó como idle, error o completed. Se rinde tras más de 5 reinicios en 5 minutos. Entonces escribe supervisor.giveup en el log y pone el estado en error. En Windows, el supervisor también pide al sistema operativo que no duerma mientras la ejecución está activa, para que una espera al reinicio de un límite de uso no duerma con ella.

Una máquina que entra en suspensión por sí sola congela esos procesos en lugar de terminarlos, y la ejecución sigue cuando despierta. Un apagado o un reinicio del equipo los termina, y la sección sobre reinicios del equipo trata de qué vuelve a iniciar la ejecución.

Cuando una ejecución termina #

Cuando el bucle vuelve, el daemon sale, y no espera nada que un participante inició desde un turno y dejó en marcha, como un servidor de desarrollo. El supervisor ve la salida y hace lo que pide una ejecución terminada: libera la petición de mantener la máquina despierta, cierra el navegador que la ejecución mantuvo abierto para las herramientas de navegador y decide si la máquina puede suspenderse.

Ese último paso es opcional. Con suspendOnCompletion activado, AutoDev pone la máquina a dormir cuando la ejecución terminó o se detuvo esperándote, si nada más la necesita. Viene desactivado por defecto, y Suspender la máquina enumera las condiciones.

Qué sobrevive #

Elemento	Tras un reinicio	Por qué
El objetivo, la memoria, los participantes y la configuración	Se conserva	Son archivos en `.autodev/`.
El hilo y el cursor de cada participante	Se conserva	`thread.jsonl` y `cursors.json` están en el disco. Al siguiente turno se le informa de lo que es nuevo para él.
Un mensaje tuyo que nadie ha leído aún	Se conserva	`inbox.json` lo guarda hasta que el daemon lo vacía.
El estado, y un gate, una propuesta o una pregunta pendiente para ti	Se conserva	`state.json` los guarda. Una ejecución `gated`, `proposed` o `awaiting_user` no se relanza, porque la decisión es tuya.
Los avisos que los participantes te dejaron	Se conserva	`notices.json` los guarda con las respuestas y las retenciones.
El reloj de una espera, la cuenta de rechazos de la auditoría y la racha de turnos de conversación	Se conserva	Están en `state.json`, así que una caída no reinicia el tope.
El gasto	Se conserva	`state.json` guarda el total acumulado.
La sesión de cada participante	Se conserva	`sessions.json` guarda el id de sesión, así que un turno puede retomar la misma conversación. Una sesión pertenece al proveedor que la creó, así que un participante que pasó a otro proveedor empieza una nueva.
Los checkpoints	Se conserva	Son commits de git, y `checkpoints.json` los lista.
El ledger de cuota	Se conserva	`quota.jsonl` nunca rota.
El presupuesto de tiempo de ejecución	Empieza de nuevo	Se mide desde el inicio de cada ejecución del daemon.
Qué proveedor está limitado o fuera de alcance	Se pierde	El registro está en memoria, y un reinicio vuelve a sondear.
Un turno que estaba en marcha	Se pierde	Ver abajo.

thread.jsonl, state.json, sessions.json y el resto de los archivos de la máquina están en ~/.autodev/<project>-<hash>/, y goal.md, memory.md, participants/ y config.json están en .autodev/. Dónde vive el estado enumera ambos lugares.

Un turno que estaba en marcha #

Un participante que muere antes de publicar no deja nada en el hilo, porque una publicación es lo único que llega a él. Su cursor no avanzó, así que su siguiente turno ve de nuevo las mismas publicaciones.

Los archivos que el turno ya había escrito se quedan en el árbol de trabajo. Cuando el daemon arranca de nuevo, el checkpoint baseline confirma los cambios sin commit como autodev: baseline before run, salvo que los checkpoints estén apagados o la carpeta no sea un repositorio git. AutoDev no retoma un turno a la mitad. Empieza uno nuevo.

Tras un reinicio del equipo #

Nada arranca solo tras un reinicio del equipo. AutoDev no se registra para arrancar con el sistema, así que la ejecución queda detenida hasta que algo la inicie. state.json sigue diciendo que la ejecución está activa, y su pid no pertenece a nada, así que autodev status y el panel la muestran como detenida.

Estas cosas la inician de nuevo:

autodev sin comando, ejecutado en el proyecto. Relanza una ejecución cuyo estado era running, planning o waiting, y una que está rate_limited, que entonces duerme hasta que el límite se reinicia. No relanza una ejecución en ningún otro estado. Si un servidor estaba en marcha desacoplado con autodev serve --daemon, también lo inicia de nuevo.
autodev start, que inicia el daemon sea cual fuese el estado, o dice que ya hay uno en marcha. Una petición de pausa que quedó se borra, ya que iniciar es la intención de continuar. autodev resume solo registra la petición, y no lanza un daemon.
Un mensaje enviado desde el panel o con autodev send, cuando ningún daemon está vivo y el equipo está armado y confirmado en esta máquina. La ejecución arranca para leerlo.
Approve, en un gate que esperaba. Registra la aprobación e inicia la ejecución.

El panel no relanza una ejecución al abrirse. Para una ejecución que se detuvo sola, dice the run is paused and will not resume on its own — send a message to resume.

Cómo se nota una ejecución muerta #

AutoDev no se fía solo del campo de estado. Comprueba que el pid de state.json está vivo, y que el proceso es un proceso de AutoDev de este proyecto. Un pid que un reinicio del equipo entregó a otro programa cuenta como muerto. Una comprobación que no puede responder cuenta como viva, para que AutoDev nunca inicie un segundo daemon bajo uno vivo.

Cuando el pid está muerto y el estado sigue siendo uno activo, AutoDev borra el pid y conserva el estado y la tarea actual, lo que permite relanzar la ejecución donde estaba.

El archivo de memoria #

Toda ejecución empieza con un memory.md. Cuando una ejecución arranca, AutoDev crea uno vacío si no hay ninguno, así que una ejecución iniciada desde el panel también tiene un archivo que su primer participante puede leer. Cada participante sabe dónde está, que debe leerlo primero cuando su contexto se compacta, y que debe escribir en él con las herramientas remember, revise y forget: decisiones y por qué, restricciones, callejones sin salida y todo lo que un turno futuro pagaría por volver a aprender.

Por eso una ejecución sobrevive a un reinicio de la forma que importa: una sesión nueva tiene el hilo y memory.md, y no necesita la conversación que los produjo. Una restauración no devuelve el archivo, y autodev new-run lo copia al archivo histórico antes de vaciarlo. autodev memory lo imprime. Dónde vive el estado describe el archivo.

Checkpoints y restauración trata de la vuelta atrás, y La ejecución se detuvo y por qué trata de leer una ejecución detenida. Todos los comandos de la CLI describe autodev start y autodev sin comando.