Is CortexPilot a full SDK platform today?

No. CortexPilot already exposes a useful API and contract edge, but the public builder story is still a thin client plus generated contract package plus shared presentation substrate, not a full SDK platform.

Who should open the API quickstart first?

Teams should start here when their first question is about the HTTP contract, route/type boundaries, thin client helpers, or builder bootstrap rather than protocol-level MCP inspection.

Do guarded operator-only routes change the public builder promise?

No. Role-config preview/apply and queue preview/cancel remain guarded operator HTTP add-ons. They do not upgrade the public story into hosted mutation, public write-capable MCP, or a full SDK platform.

HTTP and package edge

API and contract quickstart.

CortexPilot is not a full SDK platform today, but it already exposes a useful API and contract edge for dashboard, desktop, and custom frontend consumers. This page is the shortest truthful map when your first question is about HTTP routes, type boundaries, thin client helpers, or builder bootstrap.

If your first question is instead about protocol-level inspection, read-only MCP, or how a coding-agent team should adopt the system truthfully, this page should route you to the better next click instead of making you reverse-engineer the package story from source.

Current package boundary: the package names referenced here are still private workspace packages. The truthful external adoption path today is clone-and-reuse or vendor-and-adapt, not registry install.

Open the builder path Open compatibility matrix Open MCP quickstart Open builder quickstart Open integration guide

Choose the shortest starting point

My first question	Start here	Why
I need the raw HTTP contract	This page	Stay here when your team needs OpenAPI, route/query boundaries, and the package edge first.
I need the protocol boundary first	Read-only MCP quickstart	Jump to MCP when the main question is machine-readable inspection rather than package import.
I need the best next click for Codex / Claude Code / OpenClaw / skills / builders	Compatibility matrix	Use it when the team still needs the adoption ladder answer before deeper onboarding.
I need repo-owned builder packages	Builder quickstart	Use it when you already know you want the workspace-local package layer rather than the protocol or proof-first story.

What builders can do today

OpenAPI

Machine-facing contract

Use the public OpenAPI document when you want the raw HTTP route contract before client or UI sugar.

Open OpenAPI document

Client

Thin frontend API helpers

Use @cortexpilot/frontend-api-client when you are working inside a clone, shared workspace, or vendored internal package path and want convenience helpers over runs, Workflow Cases, approvals, and command-tower reads.

Open client README

Contract

Generated type boundary

Use @cortexpilot/frontend-api-contract when you are inside the same repo or a vendored workspace copy and want route/query/type boundaries without importing backend modules.

Open contract guide

Shared substrate

Locale and presentation reuse

Use @cortexpilot/frontend-shared when you are reusing CortexPilot from a clone or vendored workspace and need shared copy, locale helpers, and status presentation across dashboard and desktop surfaces.

Open shared README

Repo-owned starter path

Teams that want the shortest repo-owned starter should begin with createControlPlaneStarter(...) on top of the client when they are working inside a clone or vendored workspace copy, because it bundles the current overview + agents + contracts + role config bootstrap path without implying a hosted SDK platform.

The repo-owned starter example shows the same bootstrap + preview path as runnable code instead of leaving builders to reconstruct it from prose alone.

node packages/frontend-api-client/examples/control_plane_starter.local.mjs \
  --base-url http://127.0.0.1:10000 \
  --role WORKER \
  --mutation-role TECH_LEAD \
  --preview-provider cliproxyapi \
  --preview-model gpt-5.4

Guarded operator-only add-ons

A few extra HTTP surfaces exist for trusted repo operators, but they are intentionally outside the default external builder promise.

/api/agents/roles/{role}/config/preview and /apply stay repo-owned role-default control-plane paths.
/api/queue/from-run/{run_id}/preview and /api/queue/{queue_id}/cancel stay queue-only operator routes for trusted maintainers.
These guarded routes do not upgrade the public story into hosted mutation, public write-capable MCP, or a full SDK platform.

Current boundary

Boundary

Builder edge, not full SDK

This is a useful builder edge today, but it is still not a full SDK platform.

Boundary

Read-oriented story

The public builder story is still read-oriented and repo-owned, not a hosted operator service.

Boundary

Guarded add-ons stay guarded

Role-config preview/apply and queue preview/cancel stay operator-only helpers, not the primary external onboarding promise.

Boundary

Private workspace packages

These package names are still private workspace packages. Until a real public publish exists, the truthful external path is clone/workspace reuse or vendor copy, not npm install.

Minimal onboarding order

Read the OpenAPI document if you need the raw HTTP contract.
Use the compatibility matrix if you need the best next click for Codex / Claude Code / OpenClaw / skills / builders before deeper onboarding.
Use the thin client package when you want convenience helpers over that contract.
Use contract-facing types when you want typed route/query boundaries without importing backend modules.
Pair the result with the builder quickstart so package-level adoption stays aligned with the current MCP/API story.