Revizuire IA

Forma unei revizuiri

O revizuire IA este o singură rulare a pipeline-ului predefinit pr_review pe un pull request deschis. Pipeline-ul deschide spațiul de revizuire al PR-ului, distribuie agenți recenzori care citesc diff-ul în checkout-ul izolat al acelui spațiu, fiecare își depune constatările ca noduri de revizuire structurate, un agent lider le consolidează într-o parcurgere ghidată, iar un finalizator calculează un singur verdict: Ship, Hold sau Block. Ce nu face niciodată pipeline-ul este să publice — postarea pe GitHub este un pas separat, deliberat, pe care îl face un om.

Restul acestei pagini explică piesele și de ce sunt modelate astfel.

Un spațiu de revizuire per PR

Contextul de revizuire al unui PR este un spațiu de mesagerie — modul review, tipul pr — legat de pull request printr-o asociere de spațiu de revizuire. Este creat idempotent: pagina PR-ului, pipeline-ul de revizuire și suprafețele de chat rezolvă toate un singur spațiu suport al PR-ului prin același traseu de cod, astfel încât un șablon care revizuiește un PR și un om care îl deschide nu pot ajunge niciodată în două camere diferite, uitându-se la două checkout-uri diferite.

Worktree-ul izolat al spațiului are PR-ul extras la ref-ul său de vârf. O singură cameră înseamnă și un singur checkout: fiecare recenzent lucrează în același spațiu, în loc ca fiecare să primească propria clonă a spațiului de lucru.

Fiecare recenzent publică într-un flux propriu, cu nume, în interiorul acelui singur spațiu, iar constatările sunt mesaje review_node, nu text simplu. Adunarea la nivel de spațiu de la final este intenționată — un verdict calculat din constatările unui singur fir ar fi, în tăcere, un verdict despre un singur recenzent.

Asocierea are o scară de stări — requested → in progress → awaiting approval → completed — care este cea care condiționează Publică pe GitHub în tab-ul Revizuire al PR-ului.

Niveluri de revizuire

Cât de profund merge o revizuire este o politică de spațiu de lucru cu trei niveluri, setată în Setări → Spațiu de lucru → General, pe cardul Politică spațiu de lucru:

Nivel	Recenzenți care sunt distribuiți	Raportare
light	Doar inginerul	Doar ce contează cu adevărat
balanced	Inginer, QA, arhitect (implicit)	Verificarea obișnuită
thorough	Toți cinci, inclusiv securitate și performanță	Nimic retrogradat

Nivelul mișcă simultan două cadrane: ce recenzenți sunt distribuiți, impus de porțile de stare runWhen ale șablonului de pipeline, nu de formularea promptului — formularea promptului poate fi ignorată, o poartă nu — și unde sunt afișate constatările sub prag. Niciunul dintre cadrane nu șterge vreodată o constatare: un nivel care raportează mai puțin înregistrează exact la fel de mult și grupează restul.

Trecerea de securitate și cea de performanță refolosesc agenții predefiniți de arhitect și inginer, în loc să introducă unii noi. Specializarea este instrucțiunea cu care este trimis recenzentul, nu un agent separat per axă — un agent per axă ar însemna cinci rânduri în plus în fiecare spațiu de lucru, fără nicio capacitate suplimentară. Selecția recenzenților nu inspectează niciodată diff-ul după limbaj sau domeniu.

Nodurile de revizuire: constatările ca date, nu ca text

O constatare înregistrată cu add_review_node devine un nod de revizuire pe PR — ceea ce randează tab-ul Revizuire, ceea ce stă la baza calculării verdictului și ceea ce “Publică pe GitHub” transformă într-un comentariu inline. Un recenzent care returnează doar text produce o rulare de pipeline care pare reușită și o suprafață de revizuire goală; înregistrarea este partea esențială.

Fiecare nod conține:

Câmp	Valori
Tip	bug, suggestion, recommendation, question, ticket
Prioritate	P0 (critic) → P3 (minor)
Triplet de triaj	categorie (security, stability, …), severitate, efort
Ancoră	Calea fișierului, începutul și sfârșitul liniei
Remedierea transportată	Linii de înlocuire sugerate, un diff opțional, un prompt de remediere opțional
Încredere	Un scor [0, 1]
Raționament	Analiza, scrisă înainte de constatare

