# Prompt de démarrage `0.3.4` — transport realtime et baseline WebSocket ## 1. Base exacte et cible Partir uniquement de la version stable/taggée : ```text v0.3.3 ``` Si ce prompt est lu avant la publication effective de `0.3.3`, terminer d'abord la RC puis la release stable `0.3.3`. Version cible active : ```text 0.3.4 ``` Première tranche attendue après migration de gouvernance : ```text 0.3.4-alpha.1 ``` `alpha.1` remplace à partir de cette session l'ancien rôle obligatoire de `0-pre.1` : audit, requirements, sizing, risques, validation et création/révision du plan actif avant développement lourd. ## 2. Migration de nomenclature — première action de la session La décision est acquise depuis la fin de `0.3.3`. La nouvelle convention canonique devient : ```text X.Y.Z-alpha.N X.Y.Z-alpha.N.fix.M X.Y.Z-beta.N X.Y.Z-beta.N.fix.M X.Y.Z-rc.N X.Y.Z-rc.N.fix.M X.Y.Z ``` Supprimer pour les **nouvelles versions** les préfixes numériques historiques `0-`, `1-`, `2-`, `3-` ainsi que la phase `pre`. `alpha.1` porte désormais le cadrage obligatoire. Avant de créer le premier delta `0.3.4-alpha.1`, mettre à jour au minimum les règles et contrôles actifs concernés : ```text RULES.md docs/rules/VERSION_WORKFLOW.md docs/rules/RULES_SESSION_PLANNING.md docs/rules/PROMPT_STRUCTURE.md docs/rules/RULES_DOCUMENTATION.md scripts/audit_project_workspace_rules.py ``` Chercher également les références normatives/courantes à l'ancienne convention sous `docs/rules/`, `scripts/` et les README actifs, puis les réconcilier lorsque leur sens est prospectif. ### Immutabilité historique absolue Ne jamais renommer, déplacer ou réécrire pour cette migration les anciens jalons déjà livrés, notamment : ```text deltas/0.1.0/ ... deltas/0.3.3/ history/0.1.0/ ... history/0.3.3/ anciennes entrées CHANGELOG décrivant ces versions anciens prompts qui documentent leur workflow réel ``` Ces fichiers restent des preuves historiques avec leurs identifiants `0-pre`, `1-alpha`, `2-beta`, `3-rc`. Les audits doivent accepter cet historique tout en imposant la nouvelle convention aux versions futures. Les archives delta futures suivent naturellement : ```text games-sasedev-X.Y.Z-alpha.N-delta.zip games-sasedev-X.Y.Z-alpha.N.fix.M-delta.zip games-sasedev-X.Y.Z-beta.N-delta.zip games-sasedev-X.Y.Z-rc.N-delta.zip ``` ## 3. 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 architecture/réseau : ```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 history/0.3.3/ deltas/0.3.3/ ``` Auditer ensuite les crates réelles susceptibles de porter les contrats transport/client/serveur. Ne créer aucune abstraction ou crate uniquement parce que ce prompt mentionne un nom possible : `alpha.1` doit déterminer l'ownership physique à partir de l'architecture actuelle. ## 4. État hérité attendu de 0.3.3 La stable `0.3.3` doit laisser : - gameplay/moteur Rust partagé inchangé ; - Desktop SDL3, Web/WASM et POC Tauri existants ; - voie Android productive SDL3 natif/Java/JNI ; - build Android possédé par Gradle/Cargo sans orchestrateur Python ; - APK Debug universal et AAB Release pour `arm64-v8a`, `armeabi-v7a`, `x86_64`, `x86` ; - `minSdk 21` réellement fumé sur x86 ; - compatibilité 16 KB 64 bits réellement fumée ; - Gradle système `>= 9.6.0` et JDK courant de l'environnement ; - aucune dépendance réseau realtime imposée au moteur de rendu ou au gameplay. Ne pas rouvrir le pipeline Android dans `0.3.4` sauf régression directement provoquée par le nouveau scope. ## 5. Mission 0.3.4 Introduire une **API de transport realtime** et une baseline WebSocket fondée sur Tokio + `tokio-tungstenite`, sans implémenter encore le serveur Uroburas Mode 3 ni figer prématurément tout le protocole multijoueur. La frontière durable reste conceptuellement : ```text transport ↓ wire codec ↓ session protocol ↓ synchronization ↓ authoritative simulation ``` `0.3.4` se concentre sur le premier étage et les contrats minimaux nécessaires pour le tester proprement. Une socket ouverte ne doit jamais être confondue avec une session gameplay synchronisée. ## 6. Scope inclus `alpha.1` doit inventorier et décider au minimum : - emplacement de l'API de transport realtime et sens des dépendances ; - séparation client/server et éventuels types communs réellement nécessaires ; - connexion, fermeture, send/receive, erreurs et cancellation async ; - ownership Tokio/runtime sans le propager inutilement dans le gameplay ; - baseline `tokio-tungstenite` WebSocket ; - stratégie de codec initiale suffisamment simple pour le POC sans figer le protocole final ; - timeouts, backpressure et limites élémentaires ; - test loopback/local déterministe ; - logging/tracing transport séparé des futurs domaines session/sync/simulation ; - compatibilité future avec un autre transport, notamment le POC WebTransport/QUIC de `0.3.5`, sans abstraction spéculative excessive. ## 7. Hors scope Ne pas transformer `0.3.4` en serveur de jeu complet. Sont notamment hors scope sauf nécessité démontrée par le POC transport : - Uroburas Mode 3 ; - matchmaking complet ; - simulation authoritative de jeu ; - snapshots/deltas métier définitifs ; - prediction/reconciliation ou rollback ; - Redis/NATS/Kafka ; - persistence gameplay ; - auth complète ; - scaling/sharding/regions ; - WebTransport/QUIC de production, réservé au POC comparatif suivant ; - Actix Web comme dépendance obligatoire du data plane realtime. ## 8. Contraintes architecturales Préserver : - async-first pour les nouvelles API réseau ; - aucune dépendance transport dans les crates gameplay ; - distinction stricte transport/session/sync/simulation ; - façade `lib.rs` et ownership modulaire conformes aux règles Rust du dépôt ; - `tracing` pour les diagnostics ; - erreurs explicites, cancellation et fermeture propres ; - pas de framework générique massif avant deux consommateurs réels ; - WebSocket baseline remplaçable/comparable par le futur POC WebTransport sans réécrire le gameplay. ## 9. Cadrage alpha.1 obligatoire Avant développement lourd : 1. effectuer la migration de nomenclature décrite plus haut ; 2. auditer la stable `0.3.3` et les règles après migration ; 3. réévaluer les études réseau existantes ; 4. vérifier les versions actuelles et contraintes des dépendances réellement envisagées ; 5. décider l'ownership physique des crates/modules ; 6. définir le contrat API minimal et les erreurs ; 7. définir les tests loopback et les gates ; 8. évaluer le besoin éventuel d'un petit demo/CLI uniquement s'il apporte une preuve utile ; 9. créer `docs/plans/004-V0_3_4_REALTIME_TRANSPORT_WEBSOCKET_PLAN.md` ; 10. produire un forecast souple jusqu'à stable, avec beta de validation large, RC gelée et release mécanique. Si le scope dépasse raisonnablement une seule session/version, le scinder dès `alpha.1`. ## 10. 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 et ne sont jamais déclarés réussis sans sortie réelle. Dès qu'un fichier Rust/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 par défaut ; `cargo test --workspace --all-targets --all-features` est réservé aux jalons larges/finalisation planifiés. Toute commande nécessitant un changement de répertoire utilise un sous-shell `(cd ... && ...)`. ## 11. Deltas, historique et changelog À partir de `0.3.4`, les nouveaux fichiers utilisent uniquement la nouvelle nomenclature : ```text deltas/0.3.4/alpha.1.md history/0.3.4/alpha.1.md # créé seulement après validation, par le jalon suivant ``` Un échec de `alpha.1` produit `alpha.1.fix.1`, pas un retour vers l'ancienne convention. `CHANGELOG.md` reste normalement silencieux avant RC. `ROADMAP.md` reste macroscopique. Aucun ancien delta/history n'est renommé pour homogénéiser l'apparence. ## 12. Forecast initial non contraignant `alpha.1` doit le réviser à partir de l'audit, mais la direction initiale est : ```text alpha.1 migration nomenclature + audit + requirements + plan + contrat minimal alpha.2 API transport async + types/erreurs/tests unitaires alpha.3 backend WebSocket tokio-tungstenite + loopback alpha.4 intégration/diagnostics/backpressure/fermeture propre beta.1 validation large et POC reproductible rc.1 gel, documentation finale, prompt suivant 0.3.4 promotion mécanique ``` Les numéros peuvent être regroupés ou scindés ; aucune phase ne doit être créée par cérémonial. ## 13. Condition de fin de session La session ne vise pas une simple prerelease : elle doit mener `0.3.4` jusqu'à une stable concrète, sauf découverte imposant explicitement un redécoupage de scope vers une version suivante.