[Architecture] Unified Metadata Management Entry & Dynamic Routing

[hotlong]

Problem Statement

Currently, we have developed object and field management, but more metadata types (e.g. dashboard, page, report, workflow, etc.) need CRUD management. The codebase implements dedicated entry points and routes (e.g., /system/objects, /system/apps) for each, but this pattern does not scale as metadata types grow.

Why Unification Is Needed

• All metadata types (object, dashboard, page, report, etc.) use the same backend contract (client.meta.getItems(type), client.meta.saveItem(type, name, data)).
• Only object and app currently have full admin UIs. The rest are unmanageable except by backend ops or direct API calls.
• The SystemHubPage UI is currently hardcoded: new system types require code duplication for routes, hub cards, and manager pages.
• As metadata expands (future: workflow, tab, custom_action, validation_rule, ...), lack of a unified entry leads to a maintenance bottleneck and inconsistent admin experience.

Proposal: Unified Metadata Manager

Implement a single, extensible Metadata Manager page and route structure:

• Route pattern:
  • /system/metadata/:metadataType (list)
  • /system/metadata/:metadataType/:itemName (detail)
• Use a MetadataType registry (config) to generate:
  • List page with schema-driven grid
  • Detail page (generic modal, or custom React component for complex types)
  • Card(s) on the SystemHub auto-generated from registry
• Existing managers (ObjectManagerPage, etc.) can register as custom detail views for their type
• All CRUD and data fetching via generalized MetadataService methods
• Support soft-delete, optimistic update, and rollback for all types
• No breaking changes: legacy routes forward to unified routes

Example Config

export const METADATA_TYPES = [
  {
    type: 'object', label: 'Objects', icon: 'database',
    detailComponent: ObjectDetailView, // custom
  },
  {
    type: 'dashboard', label: 'Dashboards', icon: 'layout-dashboard',
    columns: [...], formFields: [...], // generic
  },
  // etc...
]

Benefits

• Single source of truth: new types = 1 line config
• Reduced boilerplate: all pages, routes, hub cards use registry
• Easier to onboard contributors (fewer files to touch for new types)
• Future proof: ready for workflow/automation/tab/layout additions
• Fully testable: Plug the manager into existing test harnesses

References

• See apps/console/src/pages/system/ObjectManagerPage.tsx (pattern)
• See apps/console/src/context/MetadataProvider.tsx (fetch method)
• See apps/console/src/services/MetadataService.ts (API contract)
• See ROADMAP.md metadata platform section

---

• Registry config for supported types
• Generic MetadataManagerPage for any type
• SystemHubPage auto-generate from registry
• Migrate legacy routes
• Documentation update (architecture/console/README.md)

This will unlock full SDUI native metadata management. Please discuss/critique the registry structure before implementation.