Review-Compute (Kohorten, Achsen und deterministische Diffs)

Der Tab Review eines PR ist der Live-Fortschritt der Review-Pipeline, solange sie arbeitet, und danach das Artefakt, das sie veröffentlicht hat, samt den Aktionen darauf. Ein Tab, zwei Zustände, weil es dasselbe zu zwei Zeitpunkten ist. Er ist kein Standard-Tab: Ein PR hat kein Review, bis jemand eines anfordert, und Ask AI öffnet ihn.

Hinter diesem Tab baut cc_server Kohorten aus Dateien, führt die deterministischen Achsen aus und liefert sie über die RPC-Operationen review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute und ihre watch*-Zwillinge). Ein gespeichertes Layout, das noch pr.reviewStudio heißt, öffnet denselben Tab Review.

Auf dem Tab Review:

Der konsolidierende Agent veröffentlicht mit publish_artifact ein gewöhnliches Unterhaltungsartefakt. Der Tab rendert es über denselben Artefakt-Viewer, den eine Chatblase öffnet. Eine eigens für Reviews gebaute Kopie des Artefaktsystems gibt es nicht.
Die Befunde sitzen in einer Leiste daneben, das Verdikt auf einer schmalen Leiste über dem Artefakt statt in einem Dashboard-Kopf.
Ein Banner erscheint, sobald der Head des PR über das Review hinaus weitergezogen ist und das Review damit veraltet ist.

Den Ablauf zeigt KI-gestützte Review nutzen, das Handeln danach Einen PR prüfen und mergen.

Kohorten

Kohorten fassen die geänderten Dateien des PR zu Gruppen zusammen, die der Inhalt herleitet: Dateien, die der Bedeutung nach zusammengehören, nach Wirkung sortiert, sodass die riskanteste Gruppe zuerst gelesen wird. Bei jedem Wechsel der Head-SHA werden sie neu berechnet und im Ganzen ersetzt. Jede Kohorte hat einen über Pushes stabilen Schlüssel, deshalb überstehen Zusammenfassung und Review-Fortschritt einen Rebase.

Ist das Repo nicht im Code-Index, fallen die Kohorten auf eine Gruppierung nach Pfaden zurück. Zum Indizieren öffnest du Einstellungen → Arbeitsbereich → Repositorys. Jede Repo-Zeile trägt die Aktion Code indizieren. Sie startet die Pipeline index_code und meldet den Fortschritt an Ort und Stelle.

Der Code-Graph parst nur Sprachen mit einer mitgelieferten Grammatik (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Ein Repo in jeder anderen Sprache erzeugt nie semantische Kohorten, egal wie oft du es indizierst.

Ein Agent kann mit set_cohort_summary eine Markdown-Zusammenfassung für eine Kohorte ablegen und mit add_review_diagram ein strukturiertes Walkthrough-Diagramm anhängen: ein typisiertes Objekt für Sequenz, Entity-Relation oder Zustandsmaschine, nie mermaid-Text. Jede Kante wird gegen den echten Code-Graph geprüft. Eine Kante, die der Graph nicht belegt, wird als ungeprüft markiert und nicht als Tatsache gezeichnet.

Die Achse API-Vertrag

Die Vertragsachse bildet nur von expliziten Spezifikationsdateien einen Diff. Sie trifft die sechs Standardnamen — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — und jede geänderte Datei, deren Name openapi oder swagger enthält und auf .yaml, .yml oder .json endet. Ein aus Handler-Code abgeleiteter Vertrag liegt außerhalb, und GraphQL-Schemas bekommen keinen Diff.

Jede Änderung wird eingeordnet: Ergänzung, Entfernung oder Änderung von Endpunkt, Parameter, Schema und Response. Sie trägt eine Schwere: breaking (entfernter Endpunkt oder Parameter, verschärfter Typ, neuer Pflichtparameter), non-breaking (additiv) oder informativ. Eine abgelehnte Änderung lässt das Vertrags-Gate fehlschlagen, ebenso eine Breaking-Änderung, die unentschieden bleibt. Breaking und genehmigt warnt. Ohne Breaking-Änderungen besteht das Gate. Ein Diff mit der Markierung abgeleitet (beratend) setzt nie ein Gate.

Genehmigen oder Ablehnen einer Änderung ist review_studio.setContractDecision.

Die visuelle Achse

Ändert der PR UI-Komponenten in einem Flutter-Repo mit einer Widgetbook-App, rendert der Compute-Durchgang die geänderten Komponenten davor und danach über einen headless Golden-Lauf mit flutter test in den Worktrees von Base und Head des PR und vergleicht dann die Pixel.

Snapshots mit changed oder removed halten das visuelle Gate, bis sie genehmigt sind. unchanged, added und approved heben es auf. Die Nichtverfügbarkeit hat einen von vier Gründen: „no Flutter SDK on host“, „no Widgetbook app in repo“, „no golden-testable use-cases“ oder „golden harness error“.

Eine beabsichtigte Änderung genehmigst du mit review_studio.approveVisual.

Die Achsen und das Verdikt

Achse	Angetrieben von
Korrektheit	Reviewer-Agenten (Token)
Sicherheit	Reviewer-Agenten (Token)
Testlücke	Reviewer-Agenten (Token)
Visuell	Deterministisch (Golden-Harness)
API-Vertrag	Deterministisch (Spec-Diff)

Die drei Token-Achsen werden aufgezeichnet, wenn ein Lead-Agent finalize_review aufruft. Die beiden deterministischen Achsen zeichnet der Compute-Durchgang auf.

Jede Achse meldet einen dieser Zustände:

Zustand	Bedeutung
Pass	Lief, nichts Blockierendes gefunden
Warn	Lief, mit nicht blockierenden Einwänden
Fail	Lief und fand ein blockierendes Problem
Partial	Lief, kam aber nicht zu Ende; die Ergebnisse sind unvollständig
Unavailable	Konnte gar nicht laufen

Nur pass und warn heben eine Achse mit Gate auf. Partial und unavailable sind absichtlich von fail getrennt, und keines von beiden hebt ein Gate auf.

Die Achsen gehen in Ship, Hold oder Block auf, und sie können das Verdikt nur strenger machen. Herabgestuft wird es nie. Eine Achse mit Gate, die fail meldet, erzwingt Block. Eine, die partial oder unavailable ist, erzwingt mindestens Hold. Eine blockierende Achse, die nicht laufen konnte, hält das Verdikt: Fehlende Evidenz macht ein Gate nie grün.

Das Verdikt auf dem Tab Review ist das, das finalize_review geschrieben hat.