clearup

2026-04-06 11:58:36 +08:00
parent b1b38b485e
commit aebc4011c7
84 changed files with 5796 additions and 238 deletions
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-05
@@ -0,0 +1,72 @@
+## Context
+
+当前客户端本地预测和服务端权威同步存在两个 P0 级错位。第一，客户端把 `PlayerState.Tick` 当成“服务端已确认到哪个 `MoveInput.Tick`”来修剪 prediction buffer，但服务端实际把它作为广播快照序号生成，导致客户端错误移除或错误重放输入。第二，客户端移动速度来源于 UI / 登录返回链路，服务端权威速度来源于 `ServerAuthoritativeMovementConfiguration`，两边没有统一的真相来源。
+
+这次改动跨越 protobuf 契约、共享网络同步语义、客户端本地预测初始化、服务端登录后移动 bootstrap，以及回归测试，因此需要显式设计文档先固定决策。
+
+## Goals / Non-Goals
+
+**Goals:**
+- 明确分离权威快照 tick 和已确认移动输入 tick。
+- 让客户端 reconciliation 只依赖显式 ack move tick。
+- 建立服务器确认的移动参数启动流程，让客户端预测参数与服务端权威参数共享同一真相来源。
+- 用回归测试保护上述行为，避免再次回到“一个字段承载两种语义”的状态。
+
+**Non-Goals:**
+- 不在本次 P0 中解决本地 controlled player 的视觉平滑策略。
+- 不在本次 P0 中重构完整的服务端 movement cadence 管理，只要求现有语义能正确对账。
+- 不扩展新的移动玩法或额外状态字段，除非它们是承载 ack tick / 权威参数所必需的最小改动。
+
+## Decisions
+
+### 1. `PlayerState.Tick` 保留为权威快照序号，新增显式 `AcknowledgedMoveTick`
+
+`PlayerState.Tick` 现在已经被客户端和服务端用作“最新快照 / 最新同步状态”的序号。直接把它改成 ack tick 会让 remote interpolation、stale rejection、日志语义全部混乱。更稳妥的做法是保留 `PlayerState.Tick` 作为快照序号，并新增 `AcknowledgedMoveTick` 用于本地 controlled player reconciliation。
+
+备选方案：
+- 把 `PlayerState.Tick` 改成 ack tick，并额外引入 snapshot tick。这个方案会让已有 stale rejection 和 remote snapshot buffer 全部迁移到新字段，破坏面更大。
+- 继续复用单字段并靠注释区分。这个方案无法阻止后续实现再次误用，直接排除。
+
+### 2. 服务器在生成每个 `PlayerState` 时回填该玩家最后接受的 `MoveInput.Tick`
+
+ack tick 属于每个玩家独立的服务器权威状态，而不是整个广播循环共享状态。服务端应当从玩家的权威移动状态中读取 `LastAcceptedMoveTick`，并在构造该玩家 `PlayerState` 时填入 `AcknowledgedMoveTick`。这样客户端拿到同一条快照时，既能用 `Tick` 做 stale rejection / 插值排序，也能用 `AcknowledgedMoveTick` 做 prediction buffer 修剪。
+
+备选方案：
+- 发送独立 ack 消息。这样会增加协议复杂度和时序耦合，本次只需要在已有 `PlayerState` 中补充字段即可满足需求。
+
+### 3. 客户端本地预测参数必须在登录成功后切换到服务器确认值
+
+本地预测只要继续使用 UI 本地速度，而服务端继续使用配置速度，就算 ack tick 语义正确也会不断被回拉。P0 需要把移动参数所有权收回到服务器，客户端只允许在登录前临时持有候选值，登录成功后必须切换到服务器确认的移动参数后再继续长期预测。
+
+备选方案：
+- 彻底删除客户端可配置速度。这个方向可行，但会扩大 MVP 工作面；当前先保留输入渠道，只是不再允许它绕过服务器确认值成为长期预测真相。
+- 仅在代码里假定两边常量相等。这个方案没有可验证的契约，不能接受。
+
+### 4. 回归测试以“语义分离”而不是“视觉无抖动”作为 P0 验收目标
+
+P0 的核心是让协议与 reconciliation 语义正确。测试应精确验证：
+- 服务器广播 tick 增长时，ack tick 仍保持玩家最后确认输入值。
+- 客户端 reconciliation 只修剪 `<= AcknowledgedMoveTick` 的输入。
+- 客户端在登录成功后使用服务器确认的移动参数建立或刷新本地预测配置。
+
+视觉平滑与误差阈值可以在后续 P2 再处理，不应混入本次验收。
+
+## Risks / Trade-offs
+
+- [风险] protobuf 字段变更会影响生成代码与现有消息构造路径 -> 缓解：把改动限制在 `PlayerState` 最小增量字段，并补齐协议层回归测试。
+- [风险] 客户端仍可能在登录前使用本地默认速度开始预测 -> 缓解：在 bootstrap 规范中明确“长期预测必须切换到服务器确认参数”，实现阶段为未确认参数增加显式初始化路径。
+- [风险] 某些现有测试默认把 `PlayerState.Tick` 视作 ack tick -> 缓解：把这些测试改成分别断言 snapshot tick 与 `AcknowledgedMoveTick`。
+- [风险] 只修复语义不修复 cadence 后，极端情况下仍会看到少量位置纠正 -> 缓解：将 cadence 统一保留在后续 P1，并确保本次不会再由错账语义导致持续拉扯。
+
+## Migration Plan
+
+1. 更新 OpenSpec 契约与任务清单，固定 `PlayerState` 双 tick 语义与权威参数 bootstrap 规则。
+2. 实现协议字段与服务端状态生成逻辑，确保服务器能填充 `AcknowledgedMoveTick`。
+3. 更新客户端 reconciliation 与本地预测初始化逻辑。
+4. 补齐回归测试后运行 `dotnet test Network.EditMode.Tests.csproj --no-build -v minimal`。
+5. 如果发现客户端初始化阶段需要兼容旧字段，使用默认值路径临时兜底，但不改变最终权威参数所有权。
+
+## Open Questions
+
+- 服务器确认的移动参数是否只需要 `MoveSpeed`，还是要同时把旋转速度也纳入同一 bootstrap 契约。如果现有客户端和服务端旋转速度并非单一常量来源，实现时应一并纳入。
+- 登录成功消息是否已经稳定承载移动参数；如果没有，是否需要通过初始 `PlayerState` 或其他启动消息承载该参数。该问题在实现前需要结合现有消息结构做最小改动决策。
@@ -0,0 +1,30 @@
+## Why
+
+客户端当前把 `PlayerState.Tick` 同时当作权威快照序号和已确认输入 tick 使用，而服务端广播的 `PlayerState.Tick` 实际上代表广播序号。这会让本地 prediction buffer 错误修剪与重放，持续制造可见抖动。与此同时，客户端本地预测速度与服务端权威速度来自不同来源，导致即使 tick 语义修正后，客户端轨迹仍可能系统性偏离。
+
+## What Changes
+
+- 为权威移动同步引入明确的已确认输入 tick 语义，禁止继续复用 `PlayerState.Tick` 同时表达广播序号和输入确认序号。
+- 调整 `PlayerState` 消息契约，使权威快照同时携带快照 tick 与已确认移动输入 tick。
+- 定义客户端权威移动参数启动能力，要求客户端本地预测使用服务器确认的移动参数，而不是独立 UI 本地值。
+- 更新客户端 reconciliation 规则，使 prediction buffer 只按已确认移动输入 tick 修剪。
+- 补充编辑模式回归覆盖，保护 ack tick / broadcast tick 分离以及权威移动参数启动流程。
+
+## Capabilities
+
+### New Capabilities
+- `authoritative-movement-bootstrap`: 定义客户端在开始本地预测前如何接收并应用服务器确认的权威移动参数。
+
+### Modified Capabilities
+- `client-authoritative-player-state`: 本地 reconciliation 从按 `PlayerState.Tick` 对账改为按显式 ack move tick 对账。
+- `network-gameplay-message-types`: `PlayerState` 消息契约新增显式已确认移动输入 tick 字段。
+- `network-sync-strategy`: prediction history 修剪规则从快照 tick 改为 ack move tick。
+- `server-authoritative-movement`: 服务器广播的权威状态同时暴露快照序号与最后确认的移动输入 tick。
+- `gameplay-flow-regression-coverage`: 回归测试新增 ack/broadcast tick 分离与权威移动参数启动覆盖。
+
+## Impact
+
+- 影响共享协议与生成消息代码，包括 `PlayerState` 的字段契约。
+- 影响客户端 `MovementComponent`、`ClientPredictionBuffer` 与本地预测初始化流程。
+- 影响服务端权威移动协调器、登录成功后的移动参数建立、以及权威状态广播逻辑。
+- 影响 edit-mode 网络回归测试与假传输端到端测试。
@@ -0,0 +1,17 @@
+## ADDED Requirements
+
+### Requirement: Client prediction bootstraps from server-confirmed movement parameters
+The client SHALL establish controlled-player prediction parameters from server-confirmed authoritative movement settings before treating local prediction as steady-state truth. Client-local candidate values MAY exist before login succeeds, but long-lived prediction MUST switch to the server-confirmed parameters for the controlled player.
+
+#### Scenario: Login success provides authoritative movement parameters for prediction
+- **WHEN** the controlled client completes login and receives the server-confirmed movement bootstrap data
+- **THEN** the client stores the authoritative movement parameters for that controlled player
+- **THEN** subsequent local movement prediction uses those server-confirmed parameters instead of continuing to rely on an unrelated local UI value
+
+### Requirement: Server-owned movement parameters remain the single gameplay authority
+The server SHALL keep authoritative ownership of movement tuning used for authoritative movement resolution, and any client-visible movement parameters used for prediction MUST be derived from that server-owned configuration rather than from an independent client-only truth source.
+
+#### Scenario: Client candidate speed does not override server movement authority
+- **WHEN** a client proposes or locally configures a movement speed that differs from the server-owned movement speed
+- **THEN** the server-owned movement configuration remains authoritative for gameplay resolution
+- **THEN** the client's steady-state prediction parameters converge to the server-confirmed value instead of preserving the divergent local candidate
@@ -0,0 +1,11 @@
+## MODIFIED Requirements
+
+### Requirement: Local player reconciliation applies the full authoritative state by tick
+The controlled client SHALL continue reconciling local prediction from authoritative `PlayerState` updates, but it MUST distinguish between the authoritative snapshot tick and the acknowledged movement-input tick carried by that snapshot. Reconciliation MUST use the acknowledged movement-input tick to prune and replay predicted movement, while continuing to apply the accepted authoritative `position` and `rotation` and keeping authoritative HP and optional velocity synchronized with the owned player-state snapshot.
+
+#### Scenario: Local authoritative state corrects predicted presentation
+- **WHEN** the controlled player accepts an authoritative `PlayerState` snapshot with snapshot tick `S` and acknowledged movement-input tick `N`
+- **THEN** local reconciliation prunes or replays predicted movement using acknowledged tick `N` according to the sync strategy
+- **THEN** stale rejection or snapshot ordering for authoritative state continues to use snapshot tick `S`
+- **THEN** the local player's visible transform is corrected toward authoritative `position` and `rotation`
+- **THEN** the local player's authoritative HP on the client matches the accepted `PlayerState`
@@ -0,0 +1,11 @@
+## MODIFIED Requirements
+
+### Requirement: Gameplay-flow regressions include a fake-transport authoritative round trip
+The edit-mode regression suite SHALL include at least one deterministic fake-transport test that spans client send behavior, server-authoritative processing, and outgoing authoritative results. That round-trip regression MUST cover `MoveInput -> PlayerState` and `ShootInput -> CombatEvent` within the same MVP gameplay-flow suite. Movement round-trip coverage MUST also prove that authoritative `PlayerState` snapshots preserve a distinct snapshot tick and acknowledged movement-input tick, and that controlled-client prediction bootstraps from server-confirmed movement parameters rather than a divergent local-only value.
+
+#### Scenario: Fake-transport round trip preserves server authority across movement and combat
+- **WHEN** an edit-mode regression test drives gameplay input through fake client/server transports and advances the server authority loop
+- **THEN** the authoritative server path emits `PlayerState` snapshots in response to movement input
+- **THEN** the authoritative server path emits `CombatEvent` results in response to shooting input
+- **THEN** the movement assertions prove snapshot ordering and acknowledged-input reconciliation use distinct `PlayerState` fields
+- **THEN** the combined test protects both client single-session input flow and server multi-session authoritative behavior from regression
@@ -0,0 +1,24 @@
+## MODIFIED Requirements
+
+### Requirement: Gameplay messages expose explicit MVP payload fields
+The shared networking contract SHALL define the MVP payload fields for gameplay messages explicitly in the source protobuf schema and generated C# messages. `MoveInput` MUST expose `playerId`, `tick`, `moveX`, and `moveY`; `ShootInput` MUST expose `playerId`, `tick`, `dirX`, `dirY`, and an optional `targetId`; `PlayerState` MUST expose `playerId`, `tick`, `acknowledgedMoveTick`, `position`, `rotation`, `hp`, and an optional `velocity`; `CombatEvent` MUST expose `tick`, `eventType`, `attackerId`, `targetId`, `damage`, and an optional `hitPosition`. The shared contract MUST also provide `CombatEventType` so combat results use explicit event categories rather than ad hoc integer payload conventions.
+
+#### Scenario: Movement input carries explicit movement fields
+- **WHEN** client or server code constructs or parses `MoveInput`
+- **THEN** the message exposes `playerId`, `tick`, `moveX`, and `moveY`
+- **THEN** movement intent does not rely on an overloaded payload extension
+
+#### Scenario: Shooting input carries explicit aim fields
+- **WHEN** client or server code constructs or parses `ShootInput`
+- **THEN** the message exposes `playerId`, `tick`, `dirX`, `dirY`, and `targetId`
+- **THEN** shooting direction and optional target selection are represented directly in the message contract
+
+#### Scenario: Authoritative player state carries explicit gameplay state fields
+- **WHEN** client or server code constructs or parses `PlayerState`
+- **THEN** the message exposes `playerId`, `tick`, `acknowledgedMoveTick`, `position`, `rotation`, `hp`, and `velocity`
+- **THEN** snapshot ordering and acknowledged-input reconciliation are both expressed without ad hoc payload extensions or overloaded tick semantics
+
+#### Scenario: Combat events carry explicit result fields and event categories
+- **WHEN** client or server code constructs or parses `CombatEvent`
+- **THEN** the message exposes `tick`, `eventType`, `attackerId`, `targetId`, `damage`, and `hitPosition`
+- **THEN** `CombatEventType` provides explicit combat-result categories for interpreting that event payload
@@ -0,0 +1,10 @@
+## MODIFIED Requirements
+
+### Requirement: Authoritative correction prunes acknowledged prediction history
+The client sync strategy SHALL reconcile local prediction against authoritative player-state updates by pruning acknowledged movement inputs at or before the acknowledged movement-input tick carried by the authoritative snapshot and only reapplying newer pending `MoveInput` messages. The snapshot tick used for stale rejection or remote interpolation MUST NOT be reused as the local prediction-acknowledgement boundary.
+
+#### Scenario: Reconciliation removes already acknowledged movement inputs
+- **WHEN** the client accepts an authoritative `PlayerState` update whose acknowledged movement-input tick is `N`
+- **THEN** locally buffered predicted `MoveInput` messages with tick less than or equal to `N` are removed from the replay buffer
+- **THEN** only `MoveInput` messages newer than `N` remain eligible for re-simulation
+- **THEN** the client does not infer the acknowledgement boundary solely from the snapshot tick
@@ -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 both the authoritative snapshot tick for client stale rejection or interpolation and the last acknowledged `MoveInput.Tick` for client reconciliation. 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, snapshot tick, and acknowledged movement-input 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
@@ -0,0 +1,17 @@
+## 1. Protocol And Spec Alignment
+
+- [x] 1.1 Update the shared gameplay message schema and generated code so `PlayerState` carries an explicit acknowledged movement-input tick.
+- [x] 1.2 Align OpenSpec-linked message construction and parsing paths with the new `PlayerState` field semantics.
+- [x] 1.3 Define or wire the server-confirmed movement bootstrap data used by the controlled client after login succeeds.
+
+## 2. Authoritative Movement Runtime
+
+- [x] 2.1 Update the server authoritative movement state and broadcast builder so each `PlayerState` includes both snapshot tick and last accepted `MoveInput.Tick`.
+- [x] 2.2 Update client reconciliation and prediction-buffer pruning to use the acknowledged movement-input tick instead of `PlayerState.Tick`.
+- [x] 2.3 Switch controlled-client steady-state prediction parameters to the server-confirmed authoritative movement values.
+
+## 3. Regression Coverage
+
+- [x] 3.1 Add or update edit-mode tests that prove snapshot tick and acknowledged movement-input tick remain distinct in authoritative movement broadcasts.
+- [x] 3.2 Add or update client reconciliation tests so only inputs at or before the acknowledged tick are pruned.
+- [x] 3.3 Add or update gameplay-flow round-trip coverage for server-confirmed movement bootstrap and authoritative movement convergence.
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-05
@@ -0,0 +1,75 @@
+## Context
+
+P0 separated snapshot tick from acknowledged movement-input tick and moved steady-state client prediction onto server-confirmed movement parameters. The remaining visible jitter comes from two implementation gaps: the server authoritative movement path still accepts arbitrary elapsed values from its outer loop, and the controlled client still rewrites rigidbody state immediately on every accepted authoritative snapshot. Those behaviors are individually acceptable for correctness, but together they amplify small cadence drift into visible pull-back.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make authoritative movement cadence an explicit shared runtime contract instead of an accidental property of whichever loop calls into server movement.
+- Keep server authoritative movement deterministic enough that client prediction can be compared against a known cadence during debugging and regression tests.
+- Replace unconditional hard rewrites for small controlled-player divergence with a bounded correction path that preserves server authority while reducing visible jitter.
+- Preserve the existing remote-player interpolation path and the P0 snapshot-tick versus acknowledged-move-tick contract.
+
+**Non-Goals:**
+- Do not redesign transport lanes, login flow, or session ownership.
+- Do not add a new prediction model or speculative physics stack beyond the existing movement inputs and authoritative snapshots.
+- Do not change remote-player interpolation into extrapolation.
+- Do not remove the ability to hard snap when local state diverges materially from authoritative truth.
+
+## Decisions
+
+### Decision: Introduce a dedicated authoritative movement cadence contract
+The server runtime will expose a single configured movement step interval that drives authoritative movement simulation and state emission. The coordinator will consume that fixed cadence rather than arbitrary elapsed values supplied by callers.
+
+Why:
+- A fixed cadence makes server movement behavior testable and comparable against client prediction.
+- It eliminates one major source of drift where identical movement constants still produce different trajectories because integration step sizes differ.
+
+Alternative considered:
+- Keep variable elapsed integration and only document recommended server loop timing. Rejected because the problem is not documentation; it is the lack of an enforceable contract.
+
+### Decision: Surface cadence diagnostics through existing movement/sync plumbing
+The runtime will expose enough information for logs, tests, and reconciliation code to know the authoritative movement cadence and the authoritative tick carried by snapshots.
+
+Why:
+- Debugging convergence problems requires seeing both the snapshot identity and the cadence under which it was produced.
+- Tests need a stable way to assert cadence-aligned behavior without relying on wall-clock timing.
+
+Alternative considered:
+- Keep cadence entirely internal to the server runtime. Rejected because that hides the exact value the client needs to compare against when diagnosing jitter.
+
+### Decision: Apply bounded correction for small controlled-player error
+The controlled client will classify accepted authoritative corrections into two paths: small error remains server-authoritative but is corrected through bounded convergence over subsequent local updates; large error still snaps immediately.
+
+Why:
+- Most visible jitter now comes from repeated tiny rewrites, not giant desync.
+- A bounded correction path reduces visual pull-back while preserving the ability to recover quickly from true divergence.
+
+Alternative considered:
+- Continue snapping on every accepted state. Rejected because it preserves correctness but also preserves the visible jitter this change is meant to reduce.
+
+### Decision: Keep remote-player presentation rules unchanged
+Remote players will continue using buffered interpolation/clamp over accepted authoritative snapshots. This change only modifies the local controlled-player reconciliation path.
+
+Why:
+- Remote presentation already has a distinct smoothing strategy with a different trade-off surface.
+- Mixing the two concerns would broaden the change without addressing the current problem source.
+
+## Risks / Trade-offs
+
+- [Bounded local correction can hide a real divergence for too long] -> Keep a hard snap threshold and assert it in regression coverage.
+- [Fixed authoritative cadence may require updates to server runtime callers] -> Centralize cadence ownership in runtime configuration and keep the public integration seam narrow.
+- [Cadence diagnostics may be misread as a new network contract] -> Keep diagnostics descriptive and avoid introducing a second movement truth outside authoritative snapshots.
+- [Unity rigidbody timing may still differ from deterministic server stepping] -> Tie correction policy to authoritative cadence and document that the client still converges to server truth instead of matching every substep exactly.
+
+## Migration Plan
+
+1. Introduce the authoritative movement cadence configuration and route server movement stepping through it.
+2. Update controlled-player reconciliation to classify small versus large error using the cadence-aware correction policy.
+3. Extend edit-mode regression coverage for cadence-aligned convergence and snap fallback.
+4. Verify the sample still preserves server-authoritative outcomes and archive the change after tests pass.
+
+## Open Questions
+
+- Whether cadence diagnostics belong in an explicit debug/state object or can remain as properties on existing runtime helpers.
+- The exact positional/rotational error thresholds that should trigger hard snap versus bounded correction for the sample scene.
@@ -0,0 +1,26 @@
+## Why
+
+P0 fixed tick semantics and server-confirmed movement bootstrap, but the sample still allows client prediction and server authority to advance on different cadences. That keeps controlled-player reconciliation noisy even when both sides share the same movement constants, so the next change needs to make server movement cadence explicit and tighten the client correction path against that contract.
+
+## What Changes
+
+- Define a dedicated authoritative movement cadence contract for the shared server runtime, including a fixed simulation/update interval and explicit diagnostics that let the client compare its local prediction step against server authority timing.
+- Tighten the existing server authoritative movement spec so movement simulation and `PlayerState` production are driven by the configured cadence instead of arbitrary caller-provided elapsed values.
+- Tighten the client sync strategy so controlled-player reconciliation distinguishes between small cadence-aligned error and large divergence, using bounded correction for the former and hard snap only for the latter.
+- Tighten the client authoritative player-state contract so local controlled-player presentation applies cadence-aware correction without changing remote interpolation rules.
+- Extend regression coverage to protect cadence alignment, bounded local correction, and large-error snap fallback.
+
+## Capabilities
+
+### New Capabilities
+- `authoritative-movement-cadence`: Defines the shared contract for fixed authoritative movement cadence, cadence diagnostics, and server/client observability.
+
+### Modified Capabilities
+- `server-authoritative-movement`: Require server-side movement simulation and snapshot production to follow the configured authoritative cadence.
+- `network-sync-strategy`: Require cadence-aware local reconciliation with bounded correction for small error and snap fallback for large divergence.
+- `client-authoritative-player-state`: Require the controlled-player presentation path to consume cadence-aware correction results without changing remote authoritative ownership.
+- `gameplay-flow-regression-coverage`: Require edit-mode regressions for cadence alignment and controlled-player correction behavior.
+
+## Impact
+
+Affected areas include `ServerRuntimeHandle`, `ServerAuthoritativeMovementCoordinator`, client movement/reconciliation code in `MovementComponent` and related sync helpers, and edit-mode network regression tests. No new transport or session-lifecycle capability is introduced, but movement diagnostics and correction policy become more explicit.
@@ -0,0 +1,17 @@
+## ADDED Requirements
+
+### Requirement: Server authoritative movement uses a fixed cadence contract
+The shared server runtime SHALL define a fixed authoritative movement cadence for simulation and snapshot production. Authoritative movement updates MUST be stepped from that configured cadence instead of arbitrary caller-provided elapsed values.
+
+#### Scenario: Runtime advances movement using configured cadence
+- **WHEN** the server runtime advances authoritative movement while one or more managed peers have movement state
+- **THEN** the authoritative movement coordinator steps simulation using the configured cadence interval
+- **THEN** the same cadence governs later authoritative `PlayerState` production for that runtime
+
+### Requirement: Cadence information is observable for diagnostics and regression tests
+The shared runtime SHALL expose the active authoritative movement cadence through diagnostics or runtime state that tests and debugging tools can read without inspecting private loop internals.
+
+#### Scenario: Tests can read active movement cadence
+- **WHEN** an edit-mode regression or debugging path inspects the server runtime after movement setup
+- **THEN** it can observe the authoritative movement cadence configured for that runtime
+- **THEN** the observed value matches the cadence used by authoritative movement stepping
@@ -0,0 +1,15 @@
+## MODIFIED Requirements
+
+### Requirement: Local player reconciliation applies the full authoritative state by tick
+The controlled client SHALL continue reconciling local prediction from authoritative `PlayerState` snapshots while keeping authoritative HP and optional velocity synchronized with the owned player-state snapshot. Reconciliation MUST use the acknowledged movement-input tick defined by the sync strategy, and the visible controlled-player transform MUST apply cadence-aware bounded correction for small divergence while preserving immediate authoritative snap for large divergence.
+
+#### Scenario: Local authoritative state corrects predicted presentation
+- **WHEN** the controlled player accepts an authoritative `PlayerState` whose acknowledged movement-input tick is `N`
+- **THEN** local reconciliation prunes or replays predicted movement using tick `N` according to the sync strategy
+- **THEN** the local player's visible transform converges toward authoritative `position` and `rotation` through cadence-aware correction when the remaining error is small
+- **THEN** the local player's authoritative HP on the client matches the accepted `PlayerState`
+
+#### Scenario: Large local divergence bypasses bounded correction
+- **WHEN** the controlled player accepts an authoritative `PlayerState` and the remaining transform error exceeds the configured snap threshold
+- **THEN** the controlled player's visible transform snaps immediately to authoritative `position` and `rotation`
+- **THEN** later local prediction resumes from that authoritative baseline instead of continuing from stale local presentation
@@ -0,0 +1,23 @@
+## MODIFIED Requirements
+
+### Requirement: Gameplay-flow regressions include a fake-transport authoritative round trip
+The edit-mode regression suite SHALL include at least one deterministic fake-transport test that spans client send behavior, server-authoritative processing, and outgoing authoritative results. That round-trip regression MUST cover `MoveInput -> PlayerState` and `ShootInput -> CombatEvent` within the same MVP gameplay-flow suite, and it MUST assert that authoritative movement stepping follows the configured cadence contract.
+
+#### Scenario: Fake-transport round trip preserves server authority across movement and combat
+- **WHEN** an edit-mode regression test drives gameplay input through fake client/server transports and advances the server authority loop
+- **THEN** the authoritative server path emits `PlayerState` snapshots in response to movement input using the configured authoritative movement cadence
+- **THEN** the authoritative server path emits `CombatEvent` results in response to shooting input
+- **THEN** the combined test protects both client single-session input flow and server multi-session authoritative behavior from regression
+
+### Requirement: Gameplay-flow regressions cover controlled-player correction decisions
+The edit-mode regression suite SHALL cover the controlled-player reconciliation path after authoritative movement replay, including bounded correction for small cadence-aligned error and hard snap fallback for large divergence.
+
+#### Scenario: Controlled-player reconciliation uses bounded correction for small error
+- **WHEN** an edit-mode regression test applies an authoritative local `PlayerState` that leaves only small post-replay divergence
+- **THEN** the controlled-player path keeps authoritative ownership of the snapshot
+- **THEN** visible correction converges without an immediate hard snap on the acceptance frame
+
+#### Scenario: Controlled-player reconciliation snaps on large divergence
+- **WHEN** an edit-mode regression test applies an authoritative local `PlayerState` that leaves divergence beyond the configured snap threshold
+- **THEN** the controlled-player path immediately applies the authoritative transform state
+- **THEN** later prediction resumes from that authoritative baseline
@@ -0,0 +1,19 @@
+## MODIFIED Requirements
+
+### Requirement: Authoritative correction prunes acknowledged prediction history
+The client sync strategy SHALL reconcile local prediction against authoritative player-state updates by pruning acknowledged movement inputs at or before the authoritative acknowledged movement tick and only reapplying newer pending `MoveInput` messages. For the controlled player, reconciliation MUST classify authoritative error after replay into a bounded-correction path for small cadence-aligned divergence and an immediate snap path for large divergence.
+
+#### Scenario: Reconciliation removes already acknowledged movement inputs
+- **WHEN** the client accepts an authoritative `PlayerState` update that acknowledges movement tick `N`
+- **THEN** locally buffered predicted `MoveInput` messages with tick less than or equal to `N` are removed from the replay buffer
+- **THEN** only `MoveInput` messages newer than `N` remain eligible for re-simulation
+
+#### Scenario: Small post-replay error uses bounded correction
+- **WHEN** the controlled client finishes replay after accepting an authoritative `PlayerState` and the remaining position or rotation error stays within the configured bounded-correction threshold
+- **THEN** the client keeps authoritative ownership of the accepted snapshot
+- **THEN** local presentation converges through bounded correction instead of an immediate hard snap on that frame
+
+#### Scenario: Large divergence snaps immediately
+- **WHEN** the controlled client finishes replay after accepting an authoritative `PlayerState` and the remaining error exceeds the configured snap threshold
+- **THEN** the client immediately applies the authoritative transform state
+- **THEN** later local prediction continues from that authoritative baseline
@@ -0,0 +1,32 @@
+## MODIFIED Requirements
+
+### 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. The authoritative movement integrator MUST advance using the runtime's configured authoritative movement cadence so that movement resolution and later `PlayerState` snapshots are produced from the same server-side stepping contract.
+
+#### 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 using the configured authoritative movement cadence
+- **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 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 the configured authoritative movement 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
@@ -0,0 +1,15 @@
+## 1. Cadence Contract
+
+- [x] 1.1 Introduce a fixed authoritative movement cadence configuration/runtime surface that server movement stepping can read and tests can observe.
+- [x] 1.2 Update the server authoritative movement loop and snapshot emission path to use the configured cadence instead of arbitrary elapsed input.
+
+## 2. Controlled Reconciliation
+
+- [x] 2.1 Refactor controlled-player reconciliation to distinguish bounded correction from hard snap after authoritative replay.
+- [x] 2.2 Wire cadence-aware correction thresholds through the local movement/sync path without changing remote-player interpolation rules.
+
+## 3. Regression Coverage
+
+- [x] 3.1 Add or update edit-mode tests that prove authoritative movement stepping and snapshot output follow the configured cadence.
+- [x] 3.2 Add or update edit-mode tests that prove controlled-player reconciliation uses bounded correction for small error and hard snap for large divergence.
+- [x] 3.3 Re-run OpenSpec status and confirm the change is apply-ready.
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-05
@@ -0,0 +1,68 @@
+## Context
+
+P0 separated authoritative snapshot identity from movement-input acknowledgement, and P1 made server cadence explicit while introducing an initial bounded-correction path for controlled-player reconciliation. That leaves one remaining UX-focused gap: repeated small authoritative corrections can still look noisy because the client only decides "bounded correction or snap" at the moment a snapshot is accepted. The implementation does not yet define how bounded correction persists, gets replaced, or escalates when multiple authoritative snapshots arrive while the local player is still converging.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Define a stable controlled-player visual-correction policy that survives across multiple accepted authoritative snapshots.
+- Keep authoritative gameplay truth separate from temporary visual smoothing state so local presentation can converge without weakening server authority.
+- Specify when a new small correction replaces, merges with, or escalates an existing bounded correction.
+- Add regression requirements that prove repeated small corrections converge and large divergence still snaps immediately.
+
+**Non-Goals:**
+- Do not change server-authoritative movement cadence, tick semantics, or movement parameter ownership.
+- Do not modify remote-player interpolation rules.
+- Do not introduce extrapolation, rollback beyond existing local replay, or a second gameplay-truth state on the client.
+- Do not turn bounded correction into an unbounded smoothing layer that can hide persistent divergence.
+
+## Decisions
+
+### Decision: Represent local visual convergence as explicit correction state
+The controlled-player path will keep authoritative transform truth separate from a short-lived visual correction state that tracks the remaining offset being paid down after reconciliation.
+
+Why:
+- Repeated small authoritative updates need continuity; otherwise each accepted snapshot effectively restarts smoothing from scratch.
+- An explicit correction state makes the contract testable and prevents presentation code from quietly mixing visual offset with authoritative gameplay truth.
+
+Alternative considered:
+- Recompute a one-frame bounded correction on every accepted snapshot without storing correction state. Rejected because it does not define behavior across consecutive snapshots and tends to produce visible jitter under sustained updates.
+
+### Decision: New authoritative snapshots update or replace active correction by policy
+When the controlled player already has active bounded correction and another authoritative snapshot arrives, the client will either fold the new residual error into the active correction, replace it with a fresher target, or escalate to hard snap when the combined error breaches the snap threshold.
+
+Why:
+- The sample needs deterministic behavior when correction is still in flight and another snapshot arrives.
+- Replacement rules are necessary to keep the visual path responsive to newer authoritative truth without accumulating stale offsets forever.
+
+Alternative considered:
+- Queue multiple corrections independently. Rejected because it increases latency and can create laggy visual tails after authority has already advanced.
+
+### Decision: Bound correction by convergence budget, not by indefinite smoothing
+Bounded correction will have an explicit convergence budget derived from cadence-aware limits so the visual path either settles quickly or escalates to snap when authority keeps diverging.
+
+Why:
+- P2 is intended to reduce visible twitching, not to hide desync.
+- A bounded budget preserves the principle that authoritative truth must win quickly under sustained mismatch.
+
+Alternative considered:
+- Smooth indefinitely with a low-pass presentation filter. Rejected because it can mask real divergence and make the controlled player feel floaty.
+
+## Risks / Trade-offs
+
+- [Explicit correction state increases local presentation complexity] -> Keep the state narrow, owned by the controlled-player path only, and cover it with regression tests.
+- [Aggressive replacement rules can reintroduce visible twitching] -> Define deterministic merge/replace thresholds and verify them with multi-snapshot regressions.
+- [Overly permissive smoothing can hide divergence too long] -> Keep a hard snap threshold and convergence budget that force recovery to authoritative truth.
+- [Unity update timing can still expose frame-rate-specific artifacts] -> Express requirements in terms of convergence behavior and authoritative ownership rather than exact frame counts.
+
+## Migration Plan
+
+1. Extend the controlled-player reconciliation contract to expose explicit visual correction state and replacement rules.
+2. Update the local sync strategy requirements so consecutive authoritative snapshots interact predictably with bounded correction.
+3. Add regression coverage for repeated small corrections, correction replacement, and snap escalation.
+4. Implement and verify the new policy before archiving the change.
+
+## Open Questions
+
+- Whether the correction state should be fully encapsulated inside `MovementComponent` or extracted into a dedicated helper/state holder.
+- The exact convergence budget values that feel stable in the sample scene without making the controlled player feel detached from input.
@@ -0,0 +1,24 @@
+## Why
+
+P0 and P1 fixed the correctness side of controlled-player reconciliation: acknowledged movement tick is explicit, steady-state prediction uses server-confirmed movement parameters, and authoritative movement cadence is no longer accidental. The sample still has one remaining gap: the local controlled player can look busy or twitchy under repeated small corrections because the current bounded-correction path is only a first-pass clamp, not a fully specified visual convergence policy.
+
+## What Changes
+
+- Tighten the controlled-player reconciliation requirements so small authoritative corrections accumulate through an explicit visual-correction state instead of repeatedly restarting ad hoc per accepted snapshot.
+- Require the local presentation path to separate authoritative gameplay truth from short-lived visual correction state, preserving hard snap only for material divergence.
+- Extend the sync-strategy contract so bounded correction defines convergence behavior across consecutive snapshots instead of only classifying a single snapshot as small or large error.
+- Extend regression coverage to prove multi-snapshot convergence, correction replacement rules, and hard-snap fallback still hold.
+
+## Capabilities
+
+### New Capabilities
+<!-- None. -->
+
+### Modified Capabilities
+- `client-authoritative-player-state`: Tighten the controlled-player presentation contract so authoritative truth and temporary visual correction state remain distinct during local convergence.
+- `network-sync-strategy`: Tighten local reconciliation so bounded correction has explicit replacement, convergence, and snap-escalation rules across consecutive authoritative snapshots.
+- `gameplay-flow-regression-coverage`: Require edit-mode regressions that cover multi-snapshot convergence and repeated local correction behavior for the controlled player.
+
+## Impact
+
+Affected areas include controlled-player reconciliation and presentation code in `MovementComponent` plus any helper types that own local correction state, along with edit-mode regression tests for sync strategy and gameplay-flow round trips. No transport, session-lifecycle, or server authoritative movement protocol changes are expected in this phase.
@@ -0,0 +1,20 @@
+## MODIFIED Requirements
+
+### Requirement: Local player reconciliation applies the full authoritative state by tick
+The controlled client SHALL continue reconciling local prediction from authoritative `PlayerState` snapshots while keeping authoritative HP and optional velocity synchronized with the owned player-state snapshot. Reconciliation MUST use the acknowledged movement-input tick defined by the sync strategy, and the visible controlled-player transform MUST keep authoritative gameplay truth separate from short-lived visual correction state. Small divergence after replay MUST converge through explicit bounded correction state, while large divergence or failed convergence MUST still snap immediately to authoritative `position` and `rotation`.
+
+#### Scenario: Local authoritative state corrects predicted presentation
+- **WHEN** the controlled player accepts an authoritative `PlayerState` whose acknowledged movement-input tick is `N`
+- **THEN** local reconciliation prunes or replays predicted movement using tick `N` according to the sync strategy
+- **THEN** the controlled player's authoritative gameplay state updates immediately to the accepted `position`, `rotation`, HP, and optional velocity
+- **THEN** the local player's visible transform may temporarily differ only through bounded visual correction state that converges back to the authoritative baseline
+
+#### Scenario: Consecutive small corrections replace or fold into active visual correction
+- **WHEN** the controlled player accepts a newer authoritative `PlayerState` while a bounded visual correction is still active and the new residual error remains inside the configured bounded-correction limits
+- **THEN** the client updates the active visual correction state according to the sync strategy instead of preserving stale correction targets indefinitely
+- **THEN** the controlled player's authoritative gameplay state still reflects only the newest accepted `PlayerState`
+
+#### Scenario: Large local divergence bypasses bounded correction
+- **WHEN** the controlled player accepts an authoritative `PlayerState` and the remaining transform error exceeds the configured snap threshold or the active bounded correction can no longer converge within its budget
+- **THEN** the controlled player's visible transform snaps immediately to authoritative `position` and `rotation`
+- **THEN** any temporary visual correction state is cleared before later local prediction resumes from that authoritative baseline
@@ -0,0 +1,24 @@
+## MODIFIED Requirements
+
+### Requirement: Gameplay-flow regressions cover controlled-player correction decisions
+The edit-mode regression suite SHALL cover the controlled-player reconciliation path after authoritative movement replay, including bounded correction for small cadence-aligned error, correction replacement under consecutive authoritative snapshots, and hard snap fallback for large or non-convergent divergence.
+
+#### Scenario: Controlled-player reconciliation uses bounded correction for small error
+- **WHEN** an edit-mode regression test applies an authoritative local `PlayerState` that leaves only small post-replay divergence
+- **THEN** the controlled-player path keeps authoritative ownership of the snapshot
+- **THEN** visible correction converges without an immediate hard snap on the acceptance frame
+
+#### Scenario: Controlled-player reconciliation updates active correction on repeated small snapshots
+- **WHEN** an edit-mode regression test feeds multiple authoritative local `PlayerState` updates whose residual divergence remains inside bounded-correction limits while a prior correction is still active
+- **THEN** the controlled-player path replaces or folds the active correction according to the sync strategy
+- **THEN** the test proves the client does not accumulate multiple stale correction tails
+
+#### Scenario: Controlled-player reconciliation snaps on large divergence
+- **WHEN** an edit-mode regression test applies an authoritative local `PlayerState` that leaves divergence beyond the configured snap threshold
+- **THEN** the controlled-player path immediately applies the authoritative transform state
+- **THEN** later prediction resumes from that authoritative baseline
+
+#### Scenario: Controlled-player reconciliation snaps after failed convergence
+- **WHEN** an edit-mode regression test feeds consecutive authoritative local `PlayerState` updates that keep bounded correction from converging within the configured budget
+- **THEN** the controlled-player path escalates to a hard snap
+- **THEN** the active correction state is cleared before later local prediction continues
@@ -0,0 +1,24 @@
+## MODIFIED Requirements
+
+### Requirement: Authoritative correction prunes acknowledged prediction history
+The client sync strategy SHALL reconcile local prediction against authoritative player-state updates by pruning acknowledged movement inputs at or before the authoritative acknowledged movement tick and only reapplying newer pending `MoveInput` messages. For the controlled player, reconciliation MUST classify authoritative error after replay into a bounded-correction path for small cadence-aligned divergence and an immediate snap path for large divergence. When bounded correction is already active, later authoritative snapshots MUST deterministically replace, fold into, or escalate that correction based on the newest residual error instead of stacking unbounded visual offsets.
+
+#### Scenario: Reconciliation removes already acknowledged movement inputs
+- **WHEN** the client accepts an authoritative `PlayerState` update that acknowledges movement tick `N`
+- **THEN** locally buffered predicted `MoveInput` messages with tick less than or equal to `N` are removed from the replay buffer
+- **THEN** only `MoveInput` messages newer than `N` remain eligible for re-simulation
+
+#### Scenario: Small post-replay error uses bounded correction
+- **WHEN** the controlled client finishes replay after accepting an authoritative `PlayerState` and the remaining position or rotation error stays within the configured bounded-correction threshold
+- **THEN** the client keeps authoritative ownership of the accepted snapshot
+- **THEN** local presentation converges through bounded correction instead of an immediate hard snap on that frame
+
+#### Scenario: New small error updates active bounded correction
+- **WHEN** the controlled client accepts another authoritative `PlayerState` before the previous bounded correction has finished and the new residual error still stays within bounded-correction limits
+- **THEN** the sync strategy updates the active bounded correction state using the newest authoritative residual error
+- **THEN** the client does not queue multiple independent correction tails for the same controlled player
+
+#### Scenario: Failed bounded correction escalates to snap
+- **WHEN** the controlled client detects that the residual error from consecutive authoritative updates exceeds the snap threshold or remains non-convergent beyond the configured correction budget
+- **THEN** the client immediately applies the authoritative transform state
+- **THEN** any active bounded correction state is discarded before later prediction continues from the authoritative baseline
@@ -0,0 +1,15 @@
+## 1. Controlled Correction State
+
+- [x] 1.1 Introduce an explicit controlled-player visual correction state that stays separate from authoritative gameplay truth.
+- [x] 1.2 Route `MovementComponent` reconciliation so accepted authoritative snapshots update or clear the visual correction state instead of restarting ad hoc per-frame correction.
+
+## 2. Consecutive Snapshot Policy
+
+- [x] 2.1 Implement deterministic rules for folding, replacing, or snapping active bounded correction when newer authoritative snapshots arrive before convergence completes.
+- [x] 2.2 Add convergence-budget and snap-escalation handling so repeated non-convergent small corrections cannot accumulate indefinitely.
+
+## 3. Regression Coverage
+
+- [x] 3.1 Add sync-strategy unit tests that cover repeated small corrections updating the active correction state.
+- [x] 3.2 Add gameplay-flow regression coverage for multi-snapshot controlled-player convergence and snap escalation after failed convergence.
+- [x] 3.3 Run the edit-mode network regression suite, or document the blocking environment issue if the runtime remains unavailable.
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-05
@@ -0,0 +1,81 @@
+## Context
+
+本地回环测试中受控玩家出现小幅抖动。抖动根源之一是 `ReplayPendingInputs()` 中回放时对每个 `PredictedMoveStep` 的一次性大时长积分，与实时预测路径中 FixedUpdate 按 `Time.fixedDeltaTime` 逐步积分的形状不一致。
+
+当前 `ReplayPendingInputs()` 实现：
+```csharp
+foreach (var replayInput in replayInputs)
+{
+    ApplyTankMovementToPredictedState(
+        replayInput.Input.TurnInput,
+        replayInput.Input.ThrottleInput,
+        replayInput.SimulatedDurationSeconds);  // 一次性传入总时长
+}
+```
+
+Tank 运动学中旋转影响前进方向：`heading(t+dt) = heading(t) + turnInput * turnSpeed * dt`，`position(t+dt) = position(t) + forward(heading(t+dt)) * throttleSpeed * dt`。逐步积分和一次性积分在 dt 较大时产生分歧。
+
+## Goals / Non-Goals
+
+**Goals:**
+- `ReplayPendingInputs()` 按固定步长逐步积分，与 FixedUpdate 预测路径完全一致
+- 回放结果与逐步实时预测的轨迹一致，消除因积分形状不同导致的残余误差
+- 不改变外部接口，只修改内部积分方式
+
+**Non-Goals:**
+- 不修改服务端的 50ms cadence
+- 不解决 send interval 摆动问题（Step 3 范畴）
+- 不修改 visual correction 逻辑（Step 4 范畴）
+
+## Decisions
+
+### Decision: 步长取服务端的 SimulationInterval（50ms），而非客户端的 Time.fixedDeltaTime（20ms）
+
+**选择**：按服务端 `SimulationInterval`（50ms）作为回放步长。
+
+**理由**：
+- 服务端以 50ms 步长积分产生 authoritative state，客户端回放必须与其一致才能消除偏差
+- 客户端 FixedUpdate 20ms 是渲染/物理步长，不代表服务端模拟粒度
+- 每个 `PredictedMoveStep` 的 `SimulatedDurationSeconds` 可能是 50ms、100ms 等，按 50ms 步长逐次推进即可
+
+**替代方案**：
+- 用 20ms 步长回放：与客户端 FixedUpdate 一致，但与服务端不同步，仍会产生偏差
+- 用 `SimulatedDurationSeconds` 作为单步：即当前行为，会导致非线性分歧
+
+### Decision: 循环内部分步模拟，不引入新的状态累积
+
+**选择**：在 `ReplayPendingInputs` 循环内按 50ms 步长迭代调用 `ApplyTankMovementToPredictedState`。
+
+**实现方式**：
+```csharp
+private void ReplayPendingInputs(IReadOnlyList<PredictedMoveStep> replayInputs)
+{
+    const float serverStepSeconds = 0.05f;  // 50ms，服务端 SimulationInterval
+    foreach (var replayInput in replayInputs)
+    {
+        var remaining = replayInput.SimulatedDurationSeconds;
+        while (remaining > 0f)
+        {
+            var step = Mathf.Min(remaining, serverStepSeconds);
+            ApplyTankMovementToPredictedState(
+                replayInput.Input.TurnInput,
+                replayInput.Input.ThrottleInput,
+                step);
+            remaining -= step;
+        }
+    }
+    // ...
+}
+```
+
+**理由**：
+- 不改变 `PredictedMoveStep` 结构体接口，只修改消费方式
+- 无需新增临时状态变量
+- 逻辑清晰，与实时预测路径的积分形状完全一致
+
+## Risks / Trade-offs
+
+- **[风险]** 如果 `SimulatedDurationSeconds` 累计值有浮点误差，循环可能产生多一步或少一步的小偏差
+  - **缓解**：使用 `Mathf.Min(remaining, step)` 保护，最后一步自然截断；或对 `remaining -= step` 后加 epsilon 比较
+- **[风险]** 50ms 步长对极短的输入（比如只有一帧的输入）会产生额外计算
+  - **可接受**：额外一次函数调用，代价可忽略
@@ -0,0 +1,23 @@
+## Why
+
+本地回环测试中出现受控玩家（controlled player）持续小幅抖动。经分析，问题根源之一是回滚重放（replay）时积分粒度与实时预测不一致：实时预测在 FixedUpdate 中按 `Time.fixedDeltaTime`（20ms）逐步积分，而回放时把某个输入的累计时长一次性喂给 `ApplyTankMovementToPredictedState()`。Tank 运动学是非线性的——边转向边前进时，每步的旋转角影响下一步的前进方向，导致逐步积分和一次性积分的轨迹不同。这种偏差在每次对账后出现，被 visual correction 反复拉回，表现为细碎抖动。
+
+## What Changes
+
+1. **修改 `ReplayPendingInputs()` 的积分方式**：将一次性大时长积分改为固定步长的逐步积分，与 `FixedUpdate` 预测路径的积分形状完全一致
+2. **`PredictedMoveStep.SimulatedDurationSeconds` 的处理语义变更**：`SimulatedDurationSeconds` 仍记录该输入的总模拟时长，但 replay 时按服务端的 50ms 步长（`ServerAuthoritativeMovementConfiguration.SimulationInterval`）进行分步模拟
+3. **添加测试**：比较相同输入序列下逐步预测和回放预测的轨迹一致性，验证修复效果
+
+## Capabilities
+
+### New Capabilities
+- `client-prediction-replay-granularity`: 定义客户端回放预测与实时预测使用相同积分步长的行为约束和验证方式
+
+### Modified Capabilities
+- `client-gameplay-input`: 扩展 `ReplayPendingInputs` 的实现要求，明确回放必须使用固定步长逐步积分而非一次性累积积分
+
+## Impact
+
+- **涉及代码**：`Assets/Scripts/MovementComponent.cs` 中的 `ReplayPendingInputs()` 方法
+- **涉及测试**：`Assets/Tests/EditMode/Network/GameplayFlowRoundTripTests.cs` 或新建回归测试
+- **其他系统**：`PredictedMoveStep` 结构体（`ClientPredictionBuffer.cs`）的语义略有调整，但接口不变
@@ -0,0 +1,23 @@
+# client-gameplay-input Specification
+
+## MODIFIED Requirements
+
+### Requirement: Controlled client movement input preserves immediate prediction and explicit stop signaling
+
+The MVP client SHALL capture movement intent for the controlled player in Unity-side input code, apply local movement prediction immediately, and send `MoveInput` updates through the networking boundary. When movement input transitions from non-zero to idle, the client MUST send one final zero-vector `MoveInput` so authoritative movement can stop cleanly. When the client reconciles against authoritative state and replays pending `MoveInput` messages, the replay path MUST apply each pending input in fixed-duration substeps matching the server authoritative movement cadence, so that replay trajectory matches live prediction trajectory for the same input sequence.
+
+#### Scenario: Controlled player moves locally without waiting for the network
+- **WHEN** the controlled player provides non-zero movement input
+- **THEN** the client applies local movement prediction immediately for presentation
+- **THEN** the client submits a `MoveInput` carrying the current player id, tick, and planar movement vector through the networking send path
+
+#### Scenario: Releasing movement emits an explicit stop update
+- **WHEN** the controlled player releases movement input after previously providing non-zero movement
+- **THEN** the client sends exactly one final `MoveInput` whose movement vector is zero
+- **THEN** local predicted movement also stops immediately without waiting for authoritative correction
+
+#### Scenario: Replay uses fixed-step substeps matching server cadence
+- **WHEN** the client accepts an authoritative `PlayerState` and replays pending `MoveInput` messages
+- **THEN** each `PredictedMoveStep` is consumed by applying its input in fixed-duration substeps equal to the server authoritative movement cadence
+- **THEN** the replay accumulation shape is identical to the live FixedUpdate prediction path for the same input values
+- **THEN** non-linear trajectories (e.g. simultaneous turn-and-move) produce the same result in both replay and live prediction
@@ -0,0 +1,36 @@
+# client-prediction-replay-granularity Specification
+
+## Purpose
+
+Define the contract that client-side replay of pending movement inputs MUST use fixed-step accumulation matching the server authoritative movement cadence, not a single accumulated duration, so that replay trajectory matches live prediction trajectory for the same input sequence.
+
+## Requirements
+
+### Requirement: Replay uses fixed-step accumulation matching server cadence
+
+The controlled-client prediction replay path SHALL consume each pending `PredictedMoveStep` by applying its input in fixed-duration substeps equal to the server authoritative movement cadence, regardless of the step's total `SimulatedDurationSeconds`. The replay accumulation shape MUST be identical to the live `FixedUpdate` prediction path for the same input values.
+
+#### Scenario: Replay produces same trajectory as live prediction for steady input
+- **WHEN** the client replays a `PredictedMoveStep` with turn=0, throttle=1, duration=0.15s using a 0.05s server cadence
+- **THEN** the replay applies 0.05s + 0.05s + 0.05s substeps in sequence
+- **THEN** the final predicted position matches the position that would result from three consecutive FixedUpdate predictions of 0.05s each with the same input
+
+#### Scenario: Replay produces same trajectory as live prediction for turn-and-move input
+- **WHEN** the client replays a `PredictedMoveStep` with turn=0.5, throttle=1, duration=0.10s using a 0.05s server cadence
+- **THEN** the replay applies two 0.05s substeps where each substep's heading affects the next substep's forward direction
+- **THEN** the final predicted heading and position match the live prediction path for the same input sequence
+
+#### Scenario: Replay handles non-multiples of cadence interval
+- **WHEN** the client replays a `PredictedMoveStep` with duration=0.12s using a 0.05s cadence
+- **THEN** the replay applies 0.05s + 0.05s + 0.02s substeps sequentially
+- **THEN** no remaining duration is lost or double-counted
+
+### Requirement: Replay trajectory determinism is verifiable
+
+The client prediction system SHOULD provide a deterministic way to verify that replay and live prediction produce identical trajectories for a given input sequence, enabling regression coverage.
+
+#### Scenario: Replay and live prediction produce identical results
+- **WHEN** a controlled client records a `MoveInput` sequence during live play
+- **AND** the client triggers reconciliation and replays those same inputs
+- **THEN** the final predicted pose after replay equals the predicted pose that would result from live FixedUpdate simulation for the same input sequence
+- **THEN** the result is stable across multiple replays of the same input sequence
@@ -0,0 +1,23 @@
+## 1. 理解和实现
+
+- [x] 1.1 理解 `ApplyTankMovementToPredictedState` 的积分逻辑（旋转 → 前进方向的依赖关系）
+- [x] 1.2 理解当前 `ReplayPendingInputs` 的一次性积分行为与问题
+- [x] 1.3 在 `MovementComponent` 中引入服务端 `SimulationInterval` 的引用（50ms 步长常量）
+
+## 2. 修改 `ReplayPendingInputs` 实现
+
+- [x] 2.1 修改 `ReplayPendingInputs` 循环，将每个 `PredictedMoveStep` 的总时长按 50ms 步长分步模拟
+- [x] 2.2 添加浮点截断保护，确保所有时长都被消耗而无遗失
+- [x] 2.3 验证修改后的实现与 `FixedUpdate` 预测路径的积分形状一致
+
+## 3. 添加回归测试
+
+- [x] 3.1 在 `GameplayFlowRoundTripTests.cs` 或新建测试文件中添加轨迹一致性测试
+- [x] 3.2 测试用例：相同 turn+throttle 输入序列，逐步预测 vs 回放预测的最终位置和旋转相等
+- [x] 3.3 测试用例：非线性运动（同时转向和前进），验证逐步积分与一次性积分的结果不同
+- [x] 3.4 测试用例：非 50ms 倍数的总时长（如 0.12s），验证分步后无遗失
+
+## 4. 验证
+
+- [ ] 4.1 运行所有 EditMode 测试确保无回归（在 Unity Editor 内执行）
+- [ ] 4.2 本地回环验证抖动是否改善