269 lines
9.6 KiB
Markdown
269 lines
9.6 KiB
Markdown
<!-- file: prompts/005-V0_3_4_START_PROMPT.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# 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.
|