Richtlinien, Presets und Befugnisstufen

Jedes Team hat eine Richtlinie: was kanman anfassen darf, wie viel es ausgeben darf, wann ein Mensch freigeben muss und was es allein entscheiden darf.

Mit der Richtlinie legt ein Team die Regeln für kanman fest. Sie beantwortet vier Fragen: Was darf kanman anfassen, wie viel darf es ausgeben, wann muss ein Mensch freigeben, und welche Entscheidungen darf es allein treffen? Jede Prüfung gegen die Richtlinie wird protokolliert, Sie können also immer nachvollziehen, warum kanman etwas getan oder gelassen hat.

Jedes Team hat genau eine Richtlinie. Ihre Einstellungen verteilen sich auf die Einstellungsseiten des Teams, beginnend mit Einstellungen > Selbstständigkeit, wo Sie die Vertrauensstufe wählen und festlegen, wer bei jedem Schritt entscheidet. Ändern können sie nur Workspace-Admins, und jede Änderung steht im Audit-Log als policy_changed mit einer neuen Richtlinienversion. Jeder Run merkt sich die Version, mit der er gestartet ist.

Jedes Team benennt außerdem eine verantwortliche Person dafür, wie viel kanman selbst erledigt, am Ende von Einstellungen > Selbstständigkeit. Neue Teams beginnen mit der Person, die sie eingerichtet hat; Admins können jedes Mitglied des Workspaces benennen. Jede Richtlinienänderung im Audit-Log hält sowohl die Person fest, die sie vorgenommen hat, als auch die Person, die in diesem Moment verantwortlich war. So ist “Wer hat das erlaubt?” ein einziger Eintrag. Siehe responsible_user_id.

Was die Richtlinie abdeckt

Bereich Einstellungen Standard
Umfang allowed_repos, denied_paths, max_changed_files, max_changed_lines Pfade des Presets, 30 Dateien, 800 Zeilen
Executor und Modelle executor, fallback_executor, routing, billing_mode Claude Code, Über kanman abrechnen
Budgets budget_run_cents, budget_day_cents, budget_month_cents 2,00 EUR pro Run
Freigaben plan_approval, plan_approval_min_size, merge_policy, auto_merge_max_lines, authority_overrides Plan-Freigabe immer, ein Mensch mergt
Zeit und Last working_hours, max_concurrency jederzeit, 1 gleichzeitig
Secrets secret_names keine
Gate require_acceptance_spec, rework_attempts, gate_failure_budget Spec Pflicht (außer Testphase), 1 Nacharbeitsversuch, 3 Fehler
Persönlichkeit intake_scope, maintenance, cadence vom Preset gesetzt

Die Referenz der Richtlinien-Einstellungen listet jede Einstellung mit ihren Werten.

Secrets werden nur mit Namen aufgeführt. Ihre Werte bleiben in Ihren CI-Einstellungen oder Ihrem Vault und laufen nie über kanman.

Team-Einstellungen > Selbstständigkeit: die Vertrauensstufe mit den fünf Stufen und wer bei jedem Schritt vom Eingang bis live entscheidet

Presets

Sie müssen nicht jeden Regler selbst setzen. Fünf Presets bündeln sie nach Absicht:

