Todas as chaves de configuração

As 25 configurações que o AutoDev lê de config.json, no projeto e na máquina, com o padrão de cada uma, sua variável de ambiente quando tem uma e o que ela faz.

Como um valor é escolhido #

As configurações persistem em um config.json, que autodev config set <key> <value> grava e autodev config unset <key> edita. Em qual dos dois arquivos cada chave fica está mais abaixo. O arquivo do projeto fica no seu repositório, então uma configuração viaja com o projeto e é revisada em um pull request.

Uma variável de ambiente vence o arquivo quando está definida. Um valor que não serve à chave, como um número negativo ou um provedor que não existe, é ignorado no ambiente, e o valor do arquivo prevalece. Um config.json que não pode ser lido, ou que falha na validação, é lido como uma configuração vazia. Só as chaves planas têm variável de ambiente: as chaves aninhadas, notify e capability, são lidas apenas do arquivo.

Os números devem ser positivos. Os booleanos aceitam true, false, 1, 0, on ou off em autodev config set, e o ambiente aceita também yes e no. Uma chave sem padrão não tem nada definido até você defini-la.

autodev config set maxSpendUsd 25
autodev config set notify.url https://ntfy.sh/<topic>
autodev config unset maxSpendUsd

O projeto e a máquina #

Dois arquivos guardam configurações.

autodev config set grava cada chave no arquivo dela, e autodev config mostra o valor em vigor e de onde ele vem.

suspendOnCompletion é da máquina porque suspender interrompe todas as execuções da máquina. Com dois projetos trabalhando ao mesmo tempo, uma configuração por projeto os deixaria discordar sobre se a máquina pode dormir, e o primeiro a terminar poria o outro para dormir no meio do trabalho.

notify é da máquina por dois motivos. O celular que ele alcança é seu, não do projeto, então um clone ou um worktree novo não notificaria ninguém. E o tópico em notify.url funciona como uma senha, que não deve ficar num arquivo que viaja com um repositório.

Um valor que um AutoDev mais antigo gravou para uma dessas chaves no config.json de um projeto ainda é lido quando a máquina não tem um valor próprio, e autodev config unset limpa os dois, para que ele não volte.

Execução #

Cada participante responde pelo seu próprio provider, modelo e esforço, no arquivo dele: autodev team pin define o modelo e o esforço, e o provider é aquele com que o participante foi adicionado. As três chaves acima, no nível da execução, são o que sobrou do tempo em que um projeto tinha um único agente. A tela Config do painel as deixa de fora, e autodev config ainda as lista.

model e effort são strings livres. Não há uma lista fixa, de propósito: os aliases de modelo mudam, e uma lista mantida pelo AutoDev estaria errada na manhã em que um modelo novo sair. No arquivo de um participante, os valores sugeridos para effort são low, medium, high, xhigh e max.

autocompact é uma string livre, como model e effort: o AutoDev não a verifica, e o claude recusa um valor que não aceita.

As três chaves Args são divididas por espaço em branco, então um argumento que contém um espaço não pode ser escrito nelas.

Limites de segurança #

Estas configurações pausam o loop com limpeza quando são atingidas.

O teto de gasto é flexível. O AutoDev o verifica entre as tarefas, então uma execução pode ultrapassá-lo em cerca de o custo de uma tarefa antes de pausar.

maxAcceptChecks conta a auditoria. Quando um participante diz que o objetivo foi cumprido, uma auditoria independente lê a afirmação contra o objetivo, e uma lacuna que ela encontra volta para o time como um post. A execução pausa quando a auditoria encontrou lacunas mais vezes do que essa chave permite, e uma mensagem sua a retoma.

Quando uma execução espera ou desiste #

Uma execução pode esperar por três motivos, e cada um tem seu limite.

