### Endpoints for initiating Garmin Connect authentication and linking

**Decision**: Authentication with Garmin Connect will utilize the direct email/password method as implemented in the existing `GarminClient` within `GarminAnalyser.md`. This leverages the `garminconnect` library.
**Rationale**: Adherence to existing project patterns and reuse of proven authentication mechanisms.
**Alternatives considered**: Implementing full OAuth2 flow was considered but deferred to maintain consistency with existing `GarminAnalyser.md` logic and simplify initial implementation.

### Endpoint for initiating workout uploads to Garmin Connect

**Decision**: Introduce a new API endpoint, `POST /api/sync/garmin/workouts`, which accepts a workout identifier (e.g., `workout_id` from CentralDB) and triggers an asynchronous workout upload to Garmin Connect. The `garminconnect` library will be used for the actual interaction with Garmin's API.

**Rationale**: The "Technical Context" explicitly states the requirement for workout uploads and mentions "Workout" as a key entity stored in CentralDB. Implementing a dedicated API endpoint ensures clear separation of concerns and provides a standardized way for the frontend or other services to initiate this action. Asynchronous processing is crucial for long-running operations like API calls to external services, maintaining responsiveness of the main application. The `garminconnect` library is the logical choice for this integration given its existing use for activity downloads and its purpose as a Garmin API client.

**Alternatives considered**:
*   **Batch upload endpoint**: While potentially useful, starting with a single workout upload endpoint is simpler and can be scaled to batch operations later if needed.
*   **Direct database trigger**: Allowing direct database manipulation to trigger uploads would bypass the API layer, leading to less maintainable and less secure architecture. The API endpoint centralizes control and validation.