tasks ready

specs/015-frontend-nav-redesign/research.md

@@ -0,0 +1,23 @@
+# 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).