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.

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.

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.