Prox Studio System

Position

Prox OS is an AI-native Web OS and workspace platform. Desktop Runtime is the primary runtime host for OS-grade app work, while a Studio is a workspace and composition product: a user can create, enter, configure, share, fork, and keep editing a personal or team workspace while AI helps assemble the first layout and each Studio Engine renders the same capabilities in a fit-for-purpose form.

The user-facing promise is simple:

Open Desktop Runtime for multi-window app work. Create a Studio when the work
needs a focused workspace, composition, or specialized creation surface.

The developer-facing model is explicit:

Desktop Runtime -> App Window lifecycle
Studio -> Studio Engine -> Studio Surface -> App projection

Core Terms

Users should see Desktop Runtime as the primary runtime and Studio language for workspace creation: Create Studio, Open Studio, Studio template, and Studio AI Entry. Developers may use Studio Engine, Studio Surface, Projection Contract, Command Provider, App Manifest, and Command Context.

Studio Engines

Studio Contracts And Packages

Studio language is now split across three package boundaries:

@prox-os/studio-contract must stay implementation-neutral: no React, no Shell state, no concrete engine package, and no backend persistence. The registry may depend on the contract and engine packages for metadata and command providers, but it does not own Shell runtime state. apps/os-shell owns routing, active Studio context, lazy component loading, window manager state, AI Control Plane glue, and Global Command Surface glue.

Block, Board, and Flow are extracted first because they own the heavy, engine-specific dependencies:

Desktop Runtime still leans on Shell runtime and layout state. Atlas, Grid, and Ops stay inside the Shell as the visible Studio set. Site, Webview, Device, Admin, IDE, App Studio, CLI, Block, Board, and Flow are local-only development engines reachable from /dev/studios/* in development builds, hidden from the public switcher and creation flows.

The Shell should lazy-load heavy engine components. /dev/studios/block, /dev/studios/board, and /dev/studios/flow are the current local-only routes that load their engine components; the Shell initial bundle should not statically import BlockNote, Excalidraw, or React Flow component trees.

AI Control Plane

The AI Control Plane is not one widget. It is a set of surfaces with different mental models:

These surfaces may share registries, but the UI contract stays separate:

Weather shows the distinction:

Navigation Split

The Shell now separates public landing navigation from runtime and Studio navigation:

This split keeps the homepage as a product and AI-builder entry, keeps the OS runtime as a long-lived shell, and lets each Studio preserve its local boundary.

Studio Surface Shell

StudioSurfaceShell is the shared bounded workspace container for heavy creative Studios. It provides the outer Studio workspace background, responsive padding, rounded frame, border, subtle shadow, and overflow boundary. The Studio Engine still owns 100% width and height inside that frame.

The shell applies this bounded surface to Ops Studio and to local-only development Studio routes under /dev/studios/*. Desktop Runtime uses the related runtime boundary because it is a primary host rather than a normal Studio card in the Studio list. Future focus or fullscreen modes can intentionally bypass or relax the frame when the user asks for full-bleed work.

Singleton App Window

Singleton App Window is a lightweight single-app floating surface available outside Desktop Runtime. It exists so small tasks can open anywhere while Desktop Runtime remains the strongest place to organize apps, windows, sessions, layouts, widgets, connectors, and permissions.

The current MVP allows one singleton app window at a time. It is draggable, closable, has shared app-window chrome, can be reset or maximized, and renders apps through the same AppRuntime used by normal shell windows. It does not copy app UI and it does not make every app singleton-window capable.

The shell registry annotates launch metadata through launchModes and defaultLaunchMode. Light apps such as Calculator, Currency Converter, Weather, DevUtils, Calendar, Pricing, AI Question Tracker, Subscription Tracker, and Market Watch can opt into globalWindow. Heavy Studio and hub work remains routed to Studio or normal OS surfaces.

All app-opening entry points should reuse the same launch action model:

Projection Contract

Apps and Studios can appear inside other engines, but v0 only supports projection, not unlimited recursive interactive nesting.

export const maxNestedInteractiveDepth = 1

export type ProjectionSurface =
  | 'full'
  | 'window'
  | 'widget'
  | 'block'
  | 'node'
  | 'card'
  | 'thumbnail'

export type ProjectionContract = {
  appId: string
  supportedSurfaces: ProjectionSurface[]
  maxInteractiveDepth?: number
  fallbackSurface: Extract<ProjectionSurface, 'card' | 'thumbnail'>
}

One Studio or App may appear inside another Studio as a card, widget, block, node, or thumbnail. v0 forbids a full interactive Studio inside another full interactive Studio when that nested Studio would continue nesting more interactive Studios. Past depth 1, the runtime should degrade to a card or thumbnail and expose an Open as Studio action.

The shared type home is @prox-os/studio-contract. Rendering glue still lives inside apps/os-shell; packages do not own shell state, Zustand stores, or backend persistence.

Global Command Surface

Cmd+K is a Shell-level surface, not a feature of Desktop Runtime or a Studio. The palette changes with active Studio context.

Each Studio Engine can expose command providers:

type CommandContext = {
  studioId?: string
  studioEngineId: StudioEngineId
  activeAppId?: string
  activeSurfaceId?: string
}

type CommandProvider = {
  id: string
  label: string
  getCommands: (context: CommandContext) => Command[]
}

Shortcut policy:

Routes

Current user-scoped routes:

/studio remains the AI Entry for creating or exploring Prox Studio. User-owned Studio resources use /@user/studios/:studioSlug. Runtimes use /@user/runtime/:runtimeSlug because Runtime is the repo-like object that can be named, cloned, published, and listed from a Universe page.

Block Studio

Block Studio v0 uses BlockNote because it is the fastest path to a Notion-like block editor with a default slash menu, drag handles, block nesting, and custom block direction.

Longer-term evaluation stays open:

The v0 choice is about architecture fit and product speed, not star counts.

Terminology Migration

Historical ideas are kept as design history, but the main product language is now Desktop Runtime plus Studio:

Classic OS window spaces remain implementation concepts inside Desktop Runtime and the window manager. User-facing switching is Runtime/Studio switching across resources and Scene switching inside the active runtime or Studio.