Două detalii sunt intenționate. O sugestie GitHub cu un singur clic este oferită doar când recenzentul a furnizat linii de înlocuire exacte — deducerea lor dintr-un diff unificat dă greș în tăcere, iar un commit cu un singur clic al unei deducții greșite este mai rău decât niciun buton. Și schema add_review_node prezintă reasoning înaintea constatării, astfel încât un model care completează obiectul în ordinea schemei scrie analiza prima. Câmpul este opțional: omiterea lui nu respinge nodul. Un nod al cărui payload este malformat dispare, în loc să polueze revizuirea.

Consensul între colegi

Un nod trece prin open → consensus-ready → resolved sau dismissed. Pasul din mijloc este inima modelului: o constatare avansează doar când un coleg recenzent o confirmă, iar un agent nu își poate confirma niciodată propria constatare. Instrumentul MCP publish_review_to_github și implicitul RPC publică în continuare doar constatări confirmate de colegi. Butonul Publică pe GitHub din tab-ul Revizuire trimite, în schimb, fiecare constatare deschisă rămasă.

Regula este impusă în trei locuri independente — instrumentul de confirmare, finalizatorul și publicatorul — astfel încât rezistă la un apelant cu erori în oricare dintre ele. Toate schimbările de stare trec printr-un singur serviciu, ceea ce face ca o stare să însemne ceva: înainte de asta, două jumătăți de traseu puteau să nu fie de acord dacă aceeași constatare era rezolvată.

Când recenzenții nu sunt de acord — același fișier și aceeași linie, priorități la două sau mai multe niveluri distanță sau unul numindu-l bug în timp ce celălalt îl numește suggestion — dezacordul este scos în evidență deasupra listei de constatări. Acolo diverg opiniile recenzenților și acolo judecata unui om valorează cel mai mult.

Respingerea unei constatări scrie de asemenea un fapt de suprimare slabă în domeniul de memorie, la încredere scăzută — o singură respingere este o preferință, nu o regulă.

Cohorte: în jurul a ce se grupează revizuirea

Trecerea de calcul a revizuirii grupează fișierele modificate ale unui PR în cohorte derivate din graful de cod: fișierele modificate se mapează pe simbolurile pe care le ating, simbolurile pe componentele conectate, iar cohortele sunt clasate după raza de impact. O cohortă are o ordine de citire ghidată, diagrame și observații, în loc să fie o listă plată de fișiere.

Două reguli de onestitate modelează acest lucru. Cheile cohortelor sunt derivate din conținut și stabile de-a lungul push-urilor, astfel încât constatările și progresul revizuirii supraviețuiesc unui rebase sau force-push, în loc să rămână orfane. Iar când repo-ul nu are index de cod, gruparea revine la căi simple și spune asta — fallback-ul nu simulează niciodată încredere semantică.

Axele și porțile revizuirii

Alături de constatările recenzenților, o revizuire acumulează rezultate de axe: șase axe, de două tipuri.

Axă	Tip	Dedusă din
correctness, security	Determinată de token-uri	Constatările recenzenților înșiși
testGap	Determinată de token-uri	Constatările recenzenților
visual, apiContract	Deterministă	Calculată fără consum de token-uri
performance	Deterministă	Doar enumerare — nimic din produs nu calculează un rezultat

Un verdict de axă este pass, warn, fail, partial sau unavailable — și doar pass sau warn trece o poartă. Distincția dintre fail, partial și unavailable este esențială: o axă cu poartă care nu a putut fi finalizată sau nu a putut rula deloc reține verdictul general, în loc să îl treacă. Absența dovezilor nu se transformă niciodată într-o poartă verde.

Anumite axe sunt consultative intenționat. Axa lacunelor de testare derivată din cohorte nu poate vedea acoperirea injecției de dependențe sau a fabricilor — un repo neindexat cu o suită temeinică și unul fără niciun test arată identic de acolo, așa că a afirma oricare dintre ele ar fi o minciună; ea apare în tabloul de bord fără să impună o poartă. Axele bazate pe token-uri sunt consultative pentru că prioritățile constatărilor conduc deja verdictul, iar o condiționare din nou pe baza lor ar dubla numărătoarea.

