Das Outcome-Gate und Nachweise

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.

Ein Nachweis, der zur Story passt

Eine einzeilige CSS-Korrektur braucht nicht denselben Aufwand wie eine neue Exportfunktion. kanman passt den Nachweis an die Größe der Story an: Eine kleine Änderung ist so schnell fertig wie mit dem Coding-Agent allein, mit den Prüfungen, die ein sorgfältiges Review ohnehin machen würde.

• Kleine Storys brauchen keine neue Akzeptanzspezifikation. Nachweis sind Build und Tests Ihres Repositorys, die CI, kanmans Prüfung jedes Akzeptanzkriteriums und Screenshots der laufenden App vor und nach der Änderung, im hellen und im dunklen Modus. Das Review vergleicht vorher und nachher für jedes Farbschema: Ein visuelles Kriterium gilt nur als erfüllt, wenn es in beiden erfüllt ist. Die Story-Seite zeigt Spec: nicht nötig (kleine Story), und der Nachweis sagt Kleine Story statt “nicht nachgewiesen”.
• Normale und komplexe Storys bekommen einen Akzeptanztest, den der Coding-Agent zusammen mit der Lösung schreibt. Der Agent hat den Code und die laufende App vor sich und verwendet deshalb die echten Namen von Schaltflächen und Feldern, statt sie zu raten. Die Story-Seite zeigt Spec: entsteht mit der Lösung. Am Ende des Versuchs prüft kanman den Test: Er muss ehrlich sein (keine Mocks Ihrer App), auf dem Basis-Branch fehlschlagen, wo die Änderung fehlt, auf dem Branch des Runs bestehen und jedes Akzeptanzkriterium mit einem Test abdecken, der es tatsächlich ausführt und das Ergebnis prüft. Ein Test, der nur besteht, reicht nicht.
• Schreibt der Coding-Agent keinen Test, schreibt kanman selbst einen, und der Run geht damit weiter. Akzeptanzspezifikation neu schreiben und Eigene Spec verwenden funktionieren wie bisher.

Welche Storys eine Akzeptanzspezifikation bekommen, ist eine Team-Einstellung: Einstellungen > Prüfungen und Auslieferung, Welche Storys eine Akzeptanzspezifikation bekommen, eine Auswahl mit den Optionen jede Story, normale und komplexe Storys (Standard) und nur komplexe Storys. Aus gibt es nur beim Preset Trial. Siehe acceptance_spec_for.

Erst ansehen, dann schreiben

Wer einen Test schreibt, sieht sich zuerst die App an. Bevor eine Story nach Bereit wandert, startet kanman Ihre App so, wie Ihr Akzeptanz-Manifest es beschreibt, meldet sich an wie Ihre Beispiel-Spec, öffnet die Seiten, die der Demonstrate-Schritt der Story nennt, und hält fest, was darauf zu sehen ist: welche Überschriften, Schaltflächen, Felder und Links es gibt und wie sie heißen, im hellen und im dunklen Modus. Der Coding-Agent bekommt das als Kontext, ebenso kanmans Spec-Autor, wenn er einen Test schreibt. Die Screenshots sind die “Vorher”-Hälfte des Nachweises. Lässt sich die App nicht öffnen, geht die Story trotzdem weiter; der Nachweis sagt, warum es keine Screenshots gibt.

Von Ready bis PR bereit

Der Reiter Kosten & Details des Runs zeigt, wie lange eine Story von Bereit brauchte, bis ihr Pull Request bereit zum Mergen war, aufgeteilt in die Zeit, in der der Coding-Agent gearbeitet hat, die Zeit, in der kanman auf Personen gewartet hat (zum Beispiel auf eine Plan-Freigabe), und kanmans eigene Prüfungen. Für kleine Storys ist das Ziel, dass kanmans Prüfungen höchstens 5 Minuten zu dem hinzufügen, was der Coding-Agent allein brauchen würde; der Nachweis sagt, ob der Run das Ziel erreicht hat. Die Run-Zeitleiste endet mit PR bereit nach N Min.

Die Gates

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

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, sieht sich die laufende App an und führt das Gate für Bereit aus; schreibt kanman die Spec selbst, zeigt die Karte 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. Aus demselben Grund prüft kanman den eigenen Test des Coding-Agents nach dem Versuch gegen den Basis-Branch; besteht er dort schon, geht er mit Die Spezifikation läuft schon vor der Umsetzung grün an den Agent zurück. 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.

