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

La pestaña Revisar de la PR es el progreso en directo del pipeline de revisión mientras este trabaja y, después, el artefacto que publicó, con las acciones disponibles sobre él. Una sola pestaña con dos estados, porque son lo mismo en dos momentos distintos. 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 construye cohortes de archivos, ejecuta los ejes deterministas y los sirve mediante las operaciones RPC review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute y sus gemelas watch*). Un diseño persistido 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 con el mismo visor de artefactos que abre una burbuja de chat: no existe ninguna copia del sistema de artefactos con forma de revisión.
Los hallazgos ocupan una barra lateral junto a él, y el veredicto va en una franja estrecha sobre el artefacto en lugar de en una cabecera de panel.
Aparece un aviso de obsolescencia cuando el head de la PR ha avanzado más allá de la revisión.

Consulta Usar revisión con IA para conocer el flujo y Revisar y fusionar una PR para saber cómo actuar sobre ella.

Cohortes

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

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

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

Un agente puede registrar un resumen en markdown de una cohorte con set_cohort_summary y adjuntar un diagrama de recorrido estructurado con add_review_diagram: un objeto tipado de secuencia, de relación entre entidades 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 del contrato de API

El eje del contrato solo compara archivos de especificación explícitos. Reconoce 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 a partir del código de un manejador queda fuera de alcance, y los esquemas GraphQL no se comparan.

Cada cambio se clasifica —adiciones, eliminaciones y modificaciones de endpoints, parámetros, esquemas y respuestas— y lleva asociada una gravedad: breaking (endpoint o parámetro eliminado, tipo más restrictivo, nuevo parámetro obligatorio), non-breaking (aditivo) o informativo. Un cambio rechazado no supera la compuerta del contrato, igual que un cambio breaking que quede sin decidir; un cambio breaking pero aprobado genera un aviso; y si no hay cambios breaking, la compuerta se supera. Un diff marcado como derivado (orientativo) nunca actúa como compuerta.

Aprobar o rechazar un cambio se hace con review_studio.setContractDecision.

El eje visual

Si la PR modifica componentes de UI en un repo de Flutter con una app de Widgetbook, la pasada de cómputo renderiza los componentes modificados antes y después mediante una pasada golden de flutter test en modo headless 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 indisponibilidad tiene uno de estos cuatro motivos: no hay SDK de Flutter en el host, no hay app de Widgetbook en el repo, no hay casos de uso que se puedan comprobar con golden, o hay un error del arnés golden.

Aprobar un cambio previsto se hace con review_studio.approveVisual.

Los ejes y el veredicto

Eje	Se determina por
Corrección	Agentes revisores (tokens)
Seguridad	Agentes revisores (tokens)
Brecha de tests	Agentes revisores (tokens)
Visual	Determinista (arnés 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 de uno de estos estados:

Estado	Significado
Pass	Se ejecutó y no encontró nada que bloquee
Warn	Se ejecutó y encontró aspectos no bloqueantes
Fail	Se ejecutó y 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 agregan en Ship, Hold o Block, y solo pueden hacer el veredicto más severo: nunca se rebaja. Un eje con compuerta que falla fuerza Block; uno que esté partial o unavailable fuerza como mínimo Hold. Así que un eje bloqueante que no pudo ejecutarse retiene el veredicto: la ausencia de pruebas nunca pone verde una compuerta.

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