UMES 2.09 Roadmap (Not Extensible Yet)
This is the short list of extension capabilities not fully available yet, based on current implementation and UMES phase backlog.
Not yet extensible (or not first-class yet)
| Gap | Why it matters | Planned UMES track |
|---|---|---|
Detail-page binding framework (useExtensibleDetail) | No unified API to inject typed fields/sections/actions into detail pages with save orchestration | Phase I |
| Recursive widget extension points | Widgets cannot define their own child extension zones in a standardized way | Phase J |
| UMES DevTools and conflict diagnostics | Hard to inspect extension precedence, collisions, and active registrations at runtime | Phase K |
| Integration-first UI blocks (wizard widgets, status badges, external ID presentation) | Integration UX remains mostly custom and repetitive | Phase L |
| Generic external data connector registry ("data integrators") | No built-in connector abstraction for pull/push sync providers yet | Phase L + marketplace specs |
| Integration marketplace hub | Discovery/install governance for integration packages is not productized yet | SPEC-045 series |
Phase M implemented
Phase M items (mutation guards, sync subscribers, command interceptors, client-side event filtering) are now implemented — see UMES phases.
Phase N implemented
Phase N items (query-level enrichers, sync query lifecycle events, scope guard re-application) are now implemented — see Query engine extensibility.
Related specs for this roadmap
- SPEC-041 (UMES master)
- SPEC-041i (detail bindings)
- SPEC-041j (recursive widgets)
- SPEC-041k (UMES devtools)
- SPEC-041l (integration extensions)
- SPEC-041m (mutation lifecycle)
- SPEC-041n (query engine extensibility)
- SPEC-045 (integration marketplace)
Target outcome for UMES 2.09
UMES 2.09 should make integration and extension work predictable across UI, API, data, and runtime layers, with explicit ordering, diagnostics, and testable contracts for each extension type.