Verdictul

Finalizatorul calculează verdictul pentru constatările cu starea open sau consensus-ready:

• orice constatare P0 cu încredere ≥ 0,7 → Block
• altfel, orice P0 (încredere scăzută) sau orice P1 → Hold
• altfel → Ship

Verdictul are o încredere agregată derivată din dispersia încrederilor contribuitoare — acordul o ridică, divergența o scade.

Consolidarea agentului lider (CEO) este o trecere editorială, nu o relistare: o a doua copie scrisă de mână a constatărilor este exact ce se îndepărtează de cea reală. Constatările duplicate sunt retrogradate, nu repetate — mai mulți recenzenți sunt îndreptați spre un singur diff, cu atribuții care se suprapun intenționat, așa că același defect care ajunge de trei ori la finalizator înseamnă că sistemul funcționează; publicarea lui de trei ori înseamnă că sistemul își scurge propria arhitectură în inbox-ul cititorului. La o revizuire repetată, constatările sunt amprentate și comparate cu runda anterioară, astfel încât delta este cea care iese la suprafață.

În final, axele se adaugă, și pot doar să facă verdictul mai sever: o axă cu poartă care eșuează forțează Block — constatările nu o pot depăși la vot —, iar o axă cu poartă care nu a putut fi finalizată forțează cel puțin Hold.

Publicarea rămâne la tine

Pipeline-ul nu postează intenționat pe GitHub; publicarea este condiționată de utilizator, astfel încât o revizuire nu poate fi publicată niciodată de două ori. Când apeși Publică pe GitHub:

• Se trimite o singură revizuire GitHub. Constatările deja rezolvate sau respinse sunt sărite. Butonul publică fiecare constatare deschisă rămasă (selection: all_open). Instrumentul MCP publish_review_to_github folosește în continuare implicit doar constatările confirmate de colegi (consensus).
• Constatările ancorate la un fișier și o linie devin comentarii inline; tot restul se pliază în corpul rezumatului, fiecare purtând un subsol “— Control Center AI review”, astfel încât sursa este neechivocă.
• Ancorele sunt reverificate față de diff-ul actual al PR-ului în momentul publicării. Un comentariu pe cod care a fost deja rescris este cel mai distructiv lucru pentru încredere pe care îl poate lăsa un recenzent; dacă GitHub respinge totuși o ancoră inline, întreaga revizuire este retrimisă cu fiecare constatare pliată în corp, astfel încât nimic nu este eliminat în tăcere.
• Un verdict Block este trimis ca REQUEST_CHANGES; Hold ca COMMENT; Ship ca APPROVE din buton (approve_on_ship: true). Instrumentul MCP lasă Ship ca COMMENT dacă nu transmiți approve_on_ship.
• Revizuirea este postată sub identitatea de aplicație a serverului. Cine a apăsat Publică este înregistrat pentru poarta de rol și jurnalul de audit; nu este autorul GitHub.

Publicarea declară clasa de acțiune prPublish, astfel încât punctul de control al guardrail-urilor o condiționează ca orice acțiune care mută date — solicită aprobare implicit și eșuează închis când nu este conectat niciun aprobator. Vezi Guardrail-uri.

Ce poate face un recenzent

Agenții recenzori rulează în modul review: un sandbox doar-citire și o listă de instrumente permise, selectată, care acoperă constatări, comentarii, tichete și revizuirea între colegi — dar fără mutații. Un recenzent nu poate repara codul pe care îl critică; poate atașa o remediere sugerată pe care o aplică un om. Mesajul de refuz al modului îi spune unui agent care încearcă totuși să acționeze să finalizeze revizuirea și să lase utilizatorul să acționeze pe baza rezumatului publicat.

Concepte conexe

• Guardrail-uri — motorul de politici care condiționează publicarea
• Moduri — ce schimbă modul review pentru un agent
• Pipeline-uri și automatizare — motorul pe care rulează revizuirea
• Ciclul de viață al trimiterii agenților — de unde vine worktree-ul izolat

Ghiduri conexe

• Folosește revizuirea bazată pe IA — rulează o revizuire și publică-o
• Trimite agenți revizori — alege singur recenzenții
• Calculul revizuirii (cohorte și axe) — cohorte, axe și diff-uri