AdaOS Product Terminology

AdaOS is an environment for personal digital assistants. Internally the runtime still uses subnets, scenarios, widgets, browser sessions, hub/member roles, and Yjs webspaces, but normal product UI should lead with named user-facing entities.

Primary Model

The user-facing hierarchy is:

Assistant -> Webspace -> Application -> Panel

The runtime/device hierarchy is:

Assistant -> Device -> Agent

Combined:

Assistant
  -> Webspaces
     -> Applications
        -> Panels
  -> Skills
  -> Devices
     -> Agents
  -> Interfaces
  -> Catalog

Term Mapping

Internal term	Product term	Notes
`subnet`, `subnet_id`	Assistant, Assistant ID	Show the display name by default. Keep IDs for diagnostics.
`webspace`, `default`, `main`	Webspace, Main	Webspace is an access/projection context, not a folder.
`scenario`	Application	Scenario remains the implementation/authoring term.
`web_desktop`	Capabilities	Default overview application. Keep `web_desktop` as the stable ID.
`skill`	Skill	Executable capability used by applications and agents.
`widget`	Widget, later Panel	Current UI may keep Widget while the broader product model reserves Panel.
`browser`, `member`, `hub`, `subnet endpoint`	Agent	Software participant of the assistant subnet.
`device`	Device	Physical or virtual host. One device may host multiple agents.
`marketplace`	Catalog	Place to add applications, skills, widgets/panels, interfaces, agents, and integrations.
`install`	Add to assistant	Use install/deploy wording only in advanced or developer UI.

UI Rules

Use named entities first. For example, render subnet_id as My Assistant or the user-defined assistant name, default as Main, and web_desktop as Capabilities.

The primary top-bar formula is:

Brand | Assistant | Webspace | Application | Status | Actions

In compact layouts, the assistant name may be hidden when it is the default My Assistant, leaving:

Webspace / Application

Debug-first labels such as raw subnet IDs, endpoint IDs, LINK OK, or low-level Yjs state belong in diagnostics and advanced mode.

Compatibility Policy

Do not break the current API or Yjs schema while migrating terminology. Add public aliases and projections first:

web.application.* may delegate to existing web.desktop.*.
application_id may alias scenario_id.
pinned_panels may alias pinned_widgets if and when Panel becomes the visible term.
New product kinds such as Assistant, Application, Agent, and Panel can exist next to older internal/debug kinds.

Device/Agent migration should happen through projections and catalog views before changing connectivity or pairing data structures.