0.3.4-rc.1

CHANGELOG.md

@@ -1,8 +1,19 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 18 -->
+<!-- version: 19 -->
 
 # Changelog
 
+## 0.3.4-rc.1 — 2026-09-21
+
+- gel fonctionnel de la baseline realtime : `game-realtime-transport-lib` porte le contrat binaire transport-neutral et `game-realtime-websocket-lib` son backend Tokio/tokio-tungstenite, sans dépendance transport dans les moteurs ou le gameplay ;
+- client `ws://`, listener serveur, split send/receive, close propre, erreurs transport-neutral, limites de message/frame/write-buffer et deadlines connect/send/close validés sans runtime ni task backend privé ;
+- robustesse validée sur localhost : round-trip binaire, payload hors limite, Text interdit, peer drop abrupt, handshake silencieux borné, mappings capacité/backpressure et smoke runtime public `game-realtime-websocket-smoke: PASS` ;
+- `0.3.4-beta.1` validée avec audits propres, `cargo check`, Clippy strict et `cargo test --workspace --all-targets --all-features` : 53 tests réussis, puis smoke runtime séparé et arbre inverse confirmant que seul le launcher de smoke dépend du backend WebSocket ;
+- consolidation de la documentation durable des deux crates realtime et préparation du prompt `0.3.5` pour évaluer WebTransport/QUIC sur la même frontière, avec WebSocket conservé comme fallback de référence ;
+- aucun TLS direct, protocole de session, synchronisation gameplay, simulation authoritative ou serveur Uroburas n'est introduit dans `0.3.4`.
+
+La RC n'ouvre aucun nouveau scope. Seuls les correctifs nécessaires à la publication selon `VER-RC-*` peuvent produire `0.3.4-rc.1.fix.N`.
+
 ## 0.3.3 — 2026-09-21
 
 - publication stable du pipeline Android SDL3 natif multi-ABI possédé par Gradle/Cargo, sans orchestrateur Python de build ni `src/main/jniLibs` généré dans les sources ;

Cargo.toml

@@ -1,5 +1,5 @@
 # file: Cargo.toml
-# version: 92
+# version: 93
 
 [workspace]
 resolver = "3"
@@ -24,7 +24,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.3.4-beta.1"
+version = "0.3.4-rc.1"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/games"

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 60 -->
+<!-- version: 61 -->
 
 # games.sasedev
 
@@ -27,9 +27,9 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
 
 Version stable de référence : `0.3.3`.
 
-Version candidate active : `0.3.4-beta.1`. `0.3.2` reste différée.
+Version candidate active : `0.3.4-rc.1`. `0.3.2` reste différée.
 
-La stable `0.3.3` livre la voie Android SDL3 native multi-ABI : build Gradle/Cargo sans orchestrateur Python, APK Debug universal et AAB Release pour `arm64-v8a`, `armeabi-v7a`, `x86_64` et `x86`, `minSdk 21` réellement fumé et compatibilité pages mémoire 16 KB validée sur les ABI 64 bits. `0.3.4-alpha.4` a validé la robustesse de la baseline realtime, puis `0.3.4-alpha.5` a fermé la preuve runtime avec un smoke public sur vrai socket loopback, échange bidirectionnel et close propre. `0.3.4-beta.1` n'ajoute aucun scope : elle ouvre la validation large du workspace avant consolidation de publication.
+La stable `0.3.3` livre la voie Android SDL3 native multi-ABI : build Gradle/Cargo sans orchestrateur Python, APK Debug universal et AAB Release pour `arm64-v8a`, `armeabi-v7a`, `x86_64` et `x86`, `minSdk 21` réellement fumé et compatibilité pages mémoire 16 KB validée sur les ABI 64 bits. `0.3.4-beta.1` a validé la baseline realtime sur le workspace complet : contrat transport-neutral, backend WebSocket Tokio/tokio-tungstenite, limites/timeouts, tests loopback et robustesse, smoke runtime public et frontières de dépendances. `0.3.4-rc.1` gèle ce comportement et consolide la documentation de publication sans ouvrir de nouveau scope.
 
 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.
 
@@ -45,4 +45,4 @@ Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-sna
 
 ## Diagnostics et tests
 
-Les socles transverses `crates/common/game-assets-lib` et `crates/common/game-logging-lib` fournissent respectivement la résolution logique des assets et le tracing commun. Les tests unitaires résident hors `src/` sous `unit_tests/`; les tests d’intégration/environnement résident sous `tests/`.
+Les socles transverses `crates/common/game-assets-lib` et `crates/common/game-logging-lib` fournissent respectivement la résolution logique des assets et le tracing commun. Le realtime est séparé entre `game-realtime-transport-lib`, contrat binaire transport-neutral, et `game-realtime-websocket-lib`, backend Tokio/tokio-tungstenite ; leurs responsabilités et leur consommation sont documentées dans leurs README/USAGE locaux. `game-realtime-websocket-smoke` fournit la preuve runtime localhost hors harness de test. Les tests unitaires résident hors `src/` sous `unit_tests/`; les tests d’intégration/environnement résident sous `tests/`.

crates/common/game-realtime-transport-lib/README.md

