---
title: "Um board onde In Progress é um grant, não um rótulo"
description: "Cinco estados e dois gates. O trabalho não começa sem uma spec e um impacto declarado, nem fecha sem um manifest e a evidência que ele nomeia."
url: https://commitcycle.com/pt-br/board/
language: pt-BR
---

# Cinco estados, e os dois que verificam alguma coisa

> Cinco estados e dois gates. O trabalho não começa sem uma spec e um impacto declarado, nem fecha sem um manifest e a evidência que ele nomeia.

O board de cinco estados Shipped

Os estados são os do Linear, de propósito — ninguém precisa de um vocabulário novo para o trabalho. O que muda é que duas das transições são gates: uma não deixa o trabalho começar sem uma spec, e a outra não deixa que ele feche sem evidência.

No console uma task passa pelo gate para In Progress, e o owner de uma zone responde a um access request — por uma hora, quatro, ou até a task fechar.

## Os cinco

| Estado      | O que significa aqui                                                                                          |
| ----------- | ------------------------------------------------------------------------------------------------------------- |
| Triage      | Uma linha, de qualquer lugar. Um pedido que ainda não foi delimitado não é trabalho em andamento              |
| Todo        | Aceita como trabalho. Nada é verificado na entrada: os quatro campos são verificados no gate para In Progress |
| In Progress | **O primeiro gate.** Existe um grant, preso a uma task e a um branch, e ele expira                            |
| In Review   | Entregue. As zones fecharam no mesmo instante em que o board se moveu                                         |
| Done        | **O segundo gate.** Um manifest, a evidência que o quality gate nomeou e um audit record                      |

Fora dos cinco fica Canceled: o trabalho pode ser descartado de qualquer estado antes de In Review, e o gate pergunta por quê.

Uma linha chegou a Triage **4,0 segundos** depois do clique — com a digitação automatizada, medido uma vez, em 2026-08-04, para uma task. Capturar foi pensado para ser barato; são os dois gates que foram pensados para custar alguma coisa.

## A spec de uma task: quatro campos, definidos antes do gate

O primeiro gate se recusa a abrir sem eles. São os campos de um design doc, não uma cerimônia inventada aqui.

- **Goal** — o que ela deve fazer, numa frase
- **Non-goals** — o que ela não deve fazer. É o campo que evita a maioria dos acidentes: nomeia a mudança vizinha tentadora antes que alguém caia na tentação
- **Affected zones** — de quais áreas protegidas ela precisa, o que também é o access request
- **Acceptance criteria** — como qualquer pessoa vai saber que funcionou. Vira o checklist da revisão

Não existe nenhum checklist obrigatório além desses quatro, em lugar nenhum do produto, e essa contenção foi defendida três vezes com dados.

## O gate é uma transição, não um comando

Não existe `open-zone`. O acesso existe porque uma task se moveu, e ele fica preso ao branch que essa task nomeou. Isso importa mais do que parece: **no momento em que existe uma segunda porta, ela vira a que todo mundo usa com pressa**, e um gate com um comando para contorná-lo é uma sugestão com passos extras.

Fechar tem a mesma forma, ao contrário. O segundo gate calcula um change manifest a partir do branch — pelo connector ele usa no lugar a lista de arquivos que o agente reporta, e o audit record a marca como reportada; pelo console ou num merge, ele usa o diff que a entrega registrou ou os arquivos do pull request mergeado como o GitHub os lista —, pede a evidência que o quality gate nomeia, e escreve [o audit record](https://commitcycle.com/pt-br/audit-record/) por último, para que ele contenha todo o resto.

## Spike mode, para o trabalho que não deveria sobreviver

Explorar deixa resíduo: código que chegou a ser publicado porque ninguém decidiu que não deveria. Um spike tem time-box e é **descartável por padrão** — promovido de propósito ou descartado, no seu próprio branch: `cycle start` cria `task/` como para qualquer task, e só um início pelo console ou pelo connector recebe um `spike/`. O CommitCycle não cria tabelas próprias: `cycle discard` roda o comando de limpeza do seu próprio projeto se você configurou um, e avisa quando não configurou.

A zone schema continua fechada durante todo o spike, diga o grant o que disser. É o único lugar onde um `git revert` não consegue te salvar, e por isso é a zone que a configuração de governance sempre propõe.

## Onde ele para

- **Não é um tracker melhor.** O Linear e o Jira são boards melhores. Se você já usa um, o intake é um POST com um título, então uma ponte que você escreva pode registrar trabalho a partir dele; nada aqui sincroniza com ele.
- **O console só fecha o que consegue verificar.** Ele fecha uma task quando o GitHub confirmou o merge do pull request dela e o board consegue nomear os arquivos; caso contrário, recusa e aponta para `cycle verify --close` no branch.
- **Um agente pode perguntar ao gate; nenhuma ferramenta decide por ele.** [As ferramentas MCP](https://commitcycle.com/pt-br/mcp/) registram, delimitam e — pelo connector — pedem uma transição; o gate decide pelas mesmas regras seja quem for que pergunte, e nenhuma ferramenta aprova acesso.

Os estados e suas transições estão na [documentação](https://commitcycle.com/docs/concepts/the-board/) (em inglês), o modelo contra o qual uma task declara é [o mapa de zones](https://commitcycle.com/pt-br/zones/), e o que ela deixa para trás é [o registro](https://commitcycle.com/pt-br/audit-record/).

## Perguntas que esta página responde

### Qual é a diferença disto para o Linear ou o Jira?

Os estados são os mesmos de propósito — são o fluxo padrão do Linear, mapeado um para um. A diferença está no que uma transição faz: mover uma task para In Progress emite um grant preso àquela task e àquele branch, então In Progress é uma permissão, e não um rótulo.