its functionning

.claude/launch.json

@@ -0,0 +1,11 @@
+{
+  "version": "0.0.1",
+  "configurations": [
+    {
+      "name": "dev",
+      "runtimeExecutable": "npm",
+      "runtimeArgs": ["run", "dev"],
+      "port": 5173
+    }
+  ]
+}

docs/technical/hand-tracking.md

@@ -10,23 +10,17 @@ It is now also available to the production repair flow when a mission reaches a
 
 ## Runtime Flow
 
-The frontend can run hand tracking with two interchangeable sources, selected from the debug source controller:
-
-- **Browser JS** (`src/hooks/handTracking/useBrowserHandTracking.ts`) runs MediaPipe `hand_landmarker.task` directly in the browser via `@mediapipe/tasks-vision`. Default for debug.
-- **Backend** (`src/hooks/handTracking/useRemoteHandTracking.ts`) sends webcam frames as JPEG over WebSocket to a local Python process that runs MediaPipe and returns landmarks.
-
-Both sources funnel into the same `HandTrackingContext` so all consumers see one shared snapshot:
-
-1. The active source captures or receives landmarks.
-2. The hook applies an EMA smoothing pass on the landmarks before publishing the snapshot.
-3. `HandTrackingProvider` exposes that snapshot through React context.
-4. `GrabbableObject` reads the snapshot each frame and uses the fist state plus raycasting to grab objects.
-5. `HandTrackingGlove` reads the same snapshot and places a rigged glove on each detected hand.
-6. `HandTrackingVisualizer` paints an SVG wireframe overlay on top of the canvas.
+1. The browser captures webcam frames in `src/hooks/handTracking/useRemoteHandTracking.ts`.
+2. Frames are sent to the local Python backend over WebSocket.
+3. The backend runs MediaPipe hand landmark detection.
+4. The backend returns hand data including landmarks, handedness, score, center point, and `isFist`.
+5. React stores the latest snapshot in the hand tracking provider.
+6. `GrabbableObject` reads that snapshot each frame and uses fist state plus raycasting to grab objects.
+7. `HandTrackingGlove` reads the same snapshot and places the rigged `gant_l` and `gant_r` models on the detected hands when hand tracking is active.
 
 ## Activation Rules
 
-Hand tracking is gated so the webcam and runtime are only spun up when actually needed.
+Hand tracking is intentionally gated so the webcam and backend are not used all the time.
 
 The debug activation conditions are:
 
@@ -34,26 +28,16 @@ The debug activation conditions are:
 - scene mode is `physics`
 - the player is near an interaction, is holding an object, or is hand-holding an object
 
+This keeps hand tracking active while the player is inside an interaction zone, even if the camera is not aimed directly at the object.
+
 The production repair activation conditions are:
 
 - active `mainState` is `ebike`, `pylon`, or `farm`
 - the active mission step is `inspected`, `repairing`, `reassembling`, or `done`
 
-This keeps the webcam off during `waiting`, `fragmented`, and `scanning`.
+This keeps the webcam off during `waiting`, `fragmented`, and `scanning`, then enables hand input only when the repair flow is expected to use hands.
 
-### Linger
-
-Once activation turns off (player walks back out of a trigger zone, or a mission step transitions away), the runtime stays alive for `HAND_TRACKING_LINGER_MS` (2000 ms) before being torn down. This gives MediaPipe enough time to finish initializing the webcam and load the model on a fresh entry — without the linger, a quick walk-through of a trigger zone never produces a detected hand.
-
-## Provider Stability
-
-`HandTrackingProvider` always renders the same JSX root (`HandTrackingRuntime`) and exposes `enabled` as a prop. Returning two different element types (`<HandTrackingContext value=IDLE>` vs `<ActiveHandTrackingProvider>`) used to be the historical shape and was the root cause of WebGL context loss: every `enabled` toggle forced React to remount the entire subtree, including the `<Canvas>`, which destroyed the WebGL renderer.
-
-The two source hooks are therefore mounted in permanence with an `enabled` flag that they early-return on. No webcam or MediaPipe resources are created while `enabled` is false.
-
-## StrictMode Resilience
-
-In development, `<StrictMode>` mounts → unmounts → remounts each effect to surface non-idempotent code. The two source hooks delay their actual `start()` call by `HAND_TRACKING_RUNTIME_START_DELAY_MS` (80 ms) and clear the timer on cleanup, so a StrictMode double-mount or a rapid `nearby` flicker never reaches `getUserMedia` twice.
+In the current production repair flow, `inspected` uses a two-fists hold gesture to advance to `fragmented`. The hold must last one second and is independent from local object interaction distance once the mission is in the correct state. Keyboard input for the same transition is handled separately by the repair case trigger, so pressing `E` requires the case to be focused through the shared interaction system.
 
 ## Backend
 
