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

L’onglet Revue d’une PR, c’est la progression en direct du pipeline de révision pendant qu’il travaille, puis l’artéfact qu’il a publié, avec les actions qui s’y rattachent. 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 révision tant que personne n’en demande une, et c’est donc Ask AI qui l’ouvre.

Derrière cet onglet, cc_server construit les cohortes de fichiers, exécute les axes déterministes et les expose par 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 artéfact de conversation ordinaire avec publish_artifact ; l’onglet le rend donc dans le même visualiseur d’artéfacts qu’ouvre une bulle de clavardage — il n’existe aucune copie du système d’artéfacts propre à la révision.
Les constats figurent dans un rail à côté, et le verdict s’affiche dans une mince barre au-dessus de l’artéfact plutôt que dans un en-tête de tableau de bord.
Une bannière d’obsolescence apparaît lorsque la tête de la PR a avancé depuis la révision.

Voyez Utiliser la révision assistée par IA pour le déroulement et Examiner et fusionner une PR pour passer à l’action.

Cohortes

Les cohortes regroupent les fichiers modifiés d’une PR en groupes dérivés du contenu, réunissant des fichiers qui vont ensemble par leur sens, et les classent 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 en bloc ; chaque cohorte a une clé stable d’un push à l’autre, de sorte qu’un résumé et la progression d’une révision survivent à un rebase.

Si le dépôt n’est pas indexé, les cohortes se rabattent sur un regroupement par chemin. 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 signale sa progression sur place.

Le graphe de code n’analyse que les langages pour lesquels une grammaire est livrée (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, peu importe le nombre de fois où vous l’indexez.

Un agent peut consigner un résumé 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 d’entités ou de machine à états, jamais du texte mermaid. Chaque arête est recoupée avec le graphe de code réel, et une arête que le graphe ne peut pas corroborer est marquée comme non vérifiée plutôt que tracée comme un fait.

L’axe du contrat d’API

L’axe du contrat ne compare que les fichiers de spécification explicites. Il correspond aux six noms par défaut — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — ainsi qu’à 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 portée, et les schémas GraphQL ne sont pas comparés.

Chaque changement est classé — ajouts, suppressions et modifications de points de terminaison, de paramètres, de schémas et de réponses — et porte une gravité : breaking (point de terminaison ou paramètre supprimé, type resserré, nouveau paramètre obligatoire), non-breaking (additif) ou informational. Un changement rejeté fait échouer le verrou du contrat, tout comme un changement breaking laissé sans décision ; un changement breaking approuvé produit un avertissement ; l’absence de changement breaking passe. Un diff marqué derived (advisory) ne verrouille jamais.

Approuver ou rejeter un changement, c’est review_studio.setContractDecision.

L’axe visuel

Si la PR modifie des composants d’interface dans un dépôt Flutter doté d’une appli Widgetbook, la passe de calcul rend les composants modifiés avant et après au moyen d’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 maintiennent le verrou visuel jusqu’à leur approbation ; les instantanés unchanged, added et approved le lèvent. L’indisponibilité a l’une de quatre causes : « no Flutter SDK on host », « no Widgetbook app in repo », « no golden-testable use-cases » ou « golden harness error ».

Approuver un changement souhaité, c’est review_studio.approveVisual.

Les axes et le verdict

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

Les trois axes à jetons sont consignés quand un agent principal 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 préoccupations non bloquantes
Fail	A été exécuté, un problème bloquant a été trouvé
Partial	A été exécuté, mais n’a pas pu se terminer ; les résultats sont incomplets
Unavailable	N’a pas pu s’exécuter du tout

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

Les axes se combinent en Ship, Hold ou Block, et ils ne peuvent que rendre le verdict plus sévère — il n’est jamais revu à la baisse. Un axe verrouillé 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 fait jamais passer un verrou au vert.

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