Ejecutar Trabajo

¿Qué hace Ejecutar Trabajo?

Ejecuta el trabajo acordado de forma autónoma en una rama significativa desde develop. Delega la implementación a subagentes en worktrees separados, luego integra mediante fast-forward sus ramas completadas en esa rama coordinadora, limpia y abre un Pull Request listo para revisión desde la rama coordinadora completada hacia develop.

La invocación autoriza ramas de tarea locales, worktrees, commits, rebase de tus propias ramas de tarea no publicadas, merges fast-forward en la rama coordinadora, la eliminación de worktrees y ramas de tarea limpias y completamente integradas, el envío de la rama coordinadora completada y la creación de su PR hacia develop. Procede sin necesidad de otra confirmación para esas acciones. Sigue el alcance y las instrucciones del repositorio del usuario, incluyendo un reemplazo explícito solo-local o sin PR. Fusionar el PR y el despliegue están fuera de la autorización de esta habilidad. Mantén cualquier prohibición existente en vigor.

1. Preparar la rama coordinadora

Lee el plan acordado, el AGENTS.md aplicable y la guía del proyecto requerida. Si el trabajo ya está definido, ejecuta sin otra ronda de diseño o aprobación. Haz solo una pregunta enfocada para un requisito faltante material.

Inspecciona el estado, las referencias y los worktrees existentes. Conserva las ediciones y los checkouts no relacionados; no los reinicies, ocultes ni reutilices. Obtén develop desde su remoto configurado cuando esté disponible y usa ese punto obtenido. Si no se puede obtener, revela la limitación y usa una referencia develop local existente; si no existe ninguna, pregunta por la base. Nunca sustituyas silenciosamente otra rama.

Antes de crear cualquier rama o worktree, captura git worktree list --porcelain, los nombres de ramas locales y los adjuntos de worktrees gestionados cuando estén disponibles. Mantén un inventario propiedad de la ejecución en la lista de tareas: rama, ruta absoluta, propietario/agente, tipo de gestión e identidad, commit final y estado de limpieza. Incluye cada tarea, ayudante, revisor, reintento y checkout de agente descendiente creado para esta ejecución, incluso si está abandonado o no contiene cambios. El coordinador es dueño de la limpieza de todo este inventario. Conserva las ramas y worktrees preexistentes y no relacionados; un prefijo de nombre coincidente no es prueba de propiedad.

Crea un worktree y rama coordinadores dedicados. Nómbralo con el estilo de rama Convencional, <tipo>/<descripción-corta>, en minúsculas con guiones, como feat/store-invitation-recovery. Elige el tipo que se ajuste al trabajo: feat (nuevo comportamiento), fix (corrección de error), refactor, perf, docs, test, chore (herramientas o mantenimiento), o ci. Si el usuario o el repositorio nombran una convención diferente (por ejemplo en AGENTS.md), sigue esa en su lugar. No incluyas integration en su nombre. Registra el commit base coordinador. En una invocación reanudada, reutiliza la rama y el worktree y el inventario de esta ejecución, inspeccionando su estado en lugar de empezar de nuevo.

2. Dividir y delegar

Divide por entregable y propiedad de archivos. Ejecuta tareas independientes de forma concurrente dentro de la capacidad de agente disponible; secuencia dependencias y ediciones superpuestas. Crea cada rama y worktree de tarea desde el punto actual de la rama coordinadora. Después de que una dependencia se integre, inicia las tareas dependientes desde el punto actualizado.

Genera subagentes reales con los requisitos de la tarea, las secciones del plan relevantes, la ruta absoluta del worktree, la rama, los archivos de su propiedad, los contratos de dependencia, los criterios de aceptación y las comprobaciones requeridas. Cada agente trabaja solo en su checkout asignado, confirma sus cambios e informa su commit, comprobaciones, inquietudes restantes y cualquier rama o worktree adicional que haya creado. Registra esos en el inventario propiedad de la ejecución inmediatamente. El coordinador solo integra y elimina worktrees. Los subagentes no deben invocar recursivamente esta habilidad de orquestación ni enviar sus ramas. Usa directorios de trabajo explícitos o git -C; los agentes pueden compartir un directorio predeterminado. Si la delegación no está disponible, reporta esa limitación en lugar de sustituir silenciosamente la ejecución en solitario.

3. Revisar tareas completadas

Inspecciona el diff real y los commits de cada tarea contra sus criterios de aceptación. Aborda los fallos con el agente propietario. Exige un checkout de tarea limpio, commits completados y comprobaciones relevantes aprobadas antes de la integración; reporta los bloqueadores preexistentes o ambientales con precisión. No fusiones trabajo solo porque un agente informe que está completo.

4. Integrar en serie con merges fast-forward

