Probe
ES

Primeros pasos

Revisa tu último commit en dos minutos

Solo necesitas un repositorio Git con al menos dos commits. La primera ejecución no necesita configuración, ni Docker, ni clave de API, y nunca ejecuta tu código.

Esta página trata de Probe para código, la herramienta de línea de comandos. ¿Vigilas archivos de Word, Excel o PowerPoint? Consulta Probe Desktop.

  1. Instala el binario

    Probe es un único ejecutable. Git debe estar instalado; para esta guía no hace falta nada más. Descarga el archivo comprimido para tu sistema operativo y tu procesador y extráelo. Sigue a continuación los pasos para tu sistema.

    Abre una terminal en la carpeta extraída que contiene probe. En macOS, quita primero la cuarentena de descarga del navegador con xattr -d com.apple.quarantine probe.

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

    ¿No tienes sudo? Instálalo en ~/.local/bin, siempre que exista y esté en tu PATH.

    En el Explorador de archivos, crea %LOCALAPPDATA%\Programs\probe y copia en ella el probe.exe extraído. Después, abre PowerShell:

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

    Esto define PATH para la terminal actual. Para las próximas terminales, añade la misma carpeta al Path de tu usuario en las variables de entorno de Windows.

    El último comando muestra la versión instalada, por ejemplo probe v0.5.1. Para comprobar el archivo comprimido con las sumas de verificación publicadas, consulta Verificar una descarga.

  2. Compara tu último commit con el anterior

    Ve a cualquier repositorio Git y pregunta a Probe qué cambió entre HEAD~1 y HEAD:

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

    lint es la mitad estática de Probe. Compara los dos commits, recopila señales de riesgo y escribe un informe. Nunca ejecuta código del repositorio, nunca llama a un proveedor de IA y no necesita .probe.json: sin él, se aplican los valores predeterminados integrados para el lenguaje detectado.

    Solo se analizan los archivos confirmados en un commit. Las ediciones sin commit y los archivos no rastreados se ignoran, así que haz commit de tu trabajo primero, por ejemplo en una rama provisional. Para que los informes no aparezcan en git status sin tocar .gitignore, ejecuta echo .probe/ >> .git/info/exclude.

  3. Lee el informe

    Abre .probe/CONFIDENCE_REPORT.md en tu editor. Empieza por Suggested Human Review, una lista de rangos de archivos y líneas ordenados por gravedad, cada uno con el motivo por el que se señaló:

    ## 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) apunta a una línea del commit candidato y (old) a una línea eliminada de la base. (whole file) marca una señal sobre el propio archivo, como una ruta sensible, y no sobre una de sus líneas. Review Surface te dice cuántas líneas modificadas cubren esos rangos. Los mismos datos, con los ID de commit y las evidencias de cada señal, están en confidence-report.json para scripts y CI.

    Las señales son motivos para mirar, no errores confirmados. La referencia de señales explica cada una.

  4. Elige qué comparar

    Sirven dos revisiones cualesquiera. Algunas opciones habituales:

    ComandoCompara
    probe lint HEAD~5..HEADTus últimos cinco commits en conjunto.
    probe lint --base mainTu rama actual frente a main, desde su base de merge, como una pull request. Usa --base master si esa es tu rama predeterminada.
    probe lint --base origin/main --head featureOtra rama frente a la rama predeterminada del remoto, sin hacer checkout.
    probe lint main..featureLos dos commits exactos, sin base de merge (main...feature usa la base de merge).
    probe lint --base main --ciIgual que el anterior, pero termina con el código 2 cuando se requiere revisión humana, para scripts y CI.

  5. Opcional: ejecuta tus comprobaciones en un sandbox

    review hace todo lo que hace lint y, además, ejecuta los comandos de test, typecheck, build y coverage del repositorio en contenedores Docker desechables y sin red. Necesita Docker con contenedores Linux y una imagen precargada con tu cadena de herramientas: Probe nunca descarga imágenes ni instala dependencias por su cuenta. Para un proyecto Go sin dependencias de terceros, basta con la imagen predeterminada:

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

    Para proyectos de Node.js, Python y Rust, las imágenes estándar no contienen tus dependencias: construye una imagen que las incluya y apunta sandbox.image a ella en una política (siguiente paso), o deja que la política de confianza construya esa capa con un objeto prepare. Si falta Docker o la imagen, Probe se detiene con el código de salida 4 y nunca recurre a ejecutar código en tu máquina.

  6. Adóptalo en tu repositorio

    Ejecuta probe init para generar .probe.json para el lenguaje detectado. Revisa sus comandos y su imagen de sandbox y, después, prueba la política en local:

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

    Haz commit de .probe.json en tu rama base. Las revisiones posteriores leerán esa política de confianza. En tu rama de funcionalidad, ejecuta:

    probe review --base main --ci

    ¿Trabajas con un agente de programación? Adopta el proceso de plan primero: el agente ejecuta probe plan --intent-file task.md --ci antes de escribir código (un plan señalado pasa a una persona), implementa el plan, y la CI ejecuta probe review --plan .probe/PLAN.json --ci. El código 0 significa que el cambio se ajusta a un plan de bajo riesgo y superó sus comprobaciones, así que puede fusionarse sin revisión humana; el código 2 enumera por qué una persona debe mirarlo (plan gate).

    Siguientes pasos: todas las opciones, códigos de salida y claves de política están en la referencia. Para que un revisor de IA intente reproducir problemas, configura un proveedor como se describe en Revisor de IA. Para GitHub Actions, consulta la guía de integración con CI.

  7. Muéstralo en tu README

    Cuando Probe revise tus pull requests, añade la insignia a tu README. Enlaza a este sitio e indica que el proyecto usa Probe; no es una aprobación del código.

    verificado por Probe

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

    Los estilos HTML, reStructuredText y shields.io, así como la insignia en vivo de Probe Hub, están en la guía de insignias.

Si algo sale mal

MensajeQué hacer
base: git rev-parse … Needed a single revisionUna revisión no existe. Puede que el repositorio tenga un solo commit (así que no hay HEAD~1) o que su rama predeterminada no sea main: pasa --base master o un rango explícito.
Al informe le faltan tus últimas edicionesTodavía no están en un commit. Probe solo analiza commits; haz commit y vuelve a ejecutarlo.
Código de salida 2No es un error: con --ci, significa que se requiere revisión humana. Consulta los códigos de salida.
Código de salida 4 durante reviewDocker no se está ejecutando o la imagen del sandbox no está presente en local. Descárgala primero o usa lint.
reviewer.model must be configured…Se solicitó --reviewer sin un modelo. Quítalo o configura un proveedor.