What is CC?

CommitCycle — written CC everywhere in the product — is change management for AI coding agents. It exists because agents got good at writing code before anyone decided what they were allowed to touch.

The model is three ideas, none of them exotic:

Zones

A zone is a set of path patterns with an owner, a risk level (high / medium / low) and a default policy (deny / read-only / open). Migrations are a zone. Shared contracts are a zone. Everything you don’t declare stays unprotected — which is the correct default for most of a repo. CC’s own guidance is to start with three zones, not thirty: an over-eager gate costs you more than a missing one, because a gate that blocks legitimate work gets uninstalled in week two.

Zones live in zones.yml, committed to the repo, reviewed like code.

The board

Work enters through a board with five fixed states — Triage, Todo, In Progress, In Review, Done (plus Canceled). The states are the data model, not a preference: they live in a database CHECK constraint precisely so there is nothing to add a row to.

A one-line request lands in Triage. Scoping it — filling the four-field task spec — moves it to Todo. The transition to In Progress is the main gate: it mints a time-boxed grant for exactly the zones the task declared, bound to a git branch. There is no command that opens a zone directly, so there is no back door to find.

Enforcement that is a boundary, not a request

An AGENTS.md file politely asks the agent to stay out of migrations/. Asking works right up until it doesn’t, and there is no log line where you can see that it didn’t. CC’s position is that anything enforced by prompt is advisory, so enforcement lives in three layers: context (advisory, and honestly labelled as such), a pre-tool-call hook that decides every call locally, and a required status check that re-runs the same decision against the pull request.

Worth being precise about, because it is the thing most easily overclaimed: in-flight denial is not what makes CC different. Several agent harnesses ship it, and the one you are most likely using includes it for free. What none of them has is the object being enforced — access scoped to a task you declared, bound to a branch, attributed to an owner who can be asked, and ending on a clock. The zone model is agent-agnostic; this layer needs one small adapter per harness, and today exactly one ships.

The hook never touches the network. Grants and events are local files first; the backend coordinates and mirrors. A flaky connection can’t stop your day, and a dropped backend can’t open a zone.

What CC deliberately is not

The spec carries an anti-features table, and it governs these docs too. CC never runs your code — it demands evidence and checks it. It does not host preview environments. It does not replace your tracker; intake is a form, an API endpoint and an MCP tool, so a webhook bridges whatever you use today.

And the MCP server, which has since landed, is a client of the same API rather than a second door — it is not the gate. No tool approves an access request, and none influences what the hook decides, because an agent chooses to call an MCP tool and enforcement has to be a capability boundary rather than a request. What a tool can do is ask the gate, and relay its refusal verbatim.

Where the numbers come from

Every measured claim in these docs traces to an audit record in the repository — the same records the product generates for its own development. Phase 0’s containment results, the fail-open finding, the hook’s latency budget: all of it is on the record, limits included, and the three layers page states what was not proven alongside what was.