Probe
PT

Primeiros passos

Revise seu último commit em dois minutos

Você só precisa de um repositório Git com pelo menos dois commits. A primeira execução não exige configuração, Docker nem chave de API, e nunca executa o seu código.

Esta página trata do Probe para código, a ferramenta de linha de comando. Vai monitorar arquivos Word, Excel ou PowerPoint? Veja o Probe Desktop.

  1. Instale o binário

    O Probe é um único executável. O Git precisa estar instalado; nada mais é necessário para este guia. Baixe o arquivo para o seu sistema operacional e processador e extraia-o. Siga os passos do seu sistema abaixo.

    Abra um terminal na pasta extraída que contém probe. No macOS, primeiro remova a quarentena de download do navegador com xattr -d com.apple.quarantine probe.

    sudo install probe /usr/local/bin/
probe version

    Sem sudo? Instale em ~/.local/bin, desde que essa pasta exista e esteja no seu PATH.

    No Explorador de Arquivos, crie %LOCALAPPDATA%\Programs\probe e copie para ela o probe.exe extraído. Depois abra o PowerShell:

    $env:Path += ";$env:LOCALAPPDATA\Programs\probe"
probe version

    Isso define o PATH para o terminal atual. Para os próximos terminais, adicione a mesma pasta ao Path do seu usuário nas Variáveis de Ambiente do Windows.

    O último comando exibe a versão instalada, por exemplo probe v0.5.1. Para conferir o arquivo com os checksums publicados, veja Verifique um download.

  2. Compare seu último commit com o anterior

    Vá para qualquer repositório Git e pergunte ao Probe o que mudou entre HEAD~1 e HEAD:

    cd path/to/your/repository
probe lint HEAD~1..HEAD

    O lint é a metade estática do Probe. Ele compara os dois commits, coleta sinais de risco e grava um relatório. Ele nunca executa código do repositório, nunca chama um provedor de IA e não precisa de .probe.json: sem ele, aplicam-se os padrões embutidos da linguagem detectada.

    Somente arquivos commitados são analisados. Edições não commitadas e arquivos não rastreados são ignorados, então faça commit do seu trabalho antes, por exemplo em uma branch de rascunho. Para manter os relatórios fora do git status sem mexer no .gitignore, execute echo .probe/ >> .git/info/exclude.

  3. Leia o relatório

    Abra .probe/CONFIDENCE_REPORT.md no seu editor. Comece por Suggested Human Review, uma lista de arquivos e intervalos de linhas ordenada por gravidade, cada um com o motivo pelo qual foi sinalizado:

    ## Suggested Human Review
- **high** auth/auth.go:7–7 (new): Authentication or authorization function body changed
- **high** payment/refund.go (whole file): Lines added and removed in a sensitive file; No nearby test file changed
- **high** payment/refund.go:21–21 (old): Possible input validation removed

    (new) aponta para uma linha do commit candidato e (old) para uma linha removida da base. (whole file) marca um sinal sobre o próprio arquivo, como um caminho sensível, e não sobre uma das suas linhas. Review Surface informa quantas linhas alteradas esses intervalos cobrem. Os mesmos dados, com IDs de commit e as evidências dos sinais, estão em confidence-report.json para scripts e CI.

    Sinais são motivos para olhar, não bugs confirmados. A referência de sinais explica cada um deles.

  4. Escolha o que comparar

    Quaisquer duas revisões funcionam. Algumas escolhas comuns:

    ComandoCompara
    probe lint HEAD~5..HEADSeus últimos cinco commits em conjunto.
    probe lint --base mainSua branch atual comparada com main, a partir da merge base, como um pull request. Use --base master se essa for a sua branch padrão.
    probe lint --base origin/main --head featureOutra branch comparada com a branch padrão remota, sem fazer checkout dela.
    probe lint main..featureOs dois commits exatos, sem merge base (main...feature usa a merge base).
    probe lint --base main --ciO mesmo que acima, mas sai com código 2 quando for necessária revisão humana, para scripts e CI.

  5. Opcional: execute suas verificações em uma sandbox

    O review faz tudo o que o lint faz e depois executa os comandos de teste, typecheck, build e cobertura do repositório em contêineres Docker descartáveis e sem rede. Ele precisa do Docker com contêineres Linux e de uma imagem pré-carregada com o seu toolchain: o Probe nunca baixa imagens nem instala dependências por conta própria. Para um projeto Go sem dependências de terceiros, a imagem padrão basta:

    docker pull golang:1.26-bookworm
probe review HEAD~1..HEAD --reviewer=false

    Para projetos Node.js, Python e Rust, as imagens padrão não contêm as suas dependências: construa uma imagem que as contenha e aponte sandbox.image para ela em uma política (próximo passo), ou deixe a política confiável construir essa camada com um objeto prepare. Se o Docker ou a imagem estiverem ausentes, o Probe para com código de saída 4 e nunca recorre a executar código na sua máquina.

  6. Adote no seu repositório

    Execute probe init para gerar o .probe.json da linguagem detectada. Revise os comandos e a imagem da sandbox e depois teste a política localmente:

    probe review --base main --config .probe.json

    Faça commit do .probe.json na sua branch base. Os reviews seguintes leem essa política confiável. Na sua branch de feature, execute:

    probe review --base main --ci

    Trabalha com um agente de programação? Adote o processo com plano primeiro: o agente executa probe plan --intent-file task.md --ci antes de escrever código (um plano sinalizado vai para uma pessoa), implementa o plano, e o CI executa probe review --plan .probe/PLAN.json --ci. A saída 0 significa que a mudança está em conformidade com um plano de baixo risco e passou nas verificações, então pode ser mesclada sem revisão humana; a saída 2 lista por que uma pessoa precisa olhar (plan gate).

    Próximos passos: cada flag, código de saída e chave de política está na referência. Para deixar um revisor de IA tentar reproduzir problemas, configure um provedor como descrito em Revisor de IA. Para o GitHub Actions, veja o guia de integração com CI.

  7. Mostre no seu README

    Assim que o Probe estiver revisando seus pull requests, adicione o badge ao seu README. Ele leva a este site e diz que o projeto usa o Probe; não é uma aprovação do código.

    verificado pelo Probe

    [![verified by Probe](https://probe.technology/badge/verified-by-probe.svg)](https://probe.technology/)

    HTML, reStructuredText, estilos do shields.io e o badge ao vivo do Probe Hub estão no guia de badges.

Se algo der errado

MensagemO que fazer
base: git rev-parse … Needed a single revisionUma revisão não existe. O repositório pode ter um único commit (então não há HEAD~1), ou a branch padrão dele não é main: passe --base master ou um intervalo explícito.
O relatório não inclui suas últimas ediçõesElas ainda não foram commitadas. O Probe só analisa commits; faça commit delas e execute de novo.
Código de saída 2Não é um erro: com --ci, significa que é necessária revisão humana. Veja códigos de saída.
Código de saída 4 durante o reviewO Docker não está rodando ou a imagem da sandbox não está disponível localmente. Baixe-a antes, ou use o lint.
reviewer.model must be configured…--reviewer foi solicitado sem um modelo. Remova-o ou configure um provedor.