Sasedev/games
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.3.5-beta.2

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-22 11:38:58 +02:00
parent 48444dce7f
commit 6ccdebb241
15 changed files with 692 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

403
prompts/007-V0_3_6_START_PROMPT.md Normal file
View 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.