@@ -0,0 +1,42 @@
+<!-- file: crates/common/game-realtime-transport-lib/README.md -->
+<!-- version: 1 -->
+
+# game-realtime-transport-lib
+
+Contrat realtime transport-neutral de `games.sasedev`. La crate définit uniquement la forme minimale d'une connexion établie, de ses moitiés d'envoi/réception, des payloads binaires opaques et des erreurs stables visibles par les couches supérieures.
+
+## Responsabilité
+
+La crate possède :
+
+- `TransportMessage`, buffer binaire possédé ;
+- `TransportReceive`, qui distingue message reçu et fermeture distante propre ;
+- `RealtimeConnection`, `RealtimeSender` et `RealtimeReceiver` ;
+- `TransportError` et `TransportErrorKind` comme catégories backend-neutral.
+
+Elle ne possède pas :
+
+- l'établissement d'une connexion réseau ;
+- Tokio ou un autre runtime ;
+- WebSocket, WebTransport, QUIC, HTTP ou TLS ;
+- un codec wire ;
+- une session joueur/room ;
+- la synchronisation gameplay ou la simulation authoritative.
+
+## Contrat async
+
+`RealtimeConnection::split()` consomme une connexion établie et retourne des moitiés d'envoi et de réception indépendantes. Les opérations async sont exposées par des futures associées GAT plutôt que par `async-trait` ou `Box<dyn Future>`.
+
+Le contrat n'impose volontairement aucune borne `Send` aux futures. Un backend natif peut fournir des futures `Send`, tandis qu'un futur backend navigateur/WASM ne doit pas être exclu par une contrainte de threading qui ne relève pas de l'abstraction transport.
+
+## Sémantique
+
+Les payloads sont toujours binaires et opaques. Une couche supérieure pourra ultérieurement leur appliquer un codec wire ou un protocole de session sans modifier cette crate.
+
+Une fermeture distante propre est représentée par `TransportReceive::Closed`. Elle n'est pas convertie en erreur I/O générique. Les erreurs utilisent une catégorie stable (`Timeout`, `MessageTooLarge`, `Backpressure`, `Protocol`, etc.) et un détail de diagnostic, sans exposer le type d'erreur du backend concret.
+
+## Dépendances et sens d'ownership
+
+Cette crate ne dépend d'aucun backend realtime. Les implémentations concrètes dépendent d'elle, jamais l'inverse.
+
+Le premier backend de référence est `game-realtime-websocket-lib`. Le POC WebTransport/QUIC prévu ensuite doit d'abord challenger cette même frontière avant toute généralisation supplémentaire.

crates/common/game-realtime-websocket-lib/README.md

@@ -0,0 +1,49 @@
+<!-- file: crates/common/game-realtime-websocket-lib/README.md -->
+<!-- version: 1 -->
+
+# game-realtime-websocket-lib
+
+Backend WebSocket de référence pour le contrat `game-realtime-transport-lib`, fondé sur Tokio et `tokio-tungstenite`.
+
+## Responsabilité
+
+La crate possède :
+
+- connexion client `ws://` ;
+- listener serveur TCP + upgrade WebSocket ;
+- types concrets `WebSocketConnection`, `WebSocketSender` et `WebSocketReceiver` ;
+- mapping WebSocket vers le contrat binaire transport-neutral ;
+- limites de message/frame/write-buffer ;
+- deadlines connect/handshake, send et close ;
+- tracing du domaine `games::realtime::websocket` ;
+- mapping des erreurs Tungstenite vers `TransportErrorKind`.
+
+Elle ne possède pas le runtime Tokio : le consommateur crée et exécute son runtime. La crate ne lance ni runtime global, ni thread runtime privé, ni task backend détachée pour une connexion de base.
+
+## Frontières
+
+Le backend transporte des octets opaques. Il ne connaît ni joueur, ni room, ni tick, ni snapshot, ni codec wire, ni protocole de session.
+
+Les messages Text ne font pas partie du contrat et sont rejetés comme erreur de protocole. Ping/Pong reste un détail WebSocket. Une fermeture distante propre devient `TransportReceive::Closed`.
+
+La baseline active utilise `ws://`. Aucune feature TLS de `tokio-tungstenite` n'est activée ; une politique `wss://` directe n'est pas introduite tant qu'un besoin produit et une stratégie de certificats ne sont pas démontrés.
+
+## Configuration
+
+`WebSocketConfig::default()` fournit des bornes produit explicites :
+
+```text
+message maximum      1 MiB
+frame maximum        1 MiB
+write buffer target  64 KiB
+write buffer maximum 2 MiB
+connect/handshake    10 s
+send                  5 s
+close                 2 s
+```
+
+Les builders `with_*` permettent d'adapter ces limites avant `connect_with_config` ou `WebSocketListener::bind_with_config`. `validate()` refuse les configurations incohérentes avant l'établissement réseau.
+
+## Utilisation
+
+Voir [`USAGE.md`](USAGE.md) pour les points d'entrée client/serveur, la configuration et le smoke de référence.

crates/common/game-realtime-websocket-lib/USAGE.md

@@ -0,0 +1,78 @@
+<!-- file: crates/common/game-realtime-websocket-lib/USAGE.md -->
+<!-- version: 1 -->
+
+# Utilisation — backend realtime WebSocket
+
+## Préconditions
+
+Le consommateur possède le runtime Tokio. `game-realtime-websocket-lib` utilise Tokio pour les sockets et deadlines mais ne crée jamais son propre runtime.
+
+Le contrat transport-neutral est fourni par `game-realtime-transport-lib`. Pour appeler `split`, `send`, `receive` et `close`, importer les traits correspondants dans le module consommateur selon les règles Rust du dépôt.
+
+## Client
+
+Le point d'entrée simple est :
+
+```text
+game_realtime_websocket_lib::connect("ws://host:port/path")
+```
+
+La fonction retourne une `WebSocketConnection`. La connexion est ensuite consommée par `RealtimeConnection::split()` pour obtenir un sender et un receiver indépendants.
+
+Pour une configuration spécifique, construire `WebSocketConfig`, valider ses invariants puis utiliser :
+
+```text
+game_realtime_websocket_lib::connect_with_config(endpoint, config)
+```
+
+## Serveur
+
+Créer d'abord une adresse `SocketAddr`, puis binder :
+
+```text
+WebSocketListener::bind(address)
+```
+
+ou :
+
+```text
+WebSocketListener::bind_with_config(address, config)
+```
+
+`local_addr()` permet de connaître l'adresse réellement allouée, notamment après bind sur `127.0.0.1:0`. `accept().await` attend ensuite un peer TCP et effectue l'upgrade WebSocket dans la deadline configurée.
+
+## Émission et réception
+
+Un message applicatif est encapsulé dans `TransportMessage::new(Vec<u8>)`. Le sender refuse localement un payload dépassant les bornes configurées avant écriture.
+
+`receive()` retourne :
+
+- `TransportReceive::Message` pour un payload binaire ;
+- `TransportReceive::Closed` pour une fermeture distante propre ;
+- `TransportError` pour une erreur réseau/protocole, un timeout ou une limite dépassée.
+
+Une frame Text reçue est une erreur de protocole : elle n'est jamais convertie en bytes métier.
+
+## Fermeture
+
+`RealtimeSender::close()` initie un close WebSocket propre et applique la deadline de fermeture configurée. Une task/future annulée n'est pas assimilée à un close handshake réussi.
+
+## Smoke local
+
+Le launcher de validation public utilise uniquement les API exposées par les deux crates realtime :
+
+```bash
+cargo run -p game-realtime-websocket-smoke
+```
+
+Il bind `127.0.0.1:0`, connecte un client réel, échange un payload binaire dans les deux sens, initie un close propre et doit terminer avec :
+
+```text
+game-realtime-websocket-smoke: PASS
+```
+
+Le smoke ne dépend ni d'Internet, ni d'un port fixe, ni d'un serveur externe.
+
+## Limites intentionnelles
+
+Cette crate n'est pas un protocole multijoueur. Authentification, versionnement wire, session joueur/room, heartbeat métier, resynchronisation, snapshots/deltas et simulation authoritative appartiennent aux couches supérieures et restent hors de son contrat.

