[Feature] API-native App/Extension Management: install & enable apps via UI/API, with per-Space and per-User-Group configuration (inspired by OpenCode's plugin system) #3690

Is your feature request related to a problem? Please describe.

Currently, adding and activating custom apps/extensions (JS) in OpenCloud requires:

• Manually adding the app files into the Docker image / web assets at build/deploy time.
• An instance admin manually enabling the app globally via configuration.
• A restart/redeploy of the container for any change (install, update, remove) to take effect.

This is cumbersome and has several limitations:

• Every new app or app update requires rebuilding/redeploying the Docker image — there is no way to install, update, or remove an app at runtime via the API.
• Only instance-wide admins can manage apps; Space admins have no way to enable/disable apps for their own Space.
• There is no granularity — apps are either on or off globally, with no way to scope them to specific Spaces or specific user groups.
• No hot-reload — any app change requires a restart.

This makes the app/extension system inflexible for multi-tenant setups, managed hosting, or organizations that want different Spaces/teams to have access to different tools.

Describe the solution you'd like

Introduce an API-native app/extension management system. OpenCode's plugin system (https://opencode.ai/v2/docs/plugins/) is a great reference implementation of how this can be done well — config-driven, CLI-manageable, discoverable, and hot-reloadable. OpenCloud's app system could adopt similar concepts:

1. Config-driven app declaration (like OpenCode's plugins array)

• Allow apps to be declared in a config file (e.g. opencloud.json(c)) by package name, version, scoped package, Git reference, local path, or URL — similar to OpenCode's plugins array:

  {
    "apps": [
      "opencloud-acme-app",
      "opencloud-acme-app@1.2.0",
      "@acme/opencloud-app",
      "./apps/local",
      "git+ssh://git@github.com/acme/opencloud-app.git#main",
      {
        "package": "@acme/opencloud-app",
        "options": { "someOption": true }
      }
    ]
  }

• Support layered config resolution (global/system config, instance config, Space-level config) merged by precedence, instead of a single global flat list.

2. Discovery of local/dev apps

• Like OpenCode's .opencode/plugins/ discovery, support an .opencloud/apps/ (or similar) directory where .js/.ts files and app package directories are auto-discovered without explicit config entries — useful for local development and quick testing.

3. Enable/disable control with wildcards (like OpenCode's -id / * / prefix.* syntax)

• Support enabling/disabling apps via simple ID-based rules, processed in order, e.g.:

  { "apps": ["*", "-acme.betaApp", "-vendor.*", "vendor.approvedApp"] }

• Allow instance admins to mark certain core/policy-related apps as non-removable (similar to OpenCode's built-in plugins that ignore removal), so critical functionality/compliance apps can't be disabled by Space admins.

4. CLI / API for install, list, update, remove

• Provide both a CLI and REST/GraphQL API equivalent to OpenCode's opencode plugin commands:

  opencloud app add acme-app@1.2.0
  opencloud app list
  opencloud app list --builtin
  opencloud app check
  opencloud app update
  opencloud app update acme-app
  opencloud app remove acme-app@1.2.0

• Support npm-style and Git-based install sources (hosted shortcuts, HTTPS, SSH, branches/tags/commit hashes, subdirectory selectors) so apps aren't limited to a single packaging format.
• app check / app update should check for and apply updates to unpinned apps without needing a redeploy; exact pinned versions/commits stay untouched unless explicitly updated.

5. Hot reload — no restart required

• Like OpenCode's automatic reload on config/directory changes, newly installed/updated/removed apps should take effect without a full service restart wherever technically feasible (at least for config and app-list changes; actual JS bundle changes may require a lighter-weight reload mechanism such as a frontend asset refresh rather than full server restart).

6. Space-level app management (Space admin UI)

• Space admins should be able to see a catalog of all apps available/installed on the instance.
• From the Space settings UI, a Space admin can enable/disable individual apps for their own Space, without needing instance-admin rights.
• This should also be exposed via API, so it can be automated (e.g. via scripts/provisioning tools).

7. Per-user-group configurability

• For each Space (or globally), allow configuring which apps are enabled for which user group/role within that Space (e.g. only "Editors" get access to App X, "Viewers" don't).
• This could reuse existing group/role concepts already present in OpenCloud (Space members, roles, or external groups like Keycloak groups).

8. Instance-admin level controls (kept, but extended)

• Instance admins should still be able to:
  • Globally allow/block specific apps across the whole instance (e.g. for compliance/security reasons), overriding Space-level choices if needed — similar to OpenCode's non-removable built-in plugins (opencode.config.policy, opencode.provider.opencode).
  • Define a default state for newly installed apps (enabled/disabled by default for new Spaces).
• Instance admins manage the "app catalog" (what's available to be enabled by Space admins), while Space admins manage what's actually active in their Space.

Example workflow

1. Instance admin (or an automated pipeline) registers a new app via CLI/API (opencloud app add @acme/opencloud-app@latest) — no image rebuild or restart needed.
2. The app now appears in an "App catalog" visible to Space admins.
3. A Space admin goes to their Space settings → "Apps" tab, sees the available app, and enables it for their Space.
4. The Space admin further restricts the app to only be visible/usable by a specific group (e.g. "Project Managers") within that Space.
5. All of this is also achievable by calling the API/CLI directly (e.g. for bulk provisioning of apps across many Spaces), and changes take effect immediately without restarting OpenCloud.

Describe alternatives you've considered

• Continuing to manually bake apps into the Docker image — doesn't scale, requires redeploys for every app change, and gives no Space-level flexibility.
• Only instance-admin-level global enable/disable — too coarse-grained for multi-tenant or team-based use cases where different Spaces need different toolsets.

Additional context

• Reference implementation worth studying: OpenCode's plugin system — https://opencode.ai/v2/docs/plugins/
  • Particularly good ideas to borrow: layered config precedence, .opencode/plugins/ auto-discovery, wildcard enable/disable rules with non-removable core plugins, unified CLI (add/list/check/update/remove), support for npm + Git package sources (including subdirectory/branch/commit pinning), and automatic reload on config/directory changes without a full restart.
• This would make OpenCloud's app/extension ecosystem much more dynamic and suitable for managed/hosted multi-tenant deployments.
• Could pair well with a future "App Store"/marketplace concept, where admins/Space admins browse and install apps without any manual file/config changes.
• Please clarify security/sandboxing considerations for API-installed apps (e.g. code review, signing, permissions model) as part of the design, since this introduces a new attack surface if apps can be installed without a rebuild — OpenCode's model of pinning exact versions/commit hashes and distinguishing trusted "built-in"/non-removable plugins from user-installed ones could serve as a starting point here too.