docs(sprints): regenerate sprint 3 briefings from database

Previous briefings referenced tickets not assigned to sprint 3.
Rewrote all four team briefings (server, client, joint, copy) to
match actual sprint 3 ticket assignments in the database.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/sprints/sprint-3/client.md

@@ -1,16 +1,15 @@
-# Sprint 3: Know — Client Tasks
+# Sprint 3: Content Foundation — Client Tasks
 
-**Goal:** Player character can observe NPCs, track their knowledge, and interact with the environment through a working observation event pipeline.
+**Goal:** Build client-side interaction infrastructure to support v0.1 gameplay.
 
 **Branch:** `client`
 **Agents:** Stig (UI), Tyre (architecture), Hoshe (QA)
 
 ## Tickets
 
-| # | Title | Blocked by |
-|---|-------|------------|
-| #345 | Fix entity_renderer.gd field name bug (id vs entity_id) | — |
-| #240 | Player interaction system and dispatcher | — |
+| # | Title | Priority | Blocked by |
+|---|-------|----------|------------|
+| #405 | Interaction prompt — client extensible prompt system | high | #404 |
 
 Use `db/connectors/ticket show <id>` for full details.
 
@@ -22,33 +21,38 @@ Use `db/connectors/ticket show <id>` for full details.
 
 ## Notes
 
-**#345 (Critical bug fix):**
-- **Context:** Line 26 of `client/scripts/rendering/entity_renderer.gd` checks `entity_data.has("entity_id")` (correct per Protocol v2), but this was identified as a field name bug in the Architecture Review Audit. Verify the check is correct and that entities render properly. If the bug is real, the fix is trivial (XS effort). If entities already render, mark done and document why the audit flagged it incorrectly.
-- **File:** `/var/home/jeroenschweitzer/Projects/settled-reach/main/client/scripts/rendering/entity_renderer.gd`
-- Start with this — it's blocking basic entity rendering if the bug is real.
+**#405 (Interaction prompt system):**
 
-**#240 (Interaction system):**
-- **Context:** General-purpose interaction dispatcher that routes player Interact input to appropriate subsystems. Currently there is no interaction system — player can move but not interact with anything.
-- **Routing logic:**
-  - NPC → dialogue (Sprint 4+, stub for now)
-  - Object → examine (Sprint 4+, stub for now)
-  - Door → open/close (Sprint 4+, stub for now)
-  - Terminal → info access (Sprint 4+, stub for now)
-- **Implementation:** Add `Interactable` component concept on server side. Client sends `Interact` input when player presses interact key near an entity. Server dispatcher checks entity type and routes to appropriate handler. For Sprint 3: infrastructure only, all handlers return placeholder text.
-- **Files:**
-  - Server: `server/src/simulation/interaction.rs` (new module)
-  - Client: `client/scripts/autoloads/input_mapper.gd` (add interact key binding)
-- **Integration:** Builds on existing input system (`server/src/simulation/input.rs`, `client/scripts/autoloads/input_mapper.gd`). New input type: `PlayerInput::Interact { target_entity: Option<u64> }`.
-- This is foundation work for dialogue (#168, Sprint 4+) and follow/examine mechanics (#241, #242, Sprint 4+).
+Client-side interaction prompt designed for extensibility from day one. v0.1 implementation: single context-sensitive "E" prompt (pick first available verb). Architecture supports v0.2 multi-verb radial menu (show all available verbs from server).
+
+**Context:** This is a new system — currently the player can move but cannot interact with NPCs, objects, or environment. This ticket adds the UI layer that receives `InteractionOptions` data from the server (via ObserverSnapshot v3, ticket #404) and displays the appropriate prompt.
+
+**v0.1 behavior:**
+- Server sends `InteractionOptions { verbs: ["Talk", "Examine"] }` for an NPC in proximity
+- Client picks first verb ("Talk") and displays "E - Talk to [NPC Name]"
+- Player presses E → client sends interaction request to server
+
+**v0.2 behavior (architecture must support this):**
+- Client displays radial menu with all verbs
+- Player selects verb → client sends specific verb + target to server
+
+**Separation of concerns:** This is NOT ticket #240 (Player interaction system and dispatcher). #240 was the general-purpose dispatcher infrastructure. This ticket (#405) is specifically the UI prompt system that reads `InteractionOptions` from server state and displays context-sensitive interaction prompts. Different team, different scope, different definition of done.
+
+**Files:**
+- `client/scripts/ui/interaction_prompt.gd` (new UI component)
+- `client/scripts/protocol/local_bridge.gd` (read InteractionOptions from ObserverSnapshot v3)
+
+**Blocked by #404:** Cannot implement until server sends `InteractionOptions` data via ObserverSnapshot v3 protocol extension.
+
+**Integration:** Reads from existing IPC bridge. Display layer only — no game logic. All interaction logic stays on server side (ticket #404).
 
 ## Dependency Chain
 
 ```
-#345 (bug fix) → standalone, critical for entity rendering
-#240 (interaction dispatcher) → #168, #241, #242 (Sprint 4+ dialogue/mechanics)
+#404 (server: proximity + InteractionOptions) → #405 (client: interaction prompt)
 ```
 
-Both tickets are independent and can run in parallel if multiple agents are available.
+Single ticket this sprint. Start as soon as #404 (server) is complete.
 
 ## PR Workflow