05575df408
board-agent's own README documents docs/intent/ and docs/research-intent/ as tracked corpus directories, and docs/review/<slug>.md as the reviewer's persisted report per card - but the pipeline only writes these files to the checkout, it never commits them itself. This had built up a backlog of intent/review docs for cards already marked deployed or archiviert in the live board state, which were sitting uncommitted in the working tree. Adds that backlog as-is: the originating intents, their reviewer reports, the research-intent/research pair for the board UX evaluation, and one standalone process-retrospective report (board-review-pipeline-context- overhead.md, same genre as the two already-tracked audit reports in docs/review/). No code changes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T7UVrKsttMP9a6FiGFna9b
91 lines
4.5 KiB
Markdown
91 lines
4.5 KiB
Markdown
# 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.
|