# Tasks: Fix UI Styling, WebSocket Port Mismatch, and URL Validation **Input**: Design documents from `/specs/001-fix-ui-ws-validation/` **Prerequisites**: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/ **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 ## Phase 1: Setup (Shared Infrastructure) **Purpose**: Project initialization and basic structure - [x] T001 Verify project structure and install dependencies in `backend/` and `frontend/` --- ## 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] T002 [P] Configure `PUBLIC_WS_URL` in `frontend/.env` **Checkpoint**: Foundation ready - user story implementation can now begin in parallel --- ## Phase 3: User Story 1 - Consistent UI Styling (Priority: P1) 🎯 MVP **Goal**: Apply Tailwind CSS globally via the root layout to ensure consistent appearance. **Independent Test**: Open the application in a browser and verify that Tailwind styling is applied to all elements (e.g., Navbar, Footer, Buttons). ### Implementation for User Story 1 - [x] T003 [P] [US1] Verify Tailwind directives in `frontend/src/app.css` - [x] T004 [US1] Import `../app.css` in `frontend/src/routes/+layout.svelte` **Checkpoint**: At this point, User Story 1 should be fully functional and testable independently --- ## Phase 4: User Story 2 - Real-time Log Monitoring (Priority: P1) **Goal**: Resolve WebSocket port mismatch using environment variables and fallback logic for real-time logs. **Independent Test**: Start a task (e.g., a mock migration) and verify that logs appear in the `TaskRunner` component in real-time. ### Implementation for User Story 2 - [x] T005 [P] [US2] Implement WebSocket URL fallback logic in `frontend/src/lib/api.js` - [x] T006 [US2] Update `frontend/src/components/TaskRunner.svelte` to use the dynamic WebSocket URL **Checkpoint**: At this point, User Stories 1 AND 2 should both work independently --- ## Phase 5: User Story 3 - Flexible External Service Connection (Priority: P2) **Goal**: Automatically append `/api/v1` to service base URLs if missing to simplify configuration. **Independent Test**: Create a new service connection with `http://localhost:8080` and verify it is saved as `http://localhost:8080/api/v1`. ### Implementation for User Story 3 - [x] T007 [P] [US3] Relax `base_url` validation and add normalization in `superset_tool/models.py` - [x] T008 [US3] Add unit tests for `SupersetConfig` URL normalization in `backend/tests/test_models.py` **Checkpoint**: All user stories should now be independently functional --- ## Phase 6: Polish & Cross-Cutting Concerns **Purpose**: Improvements that affect multiple user stories - [x] T009 [P] Update `docs/settings.md` with new URL validation behavior - [ ] T010 Run full verification suite per `quickstart.md` --- ## 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) - May integrate with US1 but should be independently testable - **User Story 3 (P3)**: Can start after Foundational (Phase 2) - May integrate with US1/US2 but should be independently testable ### Parallel Opportunities - All Setup tasks marked [P] can run in parallel - All Foundational tasks marked [P] can run in parallel (within Phase 2) - Once Foundational phase completes, all user stories can start in parallel - Models within a story marked [P] can run in parallel --- ## Parallel Example: User Story 1 ```bash # Launch all models for User Story 1 together: Task: "Verify Tailwind directives in frontend/src/app.css" ``` --- ## 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 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