Cómputo de revisión (cohortes, ejes y diffs deterministas)

La pestaña Revisar de la PR es el progreso en vivo del pipeline de revisión mientras trabaja y, después, el artefacto que publicó, con las acciones sobre él. Una sola pestaña con dos estados, porque son la misma cosa en dos momentos. No es una pestaña predeterminada: una PR no tiene revisión hasta que alguien la pide, así que Ask AI es lo que la abre.

Detrás de esa pestaña, cc_server arma cohortes de archivos, ejecuta los ejes deterministas y los sirve mediante las operaciones RPC de review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute y sus pares watch*). Una disposición persistida que todavía se llame pr.reviewStudio abre esta misma pestaña Revisar.

En la pestaña Revisar:

El agente consolidador publica un artefacto de conversación normal con publish_artifact, así que la pestaña lo representa mediante el mismo visor de artefactos que abre una burbuja de chat: no existe una copia del sistema de artefactos con forma de revisión.
Los hallazgos se ubican en un carril lateral junto a él, y el veredicto viaja en una barra delgada por encima del artefacto, no en el encabezado de un panel.
Aparece un aviso de desactualización cuando el head de la PR avanzó más allá de la revisión.

Consulta Usar revisión impulsada por IA para ver el flujo y Revisar y fusionar una PR para actuar sobre ella.

Cohortes

Las cohortes agrupan los archivos modificados de la PR en grupos derivados del contenido, formados por archivos que van juntos por su significado y ordenados por impacto, de modo que el grupo más riesgoso se lea primero. Se recalculan con cada cambio del SHA del head y se reemplazan por completo; cada cohorte tiene una clave estable ante pushes, así que un resumen y el progreso de la revisión sobreviven a un rebase.

Si el repositorio no tiene índice de código, las cohortes recurren a la agrupación por rutas. Para indexar un repositorio, usa Ajustes → Espacio de trabajo → Repositorios: cada fila de repositorio incluye una acción Indexar código que ejecuta el pipeline index_code e informa el progreso en el mismo lugar.

El grafo de código solo analiza los lenguajes que tienen una gramática incluida (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Un repositorio en cualquier otro lenguaje nunca podrá producir cohortes semánticas, por más veces que lo indexes.

Un agente puede registrar un resumen en markdown para una cohorte con set_cohort_summary y adjuntar un diagrama de recorrido estructurado con add_review_diagram —un objeto tipado de secuencia, de entidad-relación o de máquina de estados, nunca texto de Mermaid—. Cada arista se contrasta con el grafo de código real, y una arista que el grafo no puede corroborar se marca como no verificada en lugar de dibujarse como un hecho.

El eje de contrato de API

El eje de contrato solo calcula el diff de archivos de especificación explícitos. Coincide con los seis nombres predeterminados —openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json— más cualquier archivo modificado cuyo nombre contenga openapi o swagger y termine en .yaml, .yml o .json. Un contrato inferido del código de los manejadores queda fuera de alcance y los esquemas de GraphQL no se comparan.

Cada cambio se clasifica —adiciones, eliminaciones y modificaciones de endpoints, parámetros, esquemas y respuestas— y lleva una severidad: breaking (endpoint o parámetro eliminado, tipo restringido, nuevo parámetro obligatorio), no breaking (aditivo) o informativo. Un cambio rechazado no pasa la compuerta de contrato, y uno breaking que quede sin decidir tampoco; un cambio breaking pero aprobado genera una advertencia; y si no hay cambios breaking, se pasa. Un diff marcado como derived (advisory) nunca actúa como compuerta.

Aprobar o rechazar un cambio es review_studio.setContractDecision.

El eje visual

Si la PR cambia componentes de UI en un repositorio de Flutter con una app de Widgetbook, la pasada de cómputo renderiza los componentes modificados antes y después mediante una pasada golden headless de flutter test en los worktrees base y head de la PR, y luego compara los píxeles.

Las instantáneas marcadas como changed o removed retienen la compuerta visual hasta que se aprueban; las instantáneas unchanged, added y approved la superan. La falta de disponibilidad tiene uno de cuatro motivos: no hay SDK de Flutter en el host, no hay app de Widgetbook en el repositorio, no hay casos de uso comprobables con golden, o hay un error en el arnés de golden.

Aprobar un cambio intencional es review_studio.approveVisual.

Los ejes y el veredicto

Eje	Determinado por
Corrección	Agentes revisores (tokens)
Seguridad	Agentes revisores (tokens)
Brecha de pruebas	Agentes revisores (tokens)
Visual	Determinista (arnés de golden)
Contrato de API	Determinista (diff de especificación)

Los tres ejes de tokens se registran cuando un agente líder llama a finalize_review; los dos ejes deterministas los registra la pasada de cómputo.

Cada eje informa uno de los siguientes valores:

Estado	Significado
Pass	Se ejecutó; no se encontró nada que bloquee
Warn	Se ejecutó; hay aspectos no bloqueantes
Fail	Se ejecutó; se encontró un problema bloqueante
Partial	Se ejecutó, pero no pudo completarse; los resultados están incompletos
Unavailable	No pudo ejecutarse en absoluto

Solo pass y warn superan un eje con compuerta. Partial y unavailable son deliberadamente distintos de fail y ninguno de los dos supera una compuerta.

Los ejes se integran en Ship, Hold o Block, y solo pueden hacer el veredicto más grave: nunca se degrada. Un eje con compuerta que falla fuerza Block; uno que quede partial o unavailable fuerza como mínimo Hold. Así, un eje bloqueante que no pudo ejecutarse retiene el veredicto: la ausencia de evidencia nunca pone en verde una compuerta.

El veredicto que se muestra en la pestaña Revisar es el que registró finalize_review.