Give Claude Code a backend it can operate.

Start with korve init in the repository root. The command inspects the source, proposes a korve.toml manifest, and prints the infrastructure plan with its price before an apply. That order matters for an autonomous session: Claude Code can read the proposed runtime class, source ref, region, and declared data resources before it approves a billable change. A repository with no database declaration does not silently receive a database, and the same is true for storage, queues, cron jobs, and caches.

Keep the generated manifest in version control. It is the reviewable statement of what the application needs, not a cache of whatever happened in a dashboard. A later session can plan the same file, inspect the diff, and explain why a resource is being added or changed. If the detected shape is wrong, edit the declaration before applying it; do not accept a plan and try to repair the topology after provisioning.

korve login and the Claude Code MCP connection do not share one secret. The CLI opens a browser approval for its own grant, and the remote MCP server negotiates a separate OAuth grant on first use. Each approval names the organization, role, and operation scopes. That separation lets an owner revoke one integration without breaking the other, and it avoids placing a long-lived organization API key in a repository, shell transcript, or MCP configuration file.

Treat the approval screen as part of the change review. If the session only needs to inspect projects and deploy one application, do not approve organization-administration scopes. Sensitive mutations remain role-checked by the API even when the request comes from MCP. The agent interface is an additional way to call the platform contract; it is not a route around the contract's authentication or role requirements.

The native CLI is designed to be called by a person or a process. Use --json when a workflow needs stable fields, and branch on the documented exit status before parsing output. Exit 0 means the operation completed. Exit 3 means the session is not authenticated and should run the login flow rather than retrying the same request. Exit 5 means billing is not active for the organization; the correct next step is the hosted billing handoff, not another deploy attempt.

A failed operation should stop the loop unless the result names a recoverable next action. Destructive commands fail closed in unattended environments: pass --yes only after the intended target is explicit and reviewed. Interactive confirmation can ask for the project slug when a terminal is attached, but a background session gets no permissive default. That makes the CLI usable as a protocol without turning an absent prompt into authorization.

Every deployment has a durable record and build output. If a release fails, keep the deploy id from the result and run korve deploys diagnose <deploy-id>. The positional id is required. The platform agent reads that deployment's build output, logs, and project state, then returns a structured root cause and a proposed next step. It does not guess from the repository alone, and it does not diagnose whichever deployment happened to run most recently.

Apply the suggested change only after comparing it with the cited evidence. Then deploy again and retain the new id as a separate attempt. This produces a history a teammate can audit: the original failure, the evidence used in the diagnosis, the proposed remediation, the source change, and the replacement deployment. Reusing the same command without the id would break that chain and, in fact, exits with a usage error.

After the deployment reports ready, request the application URL and check an endpoint whose response proves the release can serve real work. Then read a bounded log window with korve logs --project <project> --limit 50. A successful build can still start an application with a missing environment variable, a failing database connection, or an unhealthy route. The HTTP check and log sample catch those runtime failures while the deploy context is still in the session.

Record the stable korve.app URL and the verification command in AGENTS.md so a future Claude Code session follows the same finish line. If the application has a custom health path, name it there rather than relying on a generic root request. Keep the log query bounded: the goal is to inspect the new release, not to pour an unbounded production stream into the context window.

A project budget alerts by default. Turn on its hard stop when the desired behavior is to refuse new deploys after month-to-date spend reaches the cap. Already-running workloads continue serving, and provisioning a database, bucket, or cache is not blocked by that budget. State those boundaries exactly in the repository instructions so Claude Code does not promise that every paid mutation is gated or assume that reaching a cap shuts down the live application.

Scale-to-zero applies to runtime compute. It idles to $0 and cold-starts on the next request, while declared databases, object storage, and other stateful resources retain their published meters. An always-on runtime continues running. That distinction belongs in design and cost reviews: removing traffic can eliminate runtime request cost, but it does not erase the data resources the manifest deliberately keeps available.