Implement production vertical slice foundation

docs/GAME_DESIGN_PLAN.md

@@ -5,15 +5,16 @@
 ## Statut du document
 
 - Nature : plan directeur de conception et de production
-- Version : 0.3
-- État : POC A et POC B validés ; cadrage technique de la verticale proposé
+- Version : 0.4
+- État : POC A et POC B validés ; cadrage technique et boucle de la verticale
+  approuvés
 - Titre : titre de travail, à valider juridiquement avant toute annonce publique
 - Prix commercial : volontairement non défini à ce stade
 
 Les baselines techniques consolidées sont conservées dans
 [POC_A_TECHNICAL_BASELINE.md](POC_A_TECHNICAL_BASELINE.md) et
 [POC_B_TECHNICAL_BASELINE.md](POC_B_TECHNICAL_BASELINE.md).
-Le périmètre et l'architecture proposés pour le prochain jalon sont décrits dans
+Le périmètre et l'architecture retenus pour le prochain jalon sont décrits dans
 [VERTICAL_SLICE_TECHNICAL_PLAN.md](VERTICAL_SLICE_TECHNICAL_PLAN.md).
 
 ## Pitch
@@ -65,7 +66,10 @@ Le jeu ne doit pas être présenté comme un simple cycle « trouver du loot, ve
 
 #### Chercher avant de récupérer
 
-Trouver l’accès doit être plus intéressant que suivre un marqueur. Les coordonnées obtenues sont relativement précises, mais le relief, les grottes, le sédiment, les courants et les champs de débris cachent la cible.
+Trouver l’accès doit être plus intéressant que suivre un marqueur. Une piste
+donne une zone, le sonar du navire la resserre sans produire un point exact,
+puis le relief, les grottes, le sédiment, les courants et les champs de débris
+cachent la cible locale.
 
 #### Risque prévisible
 
@@ -115,7 +119,7 @@ La première version ne comprend pas :
 2. Observer les projecteurs, la caméra et le retour sonar.
 3. Envoyer une impulsion et tourner autour d’un contact.
 4. Reconstruire progressivement le relief et la forme du contact.
-5. Comparer les indices avec la fiche du navire.
+5. Examiner des faits concrets et les comparer au dossier et au registre.
 6. Surveiller oxygène, batterie, profondeur et intégrité.
 7. Choisir de continuer, revenir ou abandonner le véhicule.
 8. Employer les outils contextuels dans le bon ordre.
@@ -123,16 +127,17 @@ La première version ne comprend pas :
 
 ### 2.2 Boucle d’expédition
 
-1. Sélectionner une piste.
-2. Consulter la fiche historique, la bathymétrie et la météo prévue.
-3. Choisir un capteur, deux outils et un module de survie.
-4. Acheter le ravitaillement.
-5. Tracer une route maritime.
-6. Positionner localement le bateau sur la zone.
-7. Déployer le sous-marin.
-8. Cartographier, identifier, ouvrir et récupérer.
-9. Revenir au bateau et transférer la cargaison.
-10. Décider de poursuivre la tournée ou rentrer vendre.
+1. Sélectionner une piste donnant une zone probable, jamais un point exact.
+2. Consulter le contrat, le registre public et les archives acquises.
+3. Préparer le sous-marin et le navire.
+4. Tracer une route maritime sur la carte.
+5. Positionner le navire et lancer des relevés sonar de surface imprécis.
+6. Choisir une zone d'écho et déployer le sous-marin.
+7. Cartographier, identifier, ouvrir et récupérer.
+8. Revenir près du navire, faire surface et treuiller le sous-marin.
+9. Remplir manuellement oxygène et batterie, puis vider le panier.
+10. Analyser les données et décider de replonger ou de rentrer au port.
+11. Au port, décharger la cale, vendre, réparer et améliorer.
 
 ### 2.3 Boucle de campagne
 
@@ -164,21 +169,29 @@ Fonctions d’assistance :
 - limitation du roulis ;
 - caméra fixée à un point intérieur de la cabine ;
 - regard vertical limité par le champ utile du hublot ;
+- regard horizontal limité par le champ utile du hublot ;
+- recentrage manuel du regard, sans recentrage automatique par défaut ;
 - réduction indépendante du roulis et des mouvements de caméra pour l'accessibilité.
 
+La verticale initiale n'implémente ni ballasts ni courants. Les courants entrent
+au jalon V0.5 sous forme de zones légères ou fortes, à direction fixe ou
+variable. Toute variation est progressive, déterministe et pilotée par une
+graine. La gestion manuelle des ballasts reste une piste V2 ou V3.
+
 ### 3.2 Contrôles clavier-souris par défaut
 
 - W/S : propulsion avant et arrière.
 - A/D : gouvernail gauche et droite.
-- Souris horizontale : consigne de cap.
-- Souris verticale : regard limité dans le hublot.
+- Souris horizontale et verticale : regard limité dans le hublot, sans effet
+  sur l'orientation du sous-marin.
 - Espace/Ctrl : monter et descendre.
 - Maj : forte poussée, plus rapide mais moins efficace.
 - F : impulsion sonar.
 - E : interaction contextuelle.
 - 1 à 4 : sélection des modules.
 - Tab : agrandir ou fermer l'écran sonar.
-- Commande d’éjection maintenue trois secondes : abandon volontaire.
+- Action remappable : recentrer le regard.
+- Commande d'éjection maintenue trois secondes : abandon volontaire.
 
 Toutes les actions doivent pouvoir être remappées. Le POV depuis l'habitacle est
 le seul point de vue de pilotage prévu ; aucune caméra extérieure jouable n'est
@@ -195,6 +208,7 @@ Ces valeurs sont des cibles de départ pour les playtests, pas des constantes d
 | Ressource | Valeur Standard initiale |
 |---|---:|
 | Oxygène | environ 16 minutes |
+| Batterie | 100 kWh |
 | Autonomie de propulsion | environ 1,2 km à vitesse de croisière |
 | Profondeur nominale coque I | 60 m |
 | Profondeur nominale coque II | 150 m |
@@ -206,22 +220,33 @@ Ces valeurs sont des cibles de départ pour les playtests, pas des constantes d
 
 - Diminue continuellement pendant une plongée.
 - Ne s’arrête pas lorsque le sous-marin est immobile.
-- Est affiché en minutes restantes au rythme actuel.
+- Est mesuré en litres standards et en L/min.
+- Affiche volume restant, capacité, pourcentage, consommation actuelle et
+  autonomie estimée au rythme courant.
 - Peut être assoupli par les options d’accessibilité.
 - À zéro, une courte séquence d’inconscience précède la perte du véhicule.
 
 ### 4.3 Batterie
 
-- Représente uniquement la batterie de propulsion.
-- Diminue lorsque le joueur applique de la poussée.
-- Ne diminue pas à l’arrêt.
-- Le sonar, les menus et les outils ne consomment pas cette batterie.
+- Est mesurée en kWh ; la puissance instantanée est mesurée en kW.
+- Alimente propulsion, forte poussée, stabilisation et outils de salvage.
+- Ne diminue pas lorsque ces consommateurs sont inactifs.
+- Le sonar, les menus, l'éclairage et les instruments ne consomment pas cette
+  batterie dans la verticale.
 - La forte poussée consomme davantage d’énergie par mètre.
-- La montée, les forts courants et les manœuvres de dégagement augmentent le coût.
-- L’interface estime en permanence la batterie nécessaire pour revenir par le trajet déjà cartographié.
+- La montée, les futurs courants et les manœuvres de dégagement augmentent le
+  coût.
+- L'interface affiche énergie restante, capacité, pourcentage, puissance totale
+  actuelle et autonomie au rythme courant.
+- L’interface estime la batterie nécessaire pour revenir par le trajet connu ;
+  en Expert, cette estimation chiffrée est masquée.
 
 ### 4.4 Profondeur et intégrité
 
+- L'intégrité et la pression sont deux mesures distinctes.
+- L'interface affiche les points d'intégrité actuels et maximaux.
+- Elle affiche aussi la pression extérieure actuelle et la pression maximale
+  recommandée, ainsi que leurs profondeurs équivalentes.
 - Jusqu’à 100 % de la profondeur certifiée : aucun dégât de pression.
 - Entre 100 et 115 % : craquements, distorsions et dégâts croissants.
 - Entre 115 et 125 % : perte rapide d’intégrité.
@@ -250,18 +275,26 @@ Aucune information critique ne dépend uniquement de la couleur.
 
 | Paramètre | Exploration | Standard | Expert |
 |---|---:|---:|---:|
-| Durée d’oxygène | ×1,5 | ×1 | ×0,85 |
-| Autonomie batterie | ×1,35 | ×1 | ×0,9 |
-| Dégâts de pression | ×0,5 | ×1 | ×1,5 |
-| Identification | automatique à proximité | 2 indices sur 3 | 3 indices sans surbrillance |
-| Retour | guidage complet | trace et estimation | trace sans surbrillance |
-| Faux contacts | réduits | normaux | plus ambigus |
+| Consommation d'oxygène | ×0,75 | ×1 | ×1,20 |
+| Consommation de batterie | ×0,80 | ×1 | ×1,15 |
+| Dégâts de collision | ×0,65 | ×1 | ×1,25 |
+| Dégâts de pression | ×0,50 | ×1 | ×1,35 |
+| Grâce avant rupture | ×1,50 | ×1 | ×0,75 |
+| Points d'examen | surlignés | indication discrète | sans surbrillance |
+| Indices avant hypothèse | 2 | 2 | 3 |
+| Retour au navire | direction et distance permanentes | direction et distance permanentes | ping manuel directionnel |
+| Remplacement | configuration restaurée | modèle basique | modèle basique |
+| Franchise | 0 € | 500 € | 750 € |
+
+En Expert, un ping demandé au navire affiche uniquement sa direction pendant
+environ quatre secondes, avec un délai d'environ vingt secondes avant une
+nouvelle demande. Le coût chiffré du retour est remplacé par une alerte
+qualitative. Le sonar de surface conserve le même comportement dans les trois
+modes.
 
 ### 5.2 Réglages indépendants
 
 - Multiplicateurs d’oxygène, batterie et pression.
-- Sévérité économique de la perte.
-- Pause des jauges dans la carte et les fiches.
 - Taille du texte.
 - Contraste et palette du sonar.
 - Modes de daltonisme.
@@ -270,8 +303,16 @@ Aucune information critique ne dépend uniquement de la couleur.
 - Sous-titrage des alarmes.
 - Remappage complet.
 
+La difficulté peut changer uniquement hors plongée. La prochaine plongée
+utilise un jeu de règles immuable résolu à son départ. Aucun changement ne
+modifie rétroactivement une perte, une dette ou une récompense.
+
 Aucun succès ne doit être verrouillé par ces options.
 
+Le dossier complet met toujours la plongée en pause : aucun tick, mouvement ou
+coût de ressource n'est produit pendant sa lecture. Un résumé compact des faits
+récents reste visible dans le HUD sans ouvrir le dossier.
+
 ---
 
 ## 6. Mort, assurance et sauvegarde
@@ -289,25 +330,54 @@ Causes :
 
 ### 6.2 Conséquences
 
-- Autosauvegarde immédiate au résultat.
-- Paiement d’une franchise.
-- Remplacement par une coque de même classe.
-- Plans et améliorations permanentes conservés.
-- Loadout standard fourni.
-- Modules avancés à réinstaller contre une fraction de leur valeur.
+- Le protagoniste remonte sur son navire, qui reste positionné sur le site.
+- Aucune nouvelle plongée n'est possible tant qu'il n'a pas navigué jusqu'au
+  port et obtenu un remplacement au chantier naval.
+- En Exploration, l'assurance restaure la configuration perdue sans franchise.
+- En Standard et Expert, le remplacement est un sous-marin basique : toutes les
+  améliorations et tous les modules installés sont perdus.
+- Les plans débloqués, le navire et ses améliorations restent acquis.
+- La franchise vaut 500 € en Standard et 750 € en Expert.
 - Crédit automatique sans intérêt si le joueur est insolvable.
-- 20 % des gains suivants remboursent cette dette.
-- Une balise marque le sous-marin perdu.
-- Seule une partie de la cargaison peut être récupérée.
+- 20 % de chaque paiement de contrat et de chaque vente rembourse cette dette ;
+  un remboursement manuel supplémentaire reste possible.
+- La cargaison déjà transférée dans la cale du navire reste acquise ; le
+  contenu du panier du sous-marin est perdu.
 - Les objets indispensables à la campagne retournent à leur point d’extraction s’ils n’avaient pas atteint le bateau.
 
-Les sauvegardes de port protègent contre les bugs, pas contre les conséquences normales d’une perte.
+Les observations de la plongée sont conservées lors d'une éjection volontaire,
+mais perdues après destruction de la coque ou épuisement de l'oxygène. La
+récupération physique du sous-marin perdu reste hors de la verticale.
+
+Les sauvegardes effectuées hors plongée protègent contre les bugs, pas contre
+les conséquences normales d’une perte.
 
 ---
 
 ## 7. Sonar et recherche
 
-### 7.1 Principe
+### 7.1 Sonar du navire
+
+Une piste narrative ouvre une zone probable, jamais la position exacte d'une
+épave. Le navire peut y lancer des relevés de surface déterministes :
+
+- portée initiale d'environ 400 m autour du navire ;
+- première zone d'incertitude d'environ 150 m ;
+- recoupement depuis une autre position ramenant cette zone vers 75 m ;
+- précision minimale de 50 m, jamais une coordonnée exacte ;
+- aucune silhouette, matière ou identité révélée ;
+- un nouveau relevé au même endroit donne le même résultat ;
+- aucun coût d'argent ou de carburant dans la verticale, seulement une courte
+  animation de balayage ;
+- les zones d'écho sont persistantes, mais pas les données sonar brutes.
+
+Dans la verticale, chaque écho persistant conduit à une épave ou à un site
+documentable. Les échos produits par des rochers restent une piste post-V1 et
+ne seront ajoutés que si les tests montrent une déduction intéressante plutôt
+qu'une plongée vide. Les améliorations futures peuvent agir sur la portée, la
+résolution ou la séparation des contacts, jamais sur leur identité.
+
+### 7.2 Sonar du sous-marin
 
 Le sonar est le principal risque technique et doit être validé avant la production de la campagne.
 
@@ -319,8 +389,12 @@ Le sonar est le principal risque technique et doit être validé avant la produc
 6. Le petit écran et la vue agrandie montrent exactement le même relief.
 7. Les matériaux influencent la couleur et l'intensité de la réponse.
 8. Aucune géométrie non observée n'est inventée.
+9. L'échelle de couleur est relative à chaque scan ; la vue agrandie affiche
+   une légende avec les valeurs réelles en mètres.
+10. Plusieurs anomalies spatiales restent des contacts séparés et ne sont
+    jamais fusionnées par une moyenne globale.
 
-### 7.2 Matériaux sonar
+### 7.3 Matériaux sonar
 
 - Roche.
 - Sable et vase.
@@ -330,7 +404,7 @@ Le sonar est le principal risque technique et doit être validé avant la produc
 - Vide ou cavité.
 - Matériau surnaturel tardif.
 
-### 7.3 Progression sonar
+### 7.4 Progression sonar
 
 - Sonar I : courte portée, relief grossier et impulsions manuelles.
 - Sonar II : portée et densité supérieures, remplacement plus rapide.
@@ -343,7 +417,7 @@ Modules de capteur :
 - Magnétomètre : excellent pour acier, canons et ancres.
 - Analyse spectrale : révèle certains signaux surnaturels tardifs.
 
-### 7.4 Faux contacts
+### 7.5 Faux contacts
 
 Les faux contacts sont rares et utiles :
 
@@ -357,7 +431,7 @@ Les faux contacts sont rares et utiles :
 
 Une recherche ne doit pas se terminer par vingt minutes dans une zone entièrement vide.
 
-### 7.5 Manières de cacher une épave
+### 7.6 Manières de cacher une épave
 
 - Grotte révélée par un courant sortant.
 - Écho sous un surplomb.
@@ -373,6 +447,8 @@ Une recherche ne doit pas se terminer par vingt minutes dans une zone entièreme
 
 ## 8. Identification et fiches historiques
 
+Une zone de recherche contient plusieurs épaves candidates. La cible n'est
+jamais distinguée des leurres par le sonar ou par une condition d'interface.
 Chaque épave majeure possède au minimum trois preuves parmi :
 
 - dimensions et silhouette ;
@@ -393,7 +469,45 @@ Chaque fiche distingue :
 - preuves encore manquantes ;
 - bibliographie.
 
-En mode Exploration, les preuves sont surlignées et enregistrées automatiquement à proximité. En Standard, deux preuves doivent être scannées. En Expert, les trois sont requises sans surbrillance.
+Les informations certifiées sont fiables. Une estimation ou un témoignage est
+explicitement signalé comme incertain ; le registre peut être incomplet, mais ne
+ment jamais silencieusement au joueur.
+
+Le registre public d'un secteur est gratuit. Un pack d'archives détaillées,
+acheté une seule fois en ville, ajoute photographies, dimensions, équipements
+et zones approximatives. Il reste facultatif et persiste dans la sauvegarde. Les
+épaves leurres y figurent ; une cible récente ou secrète peut n'apparaître que
+comme bâtiment disparu.
+
+Pour examiner un indice, le joueur approche à environ 8 à 12 m, regarde la zone
+depuis l'habitacle et maintient l'interaction environ 1,5 seconde. La zone de
+visée reste généreuse. Exploration surligne les points, Standard emploie une
+indication discrète et Expert ne les surligne pas.
+
+Chaque observation enregistre un fait littéral. Le dossier le rapproche des
+fiches et affiche `Concorde`, `Contredit` ou `Non déterminant`, sans calculer de
+probabilité ni choisir la cible. Après deux observations en Exploration et
+Standard, trois en Expert, le joueur peut désigner n'importe quelle épave comme
+cible présumée. Cette hypothèse reste révisable et n'est jamais validée sous
+l'eau. Une conclusion erronée ne devient un échec qu'au moment de transmettre
+explicitement le rapport final.
+
+La carte globale distingue :
+
+- aucun marqueur avant localisation ;
+- `Épave non identifiée` après sécurisation de ses coordonnées ;
+- le nom du navire après identification ;
+- une icône colorée, doublée d'un marqueur d'activité, lorsqu'une action connue
+  reste à accomplir ;
+- une icône en noir et blanc lorsqu'aucune activité connue ne reste.
+
+Une épave identifiée reste toujours revisitable. Une activité future peut lui
+rendre sa couleur ; un secret encore inconnu ne colore jamais l'icône et ne se
+révèle donc pas par l'interface.
+
+Toute épave déjà inscrite sur la carte devient un site de plongée sélectionnable.
+Le navire peut s'y repositionner et le HUD fournit un repère local pour la
+retrouver sans recommencer sa recherche initiale au sonar.
 
 ---
 
