O que sobrevive a um reinício

O que está no disco quando um processo morre, o que fica só na memória e o que inicia a execução de novo. Fechar o editor, uma queda, uma máquina que dorme e um reboot são casos diferentes.

Quem continua rodando #

O daemon é desacoplado do terminal e do editor que o iniciaram, então fechar qualquer um dos dois não o para. Um processo supervisor inicia o daemon e o inicia de novo quando ele sai com a execução ainda ativa, que é a cara de uma queda.

O supervisor não reinicia um daemon depois de um stop, de um pause, ou de uma execução que terminou como idle, error ou completed. Ele desiste depois de mais de 5 reinícios em 5 minutos. Então escreve supervisor.giveup no log e põe o status em error. No Windows, o supervisor também pede ao sistema operacional que não durma enquanto a execução está ativa, para que uma espera pelo reinício de um limite de uso não durma junto.

Uma máquina que entra em suspensão por conta própria congela esses processos em vez de encerrá-los, e a execução continua quando ela acorda. Um desligamento ou um reboot os encerra, e a seção sobre reboots trata do que inicia a execução de novo.

Quando uma execução termina #

Quando o loop retorna, o daemon sai, e não espera por nada que um participante iniciou num turno e deixou rodando, como um servidor de desenvolvimento. O supervisor vê a saída e faz o que uma execução terminada pede: libera o pedido de manter a máquina acordada, fecha o navegador que a execução manteve aberto para as ferramentas de navegador e decide se a máquina pode suspender.

Esse último passo é opcional. Com suspendOnCompletion ligado, o AutoDev põe a máquina para dormir quando a execução acabou ou parou esperando você, se nada mais precisa dela. Vem desligado por padrão, e Suspender a máquina lista as condições.

O que sobrevive #

thread.jsonl, state.json, sessions.json e o resto dos arquivos da máquina ficam em ~/.autodev/<project>-<hash>/, e goal.md, memory.md, participants/ e config.json ficam em .autodev/. Onde o estado fica lista os dois lugares.

Um turno que estava rodando #

Um participante que morre antes de postar não deixa nada na thread, porque um post é a única coisa que chega a ela. O cursor dele não andou, então o próximo turno dele vê os mesmos posts de novo.

Os arquivos que o turno já tinha escrito ficam na árvore de trabalho. Quando o daemon começa de novo, o checkpoint baseline commita as mudanças não commitadas como autodev: baseline before run, a menos que os checkpoints estejam desligados ou a pasta não seja um repositório git. O AutoDev não retoma um turno no meio. Ele começa um novo.

Depois de um reboot #

Nada inicia sozinho depois de um reboot. O AutoDev não se registra para iniciar no boot, então a execução fica parada até que algo a inicie. O state.json ainda diz que a execução está ativa, e o pid dele não pertence a nada, então autodev status e o painel a mostram como parada.

Estas coisas a iniciam de novo:

• autodev sem comando, rodado no projeto. Ele relança uma execução cujo status era running, planning ou waiting, e uma que está rate_limited, que então dorme até o limite reiniciar. Ele não relança uma execução em nenhum outro status. Se um servidor estava rodando desacoplado com autodev serve --daemon, ele o inicia de novo também.
• autodev start, que inicia o daemon qualquer que fosse o status, ou diz que já há um rodando. Um pedido de pausa que sobrou é limpo, já que iniciar é a intenção de continuar. autodev resume sozinho só registra o pedido, e não lança um daemon.
• Uma mensagem enviada pelo painel ou com autodev send, quando nenhum daemon está vivo e a equipe está montada e confirmada nesta máquina. A execução começa para lê-la.
• Approve, num gate que estava esperando. Ele registra a aprovação e inicia a execução.

O painel não relança uma execução quando abre. Para uma execução que parou sozinha, ele diz the run is paused and will not resume on its own — send a message to resume.

Como uma execução morta é percebida #

O AutoDev não confia só no campo de status. Ele confere que o pid do state.json está vivo, e que o processo é um processo do AutoDev deste projeto. Um pid que um reboot entregou a outro programa conta como morto. Uma checagem que não consegue responder conta como viva, para que o AutoDev nunca inicie um segundo daemon sob um vivo.

Quando o pid está morto e o status ainda é um ativo, o AutoDev limpa o pid e mantém o status e a tarefa atual, o que permite relançar a execução de onde estava.

O arquivo de memória #

Toda execução começa com um memory.md. Quando uma execução começa, o AutoDev cria um vazio se não houver nenhum, então uma execução iniciada pelo painel também tem um arquivo para o primeiro participante ler. Cada participante é informado de onde ele está, de que deve lê-lo primeiro quando o contexto dele é compactado, e de que deve escrever nele com as ferramentas remember, revise e forget: decisões e o porquê, restrições, becos sem saída e tudo o que um turno futuro pagaria para reaprender.

É por isso que uma execução sobrevive a um reinício do jeito que importa: uma sessão nova tem a thread e o memory.md, e não precisa da conversa que os produziu. Uma restauração não volta o arquivo, e autodev new-run o copia para a pasta de arquivo da execução antes de esvaziá-lo. autodev memory o imprime. Onde o estado fica descreve o arquivo.

Checkpoints e restauração trata da volta, e A execução parou e por quê trata de ler uma execução parada. Todos os comandos da CLI descreve autodev start e o autodev sem comando.