Code-Review

kanman beteiligt sich am Code-Review wie ein guter Kollege. Sein unabhängiger Reviewer liest die Pull- und Merge-Requests deines Teams und hinterlässt klare, konkrete Kommentare. Wenn Menschen kanmans eigene Arbeit prüfen, liest es ihre Kommentare und handelt danach. Beides funktioniert mit GitHub und GitLab.

Merge-Requests von Menschen prüfen

Das Reviewen ist die eingebaute Habit Merge Requests reviewen im Reiter Habits des Teams (/<workspace>/teams/<team>/habits/review-merge-requests). Sie zeigt, wann kanman prüft, und die letzten Reviews, jeweils mit Link zum Merge-Request. Ändere sie, indem du es kanman im Chat des Teams sagst:

Ändern können sie nur die Owner und Leads des Teams. kanmans eigene GitHub- und GitLab-Konten stellst du unter Team > Verbindungen > Meine Konten und Erwähnungen ein (siehe Erwähnungen und Zuweisungen). Weitere Namen, die als kanman gelten, zum Beispiel ein GitHub-Team namens kanman, stehen unter Team > Budget und Grenzen, Weitere Optionen, Reviewer meiner Merge Requests.

kanman prüft jeden neuen Commit einmal. Wenn die Autorin erneut pusht, prüft kanman den neuen Stand und wiederholt sich nicht.

Was ein Review enthält

kanmans Reviewer checkt die Änderung aus, liest den Diff, führt die passenden Tests aus und berücksichtigt, was deine CI und deine Scanner bereits gemeldet haben (Linter, Security-Scanner, SonarQube). Dann ordnet er seine Befunde ein:

• Blockierend: etwas, das sich vor dem Merge ändern muss, zum Beispiel falsches Verhalten, ein entfernter oder abgeschwächter Test oder ein Sicherheitsbefund, den die Änderung verursacht. Alle blockierenden Befunde stehen zusammen in einem Review-Kommentar: „Changes requested: 2 blocking findings“, jeweils mit Fundstelle, Begründung und Vorschlag zur Behebung.
• Should und Nit: kleinere Punkte, jeweils als Kommentar an der Zeile.

Wenn nichts blockiert, sagt der Review-Kommentar das. Jeder Kommentar ist als von kanman, einem KI-Agenten, geschrieben gekennzeichnet.

Was kanman an deinen Merge-Requests nie tut

kanman kommentiert nur. Es genehmigt, pusht oder mergt nie den Merge-Request einer Person: Die Autorin oder der Autor entscheidet und mergt. Diese Grenzen setzt kanman selbst durch, sie sind nicht nur versprochen. Jedes Review bleibt in den Tokens pro Review des Teams.

Im Team-Chat

Nach einem Review sagt kanman es im Team-Chat in einer Zeile, zum Beispiel „Ich habe den MR web !12 von Bob geprüft: 2 blockierende Befunde“. Der Merge-Request ist ein Link.

Review-Kommentare zu kanmans eigener Arbeit

Wenn Menschen einen Pull- oder Merge-Request prüfen, den kanman geöffnet hat, liest kanman jeden Kommentar und handelt wie ein Kollege: Es behebt Eindeutiges auf demselben Branch, beantwortet Fragen und fragt nach, wenn ein Mensch entscheiden sollte. kanmans eigene Merge-Requests prüft sein unabhängiger Reviewer, bevor sie gemergt werden (siehe Wie kanman seine Arbeit prüft), egal, was die Habit oben sagt.

Freigabe durch einen Menschen vor dem Merge

Manche Teams wollen, dass ein Mensch jede Änderung freigibt, bevor sie landet, zum Beispiel weil ihr Softwareprozess ein Vier-Augen-Prinzip verlangt. Unter Freigabe vor dem Merge in Team > Budget und Grenzen wählst du:

Wenn eine Freigabe Pflicht ist:

• Nur ein Mensch zählt. Freigaben von kanmans eigenen Konten, von Bots oder von Personen ohne Schreibrechte zählen nicht. In GitHub muss die Freigabe für den neuesten Commit gelten, und eine offene Änderungsanfrage stoppt den Merge.
• kanman fragt dein Team im Team-Chat mit einem Link zum Merge-Request und wartet. Die Frage erscheint auch dort, wo dein Team sieht, was auf wen wartet, und erreicht die Personen über ihre Benachrichtigungseinstellungen. kanman fragt einmal pro Änderung.
• Eine Freigabe pro Welle. Wenn kanman dieselbe Änderung in vielen Repositories macht (zum Beispiel ein Abhängigkeits-Update), gibt das Team einen Merge-Request frei, und diese Freigabe deckt die anderen mit genau derselben Änderung ab. Jeder Merge-Request wird trotzdem nur mit grüner CI gemergt.
• Antworte Diese Änderung nicht mergen, um sie zu stoppen. kanman lässt die Merge-Requests offen und fragt, was sich ändern soll.

Workspace-Owner und -Admins legen die Vorgabe für alle Teams in Workspace-Einstellungen > Audit (/<workspace>/settings/audit) unter Merges brauchen eine menschliche Freigabe fest. Sie ist aus, bis du sie einschaltest.

Einen Reviewer für kanmans Arbeit anfragen

Mit Eine Person mit Codekenntnis um ein Review bitten in Team > Budget und Grenzen (unter Weitere Optionen, Reviewer meiner Merge Requests) bittet kanman für jeden Pull- oder Merge-Request, den es öffnet, einmal eine Person im Team um ein Review. Es wählt jemanden, der zuletzt an den geänderten Dateien gearbeitet hat und Schreibrechte im Repository hat. Es fragt nie die Autorin, seine eigenen Konten oder Bots und fragt niemanden, wenn schon ein Reviewer gesetzt ist. Das ist aus, bis du es einschaltest, weil kanman dabei Menschen auf deinem Code-Host kontaktiert.

GitLab hinter einem VPN

Ein GitLab, das nur dein Runner erreicht, kann kanman keine Webhooks schicken. @kanman review und Zuweisungen funktionieren trotzdem: kanman sucht alle paar Minuten über deinen Runner danach. Jeden Merge-Request zu prüfen braucht die Merge-Request-Ereignisse eines Webhooks. Der Code bleibt auf deinem Runner: Der Reviewer liest ihn dort, nur die Kommentare verlassen dein Netz. Siehe GitLab hinter einem VPN.