A Model-Independent Control Platform for a Browser DAW

The feat/model-independent-control-platform branch gives the DAW one control contract for project operations across the browser, CLI, MCP, and packaged desktop host. A model discovers the available operations from the same public catalog that typed clients and human-facing tools use.

The branch treats model independence as a protocol property. The workflow does not depend on a special mutation tool, a prompt written for one model, or a transport-specific copy of the project logic.

Four layers keep the contract stable

The control platform separates meaning from transport and storage.

• @daw-browser/control owns the versioned V1 and V2 schemas, serialization, digests, durable request metadata, limits, approvals, commits, history, recoveries, and keyed operation catalog.
• @daw-browser/control-core owns pure planning and projection behavior. It also handles MIDI resolution, deletion, and recovery semantics without transport or durable storage.
• @daw-browser/control-sdk exposes typed transport-neutral clients. It retains the legacy REST client and provides the sequential JSONL JSON-RPC adapter. Node consumers can create a canonical client or connect to the authenticated desktop host.
• Handlers, invokers, and clients own separate responsibilities. Handlers bind trusted target state. ControlInvoker binds a target and principal, validates one catalog operation, and dispatches it. Clients group typed calls without adding retries or transport policy.

The catalog defines the operation. Each adapter translates that operation into its own protocol.

versioned contracts + keyed operation catalog
                    │
            control-core semantics
                    │
           trusted handlers and invoker
                    │
   REST   desktop   CLI   MCP   sequential JSONL

Every client follows the same operation loop

The branch exposes a canonical workflow:

discover → canonical snapshot → preview → approval → commit → verify

Discovery returns the available capabilities and the authoritative project snapshot. A preview calculates the proposed change without mutating that snapshot. The commit includes the expected revision and an idempotency key. The caller then reads the new snapshot and verifies the result.

Revision checks prevent a stale client from overwriting a newer edit. Idempotency keys make a retry safe when the first request already committed. Approval tokens protect destructive operations and must match the request that uses them. History and recovery records make a committed deletion reversible.

The branch tested these rules through MCP, CLI, JSONL, the standalone TypeScript SDK, and the packaged desktop host. Each adapter reaches the same operation catalog.

Project control and host control stay separate

The project-control catalog supports cloud and desktop targets. project.current remains desktop-only because the packaged host can identify the mounted local project while a cloud client cannot make that claim.

Desktop host operations use a separate typed catalog in @daw-browser/desktop-protocol. It covers transport, diagnostics, VST discovery and parameters, import and export, and host status. Electron lifecycle, filesystem paths, capability tokens, and native internals stay in that host catalog. They do not become project-control operations.

REST routes and the desktop socket retain their V1 and V2 contracts. CLI and MCP expose thin adapters over the same canonical calls. An external Node consumer can use createCanonicalControlClient or connectDesktopControl without importing browser-only code.

The process boundary rejects bad input safely

The JSONL adapter accepts one bounded JSON-RPC 2.0 request per line and processes lines in order. Notifications execute without output. Batches, malformed requests, unknown methods, invalid parameters, unsupported targets, and oversized or deeply nested inputs return structured errors.

The decoder bounds UTF-8 input before parsing. When a line exceeds its limit, the process discards that line through its newline and continues with the next request. The CLI reaches the authenticated desktop host through rpc --target host. Host acquisition failures return a stable unavailable error without exposing registration paths, socket paths, or temporary-directory details.

Cloud JSONL remains deferred because the project does not have an equivalent secure process-authentication path for a cloud client.

Extensions receive narrow permissions

The branch manages trusted built-in extensions through an app-local kernel. The kernel publishes registries atomically, isolates diagnostics, aborts stale generations, and cleans up in reverse order. Replacement requires a matching contribution contract.

The extension system supports bounded native menu projection. It validates stable contribution IDs, titles, ordering, enabled state, and checked state across 16 first-level slots. Existing native menu commands remain compatibility commands instead of being regenerated by the extension system.

Project actions receive explicit action-kind and operation grants. The action facade exposes separate preview, approval, and commit methods. It does not expose raw stores or an arbitrary invoker. External manifests, package loading, DSP ABIs, evaluation, ambient store access, and extension preference persistence remain outside the branch.

Packaged acceptance tested the public path

The acceptance report exercised an unsigned Electron package on macOS arm64 with an isolated temporary profile. The packaged run covered desktop registration, private socket creation, project discovery, canonical V2 snapshots, immutable previews, approved commits, idempotent replay, revision conflicts, recovery, MCP and JSONL parity, transport, native menus, and the installed VST3 lifecycle.

Two protocol-naive models completed the same MCP task without protocol hints. Each model discovered the desktop project, selected the canonical V2 reads, built a persisted track reference, previewed the rename, committed it with an idempotency key, and verified the resulting revision. GPT-5.6 Sol and GPT-5.5 reached the workflow independently.

The final source and native checks recorded 160 control-platform tests, 40 compatibility tests, a passing production build, and 6 of 6 native CTest cases. Repository lint completed with zero warnings and zero errors. The full Bun suite still records 2,400 passing tests, 1 skipped test, and 10 known failures in the five-second exhaustive local-control threshold and stale MIDI-expression or automation expectations. The affected blocker tests pass in their focused suites. The correctness and security review reported no P0 or P1 findings.

Current limits

The branch leaves three product boundaries open:

• The packaged product has no extension lifecycle entry point, so extension lifecycle acceptance is marked PRODUCT SKIP.
• No disposable authenticated cloud environment was available, so cloud control acceptance is marked ENVIRONMENT SKIP.
• External extension packages, arbitrary DSP or package loading, public operation endpoints, extension preference persistence, cloud JSONL process authentication, external deployment, and installed-consumer parity remain deferred or unverified.

Those limits define the current control platform. The branch provides one versioned operation model and adapters for REST, desktop, CLI, MCP, and JSONL. It does not claim a public cloud process transport or an open extension runtime.

Read the control platform source and architecture notes or try the live DAW.