# Tasks: Integrate SvelteKit

**Input**: Design documents from `/specs/004-integrate-svelte-kit/`
**Prerequisites**: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/

**Tests**: Tests are NOT explicitly requested in the feature specification, so no test-specific tasks are included. Verification will be done via the "Independent Test" criteria for each story.

**Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.

## Format: `[ID] [P?] [Story] Description`

- **[P]**: Can run in parallel (different files, no dependencies)
- **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3)
- Include exact file paths in descriptions

## Path Conventions

- **Web app**: `backend/src/`, `frontend/src/`

---

## Phase 1: Setup (Shared Infrastructure)

**Purpose**: Project initialization and basic structure

- [x] T001 Initialize SvelteKit in `frontend/` directory (replacing current setup)
- [x] T002 Install `@sveltejs/adapter-static` in `frontend/package.json`
- [x] T003 [P] Configure `frontend/svelte.config.js` for static adapter and SPA fallback

---

## Phase 2: Foundational (Blocking Prerequisites)

**Purpose**: Core infrastructure that MUST be complete before ANY user story can be implemented

**⚠️ CRITICAL**: No user story work can begin until this phase is complete

- [x] T004 Create `frontend/src/routes/+layout.ts` to disable SSR and prerendering (`ssr = false`, `prerender = false`)
- [x] T005 Implement catch-all route in `backend/src/app.py` to serve `index.html` for SPA routing
- [x] T006 [P] Update `backend/src/app.py` to mount `frontend/build` directory using `StaticFiles`
- [x] T007 [P] Update `frontend/src/lib/api.js` to ensure compatibility with SvelteKit environment
- [x] T022 [FR-008] Configure WebSocket proxying in `backend/src/app.py` and `frontend/vite.config.js`

**Checkpoint**: Foundation ready - user story implementation can now begin in parallel

---

## Phase 3: User Story 1 - Seamless Navigation (Priority: P1) 🎯 MVP

**Goal**: Navigate between Dashboard and Settings using standard URL paths so that users can bookmark pages and use browser navigation.

**Independent Test**: Click navigation links and verify the URL changes and the correct content renders without a full page reload. Verify deep linking by refreshing at `/settings`.

### Implementation for User Story 1

- [x] T008 [P] [US1] Create Dashboard route in `frontend/src/routes/+page.svelte` (migrating from `App.svelte`/`Dashboard.svelte`)
- [x] T009 [P] [US1] Create Settings route in `frontend/src/routes/settings/+page.svelte` (migrating from `Settings.svelte`)
- [x] T010 [US1] Implement navigation links between Dashboard and Settings in `frontend/src/routes/+page.svelte` and `frontend/src/routes/settings/+page.svelte`
- [x] T023 [US1] Implement "Save Settings" form submission in `frontend/src/routes/settings/+page.svelte`
- [x] T024 [US1] Implement plugin action triggers (e.g., "Run Backup") in `frontend/src/routes/+page.svelte`

**Checkpoint**: At this point, User Story 1 should be fully functional and testable independently.

---

## Phase 4: User Story 2 - Improved Data Loading (Priority: P2)

**Goal**: Use modern data loading patterns so that data is fetched efficiently before the page renders.

**Independent Test**: Observe the page load sequence and verify that data is available to the component immediately upon mount via the `data` prop.

### Implementation for User Story 2

- [x] T011 [P] [US2] Implement `load` function for Dashboard in `frontend/src/routes/+page.ts` to fetch plugins from `/api/plugins/`
- [x] T012 [P] [US2] Implement `load` function for Settings in `frontend/src/routes/settings/+page.ts` to fetch config and environments from `/api/settings/`
- [x] T013 [US2] Update `frontend/src/routes/+page.svelte` to use data from `load` function via `export let data;`
- [x] T014 [US2] Update `frontend/src/routes/settings/+page.svelte` to use data from `load` function via `export let data;`

**Checkpoint**: At this point, User Stories 1 AND 2 should both work independently.

---

## Phase 5: User Story 3 - Unified Layout (Priority: P3)

**Goal**: Consistent look and feel across all pages with a shared navigation bar and footer.

**Independent Test**: Navigate between Dashboard and Settings and verify that the header/footer remain static and do not re-render or flicker.

### Implementation for User Story 3

- [x] T015 [US3] Create shared layout in `frontend/src/routes/+layout.svelte` with `<slot />`
- [x] T016 [P] [US3] Move navigation bar component to `frontend/src/components/Navbar.svelte` and include in `+layout.svelte`
- [x] T017 [P] [US3] Create footer component in `frontend/src/components/Footer.svelte` and include in `+layout.svelte`

**Checkpoint**: All user stories should now be independently functional.

---

## Phase 6: Polish & Cross-Cutting Concerns

**Purpose**: Improvements that affect multiple user stories

- [x] T018 [P] Implement custom 404 error page in `frontend/src/routes/+error.svelte`
- [x] T019 Add graceful error handling for API failures in `load` functions (T011, T012)
- [x] T020 [P] Update `frontend/README.md` with new SvelteKit-based development and build instructions
- [x] T021 Run `specs/004-integrate-svelte-kit/quickstart.md` validation
- [x] T025 [FR-008] Update `TaskRunner.svelte` to use SvelteKit-compatible WebSocket connection logic
- [x] T026 [SC-001] Perform performance benchmarking to verify < 200ms transition time

---

## Dependencies & Execution Order

### Phase Dependencies

- **Setup (Phase 1)**: No dependencies - can start immediately
- **Foundational (Phase 2)**: Depends on Setup completion - BLOCKS all user stories
- **User Stories (Phase 3+)**: All depend on Foundational phase completion
  - User stories can then proceed in parallel (if staffed)
  - Or sequentially in priority order (P1 → P2 → P3)
- **Polish (Final Phase)**: Depends on all desired user stories being complete

### User Story Dependencies

- **User Story 1 (P1)**: Can start after Foundational (Phase 2) - No dependencies on other stories
- **User Story 2 (P2)**: Can start after Foundational (Phase 2) - Depends on US1 routes existing
- **User Story 3 (P3)**: Can start after Foundational (Phase 2) - Can be implemented independently of US1/US2 content

### Within Each User Story

- Models/Data fetching before UI implementation
- Core implementation before integration
- Story complete before moving to next priority

### Parallel Opportunities

- T003 (Svelte config) can run in parallel with other setup
- T006 (Backend mount) and T007 (API client) can run in parallel
- T008 (Dashboard route) and T009 (Settings route) can run in parallel
- T011 and T012 (Load functions) can run in parallel
- T016 and T017 (Navbar/Footer components) can run in parallel

---

## Parallel Example: User Story 2

```bash
# Launch all load function implementations for User Story 2 together:
Task: "Implement load function for Dashboard in frontend/src/routes/+page.ts"
Task: "Implement load function for Settings in frontend/src/routes/settings/+page.ts"
```

---

## Implementation Strategy

### MVP First (User Story 1 Only)

1. Complete Phase 1: Setup
2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
3. Complete Phase 3: User Story 1
4. **STOP and VALIDATE**: Test User Story 1 independently (Navigation and Deep Linking)
5. Deploy/demo if ready

### Incremental Delivery

1. Complete Setup + Foundational → Foundation ready
2. Add User Story 1 → Test independently → Deploy/Demo (MVP!)
3. Add User Story 2 → Test independently → Deploy/Demo
4. Add User Story 3 → Test independently → Deploy/Demo
5. Each story adds value without breaking previous stories
