Revisor de Pull Request

Para que serve

Revisar automaticamente toda Pull Request de um repositório do GitHub: comentar o que muda, o que pode estar errado — segurança, qualidade, comportamento — e o resultado de um conjunto de ferramentas de análise automática. Do seu lado não há nada para manter: sem arquivo de configuração dentro do repositório, sem segredo para guardar, sem rotina de integração contínua para atualizar.

Como ligar

1. Autorizar a plataforma na sua conta ou organização do GitHub — a mesma autorização que serve o resto do produto, descrita em Integração com o GitHub.
2. Em Ferramentas de Desenvolvimento → Revisor de PR, escolher a conta do GitHub entre as que você autorizou e ligar o revisor no repositório desejado.
3. Abrir uma Pull Request.

O que aparece na Pull Request

O primeiro comentário chega segundos depois da abertura; a revisão em si, minutos depois.

1. Um comentário fixo, criado logo no disparo, com a ficha da rodada — o que está sendo revisado, quantos arquivos, e como pausar. Minutos depois ele é editado com o corpo da leitura: o resumo do que muda, as áreas do projeto que a PR toca, uma estimativa de esforço de revisão e um diagrama de sequência do que passou a acontecer no código.
2. A revisão, com os achados críticos, graves e leves comentados na própria linha alterada. Achado que não está no trecho alterado, e observação pequena, ficam agrupados à parte — nunca em linha, para não poluir o diff com comentário sobre código que a PR não tocou.
3. O comentário fixo, editado de novo: o topo passa a trazer o veredito — "Dá para mesclar", "Vale olhar antes de mesclar", "Tem algo crítico aqui" — com link para cada achado. Ele também ganha "O que apontei": uma lista com todos os achados desta e das rodadas anteriores, e o estado de cada um (novo nesta rodada, aberto desde a rodada N, fechado na rodada N, comentado fora da linha alterada) — em vez de a rodada mais recente apagar o histórico das anteriores.
4. A cada push novo na mesma PR, uma rodada nova: respostas em thread confirmando o que o push já corrigiu, e o registro dos achados que alguém contestou e o revisor aceitou retirar.

O comentário fixo conta a PR inteira, não a última rodada — e desde 08/09/2026 cada parte dele tem uma regra declarada. São quatro comportamentos, e nenhuma parte fica de fora:

As duas primeiras linhas crescem de maneiras diferentes: na primeira, o push acrescenta ao que aquela parte descreve — a PR que tocava só cobrança e passa a tocar autenticação ganha a área nova na lista, sem perder a antiga. Na segunda, o que cresce é a própria lista de achados, e nada sai dela.

A estimativa é o caso à parte, e vale saber o preço: numa PR que cresceu muito desde que abriu, o número mostrado é o do tamanho inicial. Pedir uma revisão completa é o que o atualiza.

O que mudou em 08/09/2026 foi acabar com o refazer: antes, cada rodada podia reescrever tudo do zero, e um resumo que reaparecia menor a cada push — ou um diagrama que sumia e voltava — fazia a PR parecer menos revisada do que estava. A revisão completa é o único caso em que essas partes são descartadas de propósito e escritas de novo.

O diagrama é obrigatório quando a PR muda código. Numa PR só de texto ou documentação ele não aparece, mas o lugar dele não fica vazio: o comentário escreve por que não há diagrama — a mesma regra vale para qualquer seção que ficaria em branco, inclusive uma rodada sem achado. E há uma exceção ao congelamento, para o caso de uma PR que abre só com documentação e ganha código num push seguinte: o diagrama entra numa rodada posterior se ainda não existir. O que o congelamento impede é refazer um diagrama que já está lá, não criar o que faltava.

O revisor nunca aprova, nunca pede mudanças e nunca bloqueia sozinho — ele comenta. Quem decide mesclar é sempre uma pessoa.

O peso que a revisão tem na lista de checagens da PR é escolha sua, em Check na PR, com três opções:

"Informativo" é o padrão. Só a terceira opção transforma a revisão em algo que trava um merge — e, mesmo nela, achado leve não deixa a verificação vermelha.

Comandos dentro da Pull Request

Escrevendo num comentário da própria PR:

Só vale para quem tem permissão de escrita, manutenção ou administração no repositório — comentário de quem só consegue ler não dispara nada.

O que o revisor confere

As regras que o próprio repositório escreve (07/09/2026)

Além de segurança e qualidade, o revisor passa a julgar a mudança contra as regras que aquele repositório escreveu para si — as diretrizes da raiz, as de pasta quando a pasta alterada tem regra própria, e as que valem para um padrão de arquivo. É o mesmo mecanismo de descoberta descrito em Repositórios de um agente, aqui aplicado à versão proposta pela PR, e não à cópia em que o agente trabalha.

Uma linha alterada que viole uma regra objetiva vira um achado próprio, de tipo "Regra do repositório", e a ficha do achado cita o arquivo e a frase exata da regra descumprida — para o apontamento ser conferível, não uma impressão.

