Alles auf Ihren Runnern ausführen | kanman Dokumentation

Mit einem Self-hosted Runner findet die Codearbeit eines Runs in Ihrem Netz statt. Einige Schritte rund um den Run laufen standardmäßig trotzdem in der kanman Cloud: das Entwerfen von Stories aus einer Anforderung, das unabhängige Review, das Schreiben von Akzeptanzspezifikationen, die Wartungsscans und Aktionen im Repository wie das Öffnen des Pull Requests oder das Posten des Nachweispakets.

Alles auf unseren Runnern ausführen verlagert auch all diese Schritte auf Ihre Runner. Die kanman Cloud ruft dann für den Workspace nie einen Modellanbieter auf und liest oder schreibt nie eines Ihrer Repositories. Weder Quellcode noch Modellverkehr laufen über kanman.

Einschalten

Starten Sie mindestens einen Self-hosted Runner und geben Sie ihm den unten beschriebenen Modellzugang und das Token für Ihren Code-Host.
Öffnen Sie Einstellungen > Runner (/settings/runners).
Schalten Sie Alles auf unseren Runnern ausführen ein. Inhaber und Admins können das ändern; die Änderung steht im Audit-Log (Exportformat).

Beim Einschalten wechselt der Workspace auch auf Self-hosted Runs. Der Schalter kanman Cloud unter Einstellungen > KI-Anbieter, Advanced, bleibt aus, bis Sie diese Einstellung wieder ausschalten.

Screenshot folgt Einstellungen, Tab Runner mit eingeschaltetem Schalter Alles auf unseren Runnern ausführen und der Liste, was wo läuft

Was Ihre Runner brauchen

Variable	Bedeutung
`KANMAN_API_KEY`	Das API-Token des Workspaces, wie für jeden Runner
Modellzugang	Die Variablen Ihres Anbieterkontos, etwa Amazon Bedrock, Google Vertex AI, Microsoft Foundry, Azure OpenAI oder ein Schlüssel für Anthropic oder OpenAI. Siehe Modellzugang auf Self-hosted Runnern. Teams mit eigenem Schlüssel in kanman bekommen stattdessen für jeden Schritt diesen Schlüssel.
`GITHUB_TOKEN`	Token für Repositories auf GitHub oder GitHub Enterprise (`GITHUB_API_URL` für GitHub Enterprise)
`GITLAB_TOKEN`	Token für gitlab.com oder Ihr selbst betriebenes GitLab (`GITLAB_API_URL`, zum Beispiel `https://gitlab.example.com/api/v4`)
`RUNNER_JOBS`	Optional. Kommagetrennte Liste der Schrittarten, die dieser Runner übernimmt, etwa um Akzeptanzprüfungen auf einem größeren Host zu halten. Standard: alles, was er kann.
`RUNNER_JOB_CONCURRENCY`	Optional. Wie viele kurze Schritte (Entwürfe, Reviews, Aktionen im Repository) der Runner neben seinen Runs bearbeitet. Standard `2`.

Der Runner behält die Tokens für sich. Die kanman Cloud braucht in diesem Modus kein Token für Ihren Code-Host und nutzt keines.

Was wo läuft

Schritt	Wo er läuft
Coding-Runs, lokale Verifikation, Push und der Pull oder Merge Request	Ihr Runner
Akzeptanzprüfungen (Spec-Lauf, frische Umgebung, sauberer Checkout)	Ihr Runner
Schreiben der Akzeptanzspezifikation und das unabhängige Review	Ihr Runner, mit Ihrem Modellzugang. Den Diff liest der Runner selbst aus Ihrem Repository.
Entwürfe von Stories in der Aufnahme und Entwürfe aus dem Chat	Ihr Runner, mit Ihrem Modellzugang
Kommentare mit dem Nachweispaket, Commit-Status, CI-Ergebnisse, Merges	Ihr Runner, mit seinem Code-Host-Token
Prüfung des Akzeptanzmanifests und der Pull Request mit dem Startmanifest	Ihr Runner
Wartungsscans, die lesenden Reviewer, Strategievorschläge	Ihr Runner
Bündeln von Review-Hinweisen zu Konventionen	Ihr Runner
Teamkontext aus Links und Repositories sowie Antworten aus dem Teamkontext	Ihr Runner
Log-Abfragen bei Incidents (Kubernetes und Loki)	Ihr Runner
Board, Richtlinien, Entscheidungen, Audit-Log, Status der Runs, Berichte	kanman Cloud

Was genau die kanman Cloud erreicht

Die kanman Cloud speichert nur den Stand der Orchestrierung und was Ihre Runner zurückmelden:

die Stories, die Sie schreiben oder freigeben (Titel, Beschreibung, Akzeptanzkriterien, Demonstrate-Block), Entscheidungen, Richtlinien und Einstellungen,
Status und Fortschrittszeilen der Runs und die erste Zeile jeder Statusmeldung des Agenten (keine Eingaben oder Ausgaben seiner Werkzeuge, kein Protokoll seiner Arbeit), die Kosten sowie das Nachweispaket: Ergebnisse von Tests und Prüfungen, das Urteil des Reviewers je Kriterium mit Datei- und Zeilenangaben, Links zum Pull Request und zur CI,
die Namen und Zeilenzahlen der geänderten Dateien und die Commit-Liste eines Runs (keine Dateiinhalte),
den Text, den ein Runner für die eigenen Schritte von kanman zurückschickt: entworfene Stories, die geschriebene Akzeptanzspezifikation, das Urteil des Reviewers, Wartungsbefunde, Strategievorschläge und Antworten,
das Audit-Log, mit einem Eintrag für jeden Schritt, den ein Runner erledigt hat (Schritt, Runner und Ergebnis).

Für die Prompts dieser Schritte schickt kanman Ihrem Runner, was es ohnehin speichert (etwa eine Story und ihre Akzeptanzkriterien), und die Namen der Dateien oder Refs, die er lesen soll. Den Inhalt aus dem Repository ergänzt der Runner selbst. Code gelangt nie zu kanman, und kanman ruft für den Workspace nie einen Modellanbieter auf.

Wenn kein Runner online ist

Die Arbeit wartet. Nichts weicht auf die kanman Cloud aus.

Die Team-Seite zeigt Wartet auf einen Runner mit der Zahl der wartenden Schritte und einem Link zu Einstellungen > Runner.
Eine Anforderung in der Aufnahme zeigt, dass sie auf Ihren Runner wartet. Sobald ein Runner antwortet, öffnet sich der Entwurf von selbst.
Ein Run, dessen Review auf den Runner wartet, wird mit Wartet auf Ihren Runner geparkt; er läuft weiter, sobald der Runner antwortet, ohne einen Versuch zu verbrauchen.

Grenzen

Der Abgleich mit GitHub Issues oder GitLab Issues pausiert in diesem Modus, weil die Issues auf Ihrem Code-Host liegen. Nutzen Sie Jira oder das eigene Board von kanman als Tracker.
Teamkontext aus Confluence, Notion und hochgeladenen Dateien braucht Zugangsdaten oder Dateien, die nur kanman hat; ein Runner kann sie daher nicht indizieren. Links und Repositories funktionieren.
Log-Abfragen bei Incidents aus Datadog, CloudWatch und Sentry sind auf dem Runner noch nicht verfügbar; Kubernetes und Loki funktionieren.
Aktionen in Repositories auf anderen Hosts als GitHub und GitLab werden in diesem Modus noch nicht unterstützt.