O board de cinco estados Shipped

Cinco estados, e os dois que verificam alguma coisa

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.

Os cinco

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 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 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 (em inglês), o modelo contra o qual uma task declara é o mapa de zones, e o que ela deixa para trás é o registro.