--- name: bugsweep version: 1.1.0 type: protocol author: Lukas Geiger created: 2026-06-01 updated: 2026-06-13 description: > Systematischer Bug-Sweep mit codebase-skaliertem Zielwert, Verdoppelungs-Eskalation, Bereichs-Tracking und Abschluss-Verifikation. Nutze bei /bugsweep oder wenn der User einen systematischen Bug-Durchlauf verlangt. standalone: true anthropic_compatible: true bach_compatible: true bach_origin: false category: dev tags: [bugs, debugging, sweep, qualitaetssicherung, workflow, konvergenz] language: de status: active dependencies: tools: [] services: [] protocols: [bugfix-protocol] python: [] provenance: origin: "custom" origin_path: "~/.claude/skills/bugsweep/" origin_version: "1.0.0" last_sync_from_origin: "2026-06-13" last_sync_to_origin: null local_changes_since_sync: false --- # /bugsweep — Systematischer Bug-Sweep Workflow Iterative Bug-Suche mit konvergierendem Abbruchkriterium. Skaliert mit der Codebasis, eskaliert bei Verdacht auf oberflächliche Suche, und verhindert Wiederholung durch Bereichs-Tracking. ## 1. Grundrate berechnen ``` LOC = produktive Quellzeilen (src/, lib/ — ohne Tests, Configs, Docs, generated) x = max(1, ceil(LOC / 1500)) Grundrate = x * 3 ``` | LOC | x | Grundrate | |-----|---|-----------| | ~1500 | 1 | 3 | | ~3000 | 2 | 6 | | ~4500 | 3 | 9 | | ~10000 | 7 | 21 | Melde dem User: "Codebasis: {LOC} LOC → Grundrate = {Grundrate} saubere Suchläufe." ## 2. Suchschleife ``` zähler = 0 ziel = Grundrate je_bug_gefunden = False geprüft = [] # (bereich_name, typ: code|aufgabe) LOOP: bereich = wähle_neuen_bereich() # Siehe Bereichs-Regeln geprüft.append(bereich) Führe gründliche Bug-Suche durch IF Bug gefunden: je_bug_gefunden = True Fix nach bugfix-protocol (Phase 4+5) Review: siehe Modell-Regel (neuere Modellklassen: kein externer Review nötig) Commit + Push zähler = 0 # RESET ELSE: zähler += 1 Melde: "✓ Sauber: {bereich} — {zähler}/{ziel}" IF zähler >= ziel: IF NOT je_bug_gefunden: # Verdoppelungs-Eskalation: kein einziger Bug → zu oberflächlich? ziel = Grundrate * 2 je_bug_gefunden = True # Eskalation nur EINMAL Melde: "⚠ Kein Bug in {Grundrate} Läufen → Ziel verdoppelt auf {ziel}." CONTINUE LOOP ELSE: GOTO Abschluss-Verifikation ``` ### Praxis-Hinweise zur Suchschleife (aus Sweeps gelernt) - **Nicht-Git-Repos:** Wo es kein `git` gibt (z. B. Cloud-synchronisierte Projektordner), ersetzt ein **versioniertes Backup** das "Commit + Push": vor dem ersten Fix `datei_.bak` anlegen. **Achtung — das Pre-Fix-Backup ist KEINE Sicherung der Arbeit:** nach dem letzten Fix ein frisches `_FINAL_`-Backup ziehen, sonst ist bei einem Sync-Hiccup die gesamte Fix-Arbeit verloren. - **Viele vorab bekannte Bugs:** Sind beim Start schon N Bugs bekannt (z. B. aus einem vorherigen Lauf), ist "pro Bug: Fix → Review → Commit → Reset" unpraktikabel. Dann die bekannten Bugs als EINEN Fix-Block abarbeiten (gemeinsamer Review am Ende) und die Grundrate/Suchschleife ab dem ersten NEU gefundenen Bug zählen. Die Reset-Logik gilt weiter für während des Sweeps neu gefundene Bugs. - **Gleicher Bug an mehreren Stellen:** Ein gefundener Fehler (z. B. ein falsches Regex, eine kaputte Format-Annahme) steckt oft kopiert an weiteren Stellen. Nach jedem Fix per Suche prüfen, ob dasselbe Muster anderswo vorkommt — das ist ein eigener, lohnender "Bereich". ## 3. Bereichs-Regeln (Anti-Gaming) Ein "Bereich" ist entweder ein **Code-Fokus** oder eine **Aufgabe** (Zweck des Codes). ### Code-Fokus - Darf zwischen Läufen **erweitert** (mehr Dateien) oder **verschoben** (anderer Teil) werden - Darf NICHT exakt dieselbe Auswahl sein wie in einem früheren Lauf - Beispiel OK: Lauf 1 = `maintenance.py`, Lauf 5 = `maintenance.py + orchestrator.py` (erweitert) - Beispiel NICHT OK: Lauf 1 = `maintenance.py`, Lauf 5 = `maintenance.py` (identisch) ### Aufgabe (Zweck) - Darf **granulärer** gestellt werden (Subfunktion prüfen) oder **breiter** (zusammenhängende Funktionen) - Darf NICHT exakt dieselbe Aufgabe sein - Beispiel OK: Lauf 1 = "Thread-Safety im Watchdog", Lauf 5 = "Thread-Safety Tray gesamt" (breiter) - Beispiel OK: Lauf 1 = "Prozesserkennung", Lauf 5 = "Store-Marker-Matching in Prozesserkennung" (granulärer) - Beispiel NICHT OK: Lauf 1 = "Thread-Safety im Watchdog", Lauf 5 = "Thread-Safety im Watchdog" (identisch) ### Benennung - Bereich MUSS VOR der Suche benannt werden (kein nachträgliches Zuordnen) - Format: `"{Name}" ({typ}: code|aufgabe)` ## 4. Abschluss-Verifikation Nachdem zähler >= ziel UND je_bug_gefunden: **Schritt A — bugfix-protocol Phase 5:** - [ ] Vollständige Test-Suite grün (`pytest`) - [ ] **Geänderten Ausführungspfad mindestens einmal REAL durchlaufen** — nicht nur Tests. Grüne Unit-Tests an Code, der die geänderte Stelle gar nicht aufruft, sind Scheinsicherheit. Den tatsächlich geänderten Pfad ausführen (Dry-Run, Smoke-Lauf, CLI-Aufruf) und auf Tracebacks / Signatur- / Namensfehler prüfen. `py_compile` bzw. Import allein prüft NUR Syntax — nicht, ob der Pfad läuft. - [ ] **Jeder Fix hat mind. einen Test, der ihn berührt** — ein Fix ohne Test, der die geänderte Verzweigung tatsächlich auslöst, gilt als ungeprüft (für Orchestrierungs-/Netzwerkpfade ggf. mit Mock + Dry-Run kombinieren). - [ ] Type-Check (wenn konfiguriert) - [ ] Lint (wenn konfiguriert) - [ ] Edge Cases der Session-Fixes geprüft **Schritt B — Review (Modell-Regel):** - **Neuere Modellklassen (z.B. Claude 5 / Fable-Klasse):** KEIN externer Advisor-/Zweitmodell-Review erforderlich. Schritt A (Tests + realer Smoke-Lauf) ist die Verifikation. Optional bei echter Unsicherheit: frischer Review-Subagent — dessen Befunde aber empirisch gegenprüfen (Test gegen unveränderten Code), bevor sie als Bug gewertet werden. Hintergrund (Sweep-Erfahrung 2026-06-11): Der Zweit-Reviewer war nicht verfügbar, der Ersatz-Subagent lieferte 1 Befund (Konfidenz 85), der sich per Test als Nicht-Bug erwies — externer Review änderte das Ergebnis nicht. - **Ältere Modelle:** Abschließende Besprechung mit Advisor (Fallback: zweites Modell als Reviewer); Advisor bestätigt oder findet Lücken. **Bei Bug-Fund in Verifikation:** → Fix + Test + Commit → RESET: zähler = 0, ziel = Grundrate (frisch, KEINE Verdoppelung) → Zurück zur Suchschleife (geprüft-Liste bleibt, je_bug_gefunden = True) **Bei sauberer Verifikation:** → FERTIG. Commit + Push. Protokoll ausgeben. ## 5. Protokoll (am Ende) ```markdown ## Bug-Sweep Ergebnis - **Codebasis:** {LOC} LOC - **Grundrate:** {Grundrate} (eskaliert: {ziel}) - **Geprüfte Bereiche:** {len(geprüft)} - **Bugs gefunden:** {anzahl} - **Resets:** {anzahl_resets} - **Verdoppelung ausgelöst:** ja/nein - **Fixes:** - {titel} — {commit_hash} - ... - **Finale Test-Suite:** {passed}/{total} grün - **Review-Verdict:** Selbstverifikation (neuere Modellklasse) / Advisor bestätigt / Lücken benannt ``` ## Wann diesen Workflow nutzen - Nach Feature-Entwicklung (Qualitätssicherung) - Vor einem Release (Abnahme-Sweep) - Periodisch als Hygiene-Check - Wenn der User `/bugsweep` tippt ## Interaktion mit anderen Skills - **bugfix-protocol:** Fix-Verfahren (Phase 4+5) für jeden gefundenen Bug - **systematic-debugging:** Bei schwer reproduzierbaren Bugs innerhalb des Sweep - **code-review:** Kann als Aufgaben-Bereich genutzt werden --- ## Changelog ### 1.1.0 (2026-06-13) - Modell-Regel für Schritt B zurückportiert (aus lokaler Skill-Installation, Stand 2026-06-11): neuere Modellklassen verifizieren per Tests + realem Smoke-Lauf selbst, kein externer Review nötig; Protokoll-Feld "Review-Verdict" entsprechend erweitert ### 1.0.0 (2026-06-13) - Erstveröffentlichung in der Skill-Bibliothek (übernommen aus lokaler Skill-Installation, Stand 2026-06-01)