refactor: move mission flow state into game store

src/data/docs/docsSections.ts

@@ -50,6 +50,12 @@ export const docGroups: DocGroup[] = [
         subtitle: "Progression store",
         meta: "06",
       },
+      {
+        path: "/docs/mission-flow",
+        title: "Mission Flow",
+        subtitle: "Intro and mission 2 prototype",
+        meta: "07",
+      },
     ],
   },
   {
@@ -59,25 +65,25 @@ export const docGroups: DocGroup[] = [
         path: "/docs/features",
         title: "Features",
         subtitle: "Implemented scope",
-        meta: "07",
+        meta: "08",
       },
       {
         path: "/docs/main-feature",
         title: "Main Feature",
         subtitle: "Repair-game prototype",
-        meta: "08",
+        meta: "09",
       },
       {
         path: "/docs/editor",
         title: "Editor User Guide",
         subtitle: "Editing workflow",
-        meta: "09",
+        meta: "10",
       },
       {
         path: "/docs/animation",
         title: "Animation & 3D Model System",
         subtitle: "Components and usage",
-        meta: "010",
+        meta: "11",
       },
     ],
   },

src/data/docs/docsTranslations.ts

@@ -328,6 +328,7 @@ Règle simple :
 Le store expose :
 
 - \`mainState\` : phase active du jeu
+- \`missionFlow\` : état prototype de l'intro et de la mission 2
 - \`intro\` : état spécifique à l'intro
 - \`bike\` : état de la mission vélo
 - \`pylone\` : état de la mission réseau électrique
@@ -335,6 +336,8 @@ Le store expose :
 - \`outro\` : état de fin
 - des actions de mise à jour directe et des actions de progression
 
+Le slice \`missionFlow\` contient l'étape prototype, le prénom joueur, le lock de déplacement, le flag d'activité de la ville et le message de dialogue temporaire. Il vit dans le store principal parce qu'il s'agit d'un état gameplay global utilisé par l'UI, le world et le controller joueur.
+
 Les étapes de mission utilisent actuellement cette séquence :
 
 \`\`\`ts
@@ -401,6 +404,8 @@ Pour les missions de réparation, il monte le composant réutilisable \`RepairGa
 
 \`RepairGame\` lit l'étape de mission active depuis le store et écrit les transitions via des actions génériques comme \`setMissionStep\` et \`completeMission\`. Les ids de mission, étapes de mission et guards partagés vivent dans \`src/types/gameplay/repairMission.ts\`, ce qui évite à la configuration statique des missions de dépendre du store Zustand. Le flow de réparation de production supporte actuellement les transitions \`waiting -> inspected -> fragmented -> scanning -> repairing -> reassembling -> done -> next mission\`.
 
+Le flow prototype intro et mission 2 est documenté séparément dans \`docs/technical/mission-flow.md\`. Il utilise volontairement la même source de vérité \`useGameStore\`, sans \`GameStepManager\` dédié ni second store Zustand.
+
 La scène peut donc évoluer progressivement vers ce pattern :
 
 \`\`\`tsx
@@ -431,8 +436,9 @@ Overlays actuels :
 - \`Crosshair\` : aide de visée joueur
 - \`InteractPrompt\` : prompt d'interaction
 - \`RepairMovementLockIndicator\` : indicateur joueur affiché quand les étapes repair désactivent temporairement le déplacement
+- Les overlays du flow mission comme \`IntroUI\`, \`BienvenueDisplay\` et \`DialogMessage\` sont montés par \`src/pages/page.tsx\`, car ce sont des overlays HTML de route plutôt qu'un HUD de jeu persistant.
 
-\`src/pages/page.tsx\` doit rester fin et monter seulement le canvas et \`GameUI\`.
+\`src/pages/page.tsx\` doit rester fin et monter le canvas, le \`GameUI\` persistant et les overlays de route.
 
 ## Règles anti-régression
 
@@ -448,6 +454,78 @@ Overlays actuels :
 Déplacer la validation de réparation dans les données de mission lorsque chaque mission aura ses propres nodes de modules cassés, assets de remplacement et événements de complétion.
 `;
 
