Estados de flujo

Un estado de flujo es cada situación por la que pasa una issue («Backlog», «In Progress», «Done»…). Cada equipo tiene su propio juego de estados, y todos nacen con los mismos seis.

Los seis estados

Al crear un workspace, cada equipo se monta con estos estados. Entre paréntesis, la categoría a la que pertenece cada uno:

Estado	Categoría	Qué significa
Backlog	backlog	Pendiente, sin priorizar.
Todo	unstarted	Priorizado, aún sin empezar.
In Progress	started	En curso.
In Review	started	Trabajo terminado, esperando revisión. Sigue contando como trabajo en curso hasta que se aprueba.
Done	completed	Hecho.
Canceled	canceled	Descartado.

Con estos seis nace cada equipo, pero no son una lista cerrada: el dueño del workspace o un administrador puede crear estados nuevos y renombrar los que ya existen, incluidos estos. Lo que no se puede es borrar estos seis, reordenar los estados ni cambiarles la categoría; lo tienes detallado en Cómo se usa.

Por qué importa la categoría

El nombre de un estado es una etiqueta; lo que gobierna la lógica de la aplicación es su categoría. Es lo que hace, por ejemplo, que «In Review» cuente como trabajo en curso sin necesidad de que nada conozca ese nombre en concreto:

• Tablero y listado: las issues se agrupan por estado y el indicador visual sale de la categoría.
• Métricas: la velocity y el burndown suman las issues en categoría completed; los Insights miden el trabajo en curso (started) y lo completado.
• Marcas de tiempo: al pasar una issue a un estado started, completed o canceled, la app registra automáticamente cuándo ocurrió.

Sobre esas marcas hay un detalle que conviene conocer: al reabrir una issue (volver a un estado en curso) se limpian las marcas de completado y cancelado, pero se conserva la fecha en que empezó. Así el cycle time de los Insights sigue midiendo desde el arranque real del trabajo y no desde la reapertura. Completado y cancelado son además excluyentes: una issue no puede estar hecha y cancelada a la vez.

Cómo se usa

En Ajustes → Estados ves los estados agrupados por equipo y ordenados por categoría. Los gestionan el dueño del workspace y los administradores; al resto de miembros esta sección no les aparece. Pueden:

• Crear un estado nuevo eligiendo nombre, categoría y color. El nombre tiene que ser único dentro del equipo, y el estado nuevo se coloca el último de su categoría.
• Renombrar cualquiera, incluidos los seis con los que nació el equipo.
• Cambiar el color.
• Borrar un estado que haya añadido a mano, siempre que nadie lo use: ni ninguna issue, de ningún proyecto, ni una automatización, ni una regla de SLA. Si algo lo usa, la app te dice qué.

Todo esto es configuración compartida: al tocarla, cambia para todo el equipo.

Lo que no se puede

• Borrar los seis estados con los que nació el equipo, ni uno añadido que esté en uso.
• Reordenar los estados: la posición la fija el momento de crearlos.
• Cambiar la categoría de un estado ya creado. La categoría se elige al crearlo y es la única decisión irreversible del formulario, porque es lo que decide cómo cuenta ese estado en las métricas (ver Por qué importa la categoría): cambiarla reescribiría el histórico, e issues cerradas hace meses pasarían a contar como trabajo en curso.

La categoría triage no se ofrece al crear.

Renombrar, en cambio, es seguro: la lógica va por categoría y no por nombre, y el estado en el que los agentes cierran una tarea (lo ves en el apartado siguiente) se guarda por su id, así que el cambio de nombre no lo rompe.

Al terminar una tarea

Debajo de la lista de estados está la opción «Al terminar una tarea, el agente la deja en: [selector]». Decide en qué estado deja un agente la issue cuando da su trabajo por acabado: si pasa por una revisión o si se cierra directamente.

El selector ofrece, con su nombre actual:

• Los estados de revisión: «In Review» y los estados started que hayas creado detrás de «In Progress».
• Los estados de completado: «Done» y los completed que hayas creado.

Quedan fuera «Backlog», «Todo», «In Progress» y «Canceled». Por defecto es «In Review». Como el resto de la página, la cambian el dueño del workspace y los administradores.

El agente se entera por el MCP: claim_issue, get_issue y next_ready_issue devuelven el campo agentCloseState, con el id del estado (stateId), su nombre (name) y la instrucción ya redactada (instruction). Si el agente deja la tarea en otro estado final, change_issue_state se lo dice en sus pasos siguientes.

Es una instrucción, no un bloqueo: un agente trabaja con la clave de una persona, y esa persona puede cerrar una tarea a mano en el estado que quiera.

Relacionado: Issues · Ciclos · Insights.