@@ -68,27 +52,7 @@ The Python process uses MediaPipe and the local model file:
 backend/hand_landmarker.task
 ```
 
-The frontend sends JPEG frames at `HAND_TRACKING_FRAME_WIDTH × HAND_TRACKING_FRAME_HEIGHT` (320×240) to keep WebSocket bandwidth low. The backend sends normalized hand coordinates and landmarks.
-
-## Browser MediaPipe
-
-The browser path uses `hand_landmarker.task` (float16) downloaded from Google's MediaPipe model storage. The requested webcam resolution is **640×480** (`HAND_TRACKING_BROWSER_CAMERA_WIDTH/HEIGHT`), independent from the backend's 320×240. The float16 model is more sensitive than the backend Python model and needs the higher-resolution frame to detect hands reliably.
-
-The MediaPipe delegate is currently `"GPU"`. CPU works too but is significantly slower; on a loaded scene the inference drops to ~5fps and the user feels noticeable lag during grab. MediaPipe creates its own WebGL context separate from Three.js, so there is no direct contention.
-
-A singleton instance of `HandLandmarker` is cached in `src/lib/handTracking/browserHandTracking.ts`. `releaseBrowserHandLandmarker()` is called on cleanup and on WebGL context lost.
-
-## Smoothing
-
-MediaPipe at ~10 fps produces noticeable landmark jitter that, when fed raw into the scene, makes both the glove rig and any grabbed object tremble.
-
-A simple exponential moving average is applied to every landmark before the snapshot is published:
-
-```ts
-smoothed.x = previous.x * (1 - factor) + next.x * factor;
-```
-
-The factor is `HAND_TRACKING_LANDMARK_SMOOTHING` (0.4). Hands are matched across frames by `handedness` so left/right don't bleed into each other.
+The backend sends normalized hand coordinates and landmarks. The frontend treats the values as screen-space inputs, then maps them into world space with the active Three.js camera.
 
 ## Frontend Data Shape
 
@@ -142,36 +106,24 @@ This is less expressive than true depth-aware hand movement, but it is more stab
 The current debug UI includes:
 
 - `HandTrackingDebugPanel` inside `DebugOverlayLayout` for status, usage, loaded glove model, server state, hand count, and fist state
-- `HandTrackingVisualizer` for the SVG landmark overlay
-- `HandTrackingFallback` for the last-resort hand silhouette overlay
-- `HandTrackingGlove` for the per-hand rigged glove models in the R3F scene
+- `HandTrackingVisualizer` for the SVG landmark wireframe fallback
+- `HandTrackingGlove` for the left-hand `gant_l` and right-hand `gant_r` models in the R3F scene
 - `r3f-perf` for render performance
 - `lil-gui` for scene, camera, lighting, interaction, and grab controls
 
-The SVG visualizer uses a "blueish hand" style: white connection lines between landmarks, cyan circles with a dark blue outline. The outline gets thicker when the hand is detected as a fist, so the user gets a visual confirmation of the grab gesture without having to look at the debug panel.
-
-The fallback overlay (`HandTrackingFallback`) draws a simple open-hand or fist silhouette positioned on the detected wrist landmark. It only renders for a hand whose matching glove is in the `"error"` state in `useHandTrackingGloveStatus`. This guarantees the user always sees something on their hand even when the 3D glove model fails to load.
+The hand tracking debug panel is a compact HTML grid outside the canvas. `Model loaded` displays the successfully loaded glove models. The SVG hand wireframe is only a fallback while models are loading or if a glove model fails to load.
 
 ## Glove Models
 
-`HandTrackingGlove` loads `public/models/gant_l/model.gltf` for both hands. The right hand applies `scale.x = -1` at the group level to mirror the mesh, so the thumb ends up on the correct side. Both hands therefore share the same rig and the same material.
+The current glove MVP uses `public/models/gant_l/model.gltf` and `public/models/gant_r/model.gltf`, which contain GLTF skins and armatures. Each model is positioned, oriented, and scaled from palm landmarks, then each finger bone chain is rotated toward the matching MediaPipe landmark chain.
 
-The historical `public/models/gant_r/model.gltf` is kept as legacy but is not loaded by the frontend — its GLB embeds three skeletons (`Hand_l`, `Hand_l_pad`, `Hand_r`) plus a `galet` mesh, which made the finger rig unreliable.
-
-The `gant_l` material is set to `alphaMode: OPAQUE` with `doubleSided: true`. The opaque mode prevents transparency sorting issues that made folded fingers disappear behind the palm; the double-sided flag covers the back faces revealed by the mirror scale on the right hand.
-
-Two additional glove variants exist on disk:
-
-- `public/models/gant_l_pad/model.gltf`
-- `public/models/gant_r_pad/model.gltf`
-
-They are intended for future swap-by-state usage but are **not yet rigged**. They cannot be animated by MediaPipe landmarks in their current form — re-exporting them from Blender with the same armature structure as `gant_l` is a prerequisite.
+The glove models are intentionally smaller than the raw SVG overlay so they do not dominate the camera view.
 
 ## Known Limitations
 
 - Production usage is currently limited to repair mission steps that explicitly need hands.
 - MediaPipe depth is relative and currently not used for stable object depth control.
 - The virtual hit zone is an approximation based on multiple raycasts, not a real 3D collider.
-- The right glove is a mirrored copy of `gant_l` rather than its own mesh; in the future a dedicated right-hand model would give a better visual.
-- The `_pad` glove variants are not rigged yet, so swap-by-state (normal ↔ pad) is not wired in.
+- There is no smoothing layer for hand position or depth yet.
+- The SVG hand visualization is a fallback, not the primary display when glove models load correctly.
 - Finger bone animation is an approximate landmark-to-bone mapping; it still needs calibration for per-model twist, offsets, and smoothing.

docs/technical/map-lod.md

@@ -25,7 +25,7 @@ Current behavior:
 | -------- | ------------------: | --- | ------------------------------------- |
 | `low`    |                 10m | On  | Always use `*-LOD` models             |
 | `medium` |                 20m | On  | Always use `*-LOD` models             |
-| `high`   |                 35m | Off | Regular model up to 10m, then `*-LOD` |
+| `high`   | Current default 50m | Off | Regular model up to 10m, then `*-LOD` |
 | `ultra`  |                 50m | Off | Regular model up to 20m, then `*-LOD` |
 
 The unload distance stays slightly larger than the load distance to avoid rapid mount/unmount flickering when the player stands near a boundary.

docs/technical/map-performance.md

@@ -158,11 +158,9 @@ Current runtime values:
 
 ```txt
 chunkSize: 35
