0.2.0-0-pre.6-fix.1

docs/rules/VERSION_WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/VERSION_WORKFLOW.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Versionnement, maturité et livraisons
 
@@ -104,17 +104,23 @@ La promotion `rc` puis stable d'une version de conception exige une validation h
 
 ## Phases de développement
 
-Une version de code suit conceptuellement :
+Une version suit conceptuellement :
 
 ```text
 PLAN → IMPLEMENT → INTEGRATE → VALIDATE → CANDIDATE → RELEASE
 ```
 
 - **VER-PHASE-001** — Ces phases structurent le travail mais n'imposent pas une prerelease distincte pour chacune.
-- **VER-PHASE-002** — Une petite version peut combiner planification et première implémentation dans `0-pre.1`.
-- **VER-PHASE-003** — Une version lourde peut réserver `0-pre.1` à la planification/décomposition et utiliser plusieurs `pre.N` pour l'implémentation avant alpha/beta.
-- **VER-PHASE-004** — La phase de planification doit identifier le scope, les dépendances, les validations attendues et le découpage de livraison sans dupliquer le contenu normatif de ROADMAP, RULES ou de la matrice de commandes.
-- **VER-PHASE-005** — La phase de validation vérifie l'état effectivement implémenté ; elle ne réécrit pas rétroactivement le plan initial.
+- **VER-PHASE-002** — `0-pre.1` est obligatoirement la tranche de cadrage de la version : audit de la base, brainstorming/recherche de requirements, sizing, planification, dépendances, validations attendues et découpage prévisionnel.
+- **VER-PHASE-003** — `0-pre.1` peut aussi contenir une première implémentation strictement bornée si le cadrage montre qu'elle tient naturellement dans la même tranche, mais le cadrage ne doit jamais être sauté.
+- **VER-PHASE-004** — Une version doit être dimensionnée pour que l'ensemble de son développement puisse être terminé dans une seule session de travail. Si ce n'est pas réaliste, son objectif est découpé en plusieurs versions/sessions avant le développement lourd.
+- **VER-PHASE-005** — Le plan établi en `0-pre.1` est vivant : il peut regrouper, scinder, reporter ou reclasser des tranches lorsque l'information réelle le justifie, sans réécrire les deltas déjà livrés.
+- **VER-PHASE-006** — Une tranche `pre.N`, `alpha.N`, `beta.N`, `rc.N` ou leur fix vise normalement un delta réalisable en environ 15 à 30 minutes. Une tranche sensiblement plus lourde est découpée avant exécution ; une tranche trop petite peut être regroupée avec une tranche adjacente cohérente.
+- **VER-PHASE-007** — Le découpage privilégie des unités fonctionnelles complètes et validables, pas des coupures arbitraires au milieu d'une fonctionnalité.
+- **VER-PHASE-008** — Chaque tranche ferme son propre scope, produit son delta et ses validations proportionnelles avant l'ouverture de la tranche suivante.
+- **VER-PHASE-009** — Alpha, beta et RC sont utilisées proportionnellement au risque et à la maturité ; elles ne sont pas créées uniquement pour satisfaire une séquence cérémonielle.
+- **VER-PHASE-010** — La dernière tranche de développement avant la candidate de publication est réservée à la consolidation : validations finales, documentation durable, `CHANGELOG.md`, `ROADMAP.md`, historique applicable et préparation du prompt de la version/session suivante.
+- **VER-PHASE-011** — La release stable est autant que possible mécanique : elle ne doit pas introduire une nouvelle fonctionnalité, une nouvelle décision architecturale ou un nouveau scope non validé dans une candidate précédente.
 
 ## Versions Tauri/frontend
 

docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Uroburas — classification fonctionnelle par ownership
 
@@ -101,8 +101,12 @@ Le kernel ne connaît pas :
 
 ### Networking client
 
-- HTTPS ;
-- WebSocket ;
+- HTTP(S) client ;
+- realtime transport API ;
+- WebSocket baseline ;
+- WebTransport/QUIC candidate ;
+- transport capability negotiation ;
+- fallback transport ;
 - reconnect ;
 - timeout/backoff ;
 - protocole versionné ;
@@ -110,6 +114,8 @@ Le kernel ne connaît pas :
 - validation des messages ;
 - séparation transport/protocole.
 
+La logique de jeu ne dépend pas directement de `tokio-tungstenite`, Quinn, WebTransport ou d'un type de transport concret.
+
 ### Logging/telemetry
 
 - tracing ;
@@ -261,6 +267,16 @@ Ces concepts restent Uroburas-specific tant qu'un second jeu ne justifie pas leu
 - URLs/download authorization ;
 - publication/modération future.
 
+### Asset delivery
+
+- service auto-hébergé ;
+- HTTP/2 baseline ;
+- HTTP/3/QUIC lorsque disponible ;
+- même hostname H2/H3 de préférence ;
+- cache et distribution multi-nœuds futurs ;
+- séparation logique du Content service ;
+- séparation physique uniquement lorsque la charge le justifie.
+
 ### Hall of Fame
 
 - score submission ;

