# 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 accompagne la stable `0.3.5`. Il doit être utilisé uniquement après validation du delta stable, commit de release et publication effective du tag `v0.3.5`. L'archive ZIP téléchargée depuis ce tag devient alors la baseline autoritaire de la session `0.3.6`. 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/.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.