Usa la revisione basata sull'IA

Questa guida mostra come far revisionare una pull request agli agenti revisori e come pubblicare il risultato su GitHub.

Avvia una revisione IA

Apri la PR e vai nella sua scheda Panoramica
Apri il menu a comparsa ⋯ nella riga delle azioni e scegli Ask AI

La voce compare solo mentre la PR è aperta: è un’azione pre-merge. Lo stesso pulsante è offerto come Ask AI nello stato vuoto della scheda Revisione, prima che esista una revisione.

Control Center avvia la pipeline pr_review preconfigurata e apre la scheda Revisione della PR così puoi seguirla. La pipeline:

Apre lo spazio di revisione della PR, il cui worktree isolato ha la PR in checkout al suo head ref
Distribuisce i revisori in base al livello di revisione dello spazio di lavoro — tre per impostazione predefinita (gli agenti preconfigurati qa, architect e engineer, in parallelo). Non c’è alcun rilevamento per linguaggio o dominio
Fa consolidare i loro rilievi in un percorso guidato all’agente lead (CEO)
Finalizza: ordina i rilievi in gruppi di consenso e calcola il verdetto. Quando l’associazione raggiunge awaiting approval, nella scheda Revisione compare Pubblica su GitHub

Quanto è profonda la revisione dipende dal Livello di revisione dello spazio di lavoro — light (un revisore), balanced (tre, il valore predefinito) o thorough (tutti e cinque, con l’aggiunta degli specialisti di sicurezza e prestazioni) — impostato in Impostazioni → Spazio di lavoro → Generale, sulla scheda Criteri dello spazio di lavoro. Un livello più leggero deposita esattamente altrettanti rilievi; ne mette in evidenza meno.

Tutti i revisori pubblicano nell’unico spazio di revisione della PR, ed è ciò che rende confrontabili i loro rilievi. Vedi Revisione IA per capire come si combinano i vari pezzi.

pr_review viene fornita solo con un trigger manuale. Per farla scattare su ogni PR pubblicata, aggiungi tu stesso un trigger — vedi Invia agenti revisori. Puoi anche avviarne una da GitHub stesso, senza bisogno di un trigger di pipeline: menziona il bot del server sulla PR oppure aggiungi l’etichetta ai-review — vedi Parla con Control Center da una PR GitHub.

Se un avviso dice che per questa pull request è già in corso una revisione, ce n’è già una in volo; resta nella scheda Revisione oppure apri Pipelines per trovarla.

Leggi i rilievi

I revisori registrano i rilievi come nodi di revisione nello spazio di revisione. Ciascuno porta con sé:

Campo	Descrizione
Tipo	`bug`, `suggestion`, `recommendation`, `question` o `ticket`
Priorità	P0 (critico) → P3 (dettaglio)
Categoria	`security`, `stability`, `data_integrity`, `correctness`, `performance` o `maintainability`
File e riga	Dove è ancorato il rilievo
Codice originale	Il codice a cui si riferisce il rilievo
Codice suggerito	La correzione proposta
Confidenza	Quanto è sicuro il revisore
Stato	`open` → `consensus-ready` → `resolved` o `dismissed`

Un rilievo raggiunge consensus-ready solo quando un revisore pari lo conferma. Un agente non può confermare un proprio rilievo, quindi l’opinione di un singolo revisore non viene mai promossa da sola.

La scheda Revisione mostra l’elenco dei rilievi, filtrabile per tipo e stato, con un interruttore per i rilievi scartati, accanto all’artefatto pubblicato dall’agente di consolidamento. La vista deterministica — coorti, dashboard multi-asse, diff di contratto e visivi — è calcolata lato server ma non ha alcuna superficie nell’app; vedi Calcolo della revisione (coorti e assi) per ciò che produce la passata.

Controlla il pannello dei disaccordi

Quando due revisori ancorano rilievi allo stesso file e alla stessa riga ma li valutano in modo molto diverso — priorità distanti due o più livelli, oppure uno che lo chiama bug e l’altro che lo chiama suggestion — sopra l’elenco dei rilievi compare un pannello dei disaccordi. Leggili per primi: sono i punti in cui le opinioni dei revisori divergono e in cui il tuo giudizio vale di più.

Leggi il verdetto

Quando l’agente lead finalizza, calcola un verdetto:

Verdetto	Significato
Ship	Nessun problema bloccante rilevato
Hold	Problemi da risolvere prima del merge
Block	Problemi critici che devono essere corretti

Il verdetto porta con sé un punteggio di confidenza aggregato e il conteggio dei rilievi per priorità.

Gli assi di revisione poi vi confluiscono e possono solo renderlo più severo. Un asse con gate che fallisce forza Block; un asse con gate che non ha potuto completarsi (partial) o non ha potuto essere eseguito affatto (unavailable) forza almeno Hold. L’assenza di prove non supera mai un gate.

Pubblica la revisione su GitHub

La pubblicazione è un passaggio separato, deliberatamente soggetto al controllo dell’utente. La pipeline pr_review mantiene la revisione in Control Center; non la pubblica su GitHub.

Nella scheda Revisione, attendi che compaia Pubblica su GitHub
Premi Pubblica su GitHub

Control Center invia una sola revisione GitHub. I rilievi già risolti o scartati vengono saltati. Il pulsante include ogni rilievo ancora aperto e, con Ship, invia APPROVE. (Lo strumento MCP publish_review_to_github usa ancora come impostazione predefinita solo i rilievi confermati dai pari e non approva, a meno che tu non passi approve_on_ship.) I rilievi ancorati a un file e a una riga diventano commenti inline; tutto il resto si ripiega nel corpo del riepilogo, ciascuno con un piè di pagina “— Control Center AI review” perché la fonte sia inequivocabile. Un verdetto Block viene inviato come REQUEST_CHANGES; Hold come COMMENT; Ship come APPROVE da questo pulsante. Poi un avviso recita Pubblicato. La revisione viene pubblicata sotto l’identità dell’app del server.

Se GitHub rifiuta un ancoraggio inline perché la riga non fa parte del diff, l’intera revisione viene inviata di nuovo con ogni rilievo ripiegato nel corpo, così nulla viene perso in silenzio.

Altre pipeline integrate pubblicano invece direttamente su GitHub: cross_review, pr_triage, ticket_to_pr e pre_merge_gate terminano ciascuna con un passaggio di commento. Solo pr_review trattiene il proprio output per te.

Invia tu stesso i revisori

Per controllare quali ruoli revisionano la PR e quali file esamina ciascuno, usa lo strumento MCP dispatch_reviewers dentro uno spazio di revisione esistente, oppure aggiungi nodi revisori a una pipeline. Entrambi i percorsi, con la firma esatta dello strumento, sono in Invia agenti revisori.