0.3.5-beta.2
This commit is contained in:
@@ -30,7 +30,7 @@ members = [
|
||||
]
|
||||
|
||||
[workspace.package]
|
||||
version = "0.3.5-beta.1.fix.1"
|
||||
version = "0.3.5-beta.2"
|
||||
edition = "2024"
|
||||
license = "MIT"
|
||||
repository = "https://git.sasedev.com/Sasedev/games"
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 80 -->
|
||||
<!-- version: 81 -->
|
||||
|
||||
# games.sasedev
|
||||
|
||||
@@ -27,9 +27,9 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
|
||||
|
||||
Version stable de référence : `0.3.4`.
|
||||
|
||||
Version active : `0.3.5-beta.1.fix.1`. `0.3.2` reste différée.
|
||||
Version active : `0.3.5-beta.2`. `0.3.2` reste différée.
|
||||
|
||||
La stable `0.3.4` livre la première baseline realtime : contrat binaire transport-neutral, backend WebSocket Tokio/tokio-tungstenite, limites et deadlines, tests loopback/robustesse, smoke runtime localhost public et frontières de dépendances empêchant moteurs et gameplay de dépendre d'un backend concret. `0.3.5-beta.1.fix.1` ferme un défaut de cohérence de version du host navigateur découvert pendant la validation large ; `0.3.5-beta.1` avait ouvert la validation large du POC WebTransport/QUIC après fermeture de toutes les tranches alpha : chemins natif et navigateur, composition WebTransport-first avec fallback WebSocket strictement classifié, datagrams backend-spécifiques et caractérisation loopback bornée. La beta n’ajoute aucune nouvelle capacité ; elle doit confirmer le workspace complet, les smokes retenus, le build navigateur/WASM, la portabilité Android raisonnable et les frontières de dépendances avant consolidation pré-RC. La conclusion technique provisoire reste de conserver WebTransport comme second backend à côté de WebSocket, sans prétendre qu’un résultat loopback prédit les performances Internet/mobile.
|
||||
La stable `0.3.4` livre la première baseline realtime : contrat binaire transport-neutral, backend WebSocket Tokio/tokio-tungstenite, limites et deadlines, tests loopback/robustesse, smoke runtime localhost public et frontières de dépendances empêchant moteurs et gameplay de dépendre d'un backend concret. `0.3.5-beta.2` consolide le résultat du POC WebTransport/QUIC après validation large de `0.3.5-beta.1.fix.1` : chemins natif et navigateur, composition WebTransport-first avec fallback WebSocket strictement classifié, datagrams backend-spécifiques, caractérisation loopback bornée et cross-compilation Android ARM64/API 21. La décision désormais figée pour la RC est de **retenir WebTransport comme second backend realtime** à côté de WebSocket, qui reste la baseline/fallback de référence. Cette décision ne prétend pas qu’un résultat loopback prédit les performances Internet/mobile et ne transforme pas les datagrams en capacité du contrat fiable commun.
|
||||
|
||||
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. Le realtime est séparé entre `game-realtime-transport-lib`, contrat binaire transport-neutral, `game-realtime-websocket-lib`, backend Tokio/tokio-tungstenite, et `game-realtime-webtransport-lib`, backend WebTransport/QUIC candidat dont le chemin natif couvre TLS/pinning, établissement de session et stream fiable principal, tandis que son chemin client WASM compile contre l'API WebTransport du navigateur avec le même framing fiable et le même contrat commun. Leurs responsabilités sont documentées dans leurs README/USAGE locaux lorsqu'un guide d'usage est justifié. `game-realtime-websocket-smoke` et `game-realtime-webtransport-smoke` fournissent les preuves runtime localhost hors harness des deux backends fiables natifs ; `game-realtime-webtransport-browser-smoke` et son host sous `Web/` portent la preuve navigateur WebTransport réelle sans couplage gameplay ; `game-realtime-transport-fallback-smoke` prouve séparément la composition WebTransport-first et le fallback WebSocket classifié sans introduire de manager générique ; `game-realtime-webtransport-datagram-smoke` exerce enfin la capacité datagram WebTransport native sans l'ajouter au contrat fiable 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, `game-realtime-websocket-lib`, backend Tokio/tokio-tungstenite, et `game-realtime-webtransport-lib`, second backend WebTransport/QUIC retenu dont le chemin natif couvre TLS/pinning, établissement de session et stream fiable principal, tandis que son chemin client WASM compile contre l'API WebTransport du navigateur avec le même framing fiable et le même contrat commun. Leurs responsabilités sont documentées dans leurs README/USAGE locaux lorsqu'un guide d'usage est justifié. `game-realtime-websocket-smoke` et `game-realtime-webtransport-smoke` fournissent les preuves runtime localhost hors harness des deux backends fiables natifs ; `game-realtime-webtransport-browser-smoke` et son host sous `Web/` portent la preuve navigateur WebTransport réelle sans couplage gameplay ; `game-realtime-transport-fallback-smoke` prouve séparément la composition WebTransport-first et le fallback WebSocket classifié sans introduire de manager générique ; `game-realtime-webtransport-datagram-smoke` exerce enfin la capacité datagram WebTransport native sans l'ajouter au contrat fiable commun. Les tests unitaires résident hors `src/` sous `unit_tests/`; les tests d’intégration/environnement résident sous `tests/`.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "game-realtime-webtransport-browser-smoke-web",
|
||||
"private": true,
|
||||
"version": "0.3.5-beta.1.fix.1",
|
||||
"version": "0.3.5-beta.2",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"wasm:dev": "cargo build -p game-realtime-webtransport-browser-smoke --lib --target wasm32-unknown-unknown && wasm-bindgen ../../../builds/sasedev-games/target/wasm32-unknown-unknown/debug/game_realtime_webtransport_browser_smoke.wasm --target web --out-dir ../../../builds/sasedev-games/game-realtime-webtransport-browser-smoke/wasm --out-name game_realtime_webtransport_browser_smoke",
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: crates/common/game-realtime-transport-lib/README.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# game-realtime-transport-lib
|
||||
|
||||
@@ -39,4 +39,4 @@ Une fermeture distante propre est représentée par `TransportReceive::Closed`.
|
||||
|
||||
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.
|
||||
Les deux implémentations concrètes retenues à l’issue de `0.3.5` sont `game-realtime-websocket-lib`, baseline/fallback de référence, et `game-realtime-webtransport-lib`, second backend fiable. Les datagrams WebTransport restent volontairement hors de cette crate parce qu’ils ne partagent ni la fiabilité ni l’ordre garantis par `RealtimeConnection`.
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
<!-- file: crates/common/game-realtime-webtransport-lib/README.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# game-realtime-webtransport-lib
|
||||
|
||||
Backend WebTransport/QUIC candidat pour le realtime de `games.sasedev`.
|
||||
Backend WebTransport/QUIC retenu comme second backend realtime de `games.sasedev`, aux côtés de WebSocket qui reste la baseline/fallback de référence.
|
||||
|
||||
## Responsabilité
|
||||
|
||||
@@ -125,8 +125,13 @@ La crate ne possède toujours pas :
|
||||
- d'API datagram transport-neutral ;
|
||||
- de serveur WebTransport WASM ;
|
||||
- de fallback WebSocket dans le backend ;
|
||||
- de benchmark WebSocket/WebTransport.
|
||||
- de sélection dynamique de transport ;
|
||||
- de protocole wire/session ou de synchronisation gameplay.
|
||||
|
||||
Ces responsabilités restent réservées aux tranches suivantes du plan `0.3.5`.
|
||||
Le fallback WebSocket est prouvé au niveau composition par `game-realtime-transport-fallback-smoke`. La caractérisation comparative est portée par `game-realtime-transport-measure` et documentée dans `docs/studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md`; elle ne fait pas partie de la responsabilité de cette crate.
|
||||
|
||||
Le chemin natif s'exécute sous un runtime Tokio fourni par le consommateur ; la crate ne crée ni runtime ni thread privé. Les dépendances navigateur sont target-specific et ne sont donc pas tirées par le backend natif. Réciproquement, `web-transport-quinn`, Tokio et rcgen ne sont pas requis pour construire la crate en `wasm32-unknown-unknown`.
|
||||
|
||||
## Portabilité validée en 0.3.5
|
||||
|
||||
La validation de la version couvre Linux natif client/server, le client navigateur/WASM réel et la cross-compilation du backend pour `aarch64-linux-android` avec API 21. Cette dernière preuve est une preuve de compilation, pas un smoke réseau sur appareil Android. Les plateformes Apple et les autres ABI Android ne sont pas déclarées validées par `0.3.5`.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: crates/common/game-realtime-webtransport-lib/USAGE.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Utilisation de game-realtime-webtransport-lib
|
||||
|
||||
@@ -106,6 +106,27 @@ Le build workspace fournit `web_sys_unstable_apis` uniquement à `wasm32-unknown
|
||||
|
||||
Le host Vite et l'adapter `wasm-bindgen` de `game-realtime-webtransport-browser-smoke` servent uniquement de preuve runtime. Ils ne sont pas nécessaires à un consommateur qui intègre déjà la bibliothèque dans son propre frontend.
|
||||
|
||||
## Cross-compilation Android ARM64
|
||||
|
||||
`0.3.5` a validé la cross-compilation de la crate pour `aarch64-linux-android` avec le NDK `28.2.13676358` et `minSdk`/API 21. Le NDK moderne expose un Clang dont le nom contient le niveau API ; `ring`/`cc-rs` doit recevoir explicitement ce compilateur si le wrapper générique `aarch64-linux-android-clang` n'est pas présent dans le `PATH`.
|
||||
|
||||
Configuration de validation portable à partir du SDK déjà déclaré dans l'environnement :
|
||||
|
||||
```bash
|
||||
ANDROID_SDK="${ANDROID_HOME:-$ANDROID_SDK_ROOT}"
|
||||
export ANDROID_NDK_HOME="$ANDROID_SDK/ndk/28.2.13676358"
|
||||
export TOOLCHAIN="$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64"
|
||||
|
||||
export CC_aarch64_linux_android="$TOOLCHAIN/bin/aarch64-linux-android21-clang"
|
||||
export CXX_aarch64_linux_android="$TOOLCHAIN/bin/aarch64-linux-android21-clang++"
|
||||
export AR_aarch64_linux_android="$TOOLCHAIN/bin/llvm-ar"
|
||||
export CARGO_TARGET_AARCH64_LINUX_ANDROID_LINKER="$TOOLCHAIN/bin/aarch64-linux-android21-clang"
|
||||
|
||||
cargo check -p game-realtime-webtransport-lib --target aarch64-linux-android
|
||||
```
|
||||
|
||||
Ces variables décrivent une commande de cross-compilation et ne doivent pas être remplacées dans le dépôt par un chemin absolu propre à une machine. Cette preuve ne construit pas d'APK/AAB et ne remplace pas un futur smoke WebTransport sur appareil Android si cette cible devient un chemin produit réel.
|
||||
|
||||
## Contrat realtime
|
||||
|
||||
Une fois le stream primaire sélectionné, utiliser les traits de `game-realtime-transport-lib` pour le chemin fiable normal :
|
||||
|
||||
93
deltas/0.3.5/beta.2.md
Normal file
93
deltas/0.3.5/beta.2.md
Normal file
@@ -0,0 +1,93 @@
|
||||
<!-- file: deltas/0.3.5/beta.2.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.3.5-beta.2
|
||||
|
||||
## Base requise
|
||||
|
||||
`0.3.5-beta.1.fix.1` validée.
|
||||
|
||||
## Objet
|
||||
|
||||
Fermer la consolidation pré-RC de `0.3.5` sans nouvelle fonctionnalité. La gate précédente confirme le workspace complet, les smokes realtime, le chemin navigateur/WASM, les mesures, la cohérence du host frontend et la cross-compilation Android ARM64/API 21 du backend WebTransport.
|
||||
|
||||
La version technique devient :
|
||||
|
||||
```text
|
||||
0.3.5-beta.2
|
||||
```
|
||||
|
||||
La décision finale préparée pour la RC est :
|
||||
|
||||
```text
|
||||
WebSocket -> baseline/fallback de référence
|
||||
WebTransport -> second backend realtime retenu
|
||||
Datagrams -> capacité WebTransport backend-spécifique
|
||||
```
|
||||
|
||||
## Modifications
|
||||
|
||||
- enregistrer `history/0.3.5/beta.1.fix.1.md` avec les preuves réellement obtenues ;
|
||||
- synchroniser la version workspace et le host navigateur sur `0.3.5-beta.2` ;
|
||||
- réconcilier `README.md` avec la décision `retained` ;
|
||||
- mettre à jour `game-realtime-transport-lib/README.md` afin qu'il ne présente plus WebTransport comme un POC futur ;
|
||||
- mettre à jour `game-realtime-webtransport-lib/README.md` afin de qualifier le backend comme second backend retenu et d'expliciter les plateformes réellement prouvées ;
|
||||
- documenter dans `game-realtime-webtransport-lib/USAGE.md` la cross-compilation Android ARM64/API 21 avec NDK `28.2.13676358`, sans chemin machine absolu ;
|
||||
- promouvoir la décision réseau dans `docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md` ;
|
||||
- réconcilier `docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md` afin de distinguer transport validé et couches session/synchronisation encore futures ;
|
||||
- figer la conclusion `retained` et ses limites dans l'étude de mesure `027` ;
|
||||
- réconcilier les index documentaires concernés ;
|
||||
- mettre à jour le plan actif `0.3.5` avec la fermeture de `beta.1.fix.1` et le scope exact de `beta.2` ;
|
||||
- créer `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`.
|
||||
|
||||
Aucun fichier Rust, backend, dépendance, protocole, fallback, datagram, engine ou gameplay n'est modifié.
|
||||
|
||||
`CHANGELOG.md` reste volontairement inchangé : l'entrée candidate est réservée à `rc.1`. `ROADMAP.md` reste également inchangé : `0.3.5` n'est pas encore stable et aucun statut macroscopique ne change dans cette tranche.
|
||||
|
||||
## Plateformes consolidées
|
||||
|
||||
La documentation de `beta.2` distingue explicitement :
|
||||
|
||||
```text
|
||||
Linux natif runtime client/server validé
|
||||
Navigateur/WASM client réel validé contre serveur Rust natif
|
||||
Android ARM64 / API 21 cross-compilation validée
|
||||
Android runtime non validé pour WebTransport par 0.3.5
|
||||
Apple non validé par 0.3.5
|
||||
```
|
||||
|
||||
La preuve Android de compilation ne doit pas être transformée en affirmation de compatibilité runtime non testée.
|
||||
|
||||
## Validation attendue
|
||||
|
||||
```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
|
||||
|
||||
(cd Web/game-realtime-webtransport-browser-smoke && npm install && npm run build)
|
||||
```
|
||||
|
||||
Aucun full workspace test n'est répété dans `beta.2` : `beta.1` l'a déjà validé avec 77 tests et cette tranche ne modifie aucun code Rust ou comportement. Le full workspace est réservé de nouveau à `rc.1` conformément au plan.
|
||||
|
||||
## Critères de fermeture
|
||||
|
||||
La tranche est propre si :
|
||||
|
||||
- les audits restent verts ;
|
||||
- Cargo check/Clippy restent sans warning ;
|
||||
- le host navigateur porte bien `0.3.5-beta.2` et son build reste propre ;
|
||||
- aucune documentation durable ne décrit encore WebTransport comme seulement un candidat futur ;
|
||||
- aucune documentation ne prétend que les datagrams satisfont `RealtimeConnection` ;
|
||||
- aucune plateforme non testée n'est présentée comme validée ;
|
||||
- le prompt `0.3.6` part de la future stable/tag `v0.3.5` sans présenter cette publication future comme déjà acquise.
|
||||
|
||||
## Après validation
|
||||
|
||||
Créer `history/0.3.5/beta.2.md`, puis ouvrir `0.3.5-rc.1`. La RC reste fonctionnellement gelée, porte l'entrée `CHANGELOG.md` candidate, revalide le workspace complet et vérifie le prompt `0.3.6` avant promotion stable.
|
||||
@@ -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`.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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`.
|
||||
|
||||
@@ -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`.
|
||||
|
||||
101
history/0.3.5/beta.1.fix.1.md
Normal file
101
history/0.3.5/beta.1.fix.1.md
Normal file
@@ -0,0 +1,101 @@
|
||||
<!-- file: history/0.3.5/beta.1.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Historique 0.3.5-beta.1.fix.1
|
||||
|
||||
## Statut
|
||||
|
||||
`0.3.5-beta.1.fix.1` a été validée par l'utilisateur le 2026-09-22. Le correctif ferme uniquement la dérive de version du host navigateur découverte pendant la gate large `beta.1`; il ne modifie aucun backend, protocole, fallback, datagram ou scénario de mesure.
|
||||
|
||||
La validation cumulée `beta.1` + `beta.1.fix.1` confirme le workspace complet, les smokes realtime natifs, la caractérisation release, le chemin navigateur/WASM réel et la cross-compilation Android ARM64/API 21 du backend WebTransport.
|
||||
|
||||
## Gate large héritée de beta.1
|
||||
|
||||
La gate `beta.1` a confirmé :
|
||||
|
||||
```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), 312 file(s))
|
||||
Distribution layout audit: clean (66 required path(s), 8 forbidden path(s) absent)
|
||||
cargo check --workspace: clean
|
||||
cargo clippy --workspace --all-targets --all-features -- -D warnings: clean
|
||||
cargo test --workspace --all-targets --all-features: 77 passed; 0 failed
|
||||
```
|
||||
|
||||
Les smokes runtime natifs ont tous terminé par `PASS` :
|
||||
|
||||
```text
|
||||
game-realtime-websocket-smoke: PASS
|
||||
game-realtime-webtransport-smoke: PASS
|
||||
game-realtime-webtransport-datagram-smoke: PASS
|
||||
game-realtime-transport-fallback-smoke: PASS
|
||||
```
|
||||
|
||||
Le fallback valide WebTransport en priorité, le passage vers WebSocket sur un `Timeout` classifié et la visibilité d'une erreur `InvalidConfiguration` non éligible au fallback.
|
||||
|
||||
## Mesures beta.1
|
||||
|
||||
La caractérisation release `game-realtime-transport-measure` a terminé par `PASS` avec :
|
||||
|
||||
```text
|
||||
WebSocket establishment median : 42 us
|
||||
WebTransport establishment median : 963 us
|
||||
WebSocket RTT median : 19 us
|
||||
WebTransport RTT median : 12 us
|
||||
WebSocket throughput 128 x 64 KiB : 2933.255 MiB/s
|
||||
WebTransport throughput 128 x 64 KiB : 646.338 MiB/s
|
||||
WebSocket window 64 x 1 KiB : 1.471 MiB/s
|
||||
WebTransport window 64 x 1 KiB : 153.084 MiB/s
|
||||
WebTransport datagram : 64/64 reçus, payload 256 octets, client_max=1381, server_max=1381
|
||||
```
|
||||
|
||||
Ces valeurs décrivent uniquement ce run loopback. Elles ne constituent pas un classement général WebSocket/WebTransport et ne sont pas extrapolées à Internet ou au mobile.
|
||||
|
||||
La conclusion technique reste :
|
||||
|
||||
```text
|
||||
CONCLUSION webtransport=retain scope=second-backend reason=reliable-browser-fallback-datagram-capabilities
|
||||
```
|
||||
|
||||
## WASM et host navigateur
|
||||
|
||||
`beta.1` puis `beta.1.fix.1` ont confirmé :
|
||||
|
||||
- check, Clippy `--lib` et build de `game-realtime-webtransport-lib` pour `wasm32-unknown-unknown` ;
|
||||
- build de `game-realtime-webtransport-browser-smoke` pour WASM ;
|
||||
- génération `wasm-bindgen` ;
|
||||
- TypeScript/Vite propre ;
|
||||
- host npm synchronisé sur `0.3.5-beta.1.fix.1` ;
|
||||
- audit `DIST-LAYOUT-114` empêchant une nouvelle divergence de version ;
|
||||
- smoke navigateur réel terminé par `game-realtime-webtransport-browser-smoke: PASS` côté pair natif.
|
||||
|
||||
Le smoke final a utilisé un endpoint loopback éphémère et un pin SHA-256 généré en mémoire. Les valeurs concrètes de port et de certificat appartiennent uniquement à cette exécution.
|
||||
|
||||
## Android ARM64
|
||||
|
||||
La première tentative `aarch64-linux-android` de `beta.1` a été bloquée avant compilation complète parce que `ring`/`cc-rs` ne trouvait pas le Clang du NDK dans l'environnement.
|
||||
|
||||
Le NDK `28.2.13676358` était déjà installé. Après exposition explicite du toolchain LLVM avec cible API 21 :
|
||||
|
||||
```text
|
||||
CC_aarch64_linux_android=aarch64-linux-android21-clang
|
||||
CXX_aarch64_linux_android=aarch64-linux-android21-clang++
|
||||
AR_aarch64_linux_android=llvm-ar
|
||||
CARGO_TARGET_AARCH64_LINUX_ANDROID_LINKER=aarch64-linux-android21-clang
|
||||
```
|
||||
|
||||
la commande :
|
||||
|
||||
```bash
|
||||
cargo check -p game-realtime-webtransport-lib --target aarch64-linux-android
|
||||
```
|
||||
|
||||
s'est terminée proprement, y compris `ring`, `rustls-platform-verifier-android`, Quinn et `game-realtime-webtransport-lib`.
|
||||
|
||||
Cette preuve valide la **cross-compilation ARM64 Android API 21** du backend. Elle ne vaut pas smoke WebTransport runtime sur appareil Android et ne valide pas les autres ABI Android pour ce backend.
|
||||
|
||||
## Conclusion beta
|
||||
|
||||
La fonctionnalité attendue est complète et la validation large ne révèle plus de défaut fonctionnel. La consolidation `0.3.5-beta.2` peut geler la décision `retained`, réconcilier la documentation durable et préparer le prompt `0.3.6` sans rouvrir le scope transport.
|
||||
403
prompts/007-V0_3_6_START_PROMPT.md
Normal file
403
prompts/007-V0_3_6_START_PROMPT.md
Normal file
@@ -0,0 +1,403 @@
|
||||
<!-- file: prompts/007-V0_3_6_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Prompt de démarrage `0.3.6` — consolidation des POC plateforme/réseau et baseline 0.4.x
|
||||
|
||||
## 1. Base exacte et cible
|
||||
|
||||
Partir uniquement de la version stable/taggée :
|
||||
|
||||
```text
|
||||
v0.3.5
|
||||
```
|
||||
|
||||
Ce prompt est préparé pendant la consolidation `0.3.5-beta.2`. Il doit être vérifié en RC puis ajusté mécaniquement à la stable. Ne pas l'utiliser comme preuve que `v0.3.5` existe avant la publication effective du tag.
|
||||
|
||||
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.6
|
||||
```
|
||||
|
||||
Première tranche attendue :
|
||||
|
||||
```text
|
||||
0.3.6-alpha.1
|
||||
```
|
||||
|
||||
`alpha.1` est obligatoirement le gate de cadrage : audit de la stable `0.3.5`, inventaire des résultats réellement validés de `0.3.0` à `0.3.5`, identification des duplications/abstractions encore injustifiées, sizing, risques, validations et création du plan actif `0.3.6` avant toute consolidation lourde.
|
||||
|
||||
## 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
|
||||
```
|
||||
|
||||
Architecture et résultats POC :
|
||||
|
||||
```text
|
||||
docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md
|
||||
docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md
|
||||
docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md
|
||||
docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md
|
||||
docs/architecture/016-V0_2_0_CONSOLIDATED_BASELINE.md
|
||||
docs/studies/012-PLATFORM_POC_SEQUENCE.md
|
||||
docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md
|
||||
docs/studies/020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md
|
||||
docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md
|
||||
docs/studies/023-V0_3_0_PLATFORM_POC_AUDIT.md
|
||||
docs/studies/024-V0_3_1_TAURI_ANDROID_SNAKE_AUDIT.md
|
||||
docs/studies/025-V0_3_3_ANDROID_NATIVE_MULTI_ABI_AUDIT.md
|
||||
docs/studies/026-V0_3_5_WEBTRANSPORT_QUIC_STACK_AUDIT.md
|
||||
docs/studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md
|
||||
```
|
||||
|
||||
Plans et preuves :
|
||||
|
||||
```text
|
||||
docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md
|
||||
docs/plans/002-V0_3_1_TAURI_ANDROID_SNAKE_PLAN.md
|
||||
docs/plans/003-V0_3_3_ANDROID_NATIVE_MULTI_ABI_PLAN.md
|
||||
docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md
|
||||
docs/plans/005-V0_3_5_WEBTRANSPORT_QUIC_POC_PLAN.md
|
||||
history/0.3.0/
|
||||
history/0.3.1/
|
||||
history/0.3.3/
|
||||
history/0.3.4/
|
||||
history/0.3.5/
|
||||
```
|
||||
|
||||
`0.3.6-alpha.1` crée `docs/plans/006-V0_3_6_POC_CONSOLIDATION_PLAN.md`; ce plan devient ensuite l'autorité prévisionnelle active de la version.
|
||||
|
||||
## 3. État hérité attendu de 0.3.5
|
||||
|
||||
La stable `0.3.5` doit fournir la fin de la vague POC plateforme/réseau sans avoir commencé Uroburas.
|
||||
|
||||
Décisions plateforme attendues :
|
||||
|
||||
- Desktop natif SDL3 comme runner de référence ;
|
||||
- Web direct sous Vite/TypeScript + Rust/WASM validé avec Snake ;
|
||||
- Tauri Android conservé comme POC de référence/comparaison, pas comme voie Android productive par défaut ;
|
||||
- Android productif orienté SDL3 natif + Java/JNI ;
|
||||
- pipeline Android natif multi-ABI piloté par Cargo/Gradle, sans script Python de build ;
|
||||
- `minSdk 21` conservé et compatibilité 16 KB 64 bits déjà prouvée dans `0.3.3` ;
|
||||
- Tauri Desktop `0.3.2` toujours différé tant qu'aucun bénéfice produit/monétisation explicite ne justifie cette distribution.
|
||||
|
||||
Décisions réseau attendues :
|
||||
|
||||
```text
|
||||
game-realtime-transport-lib
|
||||
reliable + ordered binary contract
|
||||
├── game-realtime-websocket-lib
|
||||
│ baseline/fallback
|
||||
└── game-realtime-webtransport-lib
|
||||
retained second backend
|
||||
```
|
||||
|
||||
- WebSocket/Tokio/tokio-tungstenite reste la baseline et le fallback de référence ;
|
||||
- WebTransport/QUIC est retenu comme second backend fiable ;
|
||||
- le client navigateur/WASM WebTransport a été prouvé contre le serveur Rust natif ;
|
||||
- le backend WebTransport cross-compile pour Android ARM64/API 21 ;
|
||||
- cette preuve Android ne vaut pas smoke runtime WebTransport sur appareil ;
|
||||
- les datagrams WebTransport restent backend-spécifiques, non fiables et non ordonnés ;
|
||||
- le fallback WebTransport -> WebSocket appartient à la composition, pas au gameplay ni au backend WebTransport ;
|
||||
- les mesures loopback caractérisent les wrappers mais ne constituent pas un classement général ni une prédiction Internet/mobile.
|
||||
|
||||
Toujours hors de la baseline : codec wire métier final, protocole session joueur/room, reconnect/resync, snapshots/deltas gameplay, prediction/reconciliation, matchmaking et simulation authoritative.
|
||||
|
||||
## 4. Mission 0.3.6
|
||||
|
||||
Réconcilier les POC `0.3.x` en une baseline technique claire et minimale prête à accueillir Uroburas `0.4.x`, sans transformer cette version en développement du jeu lui-même.
|
||||
|
||||
La version doit répondre à quatre questions :
|
||||
|
||||
1. quelles décisions des POC sont désormais des choix durables du projet ?
|
||||
2. quelles crates/apps restent utiles comme composants, références ou outils de validation ?
|
||||
3. quelles abstractions/duplications peuvent réellement être consolidées parce qu'au moins deux consommateurs conservés le justifient ?
|
||||
4. quelle baseline précise doit être transmise à `0.4.x` pour commencer Uroburas Mode 1 sans réouvrir les POC déjà tranchés ?
|
||||
|
||||
La consolidation ne signifie pas « factoriser tout ce qui se ressemble ». Une duplication observée peut rester volontaire lorsque les consumers ont des lifecycles ou plateformes différents.
|
||||
|
||||
## 5. Invariants à préserver
|
||||
|
||||
### Architecture modulaire
|
||||
|
||||
Conserver la séparation :
|
||||
|
||||
```text
|
||||
engine kernel
|
||||
technical capabilities
|
||||
game-systems
|
||||
game-specific
|
||||
platform adapters
|
||||
providers
|
||||
server services
|
||||
tooling
|
||||
```
|
||||
|
||||
Aucune crate Uroburas monolithique n'est introduite dans `0.3.6`.
|
||||
|
||||
### Réseau
|
||||
|
||||
Conserver :
|
||||
|
||||
```text
|
||||
transport
|
||||
↓
|
||||
wire codec
|
||||
↓
|
||||
session protocol
|
||||
↓
|
||||
synchronization
|
||||
↓
|
||||
authoritative simulation
|
||||
```
|
||||
|
||||
`0.3.6` peut documenter ou consolider les frontières déjà prouvées, mais ne doit pas profiter de la consolidation pour implémenter les couches supérieures.
|
||||
|
||||
### Plateformes
|
||||
|
||||
Ne pas rouvrir automatiquement Tauri Desktop, Tauri iOS, Windows/macOS/iOS natifs ou un nouveau host uniquement parce qu'ils figurent dans des études anciennes. Une nouvelle cible demande encore un environnement réel et une question technique ouverte.
|
||||
|
||||
## 6. Scope inclus
|
||||
|
||||
Le scope candidat comprend :
|
||||
|
||||
- audit exhaustif des résultats `0.3.0` à `0.3.5` ;
|
||||
- matrice « retained/reference/deferred/remove » des POC et composants techniques ;
|
||||
- réconciliation de l'architecture durable avec les décisions réellement validées ;
|
||||
- revue des duplications Web/WASM, Android, runners et realtime ;
|
||||
- extraction/factorisation uniquement lorsqu'au moins deux consumers conservés et un besoin partagé réel la justifient ;
|
||||
- suppression d'une abstraction ou d'un artefact POC uniquement lorsque son absence de valeur durable est démontrée et que les preuves/historiques restent conservés ;
|
||||
- clarification des capacités nécessaires avant Uroburas Mode 1 ;
|
||||
- préparation d'une baseline `0.4.x` sans implémenter le gameplay Uroburas ;
|
||||
- documentation des décisions différées et de leurs conditions de réouverture ;
|
||||
- préparation du prompt de la première version `0.4.x` retenue lorsque la cible est suffisamment connue.
|
||||
|
||||
## 7. Hors scope
|
||||
|
||||
Sauf défaut bloquant découvert pendant la consolidation, ne pas introduire :
|
||||
|
||||
- gameplay Uroburas ;
|
||||
- Mode 1, Mode 2 ou Mode 3 jouable ;
|
||||
- simulation authoritative ;
|
||||
- protocole session joueur/room ;
|
||||
- matchmaking ;
|
||||
- auth complète ;
|
||||
- persistence gameplay ;
|
||||
- snapshot/delta définitif ;
|
||||
- prediction/reconciliation/rollback ;
|
||||
- Redis/NATS/Kafka ;
|
||||
- orchestration Kubernetes ;
|
||||
- nouvelle stack Web/API ;
|
||||
- nouveau backend realtime ;
|
||||
- remplacement de WebSocket ou WebTransport ;
|
||||
- nouveau framework générique de plugins/transports ;
|
||||
- nouvelle plateforme non nécessaire à la consolidation.
|
||||
|
||||
## 8. Questions de consolidation obligatoires
|
||||
|
||||
`alpha.1` doit produire une matrice couvrant au minimum :
|
||||
|
||||
- `engine-v1-*` : quelles responsabilités sont réellement stables ?
|
||||
- Snake/Reflex : quels POC restent utiles comme tests de régression ou références ?
|
||||
- Web direct : quelles parties sont réellement réutilisables ?
|
||||
- Tauri Android : référence à conserver telle quelle ou surface à isoler davantage ?
|
||||
- Android SDL3/Java/JNI : quelle baseline productive exacte transmettre à `0.4.x` ?
|
||||
- assets/logging : duplication restante justifiant une extraction ?
|
||||
- realtime : contrat commun, deux backends, fallback et datagrams sont-ils placés au bon niveau ?
|
||||
- tooling/smokes : lesquels doivent rester comme preuves durables ?
|
||||
- documentation : quelles études POC sont historiques et quelles décisions doivent être promues vers architecture/règles ?
|
||||
- `0.3.2` différée : les conditions de réouverture ont-elles changé ?
|
||||
|
||||
Chaque proposition de refactor doit nommer les consumers réels qu'elle sert.
|
||||
|
||||
## 9. Baseline 0.4.x attendue
|
||||
|
||||
La fin de `0.3.6` doit rendre explicite, sans encore l'implémenter :
|
||||
|
||||
- la première version `0.4.x` à ouvrir ;
|
||||
- le mode Uroburas concerné, actuellement Mode 1 Challenge sauf révision justifiée ;
|
||||
- les capabilities techniques déjà disponibles ;
|
||||
- les capabilities manquantes réellement nécessaires à cette première tranche produit ;
|
||||
- l'ownership attendu de ces capabilities ;
|
||||
- les POC conservés comme témoins de non-régression ;
|
||||
- les plateformes réellement visées par la première version produit ;
|
||||
- les points volontairement reportés à Mode 3/Mode 2 ou à une version ultérieure.
|
||||
|
||||
Ne pas réserver de nouvelles possibilités spéculatives « au cas où ».
|
||||
|
||||
## 10. Documentation README/USAGE
|
||||
|
||||
Relire `DOC-CRATE-*` pour chaque composant conservé ou consolidé.
|
||||
|
||||
La consolidation doit corriger les documentations devenues fausses ou historiques, mais ne crée pas de README/USAGE vides par cérémonie.
|
||||
|
||||
Pour chaque crate/app durable :
|
||||
|
||||
- README si responsabilité/frontière/points d'entrée ont une valeur durable ;
|
||||
- USAGE si préconditions/commandes/API sont non triviales ;
|
||||
- simple référence au document central si une documentation locale supplémentaire serait redondante.
|
||||
|
||||
## 11. Validation et responsabilité
|
||||
|
||||
Les audits statiques peuvent être exécutés par le générateur. Les builds, tests 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
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo check --workspace
|
||||
cargo clippy --workspace --all-targets --all-features -- -D warnings
|
||||
```
|
||||
|
||||
Les tests restent ciblés par défaut. `cargo test --workspace --all-targets --all-features` est réservé aux jalons larges prévus dans le plan ou à un changement transverse qui le justifie.
|
||||
|
||||
Toute commande nécessitant un `cd` reste dans un sous-shell `(cd ... && ...)`.
|
||||
|
||||
Ne pas utiliser `npm run build` comme gate manuelle d'une app Tauri : les hooks Tauri possèdent leurs builds frontend. Les hosts Web directs non-Tauri conservent leur workflow Vite/npm propre lorsque la tranche les touche réellement.
|
||||
|
||||
## 12. Deltas, history, changelog et roadmap
|
||||
|
||||
Conserver :
|
||||
|
||||
```text
|
||||
0.3.6-alpha.N
|
||||
0.3.6-alpha.N.fix.M
|
||||
0.3.6-beta.N
|
||||
0.3.6-beta.N.fix.M
|
||||
0.3.6-rc.N
|
||||
0.3.6-rc.N.fix.M
|
||||
0.3.6
|
||||
```
|
||||
|
||||
Chaque delta indique sa base, son scope, ses fichiers et ses validations attendues.
|
||||
|
||||
`history/0.3.6/<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 ; le plan `0.3.6` porte le découpage fin.
|
||||
|
||||
Un défaut fermé produit `.fix.N`. Une validation propre permet de poursuivre vers la tranche planifiée suivante. La session doit fermer au minimum `0.3.6` jusqu'à sa stable.
|
||||
|
||||
## 13. Cadrage alpha.1 obligatoire
|
||||
|
||||
Avant tout refactor ou suppression :
|
||||
|
||||
1. auditer la stable `v0.3.5` et ses historiques ;
|
||||
2. inventorier les composants introduits/conservés dans `0.3.0` à `0.3.5` ;
|
||||
3. produire une matrice retained/reference/deferred/remove avec justification ;
|
||||
4. inventorier les duplications observées et les consumers concernés ;
|
||||
5. vérifier les frontières des dépendances actuelles avec `cargo tree` seulement là où cela éclaire une décision ;
|
||||
6. identifier les documents d'architecture à promouvoir/réconcilier ;
|
||||
7. établir la baseline `0.4.x` attendue ;
|
||||
8. définir les gates proportionnelles à chaque consolidation ;
|
||||
9. créer `docs/plans/006-V0_3_6_POC_CONSOLIDATION_PLAN.md` ;
|
||||
10. produire un forecast souple jusqu'à la stable et redécouper avant tout delta trop lourd.
|
||||
|
||||
Aucune suppression ou factorisation transverse n'est autorisée avant cette matrice.
|
||||
|
||||
## 14. Forecast initial non contraignant
|
||||
|
||||
Le plan `alpha.1` peut fusionner, scinder ou supprimer ces tranches selon l'audit réel.
|
||||
|
||||
### `0.3.6-alpha.1` — audit global et plan de consolidation
|
||||
|
||||
- audit stable `0.3.5` ;
|
||||
- matrice des POC/composants ;
|
||||
- duplications et abstractions à challenger ;
|
||||
- baseline `0.4.x` candidate ;
|
||||
- plan actif et validations.
|
||||
|
||||
### `0.3.6-alpha.2` — consolidation plateforme/documentation
|
||||
|
||||
Si justifié par `alpha.1` :
|
||||
|
||||
- réconcilier Web direct, Tauri de référence, SDL Desktop et Android productif ;
|
||||
- promouvoir les décisions plateforme vers architecture durable ;
|
||||
- retirer uniquement les généralisations réellement inutiles ;
|
||||
- conserver les POC nécessaires comme témoins.
|
||||
|
||||
### `0.3.6-alpha.3` — consolidation réseau/capabilities
|
||||
|
||||
Si nécessaire :
|
||||
|
||||
- réconcilier les décisions WebSocket/WebTransport dans l'architecture durable ;
|
||||
- vérifier les frontières backend/contrat/composition ;
|
||||
- supprimer ou déplacer uniquement une abstraction dont le mauvais ownership est démontré ;
|
||||
- ne pas implémenter wire/session/synchronization.
|
||||
|
||||
Cette tranche peut disparaître si `0.3.5` laisse déjà la documentation et l'ownership suffisamment consolidés.
|
||||
|
||||
### `0.3.6-alpha.4` — baseline 0.4.x
|
||||
|
||||
Si un delta séparé reste justifié :
|
||||
|
||||
- synthèse technique prête pour Uroburas ;
|
||||
- capabilities disponibles/manquantes ;
|
||||
- ownership initial ;
|
||||
- plateformes produit candidates réellement justifiées ;
|
||||
- aucune fonctionnalité Uroburas jouable.
|
||||
|
||||
### `0.3.6-beta.1` — validation large
|
||||
|
||||
- workspace complet si du code/build a été consolidé ;
|
||||
- smokes représentatifs des chemins conservés ;
|
||||
- graphes de dépendances pour les frontières modifiées ;
|
||||
- vérification que les POC conservés restent fonctionnels.
|
||||
|
||||
### `0.3.6-beta.2` — consolidation finale pré-RC
|
||||
|
||||
- documentation durable ;
|
||||
- `CHANGELOG.md` seulement selon les règles de transition vers RC ;
|
||||
- `ROADMAP.md` si le statut macro change ;
|
||||
- historique beta ;
|
||||
- prompt de la première version `0.4.x` si la cible est figée.
|
||||
|
||||
### `0.3.6-rc.1` — candidate gelée
|
||||
|
||||
- aucun nouveau scope ;
|
||||
- gate RC proportionnelle à la consolidation réellement effectuée ;
|
||||
- vérification du prompt `0.4.x` ;
|
||||
- corrections uniquement selon `VER-RC-*`.
|
||||
|
||||
### `0.3.6` — stable
|
||||
|
||||
Promotion mécanique autant que possible : version stable, historique RC, changelog stable, clôture du plan, roadmap, delta final et ajustement mécanique du prompt `0.4.x`.
|
||||
|
||||
## 15. Critère de réussite de 0.3.6
|
||||
|
||||
La version est réussie si `0.4.x` peut commencer sans ambiguïté sur :
|
||||
|
||||
- les plateformes réellement retenues ;
|
||||
- les POC conservés comme références ;
|
||||
- les transports realtime et leur ownership ;
|
||||
- les abstractions réellement justifiées ;
|
||||
- les capabilities déjà disponibles ;
|
||||
- les capabilities manquantes à développer avec le premier jeu réel ;
|
||||
- les décisions différées et leurs conditions de réouverture.
|
||||
|
||||
Le succès n'exige pas une factorisation maximale. Une baseline plus petite, explicite et prouvée est préférable à un framework général construit à partir d'hypothèses.
|
||||
Reference in New Issue
Block a user