Rot zählt nur, wenn die Prüfungen der Spec scheitern, weil das neue Verhalten noch fehlt. Eine Spec, die an einem eigenen Fehler scheitert, etwa an einer falsch geschriebenen Funktion, einer undefinierten Variable, einem unlesbaren Selektor, einem Locator, der mehrere Elemente trifft, oder einem abstürzenden Vorbereitungsschritt, würde nie bestehen und zählt deshalb nicht als rot. Die Story bleibt in der Verfeinerung mit Die Spezifikation scheitert an einem eigenen Fehler, nicht an einer Prüfung, mit Test und Zeile, und kanman schreibt die Spec neu. Eine Spec, die Sie selbst bereitgestellt haben, geht mit demselben Grund an Sie zurück. Ist die getestete Anwendung gar nicht erreichbar, ist die Testumgebung ausgefallen, und kanman versucht es still erneut.

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.

Wie kanman die Spec schreibt

kanman schreibt die Spec so, wie Ihr Team Akzeptanztests schreibt. Vorher liest es die Beispiel-Spec in .kanman/acceptance/EXAMPLE/ (ohne sie die neueste Spec einer anderen Story) und Ihre Test-Helfer, etwa einen Login-Helfer in einem Ordner _support/ oder die Dateien, die Sie im Akzeptanz-Manifest unter context angeben. Die Spec importiert diese Helfer, statt sie nachzubauen, und liest Test-Logins aus den Variablen, die Ihr Manifest freigibt.

Eine Spec beobachtet nur. Sie wartet nach jedem Seitenwechsel, bis die App bereit ist, auch bei Anmelde- und Auswahlseiten wie einer Mandantenauswahl, und findet Elemente über das, was Menschen auf dem Bildschirm sehen. Den Checkout, in dem sie läuft, verändert sie nie: keine Git-Befehle, keine Pakete installieren oder entfernen, keine Dateien löschen. Bei Storys über die Kommandozeile oder Abhängigkeiten liest sie Dateien und führt nur Befehle aus, die nachsehen.

An der Anmeldung scheitern Specs am häufigsten. Deshalb übernimmt kanman die Anmelde- und Vorbereitungsschritte Ihrer Beispiel-Spec unverändert in jede neue Spec und schreibt die Schritte der Story dahinter. Auf jede Seite, die Ihre App unterwegs zeigt, etwa eine Mandantenauswahl, wartet sie, bis die Seite da ist, statt sie nur anzuklicken, falls sie gerade schon sichtbar ist. Sie wartet nie darauf, dass das Netzwerk zur Ruhe kommt: Apps, die laufend Aktualisierungen laden, kommen nie zur Ruhe, und eine solche Spec liefe nur in einen Timeout. Stattdessen wartet sie auf etwas Sichtbares, das zeigt, dass die Seite bereit ist.

Ihr Team kennt seine App am besten. Unter Einstellungen > Prüfungen und Auslieferung, Hinweise für Akzeptanz-Spezifikationen, halten Team-Admins fest, was jede Spec des Teams beachten muss, zum Beispiel „nach der Mandantenauswahl die Seite nie neu laden“ oder „die App ist bereit, wenn die Suchschaltfläche erscheint“. kanman befolgt diese Hinweise in jeder Spec, die es für das Team schreibt oder neu schreibt. Siehe spec_notes.

Unter Einstellungen > Agent und Modelle, im ausklappbaren Teil zum Spec-Autor in Welches Modell woran arbeitet, wählen Team-Admins außerdem das Modell, das die Specs schreibt: das Assistenzmodell von kanman (Standard) oder das Modell des Coding-Agents des Teams. Das Modell des Coding-Agents kennt Test-Frameworks und das Auffinden von Elementen auf einer Seite meist besser, seine Specs scheitern also seltener aus dem falschen Grund; dafür kostet jede Spec einen Aufruf dieses Modells. Siehe spec_author_model.

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.

Dieselbe Prüfung lehnt Specs ab, die den Checkout verändern würden (zum Beispiel Die Spezifikation verändert den Checkout, statt ihn nur zu beobachten: git clean -xfd), Specs, die darauf warten, dass das Netzwerk zur Ruhe kommt (Die Spezifikation wartet auf Netzwerkruhe), und Specs, die einen Helfer aus einem Pfad importieren, unter dem es keine Datei gibt. kanman schreibt eine solche Spec mit dem Grund sofort neu, bevor sie überhaupt läuft.

Die Akzeptanzspezifikation neu schreiben lassen

Manchmal ist die Spec falsch, nicht der Code: Sie prüft eine Seite, bevor die App bereit ist, oder sucht einen Button, den die Story nie verlangt hat. Sie müssen sie nicht selbst korrigieren. Sagen Sie kanman, was nicht stimmt, und kanman schreibt die Spec neu.

• Wählen Sie auf der Story-Seite oder der Run-Seite unter dem Spec-Status Akzeptanzspezifikation neu schreiben, beschreiben Sie das Problem in ein, zwei Sätzen und wählen Sie Spezifikation neu schreiben.
• Fragt kanman Sie während eines Runs, ob die Spec korrigiert werden soll, wählen Sie diese Antwort und ergänzen Sie Ihren Hinweis.

