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. Sie finden sie im Team unter Einstellungen > Richtlinie. Ä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.

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.

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 Akzeptanz-Spec Pflicht Standardmäßig gesperrte Pfade
Testphase (trial) Die erste Pilotwoche, 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 mehr Arbeit anlegen und übernehmen lassen 4 Menschen und kanman aus 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, Wartung und Takt, dazu die standardmäßig gesperrten Pfade und bei Testphase die Spec-Pflicht. 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, wechselt das Badge zum Beispiel zu Angepasst (basierend auf Ausgewogen). So ist immer klar, dass Sie vom Preset abweichen.

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

Bei der Wahl hilft Ein Preset wählen und anpassen.

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 Meldung. Sichtbar im Audit-Log write_ac (Akzeptanzkriterien schreiben), set_priority_in_band, link_duplicate, resequence, nudge_run
NOTIFY Handelt und hält einen Hinweis fest 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 (Wann kanman selbst handelt unter Einstellungen > Richtlinie, Erweitert) 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.

Kommt in einem späteren Release

Dass kanman die AUTO- und NOTIFY-Aktionen selbst ausführt (Duplikate verknüpfen und schließen, Stories aufteilen, das Backlog umsortieren, einen Run anstoßen oder pausieren) und dazu einzeilige Hinweise postet, kommt in einem späteren Release. Heute entscheidet die Tabelle, wann kanman anhält und fragt: Plan-Freigabe, Mergen, gesperrte Pfade, Repositorys, Größe der Änderung und Budget.

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