Coroid finaliza criando uma pull request em um ramo próprio, baseada no seu ramo principal. Ele nunca faz merge por conta própria. O merge é sempre uma decisão humana, tomada no seu provedor ou com Aprovar e mesclar em Coroid. Veja Mesclagem.
O que vem junto com isso
- a alteração de código
- os testes escritos ou atualizados juntamente com ela
- o resultado da execução do seu conjunto de testes existente
- o resultado de quaisquer portas de qualidade configuradas pela sua organização
- uma revisão do diff, com descobertas já corrigidas ou listadas
O objetivo não é substituir sua revisão. É garantir que sua revisão não seja a primeira.
main- A alteração no código4 arquivos
- Testes escritos ou atualizados2 arquivos
- Sua suíte de testes existenteAprovado
- Portas de qualidade1 item de aviso encontrado
- Aprovação da revisão2 corrigidos, 1 listado
O que verificar de fato
Os aspectos mecânicos já foram verificados. Concentre sua atenção nas coisas que só você pode avaliar:
- Ele resolve o problema certo? Compare-o com os critérios de aceitação da especificação, não com sua memória do que solicitou.
- Ele se encaixa na base de código? Convenções, nomenclatura, estrutura da abstração. Coroid analisa seu código para deduzir esses aspectos e acerta na maioria das vezes — mas nem sempre.
- O que ele modifica que você não esperava? Veja a lista de arquivos antes do diff.
- Os novos testes são significativos? Um teste aprovado que não verifica nada é pior do que nenhum teste.
Enviando trabalho de volta
Você tem três opções, em ordem crescente de custo:
- Comentar e solicitar retrabalho — a tarefa volta para o agente desenvolvedor com suas observações, mantendo seu contexto. Ideal para casos de "está correto, mas incompleto".
- Rejeitar o plano e reiniciar — quando a abordagem está errada, não a execução.
- Cancelar a tarefa — quando o trabalho não deve ser feito. O cancelamento interrompe a execução e libera a vaga do agente.
Seja específico nos comentários de retrabalho, da mesma forma que faria com um colega. "Isso não lida com o caso de valor vazio em parseRange"produz uma correção; "precisa de melhorias" gera uma
suposição.
Mesclagem
Coroid nunca faz a mesclagem por conta própria. Não existe configuração que faça com que ele mescle ao finalizar uma tarefa. A mesclagem ocorre de duas maneiras, e ambas começam com uma pessoa decidindo pela mesclagem.
Isso vale para trabalhos iniciados sob um mandato também. Coroid registra o que decidiria sobre cada mesclagem para avaliar seu próprio julgamento, mas nunca age com base nesse registro. Veja O que Coroid decide e o que fica sob seu controle.
No GitHub ou GitLab
Mescle o pull request no seu provedor, usando sua proteção de ramificação padrão, verificações obrigatórias e regras de aprovação. O pull request é comum — isso é intencional — para passar pelas revisões e CI nos quais você já confia.
Do Coroid, com Aprovar e mesclar
As telas de revisão no Coroid têm um Aprovar e mesclar botão. Ele pede sua confirmação e, em seguida, Coroid mescla o pull request para você por meio de GitHub ou GitLab, usando a conexão do repositório do projeto. É a mesma mesclagem que ocorre ao pressionar o botão de mesclagem no seu provedor, portanto suas regras de proteção de ramificação, verificações obrigatórias e aprovação são aplicadas. Se elas bloquearem a mesclagem, Coroid exibirá o motivo fornecido pelo provedor e nada será mesclado.
O que acontece antes da mesclagem depende do que você está aprovando:
- Uma tarefa. A tarefa precisa de um pull request primeiro. Se ainda não houver um, a tela de revisão oferecerá Criar PR antes de Aprovar e mesclar. Ao aprovar, Coroid envia a ramificação da tarefa para que o pull request tenha os commits revisados mais recentes e, então, mescle o pull request. Aprovar uma tarefa requer acesso de gravação ao projeto dela.
- Um plano. As tarefas pertencentes a um plano não podem ser mescladas uma por uma. O único pull request do plano é aprovado na revisão de promoção. Primeiro, Coroid verifica se a ramificação base não mudou desde o início do plano (veja Quando a ramificação base é alterada), as verificações de qualidade obrigatórias sejam aprovadas, o pull request não tenha conflitos de mesclagem e nenhuma barreira de etapa esteja bloqueando. Então, ele mescla o pull request. Aprovar um plano requer acesso de gravação ao projeto dele.
- Mesclagem forçada. A revisão de promoção de um plano também oferece Mesclagem forçada. Ela salta as verificações de ramificação base, conflito de mesclagem e barreira de etapa feitas pelo Coroid, mas não as verificações de qualidade obrigatórias ou as regras do seu provedor. Precisa de um motivo escrito, que é registrado junto à promoção, e de acesso de administrador ao projeto.
O Assistente de chat e Clientes MCP também podem aprovar ou fazer merge forçado de um pull request. Eles agem em seu nome, portanto as mesmas verificações e regras de acesso ao projeto se aplicam. O assistente sempre pede sua confirmação antes. Um merge forçado feito por um cliente MCP sempre fica aguardando em Aprovações para uma pessoa. Se uma aprovação de um cliente MCP fica aguardando lá depende das suas políticas de automação. Nenhum deles pode fazer merge de uma única tarefa.
Prepare o que será lançado
Depois do merge, abra a aba Lançamentos do seu projeto e selecione Nova versão. Escolha o commit mesclado que deseja lançar; o Coroid lista os pull requests que ele contém. A página de versão então guia cada ambiente por quatro etapas: verificações, aprovação, implantação e integridade. Seu repositório e CI/CD ainda são responsáveis pela implantação. O Coroid marca uma versão como implantada somente quando seu pipeline confirma isso ou quando um Proprietário ou Administrador registra uma implantação externa verificada.
Próximo
Lançamentos — prepare o commit mesclado e acompanhe-o por cada ambiente. Para onde ir a seguir lista os outros fluxos de trabalho.