Probe
IT

Per iniziare

Rivedi il tuo ultimo commit in due minuti

Ti basta un repository Git con almeno due commit. La prima esecuzione non richiede configurazione, né Docker, né chiave API, e non esegue mai il tuo codice.

Questa pagina riguarda Probe per il codice, lo strumento da riga di comando. Devi sorvegliare file Word, Excel o PowerPoint? Vedi Probe Desktop.

  1. Installa il binario

    Probe è un singolo eseguibile. Git deve essere installato; per questa guida non serve nient'altro. Scarica l'archivio per il tuo sistema operativo e processore, poi estrailo. Segui i passaggi per il tuo sistema qui sotto.

    Apri un terminale nella cartella estratta che contiene probe. Su macOS, rimuovi prima la quarantena del download del browser con xattr -d com.apple.quarantine probe.

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

    Niente sudo? Installa invece in ~/.local/bin, a patto che esista e sia nel tuo PATH.

    In Esplora file, crea %LOCALAPPDATA%\Programs\probe e copiaci il file probe.exe estratto. Poi apri PowerShell:

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

    Questo imposta PATH per il terminale corrente. Per i terminali futuri, aggiungi la stessa cartella al tuo Path utente nelle Variabili d'ambiente di Windows.

    L'ultimo comando stampa la versione installata, per esempio probe v0.5.1. Per verificare l'archivio rispetto ai checksum pubblicati, vedi Verifica un download.

  2. Confronta il tuo ultimo commit con il precedente

    Vai in un qualsiasi repository Git e chiedi a Probe cosa è cambiato tra HEAD~1 e HEAD:

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

    lint è la metà statica di Probe. Confronta i due commit, raccoglie i segnali di rischio e scrive un report. Non esegue mai il codice del repository, non chiama mai un provider di IA e non richiede .probe.json: in sua assenza, si applicano i valori predefiniti integrati per il linguaggio rilevato.

    Vengono analizzati solo i file committati. Le modifiche non committate e i file non tracciati vengono ignorati, quindi committa prima il tuo lavoro, per esempio su un branch di prova. Per tenere i report fuori da git status senza toccare .gitignore, esegui echo .probe/ >> .git/info/exclude.

  3. Leggi il report

    Apri .probe/CONFIDENCE_REPORT.md nel tuo editor. Inizia da Suggested Human Review, un elenco di intervalli di file e righe ordinati per gravità, ognuno con il motivo per cui è stato segnalato:

    ## 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) indica una riga nel commit candidato e (old) una riga rimossa nella base. (whole file) contrassegna un segnale che riguarda il file stesso, come un percorso sensibile, anziché una delle sue righe. Review Surface ti dice quante righe modificate coprono quegli intervalli. Gli stessi dati, con gli ID di commit e le prove dei segnali, si trovano in confidence-report.json per script e CI.

    I segnali sono motivi per guardare, non bug confermati. Il riferimento dei segnali li spiega uno per uno.

  4. Scegli cosa confrontare

    Vanno bene due revisioni qualsiasi. Alcune scelte comuni:

    ComandoConfronta
    probe lint HEAD~5..HEADI tuoi ultimi cinque commit presi insieme.
    probe lint --base mainIl tuo branch corrente rispetto a main, a partire dal loro merge base, come una pull request. Usa --base master se quello è il tuo branch predefinito.
    probe lint --base origin/main --head featureUn altro branch rispetto al branch predefinito remoto, senza farne il checkout.
    probe lint main..featureI due commit esatti, senza merge base (main...feature usa il merge base).
    probe lint --base main --ciCome sopra, ma termina con codice 2 quando è necessaria una revisione umana, per script e CI.

  5. Facoltativo: esegui i tuoi controlli in una sandbox

    review fa tutto ciò che fa lint, poi esegue i comandi di test, typecheck, build e coverage del repository in container Docker usa e getta e senza rete. Richiede Docker con container Linux e un'immagine precaricata che contenga la tua toolchain: Probe non scarica mai immagini né installa dipendenze da solo. Per un progetto Go senza dipendenze di terze parti, l'immagine predefinita è sufficiente:

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

    Per i progetti Node.js, Python e Rust, le immagini standard non contengono le tue dipendenze: costruisci un'immagine che le contenga e indicala in sandbox.image in una policy (passaggio successivo), oppure lascia che la policy attendibile costruisca quel livello con un oggetto prepare. Se Docker o l'immagine mancano, Probe si ferma con codice di uscita 4 e non ripiega mai sull'esecuzione del codice sulla tua macchina.

  6. Adottalo nel tuo repository

    Esegui probe init per generare .probe.json per il linguaggio rilevato. Rivedi i comandi e l'immagine della sandbox, poi prova la policy in locale:

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

    Committa .probe.json sul tuo branch di base. Le review successive leggeranno quella policy attendibile. Sul tuo feature branch, esegui:

    probe review --base main --ci

    Lavori con un agente di coding? Adotta il processo plan-first: l'agente esegue probe plan --intent-file task.md --ci prima di scrivere codice (un piano segnalato passa a una persona), implementa il piano, e la CI esegue probe review --plan .probe/PLAN.json --ci. L'uscita 0 significa che la modifica è conforme a un piano a basso rischio e ha superato i suoi controlli, quindi può essere unita senza revisione umana; l'uscita 2 elenca perché una persona deve guardarla (plan gate).

    Prossimi passi: ogni flag, codice di uscita e chiave di policy si trova nel riferimento. Per lasciare che un revisore IA provi a riprodurre i problemi, configura un provider come descritto in Revisore IA. Per GitHub Actions, vedi la guida all'integrazione con la CI.

  7. Mostralo nel tuo README

    Quando Probe rivede le tue pull request, aggiungi il badge al tuo README. Rimanda a questo sito e indica che il progetto usa Probe; non è un'approvazione del codice.

    verificato da Probe

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

    Gli stili HTML, reStructuredText, shields.io e il badge dinamico di Probe Hub sono nella guida ai badge.

Se qualcosa va storto

MessaggioCosa fare
base: git rev-parse … Needed a single revisionUna revisione non esiste. Il repository potrebbe avere un solo commit (quindi non esiste HEAD~1), oppure il suo branch predefinito non è main: passa --base master o un intervallo esplicito.
Il report non include le tue ultime modificheNon sono ancora state committate. Probe analizza solo i commit; committale, poi eseguilo di nuovo.
Codice di uscita 2Non è un errore: con --ci, significa che è necessaria una revisione umana. Vedi codici di uscita.
Codice di uscita 4 durante reviewDocker non è in esecuzione o l'immagine della sandbox non è presente in locale. Scaricala prima, oppure usa lint.
reviewer.model must be configured…È stato richiesto --reviewer senza un modello. Rimuovilo, oppure configura un provider.