Ein Hinweis darf bis zu 50.000 Zeichen lang sein. Kurz vor der Grenze zeigt das Formular, wie viele Zeichen Sie verwendet haben; ein längerer Hinweis wird nicht gesendet, und das Formular sagt Ihnen das, statt ihn zu kürzen.

kanman schreibt die Spec mit Ihrem Hinweis neu, prüft erneut, dass sie vor der Änderung fehlschlägt, und ersetzt die freigegebene Spec. Wartet ein Run, kommt die neue Spec auf seinen Branch und der Run geht weiter. Solange ein Run gerade arbeitet, bittet kanman Sie zu warten, bis er pausiert oder auf Sie wartet. Jede Anfrage steht im Audit-Log.

Pro Story läuft immer nur eine Neufassung. Senden Sie einen weiteren Hinweis, während kanman die Spec noch neu schreibt, etwa um Ihren ersten Hinweis zu korrigieren, zeigt das Formular an, dass gerade eine Neufassung läuft und Ihr Hinweis ihr hinzugefügt wird. kanman schließt die laufende Neufassung ab, setzt Ihren neuen Hinweis darauf um und lässt erst dann den wartenden Run weiterlaufen: denselben Run, ohne einen neuen Plan zur Freigabe. Ein Hinweis, der eintrifft, bevor die Neufassung begonnen hat, wird mit dem früheren zusammengeführt; wo sich beide widersprechen, gilt der neueste. Denselben Hinweis zweimal zu senden, ändert nichts.

Damit es bei wenigen Runden bleibt, schreibt kanman Specs, die nur prüfen, was die Akzeptanzkriterien verlangen: keine Pixelpositionen oder Ausrichtungen, keine exakten Listen oder Anzahlen, die die Kriterien nicht nennen, und keine Navigation, die die Story nicht beschreibt. Voneinander unabhängige Prüfungen sind so geschrieben, dass ein Durchlauf alle Abweichungen auf einmal meldet, nicht nur die erste. Schlagen die Prüfungen eines Runs fehl, erhalten der Run und jede Neufassung die vollständige Liste der fehlgeschlagenen Prüfungen. Hat der Run bereits etwas umgesetzt, probiert kanman die neu geschriebene Spec außerdem auf dem Branch des Runs aus, bevor der Run weitergeht. Verlangt eine Prüfung dort etwas, das die Kriterien nicht fordern, korrigiert kanman die Spec einmal selbst, sodass Sie dafür keinen weiteren Hinweis schreiben müssen.

kanman merkt sich Ihren Hinweis. Durchläuft die Story später noch einmal die Verfeinerung, behält kanman die freigegebene Spec, solange sich die Story selbst nicht geändert hat. Hat sie sich geändert, beginnt kanman mit der freigegebenen Spec und Ihren früheren Hinweisen, statt von vorn anzufangen, damit eine Korrektur, um die Sie gebeten haben, nicht verloren geht. Sobald eine neue Spec freigegeben ist, legt kanman sie außerdem auf den vorhandenen Branch der Story, damit der nächste Run mit der freigegebenen Fassung beginnt.

Eigene Spec verwenden

Manchmal haben Sie die richtige Spec schon, zum Beispiel eine, die eine Testerin von Hand geschrieben hat. Inhaber und Admins können sie direkt einsetzen, statt eine Korrektur zu beschreiben:

1. Wählen Sie auf der Story-Seite oder der Run-Seite unter dem Spec-Status Meine Spezifikation verwenden. Ist das Formular zum Neuschreiben schon offen, wechseln Sie oben zu Meine Spezifikation verwenden.
2. Fügen Sie die Spec ein (der Dateiname ist optional), laden Sie eine oder mehrere Dateien hoch oder geben Sie einen Commit auf dem Spec-Branch der Story kanman/spec/<KEY> an. Lassen Sie den Commit leer, verwendet kanman den neuesten. Jede Datei darf bis zu 120 KB groß sein, bis zu 10 Dateien auf einmal.
3. Wählen Sie Diese Spezifikation verwenden.

kanman prüft Ihre Spec genau so, wie sie ist, und verändert sie nie: Sie muss ehrlich sein, darf den Checkout nicht verändern, ihre Imports müssen existieren, und sie muss vor der Änderung fehlschlagen. Besteht sie, gibt kanman sie frei, legt sie auf den Spec-Branch und auf den Branch eines wartenden Runs, und der Run geht weiter. Bevor etwas sie verwendet, liest kanman den Spec-Branch zurück und stellt sicher, dass er genau die Datei enthält, die die Prüfungen bestanden hat; eine abweichende Spec wird nicht verwendet, und das Formular sagt Ihnen das. Schlägt eine Prüfung fehl, zeigt das Formular den Grund, zum Beispiel Die Spezifikation wartet auf Netzwerkruhe; korrigieren Sie die Datei und wählen Sie Korrigieren und erneut senden. kanman schreibt Ihre Datei nicht um.

