merge develop into feat/galerie - resolve model and code conflicts

docs/user/editor.md

@@ -6,7 +6,7 @@ The map editor is available at `/editor`. It is a browser-based tool for editing
 
 Use the editor when you need to:
 
-- move, rotate, or scale objects from `public/map.json`
+- move, rotate, scale, add, or delete objects from `public/map.json`
 - inspect the raw JSON generated by the editor
 - preview and edit cinematics from `public/cinematics.json`
 - create, preview, and validate dialogue entries from `public/sounds/dialogue/dialogues.json`
@@ -14,13 +14,13 @@ Use the editor when you need to:
 
 The map editor reads the same map data as the runtime scene:
 
-- `public/map.json` contains the object list.
+- `public/map.json` contains the current hierarchical runtime map.
 - `public/models/{name}/model.glb` contains the matching 3D model for each object name. `model.gltf` is still supported as a fallback during migration.
 - Missing models are displayed as gray fallback cubes, so incomplete maps remain editable.
 
 ## Map Node Format
 
-Each entry in `public/map.json` represents one object:
+`public/map.json` is hierarchical. Group nodes such as `Scene`, `blocking`, `vegetation`, or `agriculture` organize the map. Editable object nodes still use the same transform fields:
 
 | Field      | Description                                       |
 | ---------- | ------------------------------------------------- |
@@ -45,18 +45,34 @@ Only the `Editor` group is open by default. Open the other groups when you need
 
 1. Open `/editor` in the local app.
 2. Click an object in the scene to select it.
-3. Choose a transform mode: translate, rotate, or scale.
-4. Drag the transform gizmo in the 3D view.
-5. Check the JSON inspector if you need exact values.
-6. Use undo or redo if the transform is not correct.
-7. Export the JSON or save it to the dev server.
+3. Use `Shift + right click` on other objects to add or remove them from the current multi-selection.
+4. Choose a transform mode: translate, rotate, or scale.
+5. Drag the transform gizmo in the 3D view. With multiple objects selected, the gizmo transforms the selected group and writes each object transform back to `map.json`.
+6. Keep `Snap terrain on move` enabled when placing objects on the terrain.
+7. Use `Center on object` or `Reset camera` from the `View` section when navigating large maps.
+8. Adjust scale numerically from the `Selection` section if the gizmo is not precise enough.
+9. Check the JSON inspector if you need exact values.
+10. Use undo or redo if the transform is not correct.
+11. Export the JSON or save it to the dev server.
+
+## Adding And Deleting Nodes
+
+Use `Add Node` to create a new editable object under the `blocking` group.
+
+- The new object starts as a fallback cube at `[0, 0, 0]`.
+- Name it with the model folder name you want, for example `maison1`.
+- If `public/models/{name}/model.glb` or `model.gltf` exists, saving and reloading will display the matching model.
+- If no matching model exists, the node stays editable as a gray cube.
+
+Use the trash button in `Selection` to delete the selected node from the map tree.
 
 ## Controls
 
 | Action               | Input                      |
 | -------------------- | -------------------------- |
 | Select object        | Click object               |
-| Deselect             | `Esc` or click empty space |
+| Toggle multi-select  | `Shift` + right click      |
+| Deselect             | `Esc`                      |
 | Lock selection       | `Lock` button in Selection |
 | Clear selection      | `X` button in Selection    |
 | Translate mode       | `T`                        |
@@ -73,14 +89,25 @@ Only the `Editor` group is open by default. Open the other groups when you need
 The `Selection` section shows the selected object name and its index in `public/map.json`.
 
 - Click an object to select it.
-- Click empty space or press `Esc` to clear the selection.
+- Use `Shift + right click` on objects to add or remove them from a multi-selection.
+- When several objects are selected, the gizmo appears on the selection group and applies translate, rotate, or scale to each selected node.
+- Press `Esc` to clear the selection.
 - Use the `X` button to clear the selection explicitly.
 - Use the `Lock` button to protect the current selection while editing.
