## ADDED Requirements

### Requirement: User-scoped chart creation
When a chart is created (via CSV upload), the system SHALL associate it with the authenticated user's ID. The `charts` table row SHALL have `user_id` set to the current user's UUID.

#### Scenario: Upload creates user-scoped chart
- **WHEN** an authenticated user uploads a CSV file
- **THEN** the created chart record has `user_id` set to the authenticated user's ID

#### Scenario: User sees only their charts
- **WHEN** an authenticated user requests their chart list
- **THEN** only charts with `user_id` matching the authenticated user are returned

### Requirement: User-scoped annotations
All annotation operations (create, read, delete) SHALL be filtered by the authenticated user's ID. Annotations SHALL only be visible to the user who created them.

#### Scenario: Create annotation scoped to user
- **WHEN** an authenticated user creates an annotation
- **THEN** the annotation record has `user_id` set to the authenticated user's ID

#### Scenario: Read annotations filtered by user
- **WHEN** an authenticated user requests annotations for a chart
- **THEN** only annotations belonging to that user (and that chart) are returned

#### Scenario: Delete annotation ownership check
- **WHEN** an authenticated user attempts to delete an annotation
- **THEN** the deletion only succeeds if the annotation belongs to the authenticated user

### Requirement: User-scoped span annotations
All span annotation operations SHALL be filtered by the authenticated user's ID via the chart's `user_id`.

#### Scenario: Create span annotation scoped to user
- **WHEN** an authenticated user creates a span annotation on their chart
- **THEN** the span annotation is created and associated with the user's chart

#### Scenario: Read span annotations filtered by user
- **WHEN** an authenticated user requests span annotations
- **THEN** only span annotations on charts belonging to that user are returned

### Requirement: User-scoped annotation types
Each user SHALL have their own set of annotation types. The `annotation_types` table SHALL be filtered by `user_id`. The unique constraint on `name` SHALL be changed to a composite unique constraint on `(user_id, name)`.

#### Scenario: User-specific annotation types
- **WHEN** an authenticated user requests their annotation types
- **THEN** only annotation types with `user_id` matching the authenticated user are returned

#### Scenario: Two users with same annotation type name
- **WHEN** two different users each create an annotation type named "break_up"
- **THEN** both records are stored without conflict (unique per user, not globally)

### Requirement: User-scoped span label types
Each user SHALL have their own set of span label types. The `span_label_types` table SHALL be filtered by `user_id`. The unique constraint on `name` SHALL be changed to a composite unique constraint on `(user_id, name)`.

#### Scenario: User-specific span label types
- **WHEN** an authenticated user requests their span label types
- **THEN** only span label types with `user_id` matching the authenticated user are returned

### Requirement: Default data seeding on registration
When a new user registers, the system SHALL seed default annotation types and span label types for that user. The defaults SHALL include: annotation types `break_up` (green, marker), `break_down` (red, marker), `line` (blue, line); and a starter set of span label types.

#### Scenario: New user gets default annotation types
- **WHEN** a new user is created (via registration or first Google sign-in)
- **THEN** default annotation types (break_up, break_down, line) are inserted with the new user's ID

#### Scenario: New user gets default span label types
- **WHEN** a new user is created
- **THEN** default span label types are inserted with the new user's ID

### Requirement: ML service user context
When the Next.js API proxies requests to the FastAPI ML service, it SHALL include the `X-User-ID` header with the authenticated user's UUID. The ML service SHALL use this header to scope training runs, model storage, and experiments.

#### Scenario: Training request includes user ID
- **WHEN** an authenticated user starts a training run via `/api/training/start`
- **THEN** the proxy request to FastAPI includes `X-User-ID: <user-uuid>` header

#### Scenario: Prediction request includes user ID
- **WHEN** an authenticated user requests prediction via `/api/predict`
- **THEN** the proxy request to FastAPI includes `X-User-ID: <user-uuid>` header

#### Scenario: ML service scopes by user
- **WHEN** the FastAPI service receives a request with `X-User-ID` header
- **THEN** training runs and model lookups are scoped to that user ID