Revisión en vivo
Revisa el diff de un agente antes de fusionarlo
- Revisas tú el diffEl cambio es chico y ya estás en el editor. El veredicto automático sobra.
- Dejas que doki haga la primera pasadaEl agente trabajó un rato solo y quieres saber si hay secretos, riesgos o un diff que no debería entrar.
Tres veredictos, no una nota vaga
Listo significa que la pasada automática no encontró un motivo para frenar. Revisar significa que hay algo que un humano debería mirar antes de fusionar. No fusionar significa que el diff trae un problema concreto: un secreto, un riesgo que no se acepta, un cambio que no corresponde.
No es un sello de “tests en verde” ni una aprobación de producto. Es una lectura del diff para que “terminó” no se confunda con “ya está en main”. Los tests siguen siendo los del repo.
Secretos que se cuelan en el cambio
El fallo típico es un .env copiado, una clave en un fixture o un token que el agente pegó “para probar”. La revisión los marca. Guard, por su lado, intenta que el agente ni siquiera lea ~/.ssh o ~/.aws. Son dos momentos: antes del comando y después del diff.
Un secreto marcado es motivo de no fusionar, y de limpiar la rama antes de abrir el PR. La copia de .env que doki pone en un worktree es para que el agente arranque, no para que la commitee. Más sobre ese checkout en worktrees.
Devolverle los hallazgos al agente
En vez de reescribir tú el arreglo, doki puede mandar el informe de vuelta a la misma sesión. El agente ve qué se objetó y tiene otra pasada. Si prefieres otro modelo, un combo pone a un segundo agente de revisor: Claude escribe, Codex lee, o al revés.
Ese reparto está comparado en Claude Code vs Codex. El combo se detiene cuando el veredicto queda limpio o cuando se atasca y la pregunta vuelve al Inbox.
Qué haces con la rama después
Fusionar es para cuando el veredicto y tu propia mirada coinciden. El PR, vía gh, es para el flujo del equipo: la revisión humana de siempre no se apaga porque un agente haya pasado una pasada automática. Descartar borra el experimento sin dejar ramas muertas.
La actividad queda registrada y se puede exportar a CSV o JSON: qué agente, qué tarea, qué salió. Sirve cuando más de una persona pregunta quién tocó la rama.
Qué esta revisión no cubre
No ejecuta por ti la decisión de producto ni reemplaza el CI. Un diff “listo” puede seguir rompiendo un caso que solo el pipeline ve. Tampoco lee la intención del ticket mejor que tú: si el agente construyó la cosa equivocada con un diff limpio, el veredicto no lo va a adivinar.
Los permisos de ejecución siguen en Guard. Un diff inocente no absuelve un comando peligroso que el agente quiera correr después. Las reglas están en permisos.
Preguntas frecuentes
¿La revisión automática fusiona sola?
No. El veredicto informa. Fusionar, abrir el PR o descartar es una acción tuya en la app, salvo que armes un flujo en el que tú ya decidiste esa salida.
¿Detecta cualquier secreto?
Marca los que reconoce en el diff, como claves y archivos de entorno. No es una auditoría completa del repo. Sigue mereciendo una mirada humana si el cambio toca auth o configuración.
¿Puede revisar un agente el diff de otro?
Sí, con un combo: uno construye y el otro revisa hasta aprobar o atascarse. También puedes devolverle los hallazgos al mismo agente.
¿Hace falta gh?
Solo para abrir el pull request desde doki. Fusionar o descartar el worktree no depende de GitHub.
