The dashboard, CLI, Management API, and MCP use the same organization-scoped resource model. The dashboard adds human review and approval. The API and MCP are designed for bounded automation and agent work.

Start with inventory, confirm the active organization and capabilities, make one exact change, then read state again. Do not infer live state from a successful request alone.

Dashboard: inspect the canvas, review proposals, manage credentials, and make human-only decisions.
CLI: use the checked-out beta client for scriptable JSON output during the current beta.
API: call the HTTPS Management API with a scoped, expiring developer credential.
MCP: let compatible agents discover bounded tools and operate with the same tenant and approval boundaries.

The connected project lifecycle

Read inventory and identify the active organization.
Connect or verify the customer-owned domain without changing public traffic.
Create a private repository and a bounded build pipeline.
Build an immutable draft and inspect its private preview.
Propose Compute and data resources, then wait for the required human approval.
Publish only the exact reviewed artifact to the exact customer domain.
Verify the live release, usage, dependencies, and recovery evidence.
Keep a known-good retained release and test rollback and restore without using customer production data as a fixture.

Understand the evidence

Requested means a request was accepted, not that provider work completed.
Proposed means a human decision is still required.
Provisioning and deploying are nonterminal states; poll with bounded backoff.
Ready describes recorded service state. It is not proof of application health unless the response includes that evidence.
Uncertain and recovery required are stop states. Reconcile them before retrying.
A dashboard card, API record, provider deployment, and public response are separate evidence.