ss-tools/specs/001-fix-ui-ws-validation/tasks.md

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

• 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

• 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

• T003 [P] [US1] Verify Tailwind directives in frontend/src/app.css
• 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

• T005 [P] [US2] Implement WebSocket URL fallback logic in frontend/src/lib/api.js
• 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

• T007 [P] [US3] Relax base_url validation and add normalization in superset_tool/models.py
• 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

• 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

# 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