+- Use the scale fields to edit X/Y/Z scale precisely.
+- Use the trash button to remove the selected object.
+
+## Terrain Snapping
+
+`Snap terrain on move` is enabled by default. When you move an object, the editor samples the terrain height at the object's X/Z position and updates its Y position.
+
+This is intended for map objects that should sit on the ground. Disable it when you intentionally need a floating object.
+
+`Lock terrain` is also enabled by default. The terrain stays visible, but terrain clicks are ignored so normal objects remain easier to select. Disable it only when you need to select or transform the terrain node itself.
 
 When selection is locked:
 
 - clicking another object does not change the selection
-- clicking empty space does not clear the selection
 - pressing `Esc` does not clear the selection
 - the `X` button still clears the selection intentionally
 
@@ -88,9 +115,11 @@ When selection is locked:
 
 The `Lock view` action switches the editor into a movement mode closer to the runtime player camera. Use it to navigate larger scenes while keeping the transform tools available.
 
+The camera action switches between `Center on object` and `Reset camera`. Selecting an object also focuses the camera on that object automatically.
+
 ## JSON Inspector
 
-The `JSON` section shows the raw map data that will be exported or saved:
+The `JSON` section shows the editable node data:
 
 - When no object is selected, it shows the full map node list.
 - When an object is selected, it highlights the JSON lines for that object.
@@ -101,11 +130,11 @@ Use it to verify exact numeric transform values before saving or exporting. The
 
 ### Export JSON
 
-`Export JSON` downloads the current map node list as `map.json`. Use this when you want to manually replace `public/map.json`.
+`Export JSON` downloads the current hierarchical map tree as `map.json`. Use this when you want to manually replace `public/map.json`.
 
 ### Save To Server
 
-`Save to server` is available only during local development. It writes the edited map back to `public/map.json` through the Vite dev-server endpoint.
+`Save to server` is available only during local development. It writes the edited hierarchical map back to `public/map.json` through the Vite dev-server endpoint.
 
 The button is hidden in production builds because production persistence is not implemented.
 

docs/user/features.md

@@ -37,7 +37,7 @@ This document lists the user-visible and developer-facing features implemented i
 - Input lock while the settings menu is open
 - Input lock while a cinematic is playing
 - Octree collision against dedicated map collision nodes, currently scoped to the `terrain` node
-- Repair movement-lock hook and indicator exist, but the hook currently returns `false`, so movement is not locked during repair on the current branch
+- Repair movement lock during focused repair steps, with a matching UI indicator
 
 ## Physics And Collision
 
@@ -63,12 +63,12 @@ This document lists the user-visible and developer-facing features implemented i
 
 ## Repair Gameplay
 
-- Reusable `RepairGame` mounted for `bike`, `pylone`, and `ferme`
+- Reusable `RepairGame` mounted for `ebike`, `pylon`, and `farm`
 - Mission progression driven by Zustand and shared `MissionStep` types
 - Production repair positions:
-  - `bike` at `[8, 0, -6]`
-  - `pylone` at `[64, 0, -66]`
-  - `ferme` at `[-24, 0, 42]`
+  - `ebike` at `[42.2399, 4.5484, 34.6468]`
+  - `pylon` at `[64, 0, -66]`
+  - `farm` at `[-24, 0, 42]`
 - Debug physics repair playground zones for all three missions
 - Data-driven mission config in `src/data/gameplay/repairMissions.ts`
 - Mission flow: `locked -> waiting -> inspected -> fragmented -> scanning -> repairing -> reassembling -> done`
@@ -80,9 +80,9 @@ This document lists the user-visible and developer-facing features implemented i
 - Fragmentation through repair-case trigger or two-fists hand gesture
 - Exploded model visualization through `ExplodableModel`
 - Scan visual that steps through exploded parts
