Usar revisão com IA

Este guia mostra como pôr agentes revisores a rever uma pull request e como publicar o resultado no GitHub.

Iniciar uma revisão com IA

Abra a PR e vá ao separador Visão geral
Abra o menu de overflow ⋯ na linha de ações e escolha Ask AI

O item só aparece enquanto a PR está aberta — é uma ação de pré-merge. O mesmo botão é oferecido como Ask AI no estado vazio do separador Revisão, antes de existir qualquer revisão.

O Control Center inicia o pipeline pr_review predefinido e abre o separador Revisão da PR, para que o possa acompanhar. O pipeline:

Abre o espaço de revisão da própria PR, cujo worktree isolado tem a PR em checkout na sua ref de head
Distribui os revisores de acordo com o nível de revisão do espaço de trabalho — três por predefinição (os agentes predefinidos qa, architect e engineer, em paralelo). Não há deteção de linguagem nem de domínio
Faz com que o agente líder (CEO) consolide as suas constatações num percurso guiado
Finaliza: agrupa as constatações em categorias de consenso e calcula o veredicto. Quando a associação atinge awaiting approval, Publicar no GitHub aparece no separador Revisão

A profundidade da revisão é o nível de revisão do espaço de trabalho — light (um revisor), balanced (três, a predefinição) ou thorough (os cinco, acrescentando os especialistas de segurança e desempenho) — definido em Definições → Espaço de trabalho → Geral, no cartão Política do espaço de trabalho. Um nível mais leve regista exatamente o mesmo número de constatações; apenas relata menos delas em primeiro plano.

Todos os revisores publicam no espaço de revisão único da PR, e é isso que torna as suas constatações comparáveis. Consulte Revisão com IA para saber como as peças se encaixam.

O pr_review é fornecido apenas com um disparador manual. Para que seja acionado em cada PR publicada, adicione um disparador por si próprio — consulte Despachar agentes revisores. Também pode iniciar uma revisão a partir do próprio GitHub, sem precisar de disparador de pipeline: mencione o bot do servidor na PR ou adicione a etiqueta ai-review — consulte Falar com o Control Center a partir de uma PR do GitHub.

Se uma notificação indicar que já está a decorrer uma revisão para esta pull request, é porque já existe uma em curso; permaneça no separador Revisão ou abra Pipelines para a encontrar.

Ler as constatações

Os revisores registam as constatações como nós de revisão no espaço de revisão. Cada um transporta:

Campo	Descrição
Tipo	`bug`, `suggestion`, `recommendation`, `question` ou `ticket`
Prioridade	P0 (crítico) → P3 (pormenor)
Categoria	`security`, `stability`, `data_integrity`, `correctness`, `performance` ou `maintainability`
Ficheiro e linha	Onde a constatação está ancorada
Código original	O código a que a constatação se refere
Código sugerido	A correção proposta
Confiança	O grau de confiança do revisor
Estado	`open` → `consensus-ready` → `resolved` ou `dismissed`

Uma constatação só atinge consensus-ready quando um revisor par a confirma. Um agente não pode confirmar a sua própria constatação, por isso a opinião de um único revisor nunca progride sozinha.

O separador Revisão apresenta a lista de constatações, filtrável por tipo e estado, com um botão de alternância para constatações descartadas, ao lado do artefacto publicado pelo agente de consolidação. A vista determinística — coortes, o painel multi-eixo, diffs de contrato e visuais — é calculada do lado do servidor, mas não tem superfície na aplicação; consulte Computação de revisão para saber o que essa passagem produz.

Verificar o painel de discordâncias

Quando dois revisores ancoram constatações ao mesmo ficheiro e linha mas as classificam de forma muito diferente — prioridades com dois ou mais níveis de diferença, ou um chama-lhe bug enquanto o outro lhe chama suggestion —, aparece um painel de discordâncias acima da lista de constatações. Leia essas primeiro: é onde as opiniões dos revisores divergem e o seu julgamento vale mais.

Ler o veredicto

Quando o agente líder finaliza, calcula um veredicto:

Veredicto	Significado
Ship	Não foi encontrado nada bloqueante
Hold	Problemas que devem ser resolvidos antes do merge
Block	Problemas críticos que têm de ser corrigidos

O veredicto transporta uma pontuação de confiança agregada e contagens de constatações por prioridade.

Os eixos de revisão integram-se então nele e só o podem tornar mais severo. Um eixo com portão que falha força Block; um eixo com portão que não conseguiu concluir-se (partial) ou que não conseguiu sequer ser executado (unavailable) força, no mínimo, Hold. A ausência de provas nunca abre um portão.

Publicar a revisão no GitHub

A publicação é um passo separado e deliberadamente dependente do utilizador. O pipeline pr_review mantém a revisão no Control Center; não a publica no GitHub.

No separador Revisão, aguarde até aparecer Publicar no GitHub
Carregue em Publicar no GitHub

O Control Center envia uma revisão do GitHub. As constatações já resolvidas ou descartadas são ignoradas. O botão inclui todas as constatações abertas restantes e, com Ship, submete APPROVE. (A ferramenta MCP publish_review_to_github continua a usar por predefinição apenas constatações confirmadas por pares e não aprova, a menos que passe approve_on_ship.) As que têm uma âncora de ficheiro e linha tornam-se comentários em linha; tudo o resto é integrado no corpo do resumo, cada uma com um rodapé “— Control Center AI review” para que a origem seja inequívoca. Um veredicto Block é submetido como REQUEST_CHANGES; Hold como COMMENT; Ship como APPROVE a partir deste botão. Surge então uma notificação Publicada. A revisão é publicada sob a identidade da aplicação do servidor.

Se o GitHub rejeitar uma âncora em linha por a linha não fazer parte do diff, toda a revisão é reenviada com cada constatação integrada no corpo, para que nada seja descartado em silêncio.

Outros pipelines incorporados publicam diretamente no GitHub: cross_review, pr_triage, ticket_to_pr e pre_merge_gate terminam cada um num passo de comentário. Só o pr_review retém o resultado para si.

Despachar revisores por si próprio

Para controlar que funções revêem a PR e que ficheiros cada uma analisa, use a ferramenta MCP dispatch_reviewers dentro de um espaço de revisão existente, ou adicione nós de revisor a um pipeline. Ambas as vias, com a assinatura exata da ferramenta, estão em Despachar agentes revisores.