deltas/0.3.4/rc.1.md

@@ -0,0 +1,151 @@
+<!-- file: deltas/0.3.4/rc.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.3.4-rc.1
+
+## Base requise
+
+`0.3.4-beta.1`, validée par l'utilisateur le 2026-09-21.
+
+## Objectif
+
+Créer la candidate de publication `0.3.4` après validation large de la baseline realtime, sans rouvrir le comportement réseau.
+
+Cette tranche ferme `VER-PHASE-010` : historique beta, documentation durable, changelog, prompt de la version suivante et gel RC.
+
+## Gel fonctionnel
+
+`0.3.4-rc.1` n'ajoute :
+
+- aucun transport ;
+- aucune API réseau ;
+- aucune dépendance tierce ;
+- aucun TLS ;
+- aucun wire codec ;
+- aucun protocole session/joueur/room ;
+- aucune synchronisation gameplay ;
+- aucune simulation authoritative ;
+- aucun changement moteur, jeu, SDL, Android, Tauri ou WASM.
+
+Les seules modifications techniques sont la promotion de `workspace.package.version` vers `0.3.4-rc.1`. Le code Rust realtime validé en beta reste inchangé.
+
+Tout défaut de publication fermé relève de `0.3.4-rc.1.fix.N` selon `VER-RC-*`. Une réouverture fonctionnelle invalide la RC.
+
+## Validation beta acquise
+
+`history/0.3.4/beta.1.md` consigne la gate réelle :
+
+- audits Rust/workspace, Markdown et distribution propres ;
+- `cargo check --workspace` propre ;
+- Clippy workspace strict propre ;
+- `cargo test --workspace --all-targets --all-features` : 53 tests réussis, 0 échec ;
+- smoke runtime `game-realtime-websocket-smoke: PASS` ;
+- backend sur Tokio `1.53.1`, tokio-tungstenite/Tungstenite `0.30.0`, sans pile TLS ;
+- arbre inverse limité à `game-realtime-websocket-smoke`, sans dépendance backend dans `crates/games/` ou `crates/engines/`.
+
+Aucune beta supplémentaire n'est créée uniquement par cérémonie.
+
+## Consolidation documentaire
+
+La revue `DOC-CRATE-*` conclut :
+
+- `game-realtime-transport-lib` reçoit un `README.md` durable décrivant son contrat, ses frontières et le sens des dépendances ; son API est assez petite pour ne pas justifier un `USAGE.md` séparé ;
+- `game-realtime-websocket-lib` reçoit un `README.md` durable et un `USAGE.md`, car configuration, client/listener, limites, deadlines et smoke constituent un workflow de consommation non trivial ;
+- `game-realtime-websocket-smoke` reste sans document local supplémentaire : la commande Cargo unique, le plan et le delta couvrent entièrement son rôle.
+
+Les documents locaux ne contiennent aucun journal de prerelease.
+
+## Changelog et roadmap
+
+`CHANGELOG.md` reçoit l'entrée `0.3.4-rc.1` avec le scope réellement validé.
+
+`ROADMAP.md` est relue mais reste inchangée : `0.3.4` ne devient `(x)` qu'après validation de la RC et promotion stable. `0.3.5` reste le POC WebTransport/QUIC prévu ensuite.
+
+## Prompt suivant
+
+Ajout de :
+
+```text
+prompts/006-V0_3_5_START_PROMPT.md
+```
+
+Le prompt part de la future stable/taggée `v0.3.4`, rappelle que la RC/stable doit être terminée si nécessaire, et cadre `0.3.5-alpha.1` autour de :
+
+- recherche actuelle des stacks WebTransport/QUIC ;
+- challenge du contrat transport-neutral livré par `0.3.4` ;
+- plateformes navigateur/native/Android réellement testables ;
+- exigences TLS/certificats/HTTP3/UDP ;
+- fallback WebSocket au niveau d'ownership approprié ;
+- comparaison mesurée sans présumer que WebTransport doit être retenu ;
+- maintien hors scope des couches session/synchronisation/simulation.
+
+Le prompt ne présente aucune validation future de la RC ou de la stable comme acquise.
+
+## Fichiers
+
+Modifiés :
+
+```text
+Cargo.toml
+README.md
+CHANGELOG.md
+docs/000-README.md
+docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md
+```
+
+Ajoutés :
+
+```text
+crates/common/game-realtime-transport-lib/README.md
+crates/common/game-realtime-websocket-lib/README.md
+crates/common/game-realtime-websocket-lib/USAGE.md
+history/0.3.4/beta.1.md
+prompts/006-V0_3_5_START_PROMPT.md
+deltas/0.3.4/rc.1.md
+```
+
+## Validation RC
+
+Depuis la racine :
+
+```bash
+cargo fmt --all
+cargo fmt --all -- --check
+
+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 Web deltas history
+python3 scripts/audit_distribution_layout.py
+
+cargo check --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+
+cargo test -p game-realtime-transport-lib --all-targets --all-features
+cargo test -p game-realtime-websocket-lib --all-targets --all-features
+
+cargo run -p game-realtime-websocket-smoke
+cargo tree -i game-realtime-websocket-lib --workspace --edges normal
+```
+
+Le test workspace complet n'est pas répété par cérémonie : aucun Rust, dépendance ou contrat transverse n'a changé depuis la gate beta qui l'a déjà validé. Il redevient obligatoire si un fix RC touche ces éléments.
+
+Le smoke doit afficher :
+
+```text
+game-realtime-websocket-smoke: PASS
+```
+
+L'arbre inverse doit continuer à montrer uniquement le launcher de smoke comme consommateur du backend WebSocket.
+
+## Après validation
+
+Si la RC est propre, la promotion vers `0.3.4` est mécanique :
+
+- `workspace.package.version = 0.3.4` ;
+- ajout de `history/0.3.4/rc.1.md` ;
+- entrée stable dans `CHANGELOG.md` ;
+- `ROADMAP.md` passe `0.3.4` en `(x)` ;
+- clôture du plan `004` et de son index ;
+- ajustement mécanique de `prompts/006-V0_3_5_START_PROMPT.md` si une référence devient certaine ;
+- `deltas/0.3.4/rel.001.md`.
+
+Aucun nouveau comportement ne doit apparaître dans cette promotion.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 32 -->
+<!-- version: 33 -->
 
 # Documentation games.sasedev
 
