Das Outcome-Gate und Nachweise

kanman verlässt sich nie auf die Aussage des Executors. Das Outcome-Gate belegt jede Story gegen ihre Akzeptanz-Spec, das Nachweispaket zeigt den Beleg.

Coding-Agents können gut behaupten, fertig zu sein. Mit dem Outcome-Gate prüft kanman, ob das stimmt. Der Executor erklärt eine Story nie selbst für abgeschlossen: kanman führt die Gates selbst aus, auf Infrastruktur, die der Executor nicht kontrolliert, und verschiebt die Story erst, wenn die Gates bestanden sind. Alles, was geprüft wurde, steht anschließend im Nachweispaket am Pull Request.

Die Gates

Jede abgesicherte Bewegung einer Story hat ihre eigenen Prüfungen:

Bewegung Gates
Verfeinerung nach Bereit spec_red, spec_honest: Die Akzeptanz-Spec liegt auf dem geschützten Pfad, läuft, schlägt aktuell fehl und mockt ihr eigenes Ziel nicht
In Arbeit nach Review diff_guard, policy_diff, spec_green_ephemeral: Kein Commit des Executors hat die Akzeptanz-Spec berührt, der Diff hält gesperrte Pfade und Größengrenzen ein, und die Spec besteht in einer frisch bereitgestellten Umgebung
Review nach Fertig ci, reviewer, clean_room: Die CI ist grün, der Reviewer-Run hat jedes Kriterium bestätigt, und die Spec besteht auf einem Clean-Room-Checkout, die Nachweis-Artefakte sind gespeichert. Dann ist der Pull Request mergebar oder wird automatisch gemergt, wenn die Richtlinie das erlaubt

Neue Commits am Pull Request während des Reviews werden erneut geprüft; sie verschieben die Story nie von selbst.

kanman führt jede abgesicherte Bewegung selbst aus. Verschiebt jemand eine Story nach Bereit, auf der Team-Seite oder im Tracker, legt kanman sie zuerst in die Verfeinerung und führt das Gate für Bereit aus; die Karte zeigt Akzeptanzspezifikation wird geprüft, bis die Spec wie erwartet fehlschlägt. Bewegungen aus späteren Spalten zurück nach Bereit erfolgen direkt, weil diese Stories die Prüfung schon bestanden haben.

Auf Ihrem Git-Host meldet kanman das Ergebnis als Commit-Status kanman/outcome-gate. Machen Sie ihn in Ihrem Branch-Schutz zum Pflicht-Status, damit ein Pull Request nicht gemergt werden kann, bevor das Gate bestanden ist.

Rot vor Ready

Eine Spec, die schon besteht, bevor Code geschrieben wurde, testet das neue Verhalten nicht. Wenn kanman die Spec aus dem Demonstrate-Block der Story schreibt, bleibt die Story deshalb in der Verfeinerung, bis die Spec läuft und fehlschlägt. Die Story-Seite zeigt dann Spec: rot (erwartet), kanman committet die Spec auf den Branch kanman/spec/<KEY>, und die Story wandert nach Bereit.

Kann kanman keine funktionierende Spec schreiben, versucht es das einmal erneut mit der Gate-Ausgabe. Scheitert auch das, bittet Sie eine Entscheidung Prüfschritt fehlgeschlagen, den Demonstrate-Schritt zu verbessern und es erneut zu versuchen oder die Story in der Verfeinerung zu lassen.

Ehrliche Specs

Eine Spec muss das Echte testen. Eine statische Prüfung lehnt Specs ab, die ihr eigenes Ziel mocken, etwa durch Route-Interception, MSW, nock oder Modul-Mocks, noch bevor die Spec läuft. Mocks von Diensten Dritter sind erlaubt. Die Story bleibt dann in der Verfeinerung, mit einem Grund wie Die Spezifikation mockt ihr eigenes Ziel: Route-Interception von /api/invoices.

Der Diff-Wächter

Die Akzeptanz-Spec liegt auf einem geschützten Pfad, .kanman/acceptance/<KEY>/. Executors dürfen sie nie ändern: Der Pfad ist in jedem Preset gesperrt und lässt sich nicht freigeben. Berührt ein Commit der Umsetzung ihn trotzdem oder passt der Spec-Ordner nicht mehr zur bei Bereit freigegebenen Fassung, stoppt der Run mit Diff-Wächter: Die Akzeptanzspezifikation wurde von der Umsetzung geändert, kein Pull Request wird als mergebar markiert, und der Entscheidungseingang bietet Revert spec changes and retry oder Reject an. kanman setzt die Commit-Autorschaft außerdem selbst und weiß so, welche Commits vom Executor stammen.

Clean-Room-Prüfung

Die abschließende Prüfung läuft nie im Arbeitsverzeichnis des Executors. kanman checkt den Branch frisch aus, stellt die freigegebene Spec wieder her, stellt eine neue Umgebung bereit, wie Ihr Akzeptanz-Manifest es beschreibt, und führt die Spec dort aus. Traces, Screenshots, Videos oder Apply-Logs werden als Nachweis gespeichert. Eine grüne Spec ohne gespeicherte Artefakte zählt nicht.

Gate-Referenz

