process TODO.md step7

openspec/specs/multi-session-lifecycle/spec.md

@@ -13,7 +13,7 @@ The shared networking core SHALL provide a multi-session lifecycle coordinator f
 - **THEN** lifecycle changes for one peer do not overwrite or hide the state of the other peer
 
 ### Requirement: Multi-session hosts can observe and evaluate each managed session
-The multi-session lifecycle coordinator SHALL expose per-session lookup or enumeration and MUST evaluate timeout, heartbeat, login, and reconnect rules for each managed session independently using the shared session lifecycle vocabulary.
+The multi-session lifecycle coordinator SHALL expose per-session lookup or enumeration and MUST evaluate timeout, heartbeat, login, reconnect, and authoritative movement tick rules for each managed session independently using the shared session lifecycle vocabulary. Server-side stale-input acceptance and authoritative movement tracking MUST remain scoped to the peer that produced the traffic.
 
 #### Scenario: Timeout affects only one managed session
 - **WHEN** one managed session stops receiving liveness updates while another session continues receiving heartbeat or message activity
@@ -25,6 +25,11 @@ The multi-session lifecycle coordinator SHALL expose per-session lookup or enume
 - **THEN** it can look up or enumerate managed sessions through the multi-session coordinator
 - **THEN** each entry exposes the shared session lifecycle state for that specific peer
 
+#### Scenario: Movement tick filtering remains peer-scoped
+- **WHEN** two managed peers send `MoveInput` traffic with different tick progress or ordering
+- **THEN** stale-input acceptance is evaluated independently for each managed peer
+- **THEN** one peer's late or advanced movement input does not overwrite or suppress the other's authoritative movement state
+
 ### Requirement: Session removal is explicit and does not corrupt remaining peers
 The multi-session lifecycle coordinator SHALL support explicit removal or disconnection handling for one managed session without resetting unrelated sessions that remain active.
 

openspec/specs/server-authoritative-movement/spec.md

@@ -0,0 +1,44 @@
+# server-authoritative-movement Specification
+
+## Purpose
+Define the shared server-side movement authority contract that accepts `MoveInput`, mutates authoritative per-peer movement state, and broadcasts authoritative `PlayerState` snapshots for client reconciliation and interpolation.
+
+## Requirements
+### Requirement: Server registers and validates `MoveInput` per peer
+The shared server networking path SHALL register `MoveInput` handling through the server host/runtime composition and SHALL validate inbound movement input against the sending peer before mutating authoritative state. Validation MUST reject stale ticks for that peer, malformed numeric values, and payloads that do not map to the sender's managed movement state.
+
+#### Scenario: Accepted `MoveInput` updates the sender's authoritative movement intent
+- **WHEN** a managed peer sends a well-formed `MoveInput` with a tick newer than the last accepted movement tick for that peer
+- **THEN** the server accepts the input for that peer only
+- **THEN** the sender's authoritative movement intent and last accepted movement tick are updated
+
+#### Scenario: Stale `MoveInput` is rejected without affecting other peers
+- **WHEN** one managed peer sends a `MoveInput` whose tick is older than the last accepted movement tick for that same peer
+- **THEN** the server rejects that input for that peer
+- **THEN** authoritative movement state for other managed peers remains unchanged
+
+### Requirement: Server owns authoritative movement resolution
+The shared server networking path SHALL own the final movement state for each managed peer, including position, rotation, velocity, and stop state. Zero-vector movement input MUST stop authoritative movement rather than leaving the peer in its previous moving state.
+
+#### Scenario: Non-zero input advances authoritative movement state
+- **WHEN** the server processes an accepted non-zero `MoveInput` for a managed peer during an authority update step
+- **THEN** the server updates that peer's authoritative position, rotation, and velocity from server-side movement resolution
+- **THEN** the resulting state becomes the source of truth for later `PlayerState` broadcast
+
+#### Scenario: Zero-vector input stops authoritative movement
+- **WHEN** the server processes an accepted zero-vector `MoveInput` for a managed peer
+- **THEN** the peer's authoritative velocity becomes zero
+- **THEN** subsequent authoritative state snapshots reflect that stopped state until a newer movement input is accepted
+
+### Requirement: Server broadcasts authoritative `PlayerState` snapshots on the sync cadence
+The shared server networking path SHALL emit authoritative `PlayerState` snapshots for managed peers at a fixed cadence using the existing sync-lane message contract. Each snapshot MUST be derived from the server-owned movement state and include the authoritative tick for client reconciliation and interpolation.
+
+#### Scenario: Authority update step emits sync-lane player snapshots
+- **WHEN** the server reaches a configured authority broadcast cadence while one or more managed peers have authoritative movement state
+- **THEN** it sends `PlayerState` snapshots using the sync-lane delivery policy when a distinct sync transport exists
+- **THEN** each snapshot includes the authoritative position, rotation, velocity, and tick from server-owned state
+
+#### Scenario: Reliable transport remains fallback when no sync transport exists
+- **WHEN** the server broadcasts authoritative `PlayerState` snapshots without a dedicated sync transport
+- **THEN** the shared routing path still emits `PlayerState` through the existing fallback lane behavior
+- **THEN** the authoritative snapshot contract remains unchanged