@@ -429,6 +543,17 @@ Les cinq premiers sont introduits pendant l’acte I. Les trois derniers apparai
 
 Découpes, étais, objets déplacés et accès ouverts persistent entre les plongées.
 
+Les outils consomment la batterie du sous-marin selon leur puissance électrique
+réelle. La puissance de l'outil et celle des propulseurs de stabilisation sont
+additionnées. Une opération interrompue par un mauvais alignement se met en
+pause au lieu de recommencer ; la stabilisation aide le joueur sans figer le
+sous-marin.
+
+La verticale emploie un cutter de référence à 30 kW pendant environ 12 secondes
+(0,10 kWh hors stabilisation) et un bras simple à 8 kW pendant environ six
+secondes (0,013 kWh hors stabilisation). Ces valeurs sont des cibles de
+playtest.
+
 Une erreur peut :
 
 - abîmer la valeur d’un objet ;
@@ -447,11 +572,29 @@ Toutes les épaves, sauf la caravelle finale, doivent être terminables en une o
 
 ### 10.1 Inventaires
 
-- Panier du sous-marin : arbitrage immédiat.
-- Cale du bateau : choix de poursuivre ou rentrer.
+- Panier du sous-marin : 6 unités initiales et arbitrage immédiat.
+- Cale du navire : 12 unités initiales, puis améliorations à 18 et 24.
 - Stockage de port : illimité pour les objets conservés.
 
-Les objets occupent 1, 2, 4 ou 6 cases. L’argent, les preuves et les journaux ne prennent aucune place.
+Les objets occupent 1, 2, 4 ou 6 unités. L’argent, les preuves et les journaux
+ne prennent aucune place.
+
+Faire surface ne transfère rien. À proximité du navire, l'action `Treuiller`
+replace le sous-marin sur son berceau et termine la plongée. Le joueur doit
+ensuite cliquer séparément sur `Recharger la batterie`, `Remplir l'oxygène` et
+`Vider le panier`. Ces services sont gratuits dans la verticale, mais jamais
+automatiques. Replonger sans les utiliser conserve les ressources et la
+cargaison dans leur état actuel.
+
+`Vider le panier` transfère tout en une action si la cale dispose de la place
+nécessaire. Au port, `Décharger la cale` transfère manuellement son contenu vers
+le stockage illimité. Un objet de campagne n'est sécurisé qu'après son transfert
+hors du panier.
+
+Un objet secondaire peut être relâché sous l'eau pour libérer de la place et
+reste récupérable à cette position. Un objet indispensable ne peut être ni vendu
+ni détruit ; s'il est perdu avec le sous-marin avant transfert, il retourne à son
+point d'extraction.
 
 ### 10.2 Catégories
 
@@ -466,10 +609,22 @@ Les objets occupent 1, 2, 4 ou 6 cases. L’argent, les preuves et les journaux
 
 ### 10.3 Ports
 
+Les ports sont des écrans illustrés et non des espaces parcourus à pied. Leur
+présentation est incarnée par des lieux et des interlocuteurs : nom de
+l'entreprise plutôt que `Commanditaire`, `Archives maritimes`, `Chantier naval`
+et `Le Comptoir` tenu par un courtier maritime aux méthodes ambiguës.
+
+Le Chantier naval sépare clairement les onglets `Sous-marin` et `Navire`. Il
+répare la coque seulement au port et installe les améliorations correspondantes.
+Le Comptoir achète les objets secondaires sélectionnés ; aucune vente n'est
+automatique et aucun objet narratif n'apparaît comme vendable. Il peut proposer
+quelques objets ou informations utiles, mais aucun onglet d'achat vide ou achat
+obligatoire n'est ajouté à la verticale.
+
 #### Port industriel
 
 - Meilleurs prix pour métal, mécanique et technologie.
-- Atelier principal.
+- Chantier naval principal.
 - Assurance et réparations.
 
 #### Port touristique et collectionneur
@@ -487,27 +642,50 @@ Chaque port possède des préférences fixes et des événements temporaires ann
 
 ### 10.4 Principes économiques
 
-- Une mission principale réussie rembourse route, ravitaillement et deux plongées.
+- Une mission principale réussie finance la poursuite et une amélioration utile.
 - Les trésors et objectifs optionnels financent les upgrades.
-- Une seule monnaie.
+- Une seule monnaie, l'euro, affichée sans centimes au format français.
 - Aucun craft.
 - Les plans peuvent exiger un seuil de relation.
 - Une aide portuaire évite toujours le blocage financier.
 - Le prix commercial du jeu n’est pas décidé dans ce document.
 
+Valeurs initiales de la verticale, à ajuster par playtest :
+
+| Élément | Valeur |
+|---|---:|
+| Argent initial | 500 € |
+| Pack d'archives du secteur | 500 € |
+| Premier contrat | 1 000 € |
+| Objet secondaire de référence | environ 200 € |
+| Cale 12 vers 18 | 750 € |
+| Réparation | 4 € par point d'intégrité |
+
 ---
 
 ## 11. Surface, voyage et temps
 
 - Carte maritime interactive.
 - Route tracée entre ports, secteurs et mouillages.
-- Pilotage manuel seulement près d’un port ou d’une zone de plongée.
+- Dans la verticale, déplacement du navire sur la carte avec transition courte,
+  sans pilotage 3D, carburant ni attente en temps réel.
+- Le navire existe néanmoins comme repère 3D simplifié dans la zone de plongée,
+  avec silhouette, feux, point de récupération et treuil.
+- Le pilotage manuel et une représentation détaillée du navire restent une
+  piste V2 ou V3 derrière le même modèle de position persistante.
 - Aucun combat naval.
-- Chaque voyage consomme carburant et capacité logistique.
-- Chaque déplacement ou déploiement avance un tour d’expédition abstrait.
-- Les trois prochains états de météo et de lumière sont visibles.
-- Il n’existe pas de calendrier continu.
-- Replonger restaure oxygène et batterie, mais coûte un ravitaillement et un tour.
+- Pendant une plongée, le navire reste fixe à la position choisie.
+- En Exploration et Standard, sa direction et sa distance sont toujours
+  disponibles. En Expert, seul un ping directionnel temporaire peut être
+  demandé.
+- Le treuillage exige une remontée à faible vitesse dans un rayon initial
+  d'environ 25 m.
+- Les fonctions de base du navire sont la navigation, le sonar de surface,
+  l'analyse des données, les archives embarquées, les communications, le treuil,
+  la recharge, l'oxygène et la cale.
+- Ces instruments ne s'usent pas, ne tombent pas en panne et ne consomment pas
+  de ressources dans la verticale.
+- Il n’existe pas de calendrier continu dans la verticale.
 - La corruption remplace progressivement davantage d’états lumineux par du crépuscule ou de la nuit.
 
 ---
@@ -562,7 +740,28 @@ Ancien technicien d’inspection offshore. Il maîtrise machines et sonar, mais
 
 Le précédent opérateur de la société a fait naufrage quelques mois auparavant. Le joueur est engagé pour récupérer le matériel coûteux de son navire de prospection.
 
-Le manifeste officiel décrit une cartographie banale. Les journaux récupérés montrent que l’équipage cherchait un U-Boot non répertorié.
+La société sait dès le départ qu'elle recherche la rançon et emploie le
+contrat comme couverture. Le manifeste officiel décrit une cartographie banale ;
+son objectif réel est de récupérer les derniers relevés du précédent opérateur sur
+un U-Boot non répertorié et d'empêcher leur diffusion.
+
+La première zone contient le navire de prospection comme épave majeure et deux
+épaves leurres légères documentées dans le registre. La cible récente est
+absente des épaves localisées du registre ; sa fiche technique vient de la
+société. Elle est identifiable par son portique, son immatriculation partielle
+et ses équipements spécifiques. Elle contient :
+
+- un module de cartographie bathymétrique de 4 unités, demandé par la société ;
+- le journal ou les données du précédent opérateur, sans volume de cargaison ;
+- une première pièce mystérieuse de 1 unité ;
+- un petit objet secondaire optionnel de 1 unité.
+
+Après transfert du module vers le navire, son contenu est sauvegardé sans
+risque de perte. Le joueur déclenche manuellement son analyse à bord ; elle
+révèle les trajectoires non déclarées et la zone probable du U-Boot. Le module
+physique peut ensuite être remis explicitement à la société pour obtenir le
+paiement. La société peut prétendre que l'ancien opérateur agissait seul, mais
+les données installent le doute.
 
 ### 13.3 Chaîne narrative
 
@@ -581,7 +780,7 @@ L’enquête remonte donc la chaîne des propriétaires à rebours.
 
 Après le U-Boot :
 
-- le joueur comprend qu’un trésor est recherché ;
+- le joueur prouve que la société recherchait délibérément le trésor ;
 - il confronte son responsable ;
 - la société exige les données ;
 - le contrat est résilié ;
@@ -766,8 +965,10 @@ Deux niveaux de détail par grande épave. Collisions simplifiées séparées de
 Écrans illustrés animés :
 
 - vue du quai ;
-- atelier ;
-- marché ;
+- entreprise ou contact narratif nommé ;
+- Archives maritimes ;
+- Chantier naval avec onglets Sous-marin et Navire ;
+- Comptoir du courtier maritime ;
 - carte ;
 - portraits des personnages.
 
@@ -793,9 +994,11 @@ Aucun personnage 3D marchable.
 
 ### 20.1 Pile
 
-- Godot 4.7.1 stable.
+- Godot 4.7.2 stable.
 - GDScript.
-- Renderer Forward+ visé pour la production ; GL Compatibility utilisé par le POC A pour faciliter les premiers tests multiplateformes.
+- Renderer Forward+ unique pour la production ; les POC validés sous GL
+  Compatibility restent des références historiques, pas une configuration de
+  jeu prise en charge.
 - Blender.
 - Export glTF 2.0.
 - Git.
@@ -808,35 +1011,45 @@ La version mineure du moteur est figée pendant chaque jalon. Toute mise à jour
 | Type | Contenu |
 |---|---|
 | WreckDefinition | ID, époque, profondeur, preuves, outils, sources |
-| ContractDefinition | donneur, prérequis, délai, paiement, conséquences |
+| ContractTerms | donneur, informations visibles, objectif officiel, paiement |
+| CampaignObjective | déclencheurs réels, progression et révélations |
+| ArchivePackDefinition | secteur, prix et fiches enrichies |
 | ItemDefinition | volume, catégorie, valeur, légalité, unicité |
 | UpgradeDefinition | slot, prix, prérequis, effets |
+| DifficultyProfile | consommation, dégâts, aides et assurance |
+| VesselLocation | région, repère, position, cap et état du navire |
 | MarketProfile | préférences, événements, restrictions |
 | DialogueDefinition | textes, conditions, choix, flags |
 | DiveSiteDefinition | scène, météo, courants, faux contacts, graine |
-| SaveGame | version, économie, relations, épaves, scans, cargaison |
+| SaveGame | version, économie, relations, épaves, échos sémantiques, cargaison |
 
-### 20.3 Services globaux
+### 20.3 Composition des services
 
-- GameState.
-- SaveService.
-- SceneRouter.
-- AudioManager.
-- LocalizationService.
-- ContractService.
-- MarketService.
+Aucun service de gameplay n'est accessible par autoload dans la première
+production. Le nœud racine de composition possède les services à longue durée de
+vie et injecte explicitement leurs contrats aux cas d'usage et aux scènes,
+conformément à `docs/adr/0008-composition-owned-service-lifetimes.md`.
+
+Une longue durée de vie ne justifie pas un accès global. Tout futur autoload,
+notamment pour la sauvegarde, l'audio ou l'état de campagne, exige un ADR.
 
 ### 20.4 Sonar technique
 
-- Grille bathymétrique structurée par ligne et colonne, avec position, normale,
-  intensité, matériau et élévation normalisée.
-- Surface continue par `ArrayMesh` indexé, normales lissées et palette d'altitude.
+- Buffer compact en tableaux parallèles de positions, normales, intensités,
+  matériaux, élévations réelles et statuts d'observation.
+- Surface continue par `ArrayMesh` indexé, normales lissées et palette
+  d'altitude relative au scan avec légende en mètres.
 - Caméra sonar oblique et fixe, cap vers le haut.
+- Repère figé à la pose du capteur lors de l'émission.
 - Un scan courant et un scan précédent en fondu au maximum.
 - Une texture de rendu partagée entre l'écran compact et la vue agrandie.
-- Passe frontale complémentaire pour les anomalies matérielles.
-- Représentation hybride à concevoir pour les grottes et surplombs, qu'une carte
-  à hauteur unique ne peut pas décrire seule.
+- Clustering spatial déterministe pour conserver plusieurs anomalies distinctes.
+- Comparaison entre la réécriture bathymétrique de référence et une passe
+  frontale par rayons, derrière un contrat commun ; une seule acquisition finale.
+- Sonar de surface séparé produisant uniquement des zones d'écho sémantiques.
+- Bathymétrie limitée à une surface unique en V1 ; les véritables grottes,
+  surfaces superposées et surplombs critiques sont différés conformément à
+  `docs/adr/0010-single-surface-bathymetry-for-v1.md`.
 - Bruit déterministe selon distance, angle, sonar et difficulté après validation
   de la lecture fondamentale.
 
@@ -845,12 +1058,24 @@ La version mineure du moteur est figée pendant chaque jalon. Toute mise à jour
 - État explicite par interaction : intacte, accessible, terminée, endommagée.
 - Transformations sauvegardées seulement pour les éléments identifiés.
 - Aucune sérialisation de physique arbitraire.
+- Aucun maillage, point brut ou couleur sonar n'est sauvegardé.
+- Les zones d'écho de surface, positions d'épaves connues et observations sont
+  des données sémantiques versionnées.
 - Micro-sites régénérés depuis la graine.
 - Version du format obligatoire.
 - Migrations testées avant chaque build public.
-- Trois profils de campagne.
-- Sauvegardes automatiques tournantes.
-- Import de la sauvegarde de démo.
+- Une seule campagne narrative, avec plusieurs sauvegardes choisies par le
+  joueur.
+- Trois autosauvegardes sémantiques : avant plongée, après plongée et progression
+  de campagne ; chacune conserve une sauvegarde technique de secours.
+- Jusqu'à dix sauvegardes manuelles, uniquement hors plongée.
+- Format JSON explicite, versionné, écrit par fichier temporaire puis validé et
+  remplacé atomiquement.
+- Une sauvegarde inclut notamment argent, dette, position du navire, contrats,
+  épaves, observations, cargaison, stockage, archives et améliorations.
+- Aucune restauration de la physique d'une plongée en cours. Après crash ou
+  fermeture forcée, la partie revient à l'état précédant la plongée sans perte
+  automatique du véhicule.
 
 ---
 
@@ -884,6 +1109,7 @@ La version mineure du moteur est figée pendant chaque jalon. Toute mise à jour
 ### 22.1 Tests automatisés
 
 - Consommation d’oxygène et de batterie.
+- Addition de la puissance des outils et de la stabilisation.
 - Estimation du retour.
 - Seuils de profondeur.
 - Franchise et dette.
@@ -896,7 +1122,7 @@ La version mineure du moteur est figée pendant chaque jalon. Toute mise à jour
 
 ### 22.2 Tests d’intégration
 
-- Port vers plongée puis retour et vente.
+- Port vers relevé de surface, plongée, treuillage, entretien manuel et vente.
 - Destruction, remplacement et récupération.
 - Changement de difficulté en cours de partie.
 - Sauvegarde chargée sur un autre OS.
@@ -925,7 +1151,7 @@ La version mineure du moteur est figée pendant chaque jalon. Toute mise à jour
 | Préparation | 2 à 4 semaines | Outils, dépôt, builds vides sur trois OS |
 | POC A jetable | 6 à 8 semaines | Pilotage, caméra, jauges, profondeur, éjection |
 | POC B jetable | 8 à 12 semaines | Sonar de relief, lecture d'ouverture, anomalie |
-| Verticale | 4 à 6 mois | Une épave, port, contrat, vente, amélioration |
+| Verticale | 4 à 6 mois | Une épave majeure, deux leurres légers, port, contrat, vente, amélioration |
 | Acte I | 7 à 10 mois | Quatre épaves, économie, difficulté, bilingue |
 | Démo et préparation EA | 2 à 3 mois | Démo 30 à 45 minutes, QA Windows/Linux |
 | Accès anticipé | vers 18 à 24 mois | Acte I complet |

docs/UI_DESIGN_SYSTEM.md