@@ -82,6 +82,9 @@ Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_DOCUMENTATION.md`](ru
 - [`development/008-WASM_TAURI_POC.md`](development/008-WASM_TAURI_POC.md) — baseline historique Reflex Tauri/WebAssembly et génération WASM associée.
 - [`development/009-SNAKE_WEB_WASM_BUILD.md`](development/009-SNAKE_WEB_WASM_BUILD.md) — build Cargo + `wasm-bindgen` natif de l'adapter Snake pour le navigateur direct.
 - [`development/010-SNAKE_WEB_FRONTEND.md`](development/010-SNAKE_WEB_FRONTEND.md) — host Web direct Snake sous Vite/TypeScript, shell Bootstrap 5, Canvas, lifecycle, assets, provenance et contrôles clavier/tactiles.
+- [`../crates/common/game-realtime-transport-lib/README.md`](../crates/common/game-realtime-transport-lib/README.md) — contrat realtime transport-neutral, payload binaire, split et erreurs stables.
+- [`../crates/common/game-realtime-websocket-lib/README.md`](../crates/common/game-realtime-websocket-lib/README.md) — backend WebSocket Tokio/tokio-tungstenite, frontières et configuration produit.
+- [`../crates/common/game-realtime-websocket-lib/USAGE.md`](../crates/common/game-realtime-websocket-lib/USAGE.md) — connexion client, listener serveur, limites, deadlines et smoke localhost.
 
 ## Historique validé
 

docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md -->
-<!-- version: 7 -->
+<!-- version: 8 -->
 
 # Plan 0.3.4 — transport realtime et baseline WebSocket
 
@@ -7,7 +7,7 @@
 
 Plan actif créé pendant `0.3.4-alpha.1` à partir de l'archive taggée `v0.3.3`.
 
-Les tranches `alpha.1`, `alpha.2`, `alpha.3.fix.1`, `alpha.4` et `alpha.5` ont été validées le 2026-09-21. `alpha.3` avait été rejetée avant compilation à cause d'un héritage Cargo invalide de `default-features`; son fix a ensuite validé le backend WebSocket, le round-trip localhost et le graphe sans TLS. `alpha.4` a fermé les limites, timeouts, cas négatifs et lifecycle. `alpha.5` a ensuite fourni le smoke runtime hors harness de test : bind loopback réel, échange binaire bidirectionnel, close propre et sortie `PASS`. Les critères d'entrée en beta sont donc satisfaits et la tranche active `beta.1` ouvre la validation large sans nouveau scope.
+Les tranches `alpha.1`, `alpha.2`, `alpha.3.fix.1`, `alpha.4`, `alpha.5` et `beta.1` ont été validées le 2026-09-21. `alpha.3` avait été rejetée avant compilation à cause d'un héritage Cargo invalide de `default-features`; son fix a ensuite validé le backend WebSocket, le round-trip localhost et le graphe sans TLS. `alpha.4` a fermé les limites, timeouts, cas négatifs et lifecycle, puis `alpha.5` a fourni le smoke runtime hors harness de test. `beta.1` a enfin validé le workspace complet avec 53 tests, le smoke `PASS` et l'arbre inverse montrant que seul le launcher de smoke consomme le backend. La tranche active est désormais `0.3.4-rc.1` : comportement gelé, consolidation de publication uniquement.
 
 ## Mission
 
@@ -454,9 +454,27 @@ cargo tree -i game-realtime-websocket-lib --workspace --edges normal
 
 Elle revalide également audits, format/check et Clippy. Le test workspace couvre les suites transport/WebSocket et leurs loopbacks ; le smoke reste exécuté séparément car un binaire runtime n'est pas remplacé par le harness `#[test]`. L'arbre inverse doit confirmer qu'aucune crate sous `crates/games/` ou `crates/engines/` ne dépend du backend WebSocket.
 
+`0.3.4-beta.1` a satisfait cette gate le 2026-09-21 : 53 tests workspace réussis, smoke runtime `PASS`, graphe backend sans TLS et arbre inverse limité à `game-realtime-websocket-smoke`. Aucun fix beta n'est requis.
+
 ### RC
 
-La RC gèle le comportement et rejoue les gates de publication utiles. Le test workspace complet n'est répété que si un fix depuis la beta a modifié du Rust, des dépendances ou une frontière transverse qui le justifie.
+La RC gèle le comportement et rejoue les gates de publication utiles. Comme aucun Rust, dépendance tierce ou contrat transport n'a changé depuis la beta, le test workspace complet n'est pas répété par cérémonie. La gate RC retenue est :
+
+```bash
+cargo fmt --all
+cargo fmt --all -- --check
+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 Web deltas history
+python3 scripts/audit_distribution_layout.py
+cargo check --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+cargo test -p game-realtime-transport-lib --all-targets --all-features
+cargo test -p game-realtime-websocket-lib --all-targets --all-features
+cargo run -p game-realtime-websocket-smoke
+cargo tree -i game-realtime-websocket-lib --workspace --edges normal
+```
+
+Le smoke doit encore afficher `game-realtime-websocket-smoke: PASS`. Tout défaut de publication fermé produit `rc.1.fix.N`; toute réouverture fonctionnelle abandonne la RC conformément à `VER-RC-004`.
 
 ## Forecast révisé
 
@@ -526,18 +544,29 @@ Un défaut fermé produit `beta.1.fix.N`. Une capacité manquante réouvre une a
 
 ### `0.3.4-rc.1` — candidate gelée
 
