Entscheidungen
Alles, was einen Menschen braucht, landet an einem Ort: im Entscheidungseingang. Jede Entscheidung kommt mit kanmans Empfehlung und wenigen klaren Optionen.
kanman arbeitet selbstständig, bis es an etwas kommt, das es nicht allein entscheiden sollte. Dann hält es an und fragt. All diese Fragen landen an einem Ort, dem Entscheidungseingang. Niemand muss Chat-Verläufe, PR-Kommentare und Tracker-Benachrichtigungen durchsuchen, um herauszufinden, worauf kanman wartet.
Klicken Sie auf das Posteingangs-Symbol in der oberen Leiste (oder drücken Sie G dann D), um Entscheidungen zu öffnen. Eine gelbe Zahl am Symbol zeigt, wie viele Entscheidungen offen sind. Der Eingang hat zwei Reiter mit eigener Adresse: Offen (/<workspace>/decisions) und Entschieden (/<workspace>/decisions/resolved). Jede Entscheidung hat eine eigene Seite unter app.kanman.ai/<workspace>/decisions/<decision-key>, zum Beispiel dec-4h2k.
Wie eine Entscheidung aussieht
Jede Entscheidung hat:
- einen Titel, der sagt, worum es geht, zum Beispiel Raise budget for this run?
- einen Text mit kanmans Begründung und dem Kontext: die Story, der Run, die Gate-Ausgabe oder die betroffene Richtlinienregel
- eine Empfehlung: die Option, die kanman wählen würde, angezeigt nach Ich empfehle:
- 2 bis 4 Optionen, jede eine konkrete Aktion
kanman schreibt in Entscheidungen “ich”. Es ist ein Teammitglied, keine Gruppe von Bots.
Jede Entscheidung im Eingang nennt ihre Story mit Key und Titel, sodass sich mehrere Fragen “Bereit zum Mergen” leicht unterscheiden lassen, und zeigt, wann sie gestellt wurde. Beantworten Sie eine, steht Ihre Antwort an ihrer Stelle, bevor sie verschwindet. Der Eingang hat die Reiter Offen und Entschieden und lässt sich nach Art filtern und nach Alter sortieren. Wochenberichte des Teams, die Sie noch nicht geöffnet haben, erscheinen über den Reitern.
In der Unterhaltung beantworten Sie dieselbe Entscheidung mit einem Klick auf der Karte:
Arten von Entscheidungen
| Art | Wann sie entsteht | Optionen |
|---|---|---|
| Plan-Freigabe | Die Richtlinie verlangt eine Freigabe des Plans vor dem Code | Plan freigeben, Änderungen anfordern, Ablehnen |
| Richtlinien-Ausnahme | Ein Run braucht etwas, das die Richtlinie verbietet, zum Beispiel einen gesperrten Pfad oder ein nicht erlaubtes Repository | Einmal erlauben, Ablehnen |
| Rückfrage | Der Executor hat eine Frage, die die Story nicht beantwortet | Die von kanman angebotenen Antworten, oder Answer und Stop this run |
| Budget-Stopp | Ein Run hat sein Budget erreicht | Auf das Doppelte des Run-Budgets erhöhen, Abbrechen |
| Umfangsänderung | Die Änderung ist größer, als max_changed_files oder max_changed_lines erlauben |
Änderung eingrenzen, Diese Größe einmal erlauben, Ablehnen |
| Prüfschritt fehlgeschlagen | kanman konnte keine Akzeptanzspezifikation schreiben, die läuft, vor der Änderung fehlschlägt und die echte App prüft | Write the spec again, Keep it in Refining |
| Eingrenzen, weitermachen oder zurückstellen | Derselbe Fehler kam wieder, nachdem kanman denselben Code erneut geprüft und einen anderen Ansatz versucht hat, oder die Story hat ihre Versuche aufgebraucht | Eingrenzen: weglassen, was immer wieder scheitert, Weitermachen: noch ein Versuch, Vorerst zurückstellen |
| Die Spezifikation widerspricht der Story | Dieselbe Prüfung ist zweimal gescheitert, und kanman hat festgestellt, dass die Akzeptanzspezifikation der Story widerspricht, nicht der Code | Spezifikation an die Story anpassen, Eingrenzen: den widersprüchlichen Teil weglassen, Vorerst zurückstellen |
| Prüfung fehlgeschlagen | Auch der Nacharbeitsversuch ist am Gate gescheitert (an den Tagen, an denen kanman noch auf dem bisherigen Weg arbeitet) | Retry once more, Abandon the run |
| Diff-Schutz | Die Umsetzung hat die Akzeptanzspezifikation geändert | Revert spec changes and retry, Reject |
| Wiederholt fehlgeschlagene Prüfung | Ein Gate ist öfter gescheitert, als das Fehlerbudget erlaubt | Retry with my guidance, Retry as is, Stop this run |
| Keine Änderung | Ein neuer Versuch nach fehlgeschlagenen Prüfungen endete ohne neuen Commit, deshalb hat kanman dieselben Prüfungen nicht noch einmal laufen lassen. Die Entscheidung zitiert, was kanman am Ende des Versuchs gesagt hat. War die zuletzt fehlgeschlagene Prüfung das Review (die Einschätzung eines Modells) oder hat sie einen älteren Commit beurteilt, empfiehlt kanman, den aktuellen Code erneut zu prüfen, ohne neuen Versuch. Siehe Den aktuellen Code erneut prüfen | Mit meinem Hinweis erneut versuchen, Prüfungen am aktuellen Code erneut ausführen, Unverändert erneut versuchen, Diesen Run stoppen |
| Bereit zum Mergen | Alle Prüfungen sind bestanden, und laut Merge-Richtlinie des Teams mergt ein Mensch. Nur Inhaber und Admins können Mergen wählen; lehnt der Code-Host ab, bleibt die Entscheidung offen und nennt den Grund | Mergen, Jetzt nicht |
| Merge-Freigabe | Alle Prüfungen sind bestanden, aber die Änderung ist größer als die Grenze für automatisches Mergen, oder der Code-Host hat kanmans automatischen Merge abgelehnt | Mergen, Nicht mergen |
| Merge Request geschlossen | Der Pull Request wurde auf dem Code-Host ohne Merge geschlossen | Run stoppen, In Review lassen (ich habe ihn wieder geöffnet) |
| Main-Branch ist rot | Die CI Ihres Main-Branches ist rot; kanman hält seine automatischen Merges an | Keep holding merges while main is fixed, Release the merge hold |
| Revert-Freigabe | Ein Pull Request aus einem kanman-Run ist die wahrscheinliche Ursache für den roten Main-Branch, und kanman hat einen Revert geöffnet | Revert-Pull-Request mergen, Revert schließen und vorwärts korrigieren |
| Deine Änderung und eine rote Basis | Die gemergte Änderung einer Kollegin oder eines Kollegen hat einen Standard-Branch rot gemacht, und kanman hat eine Korrektur oder einen Revert angelegt. Nur die Person, von der die Änderung stammt, bekommt sie, mit ihrer nächsten Zusammenfassung, siehe Wenn die Änderung von jemand anderem den Branch rot gemacht hat | Korrektur mergen, Ich kümmere mich darum, Nicht meine Änderung |
| Hindernis-Alarm | Ein Problem, an dem kanman arbeitet, hält seit zwei Arbeitsstunden die ganze Arbeit eines Teams auf. Er kommt sofort, siehe Wenn ein Problem die ganze Arbeit aufhält | Ich übernehme ab hier, Bei kanman lassen |
| Wartungsvorschlag | Ein Fund aus dem Wartungsmodus steht nicht auf der Liste des Teams | Als Story anlegen, Verwerfen |
| Strategievorschlag | Der Wartungsmodus schlägt ein Feature auf Basis Ihrer STRATEGY.md vor |
Start intake, Decline |
Für vorübergehende Fehler wie einen Netzwerkfehler entsteht nie eine Entscheidung; diese wiederholt kanman selbst (siehe Runs).
Hinweis
Titel, Texte und die meisten Optionen von Entscheidungen sind derzeit auf Englisch. Die Optionen von Plan-Freigaben, Richtlinien-Ausnahmen, Umfangsänderungen und Budget-Stopps folgen Ihrer Spracheinstellung.
Beispiel: ein gesperrter Pfad
Das Preset Ausgewogen sperrt infra/**. Berührt die Änderung eines Runs infra/alarms.tf, stoppt der Run mit dem Status Durch Richtlinie blockiert, und die Run-Seite meldet, dass der Pfad infra/alarms.tf durch die Richtlinie nicht erlaubt ist. Die Entscheidung bietet Einmal erlauben und Ablehnen, und kanman empfiehlt Ablehnen: Die Regel hat einen Grund, und eine Ausnahme gilt nur für diesen Run.
Wählen Sie Einmal erlauben, steht auf der Karte Du hast es einmal erlaubt. Die Richtlinie bleibt unverändert. Der Run geht mit dieser einen Datei weiter, auch durch die Prüfungen von kanman und einen zweiten Versuch, falls einer nötig ist, und der nächste Run wird wieder blockiert. Die Richtlinie selbst sehen Sie, wenn Sie kanman im Chat des Teams fragen: „Zeig mir die Richtlinie“. Dann öffnen sich ihre Einstellungen mit den Pfaden, die kanman nicht ändern darf.
Wählen Sie Ablehnen mit der Notiz “Infra-Änderungen laufen über Ops”, endet der Run, und die Story wandert mit Ihrer Notiz als Kommentar zurück ins Backlog. Das Audit-Log erhält einen Eintrag policy_decision mit dem Ergebnis denied und einen Eintrag decision_resolved mit Ihrem Namen.
Wer antworten darf
Jedes Mitglied des Workspaces kann Entscheidungen beantworten. Optionen, die etwas beenden oder ablehnen, fragen vor dem Bestätigen nach einer optionalen Notiz; Freigaben brauchen einen Klick. Jede Antwort hält fest, wer wann auf welchem Weg (die App, Slack, MCP oder die API) entschieden hat, und die Notiz.
Sobald Sie antworten, macht kanman weiter: Eine Plan-Freigabe startet die Umsetzung, ein erhöhtes Budget setzt den Run fort, eine Ablehnung schickt die Story mit Ihrer Notiz zurück.
Was kanman allein entscheidet
Nicht jede Wahl ist eine Entscheidung für Sie. kanman ordnet jede Wahl einer von drei Befugnisstufen zu:
- AUTO: Es handelt und protokolliert.
- NOTIFY: Es handelt und hält einen Hinweis fest.
- ESCALATE: Es hält an und fragt im Entscheidungseingang.
Die Tabelle ist fest und deterministisch, und ein Team kann kanman nur vorsichtiger machen, nie weniger vorsichtig. Siehe Richtlinien, Presets und Befugnisstufen.
Status
| Status | Bedeutung |
|---|---|
| Offen | Wartet auf eine Antwort. Entscheidungen laufen nicht ab; der Run wartet, bis jemand antwortet |
| Wartet auf dieselbe Frage | kanman hat diese Frage schon gestellt; Ihre Antwort auf die offene Frage beantwortet auch diese |
| Entschieden | Beantwortet |
| Überholt | Nicht mehr nötig, weil sich die Lage von selbst geklärt hat, zum Beispiel weil Main wieder grün ist |
Fragen, die sich nicht mehr stellen, schließt kanman von selbst, innerhalb von etwa 15 Minuten, und vermerkt den Grund an der Entscheidung: Die Story hat Ready erreicht (bei „kann Ready noch nicht erreichen“), der Run ist beendet oder ein neuerer Versuch hat übernommen, die Story ist erledigt oder wurde gelöscht, oder jemand hat einen pausierten Run mit Rückgängig fortgesetzt. Eine Antwort, die Sie zuerst gegeben haben, hat immer Vorrang.
Benachrichtigungen
kanman informiert Sie auf zwei Wegen über neue Entscheidungen:
- die Zahl am Entscheidungs-Symbol in der oberen Leiste der App
- ganz oben auf der Run-Seite des Runs, der sie ausgelöst hat, wo Sie sie direkt beantworten können, und in der Karte Einrichtung eines neuen Teams (Plan prüfen)
- eine Nachricht im Slack-Kanal des Teams mit Schaltflächen zum Antworten, wenn Ihr Workspace mit Slack verbunden ist. Siehe Entscheidungen in Slack beantworten
Entscheidungen zu den Stories eines Ziels sammelt kanman auf der Karte des Ziels im Team-Chat und gruppiert sie unter Entscheidungen nach Zielen, eine Frage nach der anderen; dieselbe Frage für mehrere Stories stellt kanman nur einmal. Siehe Was ein Ziel von Ihnen braucht.
kanman fragt Sie nie zweimal dasselbe. Kommt eine Frage auf, die schon offen ist, wartet sie auf die offene Frage, und Ihre Antwort gilt für beide. Haben Sie eine Frage zu einem Zugang oder dazu, was Sie möchten, schon beantwortet, bekommt dieselbe Frage später Ihre Antwort, ohne dass kanman erneut fragt; Sie sehen das an der Entscheidung. Eine Frage zu einem einzelnen Versuch, etwa ob ein Run weiterlaufen darf, stellt kanman jedes Mal neu.
Sie können eine Entscheidung auch direkt in Ihrer Unterhaltung mit kanman beantworten (die Nachricht trägt die Entscheidungskarte) oder in einem Slack-Thread, zum Beispiel mit “freigeben dec-4h2k”.
Verwandte Seiten
Zuletzt aktualisiert: January 1, 0001
kanman öffnen