busya/ss-tools
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
006-configurable-belief-logs
ss-tools/specs/003-project-launch-script/tasks.md

4.7 KiB
Raw Permalink Blame History

description
description
Task list for Project Launch Script implementation

Tasks: Project Launch Script

Input: Design documents from /specs/003-project-launch-script/ Prerequisites: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/

Tests: Manual verification as per spec.md. No automated test suite requested for this utility script.

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/, run.sh at root

Phase 1: Setup (Shared Infrastructure)

Purpose: Project initialization and basic structure

  • T001 Create run.sh with basic structure and --help message in run.sh
  • T002 [P] Implement environment validation for python3 (3.9+) and npm in run.sh

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

  • T003 Implement backend dependency check and installation logic (venv + requirements.txt) in run.sh
  • T004 Implement frontend dependency check and installation logic (node_modules) in run.sh
  • T005 Implement SIGINT trap and cleanup function for graceful shutdown in run.sh

Checkpoint: Foundation ready - user story implementation can now begin

Phase 3: User Story 1 - Launch Project (Priority: P1) 🎯 MVP

Goal: Launch backend and frontend concurrently with dependency management and graceful shutdown.

Independent Test: Run ./run.sh from root. Verify both services start, are accessible on their ports, and both stop when Ctrl+C is pressed.

Implementation for User Story 1

  • T006 [US1] Implement backend server startup logic with BACKEND_PORT support in run.sh
  • T007 [US1] Implement frontend server startup logic with FRONTEND_PORT support in run.sh
  • T008 [US1] Implement concurrent execution using background processes and wait in run.sh
  • T009 [US1] Implement --skip-install flag logic to bypass dependency checks in run.sh

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

Phase 4: Polish & Cross-Cutting Concerns

Purpose: Improvements that affect multiple user stories

  • T010 [P] Add color-coded logging to distinguish between backend and frontend output in run.sh
  • T011 [P] Update project README.md with run.sh usage instructions
  • T012 Run quickstart.md validation for run.sh

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
  • 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

Within Each User Story

  • Core implementation before integration
  • Story complete before moving to next priority

Parallel Opportunities

  • T002 can run in parallel with T001 (though both edit run.sh, they are logically independent)
  • T010, T011 can run in parallel

Parallel Example: User Story 1

# Implementation tasks for User Story 1 are mostly sequential in run.sh
# but can be developed in separate blocks:
Task: "Implement backend server startup logic with BACKEND_PORT support in run.sh"
Task: "Implement frontend server startup logic with FRONTEND_PORT support in run.sh"

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. Each story adds value without breaking previous stories

Notes

  • [P] tasks = different files or independent logic blocks
  • [Story] label maps task to specific user story for traceability
  • Each user story should be independently completable and testable
  • Commit after each task or logical group
  • Stop at any checkpoint to validate story independently