add: repair game inspection sub state

docs/technical/architecture.md

@@ -15,7 +15,7 @@ This document describes the code that exists today in the repository.
   - either the map scene or the debug physics test scene
   - the player rig when the active camera mode is `player`
 - `src/world/GameMap.tsx` loads map nodes from `public/map.json`, resolves available models, and builds the collision octree.
-- `src/world/GameStageContent.tsx` is wrapped in Rapier `Physics` in the production game scene so stage gameplay objects can use physics without moving the map or player to Rapier.
+- `src/world/GameStageContent.tsx` is wrapped in Rapier `Physics` in the production game scene so stage gameplay objects can use physics without moving the map or player to Rapier. It now mounts reusable `RepairGame` instances for `bike`, `pylone`, and `ferme` mission states.
 - `src/world/debug/TestMap.tsx` provides a debug-oriented interaction and physics map.
 - `src/world/player/Player.tsx` mounts the camera and controller.
 - `src/world/player/PlayerController.tsx` owns pointer lock movement, jump handling, and interaction input.
@@ -62,7 +62,7 @@ Keep the player and map octree outside the Rapier provider until there is a deli
 - `src/components/three/models/` contains reusable model helpers such as `ExplodableModel`.
 - `src/components/three/interaction/` contains reusable interaction wrappers such as `InteractableObject`, `TriggerObject`, and `GrabbableObject`.
 - `src/components/three/handTracking/` contains R3F hand tracking debug models such as the glove overlays.
-- `src/components/three/gameplay/` contains the current core repair gameplay prototype: the repair case, repair game zone, and module slots.
+- `src/components/three/gameplay/` contains the repair gameplay components: the reusable production `RepairGame` flow, the repair case, the debug repair game zone, and module slots.
 - `src/components/three/world/` contains reusable world/environment objects such as `SkyModel`.
 
 ## Editor System
@@ -90,6 +90,6 @@ Keep the player and map octree outside the Rapier provider until there is a deli
 - The repository is a prototype, not the full intended game runtime.
 - `src/world/debug/TestMap.tsx` is part of the active scene composition.
 - There is no central gameplay orchestrator such as `GameManager`.
-- Missions, zones, cinematics, and dialogue systems are not implemented.
+- The mission state exists in Zustand, but zones, cinematics, dialogue, and the full repair sequence are not implemented.
 - The player uses octree collision and simple movement rules, not a complete gameplay physics stack.
 - Editor save-to-server is implemented as a Vite dev-server plugin, not a production backend API.

docs/technical/zustand.md

@@ -130,6 +130,14 @@ This keeps reusable gameplay components such as repair flows from duplicating mi
 
 `src/world/GameStageContent.tsx` subscribes to `mainState` and mounts stage-specific content.
 
+For repair missions, it mounts the reusable `RepairGame` component with a mission id:
+
+```tsx
+<RepairGame mission="bike" position={[8, 0, -6]} />
+```
+
+`RepairGame` reads the active mission step from the store and writes transitions through generic actions such as `setMissionStep`. This keeps the scene component small and avoids mission-specific branching inside the repair flow.
+
 That means the scene can progressively move toward this pattern:
 
 ```tsx
@@ -173,4 +181,4 @@ Current overlays:
 
 ## Next Steps
 
-The next natural step is to replace the temporary stage anchors in `GameStageContent` with real stage components, for example `IntroContent`, `BikeContent`, `PyloneContent`, `FermeContent`, and `OutroContent`.
+The next natural step is to extend `RepairGame` beyond `waiting -> inspected` with fragmentation, scanning, repairing, and completion behavior.