Detén las escrituras en una rama de tarea completada antes de hacerle rebase. Para cada tarea, inspecciona la ascendencia contra el punto actual de la rama coordinadora. Las ramas hermanas paralelas divergen después de la primera fusión: haz rebase de cada rama de tarea no publicada restante sobre la rama coordinadora actualizada antes de fusionar. Resuelve conflictos contra los requisitos acordados, preservando el comportamiento ya integrado; vuelve a ejecutar las comprobaciones afectadas después del rebase o la resolución de conflictos.

Ejemplo usando rutas absolutas y nombres de rama registrados:

git -C "$task_path" rebase "$work_branch"
git -C "$task_path" status --short
# Ejecuta las comprobaciones requeridas en task_path, luego verifica la ascendencia.
git -C "$work_path" merge-base --is-ancestor HEAD "$task_branch"
git -C "$work_path" merge --ff-only "$task_branch"

Inspecciona el resultado de cada comando antes de continuar. Si fast-forward falla, vuelve a inspeccionar la ascendencia y haz rebase de nuevo según sea necesario. No sustituyas un commit de merge, squash, cherry-pick, force push o reset de la rama coordinadora. Si la resolución segura requiere una decisión de producto, conserva ambas ramas y pregunta. Después de cada integración de tarea exitosa y sus comprobaciones requeridas, realiza la limpieza requerida a continuación para esa tarea inmediatamente. Revisa el trabajo combinado desde el checkout coordinador; los checkouts de tarea fusionados no son necesarios para la revisión del PR. Aplica la misma limpieza a los ayudantes propiedad de la ejecución abandonados o reemplazados una vez que su trabajo esté contabilizado.

5. Verificar, limpiar y abrir el PR

Ejecuta las comprobaciones combinadas relevantes en la rama coordinadora final y concilia el resultado contra el plan completo. Corrige las regresiones de integración antes de la finalización.

Limpieza requerida: ejecutar y verificar

La limpieza es parte del entregable, no una sugerencia para que el usuario la realice más tarde. La invocación ya autoriza la eliminación de los worktrees y ramas de tarea/ayudante limpios y completamente integrados de esta ejecución; no preguntes de nuevo por esas eliminaciones.

1. Detén el agente propietario y cualquier proceso en segundo plano que escriba en el checkout. Registra el commit final de la rama después del rebase, verifica que sea un ancestro del punto actual coordinador e inspecciona los archivos trackeados, untracked e ignorados. Para un ayudante sin commits, verifica que su punto ya esté contenido también. Contabiliza el trabajo no terminado con el propietario: integra los cambios requeridos y conserva los artefactos locales valiosos en una ubicación retenida antes de proceder. Los cachés o registros desechables generados por la ejecución se pueden eliminar por ruta exacta; no son una razón para dejar un checkout por lo demás terminado indefinidamente.

2. Para un worktree Git simple, ejecuta estas operaciones usando rutas y nombres exactos registrados, verificando cada resultado antes de continuar:

   git -C "$work_path" merge-base --is-ancestor "$task_tip" "$work_branch"
   git -C "$task_path" status --porcelain --untracked-files=all
   git -C "$work_path" worktree remove "$task_path"
   git -C "$work_path" branch -d "$task_branch"
   

   La eliminación de un worktree no elimina su rama. Ambas operaciones son requeridas. Elimina también las ramas propiedad de la ejecución que no tengan worktree restante. Nunca uses eliminación forzada, git branch -D, borrado amplio de directorios o descartar ediciones desconocidas. Diagnostica comandos fallidos y corrige problemas de limpieza ordinarios dentro del alcance en lugar de omitirlos silenciosamente.

3. Para un worktree gestionado por una aplicación, usa su API de gestión en lugar de eliminar el directorio directamente. En Codex, usa list_artifacts para resolver la identidad exacta del worktree propiedad, luego archive_worktree; inspecciona el resultado y vuelve a listar para confirmar que ya no está activo. Elimina su rama local propiedad de la ejecución después con git branch -d cuando permanezca. Una instantánea de archivo o adjunto de aplicación no sustituye la verificación del registro de Git y la eliminación de la rama.

4. Marca una entrada de inventario como limpiada solo después de verificar que su ruta exacta está ausente, ya no está registrada por git worktree list --porcelain, su rama está ausente de las referencias locales y cualquier adjunto gestionado ya no está activo. Inspecciona otros checkouts si Git dice que la rama aún está checkeada. No trates una solicitud de eliminación exitosa o el informe de un agente como prueba.

5. Inmediatamente antes de la respuesta final, después de la creación del PR o cualquier trabajo de revisión tardía, repite los inventarios de rama/worktree Git y adjuntos gestionados. Compáralos con la línea de base y el inventario propiedad de la ejecución; contabiliza nuevas entradas omitidas de informes de agentes sin eliminar trabajo concurrente no relacionado. La rama y el worktree coordinadores deben ser los únicos rama y worktree restantes propiedad de la ejecución. Consérvalos para el PR y las pruebas, junto con los checkouts preexistentes o no relacionados. Esta auditoría final es requerida incluso si la creación del PR está bloqueada u omitida, y en caso de fallo/interrupción antes de ceder cuando sea seguro.

