Finn763/pit-stop

Was macht pit-stop?

F1-Pitstop für Codebasen: reinfahren, reparieren lassen, schneller rauskommen. Eine Anweisung führt Lesen → Suchen → Korrigieren → Prüfen → Berichten aus, ohne Rückfragen während des Laufs. Der Benutzer sagt nur los; du kommst einmal mit einem Bericht zurück.

Der Ablauf (in Reihenfolge, kein Überspringen)

1. Laden: README/AGENTS.md (oder Äquivalent) lesen + git status + Hot Spots der letzten Commits.
   Eine Zeile zuerst schreiben: MODE = was hier als Fund gilt, was kategorisch abgelehnt wird.
   Fehlt ein wichtiger Fakt? Einmal nachfragen, dann strengste Voreinstellungen anwenden.
2. Suchen: Umfang vor dem Scannen eingrenzen (benanntes Ziel > Git-Hot-Spots > vollständiger Baum).
   Jeder Fund benötigt Pfad:Zeile-Beleg. Dokumentierte Entscheidungen überspringen, es sei denn, Reibung rechtfertigt eine Wiedereröffnung. Jeweils taggen: delete/stdlib/native/yagni/shrink/security/obs,
   Stärke Strong/Worth/Speculative. Spekulativ = nur Bericht, niemals korrigieren.
   Nichts gefunden: Sag Lean already. Ship. — niemals aufblähen.
3. Vorschlagen: Nur starke Elemente. Jedes = Symptom + Beleg + Auswirkung + minimale Korrektur + Kosten.
   Dazu eine NOT-doing-Liste mit Auslösebedingungen.
4. Korrigieren: Review→Fix-Schleife mit einem unabhängigen Prüfer (anderer Blickwinkel besser als gleiche Augen);
   anhalten bei sauberem Code oder --max-rounds (Standard 3). Rundenübergreifendes Register, keine wiederholten Korrekturen.
   Zwei stagnierende Runden → Eskalation zu „menschliches Eingreifen nötig“, anhalten. Siehe references/guardrails.md.
5. Berichten: Kopfzeile Vollständig automatisch von pit-stop erstellt. Vier Blöcke —
   geändert / verifiziert (Tool-Ausgabe) / unverifiziert / verbleibend. Keine Behauptung ohne frische
   Tool-Ausgabe. Geheimnisse/Tokens/PII in allem, was eingefügt wird, schwärzen. Siehe templates/report.md.

Eiserne Regeln

• Beleg vor Behauptung, immer. Kein Verifikationslauf in dieser Runde = kein Erfolgsanspruch.
• „Fertig“ eines Unteragenten ist nicht fertig. Sein Diff vor dem Berichten lesen.
• Unklare Stellen herabstufen, niemals raten. „Menschliches Eingreifen nötig“ schreiben, weitermachen.
• Push/Commit niemals automatisch. Änderungen bleiben im Arbeitsverzeichnis auf ein einziges explizites Wort.
• Einzige Ausgabensicherung: Eine Phase, die mehr als 20 $ verbraucht → Phase stoppen, Bericht schreiben.

Details: references/phases.md, references/guardrails.md, references/verification.md.