RUDPClient/openspec/changes/archive/2026-03-29-re-verify-build-and-test/design.md

Context

The repository's MVP networking and gameplay-flow work is already implemented and covered by edit-mode tests, but TODO step 10 remains open until the build and test commands are re-run in an environment that actually contains the required .NET runtime. The change is intentionally narrow: it does not introduce new gameplay behavior, only a final verification pass and a recorded outcome in project tracking.

Goals / Non-Goals

Goals:

• Define a repeatable verification path for the repository's edit-mode build and test commands.
• Re-run the existing CLI commands in a runnable local environment instead of leaving the result inferred from partial or blocked attempts.
• Record the actual outcome, including any remaining warnings, in the TODO and change tracking.

Non-Goals:

• Introducing new runtime, gameplay, or transport behavior.
• Expanding the regression suite beyond what step 9 already added.
• Solving unrelated SDK or editor installation issues outside what is minimally needed to run the verification commands.

Decisions

Decision: Treat this as a verification-only change

This change stays focused on environment readiness, command execution, and result recording. That keeps the scope aligned with TODO step 10 and avoids reopening already-implemented gameplay work.

Alternative considered: Roll environment fixes and additional code cleanup into the same change. Rejected because it would blur whether a failure came from verification setup or from new functional modifications.

Decision: Verify the exact documented commands

The source of truth remains the repository commands already documented in AGENTS.md and TODO.md:

• dotnet build Network.EditMode.Tests.csproj -v minimal
• dotnet test Network.EditMode.Tests.csproj --no-build -v minimal

Alternative considered: Use ad hoc command variants or Unity editor-driven test execution. Rejected because the TODO explicitly calls for these CLI verification steps.

Decision: Record warnings separately from pass/fail status

If build and test succeed but still emit known Unity dependency warnings, the recorded result should preserve that nuance instead of flattening everything into a generic success line.

Alternative considered: Ignore warnings once commands pass. Rejected because the TODO asks for the actual result, not a simplified interpretation.

Risks / Trade-offs

• [Environment drift] -> The runtime available on the current machine may differ from prior attempts. Mitigation: record the actual command outcome from the environment used for this change.
• [Over-scoping] -> Verification-only work can accidentally turn into general cleanup. Mitigation: limit edits to tracking/docs unless command failures expose a clear regression that must be fixed to complete step 10.
• [False confidence] -> A successful CLI run does not prove every Unity editor path. Mitigation: keep the scope explicit: this change verifies the documented build/test path, not all editor execution modes.