Review-compute (cohorten, assen en deterministische diffs)

Het tabblad Review van de PR is de live voortgang van de reviewpipeline terwijl die werkt, en daarna het artefact dat hij heeft gepubliceerd, met de acties erop. Eén tabblad met twee toestanden, want het is hetzelfde ding op twee momenten. Het is geen standaardtabblad: een PR heeft pas een review als iemand erom vraagt, dus Ask AI is wat het opent.

Achter dat tabblad bouwt cc_server bestandscohorten, draait het de deterministische assen en serveert het die via de RPC-operaties review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute en hun watch*-tweeling). Een opgeslagen layout die nog pr.reviewStudio heet, opent ditzelfde tabblad Review.

Op het tabblad Review:

De bundelende agent publiceert een gewoon gespreksartefact met publish_artifact, zodat het tabblad het weergeeft via dezelfde artefactviewer die een chatbubbel opent — er is geen reviewvormige kopie van het artefartsysteem.
Bevindingen staan in een zijbalk ernaast, en het oordeel rijdt mee op een slanke balk boven het artefact in plaats van een dashboardkop.
Er verschijnt een verouderingsbanner wanneer de head van de PR voorbij de review is geschoven.

Zie AI-gestuurde review gebruiken voor de flow en Een PR reviewen en mergen om er iets mee te doen.

Cohorten

Cohorten groeperen de gewijzigde bestanden van de PR in op inhoud afgeleide buckets met bestanden die qua betekenis bij elkaar horen, gerangschikt op impact zodat de riskantste groep als eerste wordt gelezen. Ze worden bij elke wijziging van de head-SHA opnieuw berekend en in hun geheel vervangen; elk cohort heeft een pushstabiele sleutel, zodat een samenvatting en de reviewvoortgang een rebase overleven.

Als de repo geen code-index heeft, vallen cohorten terug op groepering op pad. Om een repo te indexeren gebruik je Instellingen → Werkruimte → Repository’s — elke rij van een repo heeft een actie Code indexeren die de pipeline index_code draait en de voortgang ter plaatse meldt.

De codegraph parseert alleen talen met een meegeleverde grammatica (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Een repo in een andere taal kan nooit semantische cohorten opleveren, hoe vaak je hem ook indexeert.

Een agent kan een markdown-samenvatting voor een cohort vastleggen met set_cohort_summary en een gestructureerd rondleidingsdiagram toevoegen met add_review_diagram — een getypeerd sequence-, entiteit-relatie- of toestandsmachineobject, nooit mermaid-tekst. Elke rand wordt gecontroleerd tegen de echte codegraph, en een rand die de graaf niet kan bevestigen, wordt als onbevestigd gemarkeerd in plaats van als feit getekend.

De API-contractas

De contractas vergelijkt alleen expliciete specbestanden. Hij matcht de zes standaardnamen — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — plus elk gewijzigd bestand waarvan de naam openapi of swagger bevat en eindigt op .yaml, .yml of .json. Een contract dat uit handlercode is afgeleid, valt buiten scope en GraphQL-schema’s worden niet vergeleken.

Elke wijziging wordt geclassificeerd — toevoegingen, verwijderingen en wijzigingen van endpoints, parameters, schema’s en responses — en draagt een ernst: breaking (verwijderd endpoint of verwijderde parameter, verscherpt type, nieuwe verplichte parameter), non-breaking (additief) of informatief. Een afgewezen wijziging laat de contractpoort falen, net als een breaking wijziging die onbeslist blijft; breaking-maar-goedgekeurd geeft een waarschuwing; geen breaking wijzigingen slaagt. Een diff die als derived (advisory) is gemarkeerd, vormt nooit een poort.

Een wijziging goedkeuren of afwijzen doe je met review_studio.setContractDecision.

De visuele as

Als de PR UI-componenten wijzigt in een Flutter-repo met een Widgetbook-app, rendert de compute-ronde de gewijzigde componenten voor en na via een headless flutter test-goldenpass in de base- en head-worktrees van de PR, en vergelijkt daarna de pixels.

Snapshots die als changed of removed zijn gemarkeerd, houden de visuele poort tegen tot ze zijn goedgekeurd; unchanged, added en approved snapshots openen hem. Niet-beschikbaarheid heeft een van vier redenen: geen Flutter-SDK op de host, geen Widgetbook-app in de repo, geen golden-testbare use-cases, of een fout in de golden harness.

Een bedoelde wijziging goedkeuren doe je met review_studio.approveVisual.

De assen en het oordeel

As	Aangedreven door
Correctness	Reviewer-agenten (tokens)
Security	Reviewer-agenten (tokens)
Test gap	Reviewer-agenten (tokens)
Visual	Deterministisch (golden harness)
API contract	Deterministisch (spec diff)

De drie token-assen worden vastgelegd wanneer een lead-agent finalize_review aanroept; de twee deterministische assen worden vastgelegd door de compute-ronde.

Elke as meldt een van de volgende:

Toestand	Betekenis
Pass	Gedraaid, niets blokkerends gevonden
Warn	Gedraaid, niet-blokkerende aandachtspunten
Fail	Gedraaid, een blokkerend probleem gevonden
Partial	Gedraaid maar niet kunnen afronden; de resultaten zijn onvolledig
Unavailable	Kon helemaal niet draaien

Alleen pass en warn openen een as met een poort. Partial en unavailable zijn bewust onderscheiden van fail en geen van beide opent een poort.

De assen komen samen in Ship, Hold of Block, en ze kunnen het oordeel alleen strenger maken — het wordt nooit afgezwakt. Een as met een poort die fails, dwingt Block af; een die partial of unavailable is, dwingt minstens Hold af. Een blokkerende as die niet kon draaien, houdt het oordeel dus tegen: afwezigheid van bewijs maakt een poort nooit groen.

Het oordeel op het tabblad Review is het oordeel dat finalize_review heeft geplaatst.