player connect-disconnect

GAME_STATE_ARCHITECTURE.md

@@ -147,10 +147,12 @@ Snapshots have a monotonically increasing revision. `InternalGameServer` caches
 - Trigger-zone state.
 - Quest-definition reloads.
 
-The remote implementation currently serializes only
-`SetCharacterDestinationCommand` as player intent. The server derives the
+The remote implementation serializes destination intent from clients, while
+the server emits connection-lifecycle presence commands. The server derives the
 character and location from the assigned connection slot; arbitrary state
 mutation commands are not accepted from the network.
+`SetCharacterEnabledCommand` is consumed by the server and replicated to every
+client in the ordered tick bundle when a slot connects or disconnects.
 
 ### Presentation events
 
@@ -407,6 +409,9 @@ server interface. They can remain empty or disabled in multiplayer mode as plann
 Protocol v2 uses server-sequenced deterministic lockstep:
 
 - The server assigns a connection to a preconfigured campaign player slot.
+- Player slots are disabled in the authoritative initial state. A successful
+  connection schedules `SetCharacterEnabledCommand(enabled=true)` for the next
+  lockstep tick; disconnect schedules the corresponding `enabled=false` command.
 - Connection receives one authoritative state at a completed tick plus its
   assigned player ID, tick duration, input delay, and compatibility fingerprint.
 - Destination input is normalized and scheduled two ticks in the future.
@@ -424,7 +429,8 @@ there is no prediction or rollback.
 
 Current boundaries remain:
 
-- only `SetCharacterDestinationCommand` crosses the network;
+- client intent is limited to `SetCharacterDestinationCommand`; server presence
+  changes use `SetCharacterEnabledCommand` in tick bundles;
 - player characters must already exist in the initial state and campaign slot
   list; dynamic spawning and reconnect history are not implemented;
 - authentication and automatic checkpoint resynchronization are absent;