0.3.4-alpha.3

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: 2 -->
+<!-- version: 3 -->
 
 # 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`.
 
-La tranche `alpha.1` a été validée le 2026-09-21. La tranche active `alpha.2` matérialise maintenant le contrat transport-neutral sans dépendance runtime/backend ; le backend WebSocket reste réservé à `alpha.3`.
+Les tranches `alpha.1` et `alpha.2` ont été validées le 2026-09-21. La tranche active `alpha.3` ajoute maintenant le backend WebSocket Tokio/tokio-tungstenite derrière le contrat transport-neutral validé ; les limites, timeouts et cas négatifs complets restent réservés à `alpha.4`.
 
 ## Mission
 
@@ -64,7 +64,7 @@ Les anciens labels `0-pre`, `1-alpha`, `2-beta` et `3-rc` restent valides unique
 
 ## Dépendances vérifiées au 2026-09-21
 
-Versions amont observées pour la future implémentation :
+Versions amont retenues et introduites par `alpha.3` :
 
 ```text
 Tokio                1.53.1
@@ -82,7 +82,7 @@ Contraintes utiles :
 - `native-tls` et les variantes `rustls-*` sont optionnelles ;
 - Tungstenite expose déjà des limites de message/frame et de write buffer configurables.
 
-La compatibilité effective de la toolchain utilisateur avec ces MSRV sera attestée par les gates Cargo de la tranche qui introduira réellement les dépendances. Elles ne sont pas ajoutées pendant `alpha.1` : elles seront introduites uniquement avec les crates qui les consomment réellement.
+`alpha.3` centralise désormais ces versions sous `[workspace.dependencies]` et active les features uniquement dans `game-realtime-websocket-lib`. `futures-util` est consommé avec `default-features = false` et seulement `sink + std`; `tokio-tungstenite` est consommé avec `default-features = false` et seulement `connect + handshake`; aucune feature TLS n'est activée. La compatibilité effective de la toolchain utilisateur avec ces MSRV sera attestée par la gate Cargo utilisateur de cette tranche.
 
 ## Ownership physique retenu
 
@@ -284,6 +284,29 @@ Ne pas logguer par défaut le contenu brut des payloads de transport.
 
 Les futurs domaines session/sync/simulation utilisent des targets distinctes.
 
+## Décisions matérialisées dans `alpha.3`
+
+Le backend concret reste sous `crates/common/game-realtime-websocket-lib` et dépend uniquement du contrat commun plus des briques réseau/tracing nécessaires.
+
+L'API publique expose :
+
+```text
+connect(endpoint)
+WebSocketListener::bind(address)
+WebSocketListener::accept()
+WebSocketConnection
+WebSocketSender
+WebSocketReceiver
+```
+
+Les types `WebSocketStream`, `SplitSink`, `SplitStream`, `MaybeTlsStream` et `tungstenite::Error` restent privés. Client et serveur produisent le même `WebSocketConnection` public grâce à une représentation interne à deux variantes ; le contrat commun reste donc la seule frontière partagée par les consommateurs.
+
+`connect()` accepte volontairement uniquement `ws://` dans cette baseline. Le TLS direct reste différé. Les frames binaires deviennent `TransportMessage`; Close devient `TransportReceive::Closed`; Ping/Pong sont traités comme contrôle backend ; Text et raw Frame sont explicitement rejetés comme erreurs de protocole. Les tests négatifs exhaustifs correspondants restent planifiés pour `alpha.4`.
+
+Le backend ne crée aucun runtime, thread ni task détachée. Le harness d'intégration utilise un runtime Tokio de test courant, un bind `127.0.0.1:0` et une borne temporelle uniquement pour empêcher un test loopback défectueux de rester suspendu.
+
+Aucun `README.md`/`USAGE.md` local n'est ajouté pendant `alpha.3` : la crate reste petite, son API publique est documentée par rustdoc et le présent plan porte encore les décisions durables. Ce choix sera réévalué pendant la consolidation finale conformément à `DOC-CRATE-*`.
+
 ## Tests retenus
 
 ### Contrat commun