0.2.0-0-pre.6-fix.1

Android/game-reflex-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-reflex-poc/build.gradle
-// version: 39
+// version: 40
 
 plugins {
     id 'com.android.application'
@@ -18,7 +18,7 @@ android {
         minSdk 21
         targetSdk 36
         versionCode 2
-        versionName '0.2.0-0-pre.6'
+        versionName '0.2.0-0-pre.6.fix.1'
     }
 
     compileOptions {

Android/game-snake-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-snake-poc/build.gradle
-// version: 39
+// version: 40
 
 plugins {
     id 'com.android.application'
@@ -18,7 +18,7 @@ android {
         minSdk 21
         targetSdk 36
         versionCode 2
-        versionName '0.2.0-0-pre.6'
+        versionName '0.2.0-0-pre.6.fix.1'
     }
 
     compileOptions {

Cargo.toml

@@ -1,5 +1,5 @@
 # file: Cargo.toml
-# version: 51
+# version: 52
 
 [workspace]
 resolver = "3"
@@ -19,7 +19,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.2.0-0-pre.6"
+version = "0.2.0-0-pre.6.fix.1"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/games"

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 19 -->
+<!-- version: 20 -->
 
 # games.sasedev
 
@@ -25,7 +25,7 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
 
 Version stable de référence : `0.1.0`.
 
-Version candidate en cours de conception : `0.2.0-0-pre.6`.
+Version candidate en cours de conception : `0.2.0-0-pre.6.fix.1`.
 
 Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-snake-poc`. Ils existent d'abord pour valider les frontières du workspace, le moteur, les assets et le packaging multiplateforme.
 

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 16 -->
+<!-- version: 17 -->
 
 # Roadmap
 
@@ -30,3 +30,7 @@ Le détail historique des prereleases `0.1.0-*` reste dans `deltas/0.1.0/` et `h
 - ( ) `0.2.0` — établir la matrice plateformes et les archétypes de jeux utilisés pour challenger l'architecture.
 - ( ) `0.2.0` — définir le modèle de composition statique, le manifest produit/jeu et l'architecture cible des crates.
 - ( ) `0.2.0` — définir la trajectoire d'implémentation progressive des versions suivantes seulement après revue de la conception.
+- ( ) `0.2.0` — consolider les études acceptées en architecture/règles durables et fermer les points de classification encore candidats.
+- ( ) `0.2.0` — formaliser la stratégie réseau : Actix Web pour le Web/API, asset delivery auto-hébergé H2/H3, WebSocket baseline et WebTransport/QUIC candidat.
+- ( ) `0.2.0` — préparer une trajectoire `0.3.x` dédiée aux POC plateforme/réseau avec Snake comme jeu-sonde.
+- ( ) `0.2.0` — préparer la trajectoire `0.4.x` Uroburas Mode 1 et le prompt de session associé après gel de la conception.

deltas/0.2.0/0-pre.6.fix.1.md

@@ -0,0 +1,84 @@
+<!-- file: deltas/0.2.0/0-pre.6.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.6.fix.1
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.6`.
+
+Le delta `0-pre.6.md` reste immuable.
+
+## Objet
+
+Compléter la classification de `0-pre.6` avec la stratégie réseau/asset delivery récente et formaliser la discipline de dimensionnement des versions/sessions inspirée du workflow KSP.
+
+## Workflow de version
+
+`0-pre.1` devient obligatoirement la tranche de cadrage :
+
+- audit de la base ;
+- brainstorming/recherche de requirements ;
+- sizing ;
+- planification ;
+- dépendances ;
+- validations ;
+- découpage prévisionnel.
+
+Une version doit être dimensionnée pour être entièrement terminée dans une seule session.
+
+Les tranches `pre/alpha/beta/rc` visent généralement des deltas de 15 à 30 minutes. Une tranche trop lourde est scindée avant exécution ; une tranche trop petite peut être regroupée avec une tranche cohérente.
+
+La dernière tranche avant publication consolide validations, documentation durable, CHANGELOG, ROADMAP et prompt suivant. La release stable reste autant que possible mécanique.
+
+## Réseau et asset delivery
+
+La direction étudiée devient :
+
+- Actix Web pour Web/API ;
+- asset delivery auto-hébergé ;
+- HTTP/2 baseline ;
+- HTTP/3/QUIC pour les assets lorsque disponible ;
+- H2/H3 sur un même hostname de préférence ;
+- séparation logique initiale, séparation physique progressive ;
+- WebSocket/tokio-tungstenite comme baseline realtime ;
+- WebTransport/QUIC comme candidat à benchmarker ;
+- fallback transport ;
+- simulation indépendante du transport ;
+- gRPC/Tonic réservé principalement aux frontières server-to-server justifiées.
+
+## Classification
+
+La capability réseau est décomposée conceptuellement en :
+
+```text
+HTTP client
+realtime transport API
+WebSocket implementation
+WebTransport implementation
+wire protocol
+session protocol
+reconnect/resync
+```
+
+Les crates Uroburas ne dépendent pas directement d'un transport concret.
+
+## Reste de la 0.2.0
+
+Après validation de cette tranche :
+
+1. consolider les études acceptées dans `docs/architecture/` et les règles durables ;
+2. réconcilier ROADMAP et décisions finales ;
+3. produire la tranche de clôture documentaire ;
+4. préparer le prompt de la session `0.3.x` consacrée aux POC ;
+5. passer en RC puis stable sans rouvrir le scope.
+
+## Validation
+
+```bash
+python3 scripts/audit_rust_workspace_rules.py
+python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates Android deltas history
+python3 scripts/audit_distribution_layout.py
+```
+
+Aucune gate Cargo, Gradle ou smoke n'est requise : cette correction reste documentaire.

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-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** — 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-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** — 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-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** — La phase de validation vérifie l'état effectivement implémenté ; elle ne réécrit pas rétroactivement le plan initial.
+- **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 ;
+- HTTP(S) client ;
-- WebSocket ;
+- 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.