mirror of
https://github.com/sstent/FitTrack_GarminSync.git
synced 2026-01-25 16:41:41 +00:00
sstent
2f0b5e6bad
This commit implements the multi-factor authentication (MFA) flow for the CLI using the garth library, as specified in task 007. Changes include: - Created to handle API communication with robust error handling. - Refactored to correctly implement the logout logic and ensure proper handling of API client headers. - Updated with Black, Flake8, Mypy, and Isort configurations. - Implemented and refined integration tests for authentication, sync operations, and sync status checking, including mocking for the API client. - Renamed integration test files for clarity and consistency. - Updated to reflect task completion.
221 lines
10 KiB
Markdown
221 lines
10 KiB
Markdown
---
|
|
description: "Task list for MFA authentication flow with garth integration"
|
|
---
|
|
|
|
# Tasks: Update Authentication Flow for MFA with garth
|
|
|
|
**Input**: Design documents from `/specs/007-update-the-authentication/`
|
|
**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 in cli/ directory following implementation plan
|
|
- [x] T002 Set up Python 3.13 virtual environment and install required dependencies (Click, httpx, pydantic, pytest, garth, garminconnect)
|
|
- [x] T003 Create requirements.txt with pinned dependencies following constitution standards
|
|
- [x] T004 Create pyproject.toml with Black, Flake8, Mypy, Isort configurations
|
|
- [x] T005 [P] Create initial directory structure (src/, models/, services/, commands/, utils/, tests/)
|
|
|
|
---
|
|
|
|
## 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] T006 Create base data models for User Session, Sync Job, and Authentication Token in src/models/
|
|
- [x] T007 [P] Implement API client to interact with backend API endpoints in src/api/client.py
|
|
- [x] T008 [P] Create configuration management utilities for YAML config in src/utils/config.py
|
|
- [x] T009 [P] Implement token management with secure local storage in src/auth/token_manager.py
|
|
- [x] T010 Create output formatting utilities (JSON, table, CSV) in src/utils/output.py
|
|
- [x] T011 [P] Implement CLI entry point with base command structure in src/main.py
|
|
|
|
**Checkpoint**: Foundation ready - user story implementation can now begin in parallel
|
|
|
|
---
|
|
|
|
## Phase 3: User Story 1 - Text-Based Authentication with MFA (Priority: P1) 🎯 MVP
|
|
|
|
**Goal**: Implement authentication functionality via text-based interface with MFA support so users can securely access the system.
|
|
|
|
**Independent Test**: Can be fully tested by running the authentication command with both standard credentials and MFA-enabled accounts, and verifying the system properly validates credentials and handles MFA flows.
|
|
|
|
### Tests for User Story 1 (OPTIONAL - only if tests requested) ⚠️
|
|
|
|
**NOTE: Write these tests FIRST, ensure they FAIL before implementation**
|
|
|
|
- [x] T012 [P] [US1] Contract test for auth endpoint in tests/contract/test_auth_api.py
|
|
- [x] T013 [P] [US1] Integration test for auth flow in tests/integration/test_auth_flow.py
|
|
|
|
### Implementation for User Story 1
|
|
|
|
- [x] T014 [US1] Create AuthManager class to handle authentication flows with MFA support in src/auth/auth_manager.py
|
|
- [x] T015 [US1] Implement MFA handling functionality in AuthManager
|
|
- [x] T016 [US1] Create authentication command implementation in src/commands/auth_cmd.py
|
|
- [x] T017 [US1] Add interactive authentication mode with secure input prompts
|
|
- [x] T018 [US1] Implement token validation and refresh logic
|
|
- [x] T019 [US1] Add error handling for authentication failures
|
|
- [x] T020 [US1] [P] Write unit tests for authentication manager in tests/unit/test_auth_manager.py
|
|
- [x] T021 [US1] [P] Write integration tests for authentication flows in tests/integration/test_auth_flow.py
|
|
|
|
**Checkpoint**: At this point, User Story 1 should be fully functional and testable independently
|
|
|
|
---
|
|
|
|
## Phase 4: User Story 2 - Trigger Sync Operations via Text Interface (Priority: P2)
|
|
|
|
**Goal**: Implement functionality to trigger sync operations from text-based interface so users can initiate data synchronization without using the web interface.
|
|
|
|
**Independent Test**: Can be fully tested by authenticating and then running the sync trigger command, and verifying that the sync process is initiated in the backend system.
|
|
|
|
### Tests for User Story 2 (OPTIONAL - only if tests requested) ⚠️
|
|
|
|
- [x] T022 [P] [US2] Contract test for sync trigger endpoint in tests/contract/test_sync_trigger.py
|
|
- [x] T023 [P] [US2] Integration test for sync triggering in tests/integration/test_sync_operations.py
|
|
|
|
### Implementation for User Story 2
|
|
|
|
- [x] T024 [US2] Create SyncCommand class to handle sync triggering functionality in src/commands/sync_cmd.py
|
|
- [x] T025 [US2] Implement sync trigger API call functionality
|
|
- [x] T026 [US2] Add support for different sync types (activities, health, workouts)
|
|
- [x] T027 [US2] Implement date range and full sync options
|
|
- [x] T028 [US2] Add authentication validation before sync triggers
|
|
- [x] T029 [US2] Handle sync conflict detection (concurrent sync requests)
|
|
- [x] T030 [US2] [P] Write unit tests for sync command functionality in tests/unit/test_commands.py
|
|
- [x] T031 [US2] [P] Write integration tests for sync triggering in tests/integration/test_sync_operations.py
|
|
|
|
**Checkpoint**: At this point, User Stories 1 AND 2 should both work independently
|
|
|
|
---
|
|
|
|
## Phase 5: User Story 3 - Check Sync Status via Text Interface (Priority: P3)
|
|
|
|
**Goal**: Implement functionality to check sync operation status from text-based interface so users can monitor data synchronization progress.
|
|
|
|
**Independent Test**: Can be fully tested by triggering a sync and then checking its status via the text interface, with various sync states being properly reported.
|
|
|
|
### Tests for User Story 3 (OPTIONAL - only if tests requested) ⚠️
|
|
|
|
- [x] T032 [P] [US3] Contract test for sync status endpoint in tests/contract/test_sync_status.py
|
|
- [x] T033 [P] [US3] Integration test for status checking in tests/integration/test_sync_status.py
|
|
|
|
### Implementation for User Story 3
|
|
|
|
- [x] T034 [US3] Create StatusCommand class to handle sync status checking in src/commands/sync_cmd.py
|
|
- [x] T035 [US3] Implement sync status API call functionality
|
|
- [x] T036 [US3] Add support for retrieving specific job status by ID
|
|
- [x] T037 [US3] Format status output in multiple formats (table, JSON, CSV)
|
|
- [x] T038 [US3] Handle status requests for non-existent sync jobs
|
|
- [x] T039 [US3] [P] Write unit tests for status command functionality in tests/unit/test_commands.py
|
|
- [x] T040 [US3] [P] Write integration tests for status checking in tests/integration/test_sync_status.py
|
|
|
|
**Checkpoint**: All user stories should now be independently functional
|
|
|
|
---
|
|
|
|
## Phase N: Polish & Cross-Cutting Concerns
|
|
|
|
**Purpose**: Improvements that affect multiple user stories
|
|
|
|
- [x] T041 [P] Documentation updates in docs/
|
|
- [x] T042 Code cleanup and refactoring
|
|
- [x] T043 Performance optimization across all stories
|
|
- [x] T044 [P] Additional unit tests (if requested) in tests/unit/
|
|
- [x] T045 Security hardening
|
|
- [x] T046 Run quickstart.md validation
|
|
|
|
---
|
|
|
|
## 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) - Depends on US1 authentication
|
|
- **User Story 3 (P3)**: Can start after Foundational (Phase 2) - Depends on US1 authentication
|
|
|
|
### 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
|
|
|
|
---
|
|
|
|
## 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 (after authentication component ready)
|
|
- Developer C: User Story 3 (after authentication component ready)
|
|
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 |