Un plan es un conjunto ordenado de tareas agrupadas en fases. Lo apruebas antes de que se escriba código.
Úsalo cuando el trabajo requiera varios cambios en un orden específico, o cuando quieras ver todo el enfoque antes de comprometerte con alguna parte.
El ciclo de vida
La planificación es una etapa en sí misma, no una transformación instantánea.
- Comienza la planificación. El arquitecto explora el código base y redacta las fases y tareas.
- Revisas el borrador. Este es el punto de intervención más económico de todo el sistema.
- Aprobar, revisar o reiniciar. Al aprobarlo, se libera para ejecución; al revisarlo, se devuelve con tus comentarios; al reiniciarlo, se vuelve a planificar desde cero.
- Ejecución. Las tareas se ejecutan en orden, respetando los límites de fase.
Puedes aprobar y ejecutar en un solo paso, o aprobar y comenzar más tarde.
Revisar en lugar de reiniciar
Cuando un plan está casi listo, revisarlo conserva lo que el arquitecto aprendió sobre tu código base y aplica tus comentarios. Reiniciarlo lo descarta y comienza de nuevo.
Reinicia cuando todo el enfoque sea incorrecto. Revisa cuando el enfoque sea correcto pero los detalles no. La revisión es mucho más económica, y el contenido de un plan rechazado no se pierde: sirve como base para el siguiente intento.
Controlar un plan en ejecución
Un plan en curso puede pausarse, reanudarse o cancelarse, y puedes observar su progreso a través de las fases. También se pueden clonar planes, lo que constituye la forma práctica de repetir una estructura que funcionó bien —por ejemplo, una migración aplicada a un segundo servicio.
Los planes completados se pueden archivar para mantener la vista activa más clara.
Un único pull request, no uno por tarea
Las tareas de un plan no abren cada una un pull request. Trabajan en sus propias ramas y se fusionan en una rama de canal; esa rama se promueve como un único pull request contra tu rama base cuando el trabajo cumple los requisitos.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘Por lo tanto, revisas la funcionalidad completa de una sola vez, con todos los cambios visibles, en lugar de aprobar fases incompletas una por una.
Los planes entre proyectos son la excepción: una tarea perteneciente a un proyecto distinto al del canal se promueve por separado, por lo que obtienes un pull request por repositorio. Un pull request no puede abarcar dos repositorios.
Fases y paralelismo
Las fases definen el orden, no la concurrencia. Las tareas dentro de una fase pueden ejecutarse en paralelo si la capacidad lo permite; la siguiente fase espera a que la actual finalice.
Un plan con diez tareas aptas para paralelismo y un único slot de agente las ejecutará una tras otra. La estructura no crea capacidad — ver Capacidad y slots de agente.
¿Plan o tarea?
Tú decides, al elegir Plan de trabajo por fases o Una tarea ejecutable en el paso de enrutamiento. Nada analiza tu solicitud y decide por ti.
La prueba es la capacidad de revisión: un pull request que un compañero pueda leer de una sola vez es una tarea; cualquier cosa que requiera varios cambios ordenados es un plan.
Adivinar que algo es una tarea cuando el trabajo es realmente grande es el error más arriesgado: la tarea puede quedarse sin espacio a mitad de camino y desperdiciar la ejecución. Adivinar que es un plan te cuesta un paso de aprobación que no necesitabas estrictamente.
Puntos de entrega
Un plan puede incluir un punto de entrega que determine qué debe cumplirse antes de que su resultado avance. Ver Puntos de calidad.