-low load/unload radius: 10m / 18m
-medium load/unload radius: 20m / 30m
-high load/unload radius: 35m / 45m
-ultra load/unload radius: 50m / 65m
-updateInterval: 250ms
+loadRadius: 45
+unloadRadius: 45
+updateInterval: 350ms
 fog near: 30
 fog far: 45
 ```

docs/technical/scene-runtime.md

@@ -74,32 +74,22 @@ It tracks:
 - `gameMapLoaded`: map data and visible map nodes settled
 - `gameStageLoaded`: Rapier gameplay stage mounted
 - `showGameStage`: true when the map is ready enough to mount gameplay content
-- `gameplayReady`: true when map, stage, and octree are all ready
+- `shadowsReady`: renderer, shadow lights, and scene matrices have been forced once after the scene is mounted
+- `gameplayReady`: true when map, stage, octree, and the shadow warmup are all ready
 
-The game-scene readiness condition is:
+The base game-scene readiness condition before the shadow warmup is:
 
 ```ts
 showGameStage && gameStageLoaded && octree !== null;
 ```
 
-Shadows are configured once when `Lighting` mounts (renderer `shadowMap.enabled`, sun
-`shadow.autoUpdate = true`, bias and frustum from `SHADOW_CONFIG` in
-`src/data/world/lightingConfig.ts`). The shadow map then refreshes every frame and
-follows the player camera through the sun's `target`. The earlier `SceneShadowWarmup`
-step has been removed — the visible loading overlay no longer waits for a forced
-shadow refresh because `autoUpdate` covers steady-state rendering.
+After that condition is met, `SceneShadowWarmup` runs one final loading step:
 
-### Avoiding global scene remounts
+```txt
+Activation des ombres -> Ombres prêtes -> Gameplay prêt
+```
 
-Heavy stage components (`GameStageContent`, `Player`, dialogues) load assets via
-`useGLTF`/`useTexture` without preload (e.g. `EbikeSpeedometer` calls `useTexture`
-when the bike mounts). To prevent any late suspension from bubbling up to the
-root `<Suspense>` boundary in `src/pages/page.tsx` and unmounting the entire
-world (which would trigger a redundant octree rebuild and shadow re-config), the
-game stage block and the spawn-player block are wrapped in their own
-`<Suspense fallback={null}>` boundaries inside `src/world/World.tsx`. Any new
-sibling that suspends late should be added inside one of these boundaries or get
-its own.
+This keeps the loading overlay visible until the renderer shadow map, shadow-casting light, and mounted scene graph have all been explicitly refreshed.
 
 The debug physics scene is ready when:
 

docs/technical/three-debugging.md

@@ -20,63 +20,3 @@ If DevTools still opens a bundled file, stop the dev server, clear Vite's cached
 rm -rf node_modules/.vite
 npm run dev:three-debug
 ```
