Working on the server

GAME_STATE_ARCHITECTURE.md

@@ -8,12 +8,13 @@ This refactor does **not** add multiplayer networking. It establishes the state
 
 ## Architecture Overview
 
-The architecture has four layers:
+The architecture has five layers:
 
 1. `GameState` is the aggregate root for persistent, authoritative state.
 2. `InternalGameServer` owns `GameState`, advances the local simulation, handles commands, and produces immutable snapshots.
-3. Runtime objects hold rendering resources. `Character` and `Location` read immutable server snapshots by stable ID, while `InteractiveObject` still uses a transitional non-owning binding to server-owned state. `Location` also translates local input, scripts, and collision results into semantic server commands.
-4. Client-facing systems such as `MenuManager` read immutable snapshots and submit typed commands through `IGameServer`.
+3. `ClientLocationState` owns per-client `LocationLocalState` records, including camera orientation. Graphical hosts own this state; it is never replicated.
+4. Runtime objects hold rendering resources. `Character` and `Location` read immutable server snapshots by stable ID, while `InteractiveObject` still uses a transitional non-owning binding to server-owned state. `Location` also translates local input, scripts, and collision results into semantic server commands.
+5. Client-facing systems such as `MenuManager` read immutable snapshots and submit typed commands through `IGameServer`.
 
 ```text
 Input / UI
@@ -69,7 +70,7 @@ lookup and simulation to treat every campaign player by stable ID.
 
 Each location record owns:
 
-- One `LocationState`.
+- One `LocationNetworkState`.
 - NPC `CharacterState` objects keyed by configured ID.
 - `InteractiveObjectState` objects keyed by configured ID.
 - Trigger-zone enabled/inside flags.
@@ -193,7 +194,7 @@ Gameplay operations mutate the authoritative `CharacterState`, not the runtime
 `Character`:
 
 - `setTarget()` normalizes the destination, avoids redundant requests, stores the
-  optional Lua arrival function name, and asks the authoritative `LocationState` to
+  optional Lua arrival function name, and asks the authoritative `LocationNetworkState` to
   call `planPathExceptMyself()`.
 - `forceReplan()` recalculates the current requested destination using the same
   location navigation state.
@@ -210,7 +211,10 @@ collision handling, and presentation-event processing.
 
 Runtime visual objects do not own their authoritative state objects.
 
-- `Location` keeps only its `IGameServer` reference and stable location ID. It resolves its immutable `LocationState` view from `IGameServer::snapshot()`.
+- `Location` keeps its `IGameServer` reference, stable location ID, and a shared
+  `LocationLocalState` supplied by the graphical host. It resolves its immutable
+  `LocationNetworkState` view from `IGameServer::snapshot()`, while rendering and
+  camera input access the local state directly.
 - `Character` keeps only its `IGameServer` reference plus stable entity and location IDs. It resolves the player-first character view from `IGameServer::snapshot()`.
 - `InteractiveObject` keeps a private non-owning reference to its `InteractiveObjectState`; its configured object name is its stable ID.
 
@@ -224,9 +228,10 @@ and presentation or input work is skipped.
 The authoritative state objects are owned by `GameState` or `LocationGameState`.
 The internal server advances them before publishing a new snapshot revision.
 Runtime input, scripts, and collision handling submit semantic commands that invoke
-authoritative character and location operations. Location commands cover camera
-orientation, pending interaction targets, navigation switching and area changes,
-editor obstacles, and taxi reset. No whole-location commit command is exposed.
+authoritative character and location operations. Location commands cover pending
+interaction targets, navigation switching and area changes, editor obstacles, and
+taxi reset. Camera orientation is deliberately not a server command. No
+whole-location commit command is exposed.
 
 Navigation target selection, replanning, stopping, facing, death reset, health
 assignment, and attack-combo clock changes are implemented by `CharacterState`.
@@ -268,7 +273,7 @@ The normal frame flow is:
 4. Attack impacts are queued, then damage is applied after all characters advance.
 5. The runtime location consumes value-only events. Navigation requests are sent
    back as semantic destination commands, whose server handler calls
-   `CharacterState::setTarget()` with the authoritative `LocationState`; arrival
+   `CharacterState::setTarget()` with the authoritative `LocationNetworkState`; arrival
    function names are resolved through `ScriptEngine`.
 6. The server invalidates its cached snapshot and advances the revision so runtime
    presentation can observe the completed simulation tick.
@@ -326,8 +331,11 @@ The player state remains campaign-level and survives location changes.
 
 ## Save and Load Schema
 
-Persistence uses one strict, versioned schema. `schemaVersion` is required and
-unsupported versions are rejected rather than migrated.
+Authoritative persistence uses one strict, versioned schema. `schemaVersion` is
+required and unsupported versions are rejected rather than migrated. A
+single-player save is a separate versioned envelope containing `networkState`
+(the authoritative `GameState` JSON) and `localState` (the client-local location
+map). WebSocket replication sends only the authoritative document.
 
 - Campaign players are stored once in an ID-keyed `players` object.
 - Locations are keyed by location ID.
@@ -453,7 +461,8 @@ cmake --build proj-windows/build --config Debug --target ShadowOverBishkekDemo -
 ## Main Files
 
 - `src/GameState.h` / `src/GameState.cpp` — aggregate state and top-level persistence.
-- `src/LocationGameState.h` / `src/LocationGameState.cpp` — typed location state, simulation, and ID-keyed persistence.
+- `src/LocationState.h` / `src/LocationState.cpp` — separate local camera and authoritative network location records, plus single-player persistence composition.
+- `src/LocationGameState.h` / `src/LocationGameState.cpp` — authoritative typed location state, simulation, and ID-keyed persistence.
 - `src/content/LocationDefinition.h` / `.cpp` — renderer-free content definitions,
   parsing, and animation metadata loading.
 - `src/game_server/IGameServer.h` — public snapshot and command contract.