Gate-ID Prüft
spec_red Die Spec schlägt vor der Änderung fehl
spec_honest Die Spec mockt ihr eigenes Ziel nicht
spec_green_ephemeral Die Spec besteht in einer frisch bereitgestellten Umgebung
diff_guard Kein Commit des Executors hat .kanman/acceptance/ berührt, und die Spec ist seit Bereit unverändert
policy_diff Gesperrte Pfade, max_changed_files und max_changed_lines am finalen Diff
clean_room Die Spec besteht auf einem frischen Checkout in einer frischen Umgebung, mit Nachweis-Artefakten
ci Ihre CI-Pipeline ist grün. Solange die CI noch läuft, wartet kanman
reviewer Ein unabhängiger Reviewer-Run hat jedes Kriterium gegen den Diff geprüft
verify_local Der lokale Prüfbefehl aus .kanman/verify.json war erfolgreich. Läuft noch nicht, siehe dort

Jedes Gate-Ergebnis hat ein Urteil (pass, fail, error oder skipped), einen Grund und Links zu seinen Artefakten. Die Ergebnisse stehen im Audit-Log als gate_passed oder gate_failed.

Das zweite Signal: der Reviewer-Run

Zusätzlich zur Spec prüft ein Reviewer-Run jedes Akzeptanzkriterium gegen den Diff, mit Datei- und Zeilenangaben, und markiert Scope-Creep. Ein Kriterium ohne Codeverweis besteht nicht. Der Reviewer nutzt ein Modell des anderen Anbieters (ein Codex-Modell, wenn Claude Code den Code geschrieben hat, und umgekehrt), der Code wird also nie von dem Modell geprüft, das ihn geschrieben hat. Sein Ergebnis pro Kriterium wird in die Story zurückgeschrieben.

Wenn ein Gate fehlschlägt

  1. kanman startet einen automatischen Nacharbeitsversuch und gibt dem Executor die Gate-Ausgabe und die Befunde des Reviewers mit (rework_attempts).
  2. Scheitert auch dieser Versuch, landet die Story als Prüfung fehlgeschlagen im Entscheidungseingang, mit kanmans Empfehlung und Optionen.
  3. Jedes Gate hat ein Fehlerbudget (gate_failure_budget, standardmäßig 3), gezählt über alle Runs der Story. Ist es aufgebraucht, wird der Run mit Wiederholt fehlgeschlagene Prüfung geparkt, und Sie entscheiden, wie es weitergeht.
  4. Ein fehlgeschlagener Diff-Wächter wird nie automatisch nachgebessert; er fragt immer.

Probleme der Testumgebung selbst (Klonen, Bereitstellung, Bereitschaftsprüfung, Setup) werden still zweimal wiederholt und zählen nicht gegen das Fehlerbudget.

Ein fehlgeschlagenes Gate wird nie zur Endlosschleife.

Das Nachweispaket

Bestehen die Gates im Review, schreibt kanman das Nachweispaket. Es wird am Run gespeichert, auf der Run-Seite angezeigt und je einmal als Kommentar am Pull Request und im Tracker veröffentlicht. Es enthält:

  • den Plan und die erwogenen Lösungsansätze
  • die Akzeptanzkriterien, jedes bestanden, fehlgeschlagen oder unklar, mit Datei- und Zeilenangaben
  • die Gate-Ergebnisse mit ihren Gründen und Links zu Traces, Screenshots und Logs
  • Testzahlen und den CI-Link
  • Kosten im Verhältnis zum Budget, Dauer und Zahl der Versuche
  • ob ein Ergebnisnachweis vorliegt

Die Run-Seite listet außerdem die Richtlinien-Entscheidungen während des Runs.

Ein gekürztes Beispiel, wie es am Pull Request erscheint (der Kommentar zeigt vor jeder Zeile ein Statuszeichen):

Evidence: SBX-12 (run-7f3k)

The acceptance spec passed in a clean environment.

Plan
Add GET /invoices/export with a date-range filter and a CSV serializer.

Acceptance criteria
- Passed ac-1 Given a customer with 3 invoices in March ... (src/invoices/export.ts:42)
- Passed ac-2 Given ... (src/invoices/export.ts:61, src/invoices/csv.ts:12)

Checks
- Passed spec_green_ephemeral: Spec passed in a fresh environment [1]
- Passed diff_guard: The implementation did not touch the acceptance spec
- Passed policy_diff: The change stays within the team policy
- Passed ci: CI passed
- Passed reviewer: All 2 criteria passed review
- Passed clean_room: Spec passed on a clean checkout [1] [2]

Tests: 12 passed, 0 failed
CI: success
Cost: €0.84 / €2.00 · Duration: 11 min · Attempts: 1

Die Run-Seite zeigt das Nachweispaket in Ihrer Sprache. Die Kommentare am Pull Request und im Tracker sind derzeit auf Englisch.

Repositories ohne Manifest

Ohne Akzeptanz-Manifest gibt es keine Spec, die laufen könnte. Das erlaubt nur das Preset Testphase, damit Sie einen Pilot starten können, bevor das Manifest steht. kanman stützt sich dann auf CI, Testplan und Reviewer-Run, vermerkt die Spec-Gates als übersprungen, und das Nachweispaket sagt klar: Es lief keine Akzeptanzspezifikation, das Ergebnis ist also nicht nachgewiesen. Bitte die Änderung sorgfältig prüfen. Mit jedem anderen Preset bleibt eine Story in einem Repository ohne Manifest in der Verfeinerung. Mit einem Manifest bekommen Sie das vollständige Gate, siehe Ein Akzeptanz-Manifest anlegen.

Tipp

Das Repository der Pilot-Sandbox bringt ein Manifest mit. Im Quickstart sehen Sie das vollständige Gate in Aktion, bevor Sie es für Ihren eigenen Code einrichten.

Verwandte Seiten

Zuletzt aktualisiert: January 1, 0001

kanman öffnen