Richtlinien-Einstellungen

Jedes Team hat genau eine Richtlinie. Sie legt fest, welche Repositorys und Pfade kanman berühren darf, welchen Executor und welche Modelle es nutzt, wie viel es ausgeben darf, wann ein Mensch freigeben muss und wie viel Arbeit parallel läuft. Die Ideen dahinter beschreibt Richtlinien, Presets und Befugnisstufen.

Sie bearbeiten die Richtlinie in der App unter Teams, Ihr Team, Einstellungen. Die Einstellungen verteilen sich auf diese Bereiche:

billing_mode und ai_config_id wählen Sie beim Einrichten des Teams. Die Schlüssel auf dieser Seite sind die Namen, die kanman im Audit-Log und im Richtlinien-Stand jedes Runs verwendet.

Wer sie ändern darf

Nur Workspace-Admins können eine Richtlinie ändern; andere Mitglieder sehen die Einstellungen nur lesend. Jede Änderung erhöht die version der Richtlinie um eins und schreibt einen Eintrag policy_changed mit den geänderten Werten sowie alter und neuer Version ins Audit-Log. Jeder Run speichert die Richtlinie, mit der er gestartet ist. So sehen Sie immer, welche Regeln für einen Run galten.

Umfang

Was kanman berühren darf.

allowed_repos

Typ: Liste
Standard: []
Erlaubt: {"provider": "github" oder "gitlab", "repoFullName": "org/repo", "branches": ["main"]}

Repositorys und Basis-Branches, an denen kanman arbeiten darf. Branch-Einträge sind Globs; ein Repository ohne Branch-Liste erlaubt jeden Basis-Branch. Eine leere Liste erlaubt gar kein Repository. Arbeit in einem nicht aufgeführten Repository hält mit einer Entscheidung policy_exception an.

denied_paths

