RUDPClient/openspec/changes/archive/2026-03-28-preserve-dual-transport-runtime-wiring/specs/shared-network-foundation/spec.md

MODIFIED Requirements

Requirement: Shared core preserves current transport and message contracts

The shared client/server foundation SHALL preserve the envelope-based business-message contract across client and server hosts while allowing delivery-policy selection behind the shared message-routing layer. Reliable control traffic MUST continue to use the existing ITransport contract, and high-frequency sync traffic MUST remain composable by supplying a second host-agnostic sync transport instance to SharedNetworkRuntime or ServerNetworkHost rather than by expanding ITransport for MVP-specific lane semantics. The shared message-type contract MUST allow hosts to distinguish MoveInput, ShootInput, CombatEvent, and PlayerState as separate business messages across both delivery lanes.

Scenario: Shared runtime starts distinct reliable and sync transports

• WHEN a client host constructs SharedNetworkRuntime with one reliable transport and a different sync transport instance
• THEN starting the runtime starts both transport instances
• THEN stopping the runtime stops both transport instances while keeping the same shared message-routing contract

Scenario: Server host composes both transport lanes without protocol forks

• WHEN a server host constructs ServerNetworkHost with one reliable transport and a different sync transport instance
• THEN it observes inbound activity from both transport lanes through shared host logic
• THEN it routes messages with the same envelope and message-type contract instead of defining a lane-specific protocol fork

Scenario: Shared hosts exchange the same envelope format across delivery lanes

• WHEN a client host sends a business message through either the reliable control path or the high-frequency sync path
• THEN the payload is encoded with the same shared envelope and message-type contract
• THEN the server host decodes and routes it through shared networking logic without a host-specific protocol fork

Scenario: Hosts preserve dual-transport composition outside ITransport

• WHEN a host needs separate reliable and sync lanes for MVP gameplay traffic
• THEN it provides separate transport instances plus delivery-policy configuration to shared runtime or host entry points
• THEN the shared networking core does not require ITransport itself to grow MVP-specific multi-lane APIs