Código aberto · Para código e para documentos de escritório
As mudanças se acumulam mais rápido do que qualquer pessoa consegue lê-las: pull requests escritos com assistentes de IA, orçamentos e contratos editados por muitas mãos. O Probe compara cada nova versão com a última em que você confiou, coloca na sua frente as poucas modificações que exigem seu julgamento e mostra o porquê.
Versão mais recente v0.5.1 · Os achados vêm de regras fixas, não de um modelo · IA opcional.
As duas ferramentas partem da última versão que você revisou, sinalizam as modificações arriscadas com regras fixas e explicáveis e mantêm um registro do que foi verificado. Um modelo de IA pode ajudar a explicar um achado; ele nunca decide o que é sinalizado, e nada sai da sua máquina a menos que você escolha.
Para desenvolvedores, tech leads e pipelines de CI.
Para equipes de finanças, jurídico, vendas e operações, e para qualquer pessoa que compartilha arquivos.
| Probe para código | Probe Desktop | |
|---|---|---|
| Você é | Desenvolvedor, revisor, equipe de plataforma | Controller, advogado, gestor, assistente |
| O que muda | Código-fonte, em commits e pull requests do Git | Arquivos Word, Excel e PowerPoint, no OneDrive ou no Google Drive |
| A referência | A branch base do pull request | A última versão que alguém marcou como revisada |
| O que ele procura | Código sensível à segurança, validação removida, mudanças de API e de dependências, testes falhando ou ausentes | Fórmulas fixadas em valores, intervalos reduzidos, valores, datas e obrigações alterados, planilhas ou slides ocultos, macros |
| Evidências | Verificações executadas em uma sandbox, problemas reproduzidos, um relatório em JSON e Markdown | O antes e o depois de cada mudança sinalizada, e quem salvou por último |
| Como roda | Uma ferramenta de linha de comando no seu terminal ou CI, ou o Hub para uma conta inteira | Um aplicativo na barra de tarefas ou na barra de menus, monitorando em segundo plano |
Um orçamento que passou por cinco pessoas, um contrato reescrito pela outra parte, uma apresentação para o conselho atualizada na noite anterior. Ninguém relê tudo, e ninguém deveria precisar. O Probe Desktop monitora as pastas que sua equipe já usa e mostra as modificações que mudam um número, um compromisso ou um cálculo, com o antes e o depois.
=SUM(A1:A3)
=SUM(A1:A2)
=A2*2
400
O fornecedor deverá entregar antes de 15/03/2026.
O fornecedor poderá entregar antes de 15/03/2026.
O preço é fixado em €12.000, sem impostos.
O preço é fixado em €15.000, sem impostos.
Assistentes de IA escrevem pull requests grandes rapidamente. O Probe diz quais linhas ler primeiro: ele mapeia o diff em sinais de risco, executa suas verificações em contêineres descartáveis, tenta reproduzir problemas com testes diferenciais e entrega a você um plano de revisão focado, com evidências rastreáveis. Uma ferramenta de linha de comando para Windows, Linux e macOS, e um hub Docker para uma conta inteira do GitHub ou do GitLab. Experimente em 2 minutos →
O código escrito por IA fica previsível quando o agente anuncia o trabalho antes. O Probe mede o risco do plano antes de qualquer código ser escrito e depois verifica se a mudança fez exatamente o que foi anunciado. Uma mudança que segue um plano de baixo risco e passa nas verificações pode ser mesclada sem que uma pessoa leia o diff; todo o resto vai para revisão, com os motivos.
O probe plan faz o agente simular a mudança em modo somente leitura. Regras fixas, e não o modelo, sinalizam caminhos críticos, mudanças de API pública e de dependências, e código muito usado ou sem testes. Um plano sinalizado vai para uma pessoa antes de qualquer código ser escrito.
O plano vira um contrato: os arquivos, símbolos e dependências que o agente pode tocar. Ele implementa isso, e apenas isso.
O probe review --plan reavalia o plano, executa as verificações na sandbox e compara o diff com o contrato: cada arquivo não planejado, mudança de API não anunciada, caminho crítico ou dependência é relatado.
Mudança em conformidade, plano de baixo risco, verificações aprovadas, nada mais sinalizado: nenhuma revisão humana necessária, saída 0, o pipeline faz o merge. Caso contrário, saída 2: uma pessoa revisa o pull request, começando pelos motivos listados.
# 1. before coding: plan, and let a human validate a flagged plan
probe plan --intent-file task.md --ci
# 2. the agent implements .probe/PLAN.json
# 3-4. in CI: conformance, checks and the gate (exit 0 = merge, 2 = review)
probe review --base origin/main --plan .probe/PLAN.json --ci
Plan conformance: conforming; 0 high, 0 medium, 0 low differences from the plan.
Plan gate: no human review required (low-risk plan, conforming change, checks passed, nothing else requests review).O gate é uma decisão de processo, não uma prova de correção: a sua política confiável decide o que é crítico e quais testes rodam, e qualquer dúvida envia a mudança para uma pessoa. Como o gate decide.
Testes, vet, build e cobertura passaram nesta mudança. Ela também removeu a validação do valor de reembolso e deixou o perfil de suporte emitir reembolsos. O Probe colocou as duas coisas no topo do plano de revisão, entre 19 linhas sinalizadas de 125.
A parte cara de revisar um pull request assistido por IA não são as linhas arriscadas. É encontrá-las entre os helpers, testes e documentação ao redor e depois descobrir se uma suspeita é real. O Probe faz essa triagem e reúne as evidências antes de você abrir o diff.
payment/refund.go, onde o relatório mostra a validação removida.Uma superfície de revisão sem duplicatas, contada em linhas realmente alteradas, para que grandes mudanças geradas se reduzam às partes que tocam autenticação, pagamentos, validação, dependências ou APIs públicas.
Seus comandos de teste, typecheck, build e cobertura rodam em contêineres descartáveis e sem rede. Nada da candidata é executado na sua máquina.
Áreas não verificadas e verificações incompletas são listadas explicitamente, e o --ci as transforma em um código de saída. Você sabe o que foi coberto e o que ainda precisa do seu julgamento.
Trecho de .probe/CONFIDENCE_REPORT.md, produzido por probe review HEAD~1..HEAD --reviewer=false --ci (v0.3.0) em um pequeno repositório de loja. O commit adicionou helpers de catálogo com testes, reescreveu os reembolsos e mexeu na autorização. Nenhum provedor de IA foi usado.
## Change Summary
120 additions / 5 deletions · 5 files changed
Exit code: 2. No confidence percentage is assigned.
## Automated Checks1
- PASS test (check-1; exit 0; 5982 ms)
- PASS typecheck (check-2; exit 0; 4866 ms)
- PASS build (check-3; exit 0; 2835 ms)
- PASS coverage (check-4; exit 0; 6416 ms)
## Reproduced Issues2
No issue was reproduced by a passing baseline
and failing candidate experiment.
## Suggested Human Review3
- high auth/auth.go:7 (new): Authentication or
authorization function body changed
- high payment/refund.go:21–22 (new): Payment-sensitive
function body changed
- high payment/refund.go:25–26 (new): Exported Go
declaration added; Payment-sensitive function body changed
- high payment/refund.go:21 (old): Configured sensitive
path changed; No nearby test file changed;
Possible input validation removed
- medium catalog/format.go:9 (new): Exported Go
declaration added
… 11 more medium signals in catalog/
## Review Surface4
Focused review: 19 / 125 changed lines.
## Changed-line Execution5
Of 67 added Go lines, 44 were executed at least once,
0 were not executed, 23 are not inside any
instrumented block.As duas refs são resolvidas em IDs de commit. Renomeações, exclusões, binários e a semântica de merge base são tratados; somente arquivos commitados são revisados, então edições locais nunca vazam para o resultado.
Comparação da AST do Go, heurísticas léxicas identificadas e regras de caminhos sensíveis sinalizam autenticação, pagamentos, dependências, validação removida, construções inseguras e testes ausentes em Go, TypeScript/JavaScript, Python e Rust.
Seus comandos de teste, typecheck e build rodam como arrays argv em contêineres descartáveis, sem root e sem rede, com limites de CPU, memória, PIDs e tempo.
Um revisor opcional escreve testes temporários. Um teste que passa na baseline e falha na candidata sustenta um problema reproduzido; todo o resto continua UNVERIFIED.
Experimente no seu último commit sem configuração, sem Docker e sem chave de API. Quando adotar, faça commit de uma política na sua branch base: ela é lida da base, então um pull request não consegue afrouxar as próprias regras.
# try it: compare with the previous commit
probe lint HEAD~1..HEAD
# adopt it: once, in your repository
probe init
git add .probe.json && git commit -m "Add review policy"
# on every pull request
probe review --base main --ciO hub é a imagem Docker complementar. Rode um contêiner, entre com o GitHub ou o GitLab, e cada repositório que ainda não tem um .probe.json recebe uma política proposta em um clique, com pré-visualização antes do commit na branch padrão.
Repositórios que têm uma política podem ser monitorados: cada novo commit é analisado e o relatório dele se abre sozinho. Um controle deslizante de gravidade filtra os alertas de baixa a crítica, e clicar em um alerta expande todas as modificações a que ele se refere, com as linhas sinalizadas destacadas no diff.
Um contêiner Docker, sem banco de dados, sem serviço externo — assim uma empresa pode implantá-lo internamente com sua própria instância do GitHub Enterprise ou do GitLab. No modo padrão, ele nunca executa o código analisado.
Hospedado em app.probe.technology — a mesma imagem que você pode rodar na sua própria rede.
# one container, on your own network
$ docker run -p 8080:8080 \
-e PROBE_HUB_BASE_URL=https://hub.example.com \
-e PROBE_HUB_GITHUB_CLIENT_ID=... \
-e PROBE_HUB_GITHUB_CLIENT_SECRET=... \
-v hub-data:/var/lib/probe-hub \
gvinsot/probe-hub
Sign in · bootstrap the missing policies · watch pushes
Reports open by themselves, filtered by severity.Intervalos de revisão sem duplicatas, com coordenadas antigas e novas, contados em linhas realmente alteradas e ordenados por gravidade.
Testes gerados rodam na baseline e na candidata em ambientes novos. A execução em Go é verificada a partir de eventos de teste estruturados.
Opcionalmente, mede quais linhas Go adicionadas uma execução registrada executou — relatado como uma observação, nunca como prova de teste.
Um índice estático de Go, TypeScript/JavaScript, Python e Rust lista os chamadores não alterados de cada função alterada e os testes existentes que a alcançam.
Testes impactados e testes da baseline alterados, fuzzing diferencial e mutação das linhas adicionadas rodam na base e na candidata, registrados como evidências, nunca como veredito.
O probe plan avalia o plano de um agente antes de existir qualquer código; em seguida, o --plan sinaliza cada arquivo ou API exportada que a mudança tocou sem anunciar.
Use qualquer provedor compatível com OpenAI. As ferramentas têm limites: leitura de arquivos com dados ocultados, pesquisa e execução de testes. Sem shell, sem acesso a URLs.
Um workflow reutilizável do GitHub Actions, códigos de saída com significado, relatórios JSON com IDs de commit, evidências e hashes dos artefatos, além de SARIF e um comentário de PR contendo apenas achados sustentados por evidências.
Agentes de programação executam lint e review antes de entregar o trabalho e relatam o que foi reproduzido e o que continua em aberto.
Uma ferramenta de revisão conquista confiança sendo precisa sobre os próprios limites. O Probe não atribui percentuais de confiança e nunca aprova uma mudança com base na palavra de um modelo. Para código, ele só dispensa a revisão humana pelo plan gate, quando um plano de baixo risco foi seguido e todas as verificações automatizadas passaram sem problemas. Para documentos, uma pessoa sempre decide.
Código aberto, licença AGPL-3.0. Uma ferramenta de linha de comando para código e um aplicativo para documentos, ambos publicados em todas as versões.