Cargando…

Esto está tardando más de lo esperado.

Correr la cola con /next

Cómo se van trabajando los planes marcados como listos, qué significa cada estado del índice, dónde espera una pregunta tu respuesta y cómo se corrige una revisión que falla.

Qué es la cola

Cada plan que guardas recibe una fila en el índice de análisis de tu proyecto, con un estado. Los planes cuyo estado es Listo para ejecutar, en la rama en la que estás, forman la cola. /next los toma en orden de número, construye cada uno, lo abre en tu navegador para comprobar que lo que el plan prometió está ahí, y escribe de vuelta hasta dónde llegó cada uno como su estado, que el índice muestra. El índice y los planes viven en el toolkit, en la sección Proyectos, así que esas escrituras nunca se vuelven commits en tu repositorio.

Los planes de otra rama no se corren, sea cual sea su estado; la corrida te avisa que existen. Un plan solo pasa a otra rama cuando tú lo pides. Un plan que se apoya en otro solo corre cuando ese otro está en la misma rama.

No pregunta antes de empezar: cada plan ya se confirmó en la conversación que lo planeó. Lo que hace primero es decirte qué planes van a correr, cuáles deja como están y por qué. Ese es el momento de acotar la cola si solo quieres algunos.

Una cola vacía es una respuesta, no un problema.

Los estados del índice

El toolkit guarda el estado de un plan junto al documento, nunca escrito dentro de él.

Estado Qué significa para la cola
Listo para ejecutar El plan está cerrado y listo para construirse. La cola lo toma.
En desarrollo Se está construyendo en este momento.
Bloqueado Se detuvo, y la razón quedó escrita: en su checklist, o como una pregunta para ti en el documento.
En espera Estacionado a propósito. Solo tú lo mueves.
Implementado Construido y verificado. Se queda hasta que su código llega a tu rama principal: /finish, corrido desde ahí, lo elimina entonces para siempre, salvo que otro plan aún dependa de él o que ningún commit lleve su número — /finish dice por qué conservó cada uno. Un plan que solo comprueba otros, como el último plan de /coordinate, normalmente no deja commits: entonces se va cuando todo lo que comprueba ya llegó a tu rama principal.
Pausado, Descartado Los pone una persona, y la cola no los toca.

Listo para implementar es otro estado, y la cola nunca lo toma. Pertenece a un análisis de negocio cuyo alcance ya está resuelto y que todavía hay que planear con /plan-prompt. Listo para ejecutar es el otro extremo del mismo trabajo: el plan técnico está cerrado y solo falta construirlo.

Planes que se apoyan en otros planes

Un plan puede nombrar los planes en los que se apoya. Corre solo cuando cada uno de ellos está implementado, ya se construyó antes en la misma corrida, o va antes que él en la cola. Cuando alguno no lo cumple, el plan se salta en esta corrida y se nombra en el anuncio inicial con todo lo que sigue esperando. Su fila del índice se queda en Listo para ejecutar, así que la cola vuelve a preguntar la siguiente vez que se lee.

Cuando lo que espera está bloqueado, en espera, pausado o descartado, nada lo va a mover solo, y el reporte lo dice: eso le toca a alguien.

Un plan también puede esperar un arreglo en otro repositorio. Ese caso está en Mandar un defecto al repositorio que lo posee.

Varios planes a la vez

Cada plan se construye en su propio worktree de git — una copia de trabajo aparte de tu repositorio — aunque la cola tenga uno solo. Se construyen hasta seis en paralelo. Cada uno que regresa se integra a tu rama de trabajo, y solo entonces se revisa en el navegador.

Cada plan se construye a partir de lo que dice. Su plan técnico, al final, es una guía: donde el código resulta distinto, la construcción decide, la corrida anota en el plan lo que encontró y nada se detiene a preguntarte. Una elección técnica que contestaste al planear se sigue como la contestaste. Un plan que lleva un dibujo que aprobaste se construye hacia ese dibujo, y la revisión en el navegador compara la pantalla terminada con él.

Hay un solo navegador, así que las revisiones corren una tras otra, por lotes. Un lote lleva hasta cinco planes que necesitan el mismo estado del navegador: el mismo usuario, el mismo equipo, la misma configuración. Un plan grande va en un lote propio.

Algunos planes tienen que esperar su turno:

  • Dos planes que nombran el mismo archivo nunca se construyen al mismo tiempo. El posterior espera a que el anterior se integre, y se construye encima de él.
  • Un plan que rehace pantallas en toda la aplicación corre al final y solo.
  • Un plan que se apoya en otro espera a que ese se integre.

Ves una tabla cuando la corrida anuncia la cola, de nuevo después de cada paso y una vez más al cerrar, sea cual sea el camino que tome la corrida, y aunque la cola tenga un solo plan. Cuenta qué está terminado, construyéndose, esperando el navegador, en revisión, esperando a que presiones un botón, en cola, esperando su corrección, esperando otro plan, esperando tu respuesta, bloqueado o rechazado; un estado sin nada sigue teniendo su fila. La tabla es como sabes que la corrida sigue trabajando, así que nunca se omite: abre el mensaje de cada paso, y un paso reportado sin ella es una falla que la corrida corrige en ese mismo mensaje. Un plan que tarda mucho en construirse no muestra nada nuevo propio hasta que vuelve: ya cuenta como construyéndose desde la tabla que lo mostró empezando, y la última tabla que viste sigue diciendo dónde va la corrida.