-- Broken-part detection by configured `nodeName`, with fallback to first scanned parts
+- Broken-part detection by configured `nodeName`, with diagnostics when configured parts are missing
 - Persistent broken-part highlight and broken-part prompt after discovery
-- Grabbable replacement part choices, including decoys
+- Grabbable replacement part choices, including distractor parts
 - Grabbable broken parts that must be deposited back into the case
 - Snap-to-placeholder placement
 - Correct-part, wrong-part, and stored-part visual feedback
@@ -95,7 +95,7 @@ This document lists the user-visible and developer-facing features implemented i
 ## Game Progression Store
 
 - Zustand `useGameStore` for durable gameplay progression
-- Main states: `intro`, `bike`, `pylone`, `ferme`, `outro`
+- Main states: `intro`, `ebike`, `pylon`, `farm`, `outro`
 - Per-mission repair step state
 - Per-mission completion flags
 - Generic mission helpers: `setMissionStep`, `completeMission`, `advanceGameState`, `rewindGameState`, `resetGame`
@@ -108,12 +108,11 @@ This document lists the user-visible and developer-facing features implemented i
 - Music, SFX, and dialogue volume sliders
 - Subtitle visibility toggle
 - Subtitle language choice between French and English
-- Repair-runtime choice between JavaScript and Python modes stored in settings
 - Quit action that clears browser-accessible cookies and returns to `/`
 - Crosshair overlay
 - Interaction prompt
 - Subtitle overlay
-- Repair movement-lock indicator component, currently inactive because the lock hook returns `false`
+- Repair movement-lock indicator
 - Debug overlay layout
 - Scene loading overlay
 
@@ -192,7 +191,7 @@ This document lists the user-visible and developer-facing features implemented i
 - Debug game-state panel
 - Debug hand-tracking panel
 - Physics test scene with floor, grabbable object, trigger object, repair zones, and animated model preview
-- Animated `electricienne_animated` model preview restored in the debug physics scene
+- Animated `electricienne-animated` model preview restored in the debug physics scene
 
 ## Map And Content Editor
 
@@ -230,7 +229,7 @@ This document lists the user-visible and developer-facing features implemented i
 - Technical docs for architecture, scene runtime, repair game, interaction, editor, audio, hand tracking, Zustand, Three debugging, animation, and target architecture
 - User docs for implemented features, main feature, editor usage, and code-review preparation
 
-## Not Implemented Or Incomplete
+## Known Gaps
 
 - Complete production mission manager/orchestrator
 - Full mission HUD or minimap

docs/user/main-feature.md

@@ -8,7 +8,7 @@ The main feature is a reusable repair flow mounted in the production game scene.
 
 The current user flow is:
 
-1. Enter a mission state such as `bike`, `pylone`, or `ferme`.
+1. Enter a mission state such as `ebike`, `pylon`, or `farm`.
 2. Move close to the active repair object in the game scene.
 3. Aim at the object and press the interaction key when prompted.
 4. The mission step moves from `waiting` to `inspected`.
@@ -21,7 +21,7 @@ The current user flow is:
 11. Move each scanned broken part into a compatible placeholder so the damaged parts are stored in the case.
 12. Press `E` on the green install target to move to `reassembling`. Wrong parts turn the target red and cannot finish the repair.
 13. The exploded object animates back into its assembled form with completion particles, then moves to `done`.
-14. Press `E` on the completion target. The repair case closes, returns to the ground, disappears, then `completeMission` moves to the next mission or to `outro` after `ferme`.
+14. Press `E` on the completion target. The repair case closes, returns to the ground, disappears, then `completeMission` moves to the next mission or to `outro` after `farm`.
 
 ## Why It Matters
 
@@ -33,17 +33,17 @@ For implementation details, see `docs/technical/repair-game.md`.
 
 In `waiting`, the active mission renders its repair object and the `interagir.webm` prompt in the game scene. The interaction uses the shared focus/raycast interaction system, so the player still gets the normal `E` prompt.
 
