Seu primeiro objetivo
Monte a equipe, envie uma mensagem e deixe a execução assumir. O que o AutoDev pergunta primeiro, o que ele escreve em .autodev/ e por que fechar o editor não o para.
O tour #
Na primeira vez que o painel abre, um tour de nove passos o percorre: o compositor, a thread, os controles da execução, seus participantes e a lane de um participante, Needs you, o relatório, Memory e o check-in pelo celular. Cada passo aponta para a parte do painel que descreve, e desenha um exemplo ali quando o projeto ainda não tem nada seu para mostrar.
Next, Back e Skip the tour percorrem o tour, e as setas do teclado e o Escape também. Para vê-lo de novo, rode AutoDev: Show the tour na paleta de comandos, ou pressione Show the tour na tela Config.
Monte a equipe #
O AutoDev não tem equipe implícita. Um projeto sem equipe abre na configuração da equipe no painel, e até existir uma equipe o compositor fica desabilitado e diz Set up your team to start. Uma equipe é um arquivo por participante em .autodev/participants/, cada um com um provedor, um modelo e um esforço.
Há três caminhos até uma equipe:
- Arraste uma CLI da fileira de provedores para a grade. Uma CLI basta: é uma conversa que sobrevive a limites e reinícios, e duas ou mais conversam entre si.
- Escolha um modelo:
solo,builder-revieweroumanager-builder-reviewer. O painel mostra uma prévia das instruções de cada participante e deixa você escolher a CLI dele. O formato do arquivo de participante diz o que cada modelo escreve, eautodev team template <name>faz o mesmo pelo terminal. - Comece com a sua equipe padrão, que é copiada para o projeto.
O painel primeiro confere suas CLIs de agente e mostra só o que sabe. Ele diz claude is not installed quando uma CLI está ausente, e claude is installed but not logged in quando sabe que você está deslogado. Requisitos explica os dois.
Montar a equipe também é como você dá ao AutoDev permissão para trabalhar na pasta. Uma equipe que veio com o projeto não roda quando você o abre: os arquivos de participante viram flags e prompts de uma CLI, então o painel diz This project came with a team, e Use this team a confirma nesta máquina.
Envie uma mensagem #
Diga o que você quer construído. Pelo painel, você digita no compositor. Por um terminal, você roda isto:
autodev send "<message>"
A primeira mensagem é o objetivo, e cada uma seguinte conduz a execução. O AutoDev anexa cada mensagem a .autodev/goal.md, a mais nova por último, sob um título com o horário. O arquivo é seu para editar. Uma mensagem não precisa de comando de equipe nem de modo: é um post na thread, e o participante que a lê decide o que ela significa.
Uma mensagem inicia uma execução quando nenhum daemon está vivo e a equipe está pronta: existe uma equipe, e esta máquina a confirmou. Quando uma execução está viva, a mensagem entra na fila para o próximo turno dela, e o compositor diz Drained at the next turn boundary — never mid-turn. Todos os comandos da CLI descreve autodev send, o --image e o --no-start.
O que acontece depois #
Os participantes se revezam na thread compartilhada, e o primeiro a falar lê o objetivo. Toda execução começa com um goal.md e um memory.md, o arquivo onde a equipe guarda o que aprendeu, para que um turno futuro não pague para aprender de novo. A thread compartilhada descreve um turno.
Os arquivos que uma pessoa lê ficam em .autodev/, no seu repositório. O que só a máquina lê fica em ~/.autodev/<project>-<hash>/.
.autodev/ goal.md memory.md config.json participants/
Para começar um objetivo diferente do zero, rode autodev new-run. Ele arquiva a execução terminada e esvazia goal.md e memory.md, e Todos os comandos da CLI diz o que ele mantém.
Ações irreversíveis #
Um participante que está prestes a fazer algo que não dá para desfazer, como um git push, uma publicação, um deploy ou uma mudança no banco de dados, declara antes um gate. Por padrão o AutoDev aprova os gates que lhe são mostrados: a chave de configuração gateMode vale auto. Ponha gated na tela Config e todo gate para a execução até você responder. Ele então espera em Needs you, com Approve e Deny, ou com autodev approve e autodev deny.
O AutoDev não pergunta isso no primeiro uso. Os padrões que sempre aprovam ou sempre negam são gateAutoApprove e gateAutoDeny, e Todas as chaves de configuração trata das três.
Deixe rodando #
O daemon é desacoplado. Fechar o terminal ou o editor não o para. Depois de uma queda um supervisor inicia o daemon de novo, e depois de um reboot nada inicia sozinho até você iniciar. O painel só observa o daemon. O que sobrevive a um reinício diz o que é mantido e o que inicia a execução de novo.
A barra de status do VS Code mantém uma linha, AutoDev: <status>, com · <n> needs you depois dela quando algo espera você. Essa linha continua visível com a aba do AutoDev fechada. Para saber também pelo celular, defina notify.url, e para deixar a máquina dormir quando a execução acabar, ligue suspendOnCompletion. Todas as chaves de configuração trata das duas.
A seguir, Como é uma execução.