256 lines
12 KiB
Markdown
256 lines
12 KiB
Markdown
---
|
|
description: "Task list for Fitbit-Garmin Local Sync implementation"
|
|
---
|
|
|
|
# Tasks: Fitbit-Garmin Local Sync
|
|
|
|
**Input**: Design documents from `/specs/001-fitbit-garmin-sync/`
|
|
**Prerequisites**: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/
|
|
|
|
**Tests**: The examples below include test tasks. Tests are OPTIONAL - only include them if explicitly requested in the feature specification.
|
|
|
|
**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
|
|
|
|
- **Single project**: `src/`, `tests/` at repository root
|
|
- **Web app**: `backend/src/`, `frontend/src/`
|
|
- **Mobile**: `api/src/`, `ios/src/` or `android/src/`
|
|
- Paths shown below assume single project - adjust based on plan.md structure
|
|
|
|
## Phase 1: Setup (Shared Infrastructure)
|
|
|
|
**Purpose**: Project initialization and basic structure
|
|
|
|
- [x] T001 Create project structure per implementation plan in backend/
|
|
- [x] T002 Initialize Python 3.11 project with FastAPI, SQLAlchemy, garminconnect, garth, fitbit dependencies in requirements.txt
|
|
- [x] T003 [P] Configure linting and formatting tools (black, flake8) in pyproject.toml
|
|
|
|
---
|
|
|
|
## 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 Setup database schema and migrations framework using SQLAlchemy in backend/src/models/
|
|
- [x] T005 [P] Create base models (Configuration, API Token) in backend/src/models/config.py and backend/src/models/api_token.py
|
|
- [x] T006 [P] Setup API routing and middleware structure in backend/main.py
|
|
- [x] T007 Create database manager for PostgreSQL in backend/src/services/postgresql_manager.py
|
|
- [x] T008 Configure error handling and logging infrastructure in backend/src/utils/
|
|
- [x] T009 Setup environment configuration management in backend/src/utils/
|
|
- [x] T010 Create FastAPI app structure with proper routing in backend/main.py
|
|
- [x] T011 Setup Docker configuration with PostgreSQL in backend/Dockerfile and backend/docker-compose.yml
|
|
|
|
**Checkpoint**: Foundation ready - user story implementation can now begin in parallel
|
|
|
|
---
|
|
|
|
## Phase 3: User Story 1 - Sync Weight Data from Fitbit to Garmin (Priority: P1) 🎯 MVP
|
|
|
|
**Goal**: User can transfer weight data from Fitbit to Garmin without duplicating entries, with a web interface to trigger the sync.
|
|
|
|
**Independent Test**: Can be fully tested by configuring Fitbit and Garmin credentials, triggering a weight sync, and verifying weight entries appear in Garmin without duplication. Delivers core value of unified health data.
|
|
|
|
### Tests for User Story 1 (OPTIONAL - only if tests requested) ⚠️
|
|
|
|
> **NOTE: Write these tests FIRST, ensure they FAIL before implementation**
|
|
|
|
- [ ] T012 [P] [US1] Contract test for /api/sync/weight endpoint in backend/tests/contract/test_weight_sync.py
|
|
- [ ] T013 [P] [US1] Integration test for weight sync flow in backend/tests/integration/test_weight_sync_flow.py
|
|
|
|
### Implementation for User Story 1
|
|
|
|
- [x] T014 [P] [US1] Create Weight Record model in backend/src/models/weight_record.py
|
|
- [x] T015 [P] [US1] Create Sync Log model in backend/src/models/sync_log.py
|
|
- [x] T016 [US1] Implement Fitbit Client service in backend/src/services/fitbit_client.py
|
|
- [x] T017 [US1] Implement Garmin Client service in backend/src/services/garmin_client.py
|
|
- [x] T018 [US1] Implement weight sync logic in backend/src/services/sync_app.py
|
|
- [x] T019 [US1] Implement weight sync API endpoint in backend/src/api/sync.py
|
|
- [x] T020 [US1] Create status API endpoint in backend/src/api/status.py
|
|
- [x] T021 [US1] Add web UI for weight sync in backend/templates/index.html
|
|
- [x] T022 [US1] Add logging for weight sync operations in backend/src/utils/helpers.py
|
|
|
|
**Checkpoint**: At this point, User Story 1 should be fully functional and testable independently
|
|
|
|
---
|
|
|
|
## Phase 4: User Story 2 - Archive Activity Files from Garmin (Priority: P2)
|
|
|
|
**Goal**: User can download and archive Garmin activity files (.fit, .gpx, .tcx) to a local directory structure with proper organization.
|
|
|
|
**Independent Test**: Can be tested by triggering the activity archiving process and verifying original activity files are downloaded to the specified local directory with proper organization.
|
|
|
|
### Tests for User Story 2 (OPTIONAL - only if tests requested) ⚠️
|
|
|
|
- [ ] T023 [P] [US2] Contract test for /api/sync/activities endpoint in backend/tests/contract/test_activities_sync.py
|
|
- [ ] T024 [P] [US2] Integration test for activity archiving flow in backend/tests/integration/test_activity_flow.py
|
|
|
|
### Implementation for User Story 2
|
|
|
|
- [x] T025 [P] [US2] Create Activity Metadata model in backend/src/models/activity.py
|
|
- [x] T026 [US2] Extend Garmin Client service with activity download methods in backend/src/services/garmin_client.py
|
|
- [x] T027 [US2] Implement activity archiving logic in backend/src/services/sync_app.py
|
|
- [x] T028 [US2] Implement activity sync API endpoint in backend/src/api/sync.py
|
|
- [x] T029 [US2] Add activity list endpoint in backend/src/api/activities.py
|
|
- [x] T030 [US2] Update web UI to include activity archiving in backend/templates/index.html
|
|
- [x] T031 [US2] Add logging for activity archiving operations in backend/src/utils/helpers.py
|
|
|
|
**Checkpoint**: At this point, User Stories 1 AND 2 should both work independently
|
|
|
|
---
|
|
|
|
## Phase 5: User Story 3 - Download Comprehensive Health Metrics from Garmin (Priority: P3)
|
|
|
|
**Goal**: User can download and store comprehensive health metrics from Garmin in a local database with API endpoints for querying.
|
|
|
|
**Independent Test**: Can be tested by triggering the metrics download and verifying that various types of health metrics are stored in the database with proper timestamps and types.
|
|
|
|
### Tests for User Story 3 (OPTIONAL - only if tests requested) ⚠️
|
|
|
|
- [ ] T032 [P] [US3] Contract test for /api/metrics endpoints in backend/tests/contract/test_metrics_api.py
|
|
- [ ] T033 [P] [US3] Integration test for health metrics download flow in backend/tests/integration/test_metrics_flow.py
|
|
|
|
### Implementation for User Story 3
|
|
|
|
- [x] T034 [P] [US3] Create Health Metric model in backend/src/models/health_metric.py
|
|
- [x] T035 [US3] Extend Garmin Client service with comprehensive metrics download methods in backend/src/services/garmin_client.py
|
|
- [x] T036 [US3] Implement health metrics download logic in backend/src/services/sync_app.py
|
|
- [x] T037 [US3] Implement metrics list and query endpoints in backend/src/api/metrics.py
|
|
- [x] T038 [US3] Implement health data summary endpoint in backend/src/api/metrics.py
|
|
- [x] T039 [US3] Add UI elements for metrics management in backend/templates/
|
|
- [x] T040 [US3] Add logging for metrics download operations in backend/src/utils/helpers.py
|
|
|
|
**Checkpoint**: All user stories should now be independently functional
|
|
|
|
---
|
|
|
|
## Phase 6: Setup API Endpoints for Configuration (Cross-cutting)
|
|
|
|
**Goal**: Implement configuration and authentication endpoints that support all user stories
|
|
|
|
- [x] T041 [P] Create setup API endpoints in backend/src/api/setup.py
|
|
- [x] T042 [P] Implement Garmin credentials save endpoint in backend/src/api/setup.py
|
|
- [x] T043 [P] Implement Fitbit credentials save and auth URL endpoint in backend/src/api/setup.py
|
|
- [x] T044 [P] Implement Fitbit OAuth callback endpoint in backend/src/api/setup.py
|
|
- [x] T045 Create logs endpoint in backend/src/api/logs.py
|
|
- [x] T046 Update UI with setup page in backend/templates/setup.html
|
|
- [x] T047 [P] Create auth status model in backend/src/models/auth_status.py
|
|
- [x] T048 [P] Create auth status API endpoint in backend/src/api/setup.py
|
|
|
|
---
|
|
|
|
## Phase 7: Polish & Cross-Cutting Concerns
|
|
|
|
**Purpose**: Improvements that affect multiple user stories
|
|
|
|
- [x] T047 [P] Documentation updates in backend/README.md
|
|
- [ ] T048 Code cleanup and refactoring
|
|
- [ ] T049 Performance optimization across all stories
|
|
- [ ] T050 [P] Additional unit tests (if requested) in backend/tests/unit/
|
|
- [ ] T051 Security hardening for OAuth token storage and API access
|
|
- [ ] T052 Run quickstart.md validation
|
|
- [ ] T053 Final integration testing across all features
|
|
- [x] T054 Update Docker configuration with all required services
|
|
- [x] T055 Create setup guide in backend/docs/setup.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)
|
|
- **Configuration Phase (Phase 6)**: Can proceed in parallel with user stories but may be needed first
|
|
- **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
|
|
|
|
### Within Each User Story
|
|
|
|
- Tests (if included) MUST be written and FAIL before implementation
|
|
- Models before services
|
|
- Services before endpoints
|
|
- Core implementation before integration
|
|
- Story complete before moving to next priority
|
|
|
|
### 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 (if team capacity allows)
|
|
- All tests for a user story marked [P] can run in parallel
|
|
- Models within a story marked [P] can run in parallel
|
|
- Different user stories can be worked on in parallel by different team members
|
|
|
|
---
|
|
|
|
## Parallel Example: User Story 1
|
|
|
|
```bash
|
|
# Launch all tests for User Story 1 together (if tests requested):
|
|
Task: "Contract test for /api/sync/weight endpoint in backend/tests/contract/test_weight_sync.py"
|
|
Task: "Integration test for weight sync flow in backend/tests/integration/test_weight_sync_flow.py"
|
|
|
|
# Launch all models for User Story 1 together:
|
|
Task: "Create Weight Record model in backend/src/models/weight_record.py"
|
|
Task: "Create Sync Log model in backend/src/models/sync_log.py"
|
|
```
|
|
|
|
---
|
|
|
|
## 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
|
|
|
|
### Parallel Team Strategy
|
|
|
|
With multiple developers:
|
|
|
|
1. Team completes Setup + Foundational together
|
|
2. Once Foundational is done:
|
|
- Developer A: User Story 1
|
|
- Developer B: User Story 2
|
|
- Developer C: User Story 3
|
|
3. Stories complete and integrate independently
|
|
|
|
---
|
|
|
|
## Notes
|
|
|
|
- [P] tasks = different files, no dependencies
|
|
- [Story] label maps task to specific user story for traceability
|
|
- Each user story should be independently completable and testable
|
|
- Verify tests fail before implementing
|
|
- Commit after each task or logical group
|
|
- Stop at any checkpoint to validate story independently
|
|
- Avoid: vague tasks, same file conflicts, cross-story dependencies that break independence |