Probe
DE

Erste Schritte

Prüfen Sie Ihren letzten Commit in zwei Minuten

Sie brauchen nur ein Git-Repository mit mindestens zwei Commits. Der erste Lauf benötigt keine Konfiguration, kein Docker und keinen API-Schlüssel und führt Ihren Code niemals aus.

Diese Seite behandelt Probe für Code, das Kommandozeilenwerkzeug. Sie überwachen Word-, Excel- oder PowerPoint-Dateien? Siehe Probe Desktop.

  1. Binary installieren

    Probe ist eine einzige ausführbare Datei. Git muss installiert sein; sonst ist für diese Anleitung nichts erforderlich. Laden Sie das Archiv für Ihr Betriebssystem und Ihren Prozessor herunter und entpacken Sie es. Folgen Sie dann den Schritten für Ihr System.

    Öffnen Sie ein Terminal im entpackten Ordner, der probe enthält. Entfernen Sie unter macOS zuerst die Download-Quarantäne des Browsers mit xattr -d com.apple.quarantine probe.

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

    Kein sudo? Installieren Sie stattdessen nach ~/.local/bin, sofern das Verzeichnis existiert und in Ihrem PATH liegt.

    Legen Sie im Datei-Explorer %LOCALAPPDATA%\Programs\probe an und kopieren Sie die entpackte probe.exe hinein. Öffnen Sie dann PowerShell:

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

    Dies setzt PATH für das aktuelle Terminal. Für künftige Terminals fügen Sie denselben Ordner in den Windows-Umgebungsvariablen zu Ihrem Benutzer-Path hinzu.

    Der letzte Befehl gibt die installierte Version aus, zum Beispiel probe v0.5.1. Wie Sie das Archiv mit den veröffentlichten Prüfsummen abgleichen, lesen Sie unter Download überprüfen.

  2. Vergleichen Sie Ihren letzten Commit mit dem vorherigen

    Wechseln Sie in ein beliebiges Git-Repository und fragen Sie Probe, was sich zwischen HEAD~1 und HEAD geändert hat:

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

    lint ist die statische Hälfte von Probe. Es vergleicht die beiden Commits, sammelt Risikosignale und schreibt einen Bericht. Es führt nie Repository-Code aus, ruft nie einen KI-Anbieter auf und benötigt keine .probe.json: Ohne sie gelten die eingebauten Standardwerte für die erkannte Sprache.

    Nur committete Dateien werden analysiert. Nicht committete Änderungen und nicht versionierte Dateien werden ignoriert; committen Sie Ihre Arbeit also zuerst, zum Beispiel auf einem Test-Branch. Um Berichte aus git status herauszuhalten, ohne .gitignore anzufassen, führen Sie echo .probe/ >> .git/info/exclude aus.

  3. Bericht lesen

    Öffnen Sie .probe/CONFIDENCE_REPORT.md in Ihrem Editor. Beginnen Sie mit Suggested Human Review, einer nach Schweregrad sortierten Liste von Datei- und Zeilenbereichen, jeweils mit dem Grund der Markierung:

    ## 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) verweist auf eine Zeile im Kandidaten-Commit und (old) auf eine entfernte Zeile in der Basis. (whole file) kennzeichnet ein Signal zur Datei selbst, etwa einen sensiblen Pfad, statt zu einer ihrer Zeilen. Review Surface gibt an, wie viele geänderte Zeilen diese Bereiche abdecken. Dieselben Daten mit Commit-IDs und Signalnachweisen stehen für Skripte und CI in confidence-report.json.

    Signale sind Gründe, genauer hinzusehen, keine bestätigten Bugs. Die Signalreferenz erklärt jedes einzelne.

  4. Wählen Sie, was verglichen wird

    Zwei beliebige Revisionen funktionieren. Einige gängige Varianten:

    BefehlVergleicht
    probe lint HEAD~5..HEADIhre letzten fünf Commits zusammen.
    probe lint --base mainIhr aktueller Branch gegen main, ab ihrer Merge-Basis, wie ein Pull Request. Verwenden Sie --base master, wenn das Ihr Standard-Branch ist.
    probe lint --base origin/main --head featureEin anderer Branch gegen den Standard-Branch des Remotes, ohne ihn auszuchecken.
    probe lint main..featureDie beiden exakten Commits, ohne Merge-Basis (main...feature verwendet die Merge-Basis).
    probe lint --base main --ciWie oben, endet aber mit Code 2, wenn ein menschliches Review erforderlich ist – für Skripte und CI.

  5. Optional: Prüfungen in einer Sandbox ausführen

    review tut alles, was lint tut, und führt dann die Test-, Typecheck-, Build- und Coverage-Befehle des Repositorys in Wegwerf-Docker-Containern ohne Netzwerk aus. Es benötigt Docker mit Linux-Containern und ein vorab geladenes Image mit Ihrer Toolchain: Probe pullt nie selbst Images und installiert keine Abhängigkeiten. Für ein Go-Projekt ohne Drittanbieter-Abhängigkeiten genügt das Standard-Image:

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

    Bei Node.js-, Python- und Rust-Projekten enthalten die Standard-Images Ihre Abhängigkeiten nicht: Bauen Sie ein Image, das sie enthält, und verweisen Sie in einer Policy mit sandbox.image darauf (nächster Schritt), oder lassen Sie die vertrauenswürdige Policy diese Schicht mit einem prepare-Objekt bauen. Fehlen Docker oder das Image, bricht Probe mit Exit-Code 4 ab und führt niemals ersatzweise Code auf Ihrem Rechner aus.

  6. In Ihrem Repository einführen

    Führen Sie probe init aus, um .probe.json für die erkannte Sprache zu erzeugen. Prüfen Sie die Befehle und das Sandbox-Image und testen Sie die Policy dann lokal:

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

    Committen Sie .probe.json in Ihren Basis-Branch. Nachfolgende Reviews lesen diese vertrauenswürdige Policy. Führen Sie auf Ihrem Feature-Branch aus:

    probe review --base main --ci

    Sie arbeiten mit einem Coding-Agenten? Führen Sie den Plan-first-Prozess ein: Der Agent führt probe plan --intent-file task.md --ci aus, bevor er Code schreibt (ein markierter Plan geht an einen Menschen), setzt den Plan um, und die CI führt probe review --plan .probe/PLAN.json --ci aus. Exit-Code 0 bedeutet, dass die Änderung einem risikoarmen Plan entspricht und ihre Prüfungen bestanden hat, sodass sie ohne menschliches Review gemergt werden kann; Exit-Code 2 nennt die Gründe, warum ein Mensch hinsehen muss (Plan-Gate).

    Nächste Schritte: Alle Flags, Exit-Codes und Policy-Schlüssel finden Sie in der Referenz. Damit ein KI-Reviewer versuchen kann, Probleme zu reproduzieren, konfigurieren Sie einen Anbieter wie unter KI-Reviewer beschrieben. Für GitHub Actions lesen Sie den Leitfaden zur CI-Integration.

  7. Zeigen Sie es in Ihrer README

    Sobald Probe Ihre Pull Requests prüft, fügen Sie das Badge zu Ihrer README hinzu. Es verlinkt auf diese Website und zeigt, dass das Projekt Probe verwendet; es ist keine Freigabe des Codes.

    verified by Probe

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

    HTML, reStructuredText, shields.io-Stile und das Live-Badge von Probe Hub finden Sie im Badge-Leitfaden.

Wenn etwas schiefgeht

MeldungWas zu tun ist
base: git rev-parse … Needed a single revisionEine Revision existiert nicht. Das Repository hat vielleicht nur einen Commit (es gibt also kein HEAD~1), oder sein Standard-Branch heißt nicht main: Übergeben Sie --base master oder einen expliziten Bereich.
Im Bericht fehlen Ihre letzten ÄnderungenSie sind noch nicht committet. Probe analysiert nur Commits; committen Sie sie und führen Sie es erneut aus.
Exit-Code 2Kein Fehler: Mit --ci bedeutet er, dass ein menschliches Review erforderlich ist. Siehe Exit-Codes.
Exit-Code 4 bei reviewDocker läuft nicht oder das Sandbox-Image ist lokal nicht vorhanden. Pullen Sie es zuerst oder verwenden Sie lint.
reviewer.model must be configured…--reviewer wurde ohne Modell angefordert. Lassen Sie es weg oder konfigurieren Sie einen Anbieter.