Core Concepts
The smallest useful mental model for understanding where code lives, where it runs, and what a session remembers.
Project → Workspace → Runtime → Session
Repository, integrations, environment settings, and history.
The concrete directory where an agent reads and edits code.
Cloud or paired local compute that runs tools and processes.
A task stays on the runtime where the session started.
Project and workspace are not the same thing
A Project is the durable product record in d1v: repository identity, integrations, environment configuration, deployment history, and runtime binding.
A Workspace is the concrete filesystem an agent works in. It may live in a managed cloud container or in a directory on a paired machine.
This separation lets the same project keep its product metadata while changing where future work executes.
Cloud and local runtimes
- A cloud runtime is managed compute provisioned by d1v.
- A local runtime is
opcode-apirunning on a paired device and connected through an outbound agent relay. - The browser talks to the d1v control plane. It does not connect directly to the developer machine.
If a project is bound to a local runtime and the device is offline, d1v returns an explicit local-runtime error. It does not silently run the task in cloud compute.
Sessions are pinned
Runtime changes apply to new sessions. A session that already started remains pinned to its original runtime so that tools, files, and process state do not move underneath an active task.
When testing a runtime switch, create a new session instead of expecting an existing conversation to migrate.
Preview and production
Preview is the verification surface for code, integrations, and secrets intended for development. Production is the promoted release that serves real users.
Keep credentials environment-specific. A preview that succeeds with test keys does not prove that production callbacks, webhooks, or live credentials are configured.