--- title: "Glossary: CommitCycle terms and their sources | CommitCycle" description: "The terms CommitCycle uses, what each means here, and the tool or standard its name was taken from." url: https://commitcycle.com/docs/reference/glossary/ language: en --- # Glossary > The terms CommitCycle uses, what each means here, and the tool or standard its name was taken from. CommitCycle has one naming rule: **every label in the product is a term the market already uses**, checked against real tools rather than invented here. The project keeps a single naming authority for code, UI, docs and the CLI, and a new term gets its market grounding written down there before it ships anywhere. This page is that vocabulary for the people who use CC: what each word means here, and the tool or standard it came from. Borrowing a word is not borrowing every sense of it. Where the market uses a term in more than one way — _playbook_ is the clearest case — the entry says which sense CC means. Where the market had no word, the entry says that too. An entry here fixes what a thing is called. It is not a statement that the thing ships today: what exists is what the concept and operations pages describe. ## Workflow states A CC task moves through Linear’s default workflow, mapped one to one — the strongest market grounding available. | Term | Meaning in CC | Grounded in | | --------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------- | | **Triage** | Intake: a request nobody has scoped yet | Linear’s default intake state | | **Todo** | Scoped and accepted, not started | Linear’s default | | **In Progress** | Past the main gate, which is what issues the grant | Linear, Jira, GitHub Projects | | **In Review** | Handed in; the quality gate decides | Linear, Jira | | **Done** | Closed through the quality gate, with an audit record. Closing is not merging, and either can happen first | universal | | **Canceled** | Deliberately not done — a different outcome from Done | Linear’s default | Two of the transitions are gates, and they keep those names: **Todo → In Progress is the main gate**, and **In Review → Done is the quality gate**. [The board and its two gates](https://commitcycle.com/docs/concepts/the-board/) says what each one checks. ## Zones A zone is CC’s unit of protection: path patterns, an owner, a risk level and a default policy. | Term | Meaning in CC | Grounded in | | --------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | **zone** | A protected area of the codebase | “security zone” in network segmentation; its functional analog is a GitHub ruleset that restricts file paths | | **`zones.yml`** | The file in `.zones/` that declares the zones | none — it is a file name | | **code owner** | The person who answers for a zone | GitHub and GitLab CODEOWNERS | | **path patterns** | A zone’s boundaries, written as glob patterns | GitHub rulesets | | **risk level** | `high`, `medium` or `low` | standard risk-assessment vocabulary | | **default policy** | `deny`, `read-only` or `open` — whether a zone can be read without asking. Writing into any zone takes a grant | a firewall’s default-deny; a read-only filesystem | | **unprotected paths** | Paths no zone covers | GitHub: paths no ruleset covers | | **`schema` zone** | The system zone for the database schema, always written by a governance-mode `cycle init` | plain database vocabulary | [Zones](https://commitcycle.com/docs/concepts/zones/) covers how they are drawn and why most of a repository stays unprotected. ## Tasks Work on a CC board is a task, scoped with four fields before anything starts. | Term | Meaning in CC | Grounded in | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | **task** | The unit of work on the board. CC says task, never ticket | universal — Linear and GitHub call them issues; Things and Todoist call them tasks | | **task spec** | The four fields below, which scope a task | the PRD and design-doc convention | | **Goal** | What the task does | the design-doc template | | **Non-goals** | What the task must not do | the Google and RFC design-doc template term | | **Affected zones** | The zones the task touches | change management’s “impacted systems” or “impacted areas” | | **Acceptance criteria** | How you know it worked | agile standard | | **priority** | `urgent`, `high`, `medium`, `low` or `none` | Linear’s priority scale; Jira’s priority field | | **auto-triage** | At intake, a drafted spec, zone proposal and suggested priority — always offered as choices. The board drafts by rules when no model is configured, and says so on the draft | Linear Triage Intelligence; issue-triage bots in the GitHub ecosystem | | **user story** | A task whose Goal speaks in the user’s voice | Scrum and XP standard | [The task spec](https://commitcycle.com/docs/concepts/task-spec/) shows how the gate holds work to the four fields. ## Access Most of CC’s access vocabulary comes from privileged-access management (PAM), applied to an agent working one task. | Term | Meaning in CC | Grounded in | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **grant** | Time-bound access to zones | OAuth grants; PAM’s time-bound access | | **access request** | Asking for a zone the task never declared | “Access Requests” in Teleport, Okta and Azure PIM | | **just-in-time (JIT) access** | Access that expires on its own | PAM: Azure PIM, Teleport, Okta | | **renew** | Re-issuing a grant for another TTL without widening it: the same zones, the same modes, the same branch, a later deadline. Never called _extend_. A renewal is bounded by the approvals the gate already checked, and a high-risk zone whose approval has lapsed ends it | HashiCorp Vault’s lease renewal (`vault lease renew` extends the TTL, never the policy), Kerberos renewable tickets, ACME and certbot’s `renew`, AWS STS credential renewal — each re-issues the same authority and cannot grant more of it | [Grants & access requests](https://commitcycle.com/docs/concepts/grants/) covers the lifecycle. ## Closing and the record A CC task closes through the quality gate, and the words for what a close leaves behind come from audit and compliance. | Term | Meaning in CC | Grounded in | | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | **quality gate** | The per-task set of checks that decides In Review → Done | SonarQube’s “quality gate” | | `none` · **visual review** · **API contract check** · **regression suite** · **QA sign-off** | The quality gates a task can carry | for the last four, in order: code review, Pact contract testing, CI, release sign-off | | **change manifest** | What a task actually changed, computed rather than claimed | build and artifact manifests | | **audit trail** | The record of what happened, task by task | universal compliance vocabulary | | **audit record** | One task’s entry in the audit trail, kept by the board. `cycle verify --close` also writes it to `.zones/audit/` unless the records live on the board, and `cc_close` hands it back as a file to commit; a close in the console or on merge leaves it on the board only | universal compliance vocabulary | | **evidence** | A URL or an attached capture, where a quality gate asks for one | audit vocabulary | | **logged exception** | An exception recorded with an owner, rather than silently accepted | audit vocabulary | | **bypass** | Lowering the rigor — recorded, with an owner | GitHub rulesets’ “bypass” | [The closing gate](https://commitcycle.com/docs/operations/closing-gate/) and [the audit record](https://commitcycle.com/docs/operations/audit-record/) cover both halves. ## Playbooks and topics In Devin a playbook is a reusable task prompt; in incident response and Ansible it is a step-by-step procedure. In CC it is neither: a playbook is an evolving knowledge file, per topic and per project. If you arrive expecting a macro, this is not one. | Term | Meaning in CC | Grounded in | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **playbook** | Per-topic, per-project agent context: seeded by the first audit, fed at close | incident-response playbooks (PagerDuty, SANS); Ansible playbooks; sales playbooks; Devin Playbooks | | **`topics[]`** | The disciplines a task needs — plural, like Affected zones. Proposed at scoping, they load the playbooks, suggest the quality gate and warn on coherence at close | GitHub repository topics; Linear labels; Scrum’s “Definition of Done”, the mandatory form CC refused | | **release management** | The discipline of planning and shipping releases | the ITIL practice | | **evolving playbook** | A playbook that accumulates cited learnings through the seed → load → feed loop | ACE, _Agentic Context Engineering_ (arXiv 2510.04618): “contexts as evolving playbooks”. Its failure modes, context collapse and brevity bias, are what the append-only rule guards against | | **task-declared loading** | The task’s `topics[]` decide, deterministically, what the agent reads | the four rule activation modes Windsurf/Cascade ship — always-on, glob, model-decision, manual — do not include it; Agent Skills trigger on a probabilistic description match | | **always-on playbook** | A playbook that loads for every task, whatever it declares. It is pointed at from the hand-written half of `AGENTS.md` instead of by `topics[]`, and it is not a declarable topic, so it never enters the topic taxonomy | Windsurf/Cascade’s `always_on` activation mode; Cursor’s “Always” rule type | | **generated view** | A compiled, do-not-edit projection of a playbook — read-only by convention and regeneration, not by enforcement | GitHub Linguist’s `linguist-generated` attribute; the generated-code convention | | **archived** | A playbook’s end state: it stops loading and compiling, and keeps its git history | GitHub archived repositories — read-only, kept, left out of active surfaces | | **challenger** | The adversarial pass at seed time: it proposes best practices the repository lacks, as choices. An accepted proposal becomes a decision; a rejected one is recorded as refused knowingly | champion–challenger (FICO decision management; MLOps champion/challenger deployment); adjacent to red teams in security and critics in agent design | | **decision file** | `.zones/decisions/NNNN-slug.md`, ADR-style. Accepted and rejected decisions are both recorded — a rejection with the person’s grounds — and playbooks cite these files | Architecture Decision Records: adr-tools’ `NNNN-title.md` numbering; the MADR template | ## Exploration Exploration in CC is a spike: time-boxed, and disposable by default. | Term | Meaning in CC | Grounded in | | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | **spike** (spike mode) | Time-boxed, disposable exploration | XP and Scrum | | **`spike/` branch prefix** | The prefix the gate gives a spike’s branch when its start names none — from the console or the connector. `cycle start` cuts `task/-` for a spike too | XP vocabulary | | **time-box** | 7 days, with a warning from day 5 | the agile time-boxed spike | | **sandbox tables** | Tables made while exploring, prefixed `spike__` so they can be dropped together | “sandbox”, the standard isolation term | | **draft endpoints** | Provisional endpoints made while exploring | GitHub’s draft pull request semantics | | **promote** | Keeping what a spike earned | deployment promotion, from canary to production | | **discard** | Throwing a spike away | git’s and VS Code’s “discard changes” | | **dead code / orphaned resources** | The residue exploration must not leave behind | cloud and static-analysis vocabulary | | **zone drift** | The zone map falling out of step with the code it protects — named now, scoped for a later version | configuration and infrastructure drift | [Spike mode](https://commitcycle.com/docs/concepts/spike-mode/) covers the time-box and what a discard proves. ## Enforcement CC enforces in [three layers](https://commitcycle.com/docs/concepts/three-layers/), and only two of them block anything. | Term | Meaning in CC | Grounded in | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ | | **Layer 1 — context** | `AGENTS.md` and `CLAUDE.local.md`, and the plugin’s context hooks: the rules and the history, in words the agent reads. Advisory | the agents.md convention | | **Layer 2 — policy enforcement** | The `PreToolUse` hook, which answers a tool call with a `permissionDecision` of deny or ask, or with no decision, leaving it to the editor’s own permission settings. It never answers allow (CC-1142) | Claude Code’s own hook vocabulary; the “policy enforcement point” of security architecture | | **Layer 3 — status check** | A check on the pull request that compares its diff with what the task declared. The merge waits for it only where branch protection requires it | GitHub status checks and branch protection | | **allowlist** | A list of what is permitted | industry standard | | **default-deny** / **fail-closed** | No answer means no. In CC, `closed` is one choice of failure policy; the default is `open` (CC-1143) | security standards | | **denied call** / **block** | A tool call that was refused | Claude Code’s “deny” | | **least privilege** | Only what the task declared | the security principle | | **blast radius** | What else breaks when this does | SRE and security vocabulary | | **human-in-the-loop (HITL) approval** | A person decides, and their name is on the decision | AI-agent market standard | ## Commands The CC command line is `cycle`, and each command’s name comes from vocabulary the market already uses. What the commands do is in the [CLI reference](https://commitcycle.com/docs/reference/cli/). | Command | Named after | | ---------------------- | -------------------------------------------------------- | | `cycle init` | the git and npm convention | | `cycle sync` | standard | | `cycle status` | `git status` | | `cycle request-access` | Teleport’s `tsh request create`; PAM’s “access request” | | `cycle discard` | git vocabulary | | `cycle promote` | deployment vocabulary | | `cycle submit` | “submit for review”, from Gerrit’s changelist vocabulary | | `cycle verify` | standard | | `cycle doctor` | `brew doctor`, `flutter doctor` | ## Accounts and plans These words name CC’s account model. They are names, not a price list — nothing here says what is sold, or when. | Term | Meaning in CC | Grounded in | | ----------------------------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | **organization** (“org”) | The paying company, as the product shows it | GitHub organizations; Stripe’s “customer” | | **member** | A person in an organization | GitHub and Linear organization members | | **seat** | A billable member | per-seat pricing at GitHub, Linear and Slack | | **GitHub App** | The repository integration | GitHub’s platform term | | **free tier** / **paid plan** | Using CC without paying, and paying for it | SaaS standard — GitHub Free, Linear Free | | **Solo mode** | CC for one person | product-led growth’s “single-player mode”; Docker Personal, Tailscale Personal, JetBrains’ personal license | | **Team plan** | The plan for a team | GitHub Team; Slack’s and Linear’s per-seat plans | | **entitlement** | What a plan unlocks | licensing and billing standard | [Accounts](https://commitcycle.com/docs/operations/accounts/) covers signing in. ## Openness levels These words belong to CC’s openness dial, specified in CC-563: a graded dial from `L0` (open) to `L4` (sealed), built on the rule that restriction and verification are two axes, not one. Not every word below names a setting you can change today. | Term | Meaning in CC | Grounded in | | ------------------ | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | **openness level** | A step on the dial, `L0` (open) to `L4` (sealed) | SLSA’s numbered ladder of assurance levels; Terraform Sentinel’s enforcement levels (advisory, soft-mandatory, hard-mandatory) | | **restriction** | One axis: what the agent may do | GitHub rulesets’ “restrict updates” and “restrict pushes”; branch protection | | **verification** | The other axis: what someone else can check | SLSA’s artifact and provenance verification; `sigstore verify` | | **policy atom** | One capability that can be denied on its own: `pr.open`, `pr.merge`, `pr.automerge`, `trunk-push` | coined here (CC-562) — the market concept is fine-grained permissions, as in GitHub’s fine-grained tokens (“Pull requests: read/write”), and OAuth scopes | | **preset** | A level applied to the atoms: a starting configuration, overridable atom by atom | Babel and ESLint presets | | **pinned** | An atom the owner set by hand, which a preset change leaves alone | dependency pinning — a pinned npm or pip version | | **scan** | The computation onboarding runs over a repository | GitHub code scanning; `npm audit`; Snyk and Trivy | ## Coordination reads For someone coordinating many CC agents across many checkouts, the whole-board read carries one marker of its own. | Term | Meaning in CC | Grounded in | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **`queried_at`** | The moment a whole-board `cc_status` read was taken, stamped beside its scope label — so a consumer can compute how old its picture is (`now − queried_at`), and two coordinators can tell whose read is newer | Kubernetes stamps a `resourceVersion` on every list, and etcd returns a `revision` on every range read, for the same reason. Those are state versions, and CC does not mint one, so this marker is a query time: the HTTP `Date` header (RFC 9110 §6.6.1) that RFC 9111’s age model computes staleness from. Its name says what it holds | ## The product’s own names **CommitCycle** is the product, and its interface writes it **CC** (D-07). **The command is `cycle`**, shipped as the npm package `commitcycle` (D-51). It is not `cc` because that name already belongs to the system C compiler on every developer machine, and a governance tool must never shadow a compiler: a global `cc` would break `node-gyp` and every Makefile that never overrode `$(CC)`. Unchanged by the rename: the npm workspace scope `@commitcycle/*`, MCP tool names such as `cc_start` and `cc_status`, environment variables such as `CC_TOKEN` and `CC_API_URL`, task ids (`CC-n`), and file names like `cc-hook.sh`. ## Sources - [Linear — issue statuses and workflows](https://linear.app/docs/configuring-workflows) - [GitHub — available rules for rulesets (restrict file paths)](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets) · [push rules are generally available](https://github.blog/changelog/2024-09-10-push-rules-are-now-generally-available-and-updates-to-custom-properties/) - [Teleport — just-in-time Access Requests](https://goteleport.com/docs/identity-governance/access-requests/) · [Azure PIM deployment plan](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-deployment-plan) · [Okta and AWS IAM Identity Center — JIT privileged access](https://www.okta.com/blog/2023/06/okta-and-aws-identity-center-enforce-jit-privileged-access/) - [Claude Code — configure permissions](https://code.claude.com/docs/en/permissions) - [Agent Skills — specification](https://agentskills.io/specification) - [ACE — Agentic Context Engineering](https://arxiv.org/abs/2510.04618) - [GitHub — archiving repositories](https://docs.github.com/en/repositories/archiving-a-github-repository) · GitHub Linguist’s `linguist-generated` - FICO decision management — champion/challenger testing - [SLSA — security levels](https://slsa.dev/spec/v1.0/levels) · [Terraform Sentinel — enforcement levels](https://developer.hashicorp.com/sentinel/docs/concepts/enforcement-levels) - [GitHub — about code scanning](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning) · [fine-grained personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)