Runs | kanman Dokumentation

Ein Run beginnt, wenn eine bereite Story übernommen wird, und endet, wenn die Story fertig ist oder er endgültig anhält. Unterwegs kann er anhalten, um Sie zu fragen. Alles dazu steht auf der Run-Seite: die Stufen, der Live-Fortschritt, die Versuche, die Kosten im Verhältnis zum Budget, die Nachweise und die Entscheidungen, die der Run ausgelöst hat.

Sie öffnen einen Run über die Story-Karte auf der Team-Seite, über den Reiter Runs im Team oder direkt unter app.kanman.ai/<workspace>/teams/<team>/runs/<run-key>. Run-Schlüssel sind kurz, zum Beispiel run-7f3k.

Screenshot folgt Run-Seite mit Stufen-Zeitleiste, Live-Fortschrittszeilen, Kostenanzeige gegen das Run-Budget und dem Nachweispaket

Stufen

Jeder Run durchläuft dieselben Stufen:

Stufe	Was passiert
Planung	kanman ordnet die Story ein und plant. Verlangt die Richtlinie eine Plan-Freigabe, plant der Executor nur lesend, und der Plan geht zuerst in den Entscheidungseingang
Umsetzung	Der Executor (Claude Code oder Codex) ändert den Code auf einem eigenen Branch in einer Sandbox
Prüfung	kanman führt die ersten Gates aus: die Akzeptanz-Spec in einer frisch bereitgestellten Umgebung, den Diff-Wächter und die Richtliniengrenzen am Diff
Review	Der Pull Request ist offen. CI, der Reviewer-Run und die Clean-Room-Prüfung laufen; bestehen sie, veröffentlicht kanman das Nachweispaket, und der Pull Request wird mergebar
Fertig	Gemergt, von einem Menschen oder automatisch, wenn die Richtlinie es erlaubt

Der Executor meldet seinen Fortschritt während der Arbeit. Diese Zeilen erscheinen live auf der Run-Seite, zum Beispiel “Reading the invoices module”. Die Run-Seite listet nur die Stufen, die ein Run erreicht hat; die nächsten erscheinen als bevorstehend.

Status

Karten und Run-Seite zeigen einen Status pro Run:

Status	Bedeutung
In der Warteschlange	Wartet auf einen freien Platz, auf die Arbeitszeiten oder auf Budget
Planung, Umsetzung, Prüfung, Review, Fertig	Die Stufe, in der der Run ist
Wartet auf eine Entscheidung	Angehalten, bis jemand eine Entscheidung beantwortet
Durch Richtlinie blockiert	Von der Richtlinie gestoppt, zum Beispiel durch einen gesperrten Pfad; eine Entscheidung wartet
Gestoppt: Budget erreicht	Der Run hat sein Budget verbraucht; eine Entscheidung wartet
Geparkt	Pausiert nach einem vorübergehenden Fehler oder wiederholt fehlgeschlagenen Prüfungen
Fehlgeschlagen	Endgültig gestoppt, der Grund steht auf der Run-Seite
Gestoppt	Von einer Person gestoppt

Versuche und Nacharbeit

Ein Run kann mehrere Versuche haben. Alle Versuche teilen sich denselben Run-Schlüssel. Schlägt die Prüfung fehl, startet kanman einen automatischen Nacharbeitsversuch und gibt dem Executor die Gate-Ausgabe und die Befunde des Reviewers mit. Die Run-Seite zeigt dann zum Beispiel Versuch 1: Kriterium 2 nicht erfüllt.

Scheitert auch die Nacharbeit oder schlägt ein Gate immer wieder fehl, dreht der Run keine Schleifen. Er landet im Entscheidungseingang als Prüfung fehlgeschlagen oder Wiederholt fehlgeschlagene Prüfung. Wie viele Nacharbeitsversuche und Gate-Fehler erlaubt sind, steht in der Richtlinie (rework_attempts, gate_failure_budget).

Komplexitäts-Routing

Beim Start ordnet kanman die Story als trivial, routine oder complex ein. Die Klasse bestimmt Modellstufe, Turn-Budget und Vorgehen:

Klasse	Modellstufe	Turn-Budget	Vorgehen
trivial	small	60	keines
routine	mid	120	Plan und Selbstprüfung
complex	flagship	200	mehrere bewertete Lösungsansätze, dann ein Plan

