Autofix
Um autofix é uma pull request que o Polylane abre para resolver algo que encontrou. O agente investiga primeiro, depois escreve a mudança em uma branch e abre a pull request no GitHub; o merge é seu.
O que faz
Os autofixes começam de três lugares. Você pede um em uma thread, por exemplo "abra uma pull request que corrija isto". Uma execução de correção chega a uma causa confirmada em um repositório conectado e abre a correção na mesma thread. Ou o Polylane propõe um por conta própria, como as melhorias de observabilidade que ele esboça quando um repositório é conectado pela primeira vez.
Como funciona
- Investigar: o agente reúne contexto da topologia, da telemetria e do repositório afetado.
- Branch: ele cria uma branch a partir da branch base do repositório.
- Corrigir: o executor escreve a mudança e envia os commits.
- Pull request: ele abre a pull request descrevendo o que estava errado e o que mudou, vinculada à thread ou issue por trás dela.
- Sua revisão: sua revisão de código normal e sua integração contínua decidem o merge. Fechá-la é um resultado válido, e o Polylane o registra.
Status
| Status | Descrição |
|---|---|
started | A execução está em andamento. |
branch_pushed | Os commits estão na branch e a pull request está prestes a abrir. |
approval_required | O workspace pergunta antes de iniciar correções automáticas, então esta execução aguarda alguém iniciá-la a partir da thread. |
pr_opened | A pull request está aberta e aguarda a sua revisão. |
merged | Você fez o merge da pull request. |
closed | A pull request foi fechada sem merge, por você ou pelo Polylane. |
failed | O executor não conseguiu produzir uma correção. |
no_fix_needed | O agente concluiu que não havia nada a mudar. |
already_in_flight | Outra execução ou uma pull request aberta já cobre a mesma correção. |
quota_exhausted | O workspace não pode iniciar outra execução agora. |
disabled | O autofix está desligado para o workspace. |
plan_rejected | O pedido foi rejeitado antes de uma execução começar. |
unreachable | O Polylane não consegue mais ler o repositório, por exemplo depois que o GitHub App foi removido ou suspenso. |
expired | A execução ficou parada além da sua janela de tempo e foi encerrada. |
Uma execução ignorada pode ser iniciada a partir da sua visão geral com Run anyway, uma expirada ou com falha com Run again, e uma retida com Approve and run. Em Settings > Workspace, o cartão Autofix guarda o interruptor Open autofix pull requests para todo o workspace e Fixes Polylane starts on its own, onde Ask first retém as correções automáticas até que alguém as inicie.
Pull requests deixadas abertas
Uma pull request que o Polylane abre não espera para sempre. Após uma semana sem atividade, a varredura semanal envia um lembrete por e-mail e no Slack e deixa a mesma nota como comentário na pull request; quando ninguém foi solicitado a revisá-la, os donos do código que ela toca são solicitados. Uma pull request que não vê nada por mais uma semana após o lembrete é fechada pelo Polylane com um comentário explicando o motivo, e a branch permanece, então reabri-la traz a mudança de volta como está.
Pull requests abertas enquanto um repositório está sendo conectado ficam fora dos lembretes e fechamentos.
Executores
O executor é o agente de programação que escreve o diff. O executor do próprio Polylane não precisa de configuração; você pode, em vez disso, encaminhar os autofixes por um agente de programação que já usa:
Conecte Devin, Cursor, Factory ou Conductor em Settings > Integrations com a sua própria chave de API, depois ligue Use Devin for all autofixes (ou o interruptor equivalente na página do Cursor, da Factory ou do Conductor) para torná-lo o executor de todo autofix no workspace. Se essa integração for removida ou desabilitada, os autofixes voltam para o executor do Polylane.
Onde encontrar
Leia um autofix na thread que o produziu. A Lineage na barra lateral da thread mostra o Autofix e sua Pull request, e o nó do autofix abre as abas Overview, Diff, Session, Timeline e Properties. Approve and run, Run again e o motivo do fechamento ficam na sua visão geral.
Relacionado
- Execuções de correção para as execuções que entregam uma causa confirmada ao autofix.
- Revisões de pull requests para a verificação que toda pull request recebe antes do merge.
- Repositórios para conectar o código no qual os autofixes escrevem.
- GitHub para a conexão com o provedor de código pela qual os autofixes escrevem.
Escalations
A lista única do que os agentes precisam de você: um registro por pedido, por mais que ele se repita, encerrado quando você o trata.
Trabalhe a partir das suas ferramentas
Pergunte sobre a produção a partir do seu agente de programação, terminal ou CI: um servidor MCP, uma CLI e um plugin que instala os dois.