El board de cinco estados Shipped
Cinco estados, y los dos que comprueban algo
Los estados son los de Linear, a propósito — nadie necesita un vocabulario nuevo para el trabajo. Lo distinto es que dos de las transiciones son gates: una no deja que el trabajo empiece sin una spec, y otra no deja que se cierre sin evidencia.
✓ gate: four fields answered, no high-risk zone to approve
REQ-7 · schema · write · CC-42
Reason: the board query needs an index
Instead: hand the DDL to the owner
1 hour4 hoursUntil the task closes
✓ Approved — schema is open to CC-42 for 4 hours
En la consola una task cruza el gate hacia In Progress, y el owner de una zone responde a un access request — por una hora, cuatro, o hasta que la task se cierre.
Los cinco
| Estado | Qué significa aquí |
|---|---|
| Triage | Una línea, desde cualquier sitio. Una petición que no se ha acotado no es trabajo en curso |
| Todo | Aceptada como trabajo. Al entrar no se comprueba nada: los cuatro campos se comprueban en el gate hacia In Progress |
| In Progress | El primer gate. Existe un grant, atado a una task y a una rama, y caduca |
| In Review | Entregada. Las zones se cerraron en el mismo instante en que se movió el board |
| Done | El segundo gate. Un manifest, la evidencia que nombró el quality gate y un audit record |
Fuera de los cinco está Canceled: el trabajo se puede descartar desde cualquier estado anterior a In Review, y el gate pregunta por qué.
Una línea llegó a Triage 4,0 segundos después del clic — con el tecleo automatizado, medido una vez, el 2026-08-04, para una task. Capturar está pensado para ser barato; son los dos gates los que están pensados para costar algo.
La spec de una task: cuatro campos, fijados antes del gate
El primer gate se niega a abrirse sin ellos. Son los campos de un design doc, no una ceremonia inventada aquí.
- Goal — qué debe hacer, en una frase
- Non-goals — qué no debe hacer. Es el campo que evita la mayoría de los accidentes: nombra el cambio adyacente tentador antes de que nadie caiga en la tentación
- Affected zones — qué áreas protegidas necesita, que es también el access request
- Acceptance criteria — cómo sabrá cualquiera que funcionó. Se convierte en la checklist de la revisión
No hay ninguna checklist obligatoria más allá de estos cuatro, en ningún lugar del producto, y esa contención se defendió tres veces con datos.
El gate es una transición, no un comando
No existe open-zone. El acceso existe porque una task se movió, y está atado a la rama que esa task nombró. Eso importa más de lo que parece: en cuanto existe una segunda vía de entrada, se convierte en la que todo el mundo usa con prisa, y un gate con un comando para saltárselo es una sugerencia con pasos de más.
Cerrar tiene la misma forma, al revés. El segundo gate calcula un change manifest a partir de la rama — por el connector toma en su lugar la lista de ficheros que reporta el agente, y el audit record la marca como reportada; desde la consola o con un merge, toma el diff que registró la entrega o los archivos del pull request fusionado tal como los lista GitHub —, pide la evidencia que nombra el quality gate, y escribe el audit record al final, para que contenga todo lo demás.
Spike mode, para el trabajo que no debería sobrevivir
Explorar deja residuo: código que llegó a publicarse porque nadie decidió que no debía. Un spike tiene time-box y es desechable por defecto — se promueve deliberadamente o se descarta, en su propia rama: cycle start corta task/ como para cualquier task, y sólo un inicio desde la consola o el connector recibe una spike/. CommitCycle no crea tablas propias: cycle discard ejecuta el comando de limpieza de tu propio proyecto si configuraste uno, y lo dice cuando no lo has hecho.
La zone schema sigue cerrada durante todo el spike, diga lo que diga el grant. Es el único sitio donde un git revert no te puede salvar, y por eso es la zone que la configuración de governance siempre propone.
Dónde se detiene
- No es un tracker mejor. Linear y Jira son mejores boards. Si ya usas uno, el intake es un POST con un título, así que un puente que escribas tú puede registrar trabajo desde él; nada de aquí se sincroniza con él.
- La consola sólo cierra lo que puede comprobar. Cierra una task cuando GitHub ha confirmado que su pull request está fusionado y el board puede nombrar los archivos; si no, se niega y te remite a
cycle verify --closeen la rama. - Un agente puede preguntar al gate; ninguna herramienta puede decidir por él. Las herramientas MCP registran, acotan y — por el connector — piden una transición; el gate decide con las mismas reglas pregunte quien pregunte, y ninguna herramienta aprueba acceso.
Los estados y sus transiciones están en la documentación (en inglés), el modelo contra el que declara una task es el mapa de zones, y lo que deja detrás es el registro.
Preguntas que responde esta página
¿En qué se diferencia esto de Linear o Jira?
Los estados son los mismos a propósito — son el flujo por defecto de Linear, mapeado uno a uno. La diferencia está en lo que hace una transición: mover una task a In Progress emite un grant atado a esa task y a esa rama, así que In Progress es un permiso y no una etiqueta.