Adapters

An adapter takes a DevframeDefinition and deploys it into a specific runtime — a standalone CLI, a Vite plugin, a static snapshot, an embedded host, or an MCP server. Each adapter ships at its own entry point (devframe/adapters/<name>); the bundler pulls in only the ones you use.

Every adapter factory has the shape createXxx(devframeDef, options?).

Comparison

Adapter	Entry	Factory	Best for
cli	devframe/adapters/cli	createCli(def, options?)	Standalone tools run via node ./my-tool.js
dev	devframe/adapters/dev	createDevServer(def, options?)	Run the dev server programmatically — drive it from any CLI framework
build	devframe/adapters/build	createBuild(def, options?)	Offline reports, CI artifacts, deployable SPA snapshots
vite	@vitejs/devtools-kit/node	createPluginFromDevframe(def, options?)	Mount the definition into Vite DevTools (or any compatible host)
embedded	devframe/adapters/embedded	createEmbedded(def, { ctx })	Runtime registration into an already-running host
mcp	devframe/adapters/mcp	createMcpServer(def, options?)	Exposing a devframe to coding agents

Mount paths

A devframe's SPA basePath depends on which adapter is running it:

Adapter kind	Default basePath	Reason
cli, spa, build (standalone)	/	The devframe owns the origin.
vite, embedded (hosted)	/__<id>/	The devframe shares the origin with a host app and namespaces itself.

Override either side explicitly with DevframeDefinition.basePath:

defineDevframe({
  id: 'my-devframe',
  basePath: '/devframes/', // force this base regardless of adapter
  setup(ctx) { /* … */ },
})

SPA authors should build with relative asset paths (vite.base: './'); the client resolves its connection descriptor relative to the page at runtime. See Client for the discovery rules.