Computação de revisão (coortes, eixos e diffs determinísticos)

A aba Revisão de uma PR mostra o progresso ao vivo do pipeline de revisão enquanto ele trabalha e, depois, o artefato que ele publicou, com as ações disponíveis sobre ele. Uma única aba com dois estados, porque são a mesma coisa em dois momentos. Ela não é uma aba padrão: uma PR não tem revisão até que alguém peça uma, então é Ask AI que a abre.

Por trás dessa aba, o cc_server monta coortes de arquivos, executa os eixos determinísticos e os serve pelas operações RPC review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute e suas gêmeas watch*). Um layout persistido que ainda nomeia pr.reviewStudio abre essa mesma aba Revisão.

Na aba Revisão:

O agente consolidador publica um artefato de conversa comum com publish_artifact, então a aba o renderiza pelo mesmo visualizador de artefatos que uma bolha de chat abre — não existe uma cópia do sistema de artefatos com formato de revisão.
Os achados ficam em uma barra lateral ao lado dele, e o veredito aparece em uma barra fina acima do artefato, em vez de em um cabeçalho de painel.
Um banner de desatualização aparece quando o head da PR avançou além da revisão.

Consulte Usar revisão com IA para entender o fluxo e Revisar e fazer merge de uma PR para agir sobre ele.

Coortes

As coortes agrupam os arquivos alterados da PR em grupos derivados do conteúdo, com arquivos que pertencem juntos pelo significado, classificados por impacto para que o grupo mais arriscado seja lido primeiro. Elas são recalculadas a cada mudança de SHA de head e substituídas por completo; cada coorte tem uma chave estável entre pushes, então um resumo e o progresso da revisão sobrevivem a um rebase.

Se o repo não tiver índice de código, as coortes recorrem ao agrupamento por caminhos. Para indexar um repo, use Configurações → Espaço de trabalho → Repositórios — cada linha de repositório traz uma ação Indexar código que executa o pipeline index_code e informa o progresso no próprio lugar.

O grafo de código só analisa linguagens com uma gramática incluída (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Um repo em qualquer outra linguagem nunca poderá produzir coortes semânticas, por mais vezes que você o indexe.

Um agente pode registrar um resumo em markdown para uma coorte com set_cohort_summary e anexar um diagrama de passo a passo estruturado com add_review_diagram — um objeto tipado de sequência, de relação entre entidades ou de máquina de estados, nunca texto mermaid. Cada aresta é conferida em relação ao grafo de código real, e uma aresta que o grafo não consegue corroborar é marcada como não verificada em vez de desenhada como fato.

O eixo do contrato de API

O eixo do contrato compara apenas arquivos de especificação explícitos. Ele reconhece os seis nomes padrão — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — além de qualquer arquivo alterado cujo nome contenha openapi ou swagger e termine em .yaml, .yml ou .json. Um contrato inferido a partir do código do handler está fora do escopo, e schemas GraphQL não são comparados.

Cada mudança é classificada — adições, remoções e modificações de endpoint, parâmetro, schema e resposta — e carrega uma severidade: breaking (endpoint ou parâmetro removido, tipo restringido, novo parâmetro obrigatório), não breaking (aditivo) ou informativo. Uma mudança rejeitada faz o portão do contrato falhar, assim como uma mudança breaking deixada sem decisão; uma mudança breaking aprovada gera aviso; sem mudanças breaking, o portão passa. Um diff marcado derivado (consultivo) nunca atua como portão.

Aprovar ou rejeitar uma mudança é review_studio.setContractDecision.

O eixo visual

Se a PR alterar componentes de interface em um repo Flutter com um app Widgetbook, a passagem de computação renderiza os componentes alterados antes e depois por meio de uma passagem golden de flutter test sem interface nos worktrees de base e de head da PR, e então compara os pixels.

Instantâneos marcados como changed ou removed retêm o portão visual até serem aprovados; instantâneos unchanged, added e approved o liberam. A indisponibilidade tem uma de quatro razões: nenhum SDK do Flutter no host, nenhum app Widgetbook no repo, nenhum caso de uso testável com golden, ou um erro no harness golden.

Aprovar uma mudança pretendida é review_studio.approveVisual.

Os eixos e o veredito

Eixo	Dirigido por
Correção	Agentes revisores (tokens)
Segurança	Agentes revisores (tokens)
Lacuna de testes	Agentes revisores (tokens)
Visual	Determinístico (harness golden)
Contrato de API	Determinístico (diff de especificação)

Os três eixos de tokens são registrados quando um agente líder chama finalize_review; os dois eixos determinísticos são registrados pela passagem de computação.

Cada eixo informa um dos seguintes estados:

Estado	Significado
Pass	Foi executado, nada bloqueante foi encontrado
Warn	Foi executado, pontos não bloqueantes
Fail	Foi executado e encontrou um problema bloqueante
Partial	Foi executado, mas não pôde ser concluído; os resultados estão incompletos
Unavailable	Não pôde ser executado de forma alguma

Apenas pass e warn liberam um eixo com portão. Partial e unavailable são deliberadamente distintos de fail, e nenhum dos dois libera um portão.

Os eixos se agregam em Ship, Hold ou Block, e só podem tornar o veredito mais severo — ele nunca é rebaixado. Um eixo com portão que falha força Block; um que esteja partial ou unavailable força no mínimo Hold. Assim, um eixo bloqueante que não pôde rodar retém o veredito: a ausência de evidência nunca deixa um portão verde.

O veredito exibido na aba Revisão é o que finalize_review publicou.