admin-valentin/agent-ecosystem
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
agent-ecosystem/landing/product-docs/de/guide/code-review.md
777genius 95e0f34d31 docs(product-docs): add zh, es, ja, fr, de doc translations 
Localize the VitePress docs into Simplified Chinese, Spanish, Japanese,
French and German (18 pages each), mirroring the existing en/ru structure.

- generate the 5 new locales in config.ts from a single strings table
  (nav, sidebar, search, footer, docFooter, outline, editLink) with
  locale-prefixed links
- rework DocsCardGrid from the binary isRu check to a per-locale map so
  the home cards render translated copy and prefixed links for every locale
2026-05-31 17:50:54 +03:00

6.5 KiB
Raw Blame History

title description lang
Code-Review – Agent Teams Dokumentation Aufgabenbezogene Diffs prüfen, Hunks akzeptieren oder ablehnen, Inline-Kommentare hinterlassen und Review-Zustände von none bis approved verwalten. de-DE

Code-Review

Code-Review in Agent Teams ist aufgabenzentriert. Sie prüfen, was sich für eine bestimmte Aufgabe geändert hat, anstatt einen großen unstrukturierten Diff zu durchsuchen.

Review-Oberfläche

Für jede abgeschlossene Aufgabe, die Dateien berührt hat, ermöglicht Ihnen die Review-Oberfläche Folgendes:

  • Geänderte Dateien mit Kontext vorher/nachher prüfen
  • Einzelne Hunks akzeptieren oder ablehnen
  • Inline-Kommentare hinterlassen
  • Den Diff mit der Aufgabenbeschreibung und den Agent-Logs verknüpfen

Entscheidungen auf Hunk-Ebene

Akzeptieren Sie kleine korrekte Änderungen und lehnen Sie isolierte Fehler ab, ohne die gesamte Aufgabe zu verwerfen. Das ist nützlich, wenn ein Agent die Aufgabe größtenteils gelöst, aber in einer Datei über das Ziel hinausgeschossen ist.

::: tip Schrittweise akzeptieren Wenn ein Diff größtenteils korrekt ist, akzeptieren Sie zuerst die guten Hunks und fordern Sie nur für die Teile Änderungen an, die korrigiert werden müssen. So bleibt das Board in Bewegung. :::

Nutzen Sie Entscheidungen auf Hunk-Ebene für:

Situation Aktion
Korrekte, eng begrenzte Änderung Den Hunk akzeptieren
Korrekte Idee, falsche Datei oder breites Refactoring Den Hunk ablehnen und eine engere Korrektur anfordern
Unklare Verhaltensänderung Kommentieren und um Verifizierung bitten
Generiertes Formatierungsrauschen Ablehnen, sofern die Formatierung nicht Teil der Aufgabe war

Review starten

  1. Öffnen Sie eine abgeschlossene Aufgabe
  2. Sehen Sie sich den Tab Changes an
  3. Wenn der Diff angemessen aussieht, klicken Sie auf Request Review, um die Aufgabe in die Review-Spalte zu verschieben

Während des Reviews gilt die Aufgabe noch nicht als done, sodass andere Teammitglieder oder der Lead sie weiterhin kommentieren können.

Review-Schleife

Eine gesunde Review-Schleife sieht so aus:

  1. Der Eigentümer postet einen Ergebniskommentar mit dem geänderten Umfang und der Verifizierung
  2. Der Reviewer öffnet den Aufgaben-Diff und prüft die Hunks anhand der Aufgabenbeschreibung
  3. Der Reviewer akzeptiert gute Hunks, lehnt schlechte Hunks ab oder fordert Änderungen an
  4. Der Eigentümer korrigiert nur den angeforderten Umfang und postet einen Folgekommentar
  5. Der Reviewer genehmigt, wenn Aufgabenergebnis und Diff übereinstimmen

Beispiel für einen Kommentar mit Änderungsanforderung:

Please keep the copy improvements, but revert the unrelated runtime wording in the provider table. Add the `pnpm --dir landing docs:build` result before resubmitting.

Review-Zustände

