Revisão de código · Open source

Além do diff.
Até a evidência.

Entenda o que mudou, investigue o que importa e leve ao PR comentários que mostram o porquê.

Conectar com GitHub Ver uma revisão

Contexto do repositório. Verificação cruzada. Decisão humana.

● da hipótese ao achado confirmado

src/approvals/service.ts

diffarobotagora

P2 Valide antes de concluir a aprovação

Se os dados forem inválidos, a proposta já terá sido consumida. O usuário não conseguirá tentar novamente.

41async function approve(input) {42  await proposal.approve();43  validateFields(input);44}

Exemplo ilustrativo. Conteúdo e resultado sintéticos.

Uma nova camada de revisão.
Com as ferramentas que você já usa.

⌘ GitHubCodex✳ Claude Code>_ CLI

01 / Como funciona

Uma revisão boa
não termina na suspeita.

Da URL do pull request até um achado rastreável. Você acompanha o caminho e decide quando publicar.

01 ↗

Leia a mudança.

Fixe o commit e percorra o diff em lotes. Arquivos grandes entram na análise sem estourar o contexto.

02 ↗

Investigue o contexto.

Busque definições, usos, rotas e testes. Se a evidência não for suficiente, o candidato continua inconclusivo.

03 ↗

Comente com critério.

Verifique a hipótese e a linha do código. Faça uma prévia antes de publicar, sem repetir comentários existentes.

02 / Evidência à vista

Não basta apontar.
É preciso explicar.

O achado, o contexto consultado e o parecer ficam juntos. A revisão deixa um registro que você pode conferir.

CONTEXTO CONSULTADOEXEMPLO ILUSTRATIVO

01approvals/service.tsmudança

02approvals/validation.tsdefinição

03approvals.test.tscenário

Os arquivos e o parecer ficam registrados na revisão.

03 / Feito para dar controle

Sua revisão.
Sem caixa-preta.

Começamos pelo que torna uma revisão útil: evidência acessível, limites explícitos e autonomia para o time.

↗

Open source, desde a base.

Uma CLI em TypeScript, com histórico local em SQLite e relatórios em Markdown e JSON. Inspecione o processo, não só o resultado.

↗

Inconclusivo também é uma resposta.

Investigar mais não obriga a confirmar. Candidatos sem evidência suficiente ficam fora da publicação automática.

↗

Você escolhe quando publicar.

Confira o dry-run, valide o commit e publique os novos achados. A deduplicação preserva a conversa do PR.

Comece por um pull request

A próxima revisão
já pode ser diferente.

Conecte seu workspace e escolha onde executar as revisões. Suas assinaturas permanecem no executor que você controla.

Configurar meu workspace ↗

TERMINAL / REVISÃO PELA CLI

$ node dist/cli.js review URL_DO_PR \
  --batch --investigate \
  --publish --dry-run

Pré-requisitos: Node.js, Git, gh, Codex e Claude Code autenticados. O dry-run não publica comentários.

Contexto Revisão e investigação

Conexão GitHub App + bot

Controle Repositórios e publicação

Algumas respostas, sem rodeios

Antes do primeiro merge.

Onde as revisões são executadas?

O painel organiza as revisões e a conexão com o GitHub. A análise roda em um executor vinculado ao seu workspace, na sua máquina ou na infraestrutura do seu time. Você acompanha o resultado no painel.

Como o código é tratado?

O executor lê o snapshot do repositório e envia os trechos selecionados aos provedores usados na análise. Relatórios e evidências são enviados ao servidor do seu workspace, que valida e publica os comentários. Controle o acesso aos dois ambientes.

Preciso contratar outro modelo?

O executor usa os CLIs oficiais autenticados nas suas assinaturas do Codex e Claude Code. Aplicam-se os limites e condições desses serviços; as credenciais dos modelos permanecem no executor.

A ferramenta modifica o meu código?

O Diffaro analisa snapshots Git sem executar o projeto nem alterar seus arquivos. Os comentários são publicados pela GitHub App conforme a configuração do workspace.

Além do diff.Até a evidência.