Prerequisites
Area
UI / Frontend
Problem or Motivation
Settings navigation currently duplicates panel ownership knowledge in frontend
code and has no shared information-architecture contract.
The existing Settings sidebar is also difficult to scan as Settings grows:
navigation is fixed-width, there is no finder, and the narrow desktop rail
leaves little room for discoverability.
This makes subsequent Settings modularization harder because panel identity,
admin routing, labels, and navigation metadata do not have one authoritative
frontend representation.
Proposed Solution
Introduce a focused Settings information-architecture layer and navigation
finder while preserving existing panel behavior.
The implementation:
- adds a canonical Settings panel/group registry;
- distinguishes admin-managed panels from admin-only panels;
- replaces the existing hard-coded admin routing set with registry metadata;
- validates registry IDs against the Settings DOM;
- adds metadata-backed Settings search;
- hides admin-only finder results from non-admin users;
- supports keyboard navigation and Escape-to-clear;
- widens the Settings window and navigation rail for readability;
- makes the desktop Settings navigation resizable;
- persists the preferred navigation width;
- allows the navigation rail to collapse to a compact expand control;
- preserves the existing horizontal navigation behavior for narrow/snapped
Settings windows.
The registry remains descriptive rather than becoming a generic dynamic
Settings renderer. Existing panel implementations and persistence contracts
remain unchanged.
Alternatives Considered
Keeping panel metadata distributed across markup and routing code would avoid a
new registry but would continue duplicating ownership information.
Filtering the existing sidebar items in place was considered for search, but it
would make section dividers and admin visibility harder to reason about.
A result-oriented finder keeps the existing navigation structure intact.
A full Settings redesign or framework migration would be substantially larger
than necessary for this foundation.
Prior Art / Related Issues
This builds on the focused Settings shell modularization in #6036 / #6037.
Are you willing to implement this?
Yes — I can open a PR
Prerequisites
Area
UI / Frontend
Problem or Motivation
Settings navigation currently duplicates panel ownership knowledge in frontend
code and has no shared information-architecture contract.
The existing Settings sidebar is also difficult to scan as Settings grows:
navigation is fixed-width, there is no finder, and the narrow desktop rail
leaves little room for discoverability.
This makes subsequent Settings modularization harder because panel identity,
admin routing, labels, and navigation metadata do not have one authoritative
frontend representation.
Proposed Solution
Introduce a focused Settings information-architecture layer and navigation
finder while preserving existing panel behavior.
The implementation:
Settings windows.
The registry remains descriptive rather than becoming a generic dynamic
Settings renderer. Existing panel implementations and persistence contracts
remain unchanged.
Alternatives Considered
Keeping panel metadata distributed across markup and routing code would avoid a
new registry but would continue duplicating ownership information.
Filtering the existing sidebar items in place was considered for search, but it
would make section dividers and admin visibility harder to reason about.
A result-oriented finder keeps the existing navigation structure intact.
A full Settings redesign or framework migration would be substantially larger
than necessary for this foundation.
Prior Art / Related Issues
This builds on the focused Settings shell modularization in #6036 / #6037.
Are you willing to implement this?
Yes — I can open a PR