Fügen Sie eine vollständige Spec-Datei in einen Hinweis zum Neuschreiben ein, verwendet kanman sie auf dieselbe Weise unverändert. Zitiert Ihr Hinweis Code und bittet darum, ihn unverändert zu übernehmen, akzeptiert kanman nur eine Spec, die diesen Code genau so enthält.

Jede Spec, die Sie bereitstellen, steht im Audit-Log, und das Nachweispaket nennt, wer die Spec bereitgestellt hat.

Der Diff-Wächter

Die Akzeptanzspezifikation liegt auf einem geschützten Pfad, .kanman/acceptance/<KEY>/. Executors dürfen eine freigegebene Spec nie ändern: Der Pfad ist in jedem Preset gesperrt und lässt sich nicht freigeben. Einzige Ausnahme ist eine Story, deren Coding-Agent seinen eigenen Test mit der Lösung schreibt: Er darf im Ordner dieser Story schreiben und nirgends sonst unter .kanman/acceptance/. 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 Spec-Änderungen zurücknehmen und erneut versuchen oder Ablehnen an. kanman setzt die Commit-Autorschaft außerdem selbst und weiß so, welche Commits vom Executor stammen.

Nicht jede Abweichung geht auf den Run zurück. Liegt auf dem Branch eine andere Fassung der Spec, obwohl keiner der Commits des Runs sie geändert hat, etwa weil der Branch entstanden ist, bevor eine neu geschriebene Spec freigegeben wurde, legt kanman die freigegebene Spec selbst auf den Branch und prüft erneut. Erst wenn das nicht hilft, fragt Sie der Entscheidungseingang, mit Diff-Wächter: Die Akzeptanzspezifikation auf dem Branch ist nicht die freigegebene und der Option Freigegebene Spec zurücklegen und erneut versuchen. kanman behauptet in diesem Fall nie, der Run habe seine Spec geändert.

Geänderte Testerwartungen

Der Coding-Agent darf bei seiner Arbeit Tests hinzufügen, bestehende Tests aber nie ändern oder löschen: Sie prüfen seine Arbeit. Manchmal ist die Lösung einer Story aber tatsächlich ein Test, etwa wenn ein Live-Test die Antwort eines externen Dienstes prüft und der Anbieter diese Antwort bewusst geändert hat. Dann darf die Story genau diese Testdateien ändern:

• Storys zu fehlschlagenden Tests, die kanman aus Ihrer CI anlegt, dürfen die Testdatei des fehlschlagenden Tests ändern. kanman findet die Datei in Ihrem Repository selbst (auf Ihren Runnern, wenn Sie alles auf Ihren Runnern ausführen).
• Jede andere Story: Stellt kanman fest, dass die Erwartung eines Tests für die Story falsch ist, fragt es einmal im Entscheidungseingang, zum Beispiel Darf ich die Testerwartung in e2e/placed_test.go ändern? Wählen Sie Ja, passe die Erwartung in e2e/placed_test.go an, um diese Datei für die Story freizugeben, Nein, lass den Test, wie er ist, und korrigiere den Code oder Run stoppen. Dieselbe Option erscheint bei Verifizierung fehlgeschlagen und wiederholten Fehlschlägen, wenn ein Versuch einen Test geändert hat.

Eine Freigabe gilt für die Story, bis sie endet: kanman fragt nie zweimal nach derselben Datei, und antworten Sie, während der Agent noch arbeitet, beginnt der nächste Versuch mit Ihrer Antwort. In autonomen Teams beantwortet kanmans eigener Prüfer solche Fragen (siehe Autonomie).

Akzeptanzspezifikationen gehören nie dazu: Sie bleiben geschützt. Jede Änderung an einem bestehenden Test wird markiert: Der Pull Request nennt sie mit Testerwartung geändert und den Dateien, der Nachweis zeigt die Teständerungen mit ihrem Diff zuerst, und den Merge gibt immer eine Person frei, gleich welche Merge-Richtlinie oder Autonomie-Einstellung gilt. Wer welche Testdateien freigegeben hat, steht im Audit-Log.

Warten auf CI

Erreicht ein Run die Prüfung, liest kanman den CI-Stand seines Branches. Code-Hosts, die kanman ihre CI-Ereignisse schicken, lösen die nächste Prüfung selbst aus. kanman prüft außerdem von sich aus: anfangs alle paar Minuten, seltener, je länger ein Run wartet. So bringt auch die CI eines Code-Hosts, der kanman nicht erreicht, etwa ein selbst betriebenes GitLab hinter einer Firewall, den Run weiter. Mit Alles auf Ihren Runnern ausführen liest Ihr Runner die CI.

