So läuft eine Story | kanman Dokumentation

Jede Story in kanman nimmt denselben Weg. Diese Seite begleitet eine Beispiel-Story durch alle fünf Stufen: den Kundenwunsch, Rechnungen als CSV zu exportieren.

Aufnahme Aus der Anforderung werden Stories mit Akzeptanzkriterien. Sie geben frei.
Dispatch Richtlinien-Check: Repos, Pfade, Budget, Arbeitszeiten, Parallelität.
Ausführung Claude Code oder Codex arbeitet in einer Sandbox auf eigenem Branch.
Prüfung Akzeptanz-Spec auf frischem Checkout, CI, unabhängiger Reviewer. Scheitert sie, folgt eine automatische Nachbesserung.
Übergabe Pull Request mit Nachweispaket. Ein Mensch prüft und mergt.
Entscheidungseingang blockiert, unklar oder zweimal gescheitert: kanman hält an und fragt.

So läuft eine Story durch kanman

1. Aufnahme: von der Anforderung zu Stories

Am Anfang steht eine Anforderung, in welcher Form auch immer sie kommt: ein Absatz im Reiter Anforderungen des Teams oder ein Slack-Thread, in dem kanman erwähnt wird.

Customers need to export their invoices as CSV, filtered by date range.

kanman entscheidet zuerst, um welche Art Nachricht es sich handelt. Nur Arbeitsaufträge werden zu Stories; eine Statusfrage wird im Chat beantwortet, und eine Antwort auf eine offene Frage geht an die zugehörige Entscheidung. Dann entwirft kanman kleine Stories. Jede enthält:

Akzeptanzkriterien im Given/When/Then-Format
einen Demonstrate-Block: einen konkreten Weg, das Ergebnis zu zeigen, zum Beispiel “öffne /invoices, wähle März, klicke auf Download CSV, die Datei hat die Spalten date, number, amount”
einen Testplan, eine Größe (S, M oder L), die betroffenen Bereiche im Code und offene Fragen

Sie bearbeiten, verwerfen oder geben jeden Entwurf frei. Freigegebene Stories werden gesammelt in Ihren Tracker geschrieben und für kanman markiert. Mehr unter Stories und Akzeptanzkriterien.

Vor Ready: eine Spec, die fehlschlägt

Hat das Repository ein Akzeptanz-Manifest, macht kanman aus dem Demonstrate-Block eine ausführbare Akzeptanz-Spec unter .kanman/acceptance/<KEY>/ und führt sie aus. Die Story darf erst nach Ready, wenn die Spec läuft und fehlschlägt, denn die Funktion gibt es noch nicht. Eine Spec, die schon besteht, oder eine, die genau das mockt, was sie testen soll, hält die Story mit einer klaren Erklärung in Refining.

2. Dispatch: der Richtlinien-Check

Liegt eine Story in der Spalte Ready und trägt das Übernahme-Label (standardmäßig kanman), übernimmt kanman sie und prüft die Richtlinie des Teams:

Ist das Team aktiv und nicht pausiert?
Ist das Team innerhalb seiner Arbeitszeiten und unter seiner Grenze paralleler Runs?
Ist noch Tages- und Monatsbudget übrig?

Passt alles, startet ein Run. Wenn nicht, wartet die Story in Ready, bis sie starten kann. Während des Runs prüft kanman Repository und Branch, gesperrte Pfade und die Größe der Änderung und holt die Plan-Freigabe ein, wenn die Richtlinie sie verlangt. Diese Fragen landen im Entscheidungseingang.

3. Ausführung: der Coding-Agent bei der Arbeit

kanman startet Claude Code oder Codex in einer isolierten Sandbox mit einem Klon des Repositorys, einem eigenen Branch und nur den Zugriffen, die die Richtlinie erlaubt. Der Agent spricht über eine kleine Zahl von Tools mit kanman: Er liest die Story, meldet Fortschritt, den Sie live auf der Run-Seite sehen, prüft die Richtlinie, bevor er einen Pfad anfasst, und fragt einen Menschen, wenn er unsicher ist. Fragen landen im Entscheidungseingang und pausieren den Run, bis jemand antwortet.

Die Run-Seite zeigt die Stufen Planung, Umsetzung, Prüfung, Review und Fertig mit Live-Fortschritt und einer Kostenanzeige gegen das Run-Budget. Siehe Runs.

4. Prüfung: das Outcome-Gate

Der Coding-Agent erklärt seine Arbeit nie selbst für fertig. kanman führt die Gates aus und verschiebt die Story selbst:

die Akzeptanz-Spec muss gegen eine frisch bereitgestellte Umgebung bestehen
kein Commit des Agenten darf die Akzeptanz-Spec ändern, und gesperrte Pfade und Größengrenzen werden am finalen Diff erneut geprüft
dann wandert die Story nach Review, wo die Spec auf einem frischen Checkout erneut bestehen muss, die CI grün sein muss und Nachweis-Artefakte gespeichert werden
ein unabhängiger Reviewer, auf einem Modell eines anderen Anbieters als dem, das den Code geschrieben hat, prüft jedes Akzeptanzkriterium gegen den Diff, mit Datei- und Zeilenangaben

Scheitert ein Gate, bekommt der Agent einen Nacharbeitsversuch mit der Gate-Ausgabe und den Befunden des Reviewers. Scheitert auch dieser, geht die Story in den Entscheidungseingang statt in eine Schleife. Siehe Das Outcome-Gate und Nachweise.

5. Übergabe: ein Pull Request mit Nachweis

Der Pull Request wird auf dem Branch des Runs geöffnet, während die Story in Arbeit ist. Bestehen die Prüfungen im Review, veröffentlicht kanman das Nachweispaket als je einen Kommentar im Pull Request und im Tracker-Issue und setzt den Status kanman/outcome-gate des Pull Requests auf bestanden:

den Plan und eventuell erwogene Ansätze
jedes Akzeptanzkriterium mit bestanden oder nicht bestanden und der zugehörigen Code-Stelle
Gate-Ergebnisse mit Links zu Artefakten wie Playwright-Traces und Screenshots
Testzahlen und den CI-Link
Kosten, Dauer und die Zahl der Versuche

Ein Mensch prüft und mergt, und die Story wandert nach Fertig. Erlaubt Ihre Richtlinie es, werden kleine, geprüfte Änderungen automatisch gemergt.

Wo kanman anhält und fragt

kanman handelt nur dort selbstständig, wo Ihre Richtlinie es erlaubt. Drei Stufen legen fest, was passiert:

Stufe	Was kanman tut	Beispiele
AUTO	Handelt still; die Aktion steht im Audit-Log.	Akzeptanzkriterien schreiben, ein Duplikat verknüpfen
NOTIFY	Handelt und hält einen Hinweis fest.	Eine Story aufteilen, einen im Kreis laufenden Run pausieren
ESCALATE	Hält an und fragt, mit Empfehlung und 2 bis 4 Optionen.	Einen Plan freigeben, einen gesperrten Pfad anfassen, mehr als das Budget ausgeben, mergen

Jede Entscheidung, Freigabe und Statusänderung landet mit wer, was und wann im Audit-Log. Siehe Richtlinien, Presets und Befugnisstufen.

Ausprobieren

Der Quickstart führt genau diese Rechnungs-Story auf einem öffentlichen Beispiel-Repository aus, von der Anforderung bis zum geprüften Pull Request.