Calcul de revue (cohortes, axes et diffs déterministes)

L’onglet Revue d’une PR montre la progression en direct du pipeline de revue pendant qu’il travaille, puis l’artefact qu’il a publié, avec les actions disponibles dessus. Un seul onglet, deux états, parce qu’il s’agit de la même chose à deux moments. Ce n’est pas un onglet par défaut : une PR n’a pas de revue tant que personne n’en demande une, et c’est donc Ask AI qui l’ouvre.

Derrière cet onglet, cc_server construit des cohortes de fichiers, exécute les axes déterministes et les sert via les opérations RPC review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute et leurs jumelles watch*). Une disposition persistée qui nomme encore pr.reviewStudio ouvre ce même onglet Revue.

Dans l’onglet Revue :

L’agent de consolidation publie un artefact de conversation ordinaire avec publish_artifact, si bien que l’onglet le rend via la même visionneuse d’artefacts qu’ouvre une bulle de chat — il n’existe pas de copie du système d’artefacts en forme de revue.
Les remarques occupent un rail latéral à côté, et le verdict s’affiche dans une fine barre au-dessus de l’artefact plutôt que dans un en-tête de tableau de bord.
Un bandeau d’obsolescence apparaît lorsque la référence de tête de la PR a dépassé la revue.

Voir Utiliser la revue assistée par IA pour le déroulé et Examiner et fusionner une PR pour agir dessus.

Cohortes

Les cohortes regroupent les fichiers modifiés de la PR en groupes dérivés du contenu, réunissant les fichiers qui vont ensemble par le sens, classés par impact pour que le groupe le plus risqué se lise en premier. Elles sont recalculées à chaque changement de SHA de tête et remplacées intégralement ; chaque cohorte possède une clé stable d’un push à l’autre, si bien qu’un résumé et la progression d’une revue survivent à un rebase.

Si le dépôt n’a pas d’index de code, les cohortes se replient sur un regroupement par chemins. Pour indexer un dépôt, utilisez Paramètres → Espace de travail → Dépôts — chaque ligne de dépôt porte une action Indexer le code qui exécute le pipeline index_code et rend compte de la progression sur place.

Le graphe de code n’analyse que les langages disposant d’une grammaire fournie d’origine (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Un dépôt dans tout autre langage ne pourra jamais produire de cohortes sémantiques, quel que soit le nombre de fois où vous l’indexez.

Un agent peut consigner un résumé en markdown pour une cohorte avec set_cohort_summary et y joindre un diagramme de parcours structuré avec add_review_diagram — un objet typé de séquence, de relation entre entités ou de machine à états, jamais du texte mermaid. Chaque arête est recoupée avec le vrai graphe de code, et une arête que le graphe ne peut pas corroborer est marquée comme non vérifiée plutôt que dessinée comme un fait.

L’axe du contrat d’API

L’axe du contrat ne compare que les fichiers de spécification explicites. Il reconnaît les six noms par défaut — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — plus tout fichier modifié dont le nom contient openapi ou swagger et se termine par .yaml, .yml ou .json. Un contrat déduit du code d’un gestionnaire est hors périmètre, et les schémas GraphQL ne sont pas comparés.

Chaque changement est classé — ajouts, suppressions et modifications d’endpoints, de paramètres, de schémas et de réponses — et porte une gravité : breaking (endpoint ou paramètre supprimé, type resserré, nouveau paramètre obligatoire), non-breaking (additif) ou informative. Un changement rejeté fait échouer le verrou du contrat, tout comme un changement breaking laissé sans décision ; un changement breaking mais approuvé avertit ; en l’absence de changement breaking, le verrou est franchi. Un diff marqué dérivé (indicatif) ne verrouille jamais.

Approuver ou rejeter un changement se fait avec review_studio.setContractDecision.

L’axe visuel

Si la PR modifie des composants d’interface dans un dépôt Flutter doté d’une app Widgetbook, la passe de calcul rend les composants modifiés avant et après via une passe golden flutter test sans interface dans les arbres de travail de base et de tête de la PR, puis compare les pixels.

Les instantanés marqués changed ou removed retiennent le verrou visuel jusqu’à leur approbation ; les instantanés unchanged, added et approved le lèvent. L’indisponibilité a l’une de ces quatre raisons : pas de SDK Flutter sur l’hôte, pas d’app Widgetbook dans le dépôt, pas de cas d’usage testables en golden, ou une erreur du harnais golden.

Approuver un changement prévu se fait avec review_studio.approveVisual.

Les axes et le verdict

Axe	Piloté par
Correction	Agents relecteurs (tokens)
Sécurité	Agents relecteurs (tokens)
Lacune de tests	Agents relecteurs (tokens)
Visuel	Déterministe (harnais golden)
Contrat d’API	Déterministe (diff de spécification)

Les trois axes pilotés par les tokens sont consignés quand un agent chef de file appelle finalize_review ; les deux axes déterministes sont consignés par la passe de calcul.

Chaque axe signale l’un des états suivants :

État	Signification
Pass	A été exécuté, rien de bloquant n’a été trouvé
Warn	A été exécuté, des points non bloquants
Fail	A été exécuté et a trouvé un problème bloquant
Partial	A été exécuté mais n’a pas pu aboutir ; les résultats sont incomplets
Unavailable	N’a pas pu être exécuté du tout

Seuls pass et warn lèvent le verrou d’un axe. Partial et unavailable sont délibérément distincts de fail, et ni l’un ni l’autre ne lève de verrou.

Les axes s’agrègent en Ship, Hold ou Block, et ils ne peuvent que rendre le verdict plus sévère — il n’est jamais rétrogradé. Un axe soumis à verrou qui échoue force Block ; un axe partial ou unavailable force au moins Hold. Ainsi, un axe bloquant qui n’a pas pu s’exécuter retient le verdict : l’absence de preuve ne rend jamais un verrou vert.

Le verdict affiché dans l’onglet Revue est celui que finalize_review a publié.