add: repair mission completion step

docs/technical/zustand.md

@@ -136,7 +136,7 @@ For repair missions, it mounts the reusable `RepairGame` component with a missio
 <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. The production repair flow currently supports `waiting -> inspected -> fragmented -> scanning -> repairing -> done` state transitions.
+`RepairGame` reads the active mission step from the store and writes transitions through generic actions such as `setMissionStep` and `completeMission`. This keeps the scene component small and avoids mission-specific branching inside the repair flow. The production repair flow currently supports `waiting -> inspected -> fragmented -> scanning -> repairing -> done -> next mission` state transitions.
 
 That means the scene can progressively move toward this pattern:
 
@@ -181,4 +181,4 @@ Current overlays:
 
 ## Next Steps
 
-The next natural step is to move repair validation from this local scene interaction into richer mission data when each mission has distinct broken module nodes and replacement assets.
+The next natural step is to move repair validation from this local scene interaction into richer mission data when each mission has distinct broken module nodes, replacement assets, and narrative completion beats.

docs/user/features.md

@@ -31,7 +31,7 @@ This document lists features that are implemented in the current codebase.
 
 - Reusable production `RepairGame` mounted for `bike`, `pylone`, and `ferme` mission states
 - Repair mission config shared through `src/data/gameplay/repairMissions.ts`
-- Repair-game flow supports `waiting -> inspected -> fragmented -> scanning -> repairing -> done` with `.webm` prompts, repair case spawn/opening, `E`, two-fists hold input, exploded model transition, scan visuals, multiple grabbable replacement choices, and correct-part install validation
+- Repair-game flow supports `waiting -> inspected -> fragmented -> scanning -> repairing -> done -> next mission` with `.webm` prompts, repair case spawn/opening, `E`, two-fists hold input, exploded model transition, scan visuals, multiple grabbable replacement choices, correct-part install validation, and mission completion
 
 ## Audio
 

docs/user/main-feature.md

@@ -4,7 +4,7 @@ This document explains the current repair-game flow in La-Fabrik.
 
 ## What It Does
 
-The main feature is becoming a reusable repair flow mounted in the production game scene. It lets the player approach the active mission object, inspect it, fragment it, scan the broken part, install a replacement, and mark the repair done.
+The main feature is a reusable repair flow mounted in the production game scene. It lets the player approach the active mission object, inspect it, fragment it, scan the broken part, install the correct replacement, validate completion, and move to the next mission state.
 
 The current user flow is:
 
@@ -19,6 +19,7 @@ The current user flow is:
 9. In `repairing`, the case opens and several grabbable replacement parts appear near the case.
 10. Move the correct replacement part close to the install target.
 11. Press `E` on the green install target to move to `done` and show the reassembled object. Wrong parts turn the target red and cannot finish the repair.
+12. Press `E` on the completion target to call `completeMission` and move to the next mission, or to `outro` after `ferme`.
 
 The older debug repair sandbox still exists in the physics test scene, but the production path now starts from the reusable `RepairGame` component.
 
