Por qué el código integrado parece tuyo
Tu producto no empezó de cero. Empezó como copia de otro repositorio y sigue recibiendo sus cambios por merge: el inicio de sesión, el panel de administración, las suscripciones, los equipos. Ese código vive en tus propias carpetas, y nada en su ruta dice que vino de otro lado.
Así que un defecto en él parece un defecto tuyo. No lo es. Arreglarlo en tu producto deja roto el original, todos los demás productos construidos sobre él conservan el mismo defecto, y el siguiente merge desde arriba sobrescribe tu arreglo.
Por eso los pasos de planeación y de construcción preguntan, antes de cambiar nada, si ese código siquiera le toca a tu proyecto.
Cómo se decide de quién es
Por la historia de las líneas que están mal, nunca por el tema del código. Para cada línea, la corrida mira el cambio que la tocó por última vez y si ese cambio entró por el repositorio del que desciende tu producto. Un defecto que suena a inicio de sesión puede seguir siendo una línea que escribió tu producto, y un mismo archivo suele tener líneas de los dos.
Cuando el defecto es algo que falta y no una línea equivocada — un enlace que nadie agregó, un estado que nadie maneja — la misma pregunta se le hace al código que habría que cambiar para agregarlo.
La cadena puede ser más larga que uno. El repositorio del que desciende tu producto puede descender de otro. La corrida sigue el cambio hacia arriba hasta el repositorio que lo escribió, porque un arreglo hecho un escalón más abajo deja roto al verdadero dueño y regresa con el siguiente merge. De qué repositorio desciende tu producto se lee de la configuración de remotos de tu propio repositorio, no se adivina por el nombre de una rama.
Cuando un repositorio de esa cadena no se puede alcanzar desde tu máquina, la corrida dice cuáles revisó y cuáles no pudo, y prefiere no nombrar dueño a nombrar uno equivocado.
Un paquete funciona igual. Uno que tu proyecto descarga le pertenece a su propio repositorio. Uno que vive dentro de tu proyecto, aunque parezca instalado, es tuyo.
Qué hace una corrida con eso
No edita el otro repositorio. Trabaja solo en el proyecto en el que se inició. Dos comandos van más allá a propósito: /design-catalog puede arreglar weblabor-base o weblabor-teams cuando dices que sí, y /coordinate escribe el plan en cada repositorio que necesita su objetivo y baja cada cambio terminado con un merge.
Te entrega la petición para llevar allá: qué está mal, en qué pantalla o flujo, en qué estados y cuál sería el comportamiento correcto, escrita para que alguien que nunca vio tu conversación pueda actuar con ella. También dice que tu proyecto está esperando ese arreglo, y para qué, para que allá no se trate como un defecto aislado. Lleva esa petición a /plan-prompt en el repositorio que nombra.
El resto de tu trabajo sigue. Solo espera lo que de verdad depende del arreglo. Cuando la planeación encuentra la división, lo que le toca a tu proyecto se planea y se guarda como siempre, y la parte que espera se guarda como su propio plan. Cuando el paso de construcción la encuentra a medio camino, los puntos que dependen del arreglo se bloquean, todo lo demás se construye y se commitea, y se te indica /plan-prompt en tu proyecto para que el plan espere el arreglo en lugar de quedarse bloqueado.
Cómo se libera solo el plan que espera
El plan que espera nombra el comportamiento que está esperando — nunca un commit, una rama o una versión — y planea solo lo que construye tu proyecto. Su fila del índice se queda en Listo para ejecutar.
Cada vez que se lee la cola, busca ese comportamiento en tu código. Mientras el arreglo no se haya integrado a tu proyecto, el plan se salta y se nombra como todavía en espera. En cuanto el comportamiento está, se construye como cualquier otro plan. Nadie tiene que volver a cambiar un estado.
Un parche local también satisfaría el plan, y el trabajo puede avanzar de cualquiera de las dos formas. Eso no cierra la petición allá arriba: sigue abierta hasta que el otro repositorio la arregle, porque el siguiente merge desde arriba quitaría el parche.
Sigue por aquí
- Correr la cola con /next — cómo se retoma un plan que espera una vez que llega el arreglo.
- Planear antes de construir — qué hace
/plan-promptcon la petición en el otro repositorio. - Cómo viaja una tarea — en qué parte de una corrida se hace esta pregunta.