-- scope gelé ;
+- scope fonctionnel gelé après validation complète de `beta.1` ;
-- `CHANGELOG.md` ;
+- entrée RC dans `CHANGELOG.md` ;
-- `ROADMAP.md` si statut macro à réconcilier ;
+- `ROADMAP.md` relue mais conservée non cochée jusqu'à la stable ;
-- historique beta ;
+- historique `beta.1` ;
-- documentation finale ;
+- README durable de `game-realtime-transport-lib` ;
-- prompt `0.3.5` préparant WebTransport/QUIC sur la même frontière ;
+- README + USAGE durables de `game-realtime-websocket-lib` ;
-- aucune abstraction nouvelle sans défaut de release.
+- prompt `0.3.5` préparant le POC WebTransport/QUIC sur la même frontière, sans prétendre qu'un backend ou une stack QUIC est déjà validé ;
+- aucune abstraction nouvelle ni modification du comportement réseau sans défaut de release.
 
 ### `0.3.4` — stable
 
 Promotion mécanique : version stable, historique RC, changelog stable, clôture du plan, delta final et ajustement mécanique du prompt suivant.
 
+## Consolidation documentaire RC
+
+La revue `DOC-CRATE-*` conclut :
+
+- `game-realtime-transport-lib` est une capability durable et réutilisable : un `README.md` local documente responsabilité, frontière, sémantique et sens des dépendances ; son API publique reste suffisamment petite pour ne pas justifier un `USAGE.md` séparé ;
+- `game-realtime-websocket-lib` est un backend durable avec configuration, client, listener et lifecycle opératoire : il reçoit un `README.md` et un `USAGE.md` ;
+- `game-realtime-websocket-smoke` reste un launcher de validation minimal : le plan et la commande Cargo couvrent entièrement son usage, donc aucun document local supplémentaire n'est créé.
+
+Cette documentation est durable et ne contient pas de journal de prerelease. Les détails de validation restent dans `deltas/`, `history/` et `CHANGELOG.md`.
+
 ## Sizing
 
 Le scope reste compatible avec une seule version/session : deux petites crates techniques, un seul backend concret et des tests locaux. Le POC WebTransport/QUIC, la session multijoueur et la simulation authoritative sont explicitement exclus.

history/0.3.4/beta.1.md

@@ -0,0 +1,100 @@
+<!-- file: history/0.3.4/beta.1.md -->
+<!-- version: 1 -->
+
+# Historique 0.3.4-beta.1
+
+## Statut
+
+`0.3.4-beta.1` a été validée par l'utilisateur le 2026-09-21. La gate large est entièrement propre : audits statiques, formatage, check, Clippy strict, test workspace complet, smoke runtime WebSocket et graphes de dépendances.
+
+Aucun `beta.1.fix.N` n'est requis. Le comportement peut être gelé en `0.3.4-rc.1` sans créer de beta supplémentaire artificielle.
+
+## Gates statiques et compilation
+
+La sortie utilisateur confirme :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+games.sasedev workspace audit: clean
+Markdown table audit: clean (5 table(s), 271 file(s))
+Distribution layout audit: clean (50 required path(s), 8 forbidden path(s) absent)
+cargo fmt --all: clean
+cargo fmt --all -- --check: clean
+cargo check --workspace: clean
+cargo clippy --workspace --all-targets --all-features -- -D warnings: clean
+```
+
+Le workspace compile intégralement sous `0.3.4-beta.1`, y compris les deux crates realtime et `game-realtime-websocket-smoke`.
+
+## Test workspace complet
+
+La commande :
+
+```bash
+cargo test --workspace --all-targets --all-features
+```
+
+est propre avec **53 tests réussis, 0 échec** sur l'ensemble des suites exécutées.
+
+La gate couvre notamment :
+
+- `engine-v1-common` : 8 tests ;
+- `engine-v1-platform-api` : 3 tests ;
+- `engine-v1-sdl` : 5 tests ;
+- `game-android-entrypoint` : 2 tests ;
+- `game-assets-lib` : 2 tests ;
+- `game-logging-lib` : 1 test d'intégration ;
+- `game-realtime-transport-lib` : 7 tests ;
+- `game-realtime-websocket-lib` : 5 tests unitaires, 1 loopback et 5 tests de robustesse ;
+- `game-reflex-poc` : 4 tests ;
+- `game-snake-poc` : 5 tests ;
+- `game-snake-poc-wasm` : 5 tests.
+
+Les autres targets bin/lib de runners et hosts concernés s'exécutent également sans échec avec zéro test lorsqu'ils ne possèdent pas de suite propre.
+
+## Smoke runtime
+
+La commande :
+
+```bash
+cargo run -p game-realtime-websocket-smoke
+```
+
+passe hors harness `#[test]` et affiche :
+
+```text
+game-realtime-websocket-smoke: PASS
+```
+
+Le log de validation montre un bind éphémère `127.0.0.1:39077`, une connexion cliente réelle, l'accept serveur et la fermeture propre. Ce numéro de port décrit uniquement cette exécution ; le smoke continue d'utiliser `127.0.0.1:0`.
+
+## Graphe de dépendances
+
+`cargo tree -p game-realtime-websocket-lib --edges normal` confirme le backend attendu :
+
+- `futures-util 0.3.34` ;
+- `game-realtime-transport-lib` ;
+- Tokio `1.53.1` ;
+- `tokio-tungstenite 0.30.0` / Tungstenite `0.30.0` ;
+- tracing.
+
+Aucune pile TLS n'apparaît dans le graphe normal fourni.
+
+L'arbre inverse :
+
+```bash
+cargo tree -i game-realtime-websocket-lib --workspace --edges normal
+```
+
+ne contient qu'un consommateur workspace :
+
+```text
+game-realtime-websocket-smoke
+```
+
+Aucune crate sous `crates/games/` ou `crates/engines/` ne dépend donc du backend WebSocket.
+
+## Conclusion beta
+
+La beta valide la baseline fonctionnelle et ses frontières sans régression transverse. La RC peut se limiter au gel de publication, à la documentation durable, au changelog, à l'historique et à la préparation du prompt `0.3.5`.

prompts/006-V0_3_5_START_PROMPT.md

