Coroid finaliza creando una pull request en su propia rama, frente a tu rama base. Nunca realiza fusiones por sí solo. La fusión siempre es una decisión humana, tomada ya sea en tu proveedor o con Aprobar y fusionar en Coroid. Ver Fusión.
Lo que se incluye en ello
- 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 configurado por tu organización
- una revisión del diff, con hallazgos ya corregidos o listados
El objetivo no es reemplazar tu revisión. Es que tu revisión no sea la primera.
main- El cambio en el código4 archivos
- Pruebas escritas o actualizadas2 archivos
- Tu suite de pruebas existenteAprobado
- Requisitos de calidad1 hallazgo consultivo
- Aprobación de la revisión2 corregidos, 1 listado
Qué verificar realmente
Los aspectos mecánicos ya se han comprobado. Concéntrate en lo que solo tú puedes juzgar:
- ¿Resuelve el problema correcto? Compáralo con los criterios de aceptación de la especificación, no con tu recuerdo de lo que solicitaste.
- ¿Se adapta al código base? Convenciones, nomenclatura, la estructura de la abstracción. Coroid analiza tu código para deducir estos elementos y suele acertar en la mayoría de los casos; sin embargo, no siempre.
- ¿Qué modifica que no esperabas? Revisa la lista de archivos antes del diff.
- ¿Las nuevas pruebas son significativas? Una prueba que pasa pero no afirma nada es peor que no tener prueba alguna.
Devolver el trabajo
Tienes tres opciones, ordenadas por coste creciente:
- Comentar y solicitar re trabajo — la tarea vuelve al agente desarrollador con tus observaciones, manteniendo su contexto. Ideal para casos como "esto está bien pero está 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 en absoluto. La cancelación detiene la ejecución y libera la ranura del agente.
Sé específico en los comentarios de re trabajo, tal como lo harías con un compañero. "Esto no gestiona el caso vacío en parseRange" genera una corrección; "necesita mejoras" genera una
conjetura.
Fusión
Coroid nunca realiza fusiones por sí solo. No existe ninguna configuración que le haga fusionar cuando se complete una tarea. La fusión ocurre de dos maneras, y ambas comienzan con la decisión humana de fusionar.
Esto también se aplica al trabajo iniciado bajo un mandato Coroid registra lo que habría decidido sobre cada fusión para evaluar su propio juicio, pero nunca actúa en base a ese registro. Ver Lo que decide Coroid y lo que permanece en tus manos.
En GitHub o GitLab
Fusiona el pull request en tu proveedor, utilizando la protección de ramas habitual, las comprobaciones necesarias y las reglas de aprobación. El pull request es uno ordinario — eso es intencional — por lo que pasa por los mismos procesos de revisión y CI en los que ya confías.
Desde Coroid, con Aprobar y fusionar
Las pantallas de revisión en Coroid tienen un Aprobar y fusionar botón. Te pide que confirmes y luego Coroid fusiona el pull request por ti a través de GitHub o GitLab, utilizando la conexión al repositorio del proyecto. Es la misma operación de fusión que pulsar el botón de fusión en tu proveedor, por lo que se aplican la protección de ramas, las comprobaciones necesarias y las reglas de aprobación. Si estas impiden la fusión, Coroid muestra el motivo indicado por el proveedor y no se realiza ninguna fusión.
Lo que ocurre antes de la fusión depende de lo que estés aprobando:
- Una tarea. La tarea necesita primero un pull request. Si aún no existe, la pantalla de revisión ofrece Crear PR antes de Aprobar y fusionar. Cuando apruebas, Coroid envía la rama de la tarea para que el pull request tenga los últimos commits revisados y luego fusiona el pull request. Para aprobar una tarea se requiere acceso de escritura al proyecto correspondiente.
- Un plan. Las tareas que pertenecen a un plan no pueden fusionarse una por una. El único pull request del plan se aprueba durante la revisión de promoción. Coroid primero verifica que la rama base no haya cambiado desde que se inició el plan (ver Cuando la rama base cambia), las comprobaciones de calidad necesarias se cumplen, el pull request no presenta conflictos de fusión y ninguna puerta de control bloquea la operación. Entonces se fusiona el pull request. Para aprobar un plan se requiere acceso de escritura al proyecto correspondiente.
- Fusión forzada. La revisión de promoción de un plan también ofrece Fusión forzada. Omite las comprobaciones de la rama base, de conflictos de fusión y de puertas de control de Coroid, pero no las comprobaciones de calidad ni las reglas de tu proveedor. Requiere un motivo escrito, que se registra junto con la promoción, y acceso de administrador al proyecto.
El Asistente de chat y Clientes MCP también pueden aprobar o fusionar por fuerza los pull request de un plan. Actúan en tu nombre, por lo que se aplican las mismas comprobaciones y permisos de proyecto. El asistente siempre te pedirá confirmación previa. Una fusión forzada desde un cliente MCP siempre queda en espera en Aprobaciones para una persona. Que una aprobación desde un cliente MCP quede allí depende de tus políticas de automatización. Ninguno de ellos puede fusionar una tarea individual.
Prepara lo que se va a lanzar
Tras fusionar, abre la pestaña de tu proyecto Lanzamientos y elige Nueva versión. Selecciona el commit fusionado que deseas lanzar; Coroid muestra las solicitudes de extracción que contiene. La página de la versión guía entonces a cada entorno por cuatro pasos: comprobaciones, aprobación, despliegue y estado. Tu repositorio y CI/CD siguen encargándose del despliegue. Coroid marca una versión como desplegada solo cuando tu canal de integración lo confirma, o cuando un Propietario o Administrador registra un despliegue externo verificado.
Siguiente
Lanzamientos — prepara el commit fusionado y síguelo por cada entorno. ¿Qué hacer a continuación? enumera los otros flujos de trabajo.