Calculul revizuirii (cohorte, axe și diff-uri deterministe)

Tab-ul Revizuire al unui PR este progresul în direct al pipeline-ului de revizuire cât timp acesta lucrează, apoi artefactul pe care l-a publicat, cu acțiunile de pe el. Un singur tab cu două stări, pentru că sunt același lucru în două momente. Nu este un tab implicit: un PR nu are revizuire până când nu o cere cineva, așa că Întreabă AI este cel care îl deschide.

În spatele acelui tab, cc_server construiește cohorte de fișiere, rulează axele deterministe și le servește prin operațiunile RPC review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute și perechile lor watch*). Un layout persistat care încă numește pr.reviewStudio deschide același tab Revizuire.

În tab-ul Revizuire:

Agentul care consolidează publică un artefact obișnuit de conversație cu publish_artifact, așa că tab-ul îl redă prin același vizualizator de artefacte pe care îl deschide o bulă de chat — nu există o copie în formă de revizuire a sistemului de artefacte.
Constatările stau într-o bară laterală alături, iar verdictul stă pe o bară subțire deasupra artefactului, nu într-un antet de tablou de bord.
Apare un banner de învechire când vârful PR-ului a avansat dincolo de revizuire.

Vezi Folosește revizuirea bazată pe IA pentru flux și Revizuiește și îmbină un PR pentru cum să acționezi pe baza lui.

Cohorte

Cohortele grupează fișierele modificate ale PR-ului în grupe derivate din conținut, de fișiere care aparțin împreună prin semnificație, ordonate după impact, astfel încât grupul cel mai riscant se citește primul. Sunt recalculate la fiecare schimbare a SHA-ului de vârf și înlocuite în întregime; fiecare cohortă are o cheie stabilă la push, așa că un rezumat și progresul revizuirii supraviețuiesc unui rebase.

Dacă depozitul nu este indexat ca cod, cohortele se reduc la gruparea după cale. Ca să indexezi un depozit, folosește Setări → Spațiu de lucru → Depozite — fiecare rând de depozit are o acțiune Indexează codul care rulează pipeline-ul index_code și raportează progresul pe loc.

Graful de cod analizează doar limbajele pentru care există o gramatică livrată (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Un depozit într-un alt limbaj nu poate produce niciodată cohorte semantice, oricât de des l-ai indexa.

Un agent poate înregistra un rezumat markdown pentru o cohortă cu set_cohort_summary și poate atașa o diagramă structurată de parcurgere cu add_review_diagram — un obiect tipizat de secvență, entitate-relație sau mașină de stări, niciodată text mermaid. Fiecare muchie este verificată încrucișat cu graful de cod real, iar o muchie pe care graful nu o poate corobora este marcată ca neverificată, nu desenată ca fapt.

Axa contractului de API

Axa contractului face diff doar pe fișierele de specificație explicite. Potrivește cele șase nume implicite — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — plus orice fișier modificat al cărui nume conține openapi sau swagger și se termină în .yaml, .yml sau .json. Un contract dedus din codul de handler este în afara domeniului, iar pe schemele GraphQL nu se face diff.

Fiecare modificare este clasificată — adăugări, eliminări și modificări de endpoint, parametru, schemă și răspuns — și are o severitate: breaking (endpoint sau parametru eliminat, tip restrâns, parametru nou obligatoriu), non-breaking (aditivă) sau informativă. O modificare respinsă eșuează poarta contractului, la fel ca o modificare breaking lăsată nedecisă; breaking dar aprobată dă un avertisment; fără modificări breaking, poarta trece. Un diff marcat derived (advisory) nu impune niciodată o poartă.

Aprobarea sau respingerea unei modificări se face cu review_studio.setContractDecision.

Axa vizuală

Dacă PR-ul modifică componente de UI într-un depozit Flutter cu o aplicație Widgetbook, trecerea de calcul randează componentele modificate înainte și după printr-o trecere golden flutter test fără interfață, în worktree-urile de bază și de vârf ale PR-ului, apoi face diff pe pixeli.

Snapshot-urile marcate changed sau removed țin poarta vizuală până la aprobare; snapshot-urile unchanged, added și approved o eliberează. Indisponibilitatea are unul dintre cele patru motive: „no Flutter SDK on host”, „no Widgetbook app in repo”, „no golden-testable use-cases” sau „golden harness error”.

Aprobarea unei modificări intenționate se face cu review_studio.approveVisual.

Axele și verdictul

Axă	Determinată de
Corectitudine	Agenți recenzori (tokenuri)
Securitate	Agenți recenzori (tokenuri)
Lipsă de teste	Agenți recenzori (tokenuri)
Vizual	Deterministe (harnes golden)
Contract de API	Deterministe (diff de specificație)

Cele trei axe bazate pe tokenuri sunt înregistrate când un agent lider apelează finalize_review; cele două axe deterministe sunt înregistrate de trecerea de calcul.

Fiecare axă raportează una dintre stările:

Stare	Semnificație
Pass	A rulat, nu a găsit nimic blocant
Warn	A rulat, probleme neblocante
Fail	A rulat, a găsit o problemă blocantă
Partial	A rulat, dar nu a putut finaliza; rezultatele sunt incomplete
Unavailable	Nu a putut rula deloc

Doar pass și warn eliberează o axă cu poartă. Partial și unavailable sunt distincte în mod deliberat de fail și niciuna nu eliberează o poartă.

Axele se agregă în Ship, Hold sau Block și pot face verdictul doar mai sever — nu este niciodată retrogradat. O axă cu poartă care eșuează forțează Block; una care este partial sau unavailable forțează cel puțin Hold. Așadar, o axă blocantă care nu a putut rula menține verdictul: absența dovezilor nu trece niciodată o poartă.

Verdictul din tab-ul Revizuire este cel postat de finalize_review.