Participantes e lanes

Um participante é um arquivo no seu repositório. Uma lane é o cartão dele no painel. Como uma equipe é montada, o que cada um guarda, e o que o painel deixa você fazer com eles.

Um participante é um arquivo #

Um participante é .autodev/participants/<id>.md: frontmatter e, depois, as instruções do próprio participante em prosa. O nome do arquivo é a identidade. Um id no frontmatter que discorde dele é ignorado.

.autodev/participants/<id>.md

---
provider: codex
failover: [claude]
moves: [say, work_done, handoff, wait, gate, done]
---
Your instructions to this participant.

Campo	O que guarda
`provider`	A CLI de agente em que ele roda: `claude`, `codex` ou `antigravity`. Quando está ausente, vale o `provider` da execução.
`model`	Um nome de modelo, como string livre. Ausente significa o padrão da própria CLI.
`effort`	Um nível de esforço, como string livre. Ausente significa o padrão da própria CLI.
`failover`	Onde ele roda quando o provedor dele atinge um limite: entradas `provider[:model]`, em ordem.
`moves`	As jogadas que ele pode fazer. O padrão são as seis.
`persona`	Um caminho para um arquivo cujo corpo substitui o corpo deste arquivo.

model e effort nunca são conferidos contra uma lista. O AutoDev não mantém lista de modelos, então um modelo lançado esta manhã funciona esta manhã.

Os commits do próprio AutoDev deixam .autodev/ de fora, então um arquivo de participante só é versionado se você o commitar. Essa escolha é sua.

Montar uma equipe #

Não existe equipe implícita. Um projeto sem arquivos de participante não roda nada, e o painel abre na configuração da equipe. Três caminhos levam a uma equipe, e todos escrevem arquivos de participante:

Arraste um provedor da fileira de providers para a grade. Isso adiciona um participante, com o nome do provedor.
Comece por um modelo: solo é um participante que cuida do objetivo, builder-reviewer acrescenta um revisor que confere cada mudança antes de a execução seguir, e manager-builder-reviewer acrescenta um gestor que divide o objetivo e entrega os blocos. O formato do arquivo de participante descreve o que cada modelo escreve.
Comece com a sua equipe padrão, que é copiada para o projeto. A equipe que você monta é guardada como padrão quando ainda não há uma, e Save as default team a substitui por esta. Ela mora em ~/.autodev/team/, então é montada uma vez e não por pasta.

Uma equipe que veio com o projeto não roda até você confirmá-la nesta máquina. Os arquivos dela viram flags e instruções de uma CLI, e um arquivo pode nomear qualquer coisa. O painel diz This project came with a team, e Use this team a confirma. autodev team faz tudo isso pelo terminal.

Fixado ou padrão #

Um participante sem model e sem effort é não fixado: o AutoDev não passa nenhuma flag de modelo nem de esforço, e vale o padrão da própria CLI. Fixar e desafixar ficam na lane, e escrevem essas mesmas duas chaves no arquivo. Uma fixação vale a partir do próximo turno do participante, nunca no meio de um. Ela nomeia um modelo do provedor do próprio participante, então num salto de failover ela não se aplica. O model e o effort da execução não são um plano B: nenhum turno de participante os lê.

Quem fala primeiro #

A equipe é ordenada por nome. Quando ninguém passa o turno adiante, os turnos seguem essa ordem, e o primeiro nome abre uma thread. Cada lane traz a sua posição como um número, e o painel explica a ordem sob a grade: They take turns in this order — <names> — because a team is sorted by name, and <first> opens a thread when nobody hands the turn on. Rename to reorder.

Adicionar um participante pelo painel escreve um arquivo com o nome do provedor, depois claude-2, claude-3 e assim por diante. Renomear muda a ordem, e move o arquivo com a fixação e as instruções, e a sessão junto. A thread mantém o nome antigo nos posts já escritos: um post registra quem falou.

Uma lane é um cartão #

O destino CLIs mostra um cartão por participante. Um cartão é a lane daquele participante. Ele mostra:

o nome e o provedor;
o número da posição dele na ordem;
o estado: its turn, idle, open in an editor tab ou not installed;
quando ele está rodando em outra CLI, uma linha que diz por quê, como Running on codex: claude hit its usage limit and is back at <time>.;
um rodapé: default, default · <model it last ran> ou default · model not reported by codex, ou pinned · <model> · effort <effort>;
as três últimas coisas que ele disse ou executou.

As ações são Open ou Focus tab, fixar ou desafixar, renomear, Edit prompt, que abre o arquivo do participante no editor, e Remove. Renomear e Remove são recusados enquanto o participante está num turno, e o cartão diz <id> is taking a turn — wait for it to finish, or stop the run first. Uma lane cujo provedor está ausente diz <provider> is not available on this machine. e oferece Adopt a binary… e Copy install. O terminal faz o mesmo: autodev team edit imprime o caminho do arquivo, e pin, unpin, rename e remove fazem o que os botões fazem.

O que o Open faz #

O Open abre um terminal numa aba do editor chamada AutoDev · <id>, rodando a CLI do participante de forma interativa. A linha de comando leva a fixação do participante e o servidor MCP do próprio AutoDev, somado ao seu e nunca no lugar dele. É onde você faz login numa CLI ou escolhe um modelo. Não é onde um turno da thread roda: os turnos rodam sem interface, a partir do daemon.

O Open não envia nada à execução. A execução não pausa, e um turno em andamento continua escrevendo no repositório enquanto você digita no terminal. O painel não tem nenhum controle que tire da thread a sessão de uma lane, nem que a bifurque.

O formato do arquivo de participante traz o formato exato do arquivo. A thread compartilhada trata do que um participante faz num turno, e Provedores e failover trata do failover. Todas as chaves de configuração lista o provider da execução, em que roda um participante que não nomeia nenhum.