@@ -0,0 +1,404 @@
+<!-- file: prompts/006-V0_3_5_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage `0.3.5` — POC WebTransport/QUIC et fallback WebSocket
+
+## 1. Base exacte et cible
+
+Partir uniquement de la version stable/taggée :
+
+```text
+v0.3.4
+```
+
+Si ce prompt est lu avant la publication effective de `0.3.4`, terminer d'abord la RC puis la release stable `0.3.4`. Une archive annoncée comme téléchargement ZIP du tag Gitea est autoritaire conformément à `CMD-GIT-003` et `CMD-GIT-004` ; l'absence de `.git` n'est pas un défaut.
+
+Version cible :
+
+```text
+0.3.5
+```
+
+Première tranche attendue :
+
+```text
+0.3.5-alpha.1
+```
+
+`alpha.1` est obligatoirement le gate de cadrage : audit de la stable, recherche des stacks WebTransport/QUIC actuelles, requirements, sizing, risques, matrice plateforme, validations et création du plan actif avant développement lourd.
+
+## 2. Sources de vérité
+
+Lire intégralement, dans cet ordre :
+
+```text
+RULES.md
+ROADMAP.md
+CHANGELOG.md
+docs/000-README.md
+```
+
+Puis au minimum :
+
+```text
+docs/rules/RULES_GENERAL.md
+docs/rules/RULES_RUST.md
+docs/rules/RULES_PROJECT.md
+docs/rules/RULES_DOCUMENTATION.md
+docs/rules/FILE_CONTRACTS.md
+docs/rules/VERSION_WORKFLOW.md
+docs/rules/RULES_COMMANDS.md
+docs/rules/RULES_VALIDATION_MATRIX.md
+docs/rules/RULES_SESSION_PLANNING.md
+docs/rules/PROMPT_STRUCTURE.md
+```
+
+Transmission réseau et plateforme :
+
+```text
+docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md
+docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md
+docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md
+docs/studies/006-REALTIME_MULTIPLAYER_SERVER_STUDY.md
+docs/studies/009-PLATFORM_POC_CANDIDATES.md
+docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md
+docs/studies/012-PLATFORM_POC_SEQUENCE.md
+docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md
+history/0.3.4/
+deltas/0.3.4/
+crates/common/game-realtime-transport-lib/README.md
+crates/common/game-realtime-websocket-lib/README.md
+crates/common/game-realtime-websocket-lib/USAGE.md
+```
+
+Le plan `0.3.4` est historique une fois la stable publiée ; `0.3.5-alpha.1` crée `docs/plans/005-V0_3_5_WEBTRANSPORT_QUIC_POC_PLAN.md`, qui devient alors l'autorité prévisionnelle active.
+
+## 3. État hérité attendu de 0.3.4
+
+La stable `0.3.4` doit laisser une frontière realtime déjà testée :
+
+```text
+transport-neutral contract
+    ↓
+WebSocket backend
+    ↓
+future wire/session layers
+```
+
+État attendu :
+
+- `game-realtime-transport-lib` sans Tokio, WebSocket, QUIC, HTTP ou TLS ;
+- payload binaire opaque `TransportMessage` ;
+- split `RealtimeConnection -> Sender + Receiver` ;
+- fermeture distante propre distinguée des erreurs ;
+- catégories d'erreur transport-neutral ;
+- `game-realtime-websocket-lib` comme backend de référence Tokio/tokio-tungstenite ;
+- client `ws://`, listener serveur, close propre, limites, deadlines et tracing ;
+- aucun runtime Tokio privé ni task backend détachée ;
+- aucun moteur ou gameplay dépendant du backend WebSocket ;
+- `game-realtime-websocket-smoke` comme preuve runtime localhost hors harness `#[test]` ;
+- aucune politique TLS directe, aucun wire codec final, aucune session joueur/room et aucune simulation authoritative.
+
+À la rédaction de ce prompt pendant la RC `0.3.4`, `beta.1` a déjà validé le workspace complet, le smoke et les frontières de dépendances. Ne présenter cependant aucune validation future de `0.3.4-rc.1` ou de la stable comme acquise avant sa sortie réelle.
+
+## 4. Mission 0.3.5
+
+Évaluer puis prototyper **WebTransport/QUIC** comme second transport realtime en conservant WebSocket comme baseline/fallback de référence.
+
+Le résultat recherché n'est pas « remplacer WebSocket parce que QUIC est plus moderne ». `0.3.5` doit répondre avec des preuves :
+
+- un backend WebTransport/QUIC est-il viable sur les plateformes réellement visées ?
+- peut-il consommer la frontière `game-realtime-transport-lib` sans la déformer artificiellement ?
+- quelles différences de sémantique existent entre WebSocket et WebTransport : streams, datagrams, ordering, reliability, fermeture, backpressure ?
+- le bénéfice mesuré justifie-t-il la complexité TLS/HTTP3/QUIC et les contraintes navigateur/infrastructure ?
+- quel fallback WebSocket est réellement nécessaire et à quel niveau doit-il être choisi ?
+
+La frontière conceptuelle reste :
+
+```text
+transport
+    ↓
+wire codec
+    ↓
+session protocol
+    ↓
+synchronization
+    ↓
+authoritative simulation
+```
+
+`0.3.5` reste concentrée sur le transport et la comparaison. Elle ne doit pas profiter du POC QUIC pour concevoir prématurément les couches supérieures.
+
+## 5. Recherche alpha.1 obligatoire
+
+Avant de choisir une crate ou d'écrire un backend, vérifier sur les sources actuelles :
+
+- état et versions des crates Rust candidates WebTransport/QUIC ;
+- maintenance, MSRV, Tokio/runtime, licence et dépendances ;
+- support client et serveur natif ;
+- possibilité réelle côté navigateur/WASM et relation éventuelle avec l'API WebTransport du navigateur ;
+- support Android natif pertinent pour la trajectoire du projet ;
+- exigences TLS/certificats et contraintes de développement localhost ;
+- HTTP/3/QUIC sous-jacent et besoins UDP ;
+- compatibilité Debian Stable pour un serveur auto-hébergé ;
+- interaction avec reverse proxy/edge lorsqu'elle est réellement nécessaire ;
+- support des streams bidirectionnels/unidirectionnels et des datagrams ;
+- comportement de backpressure, limites, fermeture et cancellation ;
+- maturité des APIs de test loopback/local ;
+- disponibilité et stabilité des APIs navigateur sur les cibles réellement testables.
+
+Ne pas figer dans ce prompt un nom de crate WebTransport/QUIC : `alpha.1` doit comparer l'état actuel de l'écosystème au moment du développement.
+
+## 6. Question centrale : compatibilité du contrat 0.3.4
+
+Le contrat `game-realtime-transport-lib` a été volontairement minimal et orienté « messages binaires fiables/ordonnés » parce que WebSocket était le premier backend.
+
+`alpha.1` doit déterminer si :
+
+1. WebTransport peut implémenter ce contrat proprement via un stream fiable sans perte significative ;
+2. les datagrams WebTransport apportent une capability réellement utile qui ne rentre pas dans ce contrat ;
+3. une capability supplémentaire doit être séparée au lieu d'élargir `RealtimeConnection` ;
+4. le POC doit garder deux chemins distincts afin de comparer avant toute extraction commune.
+
+Interdiction de modifier `game-realtime-transport-lib` uniquement pour rendre les APIs WebSocket et QUIC esthétiquement identiques. Toute évolution du contrat commun doit être motivée par au moins deux consommateurs réels et un besoin sémantique partagé.
+
+## 7. Scope inclus
+
+Le scope candidat comprend :
+
+- audit/recherche WebTransport/QUIC ;
+- plan `0.3.5` et matrice de preuves ;
+- second backend transport si la stack retenue est suffisamment viable ;
+- preuve client/serveur locale ou équivalent reproductible ;
+- payload binaire opaque réutilisant le contrat commun lorsque cela est sémantiquement correct ;
+- fermeture/cancellation, limites, timeouts et erreurs du nouveau backend ;
+- tracing séparé ;
+- preuve du fallback WebSocket ou d'un choix de transport au niveau approprié, uniquement si le POC le justifie ;
+- comparaison mesurée WebSocket vs WebTransport/QUIC ;
+- documentation des contraintes plateforme/TLS/infrastructure ;
+- smoke runtime distinct du harness de test si nécessaire pour prouver le nouveau chemin.
+
+## 8. Hors scope
+
+Sauf nécessité strictement démontrée par le POC transport, ne pas introduire :
+
+- Uroburas Mode 3 ;
+- matchmaking ;
+- auth complète ;
+- protocole session joueur/room ;
+- codec wire définitif ;
+- snapshot/delta gameplay ;
+- prediction/reconciliation ou rollback ;
+- simulation authoritative ;
+- persistence gameplay ;
+- Redis/NATS/Kafka ;
+- sharding/regions ;
+- CDN/edge complexe ;
+- orchestration Kubernetes ;
+- remplacement de la stack Web/API Actix ;
+- framework générique multi-transport massif.
+
+## 9. Mesures et comparaison
+
+Le POC doit définir avant mesure les métriques réellement utiles. Candidats :
+
+- temps d'établissement ;
+- latence aller-retour de petits payloads ;
+- débit sur payloads bornés ;
+- overhead observable ;
+- comportement sous plusieurs messages en vol ;
+- coût CPU/mémoire si la mesure est suffisamment reproductible ;
+- différence fiable/ordonnée vs datagram lorsque ce dernier est réellement disponible ;
+- complexité opérationnelle : certificats, UDP, ports, reverse proxy et debugging.
+
+Un benchmark loopback ne suffit pas à conclure sur Internet/mobile. Il sert à vérifier l'implémentation et à comparer des overheads locaux contrôlés. Toute conclusion produit doit distinguer mesure locale, comportement protocolaire connu et test réseau externe réellement effectué.
+
+Les benchmarks doivent rester bornés, reproductibles et ne pas devenir une infrastructure de performance disproportionnée pour un POC.
+
+## 10. Fallback WebSocket
+
+WebSocket reste la baseline fonctionnelle jusqu'à preuve contraire.
+
+Le fallback ne doit pas être codé dans le gameplay. `alpha.1` doit décider l'ownership du choix de transport parmi :
+
+- composition/application ;
+- client/platform adapter ;
+- petit sélecteur technique dédié si deux backends réels le justifient.
+
+Ne pas créer un `TransportManager`, registry dynamique ou système de plugins uniquement pour choisir entre deux transports POC.
+
+## 11. Plateformes à challenger
+
+Le plan `alpha.1` doit expliciter ce qui est réellement testable dans la session :
+
+- Linux natif : client/server local de référence ;
+- navigateur/WASM : important pour WebTransport, mais seulement avec une chaîne de test réaliste ;
+- Android : vérifier la trajectoire et la compatibilité, sans rouvrir le pipeline multi-ABI `0.3.3` si aucun code Android n'est touché ;
+- iOS/macOS : documenter les contraintes connues mais ne pas bloquer la version en l'absence d'environnement Apple.
+
+Une plateforme non testée ne doit pas être présentée comme validée.
+
+## 12. TLS, certificats et sécurité transport
+
+Contrairement à la baseline locale `ws://`, WebTransport navigateur peut imposer des contraintes de sécurité/certificats. `alpha.1` doit vérifier les exigences actuelles au lieu de les supposer.
+
+La version peut introduire uniquement la politique minimale nécessaire au POC. Ne pas transformer `0.3.5` en projet PKI complet. Les certificats de développement, s'ils sont nécessaires, restent hors secrets du dépôt et leur génération/installation doit être documentée de façon reproductible.
+
+Aucune désactivation dangereuse de validation TLS ne devient un chemin produit permanent uniquement pour simplifier un smoke.
+
+## 13. Documentation README/USAGE
+
+Appliquer `DOC-CRATE-*` à tout nouveau composant :
+
+- backend WebTransport/QUIC durable : README probable ;
+- configuration/workflow/certificats non triviaux : USAGE probablement utile ;
+- launcher de benchmark/smoke très petit : documentation locale seulement si le plan central ne couvre pas suffisamment son rôle ;
+- ne jamais créer des fichiers vides ou redondants par cérémonie.
+
+La documentation propre à la fonctionnalité évolue avec la tranche qui l'introduit ; la RC ne doit pas être utilisée pour reporter toute documentation à la fin.
+
+## 14. Validation et responsabilité
+
+Les audits statiques peuvent être exécutés par le générateur. Les builds, tests, benchmarks et smokes finaux restent côté utilisateur conformément à `CMD-BUILD-005` et ne sont jamais déclarés réussis sans sortie réelle.
+
+Dès qu'un fichier Rust ou Cargo change :
+
+```bash
+cargo fmt --all
+cargo fmt --all -- --check
+cargo check --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+```
+
+Les tests restent ciblés pendant l'implémentation. `cargo test --workspace --all-targets --all-features` est réservé aux jalons larges planifiés ou lorsqu'une évolution transverse le justifie.
+
+`cargo tree` est utilisé lorsque les dépendances changent ou lorsqu'une frontière doit être prouvée, pas comme cérémonie à chaque tranche.
+
+Toute commande nécessitant un `cd` doit être englobée dans un sous-shell `(cd ... && ...)`.
+
+## 15. Deltas, history, changelog et roadmap
+
+À partir de `0.3.5`, conserver la nomenclature :
+
+```text
+0.3.5-alpha.N
+0.3.5-alpha.N.fix.M
+0.3.5-beta.N
+0.3.5-beta.N.fix.M
+0.3.5-rc.N
+0.3.5-rc.N.fix.M
+0.3.5
+```
+
+Chaque delta indique sa base, son scope, les fichiers touchés et les validations attendues.
+
+`history/0.3.5/<jalon>.md` est créé uniquement par la tranche suivante ou son fix après validation réelle du jalon précédent.
+
+`CHANGELOG.md` reste normalement silencieux avant la RC. `ROADMAP.md` reste macroscopique et ne change que si le scope, l'ordre ou le statut évolue réellement.
+
+Un échec fermé d'une tranche produit `<jalon>.fix.N`. Une validation propre permet de poursuivre automatiquement vers la tranche planifiée suivante. Une session doit fermer au minimum une version concrète jusqu'à sa stable ; ne pas s'arrêter volontairement sur une prerelease.
+
+## 16. Cadrage alpha.1 obligatoire
+
+Avant développement lourd :
+
+1. auditer la stable `v0.3.4` et vérifier ses gates/historique ;
+2. relire le contrat transport et le backend WebSocket réellement livrés ;
+3. rechercher l'écosystème WebTransport/QUIC actuel ;
+4. établir une matrice plateforme/runtime/TLS ;
+5. comparer les stacks candidates et justifier le choix ;
+6. décider si le contrat transport-neutral reste inchangé ;
+7. décider ownership physique des nouvelles crates/outils ;
+8. définir les preuves locales, navigateur éventuel, benchmarks et smokes ;
+9. définir précisément ce que signifie « fallback WebSocket » dans ce POC ;
+10. créer `docs/plans/005-V0_3_5_WEBTRANSPORT_QUIC_POC_PLAN.md` ;
+11. produire un forecast révisé jusqu'à stable et redécouper la version si le scope excède une session raisonnable.
+
+## 17. Forecast initial non contraignant
+
+Le forecast ci-dessous est une hypothèse de départ. `alpha.1` doit le réviser à partir des résultats réels et le plan actif devient ensuite l'autorité prévisionnelle.
+
+### `0.3.5-alpha.1` — audit WebTransport/QUIC et design du POC
+
+- audit stable `0.3.4` ;
+- recherche des stacks actuelles ;
+- matrice plateforme/TLS/runtime ;
+- challenge du contrat commun ;
+- stratégie fallback ;
+- métriques et gates ;
+- plan actif.
+
+Aucun backend lourd n'est créé avant fermeture de ces décisions.
+
+### `0.3.5-alpha.2` — backend minimal et loopback
+
+Si `alpha.1` confirme la viabilité :
+
+- créer le backend retenu avec dépendances minimales ;
+- établir client/server local ;
+- transporter un payload binaire ;
+- close/cancellation et erreurs de base ;
+- tests loopback déterministes ;
+- tracing dédié.
+
+Si le contrat commun ne convient pas, documenter le besoin avant de le modifier.
+
+### `0.3.5-alpha.3` — plateforme/fallback réel
+
+Selon les résultats :
+
+- preuve navigateur/WASM si elle est techniquement et opérationnellement réalisable ;
+- ou preuve native plus complète si le navigateur exige une infrastructure disproportionnée à cette tranche ;
+- fallback WebSocket au niveau d'ownership retenu ;
+- tests des deux chemins sans couplage au gameplay.
+
+Cette tranche peut être fusionnée ou scindée selon TLS/certificats et tooling réellement nécessaires.
+
+### `0.3.5-alpha.4` — mesures et robustesse conditionnelles
+
+Si nécessaire :
+
+- mesures WebSocket vs WebTransport/QUIC ;
+- streams vs datagrams lorsque réellement supportés ;
+- limites, timeouts, backpressure et peer drop ;
+- smoke runtime/benchmark borné ;
+- décision documentée sur la valeur réelle du second transport.
+
+Ne pas créer cette tranche si `alpha.2/alpha.3` ferment déjà ces preuves proprement.
+
+### `0.3.5-beta.1` — validation large
+
+- workspace complet ;
+- smokes réellement retenus ;
+- graphes de dépendances ;
+- vérification qu'aucun gameplay/engine ne dépend d'un backend concret ;
+- comparaison et limitations documentées.
+
+Un défaut fermé produit `beta.1.fix.N`. Une capacité majeure manquante réouvre une alpha.
+
+### `0.3.5-rc.1` — candidate gelée
+
+- aucun nouveau comportement volontaire ;
+- consolidation durable ;
+- `CHANGELOG.md` ;
+- `ROADMAP.md` si statut macro à réconcilier ;
+- historique beta ;
+- prompt `0.3.6` préparant la consolidation des POC plateforme/réseau ;
+- gates de publication proportionnelles aux changements depuis beta.
+
+### `0.3.5` — stable
+
+Promotion autant que possible mécanique : version stable, historique RC, changelog stable, clôture du plan, roadmap, delta final et ajustement mécanique du prompt `0.3.6`.
+
+## 18. Critère de réussite produit de 0.3.5
+
+La version est réussie même si la conclusion est de **ne pas adopter WebTransport immédiatement**, à condition que le POC fournisse une réponse technique solide et reproductible.
+
+La décision finale doit pouvoir distinguer clairement :
+
+- WebTransport/QUIC retenu comme second backend utile ;
+- viable mais reporté faute de bénéfice suffisant ou de contraintes plateforme/infrastructure ;
+- non viable pour la trajectoire actuelle ;
+- besoin d'une étude complémentaire explicitement reportée.
+
+Le résultat ne doit jamais être forcé pour justifier le temps investi dans le POC.