# Intent: Automatische Korrekturschleife nach negativem Review

## Ziel

Nach einer negativen Review-Entscheidung („zurück zur Planung" /
`planung_mit_feedback`) automatisch bis zu einer festen, engen Obergrenze
(2 Versuche) einen neuen Builder-Lauf mit strukturierter Korrekturübergabe
anstoßen, statt wie bisher auf eine bewusste manuelle Folgeaktion zu
warten. Dies **kehrt bewusst eine bestehende Sicherheitsregel um**, die
heute ausdrücklich in `agents/reviewer.md` steht.

## Umfang

- `agents/reviewer.md`: Der Satz „Du startest dabei keine automatische neue
  Planner-Session und stößt keine automatische Builder-Korrektur an — das
  bleibt eine bewusste, von lukas ausgelöste Folgeaktion" wird durch eine
  neue Regel ersetzt: bei `zurück zur Planung` liefert der Reviewer
  zusätzlich zum Freitextbericht ein strukturiertes Korrekturfeld-Set
  (`severity`, `file`, `problem`, `acceptance_check`) in einem
  maschinenlesbaren Marker-Block.
- Board-Worker/Completion-Watcher: Bei `planung_mit_feedback` und einem
  Korrekturzähler unter dem Limit automatisch einen neuen Builder-Job mit
  der strukturierten Übergabe als Kontext einreihen; die Karte wechselt
  automatisch zurück nach „In Umsetzung", aber mit einem eigenen
  sichtbaren Zustand/Badge (z. B. „automatisch erneut versucht,
  Versuch 2/2"), erkennbar getrennt von einem bewussten Nutzer-Trigger.
- Jeder automatische Korrekturversuch bekommt einen frischen Worktree/
  Branch (nutzt `board-builder-worktree-parallelism.md`), nicht den alten
  Zwischenstand.
- Zähler für automatische Korrekturversuche pro Karte in `state.json`
  (`auto_correction_attempts`); nach Erreichen des Limits (2) bleibt die
  Karte wie heute in „Planung mit Feedback" für manuelles Eingreifen.

## Explizit ausgeschlossen

- Kein unbegrenzter Loop — harte Obergrenze von 2 automatischen Versuchen
  pro Karte.
- Keine automatische Planner-Session — nur der Builder-Korrekturlauf wird
  automatisiert, nicht die Bedarfsklärung.
- Keine Änderung an Reviewer-Prüftiefe oder -methode selbst, nur an der
  Übergabe nach einer negativen Entscheidung.
- Kein zusätzliches automatisches Push/Merge/Deployment über das heute
  schon bestehende Builder→Review-Verhalten hinaus.
- Keine Änderung an nicht board-getriggerten Reviews (freie Diff-Review,
  Systemaudit) — nur der Board-Pfad ändert sich.

## Annahmen

- Ein strukturiertes Feld-Set lässt sich zuverlässig aus dem
  Reviewer-Markerblock extrahieren, ähnlich wie heute schon
  `===REVIEW-REPORT===` geparst wird.
- Zwei automatische Versuche sind ein sinnvoller Kompromiss zwischen
  Nutzen und Ressourcenrisiko; der Wert kann sich in der Praxis noch
  ändern.
- `board-builder-worktree-parallelism.md` ist umgesetzt, bevor dieser
  Intent produktiv genutzt wird.

## Offene Risiken

- **Bewusste Umkehr einer Sicherheitsregel:** Die Änderung muss im
  Rollentext klar als bewusste, begründete Ausnahme markiert werden, nicht
  stillschweigend gestrichen werden.
- Auch mit Limit 2 verbraucht ein hartnäckig scheiternder Fall bis zu 3
  volle Builder-Läufe (Original + 2 Korrekturen) plus 3 Reviews
  unbeaufsichtigt — bei laut Reviewer-Kriterien „riskanten" Diffs (Secrets,
  Netzwerk/Firewall/sshd/Auth, systemd-Units, mehr als 10 Zeilen/mehrere
  Dateien) ist unklar, ob Auto-Retry dort überhaupt greifen soll; eine
  Sonderregel „kein Auto-Retry bei riskantem Diff" ist zu erwägen, aber
  noch nicht entschieden.
- Zwei aufeinanderfolgende automatische Nix-Builds/Checks auf blunix
  wiederholen das VPS-Ressourcenrisiko aus
  `board-builder-worktree-parallelism.md`, auch nacheinander statt
  parallel.
- Board-Reviews laufen laut `catalog.json` mit dem günstigen Profil
  `gpt-5.6-luna`/`none` — ob dieses Profil zuverlässig strukturierte Felder
  statt nur Freitext liefert, ist ungeprüft.

## Erfolgskriterien

- Nach `zurück zur Planung` erzeugt der Reviewer zusätzlich zum
  Freitextbericht ein strukturiertes Korrekturfeld-Set.
- Bis zu 2 automatische Korrekturversuche laufen ohne manuelles
  Eingreifen, jeweils mit frischem Worktree und der strukturierten
  Übergabe als Kontext.
- Nach dem zweiten erfolglosen Versuch bleibt die Karte im heutigen
  Zustand „Planung mit Feedback" für manuelles Eingreifen.
- Die Karte zeigt während eines automatischen Korrekturversuchs einen
  eigenen erkennbaren Zustand/Badge, unterscheidbar von einem manuellen
  Trigger.
- `agents/reviewer.md` benennt die Regeländerung ausdrücklich und
  begründet die Ausnahme von der bisherigen Regel.