Archived

This repository has been archived on 2026-09-17. You can view files and clone it, but you cannot make any changes to its state, such as pushing and creating new issues, pull requests or comments.

pijukka 05575df408 docs: commit backlog of already-resolved intent/review corpus files

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

2026-09-10 12:06:53 +02:00

4.5 KiB

Raw Permalink Blame History

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.

4.5 KiB Raw Permalink Blame History