Solange ein Run wartet, zeigt seine Run-Seite Warte auf CI und wann die CI zuletzt geprüft wurde, zum Beispiel „zuletzt geprüft vor 3 Minuten“, zusammen mit dem, was kanman vorgefunden hat: Die CI läuft noch, auf dem Branch gibt es noch keine CI-Prüfungen, oder bei der letzten Prüfung waren Ihr Code-Host oder Ihr Runner nicht erreichbar. Team-Admins können mit CI jetzt prüfen sofort nachsehen lassen.

Gibt es auf einem Branch 10 Minuten nach dem letzten Push überhaupt keine CI-Prüfungen, behandelt kanman die CI als nicht eingerichtet. Die CI-Prüfung besteht mit dem Hinweis Keine CI eingerichtet im Nachweispaket, sodass ein Repository ohne CI nie eine Story blockiert. Eine fehlschlagende CI lässt die Prüfung weiterhin fehlschlagen.

Was fehlschlägt, wird benannt. Schlägt die CI fehl, liest kanman das Log des fehlgeschlagenen Jobs, nennt die fehlschlagenden Tests (Ausgaben von Go, pytest, Jest und Vitest), verlinkt den Job und zitiert die Zeilen, die den Fehler zeigen. Eine Entscheidung zu einem Run, der immer wieder scheitert, beginnt mit dem, was fehlschlägt, damit Ihr Hinweis konkret sein kann.

Fehler, die schon da waren, zählen nicht. Ein Test, der auch auf Ihrem Standardbranch fehlschlägt, wird nicht von der Story verursacht. Schlägt Ihr lokaler Verify-Befehl fehl, führt kanman ihn einmal auf dem Basisbranch aus; bei der CI vergleicht es mit dem letzten CI-Lauf Ihres Standardbranches. Fehler, die der Basisbranch teilt, zählen nicht gegen die Story, der Coding-Agent soll sie weder beheben noch nachfragen, und der Nachweis nennt sie nicht von dieser Story verursacht. Nur Fehler, die der Branch der Story hinzufügt, lassen die Prüfung weiterhin fehlschlagen.

kanman merkt sich außerdem, was auf dem Standardbranch schon fehlgeschlagen ist, aus früheren Prüfungen und aktuellen CI-Läufen. So bleibt ein Fehler entschuldigt, auch wenn der letzte Lauf auf dem Basisbranch ihn nicht benennen konnte. Verglichen wird Gleiches mit Gleichem: Ein CI-Fehler wird nur durch das entschuldigt, was in Ihrer eigenen CI fehlschlägt, und nur aktuelle Ergebnisse zählen. Ein bekannt instabiler Test, der nur einmal fehlschlug, wird als instabil gemeldet und nicht gezählt; schlägt er erneut fehl, zählt er.

Prüfungen, die nicht vorankommen

Nach dem Ende eines Versuchs startet kanman sofort seine Prüfungen. Manchmal kann eine Prüfung nicht starten, etwa weil Ihr Runner in diesem Moment neu startet. kanman bemerkt, wenn die Prüfungen eines beendeten Versuchs nicht vorankommen, und startet sie selbst neu: nach 5 ruhigen Minuten, dann nach 10, 20 und 40 Minuten, danach stündlich, höchstens sechsmal. Eine Prüfung, die noch auf einen Runner wartet oder noch läuft, startet kanman nie doppelt.

Kommen die Prüfungen auch nach 10 Minuten nicht voran, zeigt die Run-Seite Die Prüfungen kommen nicht voran, wann kanman zuletzt Aktivität gesehen hat und wie oft die Prüfungen schon neu gestartet wurden. Team-Admins können mit Prüfungen neu starten sofort einen neuen Start auslösen oder den Run mit Stoppen beenden. Jeder Neustart steht im Audit-Log als Prüfungen neu gestartet, mit der Person, die ihn ausgelöst hat, oder kanman als Akteur. Startet kanman Prüfungen nach längerer Ruhe selbst neu, steht das in der Team-Aktivität, zum Beispiel „Ich habe die Prüfungen von run-x223 neu gestartet, sie zeigten 20 Minuten lang keinen Fortschritt.“

Den aktuellen Code erneut prüfen

Ein fehlgeschlagenes Urteil bezieht sich auf den Code, den es beurteilt hat. Manchmal ist das nicht mehr der Code auf dem Branch, oder die fehlgeschlagene Prüfung war das Review, also die Einschätzung eines Modells und kein ausgeführter Test. Ein weiterer Versuch hilft dann nicht: Der Code ist vielleicht schon richtig, und der Executor findet nichts zu ändern.

