0.3.3-3-rc.1

2026-09-21 14:35:57 +02:00
parent 58ecd667b0
commit 01df07d6af
8 changed files with 625 additions and 6 deletions
--- a/prompts/005-V0_3_4_START_PROMPT.md
+++ b/prompts/005-V0_3_4_START_PROMPT.md
@@ -0,0 +1,268 @@
+<!-- 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.