# Glossary


Use these definitions when a page, workflow status, agent handoff, or policy needs exact wording. In normal prompts, describe the outcome you want.

## Core names

**ZCP MCP** - Zerops Control Plane MCP: the MCP tool surface that exposes project-scoped Zerops operations to coding agents.

**MCP server** - the Model Context Protocol server exposed by the `zcp` binary.

**ZCP MCP tools** - the project-scoped Zerops operations exposed to an agent or MCP-capable client. In MCP clients, this usually appears as the `zerops` server.

**`zcp` binary** - the executable that can run inside remote setup or on your machine in local setup.

**`zcp` service** - the service instance in a Zerops project that hosts remote setup.

**`zcp@1` service** - the Zerops service type used for remote setup.

**zCLI** - the Zerops command-line client for humans, scripts, VPN, and CI. It is separate from ZCP MCP.

**zsc** - the in-container Zerops Setup Control utility used from `zerops.yaml`.

## Setup and workspace

**Remote setup** - the `zcp` binary running inside a Zerops `zcp@1` service.

**Include Coding Agent** - remote setup option that adds the bundled agent CLI, currently Claude Code, and preconfigures it to use ZCP MCP tools.

**Cloud IDE** - browser-based VS Code served by remote setup.

**Browser VS Code** - dashboard entry point into the Cloud IDE.

**AI Agent environment** - recipe environment preset that creates app services plus remote setup with **Include Coding Agent** enabled.

**Local setup** - the `zcp` binary running on your machine after `zcp init`, while your local editor or CLI agent talks to it.

**Env bridge** - local setup behavior that writes a local `.env` snapshot from Zerops env vars and references so local app code can reach managed services over VPN.

**Agent client** - the editor, CLI, hosted agent runtime, or custom MCP client that connects to ZCP MCP.

## Generated files and state

**Generated workflow block** - the managed section in `CLAUDE.md` between `<!-- ZCP:BEGIN -->` and `<!-- ZCP:END -->`. Durable project instructions belong outside it.

**`.mcp.json`** - local MCP server config. It points the local agent client at `zcp serve` and stores `ZCP_API_KEY`; keep it out of git.

**`.zcp/state/`** - local workflow metadata for a project directory: known runtimes, pairing, delivery choice, sessions, deploy attempts, verify attempts, and coordination locks. It is not source code.

**Workflow state** - saved metadata that lets the agent resume, audit, or close a guided run after interruption.

## Workflow

**Bootstrap** - workflow phase that reads the current project and settles which runtime services and managed services the app should use before app code work starts.

**Service setup** - the phase that decides which runtime services and managed services the app should use before app code work starts.

**Develop** - workflow phase that changes app code/config, deploys, verifies reachability and behavior, and fixes failures from evidence.

**Runtime target** - the app runtime selected for the current change, such as `appdev`, `appstage`, `app`, or a linked local target.

<span id="runtime-layout"></span>**Runtime layout** - which app runtime services the workflow should use:

- `standard` - dev runtime plus explicit stage runtime.
- `dev` - one mutable development runtime.
- `simple` - one runtime with no dev/stage split.
- `local-stage` - local source directory linked to one Zerops runtime as deploy target.
- `local-only` - local source directory with no linked runtime yet.

**Managed service** - database, cache, queue, search, storage, mail, or similar dependency. It provides connection details; it is not an app deploy target.

**Direct deploy** - deploy from the current source to the scoped runtime through ZCP MCP. The first verified running result uses direct deploy before delivery setup is applied.

**Reachability verification** - checks that the runtime exists, is running, has no recent blocking errors, and can answer an HTTP probe when it is an HTTP service.

**Behavior verification** - checks that the requested app behavior works on the real URL, endpoint, worker result, or stored state.

**Proof** - user-inspectable completion evidence, such as a URL, endpoint result, UI state, processed job, or stored result.

**Blocker** - a clear stop state with evidence: failure category, runtime in scope, what was tried, and what decision or credential is needed.

## Delivery and production

**Delivery choice** - what happens after a verified deploy: keep direct deploy, push to git, or hand off to CI/release/human process.

**Delivery mode** - exact reference label for delivery choice:

- `auto` - keep direct deploy for future changes.
- `git-push` - commit and push to a configured remote, then observe/verify any tracked build.
- `manual` - external CI, release process, or a human owns future delivery.

**Git-push capability** - whether remote setup has enough remote URL and credential setup to push from remote setup. It can exist even when the current delivery mode is `auto`.

**Build integration** - repository-triggered build/deploy path that ZCP MCP may configure or observe, such as a Zerops dashboard webhook or GitHub Actions. It is separate from git-push capability and delivery mode.

**Package a running service** - workflow that turns one verified runtime and its managed dependencies into a re-importable, git-backed Zerops bundle.

**Production release** - the release operation that moves verified dev or stage work into a separate production Zerops project. It is set up once per project (production infrastructure) and once per runtime (production deploy trigger), then runs every release.

**Production boundary** - policy that production should live in a separate Zerops project without a `zcp` service and receive promoted work through CI, release process, or human action.

## Platform and failure terms

**Service scaling mode** - Zerops scaling setting such as `HA` or `NON_HA`. Different from runtime layout.

**Public subdomain access** - Zerops `.zerops.app` URL access for an eligible HTTP runtime. Workers and non-HTTP services do not get useful public URLs.

<span id="failure-category"></span>**Failure category** - label that points to the first useful evidence surface:

- `build` - build phase failed.
- `start` - build passed, but runtime start or prepare failed.
- `verify` - runtime exists, but reachability or behavior failed.
- `network` - transport, DNS, VPN, SSH, or service-to-service reach failed.
- `config` - `zerops.yaml`, env vars, setup block, or service settings mismatch.
- `credential` - Zerops, git, SSH, managed-service, or external API credential failed.
- `other` - no known category matched.

**Confirmation gate** - an operation that pauses until the user explicitly confirms the named target or consequence.

**Destructive import override** - import action that would replace an existing service stack. ZCP MCP refuses first, names affected services, and requires a matching acknowledgement before proceeding.

## Credentials

**Single-project token** - Zerops token that can access exactly one project. ZCP MCP expects this shape.

**`ZCP_API_KEY`** - single-project Zerops token used by ZCP MCP.

**`GIT_TOKEN`** - git provider credential used by remote git-push delivery when needed.

**`ZEROPS_TOKEN`** - Zerops token commonly used by GitHub Actions or external CI that runs `zcli`.

**External secret** - third-party credential such as Stripe, OpenAI, Mailgun, or GitHub API access. The agent can wire placeholders and env vars, but the secret value remains your responsibility.