Devin Review

​

Recursos

​

Introdução

• aplicativo web do Devin — Acesse app.devin.ai/review para ver seus PRs em aberto organizados por categoria (atribuídos a você, criados por você, revisão solicitada). Quando o Devin criar PRs, você verá um botão laranja “Review” no chat.
• Comentário no PR — Comente /devin review em qualquer PR do GitHub em um repositório que sua organização conectou, e o Devin fará a revisão na hora. Veja Acionando uma revisão por meio de um comentário no PR.
• Atalho de URL — Para qualquer link de PR do GitHub.com, substitua github.com por devinreview.com na URL. Para PRs privados, faça login no Devin primeiro.
• GitHub Enterprise — Cole a URL completa do PR na página Devin Review em app.devin.ai/review. Todas as ofertas do GitHub (GitHub.com, Enterprise Server, Enterprise Cloud) têm os mesmos recursos.
• Azure DevOps — Cole a URL completa do PR (por exemplo, https://dev.azure.com/.../pullrequest/..., ou o host do seu Azure DevOps Server) em app.devin.ai/review após conectar o repositório ao Devin.

​

Provedores Git compatíveis

​

Como ler uma revisão

​

Permissões

​

Governança

​

Controle de custos

​

Painel de consumo

• Detalhamento por usuário — Veja quantos ACUs de Review cada usuário consumiu no ciclo de cobrança atual e no anterior.
• Detalhamento por repositório — Veja o consumo de ACU de Review, o número de revisões e a quantidade de bugs detectados por repositório no ciclo de cobrança atual e no anterior, ajudando a identificar quais repositórios geram o maior custo de revisão e onde as revisões detectam mais problemas.

​

Indicador de tamanho da revisão

​

Limite de gastos com revisão automática por PR

• As revisões manuais continuam funcionando — o limite apenas pausa as revisões automáticas. Você sempre pode acionar uma revisão manualmente na página de revisão do PR.
• Reativar por PR — Reativar a revisão automática para o PR pelo menu de ações (três pontos no cabeçalho) retoma as revisões automáticas e isenta esse PR do limite.

​

Ação do fluxo de trabalho de PR

• Merge — Faz o merge da PR usando a estratégia de merge configurada do repositório (merge commit, squash ou rebase). O botão de merge reflete o status atual de mesclagem da PR e as verificações obrigatórias.
• Close — Fecha a PR sem mesclá-la. Disponível no menu suspenso ao lado do botão de merge.
• Convert to draft — Converte uma PR aberta para o status de rascunho. Disponível no menu suspenso quando a PR está aberta e ainda não está como rascunho.
• Mark ready for review — Marca uma PR em rascunho como pronta para revisão. Um botão “Ready for review” aparece na barra de merge para PRs em rascunho.
• Auto-merge — Ativa ou desativa o auto-merge do GitHub no menu suspenso do botão de merge. Quando ativado, a PR será mesclada automaticamente assim que todas as verificações obrigatórias forem concluídas com sucesso. A barra de merge mostra o status atual do auto-merge, incluindo quem o ativou.

​

PRs empilhadas

• Painel da pilha — O cabeçalho da PR mostra a pilha com todos os membros ordenados de baixo para cima, até a branch base na qual será feito o merge. Cada membro tem um link para sua própria página de Review, permitindo analisar a pilha camada por camada.
• Prontidão por camada — Cada membro exibe um indicador de status que reflete sua real capacidade de merge: verde quando pode ser mesclado de fato (considerando CI, revisões obrigatórias e proteção de branch), vermelho quando há verificações com falha ou conflitos e laranja para qualquer outra situação que bloqueie o merge — inclusive quando uma camada está pronta individualmente, mas é bloqueada por uma PR não mesclável abaixo dela. Um indicador agregado resume toda a pilha.
• Diffs focados — Cada PR em uma pilha é comparada à camada abaixo, para que cada revisão — incluindo a revisão automática e o Bug Catcher — veja apenas as alterações daquela camada.
• Merge da pilha — PRs empilhadas são mescladas pelo merge atômico de pilhas do GitHub: ao fazer merge de uma PR, todas as PRs abertas abaixo dela na pilha também são mescladas, de baixo para cima, em uma única operação. O botão de merge mostra exatamente quantas PRs serão incluídas na ação, e o GitHub redireciona as PRs restantes para a branch base depois.

​

Revisão automática

​

Quando a Revisão automática é executada?

• Uma PR é aberta (não é rascunho)
• Novos commits são enviados (push) para uma PR
• Uma PR em rascunho é marcada como pronta para revisão

​

Modos de acionamento

• Revisão automática (padrão) — As revisões são acionadas em todos os eventos: PR aberta, novos commits enviados e rascunho marcado como pronto.
• Na criação da PR — As revisões só são acionadas quando uma PR é aberta pela primeira vez ou quando uma PR em rascunho é marcada como pronta para revisão. Envios posteriores para a PR não acionam uma nova revisão.
• Manual — Nenhuma revisão é executada automaticamente. Você mesmo aciona uma revisão na página de Review da PR sempre que quiser. Este é o nível base para adesão pessoal.

​

Autoinscrição (Todos os usuários)

1. Acesse Configurações > Preferências
2. Em Devin Review, defina seu Review trigger como Na criação da PR ou Revisão automática (deixe em Manual se quiser apenas acionar revisões por conta própria)

​

Idioma dos comentários de revisão

• Usar o idioma de exibição (padrão) — Os comentários de revisão seguem a configuração do seu idioma de exibição.
• Idioma específico — Escolha entre inglês, espanhol, português, japonês, chinês, coreano, francês, alemão, russo, árabe, hebraico ou indonésio.

​

Configuração de administrador

• Repositories — Adicione repositórios para revisar automaticamente TODOS os PRs nesse repositório. Use o botão Adicionar repo para pesquisar e selecionar entre os repositórios conectados e defina, na lista, o modo de acionamento de cada repositório.
• Users — Visualize todos os usuários inscritos na organização, junto com o modo de acionamento de cada um. Os usuários se inscrevem por meio da autoinscrição; os administradores não podem inscrever outros usuários diretamente.
• Add “Devin Review” link in PR description — Quando ativado (padrão), Devin adiciona um link para a revisão na descrição do PR.

​

Publicação no GitHub

• Post GitHub CI checks — Quando ativado (padrão), Devin cria uma verificação de status de commit no PR para cada revisão. Isso permite que você veja os resultados da revisão diretamente na lista de verificações do seu PR.
• Bugs — Publique bugs (erros prováveis ou comportamento incorreto) como comentários no PR.
• Security — Publique vulnerabilidades de segurança e sugestões de hardening como comentários no PR.
• Flags (investigate) — Publique flags de investigação (problemas potenciais que merecem uma análise mais detalhada) como comentários no PR.
• Flags (note) — Publique flags informativas (observações que talvez não exijam ação) como comentários no PR.

​

Bug Catcher

​

Bugs

• Grave — Problemas com alta confiança que exigem atenção imediata
• Não grave — Problemas de menor gravidade que ainda devem ser revisados

​

Flags

• Investigar — O Bug Catcher identificou algo que merece sua atenção. Você deve revisar o código sinalizado por conta própria e verificar se há de fato um bug ou problema.
• Informativo — O Bug Catcher concluiu que o código está correto ou está explicando como algo funciona. Isso ajuda você a entender as mudanças de código sem exigir ação da sua parte.

​

Security

• Injeção (SQL, XSS, injeção de comando, template)
• Falhas de autenticação e autorização (controle de acesso ausente ou quebrado, escalonamento de privilégio, bypass de autenticação)
• Exposição de segredos (chaves embutidas no código, tokens em logs, credenciais no código-fonte)
• SSRF e path traversal
• Desserialização insegura, prototype pollution
• Ausência de validação de entrada para dados não confiáveis
• Criptografia fraca (algoritmos, gerenciamento de chaves)
• Segurança de transporte e cookies (ausência de exigência de HTTPS, CORS permissivo, flags de cookie inseguras)
• Configurações padrão inseguras ou configurações incorretas introduzidas pela PR

• Crítico — Vulnerabilidades com alta confiança que devem ser corrigidas antes da mesclagem
• Aviso — Possíveis fragilidades de segurança que valem a pena investigar

​

Resolvendo resultados

​

Ações de revisão

​

Acionando uma revisão por meio de um comentário no PR

• Comente exatamente /devin review no início do comentário. O comando não diferencia maiúsculas de minúsculas e funciona tanto em comentários na conversa da PR quanto em comentários de revisão inline.
• É necessário ter acesso de escrita — quem comenta precisa ter a permissão write ou admin no repositório, e a conta do GitHub deve estar vinculada à conta do Devin. Colaboradores externos não podem acionar revisões.
• Somente PRs abertas — comentários em PRs fechadas ou mescladas são ignorados.
• Somente GitHub — incluindo GitHub Enterprise Server e Enterprise Cloud. O GitLab oferece suporte à revisão automática, mas não ao acionamento por comentário.

​

Iniciando uma revisão

​

Resolvendo comentários

​

Indicadores de proprietário de código

​

Correção Automática

​

Como ativar

1. Pela barra lateral de revisão — Em qualquer PR criada pelo Devin, a barra lateral Analysis mostra uma seção Auto-fix com um botão Enable auto-fix. Clicar nele ativa o Auto-Fix para todas as PRs do Devin na sua organização. Isso requer permissões de administrador da organização.
2. Pelas configurações globais do Devin — Vá em Settings > Devin > Pull requests > Responding to bots e então:
   • Defina o modo como Selected only e adicione devin-ai-integration[bot] à lista de permissões (allowlist), ou
   • Defina o modo como All bots.

​

Resultados nos PRs do próprio Devin

1. O PR exibe o status Devin is addressing Devin Review findings.
2. Com Auto-fix review findings ativado, a sessão corrige o que for possível. Com a opção desativada, a sessão apenas é notificada e retorna um relatório.
3. Somente os resultados que o Devin não conseguiu corrigir são publicados como comentários de revisão, e o status lista o que foi corrigido.

​

Permissões e Restrições

• Apenas administradores da organização podem alterar essa configuração.
• Se o modo do bot estiver definido como Todos os bots, o Auto-Fix aparecerá ativado, mas não poderá ser alterado na barra lateral de revisão. Use as configurações de Customization para modificar o modo do bot.
• Os comentários de resumo No Issues Found do Devin Review são sempre ignorados. Apenas comentários que apontam problemas de fato disparam o Auto-Fix.

​

Atribuição de Commits e Comentários

• Bugs encontrados, sinalizações e anotações automatizadas sempre aparecem como o Devin bot.
• Quando um usuário escreve um comentário ou análise por meio do Devin Review, ele aparece usando a identidade do GitHub desse usuário.
• Quando um usuário pede para o agente de chat fazer uma alteração de código, o commit resultante é feito como o Devin bot.
• GitHub Suggested Changes segue o comportamento padrão do GitHub: qualquer revisor (incluindo Devin) pode deixar uma edição sugerida em um comentário de análise. Quando um usuário clica em “Apply suggestion”, o commit é atribuído àquele usuário, da mesma forma que no GitHub.
• Devin nunca criará commits ou comentários em nome de um usuário sem que o próprio usuário inicie explicitamente a ação.

​

AGENTS.md / Arquivos de instruções

• **/REVIEW.md
• **/AGENTS.md
• **/CLAUDE.md (sem diferenciar maiúsculas de minúsculas)
• **/CONTRIBUTING.md (sem diferenciar maiúsculas de minúsculas)
• .cursorrules
• .windsurfrules
• .cursor/rules
• *.rules
• *.mdc
• .coderabbit.yaml / .coderabbit.yml
• greptile.json

​

Regras de revisão personalizadas

1. Vá para Settings > Review
2. Em Review Rules, digite um padrão glob de arquivo (por exemplo, docs/**/*.md)
3. Clique em Add

​

REVIEW.md

• Áreas da base de código que precisam de atenção extra
• Armadilhas comuns ou antipadrões a serem observados
• Convenções específicas do projeto que os revisores devem aplicar
• Arquivos ou diretórios que podem ser ignorados com segurança durante a revisão
• Considerações de segurança ou desempenho exclusivas do seu projeto

# Review Guidelines

## Critical Areas
- All changes to `src/auth/` must be reviewed for security implications.
- Database migration files should be checked for backward compatibility.

## Conventions
- API endpoints must include input validation and proper error handling.
- All public functions require TypeScript return types — do not use `any`.
- React components should use functional components with hooks, not class components.

## Ignore
- Auto-generated files in `src/generated/` do not need review.
- Lock files (package-lock.json, yarn.lock) can be skipped unless dependencies changed.

## Performance
- Flag any database queries inside loops.
- Watch for N+1 query patterns in API resolvers.