Preset Für Parallelität Wer Arbeit anlegt Wartung Akzeptanzspezifikation Pflicht Standardmäßig gesperrte Pfade
Testphase (trial) Die erste Woche mit einem neuen Repository, Repositories ohne Specs 1 nur Menschen aus nein infra/**, **/*.tf, .github/workflows/**
Fokussiert (focused) kanman arbeitet nur an dem, was Menschen angelegt haben 1 nur Menschen aus ja wie Testphase
Ausgewogen (balanced) Die meisten Teams, empfohlener Standard 2 Menschen und kanman aus ja wie Testphase
Autonom (autonomous) Teams, die kanman innerhalb ihrer Grenzen selbst entscheiden lassen: eigene Pläne prüfen, freigeben, starten und mergen 4 Menschen und kanman wie eingestellt ja .github/workflows/**
Härtung (hardening) Teams, die stetige Wartungsarbeit wollen 2 Menschen und kanman an, 2 pro Tag ja wie Testphase

Presets ändern nur die “Persönlichkeits”-Regler: Parallelität, wer Arbeit anlegen darf, was kanman selbst entscheidet und wie oft es nach langen Runs sieht, dazu die standardmäßig gesperrten Pfade und bei Testphase die Spec-Pflicht. Die Rituale des Teams, das Scan-Intervall der Wartung und die Wartungseinstellungen bleiben beim Wechsel; Härtung schaltet die Wartung nur ein, wenn sie im Team aus ist. Die Sicherheit hängt nicht vom Preset ab: Sandbox, Outcome-Gate, Diff-Wächter und Clean-Room-Prüfung sind für alle gleich.

Sobald Sie einen Regler ändern, den ein Preset steuert, zeigt die Stufe zum Beispiel Ausgewogen, angepasst. So ist immer klar, dass Sie von der Stufe abweichen. Rituale und Wartung zählen nie.

Sie wählen das Preset beim Einrichten eines Teams (vorgeschlagen ist Ausgewogen) und können es jederzeit unter Einstellungen > Selbstständigkeit wechseln.

Bei der Wahl hilft Festlegen, wie viel kanman selbst erledigt.

Befugnisstufen

Jede Wahl, die kanman trifft, wird über eine feste Tabelle eingeordnet, im Code und nicht durch die Frage an ein Modell. Es gibt drei Stufen:

Stufe Was kanman tut Arten von Entscheidungen
AUTO Handelt ohne zu fragen. Sichtbar im Audit-Log; die Aktionen unter Was kanman selbst erledigt zeigen außerdem einen Hinweis mit Rückgängig write_ac (Akzeptanzkriterien schreiben), set_priority_in_band, link_duplicate, resequence, nudge_run
NOTIFY Handelt und hält einen Hinweis auf der Teamseite und in Slack fest, sieben Tage rückgängig zu machen close_duplicate, split_story, pause_thrashing_run
ESCALATE Hält an und fragt im Entscheidungseingang, mit Empfehlung und 2 bis 4 Optionen expand_scope, change_security_posture, touch_production_data, overspend, contradict_operator, touch_denied_path, plan_approval, merge

Drei Regeln machen das vorhersehbar:

  1. Unbekannte Arten gelten als NOTIFY. kanman handelt nie stillschweigend bei etwas, das die Tabelle nicht kennt.
  2. Risiko kann die Stufe nur anheben. Eine unumkehrbare Aktion, ein großer Wirkungsradius oder Kosten ab 20,00 EUR sind immer ESCALATE. Ein mittlerer Wirkungsradius oder Kosten ab 5,00 EUR sind mindestens NOTIFY.
  3. Teams können nur anheben. Mit authority_overrides (Kleine Aufräumarbeiten unter Einstellungen > Selbstständigkeit) heben Sie eine Art an, zum Beispiel split_story von NOTIFY auf ESCALATE. Absenken ist nie möglich.

Plan-Freigabe und Mergen erhalten ihre Grundstufe aus den Freigabe-Einstellungen, siehe Richtlinien-Einstellungen.

Was kanman selbst erledigt

Etwa alle 15 Minuten räumt kanman in jedem aktiven Team auf, mit höchstens fünf Aktionen pro Team und Durchgang. Pausierte Teams bleiben unberührt, und kanman schließt oder teilt nie eine Story, an der gerade ein Run arbeitet.

Art Stufe Was passiert
link_duplicate AUTO Zwei offene Stories in Backlog, Refining oder Ready sind ähnlich: kanman verknüpft sie als Duplikate.
close_duplicate NOTIFY Zwei offene Stories sind fast gleich: kanman verknüpft sie und schließt die neuere als Duplikat der älteren. Stammt die Story aus Ihrem Tracker, wird das Issue dort ebenfalls geschlossen, mit einem Kommentar.
split_story NOTIFY Eine Story der Größe L in Backlog oder Refining mit mindestens zwei Akzeptanzkriterien wird in 2 bis 4 kleinere Stories in derselben Spalte geteilt. Jeder Teil erhält seinen Anteil der Kriterien und behält den Demonstrate-Block; seine Akzeptanzspezifikation wird neu geschrieben. Die ursprüngliche Story wird geschlossen und mit ihren Teilen verknüpft. Bei Stories aus dem Tracker entstehen die Teile dort ebenfalls als Issues.
resequence AUTO Backlog und Ready werden nach Serviceklasse (zuerst Expedite, dann Fixtermin nach Fälligkeit, Standard, Wartung) und danach nach Priorität sortiert. Gleich eingestufte Stories behalten Ihre Reihenfolge, und sobald Sie von Hand umsortieren, behält kanman Ihre Reihenfolge bei.
nudge_run AUTO Ein Run, der seit 20 Minuten feststeckt, kommt erneut in die Warteschlange, höchstens zweimal.
pause_thrashing_run NOTIFY Ein Run, der innerhalb von zwei Stunden dreimal oder öfter neu gestartet ist, wird pausiert.

Ein Run, der auf eine Entscheidung wartet, wird nie angestoßen oder pausiert.

Hinweise. kanman sagt Ihnen jede Aktion im Chat des Teams, als Karte mit der Zeile, zum Beispiel “Ich habe SBX-14 als Duplikat von SBX-9 geschlossen.”, und den betroffenen Stories mit Key und Titel, sodass Sie auf einen Blick sehen, ob kanman richtig lag. NOTIFY-Hinweise erscheinen außerdem im Slack-Kanal des Teams für Entscheidungen, mit einem Link zurück. Aktionen, die Ihren Tracker ändern, erhalten immer einen Hinweis, auch bei AUTO-Arten. Jede Aktion steht als kanman_action im Audit-Log.

Rückgängig. Jede Hinweiskarte hat sieben Tage lang eine Schaltfläche Rückgängig, die jedes Mitglied des Workspaces nutzen kann. Rückgängig stellt alles wieder her: Die Story wird wieder geöffnet, Verknüpfungen oder Teile werden entfernt, die vorherige Reihenfolge kehrt zurück, oder der Run wird wieder fortgesetzt beziehungsweise pausiert. Hat sich die Story oder der Run inzwischen geändert, sagt kanman das und behält die Aktion bei. kanman wiederholt nie eine Aktion, die Sie rückgängig gemacht haben. Das Rückgängigmachen wird unter Ihrem Namen im Audit-Log festgehalten (kanman_action_undone).

Angehobene Stufen. Heben Sie eine Art auf ESCALATE an, fragt kanman zuerst im Entscheidungseingang, zum Beispiel “SBX-12 in 3 kleinere Stories teilen?” mit Mach das und So lassen. Stimmen Sie zu, handelt kanman sofort, und Sie können es weiterhin rückgängig machen. Lehnen Sie ab, fragt kanman für diese Story nicht noch einmal.

Die Sicherheitsuntergrenze

Manches kann keine Richtlinie ändern:

  • touch_production_data, change_security_posture und overspend sind immer ESCALATE.
  • .kanman/acceptance/** ist für Executors immer gesperrt, zusätzlich zu Ihren eigenen gesperrten Pfaden.
  • Sandbox, Diff-Wächter und Clean-Room-Prüfung sind in jedem Preset aktiv.

Eine Anhebung, die eine Stufe senken würde, hat keine Wirkung: Die strengere Stufe gilt immer.

Jede Prüfung wird protokolliert

Jede Richtlinienprüfung schreibt einen Eintrag policy_decision mit ihrem Ergebnis (allowed oder denied) ins Audit-Log. So beantworten Sie auch Monate später die Fragen “Warum hat kanman hier angehalten?” und “Wer hat das erlaubt?”. Executors können außerdem vorher fragen: Das MCP-Tool check_policy beantwortet “Darf ich infra/ anfassen?”, ohne etwas zu starten.

Verwandte Seiten

Zuletzt aktualisiert: January 1, 0001

kanman öffnen