refactor: migrate Embedding Landscape to IconRailPanel

[aaronsb]

Summary

• Replaces the custom fixed sidebar in EmbeddingLandscapeWorkspace with the shared IconRailPanel component
• Two tabs: Ontologies (visibility toggles, stats footer) and Settings (color scheme, perplexity, metric, grounding, regenerate)
• Regenerate action accessible from the icon rail for quick access
• Panel collapses VS Code-style, giving more canvas space when not needed
• Establishes consistency with ExplorerView, PolarityExplorer, BlockEditor, and ReportWorkspace (5 of 8 explorer-type views now use IconRailPanel)

Test plan

• Ontologies tab shows list with eye toggles, color dots, counts, and pinned stats footer
• Settings tab shows all controls (color scheme, perplexity slider, distance metric, refresh grounding, regenerate button)
• Clicking same icon collapses panel; clicking different icon switches tab
• Regenerate rail action triggers projection recompute
• 3D canvas renders and resizes correctly when panel is collapsed/expanded
• No regressions in other IconRailPanel consumers (2D/3D Graph, Polarity, Block Editor, Report)

[aaronsb]

Code Review: IconRailPanel Migration + Home Workspace Additions

PR Size: 4 files, +475/-250 lines -- standard review tier.

This PR contains two distinct changes: (1) migrating the Embedding Landscape sidebar to IconRailPanel, and (2) adding a NavigationGraph component plus HomeWorkspace tweaks. Reviewing both.

---

1. IconRailPanel Migration -- Well Executed

The migration from the custom sidebar to IconRailPanel is clean and consistent with how ExplorerView and PolarityExplorerWorkspace use the same component.

What looks solid:

• Wand2 import cleanly removed, showSettings state replaced with activeTab -- no stale references remain.
• Two-tab split (Ontologies / Settings) makes sense -- the old approach crammed everything behind a single toggle.
• Rail action for Regenerate gives quick access when the panel is collapsed -- good UX decision.
• defaultExpanded={true} is appropriate here (unlike ExplorerView which defaults collapsed) because ontology visibility is the primary sidebar interaction.
• Tab content definitions are inline, matching the pattern in ExplorerView (lines 525-538 of that file) and PolarityExplorerWorkspace.

Pattern consistency confirmed: The signature <IconRailPanel tabs={[...]} activeTab={activeTab} onTabChange={setActiveTab} actions={[...]} /> matches all other consumers exactly.

2. Stats Footer Layout -- Potential Scroll Conflict

Location: EmbeddingLandscapeWorkspace.tsx lines 500-581

Observation: The Ontologies tab content uses flex flex-col h-full with a scrollable list and a pinned flex-shrink-0 footer. This is a valid flexbox pattern in isolation, but it depends on the parent providing a constrained height.

Looking at IconRailPanel.tsx line 111, the content wrapper is:

<div className="flex-1 overflow-y-auto">
  {tabs.find((t) => t.id === activeTab)?.content}
</div>

The parent already has overflow-y-auto and flex-1. The child's h-full should resolve to the parent's computed height, and the inner overflow-y-auto on the scrollable region should take over scrolling. This should work correctly because:

• The parent flex-1 gives it a definite height within the flex column.
• The child h-full fills that height.
• The inner flex-1 overflow-y-auto min-h-0 creates the scroll containment.

However, there is a subtle concern: the parent also has overflow-y-auto. If the child content does not fill the parent, both scroll containers are effectively competing. In practice this is benign (the inner one scrolls, the outer one has no overflow), but it creates a double-scrollbar risk if the stats footer pushes the child taller than the parent. Worth a quick manual test with many ontologies loaded.

Suggestion: Consider adding overflow-hidden to the Ontologies tab wrapper (<div className="flex flex-col h-full">) to make the inner scroll containment fully explicit, preventing the outer overflow-y-auto from ever activating on the Ontologies tab. Not blocking -- just defensive.

3. Regenerate Action: Loading State Feedback

Location: EmbeddingLandscapeWorkspace.tsx lines 729-736

The Regenerate rail action triggers regenerateGlobalProjection but the icon in the rail is a static RefreshCw. Unlike the in-panel Regenerate button (which shows a Loader2 spinner when loading, line 709), the rail icon has no loading feedback. If a user clicks the rail action and then collapses the panel, there is no visible indication that regeneration is in progress.

Suggestion: This is minor since the main canvas shows a loading state, but if other rail actions in the codebase show loading state, this should match for consistency.

4. HomeWorkspace Changes -- Out of Scope but Reviewing

The PR description says "migrates Embedding Landscape to IconRailPanel" but also:

• Changes stats.nodes.Concept -> stats.nodes.concepts (line 72-74) -- this is an API response shape change, presumably from a backend update. If the backend hasn't landed yet, this would break the home dashboard.
• Adds NavigationGraph component and import.
• Removes description props from all SidebarItem components in AppLayout.tsx.
• Widens max-w-4xl to max-w-6xl.

These are separate concerns from the IconRailPanel migration. Not blocking, but worth noting in the PR description for traceability. The stats field rename in particular could be a regression risk if the API still returns Concept/Source (capitalized).

5. NavigationGraph Component -- Self-Contained and Clean

NavigationGraph.tsx (227 lines) is well-structured:

• Pure presentational component with no side effects beyond useNavigate.
• Static data model (NODES, EDGES) makes it deterministic and testable.
• Good accessibility: role="button", tabIndex={0}, aria-label on nodes.
• Edge rendering with quadratic bezier curves is a nice visual touch.

Minor note: The SVG uses CSS custom properties (var(--primary-h), var(--border-h), etc.) that assume HSL component variables are defined. If the theme only defines composite HSL values, these would fail silently. Since other parts of the codebase presumably use these variables, this should be fine -- just flagging the assumption.

One concern: nodeMap (line 94) is recreated on every render since it is not memoized. With 14 nodes this is negligible, but useMemo would be more idiomatic for a Map derived from a constant array.

6. No Test Coverage

No test files were added or modified. The NavigationGraph is a new component that would benefit from at least a smoke-render test (does it render 14 nodes, do click handlers fire navigation). The IconRailPanel migration is behavioral parity, so testing is lower priority there, but the new component has no coverage.

---

Summary

Category	Verdict
Correctness	Pass -- all functionality preserved, no stale references
Pattern consistency	Pass -- matches ExplorerView/PolarityExplorer usage exactly
Stats footer layout	Low risk -- works but double-scroll container worth testing
Stale imports/state	Pass -- Wand2 removed, showSettings replaced cleanly
SOLID compliance	Pass -- component boundaries are clear, no monolithic patterns
Scope creep	Note -- HomeWorkspace/AppLayout/NavigationGraph changes are bundled but unrelated to the IconRailPanel migration
Regressions	Watch -- stats.nodes.concepts vs stats.nodes.Concept depends on API shape

No blocking issues. The IconRailPanel migration is the right move for consistency across the 5+ workspace views.