Approve FS-0007: v0 Two-Client Multiplayer Slice

docs/adr/0006-input-tick-targeting.md

@@ -26,6 +26,7 @@ The Server Edge MUST provide tick guidance to clients, and clients MUST use that
 - The Server Edge MUST emit TargetTickFloor (DM-0025) in ServerWelcome and in each Snapshot (DM-0007).
 - TargetTickFloor MUST be computed as: `server.current_tick + INPUT_LEAD_TICKS` (see [docs/networking/v0-parameters.md](../networking/v0-parameters.md) for v0 value).
 - TargetTickFloor MUST be monotonic non-decreasing per Session (DM-0008); resets on session re-establishment or new MatchId (DM-0021).
+- **v0 Floor Coherency (Normative Constraint):** For v0, Server Edge MUST compute a single `target_tick_floor` value per server tick and broadcast that identical value to all connected sessions for that tick. SnapshotProto payloads MUST be identical across sessions except for any explicitly session-scoped fields. *Rationale: Floor is a match-scoped policy in v0; divergent floors across sessions would create client-side targeting divergence even if the Simulation Core remains deterministic. Post-v0 may introduce per-session floor guidance for lag compensation.*
 - Game Clients MUST target InputCmd.tick values >= TargetTickFloor (clients MUST clamp upward).
 - Game Clients MUST NOT target InputCmd.tick values earlier than TargetTickFloor.
 

docs/constitution/acceptance-kill.md

@@ -28,8 +28,8 @@ ENTRY FORMAT (use H3 with anchor):
 
 **Pass Condition:** The system MUST demonstrate functional end-to-end multiplayer with two connected Game Clients where:
 
-1. **Connectivity & initial authoritative state transfer (JoinBaseline):** Two native Game Clients can connect to a Game Server Instance, complete handshake, receive initial authoritative state, and remain synchronized.
-2. **Gameplay slice (WASD control):** Each Game Client can issue WASD movement inputs; the authoritative simulation processes them; both Game Clients see their own and the opponent's movement via snapshots with acceptable consistency.
+1. **Connectivity & initial authoritative state transfer (JoinBaseline):** Two native Game Clients can connect to a Game Server Instance, complete handshake, receive initial authoritative state (JoinBaseline), and remain synchronized. Clients MUST be able to continuously render authoritative state by applying received JoinBaseline and subsequent Snapshots; in Tier-0 harness, client state MUST equal the last received authoritative Snapshot (where Snapshot.tick indicates post-step tick; no client-side prediction required for v0).
+2. **Gameplay slice (WASD control):** Each Game Client can issue WASD movement inputs; the authoritative simulation processes them; both Game Clients see their own and the opponent's movement via snapshots with acceptable consistency. Each client MUST be able to identify which EntityId (DM-0020) corresponds to its controlled Character (DM-0003) as part of the handshake/initialization (e.g., via controlled_entity_id in ServerWelcome or equivalent binding mechanism).
 3. **Simulation Core boundary integrity:** The authoritative simulation produces identical outcomes for identical input+seed+state across multiple runs (same build/platform), verified by Tier-0 replay test. The Simulation Core MUST NOT perform I/O, networking, rendering, or wall-clock reads (INV-0001, INV-0002, INV-0004).
 4. **Tier-0 input validation:** Server enforces magnitude limit, tick window sanity check, and rate limit (values in [docs/networking/v0-parameters.md](../networking/v0-parameters.md)); input handling per ADR-0006; malformed or out-of-policy inputs are rejected without crashing.
 5. **Replay artifact generation:** A completed match produces a replay artifact (initial state, seed, input stream, final state hash) that can reproduce the authoritative outcome on the same build/platform (INV-0006). "Input stream" means the AppliedInput (DM-0024) stream—the per-tick inputs that were actually applied by the authoritative simulation, not raw InputCmd (DM-0006) traffic.

docs/networking/v0-parameters.md

@@ -14,6 +14,8 @@ These values may change as we iterate, without requiring changes to invariants o
 | max_future_ticks | 120 | Maximum ticks ahead a client can target (InputTickWindow upper bound) |
 | input_tick_window | `[current_tick, current_tick + max_future_ticks]` | Future-only acceptance; late inputs dropped |
 | input_lead_ticks | 1 | TargetTickFloor = server.current_tick + input_lead_ticks |
+| match_duration_ticks | 3600 | Match duration (60 seconds at 60 Hz); defines checkpoint_tick for "complete" end_reason |
+| connect_timeout_ms | 30000 | Connection timeout (30 seconds); server aborts if < 2 sessions connect within this window |
 
 ## Parameter definitions