Bruk AI-drevet gjennomgang

Denne guiden viser deg hvordan du lar reviewer-agenter gjennomgå en pull request, og hvordan du publiserer resultatet til GitHub.

Start en AI-gjennomgang

Åpne PR-en og gå til Oversikt-fanen
Åpne overflytsmenyen ⋯ i handlingsraden og velg Spør AI

Elementet vises bare mens PR-en er åpen — det er en handling før sammenslåing. Den samme knappen tilbys som Spør AI i tomtilstanden til Gjennomgang-fanen, før noen gjennomgang finnes.

Control Center starter den forhåndsdefinerte pr_review-pipelinen og åpner Gjennomgang-fanen til PR-en så du kan følge med. Pipelinen:

Åpner PR-ens eget gjennomgangsområde, der det isolerte worktreet har PR-en sjekket ut på head
Sprer ut reviewerne for arbeidsområdets gjennomgangsnivå — tre som standard (de forhåndsdefinerte agentene qa, architect og engineer, parallelt). Det gjøres ingen språk- eller domenegjenkjenning
Lar lederagenten (CEO) samle funnene deres i en guidet gjennomgang
Fullfører: sorterer funnene i konsensusgrupper og beregner vedtaket. Når koblingen når awaiting approval, vises Publiser til GitHub i Gjennomgang-fanen

Hvor dypt gjennomgangen går, styres av arbeidsområdets gjennomgangsnivå — light (én reviewer), balanced (tre, standard) eller thorough (alle fem, med sikkerhets- og ytelsesspesialistene i tillegg) — angitt under Innstillinger → Arbeidsområde → Generelt, på Arbeidsområdepolicy-kortet. Et lettere nivå registrerer like mange funn; det løfter bare færre av dem fram i forgrunnen.

Alle reviewerne legger inn i PR-ens ene gjennomgangsområde, og det er nettopp det som gjør funnene deres sammenlignbare. Se AI-gjennomgang for hvordan bitene henger sammen.

pr_review leveres bare med en manuell utløser. For å få den til å kjøre på hver publiserte PR, legg til en utløser selv — se Send ut reviewer-agenter. Du kan også starte en fra GitHub selv, uten pipeline-utløser: nevn serverens bot i PR-en eller legg til etiketten ai-review — se Snakk med Control Center fra en GitHub-PR.

Hvis et varsel sier at en gjennomgang allerede kjører for denne pull requesten, er en allerede i gang; bli på Gjennomgang-fanen eller åpne Pipelines for å finne den.

Les funnene

Reviewere registrerer funn som gjennomgangsnoder i gjennomgangsområdet. Hver node har:

Felt	Beskrivelse
Type	`bug`, `suggestion`, `recommendation`, `question` eller `ticket`
Prioritet	P0 (kritisk) → P3 (pirk)
Kategori	`security`, `stability`, `data_integrity`, `correctness`, `performance` eller `maintainability`
Fil og linje	Hvor funnet er forankret
Opprinnelig kode	Koden funnet gjelder
Foreslått kode	Den foreslåtte rettelsen
Konfidens	Hvor sikker revieweren er
Status	`open` → `consensus-ready` → `resolved` eller `dismissed`

Et funn når bare consensus-ready når en annen reviewer bekrefter det. En agent kan ikke bekrefte sitt eget funn, så én enkelt reviewers mening går aldri videre på egen hånd.

Gjennomgang-fanen viser funnlisten, filtrerbar på type og status, med en veksleknapp for avviste funn, ved siden av artefakten den samlende agenten publiserte. Den deterministiske visningen — kohorter, dashbordet med flere akser, kontrakt- og visuelle differ — beregnes på serversiden, men finnes ikke som egen visning i appen; se Gjennomgangsberegning for hva kjøringen produserer.

Sjekk uenighetspanelet

Når to reviewere forankrer funn til samme fil og linje, men vurderer dem svært ulikt — prioriteringer to eller flere nivåer fra hverandre, eller én kaller det en bug mens den andre kaller det en suggestion — vises et uenighetspanel over funnlisten. Les dem først: det er der reviewernes meninger spriker, og der din vurdering er verdt mest.

Les vedtaket

Når lederagenten fullfører, beregner den et vedtak:

Vedtak	Betydning
Ship	Ingenting blokkerende funnet
Hold	Problemer som bør håndteres før sammenslåing
Block	Kritiske problemer som må rettes

Vedtaket har en samlet konfidensskår og antall funn per prioritet.

Gjennomgangsaksene veves deretter inn i det, og de kan bare gjøre det mer alvorlig. En sperret akse som feiler, tvinger fram Block; en sperret akse som ikke kunne fullføres (partial) eller ikke kunne kjøre i det hele tatt (unavailable), tvinger fram minst Hold. Fravær av bevis opphever aldri en sperre.

Publiser gjennomgangen til GitHub

Publisering er et eget steg som bevisst krever at brukeren godkjenner det. pr_review-pipelinen beholder gjennomgangen i Control Center; den legger den ikke ut på GitHub.

På Gjennomgang-fanen venter du til Publiser til GitHub vises
Trykk Publiser til GitHub

Control Center sender én GitHub-gjennomgang. Funn som allerede er løst eller avvist, hoppes over. Knappen tar med hvert gjenstående åpne funn og sender APPROVE ved Ship. (MCP-verktøyet publish_review_to_github bruker fortsatt bare funn bekreftet av andre reviewere som standard, og godkjenner ikke med mindre du oppgir approve_on_ship.) De som har et fil- og linjefeste, blir innebygde kommentarer; alt annet legges inn i sammendragsteksten, hver med en «— Control Center AI review»-footer, slik at kilden er entydig. Et Block-vedtak sendes som REQUEST_CHANGES; Hold som COMMENT; Ship som APPROVE fra denne knappen. Et varsel viser deretter Publisert. Gjennomgangen legges ut under serverens appidentitet.

Hvis GitHub avviser et innebygd feste fordi linjen ikke er en del av diffen, sendes hele gjennomgangen på nytt med hvert funn lagt inn i teksten, slik at ingenting forsvinner i stillhet.

Andre innebygde pipelines legger faktisk ut på GitHub direkte: cross_review, pr_triage, ticket_to_pr og pre_merge_gate avsluttes alle med et kommentarsteg. Bare pr_review holder tilbake resultatet til deg.

Send ut reviewere selv

For å styre hvilke roller som gjennomgår PR-en, og hvilke filer hver av dem ser på, bruker du MCP-verktøyet dispatch_reviewers inne i et eksisterende gjennomgangsområde, eller legger til reviewer-noder i en pipeline. Begge veiene, med verktøyets nøyaktige signatur, står i Send ut reviewer-agenter.