Coroid finaliza abriendo un pull request en su propia rama, frente a tu rama base. No realiza la fusión. Esa decisión sigue siendo tuya.
Qué incluye
- el cambio de código
- las pruebas escritas o actualizadas junto con él
- el resultado de ejecutar tu suite existente
- el resultado de cualquier control de calidad que tu organización haya configurado
- una revisión del diff, con hallazgos ya corregidos o listados
El objetivo no es reemplazar tu revisión. Se trata de que tu revisión no sea la primera.
Qué revisar realmente
Las cuestiones mecánicas ya se han verificado. Concéntrate en los aspectos que solo tú puedes juzgar:
- ¿Resuelve el problema correcto? Compáralo con los criterios de aceptación de la especificación, no con lo que recuerdas haber solicitado.
- ¿Se adapta al código base? Convenciones, nomenclatura, estructura de la abstracción. Coroid analiza tu código para inferir estos elementos y suele acertar — pero no siempre.
- ¿Qué modifica que no esperabas? Revisa la lista de archivos antes del diff.
- ¿Son significativas las nuevas pruebas? Una prueba que pasa pero no afirma nada es peor que no tener prueba alguna.
Devolver el trabajo
Tienes tres opciones, ordenadas por complejidad creciente:
- Comentar y solicitar re trabajo — la tarea regresa al agente desarrollador con tus observaciones, conservando su contexto. Ideal para casos de "esto está bien pero incompleto".
- Rechazar el plan y volver a ejecutar — cuando el enfoque es incorrecto, no la ejecución.
- Cancelar la tarea — cuando el trabajo no debe realizarse. Al cancelar se detiene la ejecución y se libera la ranura del agente.
Sé específico en los comentarios de re trabajo como lo harías con un compañero. "Esto no maneja el caso vacío en parseRange" genera una corrección; "necesita trabajo" genera una
suposición.
Fusión
Realiza la fusión a través de tu proveedor habitual, aplicando tus reglas normales de protección de ramas, comprobaciones requeridas y aprobaciones. Coroid abre el pull request; tu proceso existente determina su destino.
Nada relacionado con la fusión es especial; eso es intencionado. El pull request es uno más, por lo que sigue el mismo flujo de revisiones e integración continua en los que ya confías.
Siguiente
A dónde ir después — te guía hacia el resto de la documentación según lo que quieras hacer.