Calcolo della revisione (coorti, assi e diff deterministici)
La scheda Revisione della PR è l’avanzamento dal vivo della pipeline di revisione mentre lavora, poi è l’artefatto che ha pubblicato, con le azioni che vi si applicano. Una sola scheda con due stati, perché sono la stessa cosa in due momenti diversi. Non è una scheda predefinita: una PR non ha alcuna revisione finché qualcuno non la richiede, quindi è Ask AI ad aprirla.
Dietro quella scheda, cc_server costruisce le coorti di file, esegue gli assi
deterministici e li serve tramite le operazioni RPC review_studio.* (cohorts,
blastRadius, cohortImpact, ciSignals, dependencyDiffs,
setContractDecision, approveVisual, compute e i loro gemelli watch*).
Un layout salvato che fa ancora riferimento a pr.reviewStudio apre questa
stessa scheda Revisione.
Nella scheda Revisione:
- L’agente di consolidamento pubblica un normale artefatto di conversazione con
publish_artifact, quindi la scheda lo visualizza tramite lo stesso visualizzatore di artefatti che apre una bolla di chat — il sistema degli artefatti non ha una copia a forma di revisione. - I rilievi stanno in una colonna laterale accanto ad esso, e il verdetto scorre su una barra sottile sopra l’artefatto invece che nell’intestazione di una dashboard.
- Compare un banner di obsolescenza quando l’head della PR è avanzato oltre la revisione.
Vedi Usa la revisione basata sull’IA per il flusso e Revisiona e unisci una PR per agire di conseguenza.
Le coorti raggruppano i file modificati della PR in gruppi derivati dal contenuto, formati da file che appartengono insieme per significato, ordinati per impatto così che il gruppo più rischioso si legga per primo. Vengono ricalcolate a ogni cambio di head-SHA e sostituite in blocco; ogni coorte ha una chiave stabile tra un push e l’altro, così un riepilogo e l’avanzamento della revisione sopravvivono a un rebase.
Se il repo non è indicizzato, le coorti ripiegano sul raggruppamento per percorsi.
Per indicizzare un repo, usa Impostazioni → Spazio di lavoro → Repository — ogni
riga di repo ha un’azione Indicizza codice che esegue la pipeline index_code
e riporta l’avanzamento sul posto.
Il grafo del codice analizza solo i linguaggi che hanno una grammatica distribuita (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Un repo in qualsiasi altro linguaggio non potrà mai produrre coorti semantiche, per quante volte tu lo indicizzi.
Un agente può registrare un riepilogo markdown per una coorte con
set_cohort_summary e allegare un diagramma strutturato di percorso guidato con
add_review_diagram — un oggetto tipizzato di sequenza, entità-relazione o
macchina a stati, mai testo mermaid. Ogni arco viene verificato in modo incrociato
con il grafo del codice reale, e un arco che il grafo non può corroborare viene
contrassegnato come non verificato anziché essere disegnato come un fatto.
L’asse del contratto API
Sezione intitolata “L’asse del contratto API”L’asse del contratto mette in diff solo i file di specifica espliciti.
Riconosce i sei nomi predefiniti — openapi.yaml, openapi.yml, openapi.json,
swagger.yaml, swagger.yml, swagger.json — più qualsiasi file modificato il
cui nome contenga openapi o swagger e termini con .yaml, .yml o .json.
Un contratto dedotto dal codice degli handler è fuori ambito e gli schemi GraphQL
non vengono messi in diff.
Ogni modifica viene classificata — aggiunte, rimozioni e modifiche di endpoint, parametri, schema e risposte — e porta con sé una gravità: breaking (endpoint o parametro rimosso, tipo reso più restrittivo, nuovo parametro obbligatorio), non-breaking (additiva) o informativa. Una modifica rifiutata fa fallire il gate del contratto, così come una modifica breaking lasciata senza decisione; una modifica breaking ma approvata genera un avviso; se non ci sono modifiche breaking, il gate è superato. Un diff contrassegnato derivato (consultivo) non fa mai da gate.
Approvare o rifiutare una modifica si fa con review_studio.setContractDecision.
L’asse visivo
Sezione intitolata “L’asse visivo”Se la PR modifica componenti UI in un repo Flutter con un’app Widgetbook, la
passata di calcolo renderizza i componenti modificati prima e dopo tramite una
passata golden headless di flutter test nei worktree base e head della PR, poi
mette in diff i pixel.
Gli snapshot contrassegnati changed o removed trattengono il gate visivo finché non vengono approvati; gli snapshot unchanged, added e approved lo sbloccano. L’indisponibilità ha una delle quattro cause seguenti: nessun Flutter SDK sull’host, nessuna app Widgetbook nel repo, nessun caso d’uso testabile con golden, oppure un errore dell’harness golden.
Approvare una modifica voluta si fa con review_studio.approveVisual.
Gli assi e il verdetto
Sezione intitolata “Gli assi e il verdetto”| Asse | Guidato da |
|---|---|
| Correttezza | Agenti revisori (token) |
| Sicurezza | Agenti revisori (token) |
| Gap di test | Agenti revisori (token) |
| Visivo | Deterministico (harness golden) |
| Contratto API | Deterministico (diff di specifica) |
I tre assi a token vengono registrati quando un agente lead chiama
finalize_review; i due assi deterministici vengono registrati dalla passata di
calcolo.
Ogni asse segnala uno dei seguenti stati:
| Stato | Significato |
|---|---|
| Pass | Eseguito, nulla di bloccante rilevato |
| Warn | Eseguito, problemi non bloccanti |
| Fail | Eseguito, rilevato un problema bloccante |
| Partial | Eseguito ma non completato; i risultati sono incompleti |
| Unavailable | Non è potuto essere eseguito affatto |
Solo pass e warn sbloccano un asse con gate. Partial e unavailable sono volutamente distinti da fail e nessuno dei due sblocca un gate.
Gli assi si aggregano in Ship, Hold o Block, e possono solo rendere il verdetto più severo — non viene mai declassato. Un asse con gate che fallisce forza Block; uno partial o unavailable forza almeno Hold. Quindi un asse bloccante che non ha potuto essere eseguito trattiene il verdetto: l’assenza di prove non rende mai verde un gate.
Il verdetto nella scheda Revisione è quello pubblicato da finalize_review.