+export const missionFlowFr = `# Flow de mission
+
+Ce document décrit le flow prototype d'intro et de mission 2 après son intégration dans l'architecture actuelle.
+
+## Source de vérité
+
+L'état du flow de mission vit dans le store global du jeu :
+
+\`\`\`txt
+src/managers/stores/useGameStore.ts
+\`\`\`
+
+Le store possède le slice \`missionFlow\` :
+
+\`\`\`ts
+missionFlow: {
+  step: GameStep;
+  activityCity: boolean;
+  playerName: string;
+  canMove: boolean;
+  dialogMessage: string | null;
+}
+\`\`\`
+
+Cela garde l'état gameplay global dans Zustand, au lieu de le répartir entre un store mission séparé ou un manager gameplay.
+
+## Frontière des managers
+
+Les managers restent responsables de services runtime locaux :
+
+- \`AudioManager\` possède les éléments audio, les pools audio, la musique, le volume par catégorie et le pan stéréo.
+- \`InteractionManager\` possède les handles d'interaction transitoires, focus, nearby et held.
+
+La progression de mission n'est pas possédée par un manager. Les composants mettent à jour le store via des actions explicites comme \`setFlowStep\`, \`setCanMove\`, \`showDialog\` et \`hideDialog\`.
+
+## Composants runtime
+
+- \`src/components/game/GameFlow.tsx\` réagit à \`missionFlow.step\` et déclenche les effets ponctuels comme l'audio d'intro et le déblocage du mouvement.
+- \`src/components/zone/ZoneDetection.tsx\` lit la position caméra et fait passer le flow à une étape cible quand le joueur entre dans une zone configurée.
+- \`src/components/three/interaction/CentralObject.tsx\` et \`VillageoisHelperObject.tsx\` exposent les objets interactifs temporaires de mission.
+- \`src/pages/page.tsx\` monte les overlays HTML de mission : \`IntroUI\`, \`BienvenueDisplay\` et \`DialogMessage\`.
+- \`src/world/player/PlayerController.tsx\` lit \`missionFlow.canMove\` comme lock de déplacement supplémentaire.
+
+## Séquence d'étapes
+
+Le prototype utilise actuellement ces étapes :
+
+\`\`\`ts
+"intro" | "start-intro" | "naming" | "bienvenue" | "star-move" | "mission2" | "searching" | "helped" | "manipulation" | "outOfFabrik"
+\`\`\`
+
+Ces étapes sont propres au prototype de flow mission. Elles ne remplacent pas \`mainState\` ni la machine d'étapes repair utilisée par \`RepairGame\`.
+
+## Configuration des zones
+
+Les triggers de zones vivent dans :
+
+\`\`\`txt
+src/data/zones.ts
+\`\`\`
+
+Chaque zone possède un id, une position, un rayon, une hauteur et un \`targetStep\`. \`ZoneDetection\` marque une zone comme déclenchée après sa première activation pour éviter de rejouer la même transition à chaque frame.
+
+## Règles
+
+- Garder l'état du flow mission dans \`useGameStore.missionFlow\`.
+- Ne pas réintroduire de \`GameStepManager\` pour les transitions globales.
+- Ne pas créer un second store Zustand pour le flow mission sauf si cet état devient réellement indépendant de la progression du jeu.
+- Garder les effets de bord comme l'audio dans les composants ou les managers de service, mais garder la transition d'état dans le store.
+- Ne pas mettre les valeurs par-frame comme la position caméra ou les distances de zones dans Zustand.
+`;
+
 export const featuresFr = `# Fonctionnalités implémentées
 
 Ce document liste les fonctionnalités présentes dans le code actuel.