Is your enhancement related to a problem? Please describe

The Eclipse Che Dashboard is a monolithic frontend application. When a team wants to add an optional feature — for example, a Devfile Creator, an AI assistant panel, or a custom workspace type — the only options today are:

1. Merge the feature directly into the dashboard core, which increases the maintenance surface for the core team and couples unrelated features together.
2. Fork the dashboard repository, which diverges from upstream and creates long-term maintenance pain.

There is no supported mechanism for developing, versioning, and distributing optional dashboard features independently of the core codebase.

Describe the solution you'd like

Introduce a lightweight plugin system that lets optional features be developed, released, and integrated into the dashboard without touching the core repository.

The system has three parts:

1. Plugin SDK — packages/dashboard-plugins

A shared TypeScript package (@eclipse-che/dashboard-plugins) that defines the contracts between the dashboard core and plugins:

• PluginManifest — plugin identity: id, name, version, enabled
• FrontendPlugin — main plugin entry point: Redux reducer + bootstrapper + extension slots
• PluginSlots — named React extension points where plugins can inject UI:

• WorkspaceHooks — lifecycle callbacks: onWorkspaceCreate, onWorkspaceStart
• Runtime registry — registerFrontendPlugin / getRegisteredFrontendPlugins used by the dashboard core at render time

2. Plugin bundles — independent source trees

Plugins live in a separate repository (e.g., olexii4/che-dashboard-plugins) and are released as ZIP archives on GitHub Releases. Each plugin is an independent npm workspace that depends only on @eclipse-che/dashboard-plugins and React.

3. Dashboard integration — thin wiring layer

A small set of scripts (scripts/fetch-plugins.sh, scripts/prepare-plugins.sh) downloads the configured plugin ZIPs at build time and mounts them into src/plugins/. The dashboard's src/plugins/index.ts registers all plugins with the runtime registry on startup.

Describe alternatives you've considered

• Feature flags inside the core — keeps everything in one repository but couples all features to the core release cycle and doesn't help external contributors.
• Micro-frontends (Module Federation) — more powerful but significantly more complex to set up, requiring separate deployment infrastructure and runtime coordination.
• Dynamic remote loading at runtime — avoids build-time coupling but introduces CSP and security concerns in a Kubernetes environment.

Additional context

• Proof-of-concept implementation: [poc]lightweight plugin system to the Eclipse Che Dashboard che-dashboard#1552
• Plugin bundles repository (draft): https://github.com/olexii4/che-dashboard-plugins
• The plugin system is intentionally minimal — it adds one npm package and two shell scripts to the core. Plugins are statically bundled at build time, so there is no runtime module loading.
• The first consumer of this system would be the Devfile Creator + AI Agent feature (see related issue).