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
Complete the drag-foldable desktop left navigation while preserving its shipped layout/state model and finishing the remaining interaction, accessibility, reflow, and integration work on the application’s selected UI-shell architecture.
The left navigation participates in normal layout. It is never a desktop overlay or backdrop. Mobile keeps its segmented/bottom-navigation presentation and preserves desktop preferences for return to desktop.
Finish left-navigation polish and integration on the selected architecture
If #577 selects Preact, the remaining implementation is Phase 2 of the migration umbrella #578. If Preact is rejected, complete the same product behavior with the smaller targeted vanilla design recorded by the #577 ADR.
This issue no longer prescribes a left-nav-focus.ts, shell-focus-transitions.ts, hook, component, or global focus manager. The behavior is fixed; the implementation boundary is selected by #577.
Shipped foundations to retain
The following design decisions are proven and should survive any rendering-layer migration:
Pure semantic layout core
src/core/left-nav-layout.ts owns semantic mode, focused-section coherence, thresholds, pointer/keyboard reducers, viewport clamping, and preferred/proposed/effective resize-session rules. It remains DOM-free.
Persistent section ownership
Databases, Dashboards, Library, and History each retain one logical host/state owner. Presentation changes must not recreate search, expansion, loaded data, scroll, edit, or selection state.
Gesture memory and preference safety
Resize sessions keep persisted preference, raw proposal, and effective viewport-clamped layout separate. Temporary viewport constraints and pointer sampling must not corrupt the saved preferred width.
One presentation owner
The selected UI-shell architecture must provide one owner for navigation geometry, visibility, pane exposure, separator state, and ARIA presentation. Do not create competing vanilla and Preact owners for the same subtree.
Remaining product work
1. Structural focus continuity
Any transition that hides or structurally reflows the focused navigation source must settle focus on a visible semantic destination.
Required behavior:
capture semantic intent before the first destructive transition frame;
preserve that intent through intermediate pointer-drag frames;
do not restore focus during live drag repaint;
settle after the destination is rendered and browser layout is stable;
cancel stale or superseded transition work;
do not steal focus after the user has moved to another visible control;
do not leave focus on <body> merely because application chrome changed presentation;
dispose pending transition work during remount, workspace switch, sign-out, or shell teardown.
Destination policy when focus originated in navigation:
Transition
Destination
wide or focused drawer -> bare rail
matching rail launcher; separator fallback
rail/focused drawer -> wide
matching live wide-mode tab; separator fallback
focused drawer closed by Escape or launcher
matching rail launcher
desktop navigation -> mobile, including Tables
active mobile bottom-navigation button
mobile Tables -> Editor/Results
selected bottom-navigation button
mobile Query -> Dashboard
visible Editor route button
cancelled gesture or no semantic change
preserve current user focus
The implementation may be a component lifecycle, hook, tiny scheduler plus feature policy, or small imperative service. It must not become a global application focus manager without evidence from #577.
2. Separator discoverability
Closing a focused drawer relocates the 7px separator from the drawer edge to the rail edge. Make the new drag location discoverable without adding a separate collapse button.
Requirements:
use a brief visual emphasis or geometry transition selected through implementation review;
honor prefers-reduced-motion;
do not steal keyboard focus;
do not make animation necessary for correctness;
keep the separator keyboard reachable with visible focus.
3. Centre and right-panel reflow
Reflow every active centre surface through established observers or explicit layout hooks:
CodeMirror/editor geometry;
result table and virtualized rows;
editor/results split layout;
Dashboard grids, flow layouts, charts, and sticky bars;
The width budget must include left navigation, the optional right inspector, and a documented useful centre minimum. Viewport clamping must not overwrite the preferred left width.
Goal
Complete the drag-foldable desktop left navigation while preserving its shipped layout/state model and finishing the remaining interaction, accessibility, reflow, and integration work on the application’s selected UI-shell architecture.
Desktop presentations remain:
The left navigation participates in normal layout. It is never a desktop overlay or backdrop. Mobile keeps its segmented/bottom-navigation presentation and preserves desktop preferences for return to desktop.
Status and architecture dependency
If #577 selects Preact, the remaining implementation is Phase 2 of the migration umbrella #578. If Preact is rejected, complete the same product behavior with the smaller targeted vanilla design recorded by the #577 ADR.
This issue no longer prescribes a
left-nav-focus.ts,shell-focus-transitions.ts, hook, component, or global focus manager. The behavior is fixed; the implementation boundary is selected by #577.Shipped foundations to retain
The following design decisions are proven and should survive any rendering-layer migration:
Pure semantic layout core
src/core/left-nav-layout.tsowns semantic mode, focused-section coherence, thresholds, pointer/keyboard reducers, viewport clamping, and preferred/proposed/effective resize-session rules. It remains DOM-free.Persistent section ownership
Databases, Dashboards, Library, and History each retain one logical host/state owner. Presentation changes must not recreate search, expansion, loaded data, scroll, edit, or selection state.
Gesture memory and preference safety
Resize sessions keep persisted preference, raw proposal, and effective viewport-clamped layout separate. Temporary viewport constraints and pointer sampling must not corrupt the saved preferred width.
One presentation owner
The selected UI-shell architecture must provide one owner for navigation geometry, visibility, pane exposure, separator state, and ARIA presentation. Do not create competing vanilla and Preact owners for the same subtree.
Remaining product work
1. Structural focus continuity
Any transition that hides or structurally reflows the focused navigation source must settle focus on a visible semantic destination.
Required behavior:
<body>merely because application chrome changed presentation;Destination policy when focus originated in navigation:
The implementation may be a component lifecycle, hook, tiny scheduler plus feature policy, or small imperative service. It must not become a global application focus manager without evidence from #577.
2. Separator discoverability
Closing a focused drawer relocates the 7px separator from the drawer edge to the rail edge. Make the new drag location discoverable without adding a separate collapse button.
Requirements:
prefers-reduced-motion;3. Centre and right-panel reflow
Reflow every active centre surface through established observers or explicit layout hooks:
The width budget must include left navigation, the optional right inspector, and a documented useful centre minimum. Viewport clamping must not overwrite the preferred left width.
4. #428 drag-and-drop integration
During a Library-query drag in rail mode:
5. Documentation and final verification
Tests
Architecture-independent unit coverage
Real-browser coverage
Chromium and WebKit must cover:
<body>when a semantic destination exists;Acceptance criteria
Non-goals
setTimeoutfocus or resize guesses.Related