• In einer Entscheidung: Endete ein neuer Versuch ohne Änderung, bietet die Entscheidung Keine Änderung die Option Prüfungen am aktuellen Code erneut ausführen. kanman prüft die vorhandenen Commits erneut, von der Akzeptanz-Spezifikation über das Review bis zum sauberen Checkout, mit der aktuellen Richtlinie des Teams. Ein neuer Versuch startet nicht. kanman empfiehlt diese Option, wenn die zuletzt fehlgeschlagene Prüfung das Review war oder einen älteren Commit beurteilt hat.
• Von selbst: War die zuletzt fehlgeschlagene Prüfung das Review und stammt sein Urteil vielleicht von älterem Code, prüft kanman den aktuellen Code sofort erneut, statt Sie zu fragen.
• Auf der Run-Seite: Ist das letzte Urteil eines beendeten Runs fehlgeschlagen, sehen Team-Admins Das letzte Urteil ist fehlgeschlagen mit Prüfungen neu starten. Die offenen Fragen des Runs schließen sich, weil das neue Urteil sie beantwortet. Solange eine offene Entscheidung dieselbe Option anbietet, überlässt die Run-Seite sie der Entscheidung.

Jeder dieser Wege steht im Audit-Log als Prüfungen neu gestartet, mit der Person, die ihn ausgelöst hat, oder kanman als Akteur.

Mergen

Haben alle Gates im Review bestanden, entscheidet die Merge-Richtlinie des Teams, was mit dem Pull Request passiert:

• Ein Mensch mergt (Standard): kanman fragt im Entscheidungseingang und auf der Run-Seite mit Bereit zum Mergen. Inhaber und Admins des Workspaces wählen Mergen, dann mergt kanman den Pull Request mit der Merge-Methode des Repositorys und schiebt die Story auf Fertig. Jetzt nicht lässt ihn offen. Andere Mitglieder sehen die Frage, aber nur Inhaber und Admins können aus kanman heraus mergen.
• Kleine Änderungen automatisch mergen: Innerhalb der Zeilengrenze mergt kanman selbst. Darüber, oder wenn der Code-Host den Merge ablehnt, fragt die Entscheidung Merge-Freigabe bei Ihnen nach.
• Eine Änderung an bestehenden Tests fragt immer eine Person, mit beiden Richtlinien und bei jeder Autonomie-Einstellung (siehe Geänderte Testerwartungen).

kanman mergt so, wie Ihr Repository eingerichtet ist. In GitLab gelten die Merge-Methode und die Squash-Einstellung des Projekts, und der Quellbranch wird gelöscht, wenn der Merge Request das vorsieht. In GitHub fasst kanman die Commits zusammen (Squash), wenn das Repository es erlaubt, sonst erstellt es einen Merge-Commit, sonst einen Rebase. Mit Alles auf Ihren Runnern ausführen mergt Ihr Runner mit seinem eigenen Token.

Lehnt der Code-Host den Merge ab, bleibt die Entscheidung offen, und kanman sagt Ihnen, warum und was als Nächstes zu tun ist: Der Branch hat Konflikte, die Pipeline muss zuerst bestehen oder läuft noch, Freigaben oder gelöste Diskussionen fehlen, der Merge Request ist ein Entwurf, das Token darf nicht in den Zielbranch mergen, oder Ihr Runner hat nicht geantwortet. Beheben Sie die Ursache und wählen Sie erneut Mergen. Jeder Merge und jeder abgelehnte Merge steht im Audit-Log, mit der Person, die Mergen gewählt hat.

Sie können auch wie bisher auf dem Code-Host mergen. kanman bemerkt den Merge und schiebt die Story auf Fertig: über den Webhook des Code-Hosts oder, bei einem Code-Host, der kanman nicht erreicht, etwa einem selbst betriebenen GitLab hinter einem VPN, über die eigene regelmäßige Prüfung des Pull Requests (im selben Rhythmus wie beim Warten auf CI). Eine offene Frage Bereit zum Mergen schließt sich dann von selbst. Schließt jemand den Pull Request ohne Merge, fragt kanman, ob der Run gestoppt werden soll (Run stoppen, die Story geht zurück ins Backlog) oder ob er in Review bleibt, nachdem Sie ihn wieder geöffnet haben.

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

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.

Der Reviewer sieht außerdem, was kanman für den Versuch bereits ausgeführt hat: die Akzeptanzspezifikation, die gerade auf einer aus dem Branch installierten und gebauten Umgebung bestanden hat (mit den Namen der bestandenen Tests), Ihren lokalen Prüfbefehl und die CI. Manche Kriterien lassen sich nur zeigen, indem man die Software ausführt, etwa „der Build läuft durch“ oder „die App startet ohne Fehler“. Deckt ein bestandener Akzeptanzlauf ein solches Kriterium ab, gilt es als erfüllt, und die Story nennt den Lauf und den Test als Nachweis. Unbewiesen bleibt ein Kriterium nur, wenn weder der Diff noch eine ausgeführte Prüfung es abdeckt. Ein Kriterium, das der Reviewer als nicht erfüllt bewertet, bleibt nicht erfüllt.

