0.2.0-0-pre.6-fix.1

docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Uroburas — ordre d'implémentation par dépendances
 
@@ -56,6 +56,8 @@ Construire d'abord les mécanismes nécessaires au Mode 1, en conservant les fro
 - Fluent serveur ;
 - Lettre ;
 - maps/assets metadata ;
+- asset delivery auto-hébergé ;
+- HTTP/2 baseline et HTTP/3 si disponible côté asset delivery ;
 - Hall of Fame ;
 - rewarded ad authority ;
 - protocole HTTP sécurisé/versionné.
@@ -75,7 +77,10 @@ Construire d'abord les mécanismes nécessaires au Mode 1, en conservant les fro
 Une fois les moteurs Mode 1 stables :
 
 - server realtime ;
-- tokio-tungstenite ;
+- realtime transport API ;
+- tokio-tungstenite baseline ;
+- WebTransport/QUIC candidat après POC ;
+- fallback transport ;
 - authoritative simulation ;
 - world persistence lifecycle ;
 - bots ;
@@ -105,3 +110,9 @@ L'éditeur de maps peut commencer lorsqu'un format de map suffisamment stable ex
 L'éditeur de skins vient après stabilisation du contrat de skin.
 
 Ni l'un ni l'autre ne doit bloquer le premier gameplay Challenge minimal.
+
+## POC transport avant Mode 3
+
+Avant de figer le transport realtime du Mode 3, un POC dédié doit comparer WebSocket et WebTransport avec la même couche protocolaire.
+
+Le POC mesure la charge et la robustesse ; il ne doit pas forcer la simulation Uroburas à dépendre d'une implémentation réseau particulière.