## Test Scenario: Rapid session starts generate unique session IDs

**Severity:** silent-wrongness

**Feature:** Feature-001 (session creation & idempotency)

**Setup:**

Marcus (work-tracking persona) has automated scripts or a test harness that rapidly fires multiple POST /sessions/start requests in parallel (simulating network retry or accidental double-tap on "Start Session" button that both succeed before the first response is rendered).

**Trigger:**

10 requests to POST /sessions/start are fired within 10 milliseconds (simulating rapid concurrent clicks or network library retry logic):

```
t=0ms:   POST /sessions/start (focus, 1500s, 300s)
t=1ms:   POST /sessions/start (focus, 1500s, 300s)
t=2ms:   POST /sessions/start (focus, 1500s, 300s)
...
t=9ms:   POST /sessions/start (focus, 1500s, 300s)
```

All 10 requests are received and processed by the backend concurrently (or in rapid succession).

**Expected:**

All 10 responses return 200 OK, each with a **unique** session_id:
```
Response 1: { session_id: "uuid-a", phase: "focus", ... }
Response 2: { session_id: "uuid-b", phase: "focus", ... }
Response 3: { session_id: "uuid-c", phase: "focus", ... }
...
Response 10: { session_id: "uuid-j", phase: "focus", ... }
```

All session_ids are distinct (no duplicates). No error, no conflict.

**Concern:**

Session ID generation race condition. If backend generates session_id (not frontend):
1. **Non-unique IDs:** Two requests assigned the same session_id due to insufficient entropy or clock granularity in the ID-generation algorithm (e.g., timestamp-based ID where clock doesn't tick between requests)
2. **Blocking contention:** Requests try to acquire a lock for ID generation; some requests time out or are rejected
3. **ID collision:** UUID v1 (time-based) has a collision risk if not seeded with uniqueness guarantees; UUID v4 (random) should be safe but depends on RNG quality

If frontend generates session_id (per contract-002 assumption):
- This concern is minimized (UUID v4 at 128-bit has negligible collision risk)
- Backend just stores what's received; any race is on the **completion** side, not the start side

**Property:**

For any set of concurrent POST /sessions/start requests (with the same or different users):
- Each response includes a session_id that is unique across all responses
- No two session_ids in the system are identical
- No requests are rejected or return error due to ID collision

If session_ids are generated by backend:
- ID generation must be thread-safe and use a true CSPRNG (cryptographically secure random)
- UUID v4 or similar (128-bit randomness minimum)

If session_ids are generated by frontend:
- Backend should accept UUIDs and store them as-is
- Backend should not attempt to re-generate or validate the format strictly (to allow for future formats)

**Mechanism:**

Backend should:
1. Use UUID v4 (random) if generating IDs, not UUID v1 (time-based) or sequential IDs
2. Ensure ID generation is thread-safe (use a library, not custom code)
3. If IDs are generated by frontend, just store them as opaque strings (backend doesn't validate format)
4. Uniqueness is enforced at the database level: (user_id, session_id) is a candidate key or primary key

**Implies:**

- Contract-002 assumption: frontend generates session_id. If this is wrong (backend generates), test needs adjustment
- Performance test: concurrent start requests should complete without blocking (no lock contention)

**Runnable Test:**

- `tests/test_feature_001_session_id_generation.py::test_rapid_concurrent_session_starts_generate_unique_ids`
- `tests/test_feature_001_session_id_generation.py::test_ten_parallel_post_sessions_start_requests_all_succeed`