-When the player inspects the object, `RepairGame` writes `inspected` through the generic mission store action. The repair case then appears from the mission config with a small pop animation. When the player is close enough, the case model floats upward and rotates gently to signal interactivity. The codebase also contains a shared repair movement-lock hook and HTML indicator, but `useRepairMovementLocked()` currently returns `false`, so movement remains available during the repair flow on the current branch.
+When the player inspects the object, `RepairGame` writes `inspected` through the generic mission store action. The repair case then appears from the mission config with a small pop animation. When the player is close enough, the case model floats upward and rotates gently to signal interactivity. The shared repair movement-lock hook and HTML indicator keep movement disabled during active repair steps.
 
 In `inspected`, `RepairGame` can also move to `fragmented`. Keyboard input goes through the shared focus/raycast interaction system on the repair case, so the player must be close enough and aim at the case before pressing `E`. The hand-tracking path still uses a two-fists hold gesture and is state-based, so it does not depend on being inside a local object interaction radius.
 
-In `fragmented`, the repair object is rendered with `ExplodableModel`, then automatically advances to `scanning`. In `scanning`, the exploded model remains visible, a blue scan visual moves from part to part, and a red halo/wire marker plus the configured broken UI video stay attached to configured broken parts after the scanner reaches them. The scan can match a specific `nodeName` when mission data provides one, otherwise it falls back to the first scanned parts as placeholder broken parts. In `repairing`, the case opens in a larger focused transform, `RepairCaseModel` traverses the case GLTF for empty nodes named `placeholder_*`, several grabbable replacement parts appear on those placeholder positions, and releasing a part near a placeholder snaps it into place with a short GSAP animation. Scanned broken parts are also rendered as grabbable objects and must be deposited into a compatible placeholder before the final install target validates. If `brokenParts[].placeholderName` is configured, that broken part snaps only to the matching placeholder; otherwise it can use any available placeholder. If the current case asset has no placeholder nodes, the flow keeps using fallback focus positions. Replacement parts show green or red placement feedback after snapping, broken parts show stored feedback after deposit, and the install target gives a short blocked feedback if the player tries to validate too early. The install target only validates when the configured correct replacement part is placed and all scanned broken parts have been deposited. In `reassembling`, the exploded model animates back into its assembled position with green completion particles before the flow moves to `done`. In `done`, the repaired object remains visible with a completion target; validating closes the repair case first, then plays the case exit animation before advancing the global mission progression.
+In `fragmented`, the repair object is rendered with `ExplodableModel`, then automatically advances to `scanning`. In `scanning`, the exploded model remains visible, a blue scan visual moves from part to part, and a red halo/wire marker plus the configured broken UI video stay attached to configured broken parts after the scanner reaches them. The scan matches configured broken parts by `nodeName` and reports diagnostics when a configured node is missing. In `repairing`, the case opens in a larger focused transform, `RepairCaseModel` traverses the case GLTF for empty nodes named `placeholder_*`, several grabbable replacement parts appear on those slot positions, and releasing a part near a slot snaps it into place with a short GSAP animation. Scanned broken parts are also rendered as grabbable objects and must be deposited into a compatible slot before the final install target validates. If `brokenParts[].caseSlotName` is configured, that broken part snaps only to the matching slot; otherwise it can use any available slot. If the current case asset has no slot nodes, the flow keeps using fallback focus positions and logs the fallback. Replacement parts show green or red placement feedback after snapping, broken parts show stored feedback after deposit, and the install target gives a short blocked feedback if the player tries to validate too early. The install target only validates when the configured correct replacement part is placed and all scanned broken parts have been deposited. In `reassembling`, the exploded model animates back into its assembled position with green completion particles before the flow moves to `done`. In `done`, the repaired object remains visible with a completion target; validating closes the repair case first, then plays the case exit animation before advancing the global mission progression.
 