La tabla conserva las mismas filas, en el mismo orden y con las mismas columnas, durante toda la corrida, por larga que sea: solo sus nombres están en tu idioma. Pide el estado como quieras —«dame status», «actualízame la tabla», «cómo vamos»— y la respuesta es esa tabla tal como está. Un plan que se vuelve a construir para una corrección aparece de nuevo construyéndose, luego esperando el navegador y en revisión, como en su primer intento, con «intento N de 3» al lado. «Esperando su corrección» solo significa que su reconstrucción todavía no arranca, por lo general porque todavía no hay lugar libre o porque otro plan por el que tiene que esperar se sigue construyendo.

Algunos controles no se dejan presionar por la extensión del navegador, como los botones de la página de autenticación de prueba de un proveedor de pagos. Cuando pasa eso, la corrida prepara una pestaña limpia, te dice qué pestaña y qué botón presionar, y comprueba el resultado ella misma.

Solo cuando tu asistente no puede aislar un agente en un worktree los planes corren uno a la vez: construir, revisar, y el siguiente. Es la misma cola, solo más lenta: igual toma los planes nuevos, no te pregunta nada sobre el trabajo y te muestra la misma tabla en los mismos momentos.

Planes que aparecen mientras corre

La cola se vuelve a leer después de cada paso. Un plan que guardas mientras la corrida trabaja, o uno que desbloqueas contestando sus preguntas en otra conversación, lo toma la misma corrida: no tienes que volver a lanzarla. Cuando ya no queda nada por construir ni revisar, la cola se lee una última vez: si hay algo nuevo, la corrida sigue; si no, cierra y reporta. Nunca se queda esperando planes que todavía no existen.

Una pregunta escrita en el plan

La corrida nunca se detiene a preguntarte nada sobre el trabajo ni si debe seguir, construya varios planes o uno solo — lo único que puede pedirte es presionar un botón que solo tú puedes presionar. Si le preguntas algo mientras corre, te responde y sigue. Cuando un plan necesita una decisión que solo tú puedes tomar, la pregunta se escribe en el plan mismo, bajo Preguntas abiertas: numerada, con sus opciones, lo que depende de la respuesta y una línea de respuesta vacía. La fila del plan pasa a Bloqueado, lo que no dependía de la respuesta se construye y se conserva, y el resto de la cola sigue avanzando.

Respondes en otra conversación, cuando quieras, y el asistente de ahí escribe cada respuesta en el plan. La siguiente vez que se lee la cola — o en cuanto lo digas — cada respuesta pasa a la sección que registra las preguntas hechas y las respuestas que recibieron, la sección de Preguntas abiertas desaparece y el plan vuelve a Listo para ejecutar, siempre que nada más lo detenga. Si la corrida sigue en marcha, ella misma lo vuelve a tomar. Una línea de respuesta vacía mantiene el plan bloqueado.

Al final tampoco se pregunta nada: el reporte lista cada plan que espera respuestas, con sus preguntas escritas completas.

Cuando la revisión falla

Cuando la revisión en el navegador encuentra que algo que el plan prometió no está, escribe la corrección en el mismo plan, como una entrada numerada de su sección Validaciones: qué falló, cómo se reprodujo, las soluciones consideradas y la elegida. No se crea ningún documento ni número nuevo. La cola vuelve a construir el mismo plan a partir de esa entrada — rehaciendo solo lo que no está hecho — y revisa de nuevo el plan entero.

Ese ciclo corre tres intentos como máximo, contando la primera construcción. Si pasa, el plan queda implementado. Una tercera falla bloquea el plan con sus tres entradas a la vista, la última abriendo con un replanteamiento del plan, y lo regresa a /plan-prompt: un plan que falla tres veces necesita repensarse, no un cuarto intento.

Solo una revisión fallida cuya entrada eligió una solución entra al ciclo. Una revisión que no pudo correr — ningún navegador conectado, credenciales que nadie tiene — bloquea el plan con lo que faltó, y la corrida sigue.

Planes que escribió /design-catalog

Un plan que escribió /design-catalog tiene una revisión más. Cuando la revisión en el navegador lo aprueba, y antes de marcarlo implementado, ux-designer abre las pantallas que construyó y las juzga contra tu catálogo y tu manual de identidad. Si siguen los dos, el plan queda implementado. Si no, la corrección del diseñador se escribe en la sección Validaciones del mismo plan, y la cola construye a partir de ella, lo revisa y lo vuelve a juzgar, dentro de los mismos tres intentos; un plan que los agota va a /plan-prompt, como cualquier otro plan. No se te pregunta por esa corrección: ya confirmaste el plan, y la corrección solo devuelve lo construido a él. Esta revisión nunca corre junto a otra revisión en el navegador, y los planes que escribió cualquier otro comando no pasan por ella. Cómo se proponen y se escriben esos planes está en Diseñar el catálogo de un producto.

Lo que deja una corrida

El estado de cada plan en el índice, cada fila del checklist marcada como hecha o bloqueada con su razón, y los commits que construyeron el código. Los planes implementados se quedan hasta que su código llega a tu rama principal, y /finish, corrido desde ahí, los elimina; para limpiar también los rechazados, o para renumerar, usa Borrar finalizados en la sección Proyectos — ve Tus proyectos y sus documentos. El reporte final dice qué corrió, qué pasó, qué está bloqueado y a dónde va cada bloqueo, y lista cada pregunta que espera tu respuesta. No se hace push de nada.

Sigue por aquí