Obliczenia recenzji (kohorty, osie i deterministyczne różnice)

Karta Recenzja PR-a to najpierw bieżący postęp potoku recenzji, gdy ten pracuje, a potem opublikowany przez niego artefakt wraz z akcjami na nim. Jedna karta o dwóch stanach, bo to to samo w dwóch momentach. Nie jest to domyślna karta: PR nie ma recenzji, dopóki ktoś o nią nie poprosi, więc otwiera ją Zapytaj AI.

Za tą kartą cc_server buduje kohorty plików, uruchamia deterministyczne osie i udostępnia je przez operacje RPC review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute oraz ich bliźniaki watch*). Zapisany układ, który nadal wskazuje pr.reviewStudio, otwiera tę samą kartę Recenzja.

Na karcie Recenzja:

Agent konsolidujący publikuje zwykły artefakt rozmowy za pomocą publish_artifact, więc karta wyświetla go przez tę samą przeglądarkę artefaktów, którą otwiera dymek czatu — nie istnieje żadna kopia systemu artefaktów stworzona specjalnie dla recenzji.
Ustalenia mieszczą się w wąskim pasku z boku, a werdykt wiezie się na cienkim pasku nad artefaktem, a nie w nagłówku pulpitu.
Gdy head PR-a przesunął się poza recenzję, pojawia się baner o nieaktualności.

Przebieg opisano w Używaj recenzji opartej na AI, a działanie na jego wyniku w Zrecenzuj i scal PR.

Kohorty

Kohorty grupują zmienione pliki PR-a w wywodzone z treści koszyki plików, które pasują do siebie znaczeniowo, uszeregowane według wpływu, tak aby najbardziej ryzykowną grupę czytać jako pierwszą. Są przeliczane przy każdej zmianie head-SHA i wymieniane w całości; każda kohorta ma klucz stabilny między wypchnięciami, więc podsumowanie i postęp recenzji przetrwają rebase.

Jeśli repozytorium nie jest zindeksowane, kohorty cofają się do grupowania po ścieżkach. Aby zindeksować repozytorium, użyj Ustawienia → Obszar roboczy → Repozytoria — każdy wiersz repozytorium ma akcję Indeksuj kod, która uruchamia potok index_code i raportuje postęp na miejscu.

Graf kodu analizuje tylko języki z dostarczoną gramatyką (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Repozytorium w każdym innym języku nigdy nie wytworzy semantycznych kohort, niezależnie od tego, jak często je zindeksujesz.

Agent może zapisać podsumowanie w formacie markdown dla kohorty za pomocą set_cohort_summary i dołączyć ustrukturyzowany diagram omówienia za pomocą add_review_diagram — typizowany obiekt sekwencji, relacji encji lub maszyny stanów, nigdy tekst mermaid. Każda krawędź jest weryfikowana krzyżowo z rzeczywistym grafem kodu, a krawędź, której graf nie może potwierdzić, jest oznaczana jako niezweryfikowana, a nie rysowana jako fakt.

Oś kontraktu API

Oś kontraktu porównuje tylko jawne pliki specyfikacji. Dopasowuje sześć domyślnych nazw — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — oraz każdy zmieniony plik, którego nazwa zawiera openapi lub swagger i kończy się na .yaml, .yml lub .json. Kontrakt wywnioskowany z kodu handlera jest poza zakresem, a schematy GraphQL nie są porównywane.

Każda zmiana jest klasyfikowana — dodania, usunięcia i modyfikacje endpointów, parametrów, schematów i odpowiedzi — i ma przypisaną wagę: breaking (usunięty endpoint lub parametr, zaostrzony typ, nowy wymagany parametr), non-breaking (addytywna) lub informacyjna. Odrzucona zmiana nie przechodzi bramki kontraktu, podobnie jak zmiana breaking pozostawiona bez decyzji; zmiana breaking, ale zatwierdzona, ostrzega; brak zmian breaking przechodzi. Diff oznaczony jako pochodny (doradczy) nigdy nie podlega bramce.

Zatwierdzanie lub odrzucanie zmiany to review_studio.setContractDecision.

Oś wizualna

Jeśli PR zmienia komponenty interfejsu w repozytorium Flutter z aplikacją Widgetbook, przebieg obliczeń renderuje zmienione komponenty przed i po przez uruchamiany bez interfejsu przebieg golden flutter test w worktree PR-a dla base i head, a następnie porównuje piksele.

Migawki oznaczone jako changed lub removed wstrzymują bramkę wizualną do czasu zatwierdzenia; migawki unchanged, added i approved ją zdejmują. Niedostępność ma jeden z czterech powodów: brak Flutter SDK na hoście, brak aplikacji Widgetbook w repozytorium, brak przypadków użycia nadających się do testów golden lub błąd harnessu golden.

Zatwierdzanie zamierzonej zmiany to review_studio.approveVisual.

Osie i werdykt

Oś	Sterowana przez
Poprawność	Agenci-recenzenci (tokeny)
Bezpieczeństwo	Agenci-recenzenci (tokeny)
Luka w testach	Agenci-recenzenci (tokeny)
Wizualna	Deterministyczna (harness golden)
Kontrakt API	Deterministyczna (diff specyfikacji)

Trzy osie tokenowe są zapisywane, gdy agent prowadzący wywoła finalize_review; dwie osie deterministyczne zapisuje przebieg obliczeń.

Każda oś zgłasza jeden z następujących stanów:

Stan	Znaczenie
Pass	Uruchomiona, nic blokującego nie znaleziono
Warn	Uruchomiona, zastrzeżenia nieblokujące
Fail	Uruchomiona, znaleziono problem blokujący
Partial	Uruchomiona, ale nie udało się jej ukończyć; wyniki są niepełne
Unavailable	Nie udało się jej w ogóle uruchomić

Tylko pass i warn zdejmują bramkę z osi objętej bramką. Partial i unavailable celowo różnią się od fail i żadne z nich nie zdejmuje bramki.

Osie agregują się w Ship, Hold lub Block i mogą tylko uczynić werdykt bardziej surowym — nigdy nie jest on łagodzony. Oś objęta bramką, która zgłasza fail, wymusza Block; oś, która zgłasza partial lub unavailable, wymusza co najmniej Hold. Zatem oś blokująca, której nie udało się uruchomić, wstrzymuje werdykt: brak dowodów nigdy nie zalicza bramki.

Werdykt na karcie Recenzja to ten zapisany przez finalize_review.