Zustand Bedeutung
none Aufgabe ist neu, in Bearbeitung oder abgeschlossen, aber noch nicht im Review
review Die Aufgabe befindet sich aktiv im Review
needsFix Es wurden Änderungen angefordert; der Eigentümer muss vor der erneuten Genehmigung aktualisieren
approved Das Review wurde akzeptiert und die Aufgabe ist abgeschlossen

Agent-Review-Workflow

Teams können die Arbeit der jeweils anderen prüfen, bevor Sie die endgültige Entscheidung treffen. Das fängt offensichtliche Regressionen ab und hält das Board ehrlich, aber Sie sollten riskante Bereiche dennoch selbst überprüfen.

Ein Agent-Review ist am nützlichsten, wenn der Reviewer ein klares Bewertungsraster hat. Weisen Sie einen Reviewer beispielsweise an, nur die Verständlichkeit der Dokumentation, nur die IPC-Sicherheit oder nur die Testabdeckung zu prüfen. Breite Aufforderungen wie "alles überprüfen" führen tendenziell zu schwächerem Feedback.

MCP-gesteuerter Review-Zustand

Änderungen des Review-Zustands (Review anfordern, Änderungen anfordern, genehmigen) sind tool-gesteuert. Das Hinterlassen eines Kommentars mit Änderungsanforderung an einer Aufgabe verschiebt die Kanban-Spalte nicht auf needsFix — ein Lead oder Agent muss das passende MCP-Tool aufrufen:

  • review_request_changes — verschiebt die Aufgabe auf needsFix und benachrichtigt den Eigentümer
  • review_approve — verschiebt die Aufgabe auf approved und schließt das Review ab

Kommentare allein reichen für Zustandsübergänge nicht aus. Die vollständige Liste der Review-MCP-Tools und ihrer Parameter finden Sie unter MCP-Integration.

Review-Teilnehmer

Der Team-Lead ist der Standard-Reviewer. Sie können in den Kanban-Einstellungen zusätzliche Reviewer konfigurieren, wenn Sie möchten, dass Kollegen die Arbeit der jeweils anderen prüfen.

Was manuell zu prüfen ist

Priorisieren Sie diese Bereiche beim Review:

  • Anbieter-Authentifizierung und Runtime-Erkennung — hat der Agent die Runtime-Einrichtung so geändert, dass andere Pfade dadurch beeinträchtigt würden?
  • IPC-, Preload- und Dateisystemgrenzen — halten Sie die Electron-Zuständigkeiten getrennt
  • Git- und Worktree-Verhalten - überprüfen Sie Branch-Benennung, Commits und Pushes; siehe Git- und Worktree-Strategie für Isolationsmuster.
  • Parsing- und Aufgabenlebenszyklus-Logik — Änderungen an Aufgabenreferenzen, Chunking oder Filterung können die Nachrichtenzustellung beeinträchtigen
  • Persistenz- und Code-Review-Abläufe — Änderungen am Aufgabenspeicher oder Review-Zustand müssen über die IPC-Schichten hinweg konsistent bleiben

Den kanonischen Feature-Aufbau und Links zu den harten Guardrails finden Sie unter Architektur für Mitwirkende.

Verifizierung

Bevorzugen Sie gezielte Verifizierungsbefehle. Breite Formatierungs- oder Lint-Fix-Befehle sollten nicht verwendet werden, sofern die Aufgabe nicht ausdrücklich eine breite Formatierungsänderung beabsichtigt.

Gute Verifizierungskommentare enthalten den Befehl und das Ergebnis:

Verified with `pnpm --dir landing docs:build`. Build passed.

Wenn die Verifizierung übersprungen wird, sollte der Aufgabenkommentar den Grund nennen:

Docs-only wording change. Build not run because the existing dev server was busy; checked Markdown links manually.

::: warning Nicht projektweit automatisch formatieren Sofern es bei der Aufgabe nicht ausdrücklich um Formatierung geht, vermeiden Sie es, pnpm lint:fix auf nicht zugehörige Dateien auszuführen. Das erzeugt Rauschen in der Review-Oberfläche. :::