收口 Client 端，添加服务端约束

2026-03-29 15:06:17 +08:00
parent fbc09186f3
commit f6ca6fa6e4
12 changed files with 854 additions and 53 deletions
@@ -5,15 +5,15 @@ Define the shared server-side combat authority contract that accepts `ShootInput

 ## 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.
+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 shot requests that do not resolve to a living managed peer either through an explicit `targetId` or through server-side aim-direction fallback when `targetId` is omitted.

 #### 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
+- **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 target resolves to another living managed peer either from explicit `targetId` data or from server-side aim-direction fallback
 - **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
+- **WHEN** a managed peer sends a `ShootInput` with malformed direction data, a stale tick, a mismatched `playerId`, or targeting data that resolves to no living non-self managed peer
 - **THEN** the server rejects that request
 - **THEN** no authoritative damage or death state is applied to any peer from that rejected request

@@ -21,7 +21,7 @@ The shared server networking path SHALL register `ShootInput` handling through t
 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
+- **WHEN** the server accepts a `ShootInput` that resolves 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

@@ -5,7 +5,12 @@ Define the shared server-side movement authority contract that accepts `MoveInpu

 ## 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.
+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. The server SHALL also bootstrap authoritative movement state for a managed peer once login succeeds so idle players can receive authoritative snapshots before any movement input is sent. Validation MUST reject stale ticks for that peer, malformed numeric values, and payloads whose player identity does not match the sender's managed movement state.
+
+#### Scenario: Login success bootstraps idle authoritative movement state
+- **WHEN** a managed peer completes login before sending any `MoveInput`
+- **THEN** the server creates authoritative movement state for that peer with zero movement intent and default authoritative HP
+- **THEN** later authority broadcasts can include that idle peer even before movement input arrives

 #### 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