-The mission config now carries the mission-specific variations. `bike` repairs one cooling core, `pylone` scans and stores both the lamp relay and a damaged panel with slower scan/reassembly timing, and `ferme` scans and stores an irrigation pump plus humidity sensor with faster scan/reassembly timing.
+The mission config now carries the mission-specific variations. `ebike` repairs one cooling core, `pylon` scans and stores both the lamp relay and a damaged panel with slower scan/reassembly timing, and `farm` scans and stores an irrigation pump plus humidity sensor with faster scan/reassembly timing.
 
 ## Key Files
 
-- `src/world/GameStageContent.tsx` mounts production `RepairGame` instances for `bike`, `pylone`, and `ferme`.
+- `src/world/GameStageContent.tsx` mounts production `RepairGame` instances for `ebike`, `pylon`, and `farm`.
 - `src/components/three/gameplay/RepairCompletionStep.tsx` renders the final repaired object, completion target, case exit animation, and mission UI prompt.
 - `src/components/three/gameplay/RepairGame.tsx` composes the reusable production repair flow.
 - `src/components/three/gameplay/RepairBrokenPartHighlight.tsx` renders the red halo and wire marker around detected broken parts during scanning.
@@ -56,16 +56,16 @@ The mission config now carries the mission-specific variations. `bike` repairs o
 - `src/components/three/gameplay/RepairPromptVideo.tsx` renders `.webm` prompts inside the 3D scene.
 - `src/components/three/gameplay/RepairScanSequence.tsx` keeps the exploded model visible and advances the scan from part to part.
 - `src/components/three/gameplay/RepairScanVisual.tsx` renders the scan halo and scan line around the active part.
-- `src/components/ui/RepairMovementLockIndicator.tsx` renders the HTML indicator intended for repair movement lock.
+- `src/components/ui/RepairMovementLockIndicator.tsx` renders the HTML repair movement-lock indicator.
 - `src/hooks/gameplay/useRepairFragmentationInput.ts` handles the `inspected -> fragmented` two-fists input and can optionally bind keyboard input for non-trigger flows.
 - `src/hooks/gameplay/useRepairMissionStep.ts` reads the active mission step from the game store.
-- `src/hooks/gameplay/useRepairMovementLocked.ts` exposes the shared repair movement-lock rule used by the player controller and UI indicator, but currently returns `false`.
+- `src/hooks/gameplay/useRepairMovementLocked.ts` exposes the shared repair movement-lock rule used by the player controller and UI indicator.
 - `src/hooks/handTracking/useBothFistsHold.ts` detects the reusable two-fists hold gesture.
 - `src/components/three/gameplay/RepairCaseModel.tsx` renders and animates the case model, and exposes `placeholder_*` transforms when the GLTF provides them.
 - `src/components/three/models/ExplodableModel.tsx` renders selectable models with split/exploded visualization.
 - `src/data/gameplay/repairCaseConfig.ts` stores repair case model, sound, and animation constants.
 - `src/data/gameplay/repairGameConfig.ts` stores repair flow timing constants.
-- `src/data/gameplay/repairMissions.ts` stores reusable repair mission config for `bike`, `pylone`, and `ferme`.
+- `src/data/gameplay/repairMissions.ts` stores reusable repair mission config for `ebike`, `pylon`, and `farm`.
 - `src/managers/stores/useGameStore.ts` stores mission progression state and generic mission step helpers.
 - `src/types/gameplay/repairMission.ts` contains shared repair mission ids, mission steps, and guards used by the store, data config, debug UI, and gameplay components.
 
@@ -73,7 +73,7 @@ The mission config now carries the mission-specific variations. `bike` repairs o
 
 The production repair flow currently requires:
 
-- the active `mainState` to be one of `bike`, `pylone`, or `ferme`
+- the active `mainState` to be one of `ebike`, `pylon`, or `farm`
 - `GameStageContent` mounted inside the game scene Rapier `Physics` boundary
 - model assets available under `public/models/`
 - sound assets available under `public/sounds/`