• Um limite de uso. O engine de um participante, que é um provedor com seu modelo e seu esforço, informa um limite. O turno passa para o próximo engine da cadeia failover do participante. Quando todos os engines estão limitados, a execução espera pelo primeiro que voltar. Nenhuma chave limita essa espera, porque ela termina sozinha, e ela não conta como iteração nem como tempo de execução.
• Uma espera que um participante pediu. Um participante que precisa segurar, por exemplo enquanto outra sessão termina, posta um wait. A execução verifica de novo em intervalos crescentes, e maxWaitMin e waitRecheckMaxMin a limitam. Quando maxWaitMin se esgota, a execução pausa, e uma mensagem sua ou autodev start a continua.
• Uma falha de infraestrutura. A CLI caiu ou passou do tempo, ou informou um limite antes de o AutoDev conseguir ler a hora em que ele volta. A primeira nova tentativa é imediata. As seguintes esperam 1, 2, 4, 8, 15 e 30 minutos, e depois uma hora cada. Depois da décima segunda falha seguida a execução desiste, tendo esperado cerca de cinco horas, e pausa. Ela nunca espera além do momento em que um engine limitado volta, porque a tentativa seguinte já vai para ele. autodev start tenta de novo. Nenhuma chave muda esse cronograma.

Dois limites fixos param uma execução que não vai a lugar nenhum, e também não têm chave: 5 passos seguidos que falham do lado do AutoDev pausam a execução como erro, e 10 iterações seguidas sem trabalho verificado a pausam como travada.

Gates #

Um gate pendente espera por autodev approve ou autodev deny.

Checkpoints #

Uso do computador #

As chaves do bloco capability.computerUse deixam os participantes ver e operar páginas da web, em um navegador que o AutoDev mantém durante a execução. Ficam no arquivo do projeto e não têm variável de ambiente.

Com o perfil padrão, você faz login em um site uma vez e todas as execuções seguintes têm esse login: autodev browser login <url> abre a página, e o painel tem a mesma ação. autodev browser login traz os detalhes.

autodev config set capability.computerUse.enabled true
autodev config set capability.computerUse.headless false

Notificações #

As chaves do bloco notify mandam uma mensagem ao seu celular quando uma execução termina, para sozinha ou precisa de você. Ficam no arquivo da máquina e não têm variável de ambiente.

A mensagem é enviada uma vez para cada coisa que precisa de você, em qualquer projeto da máquina, e é de um destes três tipos:

O título é AutoDev · <project>. Uma execução que você mesmo para ou pausa não envia nada. O POST tem um tempo limite de 5 segundos e é tentado mais uma vez se falhar, e o log registra notify.sent, notify.failed ou notify.off, nunca o endereço. O editor aplica a mesma regra à sua própria notificação, então um evento que um dos dois anunciou não é anunciado de novo pelo outro.

autodev config set notify.url https://ntfy.sh/<topic>
autodev config set notify.format json

Suspender a máquina #

Com suspendOnCompletion ligada, o AutoDev põe a máquina para dormir quando uma execução não precisa mais dela, para que a execução de uma noite não deixe a máquina acordada até de manhã. Vem desligada, só age no Windows, e dorme em vez de hibernar.

Ele só suspende quando todas estas condições valem:

• A execução terminou porque foi concluída, sem gate nem proposta pendente, ou porque parou e espera por você: pausada pelo sistema, parada em um gate ou em uma proposta, perguntando algo a você, ou com erro.
• Você não parou nem pausou a execução por conta própria.
• Nenhum outro projeto da máquina tem uma execução ativa, porque suspender interrompe todas.
• Nenhum celular pode responder pelo servidor. Um servidor em execução com um celular pareado ou pareando impede a suspensão, e um servidor que não sabe dizer também. Um servidor sem celular não impede.
• A máquina ficou ociosa por 20 minutos, ou seja, sem teclado nem mouse.

Quando elas valem, o AutoDev mostra na tela uma mensagem dizendo que a máquina vai suspender, espera 60 segundos e verifica todas as condições de novo. Encostar no mouse ou no teclado nesse minuto cancela. O log registra o motivo de cada recusa.

Um exemplo #

{
  "suspendOnCompletion": true,
  "notify": { "url": "https://ntfy.sh/<topic>", "format": "ntfy" }
}

{
  "maxIterations": 500,
  "maxSpendUsd": 25,
  "gateMode": "gated",
  "checkpoints": true,
  "capability": { "computerUse": { "enabled": true, "headless": false } }
}