@@ -0,0 +1,262 @@
+# Design system UI — verticale jouable
+
+## Statut
+
+- Version : 0.1.
+- Date : 7 août 2026.
+- État : baseline acceptée pour les menus et réglages de la verticale.
+- Référence visuelle principale : menu principal V4 sous `Design-Proposal/`.
+- Portée : menus, réglages, confirmations et états système de la verticale.
+
+Ce document est la source autoritaire. Les PNG sous `Design-Proposal/` sont des
+références d'ambiance et de composition. Leurs contradictions, textes fictifs et
+données simulées ne deviennent pas des exigences. Les HTML associés sont des
+prototypes de présentation ; aucun code de production ne les importe ou ne les
+copie.
+
+## 1. Intention
+
+L'interface évoque un équipement maritime industriel moderne, robuste, entretenu
+et réparable. Elle combine la sobriété d'un poste de travail embarqué avec
+quelques détails d'instrumentation plus ancienne.
+
+Le joueur doit percevoir :
+
+- l'isolement et la pression du milieu sous-marin ;
+- une technologie spécialisée mais compréhensible ;
+- une tension lente, annoncée et jamais décorativement alarmiste ;
+- la matérialité du cockpit sans confusion avec un système militaire futuriste.
+
+Sont exclus du langage de production : faux systèmes d'exploitation, gestion de
+flotte, réacteur, jargon de protocole, diagnostics sans fonction, interface de
+combat et données de télémétrie inventées.
+
+## 2. Références retenues
+
+| Référence | Usage retenu | Ne pas reprendre |
+|---|---|---|
+| Menu principal V4 | ancrage visuel, panneau, calme et hiérarchie | format exporté et arrière-plan comme contrat exact |
+| Menu pause V4 | contraste avec la scène en arrière-plan | navigation anglaise et protocole d'évacuation comme écran par défaut |
+| Réglages Audio V4 | densité, curseurs et groupement des canaux | statut système décoratif |
+| Réglages Commandes V4 | ligne d'action, conflit et remappage | action de tir, touches fictives et coque `DIVE_OS` |
+| Réglages Accessibilité V4 | regroupement et aperçu immédiat | radar circulaire et choix d'une couleur isolée comme palette |
+| Réglages Affichage V4 | modes d'écran, résolution, VSync et limite FPS | navigation Fleet/Logs/Nav-Com/Engineering |
+| Confirmation d'abandon V4 | texte des conséquences et hiérarchie du danger | ordre inversé des actions et télémétrie décorative |
+| Planche de composants V4 | états, bordures et redondance des signaux | réacteur, unités et libellés fictifs |
+
+Le catalogue complet et le statut de chaque proposition se trouvent dans
+`Design-Proposal/README.md`.
+
+## 3. Couleurs
+
+Les valeurs ci-dessous sont des points de départ. Elles seront vérifiées sur le
+renderer de production et corrigées si le contraste mesuré l'exige.
+
+| Rôle | Valeur de départ | Usage |
+|---|---|---|
+| Fond principal | `#09141e` | écran et voile de pause |
+| Fond profond | `#040f19` | champs et zones en retrait |
+| Panneau | `#15212b` | conteneur principal |
+| Panneau actif | `#202b36` | survol et sélection secondaire |
+| Texte principal | `#d8e4f2` | titres et actions |
+| Texte secondaire | `#bacac6` | descriptions et métadonnées utiles |
+| Focus | `#40e0d0` | bordure, crochet et repère de sélection |
+| Avertissement | `#ffbf00` | risque réversible ou attention requise |
+| Danger | `#ffb4ab` | perte, abandon et action irréversible |
+| Bordure | `#3c4a47` | structure et séparation |
+
+La couleur ne suffit jamais à transmettre un état. Focus, avertissement et
+danger combinent au moins une forme ou bordure, une icône et un texte.
+
+## 4. Typographie et densité
+
+- Corps : sans-serif lisible, 16 px minimum à 1080p.
+- Libellé fonctionnel : 14 px minimum.
+- Donnée chiffrée : monospace réservée aux valeurs réellement utiles.
+- Titre d'écran : 24 à 32 px selon la hiérarchie.
+- Zone interactive : 44 × 44 px minimum.
+- Marge sûre : 32 px à 1080p.
+- Expansion de localisation : réserver au moins 30 % de largeur supplémentaire.
+
+Inter et JetBrains Mono sont les candidats visuels actuels. Leur ajout au jeu
+nécessitera des fichiers locaux et l'enregistrement de leurs licences. Le rendu
+d'une police distante dans les HTML n'est pas une dépendance autorisée.
+
+Les capitales espacées sont réservées aux titres courts et aux actions. Les
+paragraphes et conséquences restent en casse normale. Les microtextes
+décoratifs sont supprimés.
+
+## 5. Formes, mouvement et profondeur
+
+- Panneaux rectangulaires, angles droits ou rayon maximal de 2 px.
+- Bordures franches plutôt qu'une lueur seule.
+- Focus clavier visible par une bordure double ou des crochets persistants.
+- Appui représenté par un léger déplacement ou changement tonal.
+- Flou, bloom et condensation restent décoratifs et désactivables.
+- Aucun scintillement ou clignotement rapide.
+- Les scanlines globales sont interdites.
+- La réduction des mouvements désactive parallaxe, pulsation décorative et
+  transition non essentielle.
+
+## 6. Coque de navigation commune
+
+Tous les réglages partagent la même coque : titre, onglets, contenu, retour et
+barre d'actions. Ils ne simulent ni un logiciel distinct ni un autre poste du
+véhicule.
+
+Onglets de la verticale :
+
+1. Commandes ;
+2. Accessibilité ;
+3. Audio ;
+4. Affichage.
+
+Actions persistantes : `Retour`, `Rétablir par défaut`, `Annuler` et
+`Appliquer`. Un changement non appliqué porte un repère de forme en plus de sa
+couleur. Les réglages pouvant être prévisualisés sans risque s'appliquent à
+l'aperçu immédiatement ; leur persistance suit toujours la commande explicite.
+
+L'ordre de focus suit l'ordre de lecture : titre ou retour, onglets, contenu de
+haut en bas, puis actions. Le retour arrière restaure le focus sur le contrôle
+qui a ouvert l'écran.
+
+## 7. Écrans autoritaires
+
+### Menu principal
+
+Ordre des actions :
+
+1. `Continuer` ;
+2. `Nouvelle partie` ;
+3. `Réglages` ;
+4. `Quitter`.
+
+Avec une sauvegarde valide, `Continuer` reçoit le focus. Sans sauvegarde, il
+reste lisible, affiche `Aucune sauvegarde` sans état d'erreur et `Nouvelle
+partie` reçoit le focus.
+
+### Pause
+
+Le vrai menu pause suspend les ticks de plongée, donc les consommations et les
+dégâts temporels. L'écran sonar agrandi ne met pas le jeu en pause.
+
+Ordre des actions :
+
+1. `Reprendre` ;
+2. `Réglages` ;
+3. `Abandonner la plongée` ;
+4. `Retour au menu principal` ;
+5. `Quitter le jeu`.
+
+`Reprendre` reçoit toujours le focus initial. L'abandon ouvre une confirmation ;
+il n'affiche pas un faux état critique et n'est jamais déclenché directement.
+
+### Confirmation d'abandon
+
+Titre : `Abandonner la plongée ?`
+
+Message : `Vous serez éjecté puis évacué. Le sous-marin et sa cargaison non
+sécurisée resteront au fond. Une franchise sera appliquée.`
+
+Actions, dans cet ordre : `Rester en plongée`, puis `S'éjecter et abandonner`.
+L'action sûre reçoit le focus. Une confirmation n'invente aucune profondeur,
+intégrité ou autre télémétrie.
+
+### Commandes
+
+L'écran présente les actions abstraites du jeu et détecte les conflits. Il ne
+contient aucune action de tir. La première baseline utilise :
+
+| Entrée | Action |
+|---|---|
+| W / S | avancer / reculer |
+| A / D | gouverner à gauche / droite |
+| Souris | regard horizontal et vertical limité, sans modifier le cap |
+| Espace / Ctrl | monter / descendre |
+| Maj | forte poussée |
+| F | impulsion sonar |
+| E | interaction contextuelle |
+| 1 à 4 | sélectionner un module |
+| Tab | agrandir ou fermer le sonar |
+| action d'éjection maintenue | abandon volontaire |
+
+Les valeurs affichées proviennent du service de réglages. Le joueur peut
+remapper, résoudre un conflit, restaurer les valeurs par défaut et choisir
+`Maintenir` ou `Basculer` pour les actions prolongées compatibles.
+
+### Accessibilité et sonar
+
+L'aperçu sonar emploie un échantillon de calibration explicitement fixe. Il
+représente une surface bathymétrique continue en perspective, jamais un radar
+circulaire. Une palette est un ensemble cohérent de valeurs de profondeur et
+d'anomalie, pas le choix d'une couleur unique.
+
+La palette normale conserve la grammaire validée : bleu profond, cyan et vert
+intermédiaires, jaune et rouge hauts, orange pour une anomalie. Les variantes
+accessibles ajoutent luminosité, contours ou formes ; elles ne suppriment pas la
+lecture de l'élévation.
+
+Réglages minimaux : taille du texte, mouvement caméra, roulis, flashs et
+distorsions, sous-titrage des alarmes, contraste et palette sonar, modes de
+daltonisme, maintien ou bascule.
+
+### Audio et affichage
+
+Canaux audio : principal, musique, ambiance, véhicule, interface et alarmes.
+Les alarmes restent audibles et testables indépendamment.
+
+Affichage : fenêtré, sans bordure, plein écran, résolution, VSync, limite de
+framerate et qualité graphique. Forward+ reste l'unique renderer : aucun choix
+de renderer n'est exposé. Les préréglages de qualité agissent notamment sur les
+particules, les ombres, la distance d'affichage et le post-traitement ; les
+effets atmosphériques coûteux suivent la même politique après mesure. Les
+valeurs proposées viennent de la plateforme et de configurations validées ;
+l'interface n'invente pas des modes indisponibles. Une qualité réduite ne
+supprime jamais une information nécessaire à la navigation ou au sonar.
+
+## 8. États système
+
+Libellés autoritaires :
+
+- `Sauvegarde en cours…` ;
+- `Sauvegarde terminée` ;
+- `Chargement…` ;
+- `Aucune sauvegarde` ;
+- `Sauvegarde invalide` ;
+- `Version de sauvegarde incompatible`.
+
+L'absence de sauvegarde est neutre, une sauvegarde invalide est un avertissement
+et une incompatibilité irrécupérable est une erreur. Les détails techniques
+restent dans les logs et ne remplacent pas le message joueur.
+
+`Continuer` reprend au dernier état stable pris en charge. La position physique,
+les collisions, les particules et le maillage sonar d'une plongée ne sont pas
+sérialisés dans la verticale.
+
+## 9. Contrat d'implémentation
+
+- La présentation consomme des snapshots ou réglages typés ; elle n'invente
+  aucune valeur de gameplay.
+- Une interaction UI émet une commande d'application ; elle ne mute ni la
+  plongée ni la campagne directement.
+- Le menu pause contrôle la progression par un cas d'usage explicite, pas en
+  cachant simplement la scène.
+- Les réglages sont possédés par un service unique et sauvegardés séparément de
+  la campagne.
+- Les illustrations et icônes deviennent des assets locaux avec licence connue.
+- Aucun HTML, CDN, script distant ou image distante de `Design-Proposal/` ne
+  devient une dépendance du jeu.
+- La présentation est vérifiée à 1920 × 1080, 1280 × 720 et à sa plus petite
+  taille réelle dans le cockpit.
+
+## 10. Décisions encore ouvertes
+
+Avant l'implémentation complète du flux de sortie, préciser dans le cadrage de
+sauvegarde si `Retour au menu principal` et `Quitter le jeu` pendant une plongée
+appliquent immédiatement les conséquences d'un abandon ou enregistrent un état
+de plongée active à résoudre au prochain chargement. Dans les deux cas, ces
+actions ne permettent pas d'annuler gratuitement une perte déjà engagée.
+
+Le choix final des polices et le niveau de texture décorative seront validés sur
+le renderer de production. Ils ne modifient pas les règles de lisibilité et de
+navigation de cette baseline.

docs/VERTICAL_SLICE_TECHNICAL_PLAN.md

@@ -1,13 +1,14 @@
-# Verticale jouable — Cadrage technique proposé
+# Verticale jouable — Cadrage technique retenu
 
 ## Statut
 
-- Date : 7 août 2026.
-- État : proposition à valider avant le premier code de production.
+- Date : 10 août 2026.
+- Dernière révision d'implémentation : 16 août 2026.
+- État : cadrage approuvé, tranches 0 et 1 implémentées.
 - Jalon : verticale jouable, après validation des POC A et B.
 - Durée directrice du plan général : quatre à six mois.
-- Moteur figé pour le jalon : Godot 4.7.1.
-- Références : baselines techniques des POC A et B.
+- Moteur figé pour le jalon : Godot 4.7.2.
+- Références : baselines techniques des POC A et B, design system UI.
 
 Ce document définit ce que la verticale doit prouver, les frontières de son
 implémentation et l'ordre de construction. Il ne remplace ni le game design
@@ -17,9 +18,10 @@ général ni les baselines des prototypes.
 
 La verticale doit répondre à une seule question principale :
 
-> Piloter, chercher une épave réellement cachée, l'identifier, récupérer une
-> preuve et revenir sous contrainte forme-t-il une boucle claire et assez
-> satisfaisante pour porter une campagne ?
+> Préparer une expédition, resserrer une zone avec le sonar du navire, trouver
+> et identifier une épave parmi des leurres, récupérer son objectif puis revenir
+> sous contrainte forme-t-il une boucle claire et assez satisfaisante pour
+> porter une campagne ?
 
 Les POC ont validé séparément le véhicule et le langage du sonar. La verticale
 doit vérifier leur combinaison dans une mission complète avec préparation,
@@ -30,21 +32,31 @@ objectif, conséquence et progression.
 La verticale utilise le premier navire de la campagne : le bâtiment de
 prospection contemporain du précédent opérateur.
 
-1. Consulter un message de contrat et une fiche de secteur.
-2. Accepter la mission avec un équipement imposé ou très limité.
-3. Déployer le mini-sous-marin à proximité de la zone probable.
-4. Suivre le relief tout en surveillant oxygène, propulsion et coque.
-5. Utiliser manuellement le sonar bathymétrique pour trouver un accès masqué.
-6. Découvrir l'épave sans marqueur posé directement sur elle.
-7. Observer deux indices permettant de confirmer son identité.
-8. Dégager ou ouvrir un accès avec une interaction contextuelle simple.
-9. Récupérer une caisse ou un journal lié à la piste du U-Boot.
-10. Calculer la marge de retour et remonter au bateau.
-11. Consulter le débriefing, conserver la preuve et vendre un objet secondaire.
-12. Acheter une première amélioration dont l'effet est vérifiable en replongeant.
+1. Consulter le contrat mensonger de la société, le registre public et, si
+   acheté, le pack d'archives à 500 €.
+2. Naviguer sur la carte jusqu'à la zone probable et lancer des relevés du
+   sonar de surface.
+3. Recouper les zones d'écho puis déployer le mini-sous-marin.
+4. Suivre le relief tout en surveillant oxygène, batterie, pression et coque.
+5. Utiliser manuellement le sonar bathymétrique pour trouver plusieurs épaves
+   candidates sans marqueur direct.
+6. Examiner des indices, consulter le dossier en pause et désigner une cible
+   présumée sans validation immédiate.
+7. Identifier le navire de prospection du précédent opérateur parmi deux leurres
+   extérieurs légers.
+8. Stabiliser le sous-marin, découper une attache et ouvrir un compartiment.
+9. Récupérer le module de cartographie, ses données, une pièce mystérieuse et,
+   si la place le permet, un objet secondaire.
+10. Revenir au navire, faire surface à proximité et déclencher `Treuiller`.
+11. Remplir manuellement oxygène et batterie, puis vider le panier vers la cale.
+12. Analyser les données à bord afin de révéler la zone probable du U-Boot.
+13. Rentrer au port, décharger, remettre le module, toucher 1 000 € et vendre
+    l'objet secondaire.
+14. Acheter l'agrandissement de cale de 12 à 18 unités et vérifier son effet.
 
-Durée cible initiale : 15 à 25 minutes pour une première réussite, hors reprise
-après échec. Ce nombre sera corrigé par playtest.
+Durée cible initiale : 15 à 25 minutes pour la plongée réussie et 30 à 45
+minutes pour le parcours complet avec port, relevé de surface et débriefing,
+hors reprise après échec. Ces nombres seront corrigés par playtest.
 
 ## 3. Périmètre obligatoire
 
@@ -52,25 +64,42 @@ après échec. Ce nombre sera corrigé par playtest.
 
 - POV intérieur et hublot circulaire.
 - Pilotage inertiel avec retour immédiat des commandes.
-- Oxygène, batterie de propulsion, profondeur et intégrité.
+- Oxygène, batterie électrique, profondeur, pression et intégrité.
 - Alarmes texte, couleur et son.
 - Estimation de retour compréhensible.
 - Sonar manuel progressif, compact et agrandissable.
+- Sonar de surface déterministe et imprécis depuis la carte maritime.
 - Un terrain conçu à la main avec une route sûre et une route plus risquée.
-- Une épave identifiable et une anomalie secondaire optionnelle.
-- Une interaction d'ouverture et une récupération.
+- Une épave majeure identifiable et deux épaves leurres extérieures légères.
+- Un registre public, un pack d'archives facultatif et un dossier comparatif.
+- Une interaction de découpe, une récupération et une stabilisation assistée.
 - Retour réussi, abandon volontaire et perte du véhicule.
 
 ### Métajeu minimal
 
-- Un écran de contrat.
-- Une fiche historique courte.
-- Un écran de préparation limité.
+- Un port illustré donnant accès à l'entreprise nommée, aux Archives
+  maritimes, au Chantier naval et au Comptoir.
+- Un contrat, trois fiches d'épaves candidates et un pack d'archives.
+- Une carte maritime, un écran de préparation et les instruments de base du
+  navire.
 - Un débriefing.
-- Une vente ou restitution.
-- Une amélioration achetable.
+- Une remise contractuelle et une vente manuelles.
+- Une réparation de coque et une amélioration de cale achetable.
 - Une sauvegarde locale versionnée.
 
+### Menus et réglages
+
+- Un menu principal avec Continuer, Nouvelle partie, Réglages et Quitter.
+- Un menu pause qui suspend réellement les ticks de plongée.
+- Une confirmation explicite avant abandon, retour au menu ou sortie pendant
+  une plongée.
+- Quatre catégories de réglages : commandes, accessibilité, audio et affichage.
+- Les états de chargement, sauvegarde absente, invalide ou incompatible.
+- La présentation suit `docs/UI_DESIGN_SYSTEM.md` ; les maquettes sous
+  `Design-Proposal/` restent des références non exécutables.
+- Les nouveaux écrans de port, carte, dossier et entretien exigent une itération
+  de design dédiée ; seules leurs responsabilités fonctionnelles sont figées ici.
+
 ### Qualité minimale
 
 - Clavier-souris remappable.
@@ -83,16 +112,19 @@ après échec. Ce nombre sera corrigé par playtest.
 ## 4. Hors périmètre ferme
 
 - Deuxième grande épave.
-- Carte maritime complète et pilotage de surface.
+- Pilotage 3D et physique navale ; la carte maritime limitée de la mission
+  reste obligatoire.
 - Trois ports ou marchés dynamiques.
 - Relations de personnages complètes.
 - Dialogue à embranchements complexe.
 - Plusieurs classes de coque.
 - Plusieurs outils de salvage simulés.
+- Loadout configurable ; le cutter et le bras requis sont imposés.
 - Intérieur complet de l'épave.
 - Véritable grotte à plusieurs niveaux ou surplomb complexe.
 - Génération procédurale de site majeur.
 - Corruption surnaturelle avancée.
+- Ballasts, courants et échos géologiques présentés comme contacts prometteurs.
 - Doublage, cinématique ou art final.
 - Manette certifiée, succès, cloud ou intégration de boutique.
 - Import d'une sauvegarde de démo.
@@ -107,6 +139,8 @@ document.
 
 - Au moins 8 testeurs sur 10 trouvent l'accès à l'épave en 5 à 10 minutes après
   l'arrivée dans la zone de recherche, sans aide orale.
+- Au moins 8 sur 10 comprennent la différence entre zone de recherche, écho de
+  surface, épave non identifiée et épave identifiée.
 - Au moins 8 sur 10 comprennent le rapport entre bleu, vert, jaune et hauteur.
 - Au moins 8 sur 10 identifient la caisse ou l'anomalie sur le sonar.
 - Aucun testeur ne confond oxygène et batterie après le tutoriel.
@@ -116,10 +150,11 @@ document.
 ### Boucle de jeu
 
 - Une enquête attentive réduit la recherche locale à moins de dix minutes.
-- Le joueur peut expliquer les deux indices ayant confirmé l'épave.
+- Le joueur peut expliquer les deux indices ayant motivé son identification et
+  pourquoi les leurres ne correspondent pas.
 - Le retour est une décision anticipable et non une surprise punitive.
 - Une première erreur ne rend jamais la mission principale impossible.
-- L'amélioration achetée produit un changement visible lors d'une seconde sortie.
+- Le passage de la cale de 12 à 18 unités est visible et persiste.
 
 ### Technique
 
@@ -146,20 +181,28 @@ game/
     inventory/
     economy/
     upgrades/
+    campaign/
+    rules/
   application/
     dive/
     sonar/
     mission/
+    navigation/
+    vessel/
     port/
     interfaces/
   world/
     submarine/
+    vessel/
     sonar/
     sites/
     interactions/
   presentation/
     cockpit/
     sonar/
+    dossier/
+    map/
+    port/
     briefing/
     debriefing/
     settings/
@@ -175,7 +218,9 @@ content/
   wrecks/
   contracts/
   evidence/
+  archives/
   items/
+  rules/
   upgrades/
   sites/
   localization/
@@ -189,14 +234,20 @@ d'usage du port maritime.
 
 | État | Propriétaire unique | Lecteurs principaux |
 |---|---|---|
-| Oxygène, batterie, coque, profondeur autorisée | `DiveSession` du domaine | HUD, alarmes, débriefing, sauvegarde |
+| Tick et temps réel | application et adaptateur d'horloge | `DiveSession` via `DiveTick` explicite |
+| Oxygène, batterie, coque, pression, alertes et fin de plongée | `DiveSession` du domaine | HUD, audio, débriefing |
+| Règles résolues de la plongée | `DiveRulesResolver` du domaine | `DiveSession`, navigation, outils |
 | Transform, vitesses et collisions | `SubmarineActor` dans `world` | télémétrie, caméra, capteur |
 | Commande de propulsion | cas d'usage de pilotage | adaptateur physique |
-| Scan courant et précédent | service applicatif sonar | renderer, HUD, sauvegarde si retenue |
+| Orientation de la caméra | contrôleur de caméra de présentation | vue cockpit uniquement |
+| Observations de collision | adaptateur physique du monde | `DiveSession` |
+| Scan courant et précédent | service applicatif sonar | renderer, HUD |
 | Échantillons physiques bruts | adaptateur sonar du monde | service applicatif sonar |
-| Objectifs et preuves observées | `MissionProgress` du domaine | HUD, fiche, débriefing |
+| Échos sonar de surface persistants | progression de campagne | carte, préparation, sauvegarde |
+| Objectifs, épaves connues et faits observés | `MissionProgress` du domaine | dossier, carte, débriefing |
 | Cargaison du panier | `DiveInventory` du domaine | HUD, récupération, débriefing |
-| Argent et améliorations | `CampaignState` du domaine | port, préparation, sauvegarde |
+| Cale, stockage, argent, dette et améliorations | `CampaignState` du domaine | navire, port, sauvegarde |
+| Position et disponibilité du navire | `CampaignState` via `VesselLocation` | carte, déploiement, récupération |
 | Écran ouvert et sélection locale | présentation concernée | aucune règle de gameplay |
 | Réglages joueur | service de réglages | input, caméra, audio, présentation |
 
@@ -204,58 +255,129 @@ La profondeur affichée est calculée à partir de la position physique, puis
 transmise à `DiveSession` par un échantillon de télémétrie. Le HUD ne la recalcule
 jamais depuis un nœud 3D.
 
+Le domaine n'interroge jamais une horloge. L'application fournit exactement un
+`DiveStep` par tick de physique à 60 Hz. Aucun tick n'est produit pendant une
+pause et aucun temps de pause n'est rattrapé. Un pas supérieur à 0,1 s est
+subdivisé ou refusé.
+
+Les observations et objets d'une plongée restent provisoires jusqu'à sa fin.
+Le résultat détermine ce qui rejoint la campagne ; aucune sauvegarde ne tente de
+restaurer la physique sous l'eau.
+
 ## 8. Premiers contrats typés
 
-Les noms ci-dessous sont des responsabilités proposées. Leur API exacte sera
+Les noms ci-dessous fixent les responsabilités initiales. Leur API exacte sera
 validée par tests avant toute scène complète.
 
 ### `VehicleCommand`
 
+- séquence ;
 - poussée longitudinale normalisée ;
 - gouvernail normalisé ;
 - commande verticale normalisée ;
-- forte poussée active ou non ;
-- tick ou instant logique.
+- forte poussée active ou non.
 
 Produit par l'infrastructure d'entrée, validé par l'application et consommé par
-l'acteur physique.
+l'acteur physique. La souris n'y contribue jamais.
+
+### `CameraLookCommand`
+
+- variation de lacet en radians ;
+- variation de tangage en radians ;
+- demande de recentrage éventuelle.
+
+Ce contrat oriente seulement la caméra fixée dans la cabine. Le regard persiste,
+reste borné par le hublot et ne se recentre pas automatiquement par défaut. Les
+limites initiales de playtest sont environ ±30° horizontalement et -17° / +11°
+verticalement. Un recentrage lent optionnel et un recentrage instantané en mode
+réduction des mouvements restent des réglages de présentation.
 
 ### `VehicleTelemetry`
 
 - position et orientation mondiales ;
-- vitesse linéaire et angulaire ;
+- vitesse linéaire dans le monde et vitesse angulaire dans le repère du
+  véhicule ;
 - profondeur en mètres ;
-- effort de propulsion normalisé ;
-- intensité de la dernière collision ;
-- tick logique.
+- efforts longitudinal, de gouverne et vertical normalisés ;
+- forte poussée active ;
+- identifiant de session et séquence.
 
-Snapshot immuable produit par le monde. Aucune référence de nœud n'en sort.
+Snapshot temporaire immuable produit par le monde. Aucune référence de nœud
+n'en sort et la position du sous-marin n'est pas sauvegardée en V1.
 
-### `DiveSnapshot`
+### Entrées d'un pas de plongée
 
-- identifiant de session ;
-- oxygène restant ;
-- batterie restante ;
-- intégrité ;
-- profondeur nominale et critique ;
-- coût de retour estimé ;
-- niveau d'alarme ;
-- état terminal éventuel.
+- `DiveTick` : séquence et secondes écoulées ;
+- `DiveTelemetrySample` : profondeur et efforts effectifs utiles aux règles ;
+- `CollisionObservation` : séquences de collision et de tick, vitesse normale
+  d'impact en m/s ;
+- `ToolPowerDemand` : ID d'outil et intensité électrique effective ;
+- `EjectionIntent` : commande active ou inactive ;
+- `ReturnRouteSample` : distance, ascension et statut connu ou inconnu ;
+- `DiveStep` : agrégat unique de ces entrées pour un tick.
 
-Produit par le domaine après application d'un tick et d'une télémétrie.
+Les collisions sont séparées de la télémétrie continue et sont idempotentes.
+Le domaine possède leurs seuils, dégâts et délais de répétition. Les efforts
+représentent la sortie réelle des actionneurs, jamais une touche pressée.
 
-### `SonarSample`
+### `DiveSnapshot` et `DiveUpdate`
 
-- ligne et colonne ;
-- position et normale dans un repère déclaré ;
-- distance en mètres ;
-- intensité normalisée ;
-- catégorie de matériau ;
-- élévation ou profondeur ;
-- temps de révélation ;
-- statut observé ou inconnu.
+`DiveSnapshot` contient :
 
-Il remplace les dictionnaires implicites du POC B.
+- `BatterySnapshot` : kWh restants et maximaux, ratio, puissance actuelle en kW
+  et autonomie estimée ;
+- `OxygenSnapshot` : litres standards restants et maximaux, ratio, consommation
+  en L/min et autonomie estimée ;
+- `HullSnapshot` : intégrité actuelle et maximale, ratio, pression extérieure,
+  certifiée, critique et d'écrasement en bar ;
+- `DepthSnapshot` : profondeur actuelle, certifiée, critique et d'écrasement en
+  mètres ;
+- `ReturnEstimate` : kWh requis, marge en kWh et ratio, statut sûr, serré,
+  insuffisant ou inconnu ;
+- `DiveAlertState` : niveaux indépendants pour oxygène, batterie, coque et
+  profondeur, plus la sévérité maximale ;
+- `EjectionSnapshot` : progression d'une tenue de trois secondes ;
+- motif terminal éventuel : retour, éjection volontaire, oxygène épuisé ou
+  coque détruite.
+
+`DiveUpdate` regroupe ce snapshot cohérent et des événements typés comme
+`AlertLevelChanged`, `ResourceDepleted`, `HullDamaged` et `DiveTerminated`.
+L'UI et l'audio ne redéduisent jamais les seuils. Une batterie vide est une
+défaillance, mais ne termine pas instantanément la plongée.
+
+Les niveaux d'alerte sont `NORMAL`, `ATTENTION`, `RETURN`, `CRITICAL` et
+`FAILURE`. La tenue d'éjection dure trois secondes, se réinitialise au relâchement
+et n'avance pas en pause. Une confirmation explicite depuis le menu produit le
+même motif d'éjection volontaire sans demander une seconde tenue.
+
+L'ordre interne d'un pas est fixe : validation, consommation, pression,
+collisions ordonnées, éjection, retour et alertes, état terminal, puis
+publication d'un seul `DiveUpdate`.
+
+### `ResolvedDiveRules`
+
+Au début d'une plongée, `DiveRulesResolver` combine dans cet ordre :
+
+1. règles de base ;
+2. capacités et améliorations du sous-marin ;
+3. profil de difficulté ;
+4. aides d'accessibilité de gameplay ;
+5. validation et bornage.
+
+Le résultat est immuable pour cette plongée et seul le choix des sources est
+sauvegardé. Les mêmes sources donnent toujours les mêmes règles.
+
+### `SonarSampleBuffer` et `SonarContact`
+
+Le scan stocke en mémoire des tableaux parallèles compacts de positions,
+normales, intensités, élévations, matériaux et statuts d'observation. Un même
+index décrit une cellule ; ligne et colonne sont dérivées. Un accesseur typé
+`sample_at(row, column)` masque cette représentation.
+
+Le buffer devient immuable après publication. Des clusters spatiaux
+déterministes produisent des `SonarContact` séparés avec ID, matériau, centre,
+limites, intensité maximale et nombre d'échantillons. La couleur d'altitude est
+relative au scan, mais les valeurs réelles en mètres restent stockées.
 
 ### `SonarScan`
 
@@ -264,27 +386,56 @@ Il remplace les dictionnaires implicites du POC B.
 - portée et ouvertures ;
 - durée ;
 - dimensions de grille ;
-- collection typée de `SonarSample` ;
-- état : demandé, actif, terminé ou remplacé.
+- `SonarSampleBuffer`, contacts et échelle de couleur ;
+- état : prêt, capture, révélation ou récupération.
 
-Le résultat stocke le repère de capture. La présentation peut ainsi orienter la
-carte sans relire un acteur mutable.
+Le repère est figé à l'émission, origine au capteur, +X tribord, +Y haut et +Z
+avant en mètres. L'adaptateur convertit le -Z avant de Godot. La révélation dure
+2,5 s, suivie de 0,35 s de récupération, sans file d'attente d'entrée. Un scan
+courant et un scan précédent en fondu existent au maximum.
+
+Deux acquisitions de production peuvent être comparées derrière le même
+contrat : réécriture bathymétrique de référence du POC et faisceau frontal par
+rayons. Une seule devient autoritaire après la porte de calibration.
+
+### `SurfaceSurvey` et `SurfaceEchoArea`
+
+Un relevé de surface contient la position du navire, son empreinte, sa séquence
+et des zones d'écho avec centre approximatif et rayon d'incertitude. Rejouer le
+même relevé produit le même résultat. Seules les zones sémantiques sont
+sauvegardées ; elles sont remplacées par une épave connue après localisation
+sous l'eau.
+
+### `VesselLocation`
+
+- ID de région et de repère de coordonnées ;
+- position est et nord en mètres ;
+- cap en radians ;
+- état au port, sur site, en eau libre ou en route ;
+- ID d'un mouillage connu éventuel.
+
+La composition convertit cette donnée métier en transform Godot. Ni la carte,
+ni la sauvegarde ne manipulent le nœud 3D du navire.
 
 ### `MissionProgress`
 
-- contrat actif ;
-- objectifs connus ;
-- preuves observées ;
-- identité proposée ou confirmée ;
-- interaction d'accès ;
-- objet principal récupéré ;
-- résultat de mission.
+- termes visibles du contrat et objectifs réels séparés ;
+- objectifs et révélations connus ;
+- `WreckRecord` pour chaque épave localisée : position, identité éventuelle,
+  faits observés et activités connues ;
+- cible présumée révisable ;
+- état de l'accès et de la découpe ;
+- état des objets : sur site, dans le panier, dans la cale, remis ;
+- rapport final distinct du résultat de chaque plongée.
 
 ### Définitions de contenu
 
 - `WreckDefinition` : identité, époque, dimensions, preuves et références.
-- `ContractDefinition` : donneur, site, objectifs, paiement et prérequis.
+- `ContractTerms` : donneur, informations visibles, objet demandé, paiement et
+  prérequis.
+- `CampaignObjectiveDefinition` : déclencheurs réels, visibilité et révélations.
 - `EvidenceDefinition` : type d'observation, cible et texte de fiche.
+- `ArchivePackDefinition` : secteur, prix et fiches enrichies.
 - `ItemDefinition` : volume, catégorie, valeur et caractère essentiel.
 - `UpgradeDefinition` : coût, prérequis et effet typé.
 - `DiveSiteDefinition` : scène, profondeur, limites et contenu autorisé.
@@ -294,13 +445,16 @@ un texte libre destiné au joueur.
 
 ## 9. Flux principaux
 
-### Démarrage de mission
+### Contrat, archives et relevé de surface
 
 ```text
-Briefing UI
-  → AcceptContract
-  → CampaignState valide les prérequis
-  → StartDive crée DiveSession et MissionProgress
+Port UI
+  → consulter ContractTerms et registre public
+  → acheter éventuellement ArchivePackDefinition
+  → NavigateVessel met à jour VesselLocation
+  → RequestSurfaceSurvey produit des SurfaceEchoArea déterministes
+  → sélection d'une zone d'écho
+  → StartDive résout ResolvedDiveRules et crée DiveSession
   → Composition charge le DiveSite
   → World reçoit uniquement les paramètres nécessaires
 ```
@@ -313,8 +467,9 @@ InputAdapter
   → PilotUseCase
   → SubmarineActor
   → VehicleTelemetry
-  → TickDive
-  → DiveSnapshot
+  → DiveTelemetrySample + CollisionObservation + ToolPowerDemand
+  → DiveStep à 60 Hz
+  → DiveUpdate
   → cockpit et alarmes
 ```
 
@@ -323,10 +478,10 @@ InputAdapter
 ```text
 Action F
   → RequestSonarScan
-  → validation état/cooldown
+  → validation de l'état
   → WorldSonarAdapter capture les retours
   → SonarScanService structure le scan
-  → progression déterministe
+  → révélation 2,5 s puis récupération 0,35 s
   → SonarPresentationSnapshot
   → renderer compact et agrandi
 ```
@@ -334,44 +489,89 @@ Action F
 La petite et la grande vue consomment la même sortie du renderer. Elles ne
 maintiennent jamais deux reconstructions indépendantes.
 
+#### Piste post-V1 : échos géologiques de surface
+
+La V1 ne présente pas un rocher banal comme un contact prometteur : chaque
+écho persistant du sonar du bateau conduit à une épave, un site secondaire
+ou un élément documentable. Une itération ultérieure pourra faire renvoyer des
+échos aux rochers et autres formations géologiques afin d'enrichir
+l'interprétation du relevé de surface. Cette piste ne sera retenue qu'après
+playtest, si ces faux positifs créent une déduction intéressante plutôt qu'une
+plongée vide ou punitive.
+
 ### Observation et récupération
 
 ```text
-Interaction monde
-  → ObserveEvidence ou RecoverItem
-  → MissionProgress / DiveInventory
-  → résultat explicite
-  → snapshot UI et sauvegarde éventuelle
+Regard + proximité + vitesse valide
+  → ObserveEvidence ajoute un fait idempotent
+  → dossier compare sans conclure
+  → SetSuspectedWreck reste révisable
+  → CutAccess consomme cutter + stabilisation et persiste
+  → RecoverItem valide la capacité puis consomme bras + stabilisation
+  → DiveInventory est mis à jour à la fin du transfert
 ```
 
 L'acteur d'épave ne décide pas qu'une mission est terminée. Il décrit le contact
-observé ; le domaine applique les règles du contrat.
+observé ; le domaine applique les règles de campagne. Une opération suspendue
+par la dérive conserve sa progression. Le cutter de référence consomme 30 kW
+pendant environ 12 s et le bras 8 kW pendant environ 6 s, hors stabilisation.
 
-### Retour et débriefing
+Le dossier complet met les ticks en pause. Il reste aussi consultable avant la
+plongée et depuis les instruments du navire.
+
+### Retour, treuillage et transfert
 
 ```text
-Zone de retour atteinte
-  → CompleteDive
+Sous-marin en surface à faible vitesse dans un rayon de 25 m
+  → WinchSubmarine
   → résultat immuable
-  → transfert autorisé de cargaison
-  → calcul économique
-  → sauvegarde atomique
-  → Debriefing UI
+  → retour sur le navire sans restauration automatique
+  → actions séparées RefillOxygen / RechargeBattery / EmptyBasket
+  → EmptyBasket exige la place nécessaire dans la cale
+  → sauvegarde atomique après chaque action
+  → AnalyzeRecoveredData révèle la piste du U-Boot
+  → retour au port, UnloadHold, remise, paiement et vente explicites
 ```
 
+Une fin de plongée ne termine pas la mission. Le rapport final et la remise des
+objets sont des actions de campagne explicites. Après perte du sous-marin, le
+joueur revient sur le navire au site, doit naviguer au port et demander son
+remplacement au Chantier naval.
+
+L'analyse des données est disponible à bord dès le vidage du panier et ne
+consomme ni ressource ni temps simulé. La copie reste acquise même si le module
+physique est remis à l'entreprise avant sa lecture.
+
+L'écran principal du port expose directement `Décharger la cale` et `Prendre la
+mer`. Avant le départ, il récapitule batterie, oxygène, coque, panier, cale,
+dossier suivi et archives possédées. Une préparation incomplète produit un
+avertissement, jamais une restauration ou un blocage automatique.
+
 ## 10. Scènes de production minimales
 
 | Scène | Responsabilité |
 |---|---|
 | `vertical_slice_root.tscn` | composition et transitions du parcours |
+| `main_menu.tscn` | nouvelle partie, reprise, réglages et sortie |
+| `pause_menu.tscn` | pause réelle et commandes de sortie de plongée |
+| `settings_screen.tscn` | coque commune des quatre catégories de réglages |
+| `confirmation_dialog.tscn` | confirmation sûre des actions destructrices |
+| `port_screen.tscn` | entreprise nommée, Archives, Chantier, Comptoir et départ |
+| `maritime_map.tscn` | position du navire, zones, relevés et sites connus |
+| `vessel_service_screen.tscn` | ressources, panier, cale et analyse à bord |
+| `dossier_screen.tscn` | contrat, registre, observations et cible présumée |
 | `dive_site_survey_wreck.tscn` | environnement, limites et points d'injection |
+| `surface_vessel_actor.tscn` | repère 3D statique, feux et zone de treuillage |
 | `submarine_actor.tscn` | physique et adaptateurs du véhicule |
 | `survey_wreck.tscn` | géométrie, collisions et points observables |
+| `decoy_wreck.tscn` | variante modulaire extérieure et points observables |
 | `cockpit_hud.tscn` | télémétrie et alertes |
 | `sonar_display.tscn` | affichage compact et agrandi partagé |
-| `briefing_screen.tscn` | contrat, fiche et départ |
-| `debriefing_screen.tscn` | résultat, cargaison et progression |
-| `workshop_screen.tscn` | une amélioration et son installation |
+| `company_screen.tscn` | termes du contrat, remise, rapport et paiement |
+| `archives_screen.tscn` | registre public et pack d'archives du secteur |
+| `shipyard_screen.tscn` | onglets Sous-marin et Navire, réparation et cale |
+| `counter_screen.tscn` | sélection et vente manuelle de cargaison |
+| `debriefing_screen.tscn` | résultat de plongée sans transfert implicite |
 
 Ces scènes reçoivent leurs dépendances depuis la composition. Aucun autoload de
 gameplay n'est introduit pour éviter cette injection.
@@ -381,48 +581,75 @@ gameplay n'est introduit pour éviter cette injection.
 La sauvegarde existe avant le métajeu complet afin d'empêcher une architecture
 reposant sur des nœuds sérialisés.
 
-Contenu V1 :
+La campagne narrative est unique, mais le joueur peut conserver plusieurs
+sauvegardes. `Continuer` charge la sauvegarde valide la plus récente et
+`Charger` affiche la liste sans supprimer les sauvegardes plus récentes.
 
-- version du format ;
-- ID de campagne et date technique non utilisée par le gameplay ;
-- contrat actif ou terminé ;
-- argent ;
-- améliorations acquises et installées ;
-- preuves principales sécurisées ;
-- dernier résultat de plongée ;
+Organisation V1 :
+
+- trois autosauvegardes sémantiques : avant plongée, après plongée et progression
+  de campagne ;
+- une sauvegarde technique de secours invisible pour chacune ;
+- jusqu'à dix sauvegardes manuelles nommées, seulement hors plongée ;
 - réglages joueur séparés de la campagne.
 
-La position arbitraire du sous-marin, les particules, les collisions et le
-maillage sonar dynamique ne sont pas sauvegardés dans cette verticale.
+Le format est un JSON explicite avec enveloppe `schema_version`, `campaign_id`,
+`save_id`, `created_at_utc`, `kind` et `payload`. Le payload contient au moins :
 
-Procédure : sérialiser dans un fichier temporaire, relire et valider, puis
-remplacer atomiquement la sauvegarde précédente. Conserver une fixture V1 et un
-test de round-trip dès la première implémentation.
+- argent, dette et difficulté choisie ;
+- `VesselLocation`, disponibilité du sous-marin et ressources non remplies ;
+- contrats, objectifs connus et révélations ;
+- zones d'écho, épaves localisées, identités et observations sécurisées ;
+- états persistants d'ouverture ;
+- panier, cale, stockage et objets narratifs ;
+- archives, plans et améliorations ;
+- dernier résultat de plongée.
+
+La position arbitraire du sous-marin, les particules, les collisions, les points
+sonar, leurs couleurs et le maillage dynamique ne sont pas sauvegardés. Un
+marqueur technique indique seulement qu'une plongée était active. Après crash ou
+fermeture forcée, le jeu revient à l'état précédant la plongée sans restauration
+physique ni perte automatique du véhicule.
+
+Les dictionnaires JSON restent confinés au codec d'infrastructure ; les autres
+couches reçoivent des objets typés. Procédure : sérialiser dans un fichier
+temporaire, relire et valider, puis remplacer atomiquement la sauvegarde
+précédente. Conserver une fixture par version, des migrations explicites et un
+test de round-trip dès la première implémentation. Une version inconnue est
+refusée proprement.
 
 ## 12. Stratégie de tests
 
 ### Unitaires
 
-- consommation des trois ressources ;
+- tick à 60 Hz, pause sans tick et rejet ou subdivision d'un pas trop grand ;
+- consommation d'oxygène, propulsion, outils et stabilisation ;
 - seuils de profondeur et dégâts ;
 - estimation du retour ;
 - transitions terminales ;
+- ordre et idempotence des collisions ;
+- résolution base, améliorations, difficulté et accessibilité ;
 - validation et progression temporelle d'un scan ;
 - remplacement d'un seul scan précédent ;
 - classification des matériaux ;
+- clustering de plusieurs contacts sans moyenne globale ;
+- relevé de surface identique depuis la même position et recoupement borné ;
 - ajout idempotent d'une preuve ;
-- conditions d'identification ;
-- capacité de cargaison ;
-- résultat de mission ;
-- vente, restitution et achat d'amélioration.
+- hypothèse révisable sans validation implicite ;
+- capacité du panier et de la cale ;
+- plongée terminée distincte du rapport final ;
+- perte, franchise, dette et remplacement selon la difficulté ;
+- vente, remise, réparation et achat d'amélioration.
 
 ### Contrats
 
 - IDs de contenu uniques ;
 - références résolues ;
 - contrat principal terminable ;
-- deux preuves valides pour l'épave ;
+- une cible et deux leurres possèdent chacun des faits cohérents ;
+- chaque leurre a au moins une contradiction découvrable ;
 - objet principal invendable ou récupérable selon la règle ;
+- pack d'archives facultatif et campagne terminable sans lui ;
 - effet d'amélioration reconnu ;
 - sauvegarde V1 aller-retour ;
 - rejet d'une version inconnue ;
@@ -431,22 +658,37 @@ test de round-trip dès la première implémentation.
 ### Intégration
 
 - entrée abstraite vers mouvement et télémétrie ;
+- souris vers caméra sans commande d'orientation du véhicule ;
 - collision vers dégâts uniques ;
 - sonar monde vers `SonarScan` puis maillage ;
 - rotation du véhicule vers orientation de la carte ;
 - vue compacte et agrandie partageant la même texture ;
+- carte vers relevé de surface puis `SurfaceEchoArea` persistante ;
 - observation monde vers progression de mission ;
-- récupération vers inventaire ;
-- retour vers débriefing et sauvegarde ;
-- chargement d'une sauvegarde vers écran correct.
+- outil vers consommation, progression suspendue et accès persistant ;
+- récupération vers panier seulement après transfert terminé ;
+- surface vers treuillage sans restauration automatique ;
+- actions manuelles vers ressources, cale, analyse, paiement et sauvegarde ;
+- chargement d'une sauvegarde vers écran correct ;
+- pause vers suspension puis reprise des ticks sans consommation intermédiaire ;
+- remappage vers commande véhicule sans accès direct de la présentation ;
+- réglage modifié, annulé, appliqué puis rechargé ;
+- abandon confirmé vers conséquence unique, sans double application.
 
 ### Parcours automatisés
 
-1. Succès nominal avec deux preuves et retour.
-2. Retour sans preuve principale : mission non terminée.
-3. Abandon volontaire : perte appliquée, campagne encore jouable.
-4. Batterie vide : pas de mort instantanée, oxygène continue.
-5. Sauvegarde après débriefing puis redémarrage.
+1. Relevé de surface, cible correcte parmi deux leurres, récupération et
+   treuillage.
+2. Retour sans vider le panier puis replongée : ressources et cargaison restent
+   inchangées.
+3. Vidage du panier, analyse du module, remise et déblocage de la piste U-Boot.
+4. Mauvaise hypothèse révisée sous l'eau sans message de validation.
+5. Abandon volontaire : données conservées, panier perdu, navire encore sur le
+   site et remplacement seulement au port.
+6. Perte en Standard puis Expert : modèle basique et franchises 500 € / 750 €.
+7. Batterie vide : pas de mort instantanée, oxygène continue.
+8. Sauvegarde après actions manuelles puis redémarrage.
+9. Marqueur de plongée active simulé : reprise avant plongée sans perte.
 
 Les parcours utilisent des adaptateurs déterministes, pas une simulation de
 plusieurs minutes en temps réel.
@@ -465,6 +707,39 @@ après explication ne satisfait pas le critère d'autonomie.
 
 ## 13. Budgets techniques initiaux
 
+Valeurs de gameplay de départ, toutes configurables et soumises au playtest :
+
+| Valeur | Cible initiale |
+|---|---:|
+| Fréquence de simulation | 60 Hz |
+| Batterie basique | 100 kWh |
+| Oxygène Standard | environ 16 min |
+| Autonomie Standard | environ 1,2 km |
+| Intégrité basique | 100 points |
+| Panier | 6 unités |
+| Cale initiale / première amélioration | 12 / 18 unités |
+| Cutter | 30 kW, environ 12 s, 0,10 kWh hors stabilisation |
+| Bras | 8 kW, environ 6 s, 0,013 kWh hors stabilisation |
+| Examen d'un indice | environ 1,5 s à 8–12 m |
+| Récupération par le navire | rayon 25 m, faible vitesse |
+| Sonar de surface | portée 400 m, incertitude 150 / 75 / minimum 50 m |
+| Argent initial / archives / contrat | 500 € / 500 € / 1 000 € |
+| Cale 12 vers 18 / objet secondaire | 750 € / environ 200 € |
+| Réparation | 4 € par point d'intégrité |
+
+Multiplicateurs de difficulté :
+
+| Règle | Exploration | Standard | Expert |
+|---|---:|---:|---:|
+| Oxygène | ×0,75 | ×1 | ×1,20 |
+| Batterie | ×0,80 | ×1 | ×1,15 |
+| Collision | ×0,65 | ×1 | ×1,25 |
+| Pression | ×0,50 | ×1 | ×1,35 |
+| Grâce avant rupture | ×1,50 | ×1 | ×0,75 |
+| Franchise | 0 € | 500 € | 750 € |
+
+Budgets d'exécution :
+
 | Budget | Cible de départ |
 |---|---:|
 | Framerate de validation locale | 60 FPS à 1080p |
@@ -479,36 +754,79 @@ après explication ne satisfait pas le critère d'autonomie.
 Ces budgets sont des alarmes, pas des promesses commerciales. Une mesure doit
 indiquer la machine, le renderer, la résolution, le build et la scène.
 
-Le renderer Forward+ reste la cible de production. Son adoption pour la
-verticale nécessite un ADR et un test immédiat sur les machines disponibles ;
-elle ne doit pas attendre la phase de finition graphique.
+Forward+ est l'unique renderer de production conformément à
+`docs/adr/0004-forward-plus-only.md`. Ses réglages de qualité et son coût sont
+testés immédiatement sur les machines disponibles ; cette validation ne doit
+pas attendre la phase de finition graphique.
 
 ## 14. Tranches d'implémentation
 
 ### Tranche 0 — fondations exécutables
 
+État au 10 août 2026 : implémentée. La production démarre sur un menu principal
+minimal, puis `Nouvelle partie` ouvre l'écran de diagnostic alimenté par
+`DiveSession`. `Continuer` reste désactivé tant que la persistance n'existe pas
+et l'écran complet de réglages appartient à une tranche ultérieure.
+
 - Créer les sous-dossiers nécessaires, sans architecture vide exhaustive.
-- Définir horloge, IDs et premiers types de résultat.
-- Porter `DiveSession` comme règle pure avec tests.
-- Créer une composition minimale et un écran de diagnostic.
+- Définir IDs, `DiveTick`, `DiveStep`, `ResolvedDiveRules`, snapshots et
+  événements.
+- Créer `DiveSession` comme règle pure, sans horloge interne, avec tests à 60 Hz.
+- Créer une composition minimale, un menu principal fonctionnel et un écran de
+  diagnostic.
 
 Sortie : état de plongée déterministe, testable sans scène, affiché par une scène
 de production qui ne dépend pas des POC.
 
 ### Tranche 1 — véhicule de production
 
+État au 10 août 2026 : implémentée. `Nouvelle partie` ouvre désormais un
+parcours court en vue intérieure avec mouvement inertiel, caméra souris séparée,
+ressources réelles, environnement Forward+, pause complète et remappage clavier
+avec détection puis permutation des conflits. Les valeurs de départ reprennent
+la baseline du POC A sans importer son code.
+
 - Réécrire le contrôleur derrière `VehicleCommand` et `VehicleTelemetry`.
 - Reproduire les sensations validées du POC A à partir de sa baseline.
-- Intégrer caméra intérieure et hublot.
+- Intégrer caméra intérieure, hublot et `CameraLookCommand` indépendant de la
+  coque.
+- Ajouter le menu pause et le premier parcours de remappage.
 - Ajouter les tests de mouvement et de dégâts prioritaires.
 
 Sortie : parcours de pilotage court avec ressources et retour immédiat lisible.
 
+### Tranche 1.5 — cockpit fonctionnel représentatif
+
+État au 16 août 2026 : implémentée après revue visuelle native Forward+ à
+1280 × 720. Cette tranche corrige le graybox initial, qui ne contenait qu'une
+caméra, un cercle Canvas et des textes superposés.
+
+- Construire une coque intérieure 3D fixe par rapport au véhicule, indépendante
+  du regard de la caméra.
+- Remplacer le cercle Canvas par un hublot 3D occultant avec cadre, joint, verre,
+  boulons et cloisons.
+- Ajouter tableau de bord, consoles, leviers, bouton d'éjection, éclairage et
+  premiers matériaux métalliques procéduraux.
+- Présenter batterie, oxygène, coque, pression, profondeur, vitesse et retour
+  sur des instruments physiques alimentés par `DiveUpdate` et
+  `VehicleTelemetry`.
+- Réserver un moniteur physique au sonar de la tranche 2.
+- Limiter la surimpression 2D aux alertes, à l'éjection et à la fin de plongée.
+- Garantir un relief et une balise visibles dès le point de départ.
+
+Les textures détaillées, l'usure, les animations secondaires et l'art final
+restent dans la tranche 6. Le cockpit actuel doit cependant rester assez
+représentatif pour valider la composition du sonar et la lisibilité en jeu.
+
+Sortie : un habitacle identifiable et fonctionnel, dont les instruments
+constituent la cible réelle d'intégration du sonar.
+
 ### Tranche 2 — sonar de production
 
-- Définir `SonarSample` et `SonarScan`.
+- Définir `SonarSampleBuffer`, `SonarContact` et `SonarScan`.
 - Séparer acquisition, reconstruction et présentation.
-- Reproduire la bathymétrie validée sans importer le POC B.
+- Réécrire la bathymétrie validée sans importer le POC B et comparer le
+  faisceau frontal derrière le même contrat.
 - Mesurer le coût et passer à une mise à jour incrémentale.
 
 Sortie : relief inconnu révélé manuellement, lisible dans les deux vues, avec
@@ -516,28 +834,34 @@ rotation et remplacement d'un relevé.
 
 ### Tranche 3 — site et découverte
 
-- Construire le terrain graybox et l'épave contemporaine.
-- Ajouter une entrée masquée simple, sans surplomb complexe.
-- Définir deux preuves et une anomalie secondaire.
+- Ajouter carte limitée, position persistante du navire et sonar de surface.
+- Construire le terrain graybox, l'épave majeure contemporaine et deux leurres
+  extérieurs modulaires.
+- Ajouter registre, pack d'archives, faits observables et dossier comparatif.
+- Implémenter les états cartographiques sans révéler un secret inconnu.
 - Organiser le premier playtest de recherche.
 
-Sortie : 8 testeurs sur 10 trouvent l'épave dans la fenêtre cible ou une porte de
-décision est déclenchée.
+Sortie : 8 testeurs sur 10 passent de la zone probable à la bonne épave et
+peuvent expliquer leur choix, ou une porte de décision est déclenchée.
 
 ### Tranche 4 — interaction et retour
 
-- Ajouter une interaction d'ouverture bornée.
-- Ajouter la caisse, le panier et l'objet principal.
-- Ajouter zone de retour, succès, abandon et perte.
+- Ajouter cutter, stabilisation assistée, consommation électrique et ouverture
+  persistante.
+- Ajouter bras, panier de 6 unités, module, pièce et objet secondaire.
+- Ajouter navire 3D simplifié, zone de retour, treuillage, abandon et perte.
 - Automatiser les parcours nominaux et d'échec.
 
 Sortie : boucle de plongée complète sans métajeu.
 
 ### Tranche 5 — contrat, économie et sauvegarde
 
-- Ajouter briefing, fiche, débriefing et atelier.
-- Ajouter une vente/restitution et une amélioration.
-- Écrire Save V1 et ses tests de contrat.
+- Ajouter port, entreprise, Archives, Chantier naval et Comptoir.
+- Ajouter entretien manuel, cale, analyse des données, remise, vente, dette et
+  amélioration 12 vers 18.
+- Ajouter contrat visible, objectif réel et révélation de la piste U-Boot.
+- Ajouter Continuer, les états de chargement et la persistance des réglages.
+- Écrire les sauvegardes JSON V1 et leurs tests de contrat.
 
 Sortie : boucle verticale complète et rejouable après redémarrage.
 
@@ -556,7 +880,10 @@ Sortie : décision documentée de poursuivre, corriger ou réduire le projet.
 |---|---|---|
 | Sensations perdues pendant la réécriture | test véhicule dès tranche 1 | comparer aux mesures POC A, ajuster avant sonar |
 | Sonar lisible seul mais confus en mission | playtest tranche 3 | réduire relief parasite ou resserrer la zone probable |
+| Sonar de surface répétitif | nombre de relevés avant une plongée utile | conserver les résultats déterministes et réduire la zone initiale |
+| Leurres aussi coûteux que la cible | mesure de production des micro-sites | extérieurs modulaires, faits seulement, aucun accès complexe |
 | Ouverture impossible à représenter | site graybox dédié | ajouter surfaces locales ; ne pas revenir aux voxels globaux |
+| Stabilisation d'outil frustrante | taux d'interruption et corrections requises | élargir les tolérances, suspendre sans réinitialiser |
 | États dupliqués entre monde et HUD | tests de propriétaire et snapshots | supprimer la copie, rétablir un flux unidirectionnel |
 | Scènes fortement couplées | contrôle d'architecture | déplacer l'assemblage vers `composition` |
 | Sauvegarde conçue trop tard | Save V1 tranche 5 au plus tard | bloquer le métajeu tant que le round-trip échoue |
@@ -572,11 +899,24 @@ suite indéfinie de corrections sans critère de sortie.
 
 Une fois ce document approuvé, créer des ADR séparés pour :
 
-1. le renderer de production de la verticale ;
-2. les contrats `VehicleTelemetry`, `DiveSnapshot` et `SonarScan` ;
-3. la sauvegarde V1 et sa stratégie atomique ;
-4. l'absence initiale d'autoload de gameplay ;
-5. le modèle hybride retenu si le site exige une surface non bathymétrique.
+1. le renderer Forward+ unique de production, formalisé dans
+   `docs/adr/0004-forward-plus-only.md` ;
+2. les contrats de tick, télémétrie, snapshot/événements et règles résolues,
+   formalisés dans `docs/adr/0005-fixed-dive-ticks-and-typed-updates.md` ;
+3. le contrat sonar commun, le buffer compact et la porte de comparaison,
+   formalisés dans `docs/adr/0006-sonar-contract-and-acquisition-gate.md`, puis
+   l'acquisition retenue dans un ADR de sélection ;
+4. la sauvegarde JSON V1, ses emplacements, migrations, secours et remplacement
+   récupérable, formalisés dans `docs/adr/0007-versioned-json-saves.md` ;
+5. l'absence d'autoload de gameplay et la propriété des services par la
+   composition, formalisées dans
+   `docs/adr/0008-composition-owned-service-lifetimes.md` ;
+6. le modèle de progression qui sépare vérité du contenu, termes du contrat,
+   objectifs réels et connaissances du joueur, formalisé dans
+   `docs/adr/0009-player-knowledge-driven-progression.md` ;
+7. la limitation de la V1 à une surface bathymétrique unique, formalisée dans
+   `docs/adr/0010-single-surface-bathymetry-for-v1.md` ; un modèle hybride
+   nécessitera un prototype et un nouvel ADR lorsqu'un site concret l'exigera.
 
 Les noms de classes peuvent évoluer pendant la tranche 0. Les responsabilités,
 les propriétaires et les directions de dépendance ne changent qu'avec un ADR.
@@ -586,11 +926,12 @@ les propriétaires et les directions de dépendance ne changent qu'avec un ADR.
 La première implémentation ne sera ni le sous-marin ni le sonar. Elle créera une
 tranche verticale minuscule :
 
-1. `DiveSession` pur avec horloge injectée ;
-2. `VehicleTelemetry` minimal fourni par un faux adaptateur ;
-3. `DiveSnapshot` affiché dans une scène de diagnostic ;
-4. tests de consommation, profondeur et état terminal ;
-5. ajout de cette suite à `scripts/quality_gate.sh`.
+1. `DiveSession` pur recevant un `DiveStep` explicite ;
+2. `ResolvedDiveRules` produit depuis des fixtures de base et de difficulté ;
+3. `VehicleTelemetry` minimal fourni par un faux adaptateur ;
+4. `DiveUpdate` affiché dans une scène de diagnostic ;
+5. tests de tick, consommation, profondeur, alertes et état terminal ;
+6. ajout de cette suite à `scripts/quality_gate.sh`.
 
 Cette tranche prouvera le chemin complet domaine → application → présentation
 et la discipline de tests avant de porter un comportement complexe.

docs/adr/0004-forward-plus-only.md

@@ -0,0 +1,73 @@
+# 0004 — Forward+ comme renderer unique de production
+
+- Statut : accepté
+- Date : 2026-08-10
+- Remplace : aucun
+
+## Contexte
+
+Les POC A et B ont été validés avec GL Compatibility afin de faciliter les
+premiers essais. Cette configuration a aussi conduit le POC A à simuler la
+diffusion des projecteurs avec des plans translucides dépendants du point de
+vue. Ces compromis restent documentés dans les baselines, mais ne répondent pas
+à la direction visuelle de la production : matériaux PBR, éclairage sous-marin,
+brouillard, particules et ombres réglables.
+
+Maintenir plusieurs renderers augmenterait le nombre de configurations à
+tester et encouragerait des chemins graphiques divergents. Les performances
+doivent être ajustées par la qualité des effets, pas par un changement de
+renderer qui modifierait le rendu et les capacités disponibles.
+
+## Décision
+
+Forward+ est l'unique renderer pris en charge par le code et les builds de
+production. Le jeu ne propose ni sélection de renderer, ni repli automatique
+vers GL Compatibility.
+
+Les POC demeurent des références historiques jetables dans leur configuration
+GL Compatibility documentée. Ils ne définissent pas une seconde configuration
+prise en charge et leur code ou leurs artifices graphiques ne sont pas repris
+en production.
+
+Les réglages d'affichage permettent d'adapter les performances sans quitter
+Forward+. Ils couvrent au minimum des niveaux de qualité pour les particules,
+les ombres, la distance d'affichage et le post-traitement. Les effets
+atmosphériques coûteux, dont le brouillard volumétrique s'il est retenu après
+mesure, suivent la même politique. Des préréglages cohérents peuvent exposer
+ces valeurs ensemble, avec des réglages détaillés lorsque cela reste lisible.
+
+Une baisse de qualité ne change aucune règle de gameplay et ne peut supprimer
+une information indispensable à la navigation, aux alarmes ou à la lecture du
+sonar. Les choix sont persistés dans les réglages du joueur, séparément de la
+sauvegarde de campagne.
+
+Chaque mesure de performance indique le renderer Forward+, la résolution, le
+préréglage graphique, la machine, le build et la scène testée. La première
+scène de production mesure explicitement le coût des projecteurs, des ombres,
+du brouillard et des particules avant la phase de finition visuelle.
+
+## Conséquences
+
+- Le rendu de production possède une seule configuration architecturale à
+  développer et vérifier.
+- Les machines ne prenant pas correctement en charge Forward+ ne sont pas des
+  cibles de la V1.
+- Les performances faibles se traitent par des niveaux de qualité mesurés,
+  des LOD et des budgets d'effets, sans branche de rendu alternative.
+- Le mode bas conserve la lisibilité fonctionnelle à 1080p tout en réduisant
+  particules, ombres, distance d'affichage et post-traitement.
+- Le comportement visuel doit être vérifié sur macOS ARM64, Windows et Linux
+  avant la fin de la verticale.
+- Les plans translucides utilisés comme volumes de phare dans le POC A ne sont
+  pas promus ; les projecteurs de production sont reconstruits et profilés.
+
+## Alternatives considérées
+
+- **GL Compatibility comme renderer de production** : rejeté, car ses limites
+  contrarient les besoins d'éclairage et d'atmosphère visés.
+- **Forward+ avec GL Compatibility comme mode de secours** : rejeté, car cela
+  imposerait deux chemins graphiques, deux profils de performance et davantage
+  de régressions visuelles possibles.
+- **Mobile comme renderer de secours** : rejeté pour la V1 pour les mêmes
+  raisons. Une cible matérielle future nécessiterait un nouvel ADR et une
+  validation graphique dédiée.

docs/adr/0005-fixed-dive-ticks-and-typed-updates.md

@@ -0,0 +1,139 @@
+# 0005 — Ticks de plongée fixes et mises à jour typées
+
+- Statut : accepté
+- Date : 2026-08-10
+- Remplace : aucun
+
+## Contexte
+
+La plongée combine une physique Godot, des ressources continues, des dégâts
+ponctuels, des outils électriques, des alarmes et plusieurs présentations. Si
+chaque acteur ou interface utilise sa propre horloge ou recalcule une partie de
+ces règles, la pause, les variations de framerate et l'ordre des signaux peuvent
+produire des résultats différents.
+
+Les informations n'ont pas toutes la même nature. Une commande exprime une
+intention, la télémétrie décrit une mesure du monde, un snapshot décrit l'état
+autoritaire à un instant et un événement rapporte un fait survenu pendant une
+transition. Les regrouper dans un dictionnaire ou un signal générique rendrait
+leur propriétaire et leur temporalité implicites.
+
+## Décision
+
+### Horloge et cadence
+
+La simulation de plongée utilise une cadence de physique configurée à 60 Hz.
+L'application fournit exactement un `DiveStep` au domaine pour chaque tick de
+physique accepté. Le domaine n'accède ni à l'horloge système, ni au framerate,
+ni à l'arbre de scènes.
+
+Un `DiveTick` contient au minimum l'identifiant de session, une séquence
+strictement croissante et la durée du pas en secondes. La durée normale vaut
+`1 / 60` seconde. Un pas nul, négatif, non fini ou désordonné est refusé. Un pas
+supérieur à 0,1 seconde est subdivisé de manière déterministe par l'application
+ou refusé ; il n'est jamais appliqué comme un grand saut unique.
+
+La pause suspend la production de `DiveStep`. À la reprise, le temps passé en
+pause n'est ni simulé, ni rattrapé. Les tests utilisent des ticks construits
+explicitement et n'attendent jamais le temps réel.
+
+### Contrats d'entrée séparés
+
+- `VehicleCommand` contient l'intention de propulsion issue du clavier ou d'un
+  autre périphérique remappé. La souris n'oriente jamais le sous-marin.
+- `CameraLookCommand` contient uniquement le mouvement de regard dans la
+  cabine. Il ne traverse pas le contrat de pilotage du véhicule.
+- `VehicleTelemetry` est un snapshot immuable produit par l'acteur physique :
+  transform, vitesses, profondeur et efforts réellement appliqués.
+- `DiveTelemetrySample` réduit cette télémétrie aux mesures nécessaires aux
+  règles de plongée. Le domaine ne reçoit aucun `Node` ou `Transform3D` Godot.
+- `CollisionObservation` décrit un impact ponctuel avec une séquence stable et
+  sa vitesse normale en mètres par seconde. Les observations sont traitées de
+  manière idempotente.
+- `ToolPowerDemand`, `EjectionIntent` et `ReturnRouteSample` décrivent
+  séparément la demande électrique des outils, l'intention d'éjection et les
+  données connues pour estimer le retour.
+- `DiveStep` agrège ces entrées pour un tick sans changer leur responsabilité.
+
+Ces frontières utilisent des objets typés. Les dictionnaires anonymes restent
+confinés aux codecs ou aux prototypes et ne traversent pas la production.
+
+### Règles résolues et session
+
+Au début de chaque plongée, `DiveRulesResolver` construit un
+`ResolvedDiveRules` immuable en appliquant, dans cet ordre :
+
+1. les règles de base ;
+2. les capacités et améliorations du sous-marin ;
+3. le profil de difficulté ;
+4. les aides d'accessibilité qui modifient le gameplay ;
+5. la validation et le bornage des valeurs.
+
+`DiveSession` est l'unique propriétaire de l'oxygène, de la batterie, de la
+coque, des seuils de pression, des alertes, de l'estimation de retour et de
+l'état terminal de la plongée. C'est un objet de domaine pur : il reçoit un
+`DiveStep`, applique les règles résolues dans un ordre fixe et retourne un
+`DiveUpdate`.
+
+L'ordre d'un pas est : validation, consommation, pression, collisions ordonnées,
+éjection, estimation du retour, alertes, état terminal, puis publication. Une
+session terminale ne rejoue pas sa conséquence et refuse toute mutation de
+gameplay ultérieure.
+
+### Snapshot et événements
+
+Chaque pas accepté produit un seul `DiveUpdate` cohérent, associé à la session
+et à la séquence du tick. Il contient :
+
+- un `DiveSnapshot` immuable représentant l'état autoritaire après le pas ;
+- zéro ou plusieurs événements typés décrivant uniquement les faits survenus
+  pendant ce pas.
+
+Le snapshot contient les valeurs actuelles et maximales, leurs unités et leurs
+ratios pour batterie, oxygène, coque, pression et profondeur, ainsi que
+l'estimation du retour, les alertes, l'éjection et l'éventuel motif terminal.
+Il permet à un nouvel écran de se synchroniser sans rejouer l'historique.
+
+Les événements, tels que `AlertLevelChanged`, `HullDamaged`,
+`ResourceDepleted` et `DiveTerminated`, déclenchent les réactions ponctuelles :
+audio, animation, journal ou transition applicative. Ils portent une identité
+ou une séquence permettant aux adaptateurs d'éviter un double traitement. Un
+événement ne remplace jamais une valeur persistante du snapshot.
+
+La présentation et l'audio consomment `DiveUpdate`. Ils ne recalculent ni
+seuils, ni dégâts, ni consommation, ni fin de plongée. Ils ne mutent jamais
+directement `DiveSession` ou l'acteur physique ; toute action repart sous forme
+de commande applicative.
+
+## Conséquences
+
+- Une même suite de règles, commandes, télémétries et observations produit le
+  même résultat dans les tests et dans le jeu.
+- La pause est une absence de ticks, pas un multiplicateur de temps dispersé
+  entre plusieurs systèmes.
+- Le HUD peut afficher des valeurs exactes et des pourcentages sans posséder
+  une copie concurrente des ressources.
+- L'audio peut réagir une seule fois aux transitions tout en consultant l'état
+  courant à tout moment.
+- La conversion entre les types Godot et les données pures nécessite des
+  adaptateurs explicites.
+- Ajouter une nouvelle entrée ou sortie de simulation demande un contrat nommé
+  et des tests, mais évite les clés implicites et les dépendances de scène.
+- Les consommations indépendantes du tick de plongée, notamment les actions de
+  port, restent des cas d'usage de campagne distincts.
+
+## Alternatives considérées
+
+- **Chaque système utilise `_process(delta)`** : rejeté, car les règles
+  dépendraient du framerate et leur ordre serait difficile à garantir.
+- **`DiveSession` lit directement la physique et l'horloge Godot** : rejeté,
+  car le domaine ne serait plus pur ni testable sans scène.
+- **Un dictionnaire unique de données par frame** : rejeté, car commandes,
+  mesures, états et événements auraient une temporalité implicite.
+- **Publier uniquement des événements** : rejeté, car un écran ouvert plus tard
+  devrait reconstruire l'état en rejouant l'historique.
+- **Publier uniquement un snapshot** : rejeté, car les consommateurs devraient
+  comparer deux états et réinventer les transitions ponctuelles.
+- **Rattraper les ticks après une pause ou un ralentissement important** :
+  rejeté, car cela provoquerait des consommations et dégâts invisibles ou des
+  pics de calcul au retour.

docs/adr/0006-sonar-contract-and-acquisition-gate.md

@@ -0,0 +1,149 @@
+# 0006 — Contrat sonar commun et porte de sélection de l'acquisition
+
+- Statut : accepté
+- Date : 2026-08-10
+- Remplace : aucun
+
+## Contexte
+
+Le POC B a validé une représentation bathymétrique continue, révélée
+progressivement, qui rend le relief navigable. Son acquisition principale
+utilise toutefois des sondes verticales disposées devant le véhicule et peut
+montrer le dessus de surfaces qu'un faisceau frontal ne verrait pas. Une passe
+frontale distincte détecte les anomalies métalliques. Cette combinaison est
+lisible, mais elle n'est ni une simulation acoustique fidèle, ni une
+implémentation de production.
+
+Une acquisition entièrement frontale serait plus cohérente avec la position du
+capteur, mais risque de produire des trous, de perdre la continuité du relief ou
+de rendre le sonar à nouveau difficile à interpréter. Le comportement validé du
+POC doit donc rester la référence pendant l'expérience, sans importer son code
+jetable dans la production.
+
+L'acquisition, la reconstruction et la présentation doivent pouvoir évoluer
+séparément. Sinon, comparer deux méthodes imposerait aussi de réécrire le
+renderer et rendrait leurs résultats impossibles à évaluer équitablement.
+
+## Décision
+
+### Contrat commun
+
+Toutes les acquisitions candidates produisent le même `SonarScan`. Celui-ci
+contient au minimum :
+
+- un identifiant de scan et l'identifiant de la session ;
+- le transform du capteur figé à l'émission ;
+- la portée, les ouvertures et la durée de révélation ;
+- les dimensions logiques de la grille ;
+- un `SonarSampleBuffer` immuable ;
+- des `SonarContact` distincts ;
+- l'échelle de couleur et les valeurs réelles minimales et maximales ;
+- l'état prêt, capture, révélation ou récupération.
+
+Le repère du scan est figé au déclenchement, avec son origine au capteur, +X à
+tribord, +Y vers le haut et +Z vers l'avant, en mètres. L'adaptateur du monde
+convertit le -Z avant de Godot vers ce contrat. Aucun consommateur ne déduit ou
+réinterprète cette convention.
+
+`SonarSampleBuffer` encapsule des tableaux parallèles compacts de positions,
+normales, intensités, élévations réelles, matériaux et statuts d'observation.
+Un même index décrit un échantillon ; la ligne et la colonne sont dérivées des
+dimensions de grille. Un accesseur typé comme `sample_at(row, column)` masque la
+représentation interne et vérifie les bornes. Le buffer devient immuable avant
+sa publication.
+
+Les contacts ne sont pas obtenus en moyennant tous les retours d'un matériau.
+Un clustering spatial déterministe produit plusieurs `SonarContact`, chacun
+avec une identité, un matériau, un centre, des limites, une intensité maximale
+et un nombre d'échantillons.
+
+### Acquisition, reconstruction et présentation
+
+L'adaptateur sonar du monde possède l'acquisition physique. Le service
+applicatif valide et structure les échantillons ainsi que les contacts. La
+présentation reconstruit et affiche le relief à partir du scan publié ; elle ne
+fait ni classification métier, ni détection de mission.
+
+La palette d'altitude reste relative au scan pour préserver le contraste, mais
+les élévations réelles en mètres sont conservées et une légende chiffrée indique
+l'échelle employée. Noir représente l'inconnu, pas une profondeur arbitraire.
+
+Un seul scan courant et un seul scan précédent en fondu existent au maximum.
+La vue compacte et la vue agrandie affichent la même texture produite par un
+renderer unique. Elles ne reconstruisent pas deux maillages indépendants.
+
+La révélation de référence dure 2,5 secondes, puis la récupération 0,35 seconde.
+Une nouvelle demande n'est pas mise en file pendant cette séquence. Ces valeurs
+restent configurables et testées, mais leur temporalité appartient au service
+sonar, pas au HUD.
+
+### Porte de sélection
+
+Deux acquisitions sont réécrites derrière ce contrat uniquement pendant une
+calibration bornée :
+
+1. la méthode de référence inspirée du POC B, combinant une grille
+   bathymétrique lisible et une détection frontale des anomalies ;
+2. une méthode par faisceau frontal, reconstruite dans le même buffer.
+
+La comparaison utilise les mêmes poses de capteur, scènes, portées, dimensions
+de sortie et cas de test : pente, chenal, rupture de relief, épave, ouverture,
+zones masquées et plusieurs contacts métalliques séparés. Elle mesure au
+minimum :
+
+- la compréhension du relief et d'un passage par des testeurs ;
+- la détection de l'épave et de plusieurs anomalies sans fusion incorrecte ;
+- la stabilité face aux trous et aux rotations du véhicule ;
+- le coût CPU moyen et maximal, les allocations et le coût de reconstruction ;
+- la conservation de l'effet de révélation validé.
+
+Le faisceau frontal n'est retenu que s'il atteint une lisibilité et une
+stabilité au moins équivalentes à la réécriture de référence dans les budgets
+de la verticale. Dans le cas contraire, la méthode inspirée du POC devient
+l'acquisition de production. La fidélité acoustique ne prime pas sur la
+capacité du joueur à lire le relief et à naviguer.
+
+La porte produit un compte rendu et un ADR de sélection. Après cette décision,
+une seule acquisition reste autoritaire dans `game/`. L'autre implémentation
+n'est pas maintenue comme chemin de secours ; les scènes, données de calibration
+et résultats comparatifs peuvent être conservés pour prévenir les régressions.
+
+### Persistance
+
+Ni les échantillons bruts, ni le buffer, ni le maillage, ni les couleurs d'un
+scan sous-marin ne sont sauvegardés. La campagne persiste seulement les faits
+sémantiques sécurisés : zones d'écho de surface, épaves localisées, identités et
+observations. Une sauvegarde ne tente jamais de reconstruire une image sonar en
+cours de révélation.
+
+## Conséquences
+
+- Le comportement apprécié dans le POC reste disponible comme référence et
+  issue sûre sans promouvoir son code.
+- Une acquisition peut être remplacée sans modifier le renderer, le HUD ou les
+  règles de mission.
+- Le buffer compact limite les allocations, mais demande un accesseur typé et
+  des tests d'alignement de tous les tableaux.
+- Les conversions de coordonnées sont explicites et testables.
+- Plusieurs anomalies restent distinctes, contrairement à la moyenne globale
+  provisoire du POC.
+- Le rendu sonar possède une seule reconstruction et une seule texture, ce qui
+  réduit les divergences entre les deux tailles d'affichage.
+- La calibration ajoute un coût court à la tranche sonar, borné par une porte
+  de décision et supprimant ensuite le chemin perdant.
+
+## Alternatives considérées
+
+- **Copier le sonar du POC B dans la production** : rejeté, car cela
+  introduirait ses dépendances, sa reconstruction complète et ses contrats
+  implicites dans `game/`.
+- **Choisir immédiatement le faisceau frontal** : rejeté, car sa vraisemblance
+  ne garantit pas la lisibilité déjà difficile à obtenir.
+- **Conserver durablement les deux acquisitions** : rejeté, car deux
+  implémentations autoritaires doubleraient réglages, tests et risques de
+  régression.
+- **Publier directement des nœuds, maillages ou dictionnaires depuis le monde** :
+  rejeté, car acquisition et présentation resteraient couplées.
+- **Sauvegarder la carte sonar brute** : rejeté, car elle représente une vue
+  temporaire dérivée du monde et alourdirait le format sans bénéfice de
+  progression.

docs/adr/0007-versioned-json-saves.md

@@ -0,0 +1,192 @@
+# 0007 — Sauvegardes JSON versionnées et remplaçables sans perte
+
+- Statut : accepté
+- Date : 2026-08-10
+- Remplace : aucun
+
+## Contexte
+
+La campagne contient un état métier durable : argent, dette, position du
+navire, contrats, archives, épaves connues, cargaison et améliorations. Une
+plongée contient en plus un état physique très fréquent et temporaire. Tenter
+de sérialiser les nœuds, les collisions, le maillage sonar ou la position
+arbitraire du sous-marin couplerait la sauvegarde aux scènes et rendrait les
+migrations fragiles.
+
+Le joueur doit pouvoir conserver plusieurs étapes d'une même campagne, utiliser
+des sauvegardes manuelles et reprendre après un crash sans perdre un
+sous-marin à cause d'une écriture interrompue. Les réglages de plateforme et
+d'accessibilité ne doivent pas être dupliqués dans chaque état de campagne.
+
+## Décision
+
+### Format et enveloppe
+
+Chaque sauvegarde est un document JSON explicite. Son enveloppe contient au
+minimum :
+
+```text
+schema_version  entier positif
+campaign_id     identifiant stable de la partie
+save_id         identifiant stable de cette sauvegarde
+created_at_utc  date ISO 8601 utilisée comme métadonnée d'affichage
+kind            before_dive | after_dive | campaign | manual
+display_name    libellé facultatif d'une sauvegarde manuelle
+payload         état de campagne versionné
+```
+
+Les identifiants sont générés et validés par l'application. Un libellé saisi
+par le joueur n'est jamais utilisé comme nom de fichier ou fragment de chemin.
+Les horodatages viennent d'une horloge injectée ; ils n'influencent aucune
+règle de gameplay.
+
+Le codec JSON appartient à l'infrastructure. Il convertit entre les
+dictionnaires du format et des objets de transfert typés, puis entre ces objets
+et le domaine. Aucun dictionnaire anonyme, chemin de scène, `Node`, `Resource`
+arbitraire ou objet exécutable ne traverse cette frontière.
+
+Le payload contient au minimum :
+
+- difficulté, argent et dette ;
+- `VesselLocation`, disponibilité du sous-marin et ressources non remplies ;
+- contrats, objectifs connus et révélations ;
+- zones d'écho, épaves localisées, identités et observations sécurisées ;
+- états persistants d'ouverture et d'interaction ;
+- panier, cale, stockage et objets narratifs ;
+- archives, plans et améliorations ;
+- dernier résultat de plongée.
+
+Les références de contenu utilisent des identifiants stables validés au
+chargement. Une valeur dérivée est recalculée à partir de ses sources lorsqu'il
+est possible de le faire sans perte d'information.
+
+### Organisation des fichiers
+
+Les campagnes sont rangées sous :
+
+```text
+user://saves/<campaign_id>/
+  autosave_before_dive.json
+  autosave_after_dive.json
+  autosave_campaign.json
+  manual/<save_id>.json
+  active_dive.marker.json
+```
+
+Les fichiers temporaires et de secours utilisent des suffixes techniques dans
+le même dossier que leur cible. Ils ne sont pas affichés comme des sauvegardes.
+Le `campaign_id` identifie la lignée créée par une nouvelle partie ; il ne
+représente pas une seconde campagne narrative.
+
+Les réglages du joueur sont versionnés et stockés séparément sous
+`user://settings.json`. Ils comprennent notamment commandes, accessibilité,
+audio, affichage et qualité Forward+. Charger une autre sauvegarde de campagne
+ne les remplace pas.
+
+### Politique des emplacements
+
+Trois emplacements automatiques ont une signification fixe :
+
+- `before_dive` est écrit après validation de la préparation et avant le
+  chargement de la scène sous-marine ;
+- `after_dive` est écrit après application unique du résultat de plongée au
+  navire et à la campagne ;
+- `campaign` est écrit après une action durable de progression, notamment
+  transfert, analyse, remise, vente, entretien ou achat.
+
+Chaque autosauvegarde conserve sa dernière version valide comme secours
+invisible. Une sauvegarde manuelle remplacée conserve également sa précédente
+version valide comme secours technique.
+
+Le joueur peut créer jusqu'à dix sauvegardes manuelles nommées, uniquement
+lorsqu'aucune plongée n'est active. Atteindre la limite exige de choisir et de
+confirmer un remplacement ou une suppression ; aucune sauvegarde visible n'est
+effacée automatiquement.
+
+`Continuer` charge la sauvegarde principale valide la plus récente parmi tous
+les emplacements visibles. Si elle est invalide, son secours est essayé, puis
+la recherche continue avec les autres sauvegardes valides. `Charger` affiche
+les sauvegardes visibles avec leur statut sans supprimer ni réécrire les
+fichiers invalides.
+
+### Écriture récupérable
+
+Une écriture suit toujours cette procédure :
+
+1. sérialiser vers un fichier temporaire créé dans le dossier de la cible ;
+2. fermer le fichier, puis le relire intégralement ;
+3. décoder, migrer si nécessaire et valider le document relu ;
+4. préserver la cible valide actuelle comme secours ;
+5. remplacer la cible par renommage sur le même volume ;
+6. restaurer le secours si le remplacement final échoue ;
+7. signaler explicitement le succès ou l'erreur à l'application.
+
+La dernière sauvegarde valide n'est jamais supprimée avant qu'une nouvelle
+copie complète ait été écrite et validée. Un échec d'I/O ne devient ni une
+réussite silencieuse, ni un nouvel état de campagne.
+
+Au démarrage, l'infrastructure peut supprimer uniquement les temporaires
+orphelins dont la cible ou le secours valide a été identifié. Elle ne supprime
+jamais automatiquement une sauvegarde visible invalide.
+
+### Plongée interrompue
+
+Après réussite de l'autosauvegarde `before_dive`, le démarrage effectif de la
+plongée crée `active_dive.marker.json`. Ce marqueur contient seulement le
+`campaign_id`, le `save_id` de reprise et un identifiant de session. Il ne
+contient aucune position, ressource, collision ou donnée sonar.
+
+Une fin de plongée traitée avec succès supprime le marqueur après écriture de
+l'état `after_dive`. Si le jeu redémarre avec un marqueur valide, il propose ou
+effectue la reprise depuis l'autosauvegarde `before_dive` référencée. Le crash
+n'inflige ni perte automatique du véhicule, ni consommation intermédiaire.
+
+La position arbitraire du sous-marin, les vitesses, particules, collisions,
+échantillons sonar, couleurs et maillages dynamiques ne sont jamais sauvegardés.
+
+### Versions et migrations
+
+`schema_version` existe dès la V1. Le chargement applique des migrations
+explicites, successives et déterministes d'une version prise en charge vers la
+version courante, puis valide l'ensemble des invariants et références de
+contenu.
+
+Une fixture anonymisée de chaque version prise en charge est conservée sous
+`tests/fixtures/`. Les tests vérifient migration, aller-retour, sauvegarde
+tronquée, référence absente, secours et refus d'une version inconnue.
+
+Une version plus récente que celle du jeu est refusée proprement. Le fichier
+original n'est ni modifié, ni rétrogradé. Une migration réussie en mémoire ne
+réécrit pas non plus l'original avant une nouvelle sauvegarde explicitement
+déclenchée.
+
+## Conséquences
+
+- Les sauvegardes survivent aux changements de scènes et peuvent être testées
+  sans lancer une plongée.
+- Plusieurs étapes d'une partie coexistent sans transformer les libellés du
+  joueur en chemins dangereux.
+- Une plongée ne peut pas être reprise à la seconde exacte de l'interruption ;
+  elle recommence depuis sa préparation validée.
+- Les sauvegardes et leurs secours consomment davantage d'espace, mais elles ne
+  contiennent pas les données physiques ou sonar volumineuses.
+- Chaque modification du format exige une migration et des fixtures de
+  contrat. Toute exception nécessite un nouvel ADR.
+- Les réglages restent disponibles même lorsqu'aucune campagne valide n'existe.
+- Les erreurs de disque ou de validation restent récupérables et visibles pour
+  le joueur.
+
+## Alternatives considérées
+
+- **Sérialiser l'arbre de scènes Godot** : rejeté, car les chemins, nœuds et
+  états physiques ne constituent pas un contrat de sauvegarde stable.
+- **Sauvegarder pendant la plongée** : rejeté pour la V1, car restaurer une
+  simulation cohérente coûterait beaucoup plus que reprendre avant le départ.
+- **Une seule sauvegarde écrasée en place** : rejeté, car une interruption
+  d'écriture pourrait détruire toute la progression.
+- **Un format binaire opaque** : rejeté pour la V1, car il compliquerait
+  inspection, fixtures et migrations sans besoin de taille démontré.
+- **Inclure les réglages dans chaque sauvegarde** : rejeté, car ils
+  appartiennent au joueur et à la plateforme, pas à une étape de campagne.
+- **Supprimer automatiquement les sauvegardes invalides ou excédentaires** :
+  rejeté, car la récupération ou le choix doit rester sous contrôle du joueur.

docs/adr/0008-composition-owned-service-lifetimes.md

@@ -0,0 +1,128 @@
+# 0008 — Services possédés et injectés par la composition
+
+- Statut : accepté
+- Date : 2026-08-10
+- Remplace : aucun
+
+## Contexte
+
+Les réglages, l'accès aux sauvegardes, l'audio et une campagne chargée doivent
+survivre à plusieurs changements d'écran. Godot permet de résoudre ce besoin
+avec des autoloads, des singletons statiques ou un bus de signaux global. Ces
+solutions rendent toutefois les dépendances accessibles depuis n'importe quel
+script, masquent leur durée de vie et compliquent l'isolation des tests.
+
+La verticale possède déjà une couche `composition`, seule autorisée à connaître
+les implémentations concrètes de toutes les autres couches. Elle peut donc
+maintenir les objets de longue durée sans les transformer en état global.
+
+## Décision
+
+### Aucun accès global de gameplay
+
+Aucun autoload personnalisé, singleton statique, registre global, service
+locator ou bus de signaux global n'est introduit pour le gameplay de la
+verticale. Une longue durée de vie ne suffit pas à justifier un accès global.
+
+Les singletons fournis par Godot restent des détails de plateforme. Seuls les
+adaptateurs autorisés les utilisent ; le domaine et les cas d'usage ne lisent
+pas directement `Input`, `SceneTree`, `AudioServer`, les fichiers ou l'horloge.
+
+### Racine persistante
+
+`vertical_slice_root.tscn` est la racine de composition persistante de la
+verticale. Elle crée les implémentations concrètes, les relie à leurs ports et
+possède un emplacement destiné à l'écran ou au monde actif. Une transition
+remplace ce contenu enfant sans remplacer la racine et sans demander aux scènes
+de rechercher des services dans l'arbre.
+
+La composition est responsable de :
+
+- construire les adaptateurs d'infrastructure et les cas d'usage ;
+- charger ou créer l'état de campagne ;
+- injecter les contrats requis avant d'activer une scène ;
+- connecter les sorties d'une scène aux commandes applicatives appropriées ;
+- déconnecter et libérer les dépendances de portée courte lors d'une
+  transition ;
+- choisir l'écran suivant à partir d'un résultat applicatif explicite.
+
+Une scène ne parcourt pas ses parents, `/root`, un groupe global ou un chemin
+absolu afin de découvrir une dépendance. Elle expose une méthode de
+configuration, des propriétés typées ou un constructeur de composition
+explicite. L'absence d'une dépendance requise échoue immédiatement en
+développement et dans les tests de chargement.
+
+### Durées de vie
+
+Trois portées sont distinguées :
+
+1. **Application** : réglages, localisation, adaptateurs d'entrée et d'audio,
+   horloge de plateforme, accès au stockage et liste des sauvegardes. Ils vivent
+   tant que la racine existe.
+2. **Campagne** : `CampaignState`, progression de mission et cas d'usage liés à
+   une partie. Ils sont créés lors d'une nouvelle partie ou d'un chargement et
+   détruits lors de sa fermeture ou de son remplacement.
+3. **Plongée** : `ResolvedDiveRules`, `DiveSession`, acteurs, adaptateurs
+   physiques et service sonar courant. Ils sont créés au départ d'une plongée
+   et détruits après production de son résultat immuable.
+
+Un objet de portée longue peut fournir un port à une portée plus courte. Il ne
+conserve pas en retour une référence implicite vers un acteur ou une scène déjà
+détruite. Les connexions de signaux suivent la même propriété et sont retirées
+avec leur portée.
+
+Les services d'infrastructure ne deviennent pas propriétaires des règles. Par
+exemple, le dépôt de sauvegarde écrit un document demandé par un cas d'usage ;
+il ne décide pas quand une mission progresse ou combien d'argent est gagné.
+
+### Navigation et communications
+
+La présentation traduit une interaction en commande ou appel de cas d'usage.
+Elle consomme ensuite un résultat, un snapshot ou un événement typé. Elle ne
+modifie jamais directement l'état de campagne ou un acteur du monde.
+
+Les événements locaux peuvent utiliser les signaux Godot entre objets déjà
+reliés par la composition. Un signal décrit un fait passé et ne sert pas de
+canal global anonyme. Une intention reste une commande nommée.
+
+Chaque écran et composition de plongée peut être instancié dans un test avec de
+faux ports, sans charger une campagne réelle, le stockage de la machine ou tous
+les autres écrans.
+
+### Évolution
+
+Tout nouvel autoload, accès statique global ou exception durable à cette
+politique exige un ADR qui précise son propriétaire, sa durée de vie, son API,
+sa stratégie de réinitialisation et son isolation en test.
+
+## Conséquences
+
+- Les dépendances et leur durée de vie sont visibles à l'endroit où les scènes
+  sont assemblées.
+- Un changement d'écran ne détruit pas les services applicatifs nécessaires à
+  la session.
+- Une nouvelle campagne peut remplacer proprement la précédente sans conserver
+  ses signaux, caches ou acteurs.
+- Les écrans sont testables avec des doubles légers et ne dépendent pas d'un
+  ordre d'initialisation d'autoloads.
+- La composition contient davantage de code d'assemblage explicite et doit
+  rester distincte des règles de gameplay.
+- Les transitions doivent libérer leurs objets de portée courte et seront
+  couvertes par des tests d'intégration et de fuite de nœuds.
+- Les fonctionnalités transversales passent par des ports nommés plutôt que par
+  une commodité globale.
+
+## Alternatives considérées
+
+- **Un autoload par service** : rejeté, car sauvegarde, campagne, audio et
+  navigation deviendraient accessibles et mutables depuis toutes les couches.
+- **Un unique `GameManager` autoload** : rejeté, car il concentrerait
+  assemblage, navigation et règles dans un propriétaire générique.
+- **Un bus d'événements global** : rejeté, car producteurs et consommateurs
+  seraient reliés par des noms implicites et des durées de vie difficiles à
+  vérifier.
+- **Remplacer toute la scène courante à chaque écran** : rejeté comme
+  navigation principale, car les services persistants devraient alors être
+  globaux ou reconstruits avec un état dupliqué.
+- **Rechercher les services dans les parents ou par groupe Godot** : rejeté,
+  car la dépendance resterait cachée et dépendrait de la forme de l'arbre.

docs/adr/0009-player-knowledge-driven-progression.md

@@ -0,0 +1,163 @@
+# 0009 — Progression pilotée par les connaissances et actions du joueur
+
+- Statut : accepté
+- Date : 2026-08-10
+- Remplace : aucun
+
+## Contexte
+
+L'entreprise qui engage le joueur sait qu'elle poursuit un trésor, mais présente
+la première mission comme la récupération du travail du précédent opérateur.
+Le monde possède donc une vérité, le commanditaire possède des intentions et le
+joueur ne dispose au départ que d'une version partielle ou mensongère.
+
+Une épave peut être localisée, identifiée, examinée, ouverte et revisitée sans
+que son objectif principal ait été sécurisé. Débloquer la suite dès la
+découverte du navire rendrait la récupération de l'objet ou de l'indice
+facultative et contredirait la boucle de campagne. À l'inverse, utiliser les
+secrets du contenu pour colorer une icône ou construire un objectif visible
+révélerait indirectement une information que le joueur n'a pas encore obtenue.
+
+## Décision
+
+### Trois niveaux d'information
+
+Le modèle sépare explicitement :
+
+1. **La vérité du contenu** : identité réelle d'une épave, objets présents,
+   chronologie, motivations et liens narratifs. Elle réside dans les définitions
+   de contenu et n'est jamais envoyée telle quelle à la présentation.
+2. **Les termes visibles du contrat** : `ContractTerms` contient uniquement le
+   commanditaire affiché, les informations communiquées au joueur, l'objectif
+   officiel, le paiement et les prérequis annoncés.
+3. **Les connaissances du joueur** : `MissionProgress` contient uniquement les
+   faits observés, révélations acquises, objectifs connus, épaves localisées,
+   identités établies et activités découvertes.
+
+Les intentions cachées de l'entreprise et les véritables étapes de progression
+sont décrites dans des `CampaignObjectiveDefinition` distinctes de
+`ContractTerms`. Une définition peut rester invisible, devenir connue après une
+révélation ou n'exister que comme règle interne reliant des faits.
+
+La sauvegarde persiste les identifiants et états nécessaires à la progression,
+mais l'application expose à chaque écran une projection filtrée par les
+connaissances du joueur. Le fait qu'une donnée existe dans le contenu ou le
+format de sauvegarde ne l'autorise pas à traverser le contrat de présentation.
+
+### Faits, objectifs et révélations
+
+Un fait est un événement métier idempotent déjà établi, par exemple :
+
+- une zone d'écho a été obtenue ;
+- une épave a été localisée ;
+- une preuve a été observée ;
+- une identité a été établie ;
+- un accès a été ouvert ;
+- un objet se trouve sur le site, dans le panier, dans la cale ou a été remis ;
+- des données récupérées ont été analysées.
+
+Une révélation est une nouvelle connaissance produite par une commande validée
+et ses prérequis, pas un texte déclenché par l'interface. Elle peut rendre
+visible un objectif, une activité, une identité ou une nouvelle zone probable.
+
+Un `CampaignObjectiveDefinition` exprime des prérequis typés et un effet. La
+progression les évalue après les commandes applicatives. Elle ne dépend ni de
+la scène ouverte, ni d'un libellé, ni d'une comparaison effectuée dans le HUD.
+Les mêmes faits ne produisent une révélation qu'une seule fois.
+
+Une hypothèse de joueur, telle que la cible présumée dans le dossier, reste
+révisable et n'est pas un fait d'identification. Elle ne valide ni le contrat,
+ni une étape cachée.
+
+### Localisation distincte de l'accomplissement
+
+Localiser ou identifier une épave ne satisfait pas automatiquement l'objectif
+qui y conduit. Chaque étape requiert le dernier fait métier prévu par sa
+définition : récupération, sécurisation dans la cale, analyse, lecture, remise
+ou autre action explicitement nommée.
+
+Pour la première mission de la verticale :
+
+1. le contrat visible demande de retrouver le navire de prospection et son
+   module de cartographie ;
+2. la localisation rend l'épave revisitable, sans révéler la piste suivante ;
+3. l'identification confirme le navire, sans terminer la mission ;
+4. les objets placés dans le panier restent provisoires ;
+5. le treuillage puis `EmptyBasket` sécurisent le module et ses données dans la
+   cale ;
+6. `AnalyzeRecoveredData` révèle la zone probable du U-Boot ;
+7. la remise physique du module et le paiement restent des actions séparées.
+
+La copie analysable des données demeure acquise après son transfert, même si le
+module physique est remis ensuite. Les intentions réelles de l'entreprise ne
+deviennent visibles que par une révélation narrative prévue, pas par le simple
+accomplissement technique d'un objectif caché.
+
+### Projection de la carte
+
+La carte globale reçoit une projection de `MissionProgress` et applique les
+états suivants :
+
+- une vérité de contenu non localisée n'est pas affichée comme épave ;
+- une zone d'écho connue reste une zone approximative ;
+- une épave localisée sans identité établie est nommée
+  `Épave non identifiée` ;
+- une épave identifiée utilise le nom du navire ;
+- l'icône est colorée lorsqu'au moins une activité connue et réalisable reste à
+  accomplir ;
+- l'icône devient monochrome lorsque toutes les activités connues sont
+  terminées et qu'aucun objectif connu n'y demande une action.
+
+Une activité cachée ne colore pas l'icône : cela divulguerait son existence.
+Lorsqu'une révélation la rend connue, la projection peut redevenir colorée.
+Cette couleur est une information de présentation dérivée d'un état métier
+filtré ; elle n'est pas sauvegardée comme vérité indépendante.
+
+### Responsabilités
+
+Le domaine possède faits, prérequis, états d'objets et transitions de
+progression. L'application exécute les commandes, publie les révélations et
+construit les projections autorisées. Le monde produit uniquement des
+observations et interactions. La présentation affiche les projections et émet
+des commandes ; elle ne lit jamais directement les définitions cachées.
+
+Les tests de contenu vérifient au minimum :
+
+- que le contrat visible ne référence pas une révélation prématurée ;
+- que chaque objectif de campagne possède une suite de prérequis atteignable ;
+- que la campagne reste terminable sans le pack d'archives facultatif ;
+- que localiser ou identifier seul la première épave ne révèle pas le U-Boot ;
+- que l'analyse des données sécurisées le révèle une seule fois ;
+- que chaque leurre possède des faits cohérents et une contradiction
+  découvrable ;
+- qu'aucune projection ne contient un fait ou une activité encore caché.
+
+## Conséquences
+
+- L'entreprise peut mentir sans dupliquer une seconde mission ou risquer que
+  l'interface expose son véritable objectif.
+- Une épave découverte reste facile à retrouver, mais sa découverte ne court-
+  circuite pas la récupération et l'analyse.
+- La carte peut revenir sur une épave lorsqu'une nouvelle activité y est
+  révélée, sans modifier son historique d'exploration.
+- Ajouter une révélation exige des prérequis typés et un test de contenu, ce qui
+  augmente le travail d'auteur mais réduit les blocages narratifs.
+- Les écrans reçoivent des projections dédiées plutôt que les ressources de
+  contenu complètes.
+- Les états de couleur et les libellés de carte restent dérivés et ne créent
+  pas une source de vérité concurrente.
+
+## Alternatives considérées
+
+- **Mettre objectifs visibles et cachés dans `ContractTerms`** : rejeté, car un
+  écran ou un export de contrat pourrait révéler les intentions de l'entreprise.
+- **Utiliser des booléens globaux sans propriétaire** : rejeté, car leur origine,
+  leur ordre et leurs prérequis seraient implicites.
+- **Débloquer la suite à l'identification de l'épave** : rejeté, car l'objet ou
+  l'indice demandé deviendrait facultatif.
+- **Laisser l'UI déduire l'objectif suivant** : rejeté, car la présentation
+  calculerait une règle de campagne.
+- **Colorer une épave tant qu'elle contient un secret quelconque** : rejeté,
+  car la carte divulguerait les activités inconnues du joueur.
+- **Valider immédiatement la cible présumée** : rejeté, car l'hypothèse doit
+  rester révisable et la déduction ne doit pas devenir un quiz d'interface.

docs/adr/0010-single-surface-bathymetry-for-v1.md

@@ -0,0 +1,99 @@
+# 0010 — Bathymétrie à surface unique pour la V1
+
+- Statut : accepté
+- Date : 2026-08-10
+- Remplace : aucun
+
+## Contexte
+
+Le sonar retenu représente le fond par une grille bathymétrique continue. Pour
+une ligne et une colonne données, cette structure ne peut stocker qu'une seule
+élévation autoritaire. Elle convient aux pentes, crêtes, chenaux, dépressions et
+reliefs ouverts, mais pas à un tunnel, une arche ou une grotte possédant
+plusieurs surfaces superposées au même emplacement horizontal.
+
+Une représentation hybride pourrait combiner plusieurs couches, fragments de
+maillage, points volumétriques ou voxels locaux. Aucun site de la verticale
+n'exige encore cette complexité : les véritables grottes à plusieurs niveaux et
+les surplombs complexes sont hors périmètre de la V1.
+
+## Décision
+
+Le terrain navigable et les informations critiques du sonar de la V1 utilisent
+une bathymétrie à surface unique. Chaque cellule valide du scan possède au plus
+une hauteur de terrain reconstruite.
+
+Les sites de la verticale sont conçus de sorte que :
+
+- les routes nécessaires puissent être comprises depuis une carte de hauteur ;
+- aucun objectif n'exige de passer sous un surplomb naturel ou dans un tunnel ;
+- aucune preuve indispensable ne soit cachée par une seconde surface au même
+  emplacement horizontal ;
+- une absence de mesure reste inconnue et ne soit pas comblée artificiellement ;
+- les limites de la zone jouable ne soient pas présentées comme un relief à
+  interpréter.
+
+Les épaves, le sous-marin, le navire et les accessoires restent de véritables
+modèles 3D pour le rendu et les collisions. Une épave peut présenter des
+ouvertures, des volumes, des éléments dressés et des zones interactives. Le
+sonar de la V1 n'a toutefois pas à reconstruire précisément son intérieur, son
+dessous ou plusieurs ponts superposés.
+
+Les surfaces anormales et les épaves peuvent être signalées par des
+`SonarContact` distincts et par leur contribution visible à la surface
+extérieure. Une interaction, une observation visuelle ou un indice du dossier
+confirme ensuite leur nature. Le renderer sonar ne fabrique pas un volume
+intérieur pour compenser les limites de la bathymétrie.
+
+Un surplomb purement décoratif reste autorisé s'il n'est ni une route, ni un
+abri nécessaire, ni le support d'une information de mission et si son absence
+ou sa simplification sur le sonar ne trompe pas le joueur. Cette exception est
+vérifiée lors de la revue du site et des tests humains.
+
+Aucune interface générique pour plusieurs couches, aucun voxel local et aucun
+champ de distance ne sont ajoutés préventivement. Le contrat du scan conserve
+les valeurs réelles et les contacts nécessaires, sans prétendre résoudre un
+besoin futur non validé.
+
+### Déclencheur d'une évolution
+
+Un prototype de représentation hybride devient nécessaire seulement lorsqu'un
+site retenu exige au moins l'un des comportements suivants :
+
+- naviguer au-dessus et au-dessous de surfaces superposées ;
+- lire au sonar l'entrée et la continuité d'une grotte ou d'un tunnel ;
+- distinguer plusieurs ponts, plafonds ou niveaux comme information de jeu ;
+- représenter une cible indispensable qu'une carte de hauteur rend ambiguë ou
+  invisible.
+
+Ce prototype comparera au minimum couches bathymétriques locales, fragments de
+maillage et représentation volumétrique bornée. Son adoption, ses données et
+son coût de persistance nécessiteront un nouvel ADR. Elle ne modifiera pas
+silencieusement le contrat de la V1.
+
+## Conséquences
+
+- La reconstruction sonar reste continue, compacte et compatible avec le
+  langage visuel validé par le POC B.
+- Le level design de la verticale doit éviter les configurations que le sonar
+  ne peut pas communiquer honnêtement.
+- Les épaves peuvent conserver une géométrie visuelle riche sans imposer un
+  sonar volumétrique.
+- Certaines formes 3D seront simplifiées ou absentes de la carte sonar ; elles
+  ne peuvent pas porter seules une information critique.
+- Les budgets de la tranche sonar ne comprennent ni voxelisation, ni
+  reconstruction multi-couche, ni navigation dans une grotte.
+- Une future évolution dispose de déclencheurs concrets et devra prouver sa
+  lisibilité avant d'élargir le format de scan.
+
+## Alternatives considérées
+
+- **Construire immédiatement un sonar hybride** : rejeté, car aucun objectif de
+  la verticale ne justifie encore son coût de données, de rendu et de test.
+- **Utiliser des voxels pour tous les sites** : rejeté, car les essais du POC B
+  ont montré une lecture plus confuse que la surface bathymétrique continue.
+- **Aplatir silencieusement une grotte complexe dans la carte** : rejeté, car le
+  sonar donnerait une information trompeuse au joueur.
+- **Interdire toute géométrie 3D complexe aux épaves** : rejeté, car la limite
+  concerne la représentation sonar et le level design critique, pas les modèles
+  visuels ou les collisions locales.

docs/adr/0011-godot-4-7-2-production-baseline.md

@@ -0,0 +1,45 @@
+# 0011 — Godot 4.7.2 comme baseline de production
+
+- Statut : accepté
+- Date : 2026-10-02
+- Remplace : aucun
+
+## Contexte
+
+La verticale de production a démarré sous Godot 4.7.1 et la barrière qualité
+refusait toute autre version. L'environnement de développement disponible
+fournit désormais Godot 4.7.2. Conserver l'exigence exacte 4.7.1 empêche
+d'exécuter la barrière alors que cette mise à jour corrective reste dans la
+même branche 4.7 et ne change ni le renderer Forward+ ni les contrats de jeu.
+
+Les POC A et B restent des références historiques figées sous Godot 4.7.1 et
+GL Compatibility. Leur baseline n'est pas réécrite rétroactivement.
+
+## Décision
+
+Godot 4.7.2 stable devient la version exacte exigée pour le projet de
+production et sa barrière qualité. Les documents de production et le commentaire
+du projet sont alignés sur cette version.
+
+La barrière continue de comparer la version exacte au préfixe officiel attendu.
+Une version antérieure, une version corrective ultérieure ou une préversion est
+refusée jusqu'à une nouvelle décision explicite.
+
+## Conséquences
+
+- La barrière s'exécute avec l'installation Godot 4.7.2 disponible.
+- Les résultats de la verticale sont reproductibles sur une version moteur
+  unique.
+- La mise à jour doit être validée par le chargement de toutes les ressources,
+  les tests unitaires et les tests d'intégration existants.
+- Les baselines des POC continuent de documenter la version 4.7.1 avec laquelle
+  elles ont été validées.
+
+## Alternatives considérées
+
+- **Rester sur Godot 4.7.1** : rejeté, car cette version n'est plus
+  l'installation disponible pour poursuivre la verticale.
+- **Accepter toute version 4.7.x** : rejeté, car une plage implicite rendrait
+  les validations moins reproductibles.
+- **Supprimer le contrôle de version** : rejeté, car il masquerait les mises à
+  jour du moteur au lieu de les valider explicitement.