---
title: "Uma CLI que coloca um gate no trabalho dos agentes"
description: "cycle é a metade de terminal do CommitCycle: registra a task, passa o gate, emite o grant preso a um branch e escreve o registro no fechamento."
url: https://commitcycle.com/pt-br/cli/
language: pt-BR
---

# O gate, o grant e o fechamento, do seu terminal

> cycle é a metade de terminal do CommitCycle: registra a task, passa o gate, emite o grant preso a um branch e escreve o registro no fechamento.

CommitCycle CLI Shipped

Um comando leva uma task de uma frase até um branch com acesso anexado, e outro a traz de volta com um registro. O que fica no meio é trabalho comum, feito pelo agente que você preferir.

No terminal, o cycle faz cada passo com um comando: start traz o grant para a máquina, submit devolve.

## Instalação

```
npm i -g commitcycle
```

O pacote é `commitcycle` e o comando é `cycle`. Essa separação é deliberada: em qualquer máquina Unix `cc` já é o compilador C do sistema, então um `cc` global quebraria o `node-gyp` e todo Makefile que nunca sobrescreveu `$(CC)`. Uma ferramenta de governança que ofusca um compilador é uma que as pessoas desinstalam.

## O ciclo diário

```
cycle start "a coisa" \
  --goal "…" --non-goals "…" --criteria "…" \
  --topics backend,frontend        # intake → scope → branch → gate → grant → contexto
# ... trabalho ...
cycle submit                       # In Progress → In Review, zones fechadas
cycle verify --close --evidence <url>   # o manifest, os checks, o registro
```

Os quatro campos não são enfeite naquela primeira linha: o gate recusa uma task sem eles e a deixa em Todo, então um `start` escrito sem eles para antes de abrir qualquer coisa.

Toda porta para In Progress — `cycle start`, o botão Start do console, o `cc_start` do connector — é o mesmo gate. Não existe comando que abra uma zone por conta própria, e é justamente esse o ponto: assim que existe uma segunda porta, é ela que todo mundo usa com pressa.

## O que ele sabe fazer

| Comando              | O que faz                                                                                                                                                                                      |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `init`               | Prepara o repositório e escreve o contexto do agente — no modo memory por padrão (sem zones; toda edição precisa de uma task), ou com `--mode governance` para propor zones a partir do código |
| `start`              | Intake, scope, branch, gate, grant e contexto, numa única chamada                                                                                                                              |
| `status`             | Qual task está ativa, e exatamente o que está aberto para ela agora                                                                                                                            |
| `sync`               | Envia o mapa de zones e os eventos, traz o grant deste branch                                                                                                                                  |
| `request-access`     | Pede ao owner de uma zone que a abra — com um motivo e uma alternativa                                                                                                                         |
| `approve` · `deny`   | Responde do terminal a um pedido para uma zone da qual você é owner — de uma máquina pareada, só num board de um único membro. O console é a porta mais forte                                  |
| `submit` · `pause`   | Entrega o trabalho, ou o deixa de lado sem abandoná-lo                                                                                                                                         |
| `verify --close`     | Confere o branch contra o que a task declarou, e escreve o registro                                                                                                                            |
| `seed` · `challenge` | Redige playbooks a partir do código, e depois discute com eles                                                                                                                                 |
| `doctor`             | Por que o CommitCycle está se comportando assim?                                                                                                                                               |

Trinta e sete no `cycle --help`, na versão 0.1.25 (2026-10-12). A lista completa, flag a flag, está na [referência da CLI](https://commitcycle.com/docs/reference/cli/) (em inglês).

## Onde ele para

- **Não executa seus agentes.** O CommitCycle registra, coloca o gate e deixa o rastro; quem escreve o código é o que você já usa.
- **Não fecha passando por cima das checagens.** `verify --close` confere e registra; se faltar a evidência que o quality gate nomeia, ele recusa e diz qual.
- **O enforcement não mora na CLI.** Bloquear uma escrita enquanto ela acontece é trabalho do hook, e o hook chega com [o plugin do editor](https://commitcycle.com/pt-br/claude-code/). A CLI é o fluxo; o plugin é o muro.
- **`discard` não pergunta.** Ele tira um spike de volta para a base num único comando e relata a prova; `promote`, que mantém o que o spike encontrou, pergunta uma vez.

A referência de comandos está na [documentação](https://commitcycle.com/docs/reference/cli/) (em inglês), e o modelo sobre o qual ele age é [o mapa de zones](https://commitcycle.com/pt-br/zones/).

## Perguntas que esta página responde

### Por que o comando se chama cycle e não cc?

Em qualquer máquina Unix cc já é o compilador C do sistema. Um cc global quebraria o node-gyp e todo Makefile que nunca sobrescreveu $(CC), e uma ferramenta de governança que ofusca um compilador é uma ferramenta que as pessoas desinstalam. O pacote npm é commitcycle; o comando é cycle.