Prox OS Internal Docs
PlatformArchitectureRepo

Package Taxonomy

Prox OS uses package names to describe product domains and directory layers to

Prox OS uses package names to describe product domains and directory layers to describe runtime and ownership boundaries. Package names stay stable, for example @prox-os/forms or @prox-os/app-contract; their filesystem location shows whether the package is UI, feature, contract, runtime, data, backend, devtooling, or an app package.

This avoids prefixes such as fe- and be-. A package named @prox-os/files should stay domain-readable even if its implementation later gains a backend adapter package. The directory, Nx tags, proxos metadata, and dependency-cruiser rules carry the runtime boundary.

Layers

LayerDirectoryResponsibilityMay depend onMust not depend on
UIpackages/ui/*Reusable browser UI primitives and interaction contracts.contracts, safe UI peers, design tokens, documented browser-safe feature adapters.backend, server data packages, provider SDKs, shell internals.
Featurespackages/features/*Browser-safe feature packages such as files, search, AI UI, workspace UI, maps, media, tables, and charts.ui, contracts, other browser-safe features when documented.backend, DB clients, runtime shell internals.
Contractspackages/contracts/*Shared serializable types, manifests, schemas, API/event contracts.Minimal external type utilities.ui, features, runtime, backend, browser-only or server-only implementation.
Runtimepackages/runtime/*OS runtime registries, app/window/workspace runtime helpers, and manifest resolution.contracts, selected ui types when safe.backend by default, feature implementation unless explicitly documented.
Studio Enginespackages/studio-engines/*Browser Studio Engine implementations with renderer-specific dependencies.contracts, command types, browser-safe UI, engine-owned deps.Shell internals, backend, user Studio instances.
Datapackages/data/*Data schemas, query clients, fixtures, mock data, and DB-facing packages.contracts, backend-safe utilities.Browser packages when the package contains server-only clients.
Backendpackages/backend/*Server-only packages such as auth, billing, storage, audit, moderation, AI adapters, and worker shared code.contracts, data, server-safe tooling.Browser UI/features/apps.
Devtoolspackages/devtools/*Repo tooling, generators, lint/tsconfig/test/storybook helpers.contracts, tooling deps.Product runtime packages unless tooling-specific.
App Packagespackages/apps/*Importable OS app bundles registered by the shell, not deployable apps.contracts, ui, browser-safe features.Shell private internals, backend packages, deployable app code.

Current Package Placement

PackagePathLayerRuntime
@prox-os/actionspackages/ui/actionsUIbrowser
@prox-os/activitypackages/ui/activityUIbrowser
@prox-os/commandpackages/ui/commandUIbrowser
@prox-os/design-tokenspackages/ui/design-tokensUIshared
@prox-os/editorpackages/ui/editorUIbrowser
@prox-os/formspackages/ui/formsUIbrowser
@prox-os/notificationspackages/ui/notificationsUIbrowser
@prox-os/os-uipackages/ui/os-uiUIbrowser
@prox-os/ai-uipackages/features/ai-uiFeaturebrowser
@prox-os/collaborationpackages/features/collaborationFeaturebrowser
@prox-os/data-tablepackages/features/data-tableFeaturebrowser
@prox-os/data-vizpackages/features/data-vizFeaturebrowser
@prox-os/filespackages/features/filesFeaturebrowser
@prox-os/mapspackages/features/mapsFeaturebrowser
@prox-os/mediapackages/features/mediaFeaturebrowser
@prox-os/searchpackages/features/searchFeaturebrowser
@prox-os/security-uipackages/features/security-uiFeaturebrowser
@prox-os/workspace-uipackages/features/workspace-uiFeaturebrowser
@prox-os/almapackages/features/almaFeaturebrowser
@prox-os/inspectorpackages/features/inspectorFeaturebrowser
@prox-os/platform-navigationpackages/features/platform-navigationFeaturebrowser
@prox-os/app-contractpackages/contracts/app-contractContractshared
@prox-os/data-contractpackages/contracts/data-contractContractshared
@prox-os/studio-contractpackages/contracts/studio-contractContractshared
@prox-os/app-registrypackages/runtime/app-registryRuntimeshared
@prox-os/os-runtimepackages/runtime/os-runtimeRuntimeshared
@prox-os/runtime-chromepackages/runtime/runtime-chromeRuntimebrowser
@prox-os/studio-registrypackages/runtime/studio-registryRuntimebrowser
@prox-os/block-studio-enginepackages/studio-engines/blockStudio Enginebrowser
@prox-os/board-studio-enginepackages/studio-engines/boardStudio Enginebrowser
@prox-os/flow-studio-enginepackages/studio-engines/flowStudio Enginebrowser
@prox-os/connectorspackages/connectorsRuntimeshared
@prox-os/embed-runtimepackages/embed-runtimeRuntimeshared
@prox-os/dbpackages/data/dbDataserver
@prox-os/app-sharedpackages/apps/app-sharedApp packagebrowser
@prox-os/os-appspackages/apps/system-appsApp packagebrowser
@prox-os/user-appspackages/apps/user-appsApp packagebrowser
@prox-os/user-connector-appspackages/apps/user-connector-appsApp packagebrowser
@prox-os/dev-appspackages/apps/dev-appsApp packagebrowser
@prox-os/admin-appspackages/apps/admin-appsApp packagebrowser
@prox-os/game-appspackages/apps/game-appsApp packagebrowser
@prox-os/founder-appspackages/apps/founder-appsApp packagebrowser
@prox-os/community-appspackages/apps/community-appsApp packagebrowser
@prox-os/hub-appspackages/apps/hub-appsApp packagebrowser

packages/backend/storage is currently source-only placeholder code, not a workspace package yet. It sits in the backend layer because object storage presigning and provider bindings are server concerns.

packages/connectors and packages/embed-runtime are lightweight App Hub aggregation packages. They are root-level workspace packages by design for the early App Hub phase and should stay limited to types, mock data, and safe helpers until a real runtime layer split is justified.

Choosing A Directory For A New Package

  1. Decide whether the package is importable by browser code.
  2. Decide whether it owns a product domain, a reusable primitive, a runtime bridge, a contract, or a server implementation.
  3. Pick the layer before picking a package name.
  4. Add nx.tags and proxos metadata to the package manifest.
  5. Add dependency-cruiser rules or exceptions if the package introduces a new kind of boundary.
  6. Update the architecture document that owns the boundary.

Future Package Examples

Future packageSuggested pathReason
@prox-os/api-contractpackages/contracts/api-contractShared API request/response contract.
@prox-os/event-contractspackages/contracts/event-contractsShared event and activity payload shapes.
@prox-os/app-runtimepackages/runtime/app-runtimeFuture app-specific runtime bridge if it stays separate from @prox-os/os-runtime.
@prox-os/query-clientpackages/data/query-clientBrowser query utilities without DB clients.
@prox-os/authpackages/backend/authServer-only authentication implementation.
@prox-os/billingpackages/backend/billingServer-only billing implementation.
@prox-os/ai-corepackages/backend/ai-coreBackend AI orchestration boundary.
@prox-os/storybook-utilspackages/devtools/storybook-utilsShared Storybook tooling.
@prox-os/os-studio-enginepackages/studio-engines/osFuture extraction only when Shell coupling is reduced.

AI Agent Checklist

Before creating a package, an agent should answer:

  • What layer owns this responsibility?
  • Is the runtime browser, server, shared, or tooling?
  • Which scopes apply: os, admin, founder, workspace, ai, or data?
  • Which packages may import it?
  • Which packages must never import it?
  • Does it need a contract package first?
  • Does the change require a dependency-cruiser rule or architecture note?

If those answers are unclear, prefer a small contract package or a focused feature package over a broad implementation package.

On this page