Gjennomgangsberegning (kohorter, akser og deterministiske differ)

Gjennomgang-fanen på en PR er den levende fremdriften til gjennomgangspipelinen mens den arbeider, og deretter artefakten den publiserte, med handlingene som hører til den. Én fane med to tilstander, fordi det er samme sak på to tidspunkter. Den er ikke en standardfane: en PR har ingen gjennomgang før noen ber om en, så det er Spør AI som åpner den.

Bak den fanen bygger cc_server filkohorter, kjører de deterministiske aksene og eksponerer dem gjennom RPC-operasjonene review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute og deres watch*-tvillinger). En lagret layout som fortsatt nevner pr.reviewStudio, åpner denne samme Gjennomgang-fanen.

I Gjennomgang-fanen:

Den samlende agenten publiserer en vanlig samtaleartefakt med publish_artifact, slik at fanen viser den gjennom den samme artefaktviseren som en chatboble åpner — det finnes ingen gjennomgangsformet kopi av artefaktsystemet.
Funnene ligger i et sidefelt ved siden av, og vedtaket vises i en slank linje over artefakten i stedet for i en dashbordoverskrift.
Det vises et banner om utdatert gjennomgang når PR-ens head har flyttet seg forbi gjennomgangen.

Se Bruk AI-drevet gjennomgang for flyten og Gjennomgå og slå sammen en PR for hvordan du handler på den.

Kohorter

Kohorter grupperer de endrede filene i PR-en i innholdsutledede bøtter av filer som hører sammen etter betydning, rangert etter nedslagsfelt slik at den mest risikable gruppen leses først. De beregnes på nytt ved hver endring i head-SHA og erstattes i sin helhet; hver kohort har en nøkkel som er stabil på tvers av pushes, slik at et sammendrag og fremdriften i en gjennomgang overlever en rebase.

Hvis repoet ikke har noen kodeindeks, faller kohortene tilbake til gruppering etter sti. For å indeksere et repo bruker du Innstillinger → Arbeidsområde → Arkiv — hver arkivrad har en Indekser kode-handling som kjører index_code-pipelinen og rapporterer fremdriften på stedet.

Kodegrafen parser bare språk med en medfølgende grammatikk (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Et repo på et hvilket som helst annet språk kan aldri produsere semantiske kohorter, uansett hvor ofte du indekserer det.

En agent kan registrere et markdown-sammendrag for en kohort med set_cohort_summary og legge ved et strukturert gjennomgangsdiagram med add_review_diagram — et typet objekt for sekvens, entitetsrelasjon eller tilstandsmaskin, aldri mermaid-tekst. Hver kant kryssjekkes mot den virkelige kodegrafen, og en kant grafen ikke kan bekrefte, merkes som uverifisert i stedet for å tegnes som et faktum.

Aksen for API-kontrakten

Kontraktaksen differ bare eksplisitte spesifikasjonsfiler. Den gjenkjenner de seks standardnavnene — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — pluss enhver endret fil hvis navn inneholder openapi eller swagger og slutter på .yaml, .yml eller .json. En kontrakt utledet fra handlerkode er utenfor omfanget, og GraphQL-skjemaer blir ikke diffet.

Hver endring klassifiseres — tillegg, fjerninger og endringer av endepunkter, parametere, skjemaer og responser — og har en alvorlighetsgrad: breaking (fjernet endepunkt eller parameter, strammet inn type, ny påkrevd parameter), non-breaking (additiv) eller informativ. En avvist endring får kontraktporten til å feile, og det samme gjør en breaking-endring som er latt uavgjort; breaking, men godkjent, varsler; ingen breaking-endringer passerer. En diff merket avledet (veiledende) setter aldri port.

Å godkjenne eller avvise en endring gjøres med review_studio.setContractDecision.

Den visuelle aksen

Hvis PR-en endrer UI-komponenter i et Flutter-repo med en Widgetbook-app, rendrer beregningskjøringen de endrede komponentene før og etter gjennom en headless golden-kjøring med flutter test i PR-ens base- og head-worktrees, og differ deretter pikslene.

Øyeblikksbilder merket changed eller removed holder den visuelle porten til de er godkjent; øyeblikksbilder merket unchanged, added og approved åpner den. Utilgjengelighet har én av fire årsaker: ingen Flutter SDK på verten, ingen Widgetbook-app i repoet, ingen golden-testbare brukstilfeller eller en feil i golden-harnesset.

Å godkjenne en tilsiktet endring gjøres med review_studio.approveVisual.

Aksene og vedtaket

Akse	Drevet av
Korrekthet	Reviewer-agenter (tokens)
Sikkerhet	Reviewer-agenter (tokens)
Testgap	Reviewer-agenter (tokens)
Visuell	Deterministisk (golden-harness)
API-kontrakt	Deterministisk (spesifikasjonsdiff)

De tre tokenaksene registreres når en lederagent kaller finalize_review; de to deterministiske aksene registreres av beregningskjøringen.

Hver akse rapporterer ett av:

Tilstand	Betydning
Pass	Kjørte, fant ingenting blokkerende
Warn	Kjørte, ikke-blokkerende bekymringer
Fail	Kjørte, fant et blokkerende problem
Partial	Kjørte, men kunne ikke fullføres; resultatene er ufullstendige
Unavailable	Kunne ikke kjøre i det hele tatt

Bare pass og warn åpner en akse med port. Partial og unavailable er bevisst atskilt fra fail, og ingen av dem åpner en port.

Aksene samles til Ship, Hold eller Block, og de kan bare gjøre vedtaket strengere — det nedgraderes aldri. En akse med port som feiler, tvinger fram Block; en som er partial eller unavailable, tvinger fram minst Hold. En blokkerende akse som ikke kunne kjøre, holder altså vedtaket tilbake: fravær av bevis gjør aldri en port grønn.

Vedtaket i Gjennomgang-fanen er det finalize_review la inn.