You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Proposal: Add plugin-setup to Own and Register the Platform Setup App
Background
Currently, setup app (系统设置/Setup) is dynamically composed by the engine, with its title, icon, i18n, default branding, and area skeletons (Administration, Platform, System, AI, etc) scattered in either objectql or spec.
It is unclear where the platform Setup App's authority (as an app), lifecycle, and registrations should reside. This creates architectural confusion: protocol and data engine (spec, objectql) should not own system-level app instances or finalize navigation merges.
All other major system entities (e.g., users, roles, audit logs) are owned by internal plugins: plugin-auth (SysUser), plugin-security (SysRole), plugin-audit (SysAuditLog), etc.
Proposal
Create a dedicated plugin-setup (e.g. packages/plugins/plugin-setup) as a first-class internal platform plugin, sibling to plugin-auth and plugin-security.
This plugin should:
Export Setup App identity: name, label (multi-lang), icon, permissions, branding, and all default meta.
Contain the 4 built-in Setup Areas (Administration, Platform, System, AI) as empty group skeletons for other plugins to contribute their settings/navigation.
On kernel/engine ready/finalize, collect all setupNav contributions, merge areas and groups, filter out empty areas, and register the finalized Setup App as an internal platform app.
Optionally: define platform Setup Home page, handle global Setup search, enforce Setup permissions.
Remove all platform Setup App definition and merge logic from objectql and spec, making those packages protocol- and data-focused only.
Benefits
Architectural clarity: spec = protocol only, objectql = data/query only, plugins = system feature and UI composition.
Matches existing extensibility model: all system apps and objects are owned by plugins for encapsulation, modularity, and clear ownership.
Greatly simplifies cross-repo and downstream system extension.
Foundation for future features: Setup as a visible app, plugin-aware Setup Home, Setup extensibility via plugin-contributed areas/pages/search.
Proposal: Add
plugin-setupto Own and Register the Platform Setup AppBackground
setup app(系统设置/Setup) is dynamically composed by the engine, with its title, icon, i18n, default branding, and area skeletons (Administration, Platform, System, AI, etc) scattered in either objectql or spec.plugin-auth(SysUser),plugin-security(SysRole),plugin-audit(SysAuditLog), etc.Proposal
plugin-setup(e.g.packages/plugins/plugin-setup) as a first-class internal platform plugin, sibling toplugin-authandplugin-security.ready/finalize, collect allsetupNavcontributions, merge areas and groups, filter out empty areas, and register the finalized Setup App as an internal platform app.objectqlandspec, making those packages protocol- and data-focused only.Benefits