@@ -34,7 +35,7 @@ When the player inspects the object, `RepairGame` writes `inspected` through the
 
 In `inspected`, `RepairGame` can also move to `fragmented`. The player can use the interaction key or hold both fists closed for one second. The hand-tracking path 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`, a blue scan visual and the `cassé.webm` prompt are shown before the flow advances to `repairing`. In `repairing`, the case opens, several grabbable replacement parts appear, and the install target only validates the configured correct part for the active mission.
+In `fragmented`, the repair object is rendered with `ExplodableModel`, then automatically advances to `scanning`. In `scanning`, a blue scan visual and the `cassé.webm` prompt are shown before the flow advances to `repairing`. In `repairing`, the case opens, several grabbable replacement parts appear, and the install target only validates the configured correct part for the active mission. In `done`, the repaired object remains visible with a completion target that advances the global mission progression.
 
 Repair module slots and model-selection behavior still exist in the debug prototype. They can be migrated into the reusable repair flow in later steps if the repair interaction needs more depth.
 
@@ -42,6 +43,7 @@ Repair module slots and model-selection behavior still exist in the debug protot
 
 - `src/world/debug/TestMap.tsx` mounts the repair-game prototype in the debug physics scene.
 - `src/world/GameStageContent.tsx` mounts production `RepairGame` instances for `bike`, `pylone`, and `ferme`.
+- `src/components/three/gameplay/RepairCompletionStep.tsx` renders the final repaired object, completion target, and mission UI prompt.
 - `src/components/three/gameplay/RepairGame.tsx` composes the reusable production repair flow.
 - `src/components/three/gameplay/RepairInspectionObject.tsx` handles the `waiting` inspection interaction.
 - `src/components/three/gameplay/RepairMissionCase.tsx` renders the mission repair case after inspection.
@@ -96,8 +98,8 @@ python -m backend.main
 
 ## Current Limitations
 
-- The reusable production `RepairGame` currently covers `waiting -> inspected -> fragmented -> scanning -> repairing -> done`.
+- The reusable production `RepairGame` currently covers `waiting -> inspected -> fragmented -> scanning -> repairing -> done -> next mission`.
-- Mission progression exists in Zustand, but the full repair mission flow is still being integrated.
+- Mission progression is wired through Zustand using `completeMission` at the end of each repair.
 - There is no central `GameManager` in this branch.
 - Hand tracking is available for the two-fists input and grabbable replacement parts; final installation still uses the shared `E` trigger path.
 - The repair-game content is configured statically in `src/data/gameplay/`.

src/components/three/gameplay/RepairCompletionStep.tsx

@@ -0,0 +1,42 @@
+import { RepairObjectModel } from "@/components/three/gameplay/RepairObjectModel";
+import { RepairPromptVideo } from "@/components/three/gameplay/RepairPromptVideo";
+import { TriggerObject } from "@/components/three/interaction/TriggerObject";
+import type { RepairMissionConfig } from "@/data/gameplay/repairMissions";
+
+interface RepairCompletionStepProps {
+  config: RepairMissionConfig;
+  onComplete: () => void;
+}
+
+export function RepairCompletionStep({
+  config,
+  onComplete,
+}: RepairCompletionStepProps): React.JSX.Element {
+  return (
+    <group>
+      <RepairObjectModel
+        label={config.label}
+        modelPath={config.modelPath}
+        scale={1}
+      />
+
+      <TriggerObject
+        position={[0, 1.1, 0]}
+        colliders="ball"
+        label={`Valider ${config.label}`}
+        onTrigger={onComplete}
+      >
+        <mesh>
+          <torusGeometry args={[1.35, 0.045, 12, 96]} />
+          <meshBasicMaterial color="#22c55e" transparent opacity={0.85} />
+        </mesh>
+        <mesh position={[0, 0.02, 0]} rotation={[Math.PI / 2, 0, 0]}>
+          <ringGeometry args={[0.2, 1.25, 96]} />
+          <meshBasicMaterial color="#bbf7d0" transparent opacity={0.3} />
+        </mesh>
+      </TriggerObject>
+
+      <RepairPromptVideo src={config.stageUiPath} position={[0, 2.55, 0]} />
+    </group>
+  );
+}

src/components/three/gameplay/RepairGame.tsx

@@ -1,8 +1,8 @@
 import { useEffect } from "react";
 import { ExplodableModel } from "@/components/three/models/ExplodableModel";
+import { RepairCompletionStep } from "@/components/three/gameplay/RepairCompletionStep";
 import { RepairInspectionObject } from "@/components/three/gameplay/RepairInspectionObject";
 import { RepairMissionCase } from "@/components/three/gameplay/RepairMissionCase";
-import { RepairObjectModel } from "@/components/three/gameplay/RepairObjectModel";
 import { RepairRepairingStep } from "@/components/three/gameplay/RepairRepairingStep";
 import { RepairScanVisual } from "@/components/three/gameplay/RepairScanVisual";
 import {
@@ -33,6 +33,7 @@ export function RepairGame({
 }: RepairGameProps): React.JSX.Element | null {
   const config = REPAIR_MISSIONS[mission];
   const mainState = useGameStore((state) => state.mainState);
+  const completeMission = useGameStore((state) => state.completeMission);
   const setMissionStep = useGameStore((state) => state.setMissionStep);
   const step = useRepairMissionStep(mission);
   const parsedScale = toVector3Scale(scale);
@@ -86,10 +87,9 @@ export function RepairGame({
         />
       ) : null}
       {step === "done" ? (
-        <RepairObjectModel
+        <RepairCompletionStep
-          label={config.label}
+          config={config}
-          modelPath={config.modelPath}
+          onComplete={() => completeMission(mission)}
-          scale={1}
         />
       ) : null}
       {step !== "waiting" && step !== "done" ? (

src/data/docs/docsTranslations.ts

@@ -361,7 +361,7 @@ Pour les missions de réparation, il monte le composant réutilisable \`RepairGa
 <RepairGame mission="bike" position={[8, 0, -6]} />
 \`\`\`
 
-\`RepairGame\` lit l'étape de mission active depuis le store et écrit les transitions via des actions génériques comme \`setMissionStep\`. Cela garde le composant de scène petit et évite les branches spécifiques à chaque mission dans le flow de réparation. Le flow de réparation de production supporte actuellement les transitions \`waiting -> inspected -> fragmented -> scanning -> repairing -> done\`.
+\`RepairGame\` lit l'étape de mission active depuis le store et écrit les transitions via des actions génériques comme \`setMissionStep\` et \`completeMission\`. Cela garde le composant de scène petit et évite les branches spécifiques à chaque mission dans le flow de réparation. Le flow de réparation de production supporte actuellement les transitions \`waiting -> inspected -> fragmented -> scanning -> repairing -> done -> next mission\`.
 
 La scène peut donc évoluer progressivement vers ce pattern :
 
@@ -406,7 +406,7 @@ Overlays actuels :
 
 ## Prochaines étapes
 
-La prochaine étape naturelle est de déplacer la validation de réparation depuis cette interaction locale vers des données de mission plus riches quand chaque mission aura des nodes de modules cassés et des assets de remplacement dédiés.
+La prochaine étape naturelle est de déplacer la validation de réparation depuis cette interaction locale vers des données de mission plus riches quand chaque mission aura des nodes de modules cassés, des assets de remplacement dédiés et des beats narratifs de complétion.
 `;
 
 export const featuresFr = `# Fonctionnalités implémentées
@@ -442,7 +442,7 @@ Ce document liste les fonctionnalités présentes dans le code actuel.
 
 - \`RepairGame\` de production réutilisable monté pour les états de mission \`bike\`, \`pylone\` et \`ferme\`
 - Configuration de mission partagée via \`src/data/gameplay/repairMissions.ts\`
-- Flow repair-game avec \`waiting -> inspected -> fragmented -> scanning -> repairing -> done\`, prompts \`.webm\`, apparition/ouverture de la mallette, touche \`E\`, hold deux poings, transition de modèle explosé, visuels de scan, plusieurs choix de pièces grabbables et validation de la bonne pièce
+- Flow repair-game avec \`waiting -> inspected -> fragmented -> scanning -> repairing -> done -> next mission\`, prompts \`.webm\`, apparition/ouverture de la mallette, touche \`E\`, hold deux poings, transition de modèle explosé, visuels de scan, plusieurs choix de pièces grabbables, validation de la bonne pièce et complétion de mission
 
 ## Audio