games/prompts/007-V0_3_6_START_PROMPT.md

<!-- file: prompts/007-V0_3_6_START_PROMPT.md -->
<!-- version: 2 -->

# 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/<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.