process TODO.md step8

2026-03-29 10:49:32 +08:00
parent ef01760924
commit c5fbd8e36d
26 changed files with 1005 additions and 20 deletions
@@ -0,0 +1,24 @@
+## MODIFIED Requirements
+
+### 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, reconnect, authoritative movement tick rules, and authoritative combat input rules for each managed session independently using the shared session lifecycle vocabulary. Server-side stale-input acceptance, shoot validation, and authoritative gameplay 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
+- **THEN** the timed-out session transitions through timeout or reconnect states according to policy
+- **THEN** the active session remains in its current healthy state
+
+#### Scenario: Host can inspect current managed sessions
+- **WHEN** server-side code needs to inspect the current connection state of connected peers
+- **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
+
+#### Scenario: Shoot validation remains peer-scoped
+- **WHEN** two managed peers send `ShootInput` traffic with different tick progress, target choices, or validation failures
+- **THEN** acceptance and rejection are evaluated independently for each sending peer
+- **THEN** one peer's stale or invalid shoot request does not overwrite or suppress the other's authoritative combat state
@@ -0,0 +1,40 @@
+## ADDED Requirements
+
+### Requirement: Server registers and validates `ShootInput` per peer
+The shared server networking path SHALL register `ShootInput` handling through the server host/runtime composition and SHALL validate each inbound shooting request against the sending managed peer before applying any authoritative combat result. Validation MUST reject malformed numeric input, missing or mismatched player identity, non-increasing shoot ticks for that sender, zero-direction fire requests, and targets that do not resolve to a living managed peer.
+
+#### Scenario: Valid `ShootInput` is accepted for the sending peer
+- **WHEN** a managed peer sends a well-formed `ShootInput` whose `playerId` maps to that sender, whose tick is newer than the sender's last accepted shoot tick, and whose `targetId` resolves to another living managed peer
+- **THEN** the server accepts the request for that sender only
+- **THEN** the sender's last accepted shoot tick is updated without changing other peers' combat bookkeeping
+
+#### Scenario: Invalid `ShootInput` is rejected without mutating authoritative combat state
+- **WHEN** a managed peer sends a `ShootInput` with malformed direction data, a stale tick, a mismatched `playerId`, or a target that is missing, self-targeted, or already dead
+- **THEN** the server rejects that request
+- **THEN** no authoritative damage or death state is applied to any peer from that rejected request
+
+### Requirement: Server resolves authoritative combat outcomes
+The shared server networking path SHALL own final combat resolution for accepted shots, including hit acceptance, damage application, authoritative HP mutation, and death determination. Combat resolution MUST update the authoritative server-owned state of both the attacker and target as needed without delegating gameplay truth to client-side prediction or presentation code.
+
+#### Scenario: Accepted shot applies damage to the authoritative target state
+- **WHEN** the server accepts a `ShootInput` that targets a living managed peer
+- **THEN** it resolves the shot as an authoritative hit against that target
+- **THEN** it reduces the target's authoritative HP according to the configured damage rule before later state snapshots are broadcast
+
+#### Scenario: Lethal damage marks the authoritative target as dead
+- **WHEN** an accepted shot reduces a target's authoritative HP to zero or below
+- **THEN** the server clamps the target's authoritative HP to zero
+- **THEN** subsequent combat and state broadcast treat that target as dead until a later server-owned lifecycle change resets it
+
+### Requirement: Server emits reliable authoritative `CombatEvent` results
+The shared server networking path SHALL emit authoritative combat outcomes through `CombatEvent` messages using the existing reliable-lane delivery contract. Accepted shots MUST produce reliable events for hit and damage application, and lethal results MUST also produce a death event. Rejected shots MUST produce a reliable `ShootRejected` event that identifies the attacker and rejected target context.
+
+#### Scenario: Accepted shot produces authoritative hit and damage events
+- **WHEN** the server resolves an accepted shot that damages a living target
+- **THEN** it broadcasts `CombatEvent` messages on the reliable lane for the authoritative combat result
+- **THEN** the emitted events identify the attacker, target, damage, and authoritative tick for client-side application
+
+#### Scenario: Rejected shot produces an authoritative rejection event
+- **WHEN** the server rejects a `ShootInput` during validation
+- **THEN** it broadcasts a reliable `CombatEvent` with event type `ShootRejected`
+- **THEN** clients can observe that rejection without inferring local authoritative damage or hit success
@@ -0,0 +1,19 @@
+## MODIFIED Requirements
+
+### 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 authoritative player state and include the authoritative tick for client reconciliation and interpolation. Authoritative HP changes produced by server-side combat resolution MUST be reflected in later snapshots for the affected peer.
+
+#### 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 player 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, HP, and tick from server-owned state
+
+#### Scenario: Combat-driven HP changes appear in later player snapshots
+- **WHEN** the server applies authoritative combat damage or death to a managed peer
+- **THEN** later `PlayerState` snapshots for that peer carry the updated authoritative HP value
+- **THEN** clients do not need to invent or persist a separate HP truth outside authoritative server snapshots
+
+#### 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