## Test Scenario: Two completion events POSTed rapidly, race on session_id

**Severity:** silent-wrongness

**Feature:** Feature-001 (Start and complete a focus session with breaks)

**Setup:**

User completes a 25-minute focus session. Frontend immediately POSTs the session completion event to `/sessions`. Network latency is high; the POST is in flight (not yet acknowledged). User immediately starts a 5-minute break and, when it completes, frontend generates another completion event and POSTs it as well. Both POSTs are still pending.

**Trigger:**

Backend receives both POST requests. The requests may arrive out of order due to network timing, or simultaneously. Each completion event is meant to represent a distinct session, but they might collide on `session_id` if frontend reuses IDs on retry or doesn't generate unique IDs per completion.

**Expected:**

Each completion event is recorded with a distinct `session_id`. Backend stores both as separate session facts. When frontend retries either POST (if the first ACK is delayed), the retry is idempotent — it updates the existing session record rather than creating a duplicate.

**Concern:**

Frontend might be generating a single `session_id` shared across multiple sessions, or reusing `session_id` on retry. Backend's composite key `(user_id, session_id, completed_at)` might not be unique if `session_id` isn't guaranteed unique per session. This is silent wrongness: the second session's completion event overwrites the first, or records with the same `session_id` cause a key collision. User data loss is invisible until they export history and notice a missing session.

**Property:**

For all sequences of session completion events POSTed by a client, the set of recorded `session_id` values must be disjoint and match the set of completion events sent, regardless of network delivery order, timing, or retries.

**Implies:**

- The contract (contract-note-002) specifies that `session_id` is returned by the backend in the response, not generated by the frontend. If the implementation has frontend generating `session_id`, this contract assumption is broken and needs renegotiation with Tweedles immediately (M5 blocker).

**Runnable Tests:**

- `tests/test_sessions_core_failures.py::TestConcurrentPostRaceCondition::test_two_rapid_completions_generate_distinct_session_ids`
- `tests/test_sessions_core_failures.py::TestConcurrentPostRaceCondition::test_idempotent_retry_of_same_completion_event_does_not_create_duplicate`