Si la limpieza no puede finalizar de forma segura, continúa limpiando otras entradas elegibles e informa limpieza bloqueada, con cada rama/ruta retenida, la operación exacta fallida o el trabajo valioso/no fusionado, y la acción más pequeña necesaria para resolverlo. No informes el flujo de trabajo general como completo mientras queden ramas/worktrees temporales propiedad de la ejecución. Sigue trabajando en la limpieza rutinaria en lugar de finalizar en un merge exitoso, pruebas aprobadas o creación de PR.

Enviar y abrir el PR

Mantén la rama y el worktree coordinadores con todo el trabajo comprometido listos para revisión. Después de que la integración y la validación requerida tengan éxito, inspecciona el diff final y envía solo la rama coordinadora al remoto del repositorio previsto. Crea un PR listo para revisión con develop como base y la rama coordinadora como head; usa un borrador solo cuando el usuario lo solicite explícitamente. Verifica si existe un PR abierto para esta base/head antes de crear uno, incluso después de un resultado de creación incierto, y reutilízalo o actualízalo en lugar de crear un duplicado.

Sigue las plantillas de PR del repositorio, convenciones de título y requisitos de enlace a ticket. Describe el comportamiento final, las comprobaciones y sus resultados, y los pasos concretos de prueba manual. Esos pasos deben describir ejercitar el producto y/o inspeccionar el estado persistido, no otra lista de comandos de prueba del repositorio. Prefiere Git local para el envío y un conector de repositorio disponible para la creación del PR; usa una CLI autenticada cuando sea apropiado. Verifica la base real del PR, el head y el commit publicado contra la rama coordinadora completada. Adjunta cada PR creado al chat actual cuando la herramienta de adjuntar artefactos esté disponible. Deja el PR abierto para revisión.

Si el envío o la creación del PR están bloqueados, conserva la rama y el worktree coordinadores completados e informa el bloqueador exacto y la acción restante. No afirmes que existe un PR sin una URL confirmada ni hagas force push para evitar un rechazo.

Informe de finalización

La respuesta final debe comenzar con el nombre exacto de la rama coordinadora y la ruta absoluta del worktree. Incluye un enlace Markdown al PR confirmado, o indica por qué la creación del PR está bloqueada u omitida explícitamente, luego incluye:

• Qué funciona ahora: el comportamiento completado y cualquier alcance restante.
• Comprobaciones ya ejecutadas: comandos exactos y resultados reales, identificando comprobaciones omitidas o bloqueadas.
• Cómo probar: un breve procedimiento de validación numerado y ejecutable por el usuario desde el worktree coordinador. Esto es separado de las comprobaciones automatizadas y no debe cumplirse repitiendo pnpm test, lint, build o comandos similares. Incluye, según corresponda:
  • configuración: entorno/URL de la aplicación, inicio de sesión y rol, servicios, datos semilla o fixture, IDs de registro y el directorio de trabajo;
  • el flujo principal del producto: pantalla o endpoint exacto, entradas realistas y acciones de UI, el comportamiento a desencadenar y el resultado visible esperado;
  • flujos de borde o regresión relevantes: datos inválidos, vacíos, duplicados, restringidos o previamente completados cuando esos casos importen;
  • verificación del estado persistido para cambios que escriban o transicionen datos: proporciona una inspección de solo lectura de DB/API con la tabla o recurso, filtros o identificadores, campos/estados a verificar y el resultado esperado. Conecta la acción del usuario con el registro almacenado en lugar de simplemente decir "revisa la DB". Por ejemplo, un cambio de prospección debería decir crear un escaneo de territorio para un área y radio nombrados, encontrar un lugar específico, confirmar su atributo requerido, completar la acción de revisión/difusión y verificar el estado resultante de la revisión o difusión en la aplicación y los registros relevantes. Usa el mismo nivel de especificidad para otros flujos de trabajo del producto. Mantén los comandos automatizados bajo Comprobaciones ya ejecutadas. Marca cada paso manual como realizado o sugerido; si la aplicación o la base de datos no estaban disponibles, indica el bloqueador exacto y la configuración más pequeña necesaria para ejecutarlo. La inspección de la base de datos es de solo lectura a menos que el trabajo aprobado autorice explícitamente la mutación de datos de prueba.
• Limpieza y bloqueadores: recuentos verificados de worktrees temporales eliminados o archivados y ramas locales eliminadas; la rama y el worktree restantes propiedad de la ejecución de la auditoría final (normalmente solo el coordinador). Enumera cada rama/ruta temporal bloqueada y su razón exacta; incluye cualquier paso de envío o PR incompleto.

Mantén las actualizaciones de progreso concisas y finaliza con una siguiente acción concreta realizable en menos de dos minutos.