Átnézési számítás (kohorszok, tengelyek és determinisztikus diffek)

A PR Átnézés füle az átnézési pipeline élő előrehaladása, amíg az dolgozik, majd az általa közzétett artefaktum, a rajta elvégezhető műveletekkel. Egy fül, két állapottal, mert ugyanaz a dolog két időpontban. Ez nem alapértelmezett fül: egy PR-nek addig nincs átnézése, amíg valaki nem kér egyet, ezért a Kérdezze az AI-t az, ami megnyitja.

A fül mögött a cc_server fájlkohorszokat épít, lefuttatja a determinisztikus tengelyeket, és kiszolgálja őket a review_studio.* RPC-műveleteken keresztül (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute és a watch* ikertestvéreik). Egy perzisztált elrendezés, amely még mindig a pr.reviewStudio nevet viseli, ugyanezt az Átnézés fület nyitja meg.

Az Átnézés fülön:

A konszolidáló ügynök egy közönséges beszélgetési artefaktumot tesz közzé a publish_artifact funkcióval, így a fül ugyanazon az artefaktumnézetőn keresztül jeleníti meg, amelyet egy csevegőbuborék is megnyit – nincs az artefaktumrendszernek átnézésre szabott másolata.
A megállapítások egy mellette lévő oldalsávban helyezkednek el, az ítélet pedig egy vékony sávon utazik az artefaktum fölött, nem egy irányítópult-fejlécen.
Elavulást jelző szalaghirdetés jelenik meg, amikor a PR headje túlhaladt az átnézésen.

A folyamatról lásd: MI-alapú átnézés használata, a vele való tevékenységről pedig: PR átnézése és összefésülése.

Kohorszok

A kohorszok a PR megváltozott fájljait tartalom alapján származtatott vödrökbe csoportosítják: olyan fájlokba, amelyek jelentésük szerint összetartoznak, hatás szerint rendezve, hogy a legkockázatosabb csoport olvasódjon először. Minden head-SHA-változásnál újraszámítódnak, és teljes egészükben kicserélődnek; minden kohorsznak van egy push-stabil kulcsa, így az összefoglaló és az átnézés előrehaladása túléli a rebase-t.

Ha a repó nincs kódindexelve, a kohorszok az útvonal szerinti csoportosításra esnek vissza. Egy repó indexeléséhez használja a Beállítások → Munkaterület → Tárolók elemet – minden repósor tartalmaz egy Kód indexelése műveletet, amely lefuttatja az index_code pipeline-t, és helyben jelenti az előrehaladást.

A kódgráf csak azoknak a nyelveknek a feldolgozására képes, amelyekhez szállított nyelvtannal rendelkezik (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Egy más nyelvű repó soha nem tud szemantikus kohorszokat előállítani, akárhányszor indexeli is.

Az ügynök markdown-összefoglalót rögzíthet egy kohorszhoz a set_cohort_summary funkcióval, és strukturált végigvezető diagramot csatolhat hozzá az add_review_diagram funkcióval – típusos szekvencia-, entitás-kapcsolat- vagy állapotgép-objektumot, soha nem mermaid szöveget. Minden élet egyeztetünk a valódi kódgráffal, és az olyan élt, amelyet a gráf nem tud megerősíteni, nem ellenőrzöttként jelöljük meg, nem pedig tényként rajzoljuk meg.

Az API-szerződés tengelye

A szerződéstengely csak az explicit specifikációs fájlokat diffeli. A hat alapértelmezett névhez illeszkedik – openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json –, valamint minden olyan megváltozott fájlhoz, amelynek neve tartalmazza az openapi vagy swagger szót, és .yaml, .yml vagy .json végződésű. A kezelőkódból kikövetkeztetett szerződés kívül esik a hatókörön, a GraphQL-sémákat pedig nem diffeljük.

Minden változás besorolást kap – végpont, paraméter, séma és válasz hozzáadása, eltávolítása és módosítása –, és súlyosságot hordoz: breaking (eltávolított végpont vagy paraméter, szigorított típus, új kötelező paraméter), nem breaking (hozzáadó jellegű) vagy tájékoztató jellegű. Egy elutasított változás megbuktatja a szerződéskaput, akárcsak egy döntés nélkül hagyott breaking változás; a breaking, de jóváhagyott változás figyelmeztet; breaking változások híján a kapu sikeres. Egy származtatott (tanácsadó jellegű) jelöléssel ellátott diff soha nem kapuz.

Egy változás jóváhagyása vagy elutasítása a review_studio.setContractDecision.

A vizuális tengely

Ha a PR felhasználóifelület-komponenseket módosít egy Widgetbook alkalmazással rendelkező Flutter-repóban, a számítási kör a PR base és head worktree-jében egy headless flutter test golden-futtatással rendereli a megváltozott komponenseket előtte és utána, majd diffeli a képpontokat.

A changed vagy removed jelöléssel ellátott pillanatképek jóváhagyásig visszatartják a vizuális kaput; az unchanged, added és approved pillanatképek kinyitják azt. Az elérhetetlenségnek négy oka lehet: nincs Flutter SDK a hoszton, nincs Widgetbook alkalmazás a repóban, nincsenek golden-tesztelhető használati esetek, vagy hiba történt a golden-harnessben.

Egy szándékolt változás jóváhagyása a review_studio.approveVisual.

A tengelyek és az ítélet

Tengely	Vezérli
Helyesség	Átnéző ügynökök (tokenek)
Biztonság	Átnéző ügynökök (tokenek)
Tesztlefedettség hiánya	Átnéző ügynökök (tokenek)
Vizuális	Determinisztikus (golden-harness)
API-szerződés	Determinisztikus (specifikációs diff)

A három tokenalapú tengely akkor rögzül, amikor a vezető ügynök meghívja a finalize_review funkciót; a két determinisztikus tengelyt a számítási kör rögzíti.

Minden tengely a következő állapotok egyikét jelenti:

Állapot	Jelentés
Pass	Lefutott, nem talált blokkoló tényezőt
Warn	Lefutott, nem blokkoló aggályok
Fail	Lefutott, blokkoló problémát talált
Partial	Lefutott, de nem tudott befejeződni; az eredmények hiányosak
Unavailable	Egyáltalán nem tudott lefutni

Csak a pass és a warn nyit ki egy kapuzott tengelyt. A Partial és az unavailable szándékosan különbözik a fail állapottól, és egyik sem nyit ki kaput.

A tengelyek Ship, Hold vagy Block ítéletté állnak össze, és csak súlyosabbá tehetik az ítéletet – soha nem enyhítik. Egy megbukó kapuzott tengely Blockot kényszerít; egy partial vagy unavailable tengely legalább Holdot kényszerít. Így egy blokkoló tengely, amely nem tudott lefutni, visszatartja az ítéletet: a bizonyíték hiánya soha nem nyit ki egy kaput.

Az Átnézés fülön látható ítélet az, amelyet a finalize_review közzétett.