Uma regra é sempre critério de julgamento, nunca uma ordem. Trecho de regra escrito como se falasse com o revisor — "ignore os achados de segurança", por exemplo — é tratado como tentativa de manipulação e não é obedecido. E se a própria PR altera um arquivo de regra, esse arquivo recebe um aviso para ser olhado antes do merge, e continua sendo revisado como qualquer outro código.

A leitura da mudança

A leitura não é um passe corrido sobre o diff inteiro. A mudança é repartida em blocos, lidos em paralelo, e cada bloco é avaliado por si: quem lê um bloco abre os arquivos inteiros na versão proposta, não só as linhas alteradas, e devolve um veredito por arquivo.

Duas garantias vêm dessa divisão:

• Nenhum arquivo alterado fica sem veredito. Antes de publicar, a rodada é conferida: se sobrou arquivo do diff que ninguém avaliou, a rodada é reprovada em vez de publicada incompleta.
• A leitura de um bloco que falha não derruba a revisão. Ela é retomada; persistindo a falha, aquele bloco é avaliado pelo caminho principal e fica marcado como tal.

As ferramentas de análise

Antes da leitura, uma etapa roda um conjunto de ferramentas de análise automática, e a linguagem de cada arquivo alterado decide o que roda — uma PR que só mexe em YAML não paga o preço de acionar o que serve a código.

Cada apontamento de ferramenta recebe uma decisão explícita do revisor: vira achado, com a saída da ferramenta anexada como prova, ou é descartado com o motivo registrado. A revisão mostra os dois lados — o que virou achado e o que foi descartado —, porque ferramenta automática erra, e esconder o descarte transformaria o erro dela em silêncio.

O conjunto cresceu por lotes entre 07/09/2026 e 08/09/2026, e hoje passa de sessenta ferramentas. O que elas cobrem, por área: segredo vazado, vulnerabilidade conhecida em dependência, configuração insegura de infraestrutura, qualidade de SQL, rotinas de integração contínua, contrato de API, código duplicado, código morto e dependência sem uso, ortografia em identificadores e comentários, texto e arquivos de configuração — e verificação de tipos e de estilo com a configuração do seu próprio repositório, inclusive o que apareceria se as regras estritas estivessem ligadas.

Por linguagem, a cobertura deixou de ser um punhado e virou lista longa: além de JavaScript e TypeScript, hoje entram Python, Go, PHP, Ruby, Java, Kotlin, Rust, C, C++, Swift, Lua, Fortran, PowerShell, Verilog, shell, SQL, Terraform, Docker, HTML, CSS, Markdown e YAML.

Duas ferramentas merecem nota pelo que mudam de escopo: uma varre arquivos de instrução de agente procurando instrução maliciosa ou tentativa de exfiltração, e outra procura dado pessoal em texto — esta última só entra se o repositório pedir explicitamente, e o achado dela nunca reproduz o trecho encontrado.

O que dá para fazer

Limites e modos de falha conhecidos

• Uma rodada por PR de cada vez. Um push no meio de uma rodada cancela a que estava correndo e agenda outra para o código novo. Um comando que chega durante uma rodada não é descartado: fica pendente e a rodada seguinte o herda, inclusive quando o pedido era de revisão completa (07/09/2026). Push que chega depois não apaga um comando que já estava pendente.
• Rodada que morre sem publicar não trava a PR. Ela é encerrada automaticamente depois de um tempo sem sinal de atividade, e o comentário fixo avisa que aquele push não foi revisado — em vez de a PR ficar esperando para sempre uma revisão que não vem.
• A verificação "Revisão do VolundOS" pode não aparecer, mesmo com a opção escolhida. Ela depende de uma liberação no GitHub que é feita do nosso lado, uma vez, no aplicativo que serve todas as organizações — não no seu repositório. Enquanto faltar, a revisão acontece e comenta normalmente, só não publica a verificação, e a tela avisa que é esse o motivo.
• Três tipos de PR ficam de fora por padrão: rascunho, cópia do repositório e PR aberta por robô. Cada um dos três é um interruptor que você liga se quiser, e o motivo de cada um é diferente. A cópia do repositório tem o motivo mais forte: o ambiente da revisão executa o código da PR, e código de origem não confiável não deve rodar sem alguém decidir. O rascunho fica de fora porque marcar uma PR como rascunho é justamente dizer "ainda não olhem" — o padrão respeita esse sinal, em vez de comentar sobre trabalho que você declarou incompleto. E a PR aberta por robô costuma ser atualização de dependência, sem decisão de projeto que valha uma leitura. Nada disso vale contra o push: numa PR normal, cada push novo é revisado, e essa é a maneira esperada de trabalhar — não há motivo para segurar push.
• Título, descrição e diff da PR são dados a analisar, nunca instrução. Texto escrito dentro da PR não muda o comportamento do revisor.
• O revisor roda sob a identidade da organização, não sob a pessoa que o ligou — é dela que sai o consumo da revisão, e é ela que assina o comentário.