0.3.5-beta.2

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 36 -->
+<!-- version: 37 -->
 
 # Documentation games.sasedev
 
@@ -12,7 +12,7 @@
 - [`ideas/000-README.md`](ideas/000-README.md) — rôle des idées non engagées et règles de maturation.
 - [`studies/000-README.md`](studies/000-README.md) — rôle des études comparatives non normatives.
 - [`studies/026-V0_3_5_WEBTRANSPORT_QUIC_STACK_AUDIT.md`](studies/026-V0_3_5_WEBTRANSPORT_QUIC_STACK_AUDIT.md) — audit `0.3.5` des stacks WebTransport/QUIC, du contrat transport, de TLS et des plateformes.
-- [`studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md`](studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md) — méthode `0.3.5-alpha.10` de caractérisation loopback WebSocket/WebTransport fiable et datagram séparé.
+- [`studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md`](studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md) — méthode et conclusion consolidée de caractérisation loopback WebSocket/WebTransport fiable, avec datagram séparé.
 
 ## Plans
 
@@ -34,9 +34,9 @@
 - [`architecture/010-RUNTIME_PROVENANCE.md`](architecture/010-RUNTIME_PROVENANCE.md) — provenance plateforme/device/runtime/input pour sessions, scores et analytics.
 - [`architecture/011-POST_0_1_0_DIRECTION.md`](architecture/011-POST_0_1_0_DIRECTION.md) — décisions de transition entre le POC stable 0.1.0 et la conception modulaire 0.2.0.
 - [`architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md`](architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md) — architecture durable kernel/capabilities/game-systems/games/adapters/providers/services/tooling.
-- [`architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md`](architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md) — Web/API, realtime, transports, asset delivery auto-hébergé et frontières serveur.
+- [`architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md`](architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md) — Web/API, baseline WebSocket, second backend WebTransport retenu, asset delivery auto-hébergé et frontières serveur.
 - [`architecture/014-UROBURAS_TARGET_ARCHITECTURE.md`](architecture/014-UROBURAS_TARGET_ARCHITECTURE.md) — ownership cible des besoins Uroburas et ordre Mode 1 → Mode 3 → Mode 2.
-- [`architecture/015-PLATFORM_POC_ARCHITECTURE.md`](architecture/015-PLATFORM_POC_ARCHITECTURE.md) — rôle des POC `0.3.x`, Snake comme sonde et critères d'extraction.
+- [`architecture/015-PLATFORM_POC_ARCHITECTURE.md`](architecture/015-PLATFORM_POC_ARCHITECTURE.md) — rôle des POC `0.3.x`, Snake comme sonde, décisions plateforme/réseau retenues et critères d'extraction.
 - [`architecture/016-V0_2_0_CONSOLIDATED_BASELINE.md`](architecture/016-V0_2_0_CONSOLIDATED_BASELINE.md) — synthèse de la baseline destinée au gel RC `0.2.0`.
 - [`architecture/017-V0_2_0_RC_REVIEW.md`](architecture/017-V0_2_0_RC_REVIEW.md) — checklist de cohérence et scope gelé de la candidate `0.2.0-3-rc.1`.
 

docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Architecture réseau et serveur
 
@@ -21,22 +21,19 @@ Actix Web porte le Web/API, l'authentification, les comptes, Hall of Fame, metad
 
 Le realtime est séparé du Web/API classique.
 
-Baseline :
+Backends retenus :
 
 ```text
-Tokio
-tokio-tungstenite
 WebSocket
-```
+    Tokio + tokio-tungstenite
+    baseline/fallback de référence
 
-Candidat à évaluer :
-
-```text
 WebTransport
-QUIC
+    QUIC + HTTP/3
+    second backend retenu
 ```
 
-La simulation authoritative ne dépend directement d'aucun de ces transports.
+La simulation authoritative ne dépend directement d'aucun de ces transports. WebTransport est retenu à l'issue du POC `0.3.5` pour son chemin fiable natif/navigateur et sa capacité datagram optionnelle, sans remplacer WebSocket ni élargir artificiellement le contrat commun.
 
 ## Frontière de transport
 