-
-## Visual debug toggles
-
-The `Debug` folder of the runtime debug GUI exposes inspection toggles backed by
-`src/managers/stores/useDebugVisualsStore.ts`:
-
-- **Show Player Model** — renders the main character GLTF in front of the
-  current camera (`src/components/debug/DebugPlayerModel.tsx`). The model is
-  positioned in camera-local space so it stays visible regardless of pitch.
-- **Show Octree** — overlays the collision octree as colored line segments,
-  one wireframe per spatial cell (`src/components/debug/DebugOctreeVisualization.tsx`).
-  Cells are colored by depth. Use it to inspect collision precision around
-  doorways or passages.
-- **Octree Max Depth** — caps how deep the octree visualization recurses
-  (default 6). Increase to see leaf-level subdivisions; decrease to keep the
-  scene readable when the tree is large.
-
-The octree visualization reads the live `Octree` instance from `World`. The
-mesh uses `depthTest: false` and a high `renderOrder`, so cells stay visible
-through opaque geometry.
-
-## Shadow rendering intermittence
-
-Shadows occasionally failed to render on initial load and could disappear
-mid-session even though the `Lighting` configuration ran to completion. The
-fix has two layers:
-
-### Per-frame refresh (steady state)
-
-The sun follows the camera, so its world matrix is dirty every frame. With
-`shadow.autoUpdate` alone, three.js can skip the shadow map re-render on a
-frame where the matrix update has happened but the renderer's internal dirty
-tracking does not pick it up. To prevent that, `Lighting.useFrame` sets
-`sun.shadow.needsUpdate = true` after the per-frame matrix updates. Shadow
-config is centralized in `src/data/world/lightingConfig.ts` (`bias=0`,
-`normalBias=0`, `cameraSize=95`).
-
-### Mount-time shadow map reallocation (`useShadowMapWarmup`)
-
-The merged static map and other GLTFs mount imperatively after `Lighting`,
-so the shadow render target ends up linked to a renderer state that pre-dates
-the final scene. Materials compiled at that point bake a "no shadow map"
-permutation into their shader program and silently fail to render shadows
-until a WebGL context-restore cycle (the kind triggered by Chrome DevTools
-in `?debug` runs) reallocates everything.
-
-`src/hooks/three/useShadowMapWarmup.ts` replays that cycle programmatically
-without the cost of a full context loss. It runs a `useFrame` watchdog that
-samples the scene mesh count every 6 frames; once the count has been stable
-for ~1 s (or after a 5 s safety cap), it:
-
-1. Disposes the directional light shadow map and nulls it. three.js
-   reallocates the render target on the next render at the configured
-   `mapSize`.
-2. Marks every material's `needsUpdate = true`, forcing a shader recompile
-   that rebinds every program to the freshly created shadow sampler.
-3. Forces a single shadow pass and invalidates the renderer.
-
-The watchdog runs once per mount and adds a single traversal every 6 frames
-during the warmup window, after which it self-terminates.