Studio Convergence

From Desktop Shell To Studio Platform

Prox OS began as a browser desktop shell: windows, app icons, folders, dock, settings, route-aware windows, and a playful operating environment in the browser.

That was useful, but the product language started to outgrow one desktop. AI Rail introduced a second layer: an ambient companion that could observe the workspace, explain what it saw, suggest actions, and keep permission prompts visible without becoming a normal app window.

Then more surfaces appeared: block documents, node graphs, whiteboards, dashboards, focus modes, community spaces, public pages, iframe tools, and mobile previews. The single Desktop mental model stopped being enough. It made every surface feel like a variant of one shell instead of a first-class workspace shape.

The convergence point is Studio.

Why Studio

Studio is the resource the user owns. It can have an owner, title, slug, visibility, engine, apps, datasets, permissions, layout, theme, and AI context. It can be saved, copied, forked, shared, turned into a template, and rendered by different Studio Engines.

This is not a copy of Hugging Face Spaces. The similarity is the resource shape: owner-owned, rich UI, community-visible, dataset-aware, app-capable, and AI-context-aware. The Prox OS direction is broader: a Web OS runtime where apps, connectors, datasets, permissions, and AI guidance mount into Studios.

Studio is the smallest meaningful workspace resource in Prox OS. Earlier iterations treated the App as the center, but an App alone does not carry owner identity, data boundaries, permissions, AI context, presentation state, or shareability. Then the Desktop felt like the center, but Desktop language pulled every experience back toward macOS and Windows. Studio keeps the useful parts of a workspace while leaving room for documents, dashboards, sites, mobile previews, admin tools, app-centered workspaces, and future engines.

A Studio can organize:

• Apps.
• Datasets.
• Docs.
• AI tools and AI capabilities.
• Connectors.
• Permissions.
• Scenes.
• Layouts.
• Owner identity.
• Public, private, and shared state.

This matters because Prox OS has more generated code to govern, more app UI to organize, more documentation that AI agents need to read, more data sources to connect later, and a stronger need to present the project as a living platform rather than a normal website. The convergence sentence is:

Prox OS turns apps, datasets, docs, and AI tools into user-owned Studios that individuals and small teams can use, operate, and share as AI-native workspaces.

Data Sovereignty

Data sovereignty in Prox OS means user-owned resources, explicit dataset mounting, permissioned connectors, and AI-readable but scoped capabilities.

The owner owns the Studio. The owner owns Library entries. The owner owns or mounts Datasets. Connectors are permissioned pipes, not the source of product identity. Apps are capabilities, not the owner of all user data. A Studio can mount datasets without letting every App copy or own the data. Alma and runtime AI tools must operate through explicit capability, dataset, connector, and permission boundaries.

This is why Dataset becomes a first-class resource instead of a hidden page inside one App. It is also why Settings and Library manage connectors, installed assets, and permissions while Studios remain the main place where work happens.

Application Ecosystem

Prox OS is not just a Desktop that launches Apps. Apps can enter the platform as Local Apps, Route Apps, Frame Apps, Proxied Apps, or future Remote Apps. Microfrontend capability is useful only when it supports those adapter boundaries without forcing every App into one shell implementation.

The ecosystem layers are:

• App Store: public discovery, listing, installation, and Studio creation entry.
• Library: the user's installed asset inventory.
• Studio: the user-owned workspace context where Apps, Datasets, permissions, and AI context come together.
• Published App: an owner-published app definition such as @prox-os/apps/hola.

One App can power multiple Studios because a Studio is a context instance, not a copy of the App. Prox OS should grow an application ecosystem through clear app contracts, curated discovery, user-owned installations, and Studio-based usage contexts.

Alma After Convergence

Alma should no longer be described as supervising one Desktop. It is part of the AI Control Plane across Studios. It observes the current Studio context, summarizes app and dataset boundaries, proposes reviewable action cards, and hands explicit intent to Cmd+K or user-confirmed actions.

The product shift is:

Desktop-first app playground
-> Runtime-first AI-native workspace platform

Desktop Runtime remains valuable. It is simply one Studio Engine among several.