@@ -52,7 +49,7 @@ synchronization
 authoritative simulation
 ```
 
-Le client utilise une realtime transport API. WebSocket reste le fallback de référence. WebTransport est évalué lorsqu'il apporte un bénéfice mesuré.
+Le client utilise une realtime transport API fiable/ordonnée commune. WebSocket reste le fallback de référence. WebTransport peut satisfaire cette même frontière via son stream bidirectionnel primaire ; ses datagrams restent backend-spécifiques car leur sémantique non fiable/non ordonnée n’appartient pas à `RealtimeConnection`. Le choix WebTransport-first/fallback WebSocket appartient à la composition ou à un adapter de plateforme, jamais au gameplay.
 
 ## gRPC
 
@@ -83,3 +80,13 @@ L'architecture permet ensuite de séparer Web/API, Assets, Realtime, Database et
 Debian Stable est la cible opérationnelle préférée.
 
 Le choix futur d'un edge/reverse proxy HTTP/3, stockage ou composant d'infrastructure reste reporté aux POC correspondants et doit tenir compte de la disponibilité/maturité sur Debian Stable.
+## Portabilité démontrée par le POC WebTransport 0.3.5
+
+La preuve `0.3.5` couvre :
+
+- Linux natif client/server WebTransport en loopback ;
+- client navigateur/WASM réel contre le serveur Rust natif ;
+- cross-compilation du backend pour Android ARM64 `aarch64-linux-android`, API 21, avec NDK `28.2.13676358`.
+
+La preuve Android est une preuve de compilation et ne vaut pas smoke runtime réseau sur appareil. Les plateformes Apple ne sont pas déclarées validées par cette version. Les résultats de caractérisation loopback sont documentés séparément et ne sont pas extrapolés à Internet/mobile.
+

docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Architecture des POC plateforme et réseau
 
@@ -32,9 +32,9 @@ Cette décision n’interdit pas Tauri Desktop. Le Desktop reste une distributio
 
 ## POC réseau
 
-Avant le Mode 3, comparer au minimum WebSocket/tokio-tungstenite, WebTransport/QUIC, fallback automatique, charge, reconnect/resync, backpressure, snapshots/deltas et mobilité réseau.
+`0.3.4` puis `0.3.5` ont fermé la question du transport de base : WebSocket/tokio-tungstenite reste la baseline/fallback de référence et WebTransport/QUIC est retenu comme second backend. Les deux partagent le contrat fiable/ordonné minimal de `game-realtime-transport-lib`; les datagrams WebTransport restent une capacité backend-spécifique. Le fallback est possédé par la composition, pas par le gameplay.
 
-Le même protocole métier doit pouvoir être exercé sur plusieurs transports.
+Les questions reconnect/resync, snapshots/deltas, mobilité réseau et protocole de session restent des couches supérieures distinctes. Elles ne doivent pas être présentées comme déjà validées par le POC transport `0.3.5`. Le même futur protocole métier doit pouvoir être exercé sur plusieurs transports lorsque cette couche sera réellement introduite.
 
 ## Build
 

docs/plans/005-V0_3_5_WEBTRANSPORT_QUIC_POC_PLAN.md

@@ -1,11 +1,11 @@
 <!-- file: docs/plans/005-V0_3_5_WEBTRANSPORT_QUIC_POC_PLAN.md -->
-<!-- version: 19 -->
+<!-- version: 20 -->
 
 # Plan 0.3.5 — POC WebTransport/QUIC et fallback WebSocket
 
 ## Statut
 
-Plan actif créé pendant `0.3.5-alpha.1` à partir de l'archive taggée `v0.3.4`, puis réconcilié pour l'implémentation native de `0.3.5-alpha.2`, son correctif de validation `0.3.5-alpha.2.fix.1`, le chemin fiable validé de `0.3.5-alpha.3`, la robustesse validée par `0.3.5-alpha.4.fix.1`, le smoke natif validé de `0.3.5-alpha.5`, le chemin client WASM validé de `0.3.5-alpha.6`, le smoke navigateur validé par `0.3.5-alpha.7.fix.2`, la composition/fallback WebSocket validée par `0.3.5-alpha.8.fix.1`, le POC datagram backend-spécifique validé par `0.3.5-alpha.9.fix.1`, puis la caractérisation comparative bornée validée par `0.3.5-alpha.10.fix.1`. `0.3.5-beta.1` a validé le workspace complet, les smokes natifs, les mesures, le build WASM/frontend et le smoke navigateur réel. La preuve Android ARM64 a été bloquée uniquement par l’absence de `aarch64-linux-android-clang` dans l’environnement. La gate a aussi révélé que le `package.json` du host navigateur était resté à `0.3.5-alpha.7.fix.2`; `0.3.5-beta.1.fix.1` corrige cette dérive et ajoute un audit de synchronisation ciblé.
+Plan actif créé pendant `0.3.5-alpha.1` à partir de l'archive taggée `v0.3.4`, puis réconcilié pour l'implémentation native de `0.3.5-alpha.2`, son correctif de validation `0.3.5-alpha.2.fix.1`, le chemin fiable validé de `0.3.5-alpha.3`, la robustesse validée par `0.3.5-alpha.4.fix.1`, le smoke natif validé de `0.3.5-alpha.5`, le chemin client WASM validé de `0.3.5-alpha.6`, le smoke navigateur validé par `0.3.5-alpha.7.fix.2`, la composition/fallback WebSocket validée par `0.3.5-alpha.8.fix.1`, le POC datagram backend-spécifique validé par `0.3.5-alpha.9.fix.1`, puis la caractérisation comparative bornée validée par `0.3.5-alpha.10.fix.1`. `0.3.5-beta.1` a validé le workspace complet, les smokes natifs, les mesures, le build WASM/frontend et le smoke navigateur réel. `0.3.5-beta.1.fix.1` a ensuite fermé la dérive de version du host navigateur, revalidé son build/smoke réel et confirmé la cross-compilation du backend WebTransport pour Android ARM64/API 21 avec le NDK `28.2.13676358`. `0.3.5-beta.2` est désormais la tranche active de consolidation pré-RC et fige la décision **retained** : WebTransport est conservé comme second backend realtime, WebSocket restant la baseline/fallback de référence.
 
 Le cadrage détaillé et la comparaison des stacks actuelles sont conservés dans `docs/studies/026-V0_3_5_WEBTRANSPORT_QUIC_STACK_AUDIT.md`. Le présent document porte les décisions opérationnelles, le scope, les gates et le forecast vivant de la version.
 
@@ -605,27 +605,33 @@ Toute capacité fonctionnelle majeure manquante réouvre une alpha ; un défaut
 
 ### `0.3.5-beta.1.fix.1` — cohérence de version du host navigateur
 
-Correctif fermé de validation :
+Correctif validé :
 
-- synchroniser `Web/game-realtime-webtransport-browser-smoke/package.json` avec la version workspace ;
-- ajouter `DIST-LAYOUT-114` pour empêcher une nouvelle dérive de cette version ;
-- ne modifier aucun backend, protocole, test, mesure ou comportement runtime ;
-- conserver la preuve Android ARM64 comme non validée dans cet environnement tant que le compilateur NDK `aarch64-linux-android-clang` n’est pas disponible.
+- `Web/game-realtime-webtransport-browser-smoke/package.json` synchronisé avec la version workspace ;
+- `DIST-LAYOUT-114` ajouté pour empêcher une nouvelle dérive de cette version ;
+- aucun backend, protocole, test, mesure ou comportement runtime modifié ;
+- build frontend/WASM revalidé avec la version corrigée ;
+- smoke navigateur réel revalidé avec verdict `PASS` ;
+- cross-compilation Android ARM64/API 21 finalement validée après exposition explicite du Clang NDK `aarch64-linux-android21-clang` à `ring`/`cc-rs`.
 
-Après validation de ce fix, enregistrer `history/0.3.5/beta.1.fix.1.md` puis ouvrir `beta.2`.
+La preuve détaillée est conservée dans `history/0.3.5/beta.1.fix.1.md`.
 
 ### `0.3.5-beta.2` — consolidation pré-RC
 
-Tranche explicitement réservée par `SESSION-009` / `VER-PHASE-010` :
+Tranche candidate explicitement réservée par `SESSION-009` / `VER-PHASE-010` :
 
-- réconcilier README/USAGE et docs durables ;
-- figer la conclusion WebTransport ;
-- documenter plateformes réellement validées/non validées ;
-- mettre à jour `CHANGELOG.md` si la transition vers RC est préparée ;
-- réconcilier `ROADMAP.md` seulement si le statut macro change ;
-- écrire le prompt `0.3.6` ;
-- enregistrer l'historique `beta.1` après validation ;
-- aucune nouvelle fonctionnalité majeure.
+- enregistrer `history/0.3.5/beta.1.fix.1.md` avec les validations réellement obtenues ;
+- réconcilier les README/USAGE realtime et les documents d'architecture devenus historiques ;
+- figer la conclusion **retained** : WebTransport reste un second backend, WebSocket la baseline/fallback ;
+- maintenir les datagrams hors de `RealtimeConnection` ;
+- documenter Linux natif et navigateur/WASM comme preuves runtime validées, Android ARM64/API 21 comme cross-compilation validée seulement, et Apple comme non validé ;
+- documenter la procédure Android NDK sans chemin machine absolu ;
+- conserver `CHANGELOG.md` inchangé avant la RC conformément à `PROMPT-STR-012` et aux règles documentaires ;
+- conserver `ROADMAP.md` inchangé tant que `0.3.5` n'est pas stable et que le statut macro ne change pas ;
+- écrire `prompts/007-V0_3_6_START_PROMPT.md` pour la consolidation des POC `0.3.x` et la préparation de la baseline `0.4.x` ;
+- aucune nouvelle fonctionnalité ni modification des backends.
+
+La RC suivante vérifie cette documentation consolidée et porte l'entrée changelog candidate.
 
 ### `0.3.5-rc.1` — candidate gelée
 

docs/studies/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/000-README.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->
 
 # Études
 
@@ -69,4 +69,4 @@ Ces documents étudient les POC à réaliser ; ils ne lancent encore aucune impl
 ## Étude de cadrage 0.3.5
 
 - [`026-V0_3_5_WEBTRANSPORT_QUIC_STACK_AUDIT.md`](026-V0_3_5_WEBTRANSPORT_QUIC_STACK_AUDIT.md) — audit de la stable `0.3.4`, comparaison des stacks WebTransport/QUIC actuelles, compatibilité du contrat realtime, TLS, navigateurs et sizing de `0.3.5`.
-- [`027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md`](027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md) — méthode bornée de mesure loopback WebSocket/WebTransport de `alpha.10`, datagrams séparés et limites d’interprétation.
+- [`027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md`](027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md) — méthode bornée de mesure loopback WebSocket/WebTransport, datagrams séparés, limites d’interprétation et conclusion consolidée `retained` de `0.3.5`.

docs/studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Étude 0.3.5 — caractérisation bornée WebSocket / WebTransport
 
@@ -175,9 +175,9 @@ Les dimensions utiles sont :
 - capacité à soutenir la fenêtre applicative bornée ;
 - observation distincte de la capacité datagram.
 
-## Conclusion technique provisoire
+## Conclusion technique retenue
 
-Décision `alpha.10` : **retain**.
+Décision consolidée pour `0.3.5` : **retained**.
 
 Cela signifie : conserver WebTransport comme second backend realtime expérimental/évolutif à côté de WebSocket. Cette décision repose sur l'ensemble des preuves `0.3.5` déjà acquises :
 
@@ -188,4 +188,6 @@ Cela signifie : conserver WebTransport comme second backend realtime expériment
 - fallback WebSocket strictement classifié ;
 - datagrams optionnels backend-spécifiques.
 
-Cette conclusion **ne signifie pas** que WebTransport est déclaré plus rapide que WebSocket. Les chiffres de `alpha.10` servent à détecter des écarts grossiers et à documenter la baseline locale avant la validation large `beta.1`.
+Cette conclusion **ne signifie pas** que WebTransport est déclaré plus rapide que WebSocket. Les runs `alpha.10.fix.1` et `beta.1` montrent au contraire des avantages différents selon le pattern mesuré : établissement plus coûteux pour WebTransport, RTT local plus faible dans ces runs, throughput 64 KiB supérieur pour WebSocket et fenêtre 1 KiB nettement supérieure pour WebTransport. Ces écarts servent à caractériser les wrappers actuels, pas à produire un classement général.
+
+La validation large a ensuite confirmé le workspace complet, les smokes natifs, le chemin navigateur/WASM réel et la cross-compilation Android ARM64/API 21. Les valeurs exactes des runs validés restent dans `history/0.3.5/alpha.10.fix.1.md` et `history/0.3.5/beta.1.fix.1.md`.