Para qué sirve
Hay objetivos que no caben en un solo repositorio. Una funcionalidad que necesita tu producto puede empezar con un cambio en weblabor-base, seguir en weblabor-teams y terminar en las pantallas de tu producto. Llevado a mano, eso es escribir un plan arriba, esperar a que se construya, bajar el cambio, escribir el siguiente plan, y así hasta que alguien comprueba que el objetivo funciona — mientras las preguntas esperan sin respuesta y el trabajo terminado se queda arriba.
/coordinate toma el objetivo y lo lleva hasta el final. Escríbelo en tu producto, el que muestra en sus pantallas si el objetivo se logró, seguido de lo que quieres:
/coordinate los miembros pueden invitar a un invitado a un solo proyecto
No construye nada por sí mismo y no sube nada. /next construye lo que planea, y /test lo comprueba, como con cualquier otro plan.
La entrevista
Empieza como lo hace planear antes de construir: pregunta si es urgente, y necesita la visión de tu producto — sin ella, y si nada se está incendiando, te manda primero a /vision.
Después pregunta hasta que no queda ninguna duda: qué funcionalidad necesitas, en qué pantallas y flujos, en qué estados, qué no debe cambiar y cómo vas a saber que el objetivo se logró. Mientras tanto lee cada repositorio al que llega el objetivo, para saber qué parte le toca a cada uno. Cierra la entrevista mostrándote el objetivo, los puntos que lo prueban y lo que construirá cada repositorio, y te pregunta si falta algo.
Desde ahí ya no pregunta nada más del trabajo, salvo algo de producto que no pueda sacar del objetivo, en texto normal. Contesta solo, con todo lo que le dijiste, y toma él cada decisión técnica.
La rama en la que tienen que estar tus repositorios
Cada repositorio al que llega el objetivo tiene que estar en la rama feature/update en tu computadora: tu producto, y cada repositorio entre él y el más alto que el objetivo cambia. Ahí se guardan los planes y ahí se juntan los cambios.
Cada uno de ellos por debajo del más alto necesita además una rama base-update, la que sigue la feature/update del repositorio de arriba. Ahí llega cada cambio de arriba antes de integrarse con un merge a feature/update, igual que cuando bajas uno a mano.
Si alguno está en otra rama, le falta la rama base-update que necesita, o no se encuentra su carpeta, se detiene antes de escribir nada y te dice cuál es y qué falta. Nunca te cambia de rama ni te crea una.
Si todos los cambios que necesita el objetivo están en tu propio producto, planea ahí y sigue esa cola; no hay nada que bajar.
Qué escribe, y dónde
- Un documento de coordinación, en el proyecto de tu producto en el toolkit, en la carpeta
coordination/: el objetivo, los puntos que lo prueban, los repositorios y su rama, cada plan escrito, los cambios ya bajados y las conversaciones que vigila. Cada revisión lo lee primero. Cuando el objetivo se logró y los planes de tu producto para él ya no están,/finishcorrido desde tu rama principal lo borra. - Un plan en cada repositorio que necesita un cambio, guardado en el proyecto de ese repositorio en el toolkit y marcado Listo para ejecutar. Cada plan tiene solo lo que construye ese repositorio. Un plan que está debajo de otro espera el comportamiento que necesita de arriba, y
/nextlo salta hasta que ese comportamiento llega. - Un último plan que comprueba el objetivo, en tu producto. Espera a todos los demás, y su único trabajo es abrir tu producto en el navegador y recorrer cada punto del objetivo en los estados que importan. Cuando no deja commits propios,
/finishlo borra cuando todo lo que comprueba ya llegó a tu rama principal.
Cada plan que guarda o cambia se lo avisa a la conversación donde corre /next para ese repositorio, por defecto la llamada Next steps.
Qué vigila, y cuándo se detiene
Cada 10 minutos, en una conversación propia, revisa la conversación Next steps de cada repositorio: que la cola avance, que ninguno de sus planes esté detenido por una pregunta — que contesta en el propio plan, con el motivo — y que no se haya quedado fuera un plan nuevo. Si no hay ninguna conversación con ese nombre, te pregunta cuál vigilar.
Cuando un plan de arriba queda implementado, baja ese cambio al repositorio de abajo: primero a la base-update de ese repositorio, directo desde la feature/update del repositorio de arriba, en su carpeta de tu computadora (no desde el remoto), y de ahí con un merge a su feature/update. Solo mueve base-update hacia adelante: si esa rama tiene commits que el repositorio de arriba no tiene, o no existe, te dice en qué repositorio y espera a que lo resuelvas. Como sigue el mismo camino que tú, sus merges y los tuyos se pueden alternar sin estorbarse. Luego le avisa a la conversación de ese repositorio que ya llegó lo que esperaba. No espera a los planes que una cola sigue construyendo cada uno en su propio worktree, en ese repositorio o en el de arriba, porque no se construyen sobre la rama de la que el merge lee ni sobre la que cae. Sí espera mientras una cola construye directamente sobre la rama, un plan a la vez, hasta que esa construcción termine, y mientras la cola del repositorio al que hace el merge está comprobando un plan en el navegador, para que las pantallas no cambien mientras se comprueban. Cuando el cambio que bajó es también lo que espera el siguiente repositorio de abajo, lo sigue bajando en la misma revisión, por la base-update de ese repositorio, en vez de esperar 10 minutos por cada paso. Donde el código vino del repositorio de arriba, gana la versión de arriba; donde tu repositorio lo cambió por su cuenta, conserva lo que querían los dos lados, y un conflicto que no puede resolver con certeza lo deja sin hacer y te dice el archivo y el motivo. Nunca sube nada: subir te toca a ti.
Antes de marcar el objetivo como logrado hace un barrido de cierre: lo que el trabajo del objetivo haya encontrado en sus propias pantallas y flujos — una vista que falla, un mensaje que nunca se muestra, un hallazgo que los planes dejaron — no te lo pregunta. Escribe un plan que lo corrige, en el repositorio dueño del código, y vuelve a comprobar el objetivo después. Un hallazgo en pantallas que el objetivo nunca tocó se queda donde está y se nombra en una línea, y una decisión de producto que no pueda sacar de tus respuestas es lo único que aún pregunta. Tras tres rondas de correcciones deja de escribir más y nombra lo que queda.
Se detiene cuando el último plan pasa su comprobación y el barrido ya no encuentra nada por corregir — y entonces marca el objetivo como logrado — o cuando ya no queda nada en camino. Un plan que se atora donde solo tú puedes moverlo no lo detiene: sigue con lo demás y nombra ese plan en su último mensaje. Si tu asistente no puede programar la revisión, te lo dice y te pide que le escribas cada cierto tiempo para revisar.
/design-catalog sigue sus propios planes con este mismo coordinador; mira Diseñar el catálogo de un producto.
Sigue por aquí
- Correr la cola con /next — cómo se construyen y se comprueban los planes de cada repositorio.
- Mandar un defecto a su repositorio — cómo se sabe que una parte de un cambio es de weblabor-base o de weblabor-teams.
- Verificar un plan con /test — cómo el último plan comprueba el objetivo.