games/prompts/005-V0_3_4_START_PROMPT.md

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 :

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 :

0.3.4

Première tranche attendue après migration de gouvernance :

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 :

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 :

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 :

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 :

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 :

RULES.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md

Puis au minimum :

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 :

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 :

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 :

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 :

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 :

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.