kanmans eigene Akzeptanzspezifikation auf dem Branch zählt nie als Scope-Creep. Große Dateien wie Lockfiles erreichen den Reviewer als kurze Zusammenfassung: bei einem Lockfile die Pakete, die die Änderung hinzufügt, entfernt oder aktualisiert, bei anderen großen Dateien die Anzahl geänderter Zeilen und die betroffenen Abschnitte.

Wenn ein Gate fehlschlägt

kanman entscheidet selbst, ob sich ein weiterer Versuch lohnt, und fragt Sie nie “nochmal versuchen oder aufhören?”:

1. Etwas Neues ist fehlgeschlagen: kanman versucht es erneut. Der nächste Versuch bekommt die Gate-Ausgabe, die Befunde des Reviewers und das Log des fehlgeschlagenen CI-Jobs. Eine eindeutig fehlgeschlagene Prüfung, zum Beispiel “dunkler Modus: eine einzelne 1-px-Trennlinie, erwartet 1, gefunden 2”, gibt dem nächsten Versuch die vollständige Liste der fehlgeschlagenen Prüfungen mit.
2. Ein Test, der an einem eigenen Fehler scheitert (ein Tippfehler im Test, ein Locator, der mehrere Elemente trifft, ein abstürzender Einrichtungsschritt), ist nicht die Schuld der Änderung. kanman repariert ihn einmal, bevor jemand gefragt wird: Der Coding-Agent korrigiert seinen eigenen Test, oder kanmans Spec-Autor korrigiert eine Spec, die er geschrieben hat. Eine Spec, die Sie bereitgestellt haben, wird nie für Sie geändert.
3. Zweimal derselbe Fehler: kanman findet heraus, warum, bevor es weitermacht. Es führt dieselben Prüfungen noch einmal auf demselben Code aus. Bestehen sie jetzt, geht die Story weiter. Scheitern sie genauso, sucht kanman die Ursache und handelt danach:
   • Die Testumgebung ist gescheitert, nicht die Änderung: Die Story wartet einmal darauf, danach kümmert sich kanman selbst um die Umgebung und meldet sich nur, wenn es Sie braucht, einmal für alle Storys, die daran hängen (siehe Gestoppte Arbeit bleibt nie einfach liegen).
   • Der Haupt-Branch scheitert genauso: Die Story wartet, bis der Haupt-Branch behoben ist, statt es dagegen erneut zu versuchen.
   • Die Akzeptanzspezifikation widerspricht der Story: Sie bekommen eine Frage mit dem, was gescheitert ist, und kanmans Empfehlung: Spezifikation an die Story anpassen (empfohlen), Eingrenzen: den widersprüchlichen Teil weglassen oder Vorerst zurückstellen.
   • Die Änderung erfüllt das Kriterium noch nicht: kanman macht einen Versuch mit einem anderen Ansatz statt einer Wiederholung und gibt ihm mit, was es herausgefunden hat.
4. Weiter derselbe Fehler oder die Versuche der Story sind aufgebraucht: eine Frage, in Ihrem Briefing. Der Run wartet, und Sie bekommen einen Punkt mit dem, was versucht wurde, wie viele Versuche die Story voraussichtlich noch bräuchte, was das kosten und dauern würde und wie hoch die geschätzte Erfolgschance ist, dazu kanmans Empfehlung: Eingrenzen: weglassen, was immer wieder scheitert (empfohlen), Weitermachen: noch ein Versuch oder Vorerst zurückstellen: zurück ins Backlog. Er erreicht Sie mit Ihrem nächsten Briefing, nicht als Unterbrechung.
5. Ein fehlgeschlagener Diff-Wächter wird nie automatisch nachgebessert; er fragt immer. Einzige Ausnahme ist ein Branch, dem nur die freigegebene Spec fehlt: kanman legt sie zurück und prüft einmal erneut, ohne zu fragen.

Probleme der Testumgebung selbst (Klonen, Bereitstellung, Bereitschaftsprüfung, Setup) und kurze Ausfälle werden still wiederholt, und nur in einem kleinen Anteil der Arbeit Ihres Teams, damit ein gestörter Dienst nie zu einer Welle von Wiederholungen wird. Ein Versuch, der wegen eines solchen Problems scheiterte, bevor der Agent starten konnte, zählt nicht gegen die Versuche der Story; ist das Problem behoben, startet die Story einfach wieder.

