process TODO.md

openspec/specs/network-sync-strategy/spec.md

@@ -5,21 +5,21 @@ Define how client and server route high-frequency gameplay synchronization traff
 
 ## Requirements
 ### Requirement: Hosts assign delivery policies to synchronization message types
-The shared networking core SHALL allow hosts to map business message types to delivery policies. `MoveInput` and `PlayerState` MUST be assignable to a high-frequency sync policy that is independent from the reliable ordered control policy used by login and lifecycle traffic, while `ShootInput` and `CombatEvent` MUST remain independently routable business messages that can stay on the reliable ordered lane.
+The shared networking core SHALL allow hosts to map business message types to delivery policies. The default shared resolver used by `MessageManager` MUST map `MoveInput` and `PlayerState` to `HighFrequencySync`, while `ShootInput`, `CombatEvent`, and control-plane messages MUST resolve to `ReliableOrdered` unless a host intentionally supplies a different resolver.
 
-#### Scenario: High-frequency movement and state messages use a dedicated policy
-- **WHEN** the client or server sends `MoveInput` or `PlayerState`
-- **THEN** the runtime resolves a high-frequency sync delivery policy for that message type
-- **THEN** the message is sent through the sync lane configured for that policy instead of defaulting to reliable ordered delivery
+#### Scenario: Default resolver sends movement and state traffic to the sync lane
+- **WHEN** the runtime uses `DefaultMessageDeliveryPolicyResolver` to send `MoveInput` or `PlayerState`
+- **THEN** the resolver returns `HighFrequencySync`
+- **THEN** `MessageManager` sends that envelope through the sync transport lane when one is configured
 
-#### Scenario: Shooting and combat events keep reliable ordered delivery
-- **WHEN** the client or server sends `ShootInput` or `CombatEvent`
-- **THEN** the runtime resolves the reliable ordered delivery policy for that message type
-- **THEN** those messages continue to use the reliable transport path
+#### Scenario: Default resolver keeps shooting and combat events on the reliable lane
+- **WHEN** the runtime uses `DefaultMessageDeliveryPolicyResolver` to send `ShootInput` or `CombatEvent`
+- **THEN** the resolver returns `ReliableOrdered`
+- **THEN** `MessageManager` sends that envelope through the reliable transport lane
 
-#### Scenario: Control traffic keeps reliable delivery
-- **WHEN** the runtime sends login, logout, heartbeat, or other session-management messages
-- **THEN** the runtime resolves the reliable ordered control policy
+#### Scenario: Default resolver preserves reliable control traffic
+- **WHEN** the runtime uses `DefaultMessageDeliveryPolicyResolver` to send login, logout, heartbeat, or other session-management messages
+- **THEN** the resolver returns `ReliableOrdered`
 - **THEN** those messages continue to use the reliable transport path
 
 ### Requirement: Sequenced sync receivers discard stale gameplay updates

openspec/specs/shared-network-foundation/spec.md

@@ -31,17 +31,27 @@ The shared message-routing layer SHALL execute received business handlers throug
 - **THEN** the shared message-routing layer still processes received messages correctly through that host-selected strategy
 
 ### 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 be composable through a host-agnostic sync strategy without introducing Unity-specific runtime types into the shared networking core. The shared message-type contract MUST allow hosts to distinguish `MoveInput`, `ShootInput`, `CombatEvent`, and `PlayerState` as separate business messages across both delivery lanes.
+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 compose delivery-policy selection without Unity dependencies
-- **WHEN** a non-Unity server host constructs the runtime networking stack with reliable control traffic and a high-frequency sync lane
-- **THEN** it uses shared delivery-policy abstractions without depending on Unity frame-loop types
-- **THEN** the Unity client can use the same abstractions while still supplying its own host-specific dispatch behavior
+#### 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
 
 #### Scenario: Shared hosts route split gameplay message identities consistently
 - **WHEN** client or server code sends `MoveInput`, `ShootInput`, `CombatEvent`, or `PlayerState`