process TODO.md step 10

2026-03-29 12:43:57 +08:00
parent c5fbd8e36d
commit fbc09186f3
21 changed files with 913 additions and 19 deletions
@@ -0,0 +1,28 @@
+# build-test-verification Specification
+
+## Purpose
+
+Define the runnable local environment and recorded CLI verification result required to close the final MVP build/test verification step.
+
+## Requirements
+
+### Requirement: Runnable CLI verification environment
+The repository SHALL define step 10 completion in terms of a local environment that can execute the documented `dotnet build` and `dotnet test` commands for `Network.EditMode.Tests.csproj` without failing due to a missing required .NET runtime.
+
+#### Scenario: Environment is suitable for verification
+- **WHEN** a maintainer performs the final MVP verification pass
+- **THEN** the environment used for that pass MUST contain the runtime needed to execute the documented CLI build and test commands
+- **AND** the verification record MUST distinguish environment readiness issues from actual build or test failures
+
+### Requirement: Build and test commands are re-run and recorded
+The repository SHALL re-run the documented edit-mode CLI verification commands and record the actual outcome for the current MVP networking codebase.
+
+#### Scenario: Build and test both succeed
+- **WHEN** `dotnet build Network.EditMode.Tests.csproj -v minimal` succeeds and `dotnet test Network.EditMode.Tests.csproj --no-build -v minimal` succeeds
+- **THEN** project tracking MUST mark the build/test verification step complete
+- **AND** the recorded result MUST state that the edit-mode network test suite passed in the runnable environment
+
+#### Scenario: Verification succeeds with warnings
+- **WHEN** the documented build and test commands succeed but emit non-fatal warnings
+- **THEN** the recorded result MUST preserve the warnings as part of the verification summary
+- **AND** the step MUST still be considered complete because the commands passed
@@ -0,0 +1,35 @@
+# gameplay-flow-regression-coverage Specification
+
+## Purpose
+Define the required edit-mode regression coverage that protects the MVP gameplay flow from client gameplay input through authoritative server outputs and client-side application.
+
+## Requirements
+### Requirement: Gameplay-flow regressions cover client gameplay send and receive paths
+The edit-mode regression suite SHALL cover the MVP client gameplay flow above the raw transport router, including `ShootInput` send routing and authoritative `CombatEvent` receive/apply behavior. Lane-policy assertions that belong to `MessageManager` MAY remain in `MessageManagerTests`, but gameplay-flow assertions MUST live in tests that exercise the client runtime or player-facing application path.
+
+#### Scenario: Client fire intent regression proves dedicated `ShootInput` routing
+- **WHEN** the controlled client gameplay path is exercised in an edit-mode regression test for a fire action
+- **THEN** the test observes a `ShootInput` payload sent through the dedicated client shooting path
+- **THEN** any lane-policy assertion in that flow remains limited to confirming the MVP reliable-lane contract rather than replacing broader gameplay-flow coverage
+
+#### Scenario: Authoritative combat event regression proves client-side application
+- **WHEN** an edit-mode regression test delivers an authoritative `CombatEvent` into the client gameplay receive path
+- **THEN** the relevant player-owned authoritative state, presentation model, or diagnostics surface reflects the authoritative hit, damage, death, or rejection result
+- **THEN** the test proves the outcome is applied from server truth rather than speculative local combat logic
+
+### Requirement: Gameplay-flow regressions cover remote authoritative snapshot decisions
+The edit-mode regression suite SHALL cover the client path that buffers and consumes remote authoritative `PlayerState` snapshots, including stale rejection and interpolation/clamp behavior where practical.
+
+#### Scenario: Remote interpolation regression proves buffering and stale rejection
+- **WHEN** an edit-mode regression test feeds ordered and stale remote `PlayerState` snapshots into the client remote-player path
+- **THEN** the test observes that newer authoritative snapshots enter the remote buffer while stale snapshots do not replace newer accepted state
+- **THEN** the test verifies the resulting interpolation or latest-snapshot clamp decision matches the MVP remote-presentation rules
+
+### 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.
+
+#### 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 combined test protects both client single-session input flow and server multi-session authoritative behavior from regression