--- title: "Un board donde In Progress es un grant, no una etiqueta" description: "Cinco estados y dos gates. El trabajo no puede empezar sin una spec y un impacto declarado, ni cerrarse sin un manifest y la evidencia que nombra." url: https://commitcycle.com/es/board/ language: es --- # Cinco estados, y los dos que comprueban algo > Cinco estados y dos gates. El trabajo no puede empezar sin una spec y un impacto declarado, ni cerrarse sin un manifest y la evidencia que nombra. El board de cinco estados Shipped 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. 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](https://commitcycle.com/es/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 --close` en la rama. - **Un agente puede preguntar al gate; ninguna herramienta puede decidir por él.** [Las herramientas MCP](https://commitcycle.com/es/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](https://commitcycle.com/docs/concepts/the-board/) (en inglés), el modelo contra el que declara una task es [el mapa de zones](https://commitcycle.com/es/zones/), y lo que deja detrás es [el registro](https://commitcycle.com/es/audit-record/). ## 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.