Entscheidungen | kanman Dokumentation

Entscheidungen sind alles, wofür kanman einen Menschen braucht: Plan-Freigaben, Ausnahmen von der Richtlinie, Rückfragen, Budgetstopps und fehlgeschlagene Prüfungen. Jede Entscheidung, die auf Sie wartet, kommt mit einer Empfehlung von kanman und 2 bis 4 Optionen. Das Konzept beschreibt Entscheidungen. Entscheidungen beantworten Sie in der App, in Slack oder über die REST-API.

Eine Entscheidung beantworten

Wo	Wie
App	Entscheidungen (`/<workspace>/decisions`), Reiter Offen und Entschieden, oder die Entscheidungsseite `/<workspace>/decisions/<entscheidungsschlüssel>`. Zustimmende Optionen brauchen einen Klick; Ablehnen, Änderungen anfordern, Antworten, Abbrechen und Ablehnen eines Vorschlags öffnen vorher eine kurze Notiz.
Slack	Die Buttons unter der Entscheidungsnachricht im Kanal des Teams, oder eine Antwort an kanman im Thread, zum Beispiel „approve“ oder „reject dec-4h2k“. Siehe Entscheidungen in Slack beantworten.
Aufnahme	Eine Antwort in der Aufnahme des Teams, die die Entscheidung nennt, zum Beispiel „approve dec-4h2k“.
REST-API	`POST /v1/decisions/<decision-key>/resolve` mit einem Token mit der Berechtigung `write`. Siehe unten.

Die erste Antwort gilt. Wer als Zweites antwortet, erfährt, dass die Entscheidung schon getroffen ist. Jede Antwort schreibt einen Audit-Eintrag decision_resolved mit Person und Kanal; die Entscheidung zeigt, ob sie über die App, Slack, den MCP-Server oder die API getroffen wurde.

Arten

Art	Entsteht, wenn
`plan_approval`	Die Richtlinie für diese Story eine Plan-Freigabe verlangt.
`policy_exception`	Die Story etwas braucht, das die Richtlinie nicht erlaubt, zum Beispiel einen gesperrten Pfad.
`clarification`	Der Coding-Agent über `request_human_input` eine Frage gestellt hat.
`budget_stop`	Der Run sein Budget erreicht hat.
`verification_failed`	Die Prüfung nach dem automatischen Nacharbeitsversuch gescheitert ist.
`gate_failure`	Für die Story keine funktionierende Akzeptanz-Spec geschrieben werden konnte.
`diff_guard`	Die Umsetzung die Akzeptanz-Spec verändert hat.
`repeated_gate_failure`	Ein Gate öfter gescheitert ist, als `gate_failure_budget` erlaubt.
`merge_approval`	Eine geprüfte Änderung größer ist, als die Richtlinie automatisch mergen lässt.
`revert_approval`	Ein Merge von kanman den Hauptbranch gebrochen hat und kanman einen Revert vorschlägt.
`main_red_incident`	Der Hauptbranch rot ist; Merges werden zurückgehalten.
`maintenance_proposal`	Der Wartungsmodus etwas gefunden hat, das eine Story wert ist.
`strategy_proposal`	kanman auf Grundlage der Strategienotizen Ihres Repositorys ein Feature vorschlägt.
`scope_change`	Die Story gut umzusetzen hieße, ihren Umfang zu ändern.

Optionsaktionen

Aktion	Wirkung
`approve_plan`	Der Plan ist freigegeben; die Umsetzung beginnt.
`request_changes`	Der Run läuft mit Ihrer Notiz als Vorgabe weiter.
`allow_once`	Die Ausnahme gilt nur für diesen Run.
`reject`	Der Run endet, und die Story geht mit Ihrer Notiz zurück ins Backlog.
`raise_budget`	Das Run-Budget wird erhöht, standardmäßig auf das Doppelte, und der Run läuft weiter.
`abandon`	Der Run endet, und die Story geht zurück ins Backlog.
`revert_spec_and_retry`	kanman stellt die Akzeptanz-Spec wieder her und startet einen neuen Versuch.
`retry`	Ein neuer Versuch startet, mit Ihrer Notiz als Hinweis.
`answer`	Ihre Antwort geht an den Coding-Agenten, und der Run läuft weiter.
`merge`	Der Pull Request wird gemergt.
`open_revert`	kanman öffnet einen Revert-Pull-Request.
`accept_proposal`	Der Vorschlag wird als Story angelegt oder geht in die Aufnahme.
`decline_proposal`	Der Vorschlag wird abgelehnt und gemerkt.

REST-API

Entscheidungen auflisten

GET /v1/decisions liefert die Entscheidungen des Workspaces, die neuesten zuerst, seitenweise. Filtern Sie mit status (pending, resolved, expired, cancelled, superseded), team (Team-Slug) und run (Run-Schlüssel).

curl "https://api.kanman.ai/functions/v1/api-gateway/v1/decisions?status=pending" --header "Authorization: Bearer $KANMAN_API_KEY"

Feld	Beschreibung
`key`, `kind`, `authority`, `title`, `body`	Die Entscheidung; `body` enthält kanmans Begründung als Markdown.
`status`, `recommendation`	Der Zustand und die ID der Option, die kanman empfiehlt.
`options`	`id`, `label`, `action` und `recommended` pro Option.
`team`, `story`, `runKey`	Wozu die Entscheidung gehört.
`resolution`, `resolvedVia`, `resolvedAt`	Die Antwort (`optionId`, `note`) und ihr Kanal, sobald beantwortet.
`expiresAt`, `createdAt`	Zeitstempel.

GET /v1/decisions/{decision-key} liefert eine Entscheidung in derselben Form.

Eine Entscheidung über die API beantworten

POST /v1/decisions/{decision-key}/resolve braucht ein Token mit der Berechtigung write. Die Antwort wird mit der Person, der das Token gehört, als Antwortender und api als Kanal festgehalten und wirkt genauso wie eine Antwort in der App.

curl -X POST https://api.kanman.ai/functions/v1/api-gateway/v1/decisions/dec-4h2k/resolve \
  --header "Authorization: Bearer $KANMAN_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{"optionId": "approve", "note": "Looks good"}'

Feld im Body	Beschreibung
`optionId`	Pflicht. Die `id` einer der Optionen der Entscheidung.
`note`	Optional, bis zu 4.000 Zeichen. Wird wie eine Notiz in der App weitergegeben.

Die Antwort ist die aktualisierte Entscheidung plus effects, die Schritte, die kanman ausgeführt hat. 400 bedeutet, dass es die Option nicht gibt, 404, dass die Entscheidung nicht im Workspace des Tokens liegt, 409, dass sie schon beantwortet ist (die erste Antwort gilt).