games/prompts/007-V0_3_6_START_PROMPT.md

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 :

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 :

0.3.6

Première tranche attendue :

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 :

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

Architecture et résultats POC :

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 :

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 :

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 :

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 :

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 :

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 :

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.