# Research: Frontend Navigation Redesign

## Decisions

### 1. Backup Management UI Strategy
**Decision**: Create a dedicated `BackupManager` component in `frontend/src/components/backups/`.
**Rationale**: The requirement is to have a "full component" accessible from the dashboard. Separating it into its own directory ensures modularity and keeps the Dashboard component clean. It will consume the existing backup APIs (likely `/api/tasks` with specific backup types or a dedicated backup endpoint if one exists - *to be verified in Phase 1*).
**Alternatives considered**: Embedding backup controls directly in the Dashboard (rejected: clutters the main view), reusing the TaskRunner component (rejected: need specific backup context/history view).

### 2. Navigation State Management
**Decision**: Use SvelteKit's layout system (`+layout.svelte`) and simple component props for Navbar state.
**Rationale**: The Navbar changes are global. Removing items is a static change to the `Navbar.svelte` component. No complex state management (stores) is needed for this structural change.
**Alternatives considered**: Dynamic config-based menu (rejected: overkill for this specific redesign).

### 3. Deprecation Strategy
**Decision**: Hard removal of "Dataset Search" and "Deployment Environments" components and routes.
**Rationale**: The spec explicitly calls for removal. Keeping dead code increases maintenance burden.
**Alternatives considered**: Hiding behind a feature flag (rejected: requirement is explicit removal).

### 4. Dashboard Grid Layout
**Decision**: Update `DashboardGrid.svelte` to include new cards for Mapper, Storage, and Backups.
**Rationale**: Reusing the existing grid component maintains consistency.
**Alternatives considered**: Creating a separate "Tools" page (rejected: spec requires access from main Dashboard).