Das ist der wichtigste Kostenhebel: Kleine Änderungen bezahlen nicht für das teuerste Modell. Stufe und Turn-Budget pro Klasse ändern Sie in der Richtlinie (routing); Einstellungen > Executor zeigt das daraus folgende Modell für jede Klasse.

Der Reviewer-Run, der die Akzeptanzkriterien prüft, nutzt ein Modell des anderen Anbieters (ein Codex-Modell bei Claude Code und umgekehrt). Der Code wird also nie von dem Modell geprüft, das ihn geschrieben hat.

Das Run-Notizbuch

Jeder Run führt ein Notizbuch, in das nur angehängt wird, mit diesen Abschnitten:

Einordnung
Lösungsansätze
Plan
Umsetzungsnotizen
Selbstprüfung
Review-Urteil
Retrospektive
Entscheidungen

Plan und bewertete Lösungsansätze erscheinen im Nachweispaket. Die Retrospektive und die Einwände des Reviewers fließen in die Konventionen des Teams ein, und Ihre Notizen zu Entscheidungen erreichen von hier aus den nächsten Versuch.

Kosten

Die Kostenanzeige auf der Run-Seite zeigt die Kosten des Runs im Verhältnis zum Run-Budget (standardmäßig 2,00 EUR). Würde ein Run sein Budget überschreiten, stoppt er mit Gestoppt: Budget erreicht, es entsteht kein Pull Request, und der Entscheidungseingang fragt, ob das Budget erhöht werden soll. Siehe Budgets und Kosten.

Aktionen auf einem Run

Aktion	Wirkung
Stoppen	Bricht den Run nach einer Bestätigung ab. Die Story bleibt, wo sie ist, und behält ihren Verlauf
Erneut versuchen	Reiht einen neuen Versuch unter demselben Run-Schlüssel ein
Entscheidung öffnen	Springt zur offenen Entscheidung dieses Runs

Jede Statusänderung eines Runs steht im Audit-Log als run_state_changed, mit der Person, die geklickt hat, als Akteur.

Vorübergehende Fehler heilen von selbst

Netzwerkfehler, eine überlastete Modell-API oder ein abgestürzter Executor sind nicht Ihr Problem. kanman parkt den Run und versucht es nach 1, 5 und 15 Minuten erneut. Solche Fehler landen nie im Entscheidungseingang. Die Run-Seite zeigt Nach einem vorübergehenden Fehler erholt, sobald es weitergeht. Nach drei erfolglosen Wiederholungen endet der Run als Fehlgeschlagen, mit dem Grund auf der Run-Seite.

Antwortet Ihr Git-Host oder Tracker nicht, hält kanman neue Runs zurück und parkt laufende, bis der Dienst wieder erreichbar ist, höchstens drei Stunden lang.

Die Prüfung auf festgefahrene Runs

kanman prüft regelmäßig die Runs des Teams zwischen zwei Versuchen (alle 15 Minuten) und den Main-Branch des Teams (alle 5 Minuten):

Ein Run, dessen Gates immer wieder scheitern (das gate_failure_budget ist aufgebraucht, oder die Story ist über mehrere Runs doppelt so oft gescheitert), wird geparkt, und eine Entscheidung Wiederholt fehlgeschlagene Prüfung bietet Retry with my guidance, Retry as is oder Stop this run.
Ein Run, dessen Ausgaben sein Budget erreicht haben, wird geparkt, und eine Entscheidung Budget-Stopp bietet an, das Budget zu erhöhen oder zu stoppen.
Wird die CI Ihres Main-Branches rot, hält kanman seine automatischen Merges an und öffnet eine Entscheidung Main-Branch ist rot. Ist ein gemergter Pull Request aus einem kanman-Run die wahrscheinliche Ursache, öffnet kanman auf GitHub einen Revert-Pull-Request und fragt, bevor er gemergt wird. Auf GitLab öffnet die Entscheidung ohne Revert-Pull-Request.

Die Team-Seite zeigt das Ergebnis als Gesundheitszeile, zum Beispiel 1 Run wegen wiederholter Prüffehler geparkt oder Main ist rot, Merges sind angehalten.