Solange kanman bestätigt, dass das für Ihr Team besser funktioniert, kommt eine fehlgeschlagene Story an manchen Tagen noch auf dem bisherigen Weg zu Ihnen: ein automatischer Nacharbeitsversuch, dann Prüfung fehlgeschlagen, und Wiederholt fehlgeschlagene Prüfung, sobald das Fehlerbudget eines Gates (gate_failure_budget, standardmäßig 3) aufgebraucht ist.

Ein fehlgeschlagenes Gate wird nie zur Endlosschleife.

Das Nachweispaket

Bestehen die Gates im Review, schreibt kanman das Nachweispaket. Es wird am Run gespeichert, auf dem Reiter Nachweis 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 ihren Nachweisdateien: Screenshots mit Dateiname und der Prüfung, die sie aufgenommen hat, und Links zu Logs, Berichten, Traces und Videos mit ihrem Dateinamen
• Testzahlen und den CI-Link
• Kosten im Verhältnis zum Budget, Dauer und Zahl der Versuche
• ob ein Ergebnisnachweis vorliegt, oder dass eine kleine Story ohne Akzeptanzspezifikation nachgewiesen wurde
• Screenshots der laufenden App vor und nach der Änderung, im hellen und im dunklen Modus
• die Zeit von Bereit bis PR bereit, siehe Von Ready bis PR bereit
• wer die Akzeptanzspezifikation bereitgestellt hat, wenn ein Mensch sie statt kanman geschrieben hat

Auf dem Reiter Nachweis zeigt eine Abdeckungstabelle für jedes Kriterium, was es nachweist (Code, Akzeptanztest, Clean Room und Review), die Screenshots erscheinen als Paare vorher und nachher im hellen und dunklen Modus, und der Reiter listet außerdem die Richtlinien-Entscheidungen während des Runs; ein Klick auf einen Screenshot öffnet ihn in voller Größe. Plan, Ansätze und die Zeit von Bereit bis PR bereit stehen auf dem Reiter Kosten & Details. Die Links auf der Run-Seite funktionieren immer, auch Wochen später.

Am Pull Request zeigt der Kommentar bis zu acht Screenshots direkt an, jeweils mit Dateiname und Prüfung, und endet mit einem Link zum Nachweis auf der Run-Seite in kanman. Die Bilder im Kommentar bleiben 30 Tage sichtbar; danach öffnet der Link zur Run-Seite weiterhin jede Nachweisdatei.

Ein gekürztes Beispiel, wie es am Pull Request eines deutschsprachigen Teams erscheint. Jede Zeile beginnt mit einem klaren Statuswort (BESTANDEN, FEHLGESCHLAGEN, FEHLER, ÜBERSPRUNGEN oder UNKLAR) statt mit einem Symbol, sodass der Kommentar auf GitHub, in GitLab und in Jira, in E-Mail-Benachrichtigungen und mit einem Screenreader gleich gut lesbar ist:

Nachweis: SBX-12 (run-7f3k)

Ergebnis: NACHGEWIESEN. Die Akzeptanzspezifikation lief in einer sauberen Umgebung erfolgreich.

Plan
GET /invoices/export mit Datumsfilter und CSV-Serializer ergänzen.

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

Prüfungen
- BESTANDEN spec_green_ephemeral: Spec in einer frischen Umgebung bestanden (kanman-verify.log, invoices-export.png)
- BESTANDEN diff_guard: Die Umsetzung hat die Akzeptanzspezifikation nicht verändert
- BESTANDEN policy_diff: Die Änderung bleibt innerhalb der Team-Richtlinie
- BESTANDEN ci: CI bestanden
- BESTANDEN reviewer: Alle 2 Kriterien im Review bestanden
- BESTANDEN clean_room: Spec auf einem sauberen Checkout bestanden (kanman-verify.log, trace.zip, invoices-export.png)

- Tests: 12 bestanden, 0 fehlgeschlagen
- CI: success
- Kosten: €0.84 / €2.00
- Dauer: 11 min
- Versuche: 1

Screenshots
invoices-export.png · Spezifikation grün auf sauberem Checkout
[Bild]

Nachweis in kanman öffnen

Die Run-Seite zeigt das Nachweispaket in Ihrer Sprache. Die Kommentare am Pull Request und im Tracker erscheinen in der Sprache des Teams: der Sprache, die der Inhaber des Teams in kanman gewählt hat (Deutsch, Englisch, Spanisch oder Französisch), sonst auf Englisch.

Repositories ohne Manifest

Kleine Storys brauchen kein Manifest: Ohne eines werden sie durch CI und das Review nachgewiesen, nur ohne Screenshots. Für andere Storys gilt: Ohne Akzeptanz-Manifest gibt es keine Spec, die laufen könnte. Das erlaubt nur das Preset Testphase, damit Sie kanman an einem Repository ausprobieren 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.

Verwandte Seiten

• .kanman/acceptance.json und .kanman/verify.json
• Runs
• Stories und Akzeptanzkriterien