PR Review Console

01 Contexto

Por qué existe

02 En uso

Qué hace

03 Arquitectura

Cómo funciona

1. 1

   Recolectar por niveles

   Un solo ciclo hace toda la recolección. Cada tres minutos corre una búsqueda y enriquece solo los pull requests cuya hora de actualización cambió; una pasada más liviana y un barrido completo corren con menos frecuencia. Las observaciones van a SQLite.

2. 2

   Tres tipos de estado, un escritor para cada uno

   Lo que dijo la forja, lo que hizo la persona y lo que decidieron las reglas viven en familias de columnas separadas. El upsert del recolector nunca nombra una columna de usuario, y una prueba lo verifica byte por byte.

3. 3

   Primero las reglas

   Una función pura, sin I/O y sin reloj, clasifica cada fila en actuar, revisar, delegar, bloqueado, observar o borrador, y le asigna una prioridad. Cada decisión lleva un id de regla, un motivo hecho con plantilla y la versión de las reglas. Para dos decisiones que requieren criterio, lee el diff real.

4. 4

   Un modelo para la franja ambigua

   Solo las filas que las reglas no logran resolver, y cuya señal cambió, van al modelo, en una sola llamada en lote con presupuesto y timeout. La respuesta se revisa contra overrides estrictos, y se descarta si rompe alguno.

5. 5

   Revisiones como sesiones headless

   Una revisión es una ejecución headless de Claude Code: un orquestador con un modelo potente reparte el trabajo entre especialistas elegidos según lo que toca el cambio, como seguridad, rendimiento o datos. La salida se guarda antes de transmitirse al navegador, y el veredicto vuelve en un archivo estructurado, no extraído de la prosa.

6. 6

   Publicar sin un modelo

   Una persona envía desde el diálogo, o la consola publica sin supervisión si una política revisada por repositorio permite ese veredicto y pasan cinco controles: el head no se movió, todavía no respondiste, ninguna revisión está esperando tu respuesta, una solicitud de cambios no se envía sin supervisión (salvo dos excepciones acotadas) y sale una sola publicación por ciclo.

04 Decisiones

Las decisiones que le dieron forma

1. Decisión 01

   Triage determinista, con el modelo solo para una franja ambigua

   Elegí

   Un motor de reglas, con el modelo como asesor dentro de una zona acotada.

   En vez de

   El enfoque anterior, en el que un modelo clasificaba toda la cola.

   Porque

   Se midió. En una cola congelada de 49 pull requests, el modelo y las reglas coincidieron en 45, y las reglas acertaron en los cuatro desacuerdos. Además, las reglas son reproducibles, no cuestan nada y dan motivos estables; un motivo redactado de otra forma inundaría el feed de cambios.

   Costo

   Las reglas tienen que seguir la política a mano: subir el tope de tamaño cambió una fila fijada en la prueba golden. Parte de la ventaja vino de calcular hechos que el pipeline anterior nunca tuvo, como si ya lo aprobaste.

2. Decisión 02

   Ningún modelo en la ruta de publicación; ampliar la autonomía midiendo

   Elegí

   Una revisión propone; un archivo de políticas revisado decide si ese veredicto puede salir sin supervisión. La publicación sin supervisión viene apagada por defecto y corrió primero en modo sombra.

   En vez de

   Dejar que el skill de revisión publique, y publicar solicitudes de cambios sin supervisión, lo que iniciaría un ciclo de nuevas revisiones que el interruptor de pausa no alcanza a detener.

   Porque

   En modo sombra, de los ocho veredictos que una persona publicó de verdad, la persona coincidió con el modelo en los ocho y dejó el texto sin cambios en los ocho.

   Costo

   Pierdes la mirada de último segundo, y se necesitan varios controles para que publicar sin supervisión sea seguro.

3. Decisión 03

   Control de admisión que cuenta la máquina entera

   Elegí

   Una revisión empieza solo si la CPU y la memoria de toda la máquina están bajo sus topes, contando también las revisiones que iniciaron otras sesiones.

   En vez de

   Una cola de tareas como Celery o RQ, o un límite de concurrencia dentro de la app.

   Porque

   Varias sesiones abrieron cada una unos ocho subagentes y la máquina se quedó sin CPU ni memoria. Un límite por app no sirve cuando nada de la carga es de la app.

   Costo

   Las revisiones ajenas se reconocen por su línea de comandos, lo que es frágil y está fijado con pruebas.

4. Decisión 04

   Supervisar como OTP, no como cron

   Elegí

   Un supervisor dentro del proceso con hijos permanentes, transitorios y temporales, backoff exponencial y escalamiento después de cinco reinicios en un minuto.

   En vez de

   Tareas de cron o una biblioteca de planificación.

   Porque

   Una vez un ciclo de monitoreo se detuvo en silencio, y una instancia de respaldo sirvió una cola desactualizada durante 67 horas.

   Costo

   Un supervisor propio y una elección de líder que mantener.

5. Decisión 05

   Revisores independientes en distintas cuentas de Claude

   Elegí

   Varias cuentas con asignación lineal, round-robin o balanceada por carga, y una regla estricta: una cuenta que escribió código en un pull request no puede revisarlo.

   En vez de

   Roles fijos por cuenta, con lo que una cuenta de revisión agotada se volvía un callejón sin salida.

   Porque

   Las revisiones siguen saliendo cuando se acaba el plan de una cuenta, y nada evalúa su propio trabajo.

   Costo

   Las sesiones quedan fijadas a la cuenta que las creó.

05 Lo interesante

Vale la pena mirarlo de cerca

• El resultado de reglas contra modelo es una prueba

  La prueba golden corre el motor sobre la cola congelada de 49 filas y compara el resultado con lo que dijo el modelo. Nombra cada desacuerdo, así que un cambio a las reglas tiene que discutir con evidencia registrada.

• Honesto sobre dónde se filtra el límite

  La documentación enumera dónde «el modelo nunca publica» no es hermético: un panel de asistente puede publicar si se le pide, y autorizar un comando de la CLI autorizaba escrituras. Restringir las escrituras terminó siendo un hook fail-closed, porque los flags de permisos documentados no las restringían.

• Aprendido corriendo la CLI

  Un flag de presupuesto es un cortacircuitos, no un tope: se revisa entre turnos, y una ejecución medida gastó unas 3,8 veces un límite pequeño. La señal de salud resultó ser la cuenta de permisos denegados, no el flag de error.

• Escalar el hallazgo, no el agente

  Los especialistas corren en un modelo más barato y el orquestador mantiene el potente. Un hallazgo que necesita pensarse más va a un asesor con el modelo más potente, como máximo tres veces por revisión.

06 Hecho con agentes

Cómo encajan los agentes