Reviews e QA
Como uma mudança é conferida antes e depois de subir
Em trabalhos com repositórios, um agente pode entregar um pull request e um preview configurado. Esta página descreve esse fluxo de revisão de código e entrega. Tarefas de pesquisa ou com ferramentas de negócio podem produzir outros resultados revisáveis.
A passagem automatizada
Um revisor roda uma passagem sobre a mudança. Ele aprova, ou pede alterações e passa o card para uma pessoa. Ele deliberadamente não fica em loop — um agente discutindo com um revisor queima orçamento sem convergir.
Isso substituiu uma divisão anterior entre uma passagem de QA e uma de revisão de código. Uma passagem com uma entrega clara funcionou melhor que duas que discordavam.
O preview
Quando o projeto fornece deployments de preview, um pull request sobe um preview — a mudança rodando, numa URL que você abre e compartilha. O card lista exatamente as páginas que mudaram, então você não fica adivinhando o que conferir.
Revise o preview antes do diff. O preview é o resultado; o diff é o método.
Validação pós-deploy
Subir não é o fim da task. A coluna de post-deploy validation deixa o último passo explícito: alguém confirma que a mudança fez o que deveria, em produção.
As faixas de entrega — approved, merged, post-deploy validation — estão atrás de uma flag de organização. Sem ela, o board termina em in review e a validação volta a ser informal.
O que ainda precisa de gente
Correção automática não é merge automático. O auto-merge fica desligado por padrão, e a correção automatizada tem uma taxa de erro real, então a maior parte das mudanças espera uma pessoa aprovar. Isso é uma escolha, não uma funcionalidade faltando: o custo de um merge errado numa loja no ar é muito maior que o custo de um clique.
À medida que o histórico do revisor no seu repositório se acumula, vale revisitar esse equilíbrio com o time.