docs/studies/020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Uroburas — étude de décomposition en crates
 
@@ -31,6 +31,9 @@ crates/capabilities/
     game-input-lib
     game-localization-lib
     game-network-client-lib
+    game-network-realtime-api
+    game-network-websocket-lib
+    game-network-webtransport-lib
     game-persistence-lib
     game-audio-lib
 ```
@@ -143,7 +146,9 @@ Ne contient pas Actix/Tungstenite/Tonic.
 Contrats DTO/protocole :
 
 - HTTP DTOs ;
-- WebSocket messages ;
+- realtime messages indépendants du transport ;
+- WebSocket mapping ;
+- WebTransport mapping futur ;
 - versioning ;
 - validation structurale.
 
@@ -165,7 +170,9 @@ Les wire types restent distincts des modèles métier internes.
 Future Mode 3/2 :
 
 - Tokio ;
-- tokio-tungstenite ;
+- tokio-tungstenite comme baseline WebSocket ;
+- WebTransport/QUIC comme transport candidat ;
+- adaptation transport séparée de la simulation ;
 - rooms/worlds ;
 - authoritative simulation ;
 - snapshots/deltas ;

docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Uroburas — stack serveur de référence
 
@@ -51,19 +51,64 @@ Objectif :
 
 Le JavaScript reste réservé aux interactions qui le nécessitent.
 
+## Asset delivery auto-hébergé
+
+La distribution des maps, skins, sons, sprites, bundles Fluent et autres assets reste auto-hébergée par défaut.
+
+Direction :
+
+```text
+assets.games.sasedev.com
+    HTTP/2
+    HTTP/3/QUIC lorsque disponible
+```
+
+Le même hostname doit de préférence accepter H2 et H3 avec fallback transparent.
+
+La topologie initiale peut rester sur une seule machine, avec séparation logique des hostnames/services. La séparation physique vient ensuite :
+
+```text
+Web/API
+Asset delivery
+Realtime
+Database
+Media/replay
+```
+
+puis plusieurs nœuds/cache d'assets si la charge le justifie.
+
+Aucun CDN tiers n'est une dépendance architecturale obligatoire.
+
 ## Realtime public
 
-Référence :
+Baseline :
 
 ```text
 Tokio + tokio-tungstenite
 ```
 
+Candidat à benchmarker :
+
+```text
+WebTransport / QUIC
+```
+
 Utilisé pour les futurs Modes 3 puis 2.
 
-La logique de gameplay ne dépend pas directement des types Tungstenite.
+La capability client doit exposer les propriétés du transport plutôt que simuler une équivalence artificielle :
 
-Le transport doit rester encapsulé derrière le protocole Uroburas afin qu'un benchmark futur puisse justifier un changement d'implémentation sans réécrire la simulation.
+```text
+reliable ordered
+streams
+datagrams
+connection migration
+```
+
+WebSocket reste le fallback universel lorsque WebTransport n'est pas disponible ou échoue.
+
+La logique de gameplay ne dépend pas directement des types Tungstenite, WebTransport ou QUIC.
+
+Le transport reste encapsulé derrière le protocole Uroburas afin qu'un benchmark futur puisse justifier un changement d'implémentation sans réécrire la simulation.
 
 ## gRPC
 
@@ -85,9 +130,15 @@ gRPC n'est pas obligatoire pour le transport public client/gameplay.
 Le client public utilise en priorité :
 
 ```text
-HTTPS + WebSocket
+HTTPS
++
+WebSocket baseline
++
+WebTransport lorsque disponible et validé
 ```
 
+gRPC n'est pas utilisé comme remplacement obligatoire du transport gameplay public.
+
 ## Localization
 
 Référence :
@@ -167,3 +218,38 @@ Mesures candidates :
 - CPU par tick.
 
 Le choix `tokio-tungstenite` est la référence initiale, pas une affirmation non mesurée de supériorité universelle.
+
+## Frontière transport / protocole
+
+La stack doit distinguer :
+
+```text
+transport
+    ↓
+wire codec
+    ↓
+session protocol
+    ↓
+synchronization
+    ↓
+authoritative simulation
+```
+
+Cette séparation permet de comparer WebSocket et WebTransport sur le même protocole métier.
+
+## POC réseau futur
+
+Avant gel long terme du transport realtime, la série POC doit comparer au minimum :
+
+- WebSocket / tokio-tungstenite ;
+- WebTransport / QUIC ;
+- fallback automatique ;
+- pics de connexions ;
+- mémoire/connexion ;
+- CPU ;
+- p50/p95/p99 ;
+- pertes réseau ;
+- backpressure ;
+- mobilité réseau ;
+- snapshots/deltas ;
+- broadcast/interest management.

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.