Typ: Liste von Globs
Standard: aus dem Preset
Erlaubt: Glob-Muster, zum Beispiel infra/**

Pfade, die der Executor nicht ändern darf. kanman prüft sie, während der Executor arbeitet (über check_policy), und noch einmal am finalen Diff. Eine Änderung an einem gesperrten Pfad hält den Run mit einer Entscheidung policy_exception an. .kanman/acceptance/** ist zusätzlich immer gesperrt und lässt sich weder entfernen noch einmalig erlauben.

max_changed_files

Typ: Ganzzahl
Standard: 30
Erlaubt: ab 1

Höchstzahl der Dateien, die eine Änderung berühren darf. Größere Änderungen scheitern am Gate policy_diff.

max_changed_lines

Typ: Ganzzahl
Standard: 800
Erlaubt: ab 1

Höchstzahl hinzugefügter plus gelöschter Zeilen einer Änderung.

secret_names

Typ: Liste von Strings
Standard: []
Erlaubt: Variablennamen

Namen der Secrets, die der Executor erhalten darf. Die Werte bleiben in Ihrem CI oder Vault, gespeichert werden nur Namen. Eine Variable muss zusätzlich in ci_var_keys von .kanman/verify.json stehen.

Executor und Routing

Welcher Coding-Agent und welche Modelle die Arbeit machen.

executor

Typ: String
Standard: claude-code
Erlaubt: claude-code, codex

Der Coding-Agent, der Stories umsetzt. Unter Einstellungen > Executor als Claude Code oder Codex angezeigt.

fallback_executor

Typ: String oder null
Standard: null
Erlaubt: claude-code, codex

Der Executor, der einspringen soll, wenn der Haupt-Executor nicht verfügbar ist.

routing

Typ: Objekt
Standard: siehe unten

Modellstufe, Turn-Budget und Vorgehen je Komplexitätsklasse sowie die Reviewer-Einstellungen.

Standardwert:

{
  "trivial":  { "modelTier": "small",    "turnBudget": 60,  "ceremony": "none" },
  "routine":  { "modelTier": "mid",      "turnBudget": 120, "ceremony": "plan_self_review" },
  "complex":  { "modelTier": "flagship", "turnBudget": 200, "ceremony": "approaches_then_plan" },
  "reviewer": { "vendor": "different_from_executor", "modelTier": "mid" },
  "modelOverrides": {}
}

Standardmodelle je Stufe:

Die Namen für Claude Code zeigen immer auf das aktuelle Modell der jeweiligen Familie. modelOverrides legt ein Modell je Komplexitätsklasse (zum Beispiel "routine"), je Stufe (zum Beispiel "mid") oder für den "reviewer" fest; ein Eintrag für die Klasse hat Vorrang vor einem für die Stufe. Mit "vendor": "different_from_executor" nutzt der Reviewer das Modell des anderen Anbieters in seiner Stufe: Code von Claude Code prüft ein Codex-Modell und umgekehrt.

In der App ändern Sie Modellstufe und Turn-Budget (1 bis 1000) je Klasse unter Einstellungen > Richtlinie, Erweitert.

billing_mode

Typ: String
Standard: pass_through
Erlaubt: byok, pass_through

Wer den Modellanbieter bezahlt: Ihr eigener Vertrag (byok) oder kanman, abgerechnet zu Kosten plus 15 Prozent (pass_through). Gewählt bei der Einrichtung des Teams und angezeigt unter Einstellungen > Budgets.

ai_config_id

Typ: Verweis oder null
Standard: null
Erlaubt: Der unter Einstellungen > KI-Anbieter gespeicherte Schlüssel

Der Anbieterschlüssel für byok. Claude Code arbeitet mit einem Schlüssel für Anthropic oder Amazon Bedrock, Codex mit einem für OpenAI oder Azure OpenAI. Ein Run mit fehlendem, inaktivem oder unpassendem Schlüssel schlägt mit einer klaren Meldung fehl, statt auf die Abrechnung über kanman auszuweichen.

Budgets

Alle Beträge sind in Euro-Cent angegeben. Budgets sind harte Grenzen. Arbeit mit der Serviceklasse expedite und Störungsbehebung werden nie durch Budgets gestoppt.

budget_run_cents

Typ: Ganzzahl
Standard: 200 (2,00 EUR)
Erlaubt: ab 1

Höchstkosten eines Runs über alle Versuche. Ist es erreicht, stoppt der Run mit Gestoppt: Budget erreicht, es entsteht kein Pull Request, und eine Entscheidung budget_stop bietet an, das Run-Budget zu verdoppeln.

budget_day_cents

Typ: Ganzzahl oder null
Standard: null (kein Limit)
Erlaubt: ab 1

Höchstausgaben des Teams pro Tag, in der Zeitzone von working_hours (UTC, wenn nicht gesetzt). Ist es aufgebraucht, startet bis zum nächsten Tag kein neuer Run.

budget_month_cents

Typ: Ganzzahl oder null
Standard: null (kein Limit)
Erlaubt: ab 1

Höchstausgaben des Teams pro Kalendermonat, in derselben Zeitzone. Ist es aufgebraucht, startet bis zum nächsten Monat kein neuer Run.

Freigaben

Wann ein Mensch zustimmen muss. Nur unter Einstellungen > Freigaben bearbeitbar.

plan_approval

Typ: String
Standard: always
Erlaubt: always, by_size, never

Wann ein Mensch den Plan freigeben muss, bevor Code entsteht. Der Run plant zuerst nur lesend, und der Plan kommt als Entscheidung plan_approval.

plan_approval_min_size

Typ: String oder null
Standard: null
Erlaubt: S, M, L

Mit by_size: Stories dieser Größe oder größer brauchen eine Freigabe. Ohne Wert, oder bei einer Story ohne Größe, braucht jeder Plan eine Freigabe.

merge_policy

Typ: String
Standard: human
Erlaubt: human, auto_if_small

Wer mergt. Mit human bleibt die Story mit einem mergebaren Pull Request im Review, bis ein Mensch ihn mergt. auto_if_small mergt automatisch, wenn alle Gates bestanden sind und die Änderung nicht größer als auto_merge_max_lines ist; größere Änderungen erzeugen eine Entscheidung merge_approval. Solange Ihr Main-Branch rot ist, hält kanman automatische Merges an.

auto_merge_max_lines

Typ: Ganzzahl oder null
Standard: null
Erlaubt: ab 1

Mit auto_if_small: die größte Änderung in Zeilen, die automatisch gemergt werden darf.

authority_overrides

Typ: Objekt
Standard: {}
Erlaubt: {"<kind>": "NOTIFY"} oder "ESCALATE"

Hebt die Befugnisstufe einzelner Entscheidungsarten an. Siehe Befugnistabelle. In der App heißt das Wann kanman selbst handelt unter Einstellungen > Richtlinie, Erweitert, mit den Stufen Standard, Informiere mich und Frag mich vorher.

Arbeitszeiten und Parallelität

Wann und wie viel kanman arbeitet.

working_hours

Typ: Objekt oder null
Standard: null (immer)
Erlaubt: {"tz", "days", "start", "end"}

Wann neue Runs starten dürfen, zum Beispiel {"tz": "Europe/Berlin", "days": [1,2,3,4,5], "start": "08:00", "end": "19:00"}. Tage von 1 (Montag) bis 7 (Sonntag). Laufende Runs laufen zu Ende. Dringende Stories (expedite) und Störungen starten auch außerhalb der Arbeitszeiten.

max_concurrency

Typ: Ganzzahl
Standard: 1
Erlaubt: 1 bis 20

Wie viele Runs dieses Teams gleichzeitig aktiv sein dürfen. Der wirksame Wert ist durch den Tarif des Teams begrenzt: Pilot 3, Team 5, Self-hosted 20 und 1 für ein Team ohne Tarif. Stories warten in Ready, bis ein Platz frei wird.

is_paused

Typ: Boolean
Standard: false
Erlaubt: true, false

Ein pausiertes Team startet keine neuen Runs, laufende Runs laufen zu Ende. Sie setzen das mit kanman für dieses Team pausieren unter Einstellungen > Arbeitszeiten oder bitten kanman auf der Anforderungsseite des Teams darum, zum Beispiel mit “pausiere das Team”.

Gates

Wie streng das Outcome-Gate ist. Das Gate selbst, der Diff-Wächter und die Clean-Room-Prüfung lassen sich nicht abschalten.

require_acceptance_spec

Typ: Boolean
Standard: true
Erlaubt: true; false nur mit dem Preset Testphase (trial)

Ob eine Story eine rote Akzeptanz-Spec braucht, bevor sie Ready erreicht. Mit false nutzt kanman CI, den Testplan und den Reviewer-Run, und das Nachweispaket sagt, dass kein Ergebnisnachweis vorliegt. false mit einem anderen Preset wird abgelehnt mit Nur das Preset Testphase kann ohne Akzeptanzspezifikationen arbeiten.

rework_attempts

Typ: Ganzzahl
Standard: 1
Erlaubt: 0, 1

Automatische Nacharbeit nach einer fehlgeschlagenen Prüfung, mit der Gate-Ausgabe und den Befunden des Reviewers als Eingabe. Mit 0 geht eine fehlgeschlagene Prüfung direkt in den Entscheidungseingang.

gate_failure_budget

Typ: Ganzzahl
Standard: 3
Erlaubt: 1 bis 10

Wie viele Fehlschläge desselben Gates eine Story über alle ihre Runs und Versuche sammeln darf, bevor kanman den Run parkt und mit einer Entscheidung Wiederholt fehlgeschlagene Prüfung fragt. Ausfälle der Testumgebung selbst zählen nicht.

Persönlichkeits-Einstellungen

Diese Einstellungen ändern die Presets, zusammen mit max_concurrency und den standardmäßig gesperrten denied_paths.

preset_id

Typ: String
Standard: trial
Erlaubt: trial, focused, balanced, autonomous, hardening

Das Preset, auf dem die Richtlinie beruht. Siehe Presets. Die Team-Einrichtung schlägt Ausgewogen (balanced) vor.

is_custom

Typ: Boolean
Standard: false
Erlaubt: nur lesbar

true, sobald eine Einstellung vom Preset abweicht. Die App zeigt dann “Angepasst (basierend auf Ausgewogen)”.

intake_scope

Typ: String
Standard: humans_and_kanman
Erlaubt: humans_only, humans_and_kanman

Wer die Stories anlegen darf, an denen kanman arbeitet.

• humans_only: kanman arbeitet nur an Stories, die Menschen angelegt haben. kanman legt selbst nie eine Story an: Bei eingeschalteter Wartung wartet jeder Fund als Vorschlag unter Entscheidungen, und erst wenn eine Person ihn annimmt, entsteht die Story.
• humans_and_kanman: kanman darf auch selbst Stories anlegen. Bei eingeschalteter Wartung werden Funde der erlaubten Arten (allowedKinds) ohne Rückfrage als Wartungs-Stories angelegt; alle anderen Funde warten weiterhin als Vorschlag.

Stories aus der Aufnahme gibt immer eine Person frei, bevor sie in den Tracker geschrieben werden, unabhängig von dieser Einstellung.

maintenance

Typ: Objekt
Standard: {"enabled": false, "dripPerDay": 0, "maxPerRun": 1, "allowedKinds": []}

Wartungsmodus: an oder aus, wie viele Wartungs-Stories und Vorschläge pro Tag angelegt und gestartet werden dürfen, wie viele Funde ein Scan höchstens anlegt und welche Arten ohne Rückfrage zu Stories werden. Eingeschaltet wird er derzeit über das Preset Härtung (hardening).

cadence

Typ: Objekt
Standard: {"reportWeekday": 1, "loopDoctorMinutes": 15, "scannerDays": 7}

Wochentag des Team-Berichts (1 = Montag), wie oft die Prüfung auf festgefahrene Runs die Runs des Teams ansieht und wie oft die Wartungs-Scanner für das Team laufen. Die Prüfung auf festgefahrene Runs läuft derzeit für jedes Team alle 15 Minuten.

Presets

Presets ändern nur die Persönlichkeits-Einstellungen und die standardmäßig gesperrten Pfade. Sicherheitseinstellungen (Sandbox, Diff-Wächter, Clean-Room-Prüfung, immer gesperrte Pfade) sind für jedes Preset gleich.

Härtung erlaubt die Wartungsarten cve, outdated_dep, unused_dep, lockfile_drift und broken_doc_link. Alle Presets nutzen cadence {"reportWeekday": 1, "loopDoctorMinutes": 15, "scannerDays": 7}.

Sie wählen das Preset unter Einstellungen > Richtlinie. Der Wechsel gilt sofort; ist das Team angepasst, fragt kanman vorher, weil Ihre Änderungen an diesen Einstellungen ersetzt werden. Budgets, Freigaben, Arbeitszeiten, Routing und Befugnis-Anhebungen gehören nicht zum Preset und bleiben erhalten.

Befugnistabelle

Jede Entscheidung, die kanman trifft, hat eine Art, und jede Art hat eine Grundstufe. Die Tabelle ist fester Code, kein Prompt.

Regeln:

• Unbekannte Arten gelten als NOTIFY.
• Risiko hebt die Stufe nur an: Eine nicht umkehrbare Aktion, ein großer Wirkungsbereich oder Kosten ab 20,00 EUR machen sie zu ESCALATE; ein mittlerer Wirkungsbereich oder Kosten ab 5,00 EUR machen sie mindestens zu NOTIFY.
• authority_overrides kann eine Art nur anheben, nie absenken.
• touch_production_data, change_security_posture und overspend sind immer ESCALATE (Sicherheitsuntergrenze).
• plan_approval und merge erhalten ihre Grundstufe aus den Freigabe-Einstellungen (plan_approval, merge_policy); eine Anhebung kann sie nur strenger machen.

Beispiel: kanman soll immer fragen, bevor es Duplikate verknüpft:

{
  "authority_overrides": {
    "link_duplicate": "ESCALATE"
  }
}

Eine Anhebung, die eine Stufe senken würde (zum Beispiel "merge": "NOTIFY", während ein Mensch mergt), hat keine Wirkung: Die strengere Stufe gilt immer. Andere Werte als NOTIFY und ESCALATE werden ignoriert.

Vollständiges Beispiel

{
  "preset_id": "balanced",
  "is_custom": true,
  "version": 7,
  "allowed_repos": [
    { "provider": "github", "repoFullName": "acme/billing", "branches": ["main"] }
  ],
  "denied_paths": ["infra/**", "**/*.tf", ".github/workflows/**", "migrations/**"],
  "max_changed_files": 30,
  "max_changed_lines": 800,
  "executor": "claude-code",
  "fallback_executor": null,
  "billing_mode": "pass_through",
  "ai_config_id": null,
  "budget_run_cents": 300,
  "budget_day_cents": 3000,
  "budget_month_cents": 40000,
  "plan_approval": "by_size",
  "plan_approval_min_size": "M",
  "merge_policy": "human",
  "auto_merge_max_lines": null,
  "authority_overrides": {},
  "working_hours": { "tz": "Europe/Berlin", "days": [1, 2, 3, 4, 5], "start": "08:00", "end": "19:00" },
  "max_concurrency": 2,
  "secret_names": [],
  "require_acceptance_spec": true,
  "rework_attempts": 1,
  "gate_failure_budget": 3,
  "intake_scope": "humans_and_kanman",
  "maintenance": { "enabled": false, "dripPerDay": 0, "maxPerRun": 1, "allowedKinds": [] },
  "cadence": { "reportWeekday": 1, "loopDoctorMinutes": 15, "scannerDays": 7 },
  "is_paused": false
}

Verwandte Seiten

• Richtlinien, Presets und Befugnisstufen
• Preset wählen und anpassen
• Budgets und Kosten
• Entscheidungen