busya/ss-tools
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
43b4c75e36cccccadb892e1f438d965530281d41
ss-tools/specs/005-fix-ui-ws-validation/tasks.md
busya 43b4c75e36 worked backup
2025-12-21 00:16:12 +03:00

5.8 KiB
Raw Blame History

Tasks: Fix UI Styling, WebSocket Port Mismatch, and URL Validation

Input: Design documents from /specs/005-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

Phase 7: Addressing Requirements Gaps (from ws-connection.md)

Purpose: Close gaps identified during requirements quality review to ensure robust WebSocket communication.

  • T011 [US2] Resolve WebSocket endpoint path conflict between contract and implementation (Contract: /ws/logs/{id} vs Actual: /ws/logs/{id})
  • T012 [US2] Implement environment-aware protocol selection (ws vs wss) based on PUBLIC_WS_URL
  • T013 [US2] Implement robust exponential backoff with specific initial delays and max retry counts
  • T014 [US2] Add UI handling for "Partial Log" and "Task Completed" WebSocket states in TaskRunner.svelte
  • T015 [US2] Implement backend port availability check and user-friendly error reporting in the frontend

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