0.2.0-0-pre.2-fix.1

docs/studies/003-PLATFORM_CAPABILITY_STUDY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/003-PLATFORM_CAPABILITY_STUDY.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Étude plateforme et disponibilité des capacités
 
@@ -55,7 +55,7 @@ Le backend n'est pas l'identité du jeu.
 ## Cibles connues
 
 | Cible | OS/environnement | Device | Execution | Host | Backend principal |
-| --- | --- | --- | --- | --- | --- |
+| :--- | :--- | :--- | :--- | :--- | :--- |
 | Desktop SDL Linux | Linux | Desktop | Native | Native | SDL3 |
 | Desktop SDL Windows | Windows | Desktop | Native | Native | SDL3 |
 | Desktop SDL macOS | macOS | Desktop | Native | Native | SDL3, réservé |
@@ -117,6 +117,19 @@ HTTP/WebSocket sont plausibles sur toutes les grandes cibles mais leur implémen
 
 Le protocole métier reste indépendant du transport.
 
+Pour le multijoueur temps réel, le support d'un WebSocket côté plateforme ne suffit pas à définir la synchronisation. Le client doit pouvoir se connecter à une session distante qui possède ses propres contrats de tick, sequencing, snapshots/deltas, reconnexion et resynchronisation.
+
+Les contraintes navigateur/mobile/desktop peuvent modifier :
+
+- la durée de vie d'une connexion ;
+- la suspension en arrière-plan ;
+- les timeouts ;
+- les politiques de reconnexion ;
+- la disponibilité de threads/timers ;
+- les stratégies de buffering.
+
+Ces différences appartiennent aux adapters/runtime et ne doivent pas modifier le protocole de gameplay lui-même.
+
 ## Politique de disponibilité candidate
 
 Une capability produit peut être :