AI-gjennomgang

Strukturen i en gjennomgang

En AI-gjennomgang er én kjøring av den innebygde pr_review-pipelinen mot én åpen pull request. Pipelinen åpner gjennomgangsområdet til PR-en, sender ut reviewer-agenter for å lese diffen i områdets isolerte checkout, hver av dem registrerer funnene sine som strukturerte gjennomgangsknoder, en lederagent konsoliderer dem til en samlet fremstilling, og en avslutningsagent beregner én dom: Ship, Hold eller Block. Det pipelinen aldri gjør, er å publisere – å legge ut til GitHub er et eget, bevisst steg som et menneske tar.

Resten av denne siden forklarer delene og hvorfor de er formet slik.

Ett gjennomgangsområde per PR

Gjennomgangskonteksten til en PR er et meldingsområde – modus review, type pr – koblet til pull requesten med en tilknytning til gjennomgangsområdet. Den opprettes idempotent: PR-siden, gjennomgangspipelinen og chatflatene finner alle det ene området som ligger bak PR-en, gjennom samme kodesti, slik at en mal som gjennomgår en PR og et menneske som åpner den, aldri kan ende opp i to forskjellige rom med to forskjellige checkouts.

Det isolerte worktreet til området har PR-en sjekket ut på head-refen sin. Ett rom betyr også én checkout: alle reviewere jobber i samme område i stedet for at hver av dem får sin egen klon av arbeidsområdet.

Hver reviewer skriver inn i sin egen navngitte strøm inne i dette ene området, og funn er review_node-meldinger i stedet for ren prosa. Innsamlingen på tvers av hele området til slutt er bevisst – en dom beregnet ut fra funnene i én tråd ville stille og rolig være en dom over én enkelt reviewer.

Tilknytningen har en statusstige – requested → in progress → awaiting approval → completed – og det er denne som styrer om Publiser til GitHub er tilgjengelig i fanen Gjennomgang på PR-en.

Nivåer for gjennomgang

Hvor dypt en gjennomgang går, er en policy for arbeidsområdet med tre nivåer, som angis under Innstillinger → Arbeidsområde → Generelt, på kortet Arbeidsområdepolicy:

Nivå	Reviewere som sendes ut	Rapportering
light	Bare engineer	Bare det som materielt teller
balanced	Engineer, QA, architect (standard)	Den faste gjennomgangen
thorough	Alle fem, inkludert sikkerhet og ytelse	Ingenting nedgraderes

Nivået dreier to skruer samtidig: hvilke reviewere som sendes ut – håndhevet av tilstandsportene runWhen i pipeline-malen og ikke av ordlyden i prompten, for ordlyd i en prompt kan ignoreres, mens en port ikke kan – og hvor funn under terskelen vises. Ingen av skruene sletter noen gang et funn: et nivå som rapporterer mindre, registrerer like mye og grupperer resten.

Passene for sikkerhet og ytelse gjenbruker de innebygde agentene architect og engineer i stedet for å innføre nye. Spesialiseringen er oppdraget revieweren sendes ut med, ikke en egen agent per akse – en agent per akse ville være fem rader mer i hvert arbeidsområde uten noen ekstra evne. Utvelgelsen av reviewere ser aldri på diffen etter språk eller domene.

Gjennomgangsknoder: funn som data, ikke prosa

Et funn som registreres med add_review_node, blir en gjennomgangsknode på PR-en – det er den fanen Gjennomgang viser, det er den dommen beregnes ut fra, og det er den «Publiser til GitHub» gjør om til en innebygd kommentar. En reviewer som bare returnerer prosa, gir en pipeline-kjøring som ser vellykket ut og en gjennomgangsflate som er tom; det er registreringen som bærer.

Hver node har:

Felt	Verdier
Type	bug, suggestion, recommendation, question, ticket
Prioritet	P0 (kritisk) → P3 (bagatell)
Triage-trippel	kategori (security, stability, …), alvorlighetsgrad, innsats
Anker	Filsti, linjestart og linjeslutt
Medfølgende retting	Foreslåtte erstatningslinjer, en valgfri diff, en valgfri rettingsprompt
Konfidens	En verdi i [0, 1]
Begrunnelse	Analysen, skrevet før funnet

To detaljer er bevisste. Et GitHub-forslag med ett klikk tilbys bare når revieweren har oppgitt eksakte erstatningslinjer – å utlede dem fra en unified diff går stille galt, og å committe en feil utledning med ett klikk er verre enn ingen knapp i det hele tatt. Og skjemaet for add_review_node presenterer reasoning før funnet, slik at en modell som fyller ut objektet i skjemaets rekkefølge, skriver analysen først. Feltet er valgfritt: å utelate det avviser ikke noden. En node med ugyldig nyttelast forsvinner i stedet for å forurense gjennomgangen.

Peer-konsensus

En node går gjennom open → consensus-ready → resolved eller dismissed. Det midterste steget er kjernen i modellen: et funn rykker bare opp når en peer-reviewer bekrefter det, og en agent kan aldri bekrefte sitt eget funn. MCP-verktøyet publish_review_to_github og RPC-standardverdien publiserer fortsatt bare peer-bekreftede funn. Knappen Publiser til GitHub i fanen Gjennomgang sender i stedet hvert gjenstående åpne funn.

Regelen håndheves tre uavhengige steder – bekreftelsesverktøyet, avslutningsagenten og publisereren – slik at den står imot en feilende kaller i hvilken som helst av dem. Alle statusendringer går gjennom én tjeneste, og det er nettopp det som gir en status mening: før dette kunne to halvferdige stier være uenige om det samme funnet var løst.

Når reviewere er uenige – samme fil og linje, prioriteter to eller flere nivåer fra hverandre, eller én kaller det en bug mens den andre kaller det en suggestion – vises uenigheten over funnlisten. Det er der reviewernes oppfatninger spriker, og der et menneskes vurdering er mest verdt.

Å avvise et funn skriver også et mykt undertrykkingsfaktum inn i minnedomenet, med lav konfidens – én avvisning er en preferanse, ikke en regel.

Kohorter: det gjennomgangen grupperes rundt

Gjennomgangsberegningen grupperer de endrede filene i en PR i kohorter utledet fra kodegrafen: endrede filer kobles til symbolene de berører, symboler til sammenhengskomponenter, og kohortene rangeres etter nedslagsfelt. En kohort har en veiledet leserekkefølge, diagrammer og innsikter i stedet for å være en flat filliste.

To ærlighetsregler former dette. Kohortnøkler er utledet fra innholdet og stabile på tvers av pushes, slik at funn og fremdrift i gjennomgangen overlever en rebase eller force-push i stedet for å bli foreldreløse. Og når repoet ikke har noen kodeindeks, faller grupperingen tilbake til rene stier og sier ifra om det – reserveveien later aldri som om den har semantisk konfidens.

Gjennomgangsakser og porter

Ved siden av reviewernes funn samler en gjennomgang akseresultater: seks akser, av to slag.

Akse	Slag	Hentet fra
correctness, security	Tokendrevet	Reviewernes egne funn
testGap	Tokendrevet	Reviewernes funn
visual, apiContract	Deterministisk	Beregnet uten å bruke tokens
performance	Deterministisk	Bare enum – ingenting i produktet beregner et resultat

En dom for en akse er pass, warn, fail, partial eller unavailable – og bare pass eller warn passerer en port. Forskjellen mellom fail, partial og unavailable er bærende: en akse med port som ikke kunne fullføres eller ikke kunne kjøre i det hele tatt, holder den samlede dommen tilbake i stedet for å slippe den gjennom. Fravær av bevis blir aldri til en grønn port.

Noen akser er rådgivende med vilje. Testgap-aksen utledet fra kohorter kan ikke se dekning av avhengighetsinjeksjon eller fabrikker – et ikke-indeksert repo med en grundig testsuite og et helt uten tester ser identiske ut derfra, så å påstå noe av det ville være en løgn; den vises i dashbordet uten å sette port. Tokenaksene er rådgivende fordi prioritetene på funnene allerede driver dommen, og å sette port på dem igjen ville dobbelttelle.

Dommen

Avslutningsagenten beregner dommen over funnene med status open eller consensus-ready:

• ethvert P0-funn med konfidens ≥ 0,7 → Block
• ellers ethvert P0 (lav konfidens) eller ethvert P1 → Hold
• ellers → Ship

Dommen har en samlet konfidens utledet fra spredningen mellom konfidensene som bidrar – enighet hever den, sprik senker den.

Konsolideringen til lederagenten (CEO) er en redaksjonell bearbeiding, ikke en ny opplisting: en håndskrevet andreutgave av funnene er nettopp det som driver bort fra den ekte. Dupliserte funn nedgraderes i stedet for å gjentas – flere reviewere pekes mot én diff med bevisst overlappende mandater, så når den samme feilen når avslutningsagenten tre ganger, er det systemet som virker; å publisere den tre ganger er systemet som lekker sin egen arkitektur inn i leserens innboks. Ved en ny gjennomgang får funnene fingeravtrykk og diffes mot forrige runde, slik at det er deltaet som vises.

Til slutt kommer aksene inn, og de kan bare gjøre dommen strengere: en akse med port som feiler, tvinger Block – funn kan ikke overstemme den – og en akse med port som ikke kunne fullføres, tvinger minst Hold.

Publiseringen er opp til deg

Pipelinen legger bevisst ikke ut til GitHub; publiseringen er kontrollert av brukeren, slik at en gjennomgang aldri kan publiseres dobbelt. Når du trykker Publiser til GitHub:

• Én GitHub-gjennomgang sendes inn. Funn som allerede er løst eller avvist, hoppes over. Knappen publiserer hvert gjenstående åpent funn (selection: all_open). MCP-verktøyet publish_review_to_github har fortsatt bare peer-bekreftede funn som standard (consensus).
• Funn forankret til en fil og linje blir innebygde kommentarer; alt annet legges inn i sammendraget, hvert med en “— Control Center AI review”-fotnote, slik at kilden er entydig.
• Ankere verifiseres på nytt mot PR-ens nåværende diff på publiseringstidspunktet. En kommentar på kode som allerede er skrevet om, er det mest tillitsødeleggende en reviewer kan legge igjen; hvis GitHub likevel avviser et innebygd anker, sendes hele gjennomgangen på nytt med hvert funn lagt inn i teksten, slik at ingenting forsvinner i stillhet.
• En Block-dom sendes inn som REQUEST_CHANGES; Hold som COMMENT; Ship som APPROVE fra knappen (approve_on_ship: true). MCP-verktøyet lar Ship stå som COMMENT med mindre du oppgir approve_on_ship.
• Gjennomgangen legges ut under serverens appidentitet. Hvem som trykket på Publiser, registreres for rolleporten og revisjonsloggen; det er ikke GitHub-forfatteren.

Publiseringen deklarerer handlingsklassen prPublish, så kontrollpunktet i tillatelsesreglene behandler den som enhver muterende handling – den ber om bekreftelse som standard og feiler lukket når ingen godkjenner er koblet til. Se Tillatelsesregler.

Hva en reviewer kan gjøre

Reviewer-agenter kjører i modusen review: en skrivebeskyttet sandkasse og en kuratert tillatelsesliste over verktøy som dekker funn, kommentarer, saker og peer-gjennomgang – men ingen mutasjoner. En reviewer kan ikke rette koden den kritiserer; den kan legge ved et forslag til retting som et menneske bruker. Avvisningsmeldingen i modusen sier til en agent som likevel prøver å handle, at den skal fullføre gjennomgangen og la brukeren handle på det publiserte sammendraget.

Relaterte konsepter

• Tillatelsesregler – policymotoren som styrer publiseringen
• Moduser – hva modusen review endrer for en agent
• Pipelines og automatisering – motoren gjennomgangen kjører på
• Livssyklus for agentutsending – hvor det isolerte worktreet kommer fra

Relaterte veiledninger

• Bruk AI-drevet gjennomgang – kjør en gjennomgang og publiser den
• Send ut reviewer-agenter – velg reviewerene